Debunking NSLog Misconceptions

It is a fairly common occurrence to encounter iOS applications that are logging sensitive data during mobile application security assessments.  Some examples of sensitive data we have seen logged include authentication tokens, session cookies, passwords, etc. We have also noticed that developers sometimes do not fully understand the implications of logging this data using the NSLog function. Lets walk through some of these misconceptions.

1. NSLog data is only displayed in the device console and not stored on the device.

When writing an iOS application, developers commonly use NSLog for debugging purposes and the data is displayed within the device console provided by XCode. Behind the scenes, the data passed to the NSLog function is logged using the Apple System Log (ASL), which is Apple’s alternative for syslogd. On iOS devices, the data logged using ASL appears to be cached until the device is rebooted.

2. NSLog data cannot be read by other applications.

The Apple System Log C library (asl.h), which is available for Mac OS X, is also available on iOS. This library can be used to print out the contents of the ASL and even perform queries to retrieve specific log data. An example of a query would be querying for data logged by specific applications. One might ask, what about the iOS sandbox? Shouldn’t the sandbox prevent applications from accessing data logged by another application? Unfortunately, the iOS sandbox does not protect the ASL and therefore any application is able to view the data logged by another application. The following documentation details the ASL API for writing, reading and querying data from the ASL:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/asl_search.3.html#//apple_ref/doc/man/3/asl_search

3. iOS prevents applications from utilizing these low level C APIs during their submission review process.

Unfortunately, it does not look like Apple has a strict restriction on iOS applications utilizing the ASL C library in order to retrieve data from the ASL. There are applications currently in the App Store that are able to read and perform queries on ASL data. One example of such an application is the “AppSwitch” application. 

So let us recap,

• iOS application data logged using NSLog utilizes the Apple System Log (ASL) which caches the data logged until the device is rebooted
• The ASL data can be read and queried through a C API available for iOS applications. This API is not restricted by Apple’s application review process.
• The ASL data is not sandboxed and therefore any iOS application can read data logged by arbitrary applications

Due to all these conditions, logging sensitive data using NSLog should be considered a fairly high-risk issue. If applications are logging sensitive authentication data, a malicious application would be able to actively query for this data and send it off to a remote server.

Developers should get in the habit of using a preprocessor macro for performing any logging used during the development process. The following blog post provides a nice walkthrough on how to utilize NSLog when building in DEBUG mode and how to remove all NSLog statements within production builds.

http://www.cimgf.com/2009/01/24/dropping-nslog-in-release-builds/

SOURCE Barcelona: Rails Slides Posted

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.

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

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.

OWASP NYC Slides Posted

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.

The ISSD Conference 2011

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!