CVE-2013-0333 - Ruby On Rails: JSON Parser Derailed

Yet another vulnerability Ruby on Rails vulnerability has been patched today.
Official(ish) notification here: Google Groups: Ruby on Rails Security

This time, instead of XML being used to pass raw POST data as an argument to the backend, the problem lies in the JSON (which was originally considered the work around for CVE 2013-0156) parser which transforms JSON into YAML, which is in turn passed through a YAML parser. This leads to a very similar attack, abusing !ruby/hash:ActionController::Routing::RouteSet::NamedRouteCollection, that was previously thought patched in ROR 2.3.x and 3.0.x.

Here's a look at the problem (activesupport/lib/active_support/json/backends/yaml.rb)

# Parses a JSON string or IO and converts it into an object
         def decode(json)              if json.respond_to?(:read)                 json = json.read            end            YAML.load(convert_json_to_yaml(json))         rescue *EXCEPTIONS => e
           raise ParseError, "Invalid JSON string: '%s'" % json

The bold part is important. This is what further encodes arbitrary user input into a format that supports serialization and deserialization of arbitrary data types by the Yaml parser. Once again, this includes reserved Symbols and arbitrary objects.However, instead of a combination of XML and Yaml, JSON converted into Yaml is the culprit.

The fix replaces the Yaml backend (activesupport/lib/active_support/json/backends/yaml.rb), which allowed single quoted ('foo') strings, with OkJson (activesupport/lib/active_support/json/backends/okjson.rb). The fixed versions are identified as: 3.0.20 and 2.3.16. Due to the similarity to the previous vulnerabilities earlier this month, this is likely to quickly be utilized in the wild. Expect probes soon.

Update 1: POC here: https://gist.github.com/4660248

encoded_yaml = yaml.gsub(':','\u003a') 

 [Clever!]

Update 2: Sample of Metasploit Module Code, based on the previous XML/YAML Vuln

1. !ruby/hash\:ActionDispatch\:\:Routing\:\:RouteSet\:\:NamedRouteCollection\n" +                        "'#{Rex::Text.rand_text_alpha(rand(8)+1)}; " +                        "eval(%[#{code}].unpack(%[m0])[0]);' " +                        "\: !ruby/object:OpenStruct\n table\:\n  \:defaults\: {}\n"                yaml.gsub(':','\u003a')

Windows 7/8 ASLR - Not so Much

This commentary is based on the work published and performed by "Kingcope". The original text and PoCs are located here: http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/

The inclusion of memory protections in Windows 7 (and now Windows 8) was touted as a means to defeat exploitation attempts by:

1) Preventing code execution on the stack [DEP]
2) Randomizing the memory offsets of Programs (and associated DLLs) [ASLR].

While bypassing DEP has been relatively well documented by multiple sources in numerous locations [see: ROP Chains], ASLR has proven a tougher nut to crack. Randomization of the memory space forces an exploit writer to try and predict where in memory to point an instruction pointer that he or she has gained control over. The goal being, of course, to point to an area of memory which contains the writer's arbitrary code.

Current methods for "beating" ASLR include: utilizing browser memory leak bugs or relying on older DLLs that do not have their image bases randomized. Unfortunately, knowledge of a particular memory leak or reliance on outdated third party software are niche* scenarios culminating in the creation of an idyllic attack surface.

That's where Kingcope's research comes in!

The theory presented is fairly simple: DLLs are loaded into memory space as long as there is space available. If no memory (or very little) is availble, the DLL will be put into the remaining memory. But how does an attacker create a situation in which there is no or minimal (and thus predictable!) memory available in which to load a DLL? By utilizing JavaScript in a target's browser to fill memory to the allocated boundary.** When the allocated boundary is hit, a JavaScript exception is raised which causes the exception handler to execute additional code that frees small chunks of memory. The goal is to slowly free small heap blocks and try to add the DLL(s) into memory; when the DLL is successfully loaded, the region (address space) is fixed and predictable, allowing an exploit writer to point an instruction pointer at a fixed location on the heap.

In his example, Kingcope utilizes the Windows Media Player control ActiveX object to illustrate how the previously described method of abusing JavaScript's exception handler can be used to load a DLL into predictable address space.

Now that the selected DLL (The Windows Media Player DLLs, to continue the example) are loaded into a predictable address, execution of shellcode is only an ROP chain away! I won't spoil the rest of the example Kingcope provided [Hint: LoadLibrary API], but suffice to say it is relatively simple to construct an ROP chain by which to execute arbitrary code following a heap spray.

Click the link to view a quick graphic summary.

My GCIA Gold paper was published on sans.org. Also, SANS watermarks

I completed my GCIA Gold paper and it was accepted and published this past week.  Link below:

