Applied Application Security at CodeMash

January 2014, at CodeMash, I'll be presenting my new 4 hours Applied Application Security seminar as a precompiler. It is Tuesday afternoon, on the first day of the conference. A Tuesday precompiler ticket is required for attendance, but there is no additional charge.

We will be covering both testing for the vulnerabilities that I feel developers need to know the most about, and defensive methods that work in today's market. It is a language neutral class - samples will be in Java, C#, PHP, Ruby and occasionally Perl. The topic breakdown is:

• Information disclosure (spilling to Google, exception management, server ops)
• Injection (SQL, OS, Browser, LDAP, AD)
• Authentication and session management
• Data protection

Guddam PowerShell

I had to count SLOC and files for a POC of a static analysis tool

The SLOC were counted using:

ls * -recurse -include *.aspx, *.ascx, *.cs, *.ps1 | Get-Content | Measure-Object -Line

The files were counted using

(Get-ChildItem -force -recurse).Count

Guddam PowerShell. Rocks. So. Hard.

Thirty Thousand Tweets

I am probably going to pass 30,000 tweets with the message that this post will trigger.

When I started using the Internet, NetNews was the way people publicly communicated. Used to be UUCP, thankfully replaced by NNTP, the newsgroups are almost dead now thanks to the proliferation of the web. You used to be able to read my posts form '92 on Google, harking back to when I was a Clarinet major (and Unix sysadmin) at OSU, but I was posting even before then, back in '89. Probably those are around somewhere.

In the mid nineties, I made use of IRC a lot for public conversation. Thankfully, there are no (public) logs of these conversations.

When TB-L first envisioned HTTP, he saw it as a collaborative medium at the outset, but it took nearly twenty years before we truly achieved collaborative web. Twitter is a public conversation, a collaborative web, and I enjoy being part of it. Are there problems? Sure. Does it sometimes fall short of human decency? You bet. Mostly, however, it is a nice chat amongst friends, with the occasional injection of local, national, or international tidbits of interest, and I can't complain about that at all.

Don't put secrets in the URL Querystring

I am working on an app for Facebook right now, and I came across this gem:

Note that because this request uses your app secret, it must never be made in client-side code or in an app binary that could be decompiled. It is important that your app secret is never shared with anyone. Therefore, this API call should only be made using server-side code.

There is another method to make calls to the Graph API that doesn't require using a generated app token. You can just pass your app id and app secret as the access_token parameter when you make a call:

https://graph.facebook.com/endpoint?key=value&access_token=app_id|app_secret

Now, one one hand, they give good advice. A lot of developers think that they can put the app secret in a javascript file in a web app and it is safe. Most of us know that it is not. What most people don't know is that you can't put it in a Flash file or Silverlight file, or even a Windows Store app, because it is easily reversed. That's good advice.

The next advice is less good. Never, ever put a password, multi-use token or a secret of any kind in the URL. The servers on both end of the communication with cache it in the HTTP server log, the routers will cache it, and it is visible on the wire, even under SSL. Just don't to it.

What do you do instead? Put your secret in the POST data. Don't use, or allow a GET. POST bodies are encrypted in SSL, and are not logged.

Six hundred and sixty six XSS vectors, suitable for attacking an API

So I need to attack an API. None of the XSS tools do it well - not Burp, not xsser, not Xenotix. All of the XSS vectors are packed away in Perl or Ruby or Python, or in articles. So I made my own data file.

Honestly, I didn't tweak the number, that what it came out to when I was done.

Anyway, here it is, ready for your File.ReadLine pleasure:

http://pastebin.com/48WdZR6L

Please use it responsibly.

S

Reflected XSS

As some of you know, I have been spending much of 2013 doing security related testing of applications (sometimes called penetration testing, or pentesting). This is a change from my usual, 20 year history of writing secure applications. I am still all about writing secure applications, and will be doing more of that in the future, but there are a lot of apps that need to be fixed.

All of the applications that I have tested this year, from fortune 100 companies to small companies that have a community web presence, have a common and very dangerous vulnerability called Reflected XSS. This is a Cross Site Scripting vulnerability that is related to content driven XSS, but has a different, and very scary, scope - values that are directly written to the user's screen from a POST or GET operation.

I could go on and on about the dangers of XSS, but I'll leave that to OWASP, and instead tell you how to avoid it.  Leave it to this: XSS is a phishing related vulnerability. It requires users to get all clicky with an email, but when it works, it gives the attacker a very easy path to application ownage.

