Corruption, intimidation, robbery, violent assault, forgery, large-scale fraud. No, not the subject of the latest John Grisham novel, but sensational allegations, made public Apr. 4 by Hermitage Capital Management -- until recently the largest foreign portfolio investor in Russia. In a detailed and damning report, titled Criminal Justice -- Russian-Style, Hermitage alleges the fund's Russian subsidiaries have fallen victim to an elaborate con designed to defraud the fund of hundreds of millions of dollars. 
  
The most sensational part of Hermitage's allegations is that the attempted larceny was carried out with the direct connivance of officials in the Russian police. Hermitage alleges the police seized documents and equipment that were instrumental to the attempted fraud, which involved bogus court cases based on forged documents, the aim of which was to sue Hermitage subsidiaries for hundreds of millions of dollars. "The most shocking thing is not that there are corporate raiders in Russia who attempt to steal your shares," says Jamison Firestone, managing partner of Firestone Duncan, Hermitage's law firm. "The shocking thing is that the police worked hand-in-hand with them, and actually performed the theft of the documents so that the corporate raiders could then do their work."

So the two-pronged scam worked in one area and failed in another. The perpetrators weren’t able to steal the assets from us based on the fake court claims, but they were able to steal $230 million from the Russian government by filing amended tax returns on behalf of our stolen companies. What makes this story even more shocking is that we filed six 255-page criminal complaints with the Russian authorities in December last year, one month before the tax fraud took place, and they did nothing to stop it. Two complaints were sent to the Russian General Prosecutor, two to the Russian State Investigative Committee and two to the Internal Affairs Department of the Interior Ministry. There was enough information to prevent the fraud and indict a number of people behind it if the government had acted. 

Instead of doing anything to save the Russian state from this highly sophisticated and organized looting, two of our complaints were thrown out immediately; two were returned to the same Interior Ministry official we were complaining about (essentially, he was being asked to “investigate himself”); and one was thrown out for “lack of any crime committed.” Only one complaint was taken seriously. It was taken up by the Russian State Investigative Committee in early February, but before it could get any traction, the case was lowered to the South region of the Moscow district of the State Investigative Committee (the lowest level of the Committee) and by June, another senior Interior Ministry official whom we had named in our complaint had joined the “investigation” team (again, to “investigate himself”). To this day there has been no serious response by the Russian authorities to this massive fraud against the Russian state. 

As we described in our April letter, the problem of corporate “raiding” is now so endemic in Russia that President Medvedev speaks about it as one of the biggest problems faced by Russian businesses. In this case, raiders have taken this problem to a new and absurd extreme by “raiding” the Russian state itself and so far getting away with it. Together with HSBC, we will shortly be filing new criminal complaints with the Russian General Prosecutor and Russian State Investigative Committee as well as with many law enforcement authorities outside of Russia. It is hard to predict what will happen next in this unfolding and unbelievable saga, but as always we will keep you updated on any further developments as they arise.

Of course we see individual identity theft on a regular basis (actually as Ross Anderson points out its not really identity theft but poor controls on the bank's parts using SSNs as secrets and so on), but you dont see a major corporation stolen every day.

For example, Reconnex that was recently absorbed by McAfee, touts "information protection" before compliance. Similarly, my friends from nexTier only mention "compliance" on a few pages. Even newly unveiled DLP resource  (DLP In-Depth portal) only contains a little bit  of information on how DLP solutions help with various compliance projects. People tout "data protection", " data security", "data governance" (aka "we know big words - bigger than you") or even "data risk management" (aka "we are confused about what we sell")

I decide to explore this curious phenomenon.

Initially, I thought that it was reverse compliance at work? People not wanting to know what content packs up and leaves their network. Then I thought that maybe DLP vendors just aren't "the bandwagon jumping kind" (yeah, right!) Then I thought that they are "beyond compliance" already :-)

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)!  You know, DLP is newer than  most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn't mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says "get a firewall", "deploy log management", "get scanned", "install and update AV" - but where is DLP? Ain't there...

Yes, Virginia, folks who "go by the book" and just "do the minimum" are missing out on the chance to procure DLP while their compliance budgets are still flowing. To me that means that many still don't get the "compliance+" model - buy for compliance -> use for security, operations, having fun, etc. Think what a good DLP solution  will do for you in discovering regulated data across the entire organization, blocking those pesky email with SSNs, PHI (hi, HIPAA) and CCs (hi, PCI) as well as solving plenty of other problems ...

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

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!