http://www.sans.org/reading_room/whitepapers/detection/watermarks-prevent-leaks_34087

I wrote it on watermarks and it took me the larger half of the past year to complete.  Boy I really underestimated how difficult it would be. When I read other people's papers I saw a lot of poor grammar and spelling so I didn't take it very seriously and figured I could just knock it out in a leisurely few months.  I couldn't be more wrong.  I spent well over a hundred hours on it, and almost all of the original draft got scrapped.  If you're considering a "gold" level paper for any of the GIAC certifications, be aware it isn't going to be easy.  But when you get it, it's good resume fodder.

I picked the topic of the paper due to the watermarks I noticed on the GCIA practice tests I was taking.  Below are details about SANS watermarks, simply because they were dropped from the paper.  The information was passed along to SANS many months ago so they can act on it if they wanted.  None of this could be exploited in a profitable way, but I found it interesting.

If you look at the monitor at an angle while taking a SANS practice test you can see the watermarks.  On further inspection you may notice it's the exact same number as the exam ID.  You might also notice that the exam ID numbers you get if you purchase multiple tests are sequential.  I collected dozens of numbers from other users and found that this incrementing number is sequential for all users.  You could spawn practice "math tests" to ensure the software worked, and those numbers were also sequential from the same autoincrementing field in their database.  This indicates an inference attack is possible.

Now the purpose of the watermark is most undoubtedly to trace the source of copyright infringement.  The number is unique on a per-test basis and if the test questions were found on p2p networks and the watermark number was carried over, it could be used as evidence against the student that number pointed to.  Since SANS testing costs as about much as a used car, they probably care more about piracy than the average cert vendor.

The problem is that the watermark number is semi-predictable and easily altered.  It isn't apparent that your exam ID is sensitive information and could be used against you as evidence, and I didn't realize it myself when I was asking people for theirs.  If you wanted to frame someone for piracy, it's as simple as asking them for their practice exam ID.

Since the IDs are sequential, you could also spawn many math tests and infer someone else's exam ID numbers when they purchase one.  example:

Exam ID - description
1 - my math test
2 - my math test
3 - my math test
4 - Other person's practice test
5 - Other person's practice test
6 - Other person's exam
7 - my math test
8 - my math test

On my account I would notice a gap between 4 and 7 in my math test IDs and I would know that someone purchased a set of three tests(which is how it goes when they buy the full training, afaik) and #4 and #5 are the practice tests.  Then if I was an awful person I could insert a "4" watermark and release the test question into the wild.  This is a very hit or miss way of framing someone because their practice test is most likely for a different certification than your test question and you can't tell.

Aside from that, one could also infer purchasing statistics from this autoincrement field.  By spawning math tests over time, one could infer how many tests are purchased by observing how many exam IDs were generated by other people.  clusters of 3 are most likely full training purchases, and 1 indicates a single test purchase or a math test.  The math test function is rather obscure on their website and I think it's fair to say that it's rarely used.  SANS doesn't release any information(afaik) about how many tests or trainings are purchased- only how many students pass.  This information isn't very profitable but it is not public either.

Now with all of that said, the real core of this weakness is that they're using their autoincrement field for something important.  It's a convenient field to use because you know it'll be unique and it's always going to be an index and easily searchable.  But it will always be weak to inference attacks, and that class of attacks is very hard to protect against because most of the time it isn't obvious what you could discover with that data.

This attack was inspired by an inference attack I found/reported against a video game years ago.  The account ID was autoincremented and easily obtainable so I could infer secret data like account age and some overall userbase statistics.  In the context of that game it was useful for cheating, so beware of using that field.

And if you ever plan to do evil stuff with this knowledge, this is all i have to say to you.  Spawning tons of math tests on sans exam portal will get you noticed.

JavaScript Anti-Automated Detection

Yesterday, I came across a relatively rudimentary webpage attempting to exploit a vulnerability in Microsoft Internet Explorer. The particular vulnerability in question is defined in CVE-2012-1875 and is identified by Microsoft in MS12-037. Excellent coverage of this exploit in the wild was posted by AlienVault Labs http://labs.alienvault.com/labs/index.php/2012/ongoing-attacks-exploiting-cve-2012-1875/

Though hardly cutting edge now (a fix was issued in June of 2012), I was curious about one of the sections of code. Following the ROP techniques used to bypass Windows Vista (And later) DEP [Data Execution Prevention], there is a section of code, a "Trigger" that looks like the following [Code follows the Break]:

Update on CVE-2013-0422, The Aftermath

Oracle has officially released Java 7 update 11 which addresses one of two vulnerabilities highlighted in CVE-2013-0422.