How it works

We all know to encode output by now, but some things, like exception handling especially, escape our view. Error handling is often encapsulated in common controls (as it should be), written quickly at the start of a project. Encoding of the output is usually not handled by the control, and is rarely implemented by those using the control.

Here is an example: a simple web site that expects the user to type the right string:

<asp:Content runat="server" ID="BodyContent" ContentPlaceHolderID="MainContent">
    <h3>Only type "xss" here!!</h3>
    <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
    <br />
    Answer:
    <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
    <br />
    <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
</asp:Content>

 In the back end, I have rolled the exception management into the codebehind, just for example's sake.

protected void Button1_Click(object sender, EventArgs e)
        {
            try
            {
                if (TextBox1.Text != "xss") throw new ApplicationException("The value " + TextBox1.Text + " is not correct.");
                Label1.Text = Server.HtmlEncode(TextBox1.Text) + " is correct!!";
                Label1.ForeColor = System.Drawing.Color.Black;
            }
            catch (ApplicationException ex)
            {
                Label1.Text = ex.Message;
                Label1.ForeColor = System.Drawing.Color.Red;
            }
        }

Now, when we type the right string, the application behaves as expected:

And when we type the wrong string, the application also behaves as expected:

That's as far as much testing takes us.  However, when we type evilstring:

That's when the problems occur. Of course, the bad actor won't just put up an alert().

Fixing it

Fixing the problem is very simple.  Just encode the string you are writing to the screen. The exception manager should assume that string is evil, just like it should with every other string.

protected void Button1_Click(object sender, EventArgs e)
        {
            try
            {
                if (TextBox1.Text != "xss") throw new ApplicationException("The value " + TextBox1.Text + " is not correct.");
                Label1.Text = Server.HtmlEncode(TextBox1.Text) + " is correct!!";
                Label1.ForeColor = System.Drawing.Color.Black;
            }
            catch (ApplicationException ex)
            {
                Label1.Text = Server.HtmlEncode(ex.Message);
                Label1.ForeColor = System.Drawing.Color.Red;
            }
        }

My example is in .NET, which means I had to disable the AntyXSS AntiXSS library, but if you are writing in Rails, PHP or Java you aren't so lucky.  Better to be safe than sorry.  Encode that output folks!!  ENCODE IT!!

Summary of my Windows Store App security BlackHat talk

Last week, I spoke on the security implications of Windows Store apps for Windows 8 at BlackHat Europe. Running the risk of ruining the suspense for later listeners, I decided to take the advice of several of my attendees and summarize my main points here.

Remember, this is just a summary. I am boiling down a 60 minute talk into 12 or so talking points. If you have questions about specifics, ping me in the comments or via the contact form.

Some of this is original research, some of it is just from the documentation, but all of it applies to the security or privacy of Windows Store apps on Windows 8. Doesn’t matter what you think of Windows 8, you will have to deal with it eventually. It is growing faster than XP or 7 did. The store is selling stuff. It is out there. You will have to either scan an app for your company, or deal with BYOD.

This is all about helping you out.

Features with a risk component

• You log into a Windows 8 machine with your Microsoft Account. Apps have access to the account information with only a request at install time. Are your users logging in with personal accounts? Company accounts?
• Capabilities need to be used sparingly. Least Privilege is the rule, not the exception.
• Remote Settings stores the data saved to it somewhere in the cloud.
• Local Settings are saved in an unencrypted XML file.
• The applications themselves are saved locally with source code available or easily obtainable. Code defensively!

Testing Windows Store Apps

• Test backend services with Burp or ZAP.
• Test for the same vulnerabilities you test your web apps for, manually for now.
• Do a code review.

Countermeasures provided by WinRT

•  Hashing and encryption are in Windows.Security, but are sloowwww.
•  Instead of Microsoft Account, use OAuth for auth-n
•  Apps that come across an unexpected error, don’t leak information. They just die!!

There you go. If you didn’t make it to my talk, you don’t need to go to a later rendition (although the demos are pretty awesome). I just want to make sure that people understand what they are getting into with Windows 8 apps.

Are you doing Windows Store app research? If so, drop me a line. You can find me @sempf on Twitter, or use the contact for on the blog here – it works good.

Why I went back to Android from WP8

At BUILD 2012 Microsoft gave me a Nokia 920 Windows Phone.  Ever since then I’ve been using as my primary cell phone.  It has had ups and downs, but in general I enjoyed very much.

