My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned. It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

Granting the presence of perverse incentives, what are the operating mechanics that cause widespread bad loans (where the higher interest rates do not adequately cover increased risk of loss) under our present system? After all, the bad lending, while it has a surface plausibility to bankers under cost pressure, is, by definition, not rational, at least for the lending banks and the wider civilization. How then does bad lending occur so often? 

It occurs (partly) because there are predictable irrationalities among people as social animals. It is now pretty clear (in experimental social psychology) that people on the horns of a dilemma, which is where our system has placed our bankers, are extra likely to react unwisely to the example of other peoples' conduct, now widely called "social proof". So, once some banker has apparently (but not really) solved his cost-pressure problem by unwise lending, a considerable amount of imitative "crowd folly", relying on the "social proof", is the natural consequence. Additional massive irrational lending is caused by "reinforcement" of foolish behavior, caused by unwise accounting convention in a manner discussed later in this letter. It is hard to be wise when the messages which drive you are wrong messages provided by a mal-designed system. 

In chemistry, if you mix items that explode in combination, you always get in trouble until you learn not to allow the mixture. So also, in the American banking system.

So Munger identified this volatile combination about 17 years ago at least. In the same letter Warren Buffett added:

A few small sections of Mr. Munger's letter have been excluded: When Berkshire's report exceeds 72 pages, we have problems in binding it. Because of this limitation, either Charlie's letter or mine had to be cut and I decided a coin flip was appropriate. In fact - as things turned out - I finally decided nine flips were appropriate. -- W.E.B.

Only thing I would (and did) add to iang's post is that historically speaking when things are looking bad is when deals are found. Jason Zweig (channeling Ben Graham)

"Could things possibly get worse? I don't know, but I am an optimist -- so I certainly hope things do get worse. Nothing else should satisfy an intelligent investor."

Disappointingly, the author sprinkles the usual super-secret uber-hacker spin throughout the article to make the Red Team seem mysterious and exclusive, with untouchable talent. It’s a little misleading. For starters, there’s the predictable question about success rates:

I’d heard from one of the Department of Defense clients who had previously worked with the NSA red team that OWNSAVAOG and his team had a success rate of close to 100 percent. “We don’t keep statistics on that,” OWNSAVAOG insisted when I pressed him on an internal measuring stick.

This is one of those statements that is difficult for the average reader to interpret. It’s intended to make the team sound like a crack squad of hackers, but in reality it’s the same statistic that every security consultancy cites during sales calls. The truth is, there’s a lot of wiggle room on what is considered “getting in” to the target. For example, some would say that brute forcing an FTP server and downloading some FOUO (For Official Use Only) documents constitutes penetrating the target. Others would disagree.

How about personnel? I thought this was an englightening and accurate statement from the unnamed NSA source:

And like any good geek at a desk talking to a guy with a really cool job, I wondered just where the NSA finds the members of its superhacker squad. “The bulk is military personnel, civilian government employees and a small cadre of contractors,” OWNSAVAOG says. The military guys mainly conduct the ops (the actual breaking and entering stuff), while the civilians and contractors mainly write code to support their endeavors. For those of you looking for a gig in the ultrasecret world of red teaming, this top hacker says the ideal profile is someone with “technical skills, an adversarial mind-set, perseverance and imagination.”

He basically admits that the team consists mostly of people who “run the tools” and only a handful that actually write the tools or do anything cutting-edge. It shouldn’t be that surprising; just as in any large consulting organization, you have some people who run scanners/tools and aren’t expected to be terribly analytical. While the Red Team almost certainly has some superstars, on the whole it is similar in both skillset and composition to a typical consultancy or enterprise security team.

In terms of attracting and retaining top talent, the Red Team faces the same challenges as the rest of the information security industry, with the built-in disadvantage of the government pay scale. If that wasn’t bad enough, they also have to compete with themselves (i.e. the rest of the NSA) for already scarce resources. Given these challenges, how could one realistically expect the Red Team to be as advanced as the article portrays?

Finally, let’s dispel the “super-secret” notion — unless things have changed significantly, the majority of Red Team operations are unclassified. Granted, detailed information is guarded, but you can find reports summarizing past operations if you dig around a bit. One would expect that an operation intended to be truly secretive would never make its way into Google search results.

I want to conclude by saying that this post is not intended to cast the Red Team itself in a negative light. I enjoyed my time there and had the opportunity to work with some smart people. The Red Team’s goals are worthy and noble; clearly, state-sponsored cyberterrorism is a growing concern and as a country we should be as prepared as possible. But realize that we have a long way to go.

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #

Fear, in other words, is a tax, and al-Qaeda and its ilk have done better at extracting it from Americans than the Internal Revenue Service. Think about the extra half-hour millions of airline passengers waste standing in security lines; the annual cost in lost work hours runs into the billions. Add to that the freight delays at borders, ports and airports, the cost of checking money transfers as well as goods in transit, the wages for beefed-up security forces around the world. And that doesn't even attempt to put a price tag on the compression of civil liberties or the loss of human dignity from being groped in full public view by Transportation Security Administration personnel at the airport or from having to walk barefoot through the metal detector, holding up your beltless pants. This global transaction tax represents the most significant victory of Terror International to date.

The new fear tax falls most heavily on the United States. Last November, the Commerce Department reported a 17 percent decline in overseas travel to the United States between Sept. 11, 2001, and 2006. (There are no firm figures for 2007 yet, but there seems to have been an uptick.) That slump has cost the country $94 billion in lost tourist spending, nearly 200,000 jobs and $16 billion in forgone tax revenue -- and all while the dollar has kept dropping.

Why? The journal Tourism Economics gives the predictable answer: "The perception that U.S. visa and entry policies do not welcome international visitors is the largest factor in the decline of overseas travelers." Two-thirds of survey respondents worried about being detained for hours because of a misstatement to immigration officials. And here is the ultimate irony: "More respondents were worried about U.S. immigration officials (70 percent) than about crime or terrorism (54 percent) when considering a trip to the country."

In Beyond Fear I wrote:

Security is a tax on the honest.

If it weren’t for attackers, our lives would be a whole lot easier. In a world where everyone was completely honorable and law-abiding all of the time, everything we bought and did would be cheaper. We wouldn’t have to pay for door locks, police departments, or militaries. There would be no security countermeasures, because people would never consider going where they were not allowed to go or doing what they were not allowed to do. Fraud would not be a problem, because no one would commit fraud. Nor would anyone commit burglary, murder, or terrorism. We wouldn’t have to modify our behavior based on security risks, because there would be none.

But that’s not the world we live in. Security permeates everything we do and supports our society in innumerable ways. It’s there when we wake up in the morning, when we eat our meals, when we’re at work, and when we’re with our families. It’s embedded in our wallets and the global financial network, in the doors of our homes and the border crossings of our countries, in our conversations and the publications we read. We constantly make security trade-offs, whether we’re conscious of them or not: large and small, personal and social. Many more security trade-offs are imposed on us from outside: by governments, by the marketplace, by technology, and by social norms. Security is a part of our world, just as it is part of the world of every other living thing. It has always been a part, and it always will be.

Took the kids to see Iron Man tonight with our cousins Jeri and Danny.  I generally like Robert Downey, Jr and he acted very hard in this movie. However, I just didn't get the story. I remember watching Iron Man cartoons when I was little and reading the comic books, there was some special thing about Iron Man's blood the way I remember it that gave him super hero powers.

In the movie incarnation, Tony Starks is the son of a weapons designer and a brilliant weapons designer himself.  However, he has some serious character flaws. He is kidnapped by some sort of mid-eastern terrorists and take some shrapnel in his chest.  A doctor attaches an electromagnet to a car battery on his chest to keep the shrapnel from going into his heart. Downey then designs some sort of mini-power source to power the electromagnet,  He uses the power source to power a metal suit he builds (long story) and escapes from the terrorists.  From there the movie is fairly predictable and frankly in my opinion not very good.  I didn't understand how he got the superpower, it was just a powered suit and how it worked was pretty silly. 

The ultimate thumbs up or down for me was that both of my sons fell asleep in the movie theater.  The good news is that this is the start of the summer movie season. I am really looking forward to Indiana Jones and the kids want to see Speed Racer!

In modern times, the nearly ubiquitous availability of powerful computing systems, along with the proliferation of high-speed networks, have converged to create a new version of the high seas--the cyber seas. The Internet has the potential to significantly impact the United States' position as a world leader. Nevertheless, for the last decade, U.S. cybersecurity policy has been inconsistent and reactionary. The private sector has often been left to fend for itself, and sporadic policy statements have left U.S. government organizations, private enterprises and allies uncertain of which tack the nation will take to secure the cyber frontier.

This should be a surprise to no one.

What to do?

With that goal in mind, let us consider how the United States could take a Jeffersonian approach to the cyber threats faced by our economy. The first step would be for the United States to develop a consistent policy that articulates America's commitment to assuring the free navigation of the "cyber seas." Perhaps most critical to the success of that policy will be a future president's support for efforts that translate rhetoric to actions--developing initiatives to thwart cyber criminals, protecting U.S. technological sovereignty, and balancing any defensive actions to avoid violating U.S. citizens' constitutional rights. Clearly articulated policy and consistent actions will assure a stable and predictable environment where electronic commerce can thrive, continuing to drive U.S. economic growth and avoiding the possibility of the U.S. becoming a cyber-colony subject to the whims of organized criminal efforts on the Internet.

I am reminded of comments comparing modern terrorism with piracy on the high seas.