The reflective (invoke) API vulnerability (introduced in Java 7) has been patched, and it has come to light from posts to the Full Disclosure mailing list that this particular vulnerability was introduced due to an earlier, incomplete patch.
Full write up here: More details on Issue 32 and Oracle's 'fix' for it

The initial confounding information released by Immunity Inc stating that JRE6 could be effected by the "com.sun.jmx.mbeanserver.MBeanInstantiator.findClass" has been refuted by the very same firm after further analysis. This leads to 3rd party substantiation of Oracle's claim that only JDK and JRE 7 update 10 and earlier are affected.
A summary of Immunity Inc's findings:

After further research we found that although theMBeanInstantiator code is the same in both versions, JDK/JRE 6 cannot be exploited.

Original analysis [Warning, PDF!]: https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf
Post Patch Analysis: http://immunityproducts.blogspot.com.ar/2013/01/confirmed-java-only-fixed-one-of-two.html?m=1

Patching the reflective API vulnerability cuts off the vehicle for exploitation of the MBeanInstantiator.findClass vulnerability. However, Immunity Inc indicates that restricted classes can still be called. This calls into question the overall security of the trusted class model utilized my Java 7. It remains to be seen if another vehicle for exploitation will be found, and if so, how soon it will be utilized.

Oracle's official Security Alert can be found here: http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html

Two big takeaways here:
1) JDK and JRE 6, 5.0 and 1.4.2, and Java SE Embedded JRE releases are not affected.
2) The MBeanInstantiator.findClass vulnerability is still present, but currently there are no known alternative methods to utilize this bug.

Off the Rails: A blurb about CVE 2013-0156

Its been quite a January so far, and we aren't even half way through!

Earlier this week (Prior to the January 10th, 2013 Java 0day), another major remote code execution vulnerability was disclosed which effects Ruby on Rails implementations 2.x and 3.x.
Summary Here: http://threatpost.com

So far, a Metasploit module and POC exploit code have been released. The SQL injection vulnerability is nicely summarized here:
 !ruby/object:Arel::Nodes::SqlLiteral 

A trio of vulnerabilities exist, JSON, XML [Parsing], and Remote Code Execution. For more information see the link here:  http://ronin-ruby.github.com/blog. The root of these vulnerabilities lies in the way in which Rails parses YAML input (user-controlled).


If you want an in depth break down of the functionality of the RoR vulnerability:
http://www.insinuator.net/2013/01/rails-yaml/

For a tl:dr
1. The XML case calls Hash.from_xml() passing the raw POST body as argument
2. The YAML string “”— !ruby/object:A\nfoo: 1\nbar: 1\n” will create an object instance of class A and set the object attributes @foo and @bar to the value 1. This means that an attacker can create instances of all classes defined in the targeted Rails application.
3. ^^ All basic Ruby classes are included, meaning this vulnerability is quite broad.
4. The YAML parser used by Ruby supports the serialization and deserialization of arbitrary data types. This includes Symbols and also arbitrary Objects.
5. SQLi (in the form of the arel object) is probably only the first of many different ways to exploit this, as it is essentially remote code execution.
6. Validate input. Seriously.

Mitigation

Upgrade Rails to one of the following releases: 3.2.11, 3.1.10, 3.0.19 or 2.3.15.

New Java 0-day - 1.7u10

Following 4 months of relative quiet from the Java front, today marks the appearance of the first 0day since CVE-2012-5088, which was patched by Oracle in October.

Preliminary reports from multiple vendors indicate this exploit shares some characteristics with CVE-2012-5088, according to Trustwave's SpiderLabs:

On top of using java.lang.invoke.MethodHandle.InvokeWithArguments() from CVE-2012-5088, the attacker smartly takes advantage of MBeanInstantiator in order to get a reference to a restricted class from a trusted caller (MBeanInstantiator is trusted). [http://blog.spiderlabs.com/2013/01/first-java-0day-for-the-year-2013.html]

Alienvault has released a screenshot of the exploit in action against a fully patched version of Java. Their conclusions mirror those of the preliminary findings from Trustwave: http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/

Brian Krebs reports that this exploit has already been included in Pauch's Blackhole and Cool Exploit Kits as well as the Nuclear Exploit Kit. The SANS ISC recommends disabling Java if possible. Fortunately, a feature to disable the browser plugin was conveniently rolled into Java 1.7u10.

For more information, including ISC's recommendation and primary sources, follow the link here http://isc.sans.edu/diary/Java+is+still+exploitable+and+is+likely+going+to+remain+so./14899

Update 1: Exploit code has been published here: http://pastebin.com/raw.php?i=cUG2ayjh

Update 2: CVE candidate has been added: CVE-2013-0422. The exploit has also been ported to Metasploit.

Update 3: Lightly Commented Exploit Code Sample

Click to Embiggen