Originally, I was using a Samsung Galaxy Nexus.  That phone had served me well for many months before I switched to the Nokia.  I wanted to give the Nokia a fair shot, because I really believe that Windows Phone can succeed.  Although it was a good run, there were several things that made the switch back necessary.  Let’s start with the good things first.

The good

First, the phone is truly beautiful.  I don’t just mean well-built. I mean everything about it is truly amazingly beautiful.  The device itself, the screen, the applications, the start screen.  Everything.  It’s a joy to use.

Second, the integration with Microsoft products is a very impressive.  The office tools work very well.  Skype and Messenger are very good.  The Xbox integration is truly incredible.  Microsoft has done a very nice job of making the Windows Phone platform part of the full Windows suite of products.

Third, despite what people say, the selection of applications is very impressive.  I have yet to find more than one significant application but I need that isn’t in the window store.  The only thing I ever found that was missing was Wuala, but with the weaknesses in Java I switched to SkyDrive anyway.

The bad

Despite the fact that the user interface is very smooth, the whole phone updates very slowly.  It takes a long time to update the applications.  Text messages come in the wrong order.  E-mail takes a long time to synchronize.  In general, network activity is less than wonderful.  When the phone goes to sleep, it forgets a lot.  A lot more than it should.  Every time I wake it to use it have to wait for it to remember what network it’s on, what wifi I was using and what I was doing last.

All of those same lines, and synchronization is very weak.  Trying to get service driven applications to get new data and refresh the cache is very difficult.  If the application developer fails to give you an explicit synchronization option, you’re often out of luck. Often, I had to restart the phone to get things updated.

While there are no lack of applications in the store, developers are not keeping up with new trends.  For instance, there’s no Pebble app for the windows phone.  Windows Phone is still the last in line to get an app for a new online tool, if it ever gets one at all.  I’m not really an early adopter so this isn’t a huge deal for me, but occasionally I’d like to see some of the new stuff that’s out there.  It’s frustrating that I never seem to be able to.

One more thing.  The phone is absurdly heavy.  I know that’s a small thing but after a while it gets to you.  It’s amazing how six ounces matters. Makes my pants fall down.  Nobody needs to see that.

The ugly

The phone reboots 10 times a day.  This is a not the huge problem for me it is for some people because I am not a heavy phone user.  It can get frustrating when I sit down for short ‘break’ (you know what I mean), launch Angry Birds, and immediately get to watch the phone reboot.  Where it really becomes a problem is when some call comes in, and the phone reboots.  This happens to me least once a day.  I have more than a few uncomfortable moments having to call somebody back and explain that my phone reset.

A huge problem is the lack of S/MIME support.  There is just simply is no way to send secure email using Windows Phone.  Yes I’m aware that I could write an application for S/MIME.  But that’s not really my area of specialty in programming, and I have other things I need to write more.  It seems like S/MIME is something that should be supported out of the box on any platform these days.  I mean come on, even Windows Mobile 5 supported S/MIME.

The real nail in the coffin for me is the lack of integration with other e-mail platforms.  Many moons ago I used Microsoft’s online office tools for my business.  The product flopped, and I went to Google Apps.  I very much enjoyed using the Google product since then.  I don’t mind paying for Google Apps, I think Gmail is a fantastic product.  The spam filtering, certainly, and threaded messaging are just too good to leave.  The domain level integration, document storage, search and sharing, and ease of use are just better than anything else out there. Plus, it supports two-factor authentication.

For whatever reason, Windows Phone 8 is horrible running Google Apps. Email synchronization is awful.  Google Talk barely works at all. Notifications don’t work. None of the other applications are available.  Google has decided that they are going to beat Microsoft on at least this one thing, and this is a pretty successful way to do it.  They have not wanted to make their tools available on the windows platform and I can’t blame them.  Microsoft on the other hand has made most of the tools available on Android.  Thus if I want to use a Microsoft tool, it is probably available on the Android platform.  The reverse is not true.

Conclusion

So there you have it.  The problem is not the app store.  The problem is not the lack of the phone’s popularity.  The problem is that in making the phone easy to use and easy to develop for, they have closed the door to too much innovation and integration. It’s really easy to do the things we wanted to do yesterday, and really hard to do the things we need to do tomorrow.

I still think the Windows Phone is an excellent consumer device.  I would recommend it to anybody.  Not too many people worry about A/MIME support, or integration with their business’s Google Apps.  The application selection, games, and Microsoft integration is really very good.  The phone draws stares everywhere I use it.  But it just isn’t right for me, and I can’t make it right for me.  Therein lies the rub.

