GDS Blog

SOURCE Barcelona: Rails Slides Posted

Daniel Peláez — Fri, 25 Nov 2011 11:28:17 +0000

My presentation slides (Security Goodness with Ruby on Rails) from last week's SOURCE Barcelona Conference are posted here. During the talk I spoke about strategies for both auditing and writing more secure applications with this popular framework. I covered a number of different topics including: best practices, security tools and APIs, and how to identify and address the most common vulnerabilities.

Thanks to Stacy and the SOURCE Barcelona Advisory Board for putting on such a great conference. As always, I felt very comfortable there and had a great time. I highly recommend attending SOURCE next year and enjoying Barcelona as well.

Ekoparty Presentation: Cloud & Control

Tom Ritter — Mon, 26 Sep 2011 13:15:27 +0000

I gave my first presentation at a security conference on Friday, presenting at ekoparty on some work I did at the beginning of the year on distributing complex tasks to hundreds or thousands of computers. SETI@Home was the project that pioneered the idea of distributed volunteer computing, and their command & control software evolved into a generic project called BOINC. You can run just about any application in BOINC - whether it's open or closed source, uses GPUs, the network, or even if it's not CPU intensive (like nmapping the internet).

Setting up a server isn't the most exciting topic to talk about, so I used two examples to illustrate BOINC in my presentation: factoring RSA512 to recover the private key to SSL certificates or PGP keys and cracking passwords. Factoring was a huge success, but cracking didn't work out that well. BOINC was able to distribute the work and crack things really quickly - by splitting up wordlists automatically based on hash functions I was able to scale out to more machines than I think most people are able to... but the problem came from never actually looking at the output. The best crackers, especially in cracking contests, find patterns in the cracked passwords to make mangling rules and masks and crack more passwords. You could still use BOINC as a work distributor to scale out, but you need to be behind the wheel making work units - not use it as a fire-and-forget system.

Getting applications running in BOINC is a bit of trial and error. If it's an open source application, you have to patch it a little bit and if it's closed source you have to write a job.xml file defining how to run the application. In either case you have to define input and output templates that let BOINC know what files to send with the workunit and to expect the program to produce. And when I was sending a couple hundred MB wordlists and resource files, I wanted to compress them and decompress them on the client, so that added a little bit of work too. To try and make it easier on you, I've released all the scripts, templates, config files, and patches I created while working with BOINC. I've also not just released my slides, but annotated them with links to the reference material for everything mentioned. Everything is up on github.

I've wanted to factor large numbers for a while, and this was actually what got me into this whole mess. I have some (simple) observations about factoring using the General Number Field Sieve, as well as instructions for how to do it yourself (with or without BOINC).

I have to thank Leonardo and all the ekoparty organizers for putting on a great conference. They went out of the way to make the international arrivees as comfortable as possible, and even had simultaneous translation from english to spanish and from spanish to english. Buenos Aires is a wonderful city, and I really recommend you visit!

.NET Server.Transfer vs Response.Redirect - Reiterating a Security Warning

Mark Andrews — Fri, 09 Sep 2011 04:17:00 +0000