I’ll still develop for the windows phone.  I’ll still use it as a standalone device.  It just doesn’t work for me as a primary phone, and I can’t imagine that it does for anyone else with specialized needs.  Microsoft has made their decision, and they’re shooting for the 80%. Unfortunately, the 20% are the folk with loud voices.  That might be the platform’s downfall.

Fixing the 'The package contains code signing keys <project>_TemporaryKey.pfx' WACK error

I recently updated a Windows 8 application for a client, but it failed submission to The Windows Application Certification Kit. The problem was shown as: 

The package contains code signing keys <project>_TemporaryKey.pfx

The development key was in the project, but it needed to be to do the signing for the test run. I had no idea what to do so I pinged Jon Box and he asked if the project has been initially done on someone else's machine. That got me thinking - this project file was from an earlier pre-release version of Visual Studio! Perhaps there was a configuration problem with the project itself.

Next, I opened the file uin a text editor and located the PropertyGroup that hosted the key information.

<PropertyGroup>
    <TargetPlatformIdentifier>Windows</TargetPlatformIdentifier>
    <TargetPlatformVersion>8.0</TargetPlatformVersion>
    <DefaultLanguage>en-US</DefaultLanguage>
    <PackageCertificateKeyFile>Tower_TemporaryKey.pfx</PackageCertificateKeyFile>
    <AppxAutoIncrementPackageRevision>False</AppxAutoIncrementPackageRevision>
  </PropertyGroup>

I deleted the PackageCertificateKeyFile to see if Visual Studio would remake it, and it did, and included a hash this time (interesting addition). What was more interesting was that VS changed the ItemGroup node for the key inclusion from Content to None. That was probably the bit that did it.

Hope this helps someone else who runs into this problem.

Viewing the source code of installed Windows Store apps on Windows 8

While it isn't surprising that you can access the files of installed Windows Store apps (they are installed locally after all) it might to come as a surprise to some that the code isn't encrypted or obfuscated at all. In my early conversations with Microsoft I was led to believe that the code would be encrypted as part of the signing process, but that isn't true at all.

Getting to the installed apps

Files for installed apps are in C:\Program Files\WindowsApps, which is 'hidden' so make sure you have 'View Hidden Items' turned on. This folder isn't accessible by the governing user even if you are running as the administrator, which you shouldn't be. The easiest way to get access to the folder is to take ownership of the folder and everything in it.  You can do this with Powershell if you like.

Get-ChildItem 'C:\Program Files\WindowsApps' -recurse | ForEach-Object {Get-Acl $_.FullName}

But is remarkably easy to do in the UI, so that is how I did it.  Right click on C:\Program Files\WindowsApps and select Properties, then click on the Security tab. From there you can click Advanced to get the Advanced Security Settings. As you can see from Figure 1, the owner is TrustedInstaller. 

Click the Change link and then type in your Microsoft Account email address. Then press enter, OK, and OK again to close all of the dialog boxes. From there you can easily navigate to any installed apps.

Open one of these, Amazon for instance, and you can see that the file structure is just as it would be in Visual Studio.

From there you can browse at will.

As expected, apps written in C++ or .NET are compiled EXEs, although the XAML is still browsable. Here is Barnes and Noble's Nook app, as a point of comparison.

Nothing that a small dose of dotPeek won't fix, I am sure. I'll leave that as an exercise for the reader.

The implications

What are the implications of all of this? Not a lot really. For most apps written in JavaScript, there is nothing there that a quick right-click, browse-source won't do for you on that organization's web site. JavaScript is just as discoverable as HTML in those cases.

For some apps, though, there may be some consideration for keys to services such as Google, Bing or other service providers.  For instance, we are using Weather Underground in an app I am developing, and the client's use key is right there in the settings.js file. Usually, that would be accessed server-side in a regular web app, and apparently we are going to have to do something similar for the Windows 8 app. Perhaps wrapping external services in your own service layer and then accessing those to get the values provided by the original service.

There has been some discussion of changing code, recompiling using the provided key, and getting access to for pay content or disabling ads. I am not a fan of ripping of developers (being one myself) so I won't go into that here. It could be a very significant detriment to those seeking to monetize apps, however.

The most significant thing, as usual, is developer ignorance. If the developer doesn't realize that all of the code is easily browsable, then they may make poor decisions in the construction, commenting or production of the code base.

Lesson learned - code as if someone is watching you. Because they are!