During several recent .NET (C#) security code review projects, multiple severe authorization bypass vulnerabilities were identified that allowed unprivileged remote users to access any page hosted on the web server, despite not having been provisioned with the appropriate required security access permissions. (Typically an attacker could leverage this type of vulnerability to access application administration functionality, both to obtain access to application data and to consolidate on-going future privileged access for themselves.)

The primary cause of these vulnerabilities was insecure use of the Server.Transfer method. As we continue to regularly identify and exploit this issue during our security reviews I thought I would write this quick blog in an effort to further raise awareness around this simple yet often overlooked security item.

Ultimately, any use of the Server.Transfer method that takes in user controllable input is likely to result in authorization bypass vulnerabilities (amongst other possible security issues). This is a known issue and is captured in the Microsoft Support KB Article ID: 320976 (http://support.microsoft.com/kb/320976/).

The underlying security “gotcha” that is not well communicated/publicized to developers is that when using the Server.Transfer method, the new page is being retrieved and presented by a separate handler, during which no authorization checks are performed regarding the actual remote user/callers identity. This is very different from the Response.Redirect method which instructs the user’s browser to request a different page, and forces a new page request - thus (hopefully) triggering an appropriate authorization check.

Unfortunately, much of the core standard documentation available to developers makes no mention of this important security factor, including those found on the MSDN site (http://msdn.microsoft.com/en-us/library/ms525800%28v=vs.90%29.aspx). In fact, on first glance the documentation on MSDN states that “Server.Transfer acts as an efficient replacement for the Response.Redirect method” but does not highlight the potential security implications of using this method.

(However, to be fair, the MS Patterns and Practices team do capture this exact issue in Chapter 6 of their “Improving .NET Application Performance and Scalability” publication: http://msdn.microsoft.com/en-us/library/ff647787.aspx)

As an example, the following vulnerable code snip is representative of those we regularly identify and leverage in proof-of-concept authorization bypass attacks:

protected void btnBack_Click(object sender, System.EventArgs e)
{

          string returnUrl = Request["ReturnUrl"];
           if (returnUrl == null)
            {
                returnUrl = "Login.aspx";
            }

            Server.Transfer(returnUrl);
            Response.End();
       }

The function above will redirect the browser to the page contained in the ReturnUrl parameter, unless it is null in which case the browser will be redirected to the login page.

A typical application will have authorization checks to confirm if a user is authorized to view a requested page but as discussed previously when the Server.Transfer method is used, this logic will be bypassed (assuming that the page requested is hosted on the server). As the “ReturnUrl” parameter is user controllable, this function makes it possible to load any page on the server, including admin pages that lower privileged users should not be authorized to view. It is also possible to download DLLs from the /bin directory if the name of the dll is known (the dll can then be decompiled for further analysis). However, IIS does prevent the web.config file from being viewed.

If the Response.Redirect method was used in the code sample above, the browser would issue a new request for the page passed in the ReturnUrl parameter; because this would be a new request it would pass through the permissions checks again and the authorization bypass vulnerability would be prevented.

The Server.Transfer method of course can be used in valid circumstances such as to redirect to a page where the destination is not user-controllable (i.e. perhaps using an index of hardcoded ‘safe’, non-privileged destinations). Developers should take into account the differences between the Server.Transfer and Response.Redirect methods and understand that the Server.Transfer method is NOT always a secure replacement for the Response.Redirect method.

XSS in Microsoft ReportViewer

Adam Bixby — Fri, 19 Aug 2011 16:54:39 +0000

Lost amongst the numerous issues patched during this month's Patch Tuesday was a bug I found in Microsoft's ReportViewer 2005 Web Controls. While the issue was really just a vanilla XSS, the surprising thing was that it was in a product that has been out for 6 years and hasn't been found or patched in that time. You mean to tell me nobody's ever fuzzed that request!? We're not talking about a complex memory corruption bug here! Anyway, the technical details and a walkthrough of the bug can be found below.

Overview
The Microsoft ReportViewer Controls are a freely redistributable control that enables embedding reports in applications developed using the .NET Framework. A Cross-Site Scripting (XSS) vulnerability was found in the Microsoft.ReportViewer.WebForms.dll library. The XSS vulnerability appears to affect all websites that utilize the affected controls.

Technical Details
File: Microsoft.ReportViewer.WebForms.dll (PerformOperation() method of the SessionKeepAliveOperation class)

1) User controllable data enters via the "TimerMethod" URL parameter value and is assigned to the "andEnsureParam" string variable.

string andEnsureParam = HandlerOperation.GetAndEnsureParam
  (urlQuery, "TimerMethod");

2) The "andEnsureParam" variable with user-controllable input is then passed into the "s" string variable which is dynamically building a javascript block. The "s" variable is then passed to response.write(). Writing the un-validated data to the JS block creates the XSS exposure.

string s = string.Format(CultureInfo.InvariantCulture, "<html>
<body><script type=\"text/javascript\">parent.{0}();</script>
</body></html>", new object[]
 { andEnsureParam }); response.Write(s);

Proof-of-Concept Exploit
This vulnerability can be exploited against websites that have deployed the vulnerable Microsoft.ReportViewer.WebForms.dll library. You will note that since the data is being written into an existing Javascript block that the attacker does not need to include any opening or closing tags (i.e.,<img>, <script>, etc) to execute code.

Reproduction Request:

https://test.com/Reserved.ReportViewerWebControl.axd?Mode=true&
ReportID=<arbitraryIDvalue>&ControlID=<validControlID>&
Culture=1033&UICulture=1033&ReportStack=1&OpType=SessionKeepAlive
&TimerMethod=KeepAliveMethodctl00_PlaceHolderMain_
SiteTopUsersByHits_ctl00TouchSession0;alert(document.cookie);
//&CacheSeed=

(Note: During testing of this issue, it appeared as though a valid ControlID parameter value was needed to exploit this issue)

Recommendation
Update to the latest versions. For more information please see http://www.microsoft.com/technet/security/Bulletin/MS11-067.mspx

Accepting Un-Trusted Certificates using the iOS Simulator

Ron Gutierrez — Mon, 08 Aug 2011 00:51:42 +0000

There are scenarios where an iOS developer might want to accept an un-trusted SSL certificate, such as when they are testing their application using the iOS simulator. By default applications using the NSUrlConnection API for performing remote connections contains built-in certificate validation. Therefore, developers or testers may encounter issues when testing HTTPS traffic using the iOS simulator. Some example scenarios may include applications communicating with remote services hosted on a non-production environment using self-signed certificates or the testers who need to debug SSL communication between the application and service using a local proxy tool, such as Burp Proxy or Fiddler. From a developer’s perspective, what is the best way to accept SSL certificates? While performing a Google search, I encountered the following thread on Stack Overflow discussing ways to accept self-signed certificates when using NSUrlConnection to connect to a website. In general, the responses all recommended performing code level changes in order to disable the built in certificate validation performed by iOS. Although, some answers recommend disabling certificate validation against certain hosts, there are also recommendations for disabling validation against all hosts. Given the temptation to copy and paste, this guidance is likely to result in insecure iOS application releases to the Apple App Store as the applications will be susceptible to man in the middle attacks.

Is there a better way to temporarily trust un-trusted certificates within the Simulator? In my opinion, the more secure way is to add the Certificate Authority(CA) certificate which signed the website’s certificate as a Trusted CA on the simulator. On an iOS device, this can be performed easily by opening the CA certificate on the device by emailing the certificate; however this is not possible with the simulator. Behind the scenes, when a CA certificate is added as a Trusted CA on the device, the certificate is inserted into the tsettings table of the TrustStore.sqlite3 database. This database is also used by the Simulator and can be found in the ~/Library/Application Support/iPhone Simulator/<SDK version>/Library/Keychains/ directory on your Mac workstation.

The tsettings table stores the contents of the CA certificate (Fingerprint, Subject, etc) but the only field needed by iOS during validation is the sha1 column which refers to the certificate's SHA1 fingerprint. The table can be manually modified by using one of the many available SQLite clients. In order to simplify this process, I wrote a simple python script which can be used to import CA certificates into each TrustStore database used by the Simulator. The following example will walkthrough the steps for importing the Portswigger CA certificate. Importing this certificate will provide testers with the ability to intercept application HTTPS traffic using Burp Proxy. Although we can view and intercept SSL HTTP traffic while testing applications, the insecurity of accepting un-trusted certificates is no longer built into the application logic

Step 1: Modify the System Preferences/Network Proxy settings on your Mac in order to have all HTTP/HTTPS traffic be sent to your Burp Proxy.

Step 2: Visit an HTTPS website using Firefox. You will be shown a “This Connection is Untrusted” error page. Choose the Add Exception option and then click the View button. Enter the Details tab and you will be shown information about the certificate chain. Select the PortSwigger CA within the “Certificate Hierarchy” listing. Export the Certificate to the directory of your choice.

Step 3: Run the add_ca_to_iossim script and pass in the exported certificate as an argument.

Sample Usage:

python add_ca_to_iossim.py PortSwiggerCA.cer

Successfully added CA to /User/GDS/Library/Application Support/iPhone Simulator/4.3/Library/Keychains/TrustStore.sqlite3

Successfully added CA to /User/GDS/Library/Application Support/iPhone Simulator/4.3.2/Library/Keychains/TrustStore.sqlite3

Run the simulator while proxying through Burp Proxy and you should be able to intercept HTTPS application sent by your application.

The add_ca_to_iossim python script can be download within the GDS Github page.

OWASP NYC Slides Posted

Brian Holyfield — Thu, 16 Jun 2011 19:55:07 +0000

The deck from my recent OWASP session has been posted.

The discussion focused on identifying and exploiting Padding Oracles in custom web applications, and walked through specifics on how to use PadBuster in a variety of common scenarios. Hopefully those using PadBuster will find the second half of the deck a useful reference.

Beyond Padding Oracle - Manger's Oracle and RSA OAEP Padding

Tom Ritter — Thu, 02 Jun 2011 16:54:46 +0000

Several months ago I was looking at the proceedings from #days 2010 and read Pascal Junod's slides Open-Source Cryptographic Libraries and Embedded Platforms. In them, he mentioned James Manger's attack on RSA OAEP, a padding scheme first defined in PKCS #1 v2.0. I hadn't heard of it before, and it interested me enough to investigate. (The paper is available via Google or ACM if you're a member.)

The basics of the attack are similar to the Padding Oracle attack in that a small piece of information is exposed via error messages and doing some clever math you can use that to retrieve the plaintext from the ciphertext. After the ciphertext is decrypted, the OAEP decoding process begins. The decrypted plaintext is supposed to fit in one less byte than the maximum size of the ciphertext. If the plaintext does not have a 00 in the highest byte, the ciphertext is considered to have been tampered with and an error is returned. Because of the properties of RSA, you can directly influence the plaintext p by multiplying the ciphertext c by x^e mod n - where e is the exponent from the public key, n the modulus, and x the arbitrary number you want to multiply the plaintext by. This will produce a plaintext p*x mod n after decryption.

Manger's Oracle relies on manipulating the plaintext and detecting when it has overflowed into the highest byte. Using a method reminiscent of binary search, the possible values of the plaintext are narrowed down until only one remains - allowing recovery of the plaintext from the ciphertext. The number of oracle queries needed depends on keysize; for 1024, it's around 1200.

I checked the popular implementations of RSA-OAEP and found none of them vulnerable to Manger's Oracle. OpenSSL specifically protects against it, calling Manger out by name in the comments. BouncyCastle and the .NET implementation were secure because they didn't throw an error if the first byte was non-zero (probably on the assumption that another part of OAEP, the hash, wouldn't match). Libgcrypt didn't implement RSA-OAEP - a patch had been provided a few years ago, but it was never merged... until a few weeks ago when it was committed to trunk.

The new code wasn't actually directly vulnerable - the same error code was returned no matter the type of error that occurred. Regardless, I decided this would be a fun exercise and set about implementing the attack. I got it working; but only after editing the source of libgcrypt to 'cheat', providing my own oracle. I managed to find a mistake in the original paper too, a floor() that should have been a ceil() - detailed in the code linked later.

Since I modified the libgcrypt code to provide an oracle, it was an overly contrived example, but it seemed like it might be possible to exploit it using a timing attack. After measuring and graphing the differences between the two cases, I saw you could determine the error from timing information - so long as you looked at the percentiles over a sufficient number of trials, as shown below. It isn't 100% reliable, but I was able to get a working proof of concept going with just timing information.

Left two box plots show the longer execution time, right two show the shorter.

I've published the code to exploit the oracle in a contrived case, and included the code and steps to demonstrate the timing differential. The code is on github, and as far as I know, this is the only public implementation of Manger's Oracle. (Although apparently it is assigned as homework somewhere...)

"OAEP Padding" is indeed an example of RAS Syndrome

The ISSD Conference 2011

Andrew Nairn — Fri, 13 May 2011 15:55:20 +0000

The second International Secure Systems Development Conference (ISSD) is being held next week in London, and GDS are once again very happy to be supporting it as both speakers and conference sponsors. Event details this year are as follows:

The 2nd International Secure Systems Development Conference (ISSD)

18th & 19th May 2011, Hilton London Olympia Hotel

Dealing with Tomorrow's Threats Today - by Designing Security In

Both Matt & Justin are speaking on the opening day - Wed 18 May:

10.30am - Are Agile and Secure Development Mutually Exclusive? - Matt Bartoldus
11.45am - Metrics – knowing before you start – Justin Clarke

If you would like to attend its not too late - contact us (mention this blog post) and we can organize a discount on your tickets. Hope to see you there!

Regional Broadcast Using an Atmospheric Link Layer

Tom Ritter — Fri, 01 Apr 2011 15:08:21 +0000

I'm happy to announce my latest endeavor, published today by the IETF: RFC 6217: Regional Broadcast Using an Atmospheric Link Layer. It provides recommendations for broadcasting text or binary data to a geographic region, in an efficient manner that does not impede existing network infrastructure. It also defines a new protocol, Asynchronous Dumb Visual Exchange of Raw Transmissions, for the Network Layer, designed to be both extremely compact but also flexible enough for use in different communities and for different uses.

The RFC does raise, and attempt to address, certain security concerns. If organizations feel this protocol may be beneficial to them but are concerned about testing their infrastructures prior to deployment, Gotham Digital Science is poised to offer the best advice and services relating to this cutting-edge technology.

Hackers Puzzle Challenge in the CSAW 2010 CTF Final Round

Tom Ritter — Thu, 18 Nov 2010 20:37:52 +0000

A few weeks ago NYU Polytechnic held the final round of their Capture the Flag. Marcinand I both wrote challenges for the final round, and my challenge was primarily based around steganographic tricks with file formats, surrounded by some simple cryptography.