Applied Application Security - followup

I had a number of requests for my slides at CodeMash for the Applied Application Security class.

Those slides are from the deck that I use to give my paid training, so I don't toss them around lightly. They have more detail in them than we had time to get into at the con.

Instead, I though I would edit up my whitepaper that I provide to see that it covers the materials that we went over. You can find it attached to this post.

Codemash 2014 Applied Application Security Whitepaper.pdf (657.56 kb)

The exercises were all completed using the OWASP Web Goat on the SamuraiWTF virtual machine.

if you have any questions, feel free to contact me using the contact form above.


The importance of securing file upload

On a recent vulnerability assessment, I discovered an unsecured file upload and was challenged by the client.

"Was the file uploaded to the webroot, where it was executable?"

"Well, no." I said. "I don't know where it was uploaded to, but there weren't the necessary protections in place, I can assure you that."

"What can happen if it isn't executable by a web user, then?"

Oh, let me count the ways.

What we are talking about

Allowing file upload from a web page is a common activity. Everything form web email clients to interoffice management systems allow for file upload. Profile pictures are uploaded form client machines. Data is upload to support websites. Anytime you click a Browse button and look at your local hard drive from a web browser, you are uploading a file.

Keep in mind, file upload by itself isn’t a security risk. The web developer is taking advantage of built-in browser functionality, and the site itself doesn’t have any insight into your PC’s internals. File upload is governed by RFC 1867 and has been around for a long time. The communication is one way.

The code for a file upload just has to invoke an enctype of multipart/form-data, and that gives us an input type of ‘file’ as seen in this example snippet:

<form action="http://localhost/"
enctype="multipart/form-data" method="post">
Please select a file:<br>
<input type="file" name="datafile" size="40">
<input type="submit" value="Send">

If the upload isn’t intrinsically bad, then what is? Well, what you upload can be bad – aiming to exploit something later, when the file is accessed.

The classic case – upload to the web root

The case that my clients were interested in is the classic problem. Back in the day, we used to let users upload files into the web directory. So, for instance, you might be able to save an image directly to the /img/ directory of the web server.

How is that a problem? If I upload a backdoor shell, I can call it with http://yourserver/image/mywebshell.php and you are pwned. Anytime I can write and execute my own code on your server, it is a bad thing. I think we can all agree on that. As a community of people that didn’t want our servers hacked, we stopped allowing upload of files to the web root, and the problem (largely) went away.

But the problem of unrestricted file upload didn’t go away. There are still a number of things that pentesters and bad guys both can do to get your server under their control. Here we’ll look at a handful of them.

Uploading something evil for a user to find later

The first, most common and probably most dangerous act is most likely the uploading of malware. Often, business and social sites both allow for uploading of files for other user’s use. If there is insufficient protection on the file upload, an attacker just uploads evilmalware.docx.exe and waits until the target opens the file. When the file is downloaded, the .exe extension isn’t visible to the user (if on Windows) and bang, we got them.

This attack isn’t much different from phishing by sending email messages. Since the site is trusted by the user, however, the malware executable might have a little more change of getting executed.

Mitigation is fairly straightforward. First, in a Windows environment, check extensions. If you are expecting a docx file, rename the file with the extension. Whitelist the extensions you expect. Second, run a pattern analyzing virus scanner on your server. There are a number of products that are designed to be run on web servers for just this case.

Taking advantage of parsers

A far more subtle attack is to directly affect the server by attacking file handlers on the host machine itself. Adobe PDF, Word and images are all common targets of these kinds of attacks.

What happens, is some flaw in the underlying system – say a PDF parser that reads a PDH form and uses the information to correctly forward the document – is exploited by a malware author. Then documents can be created that exploit this flaw and uploaded somewhere where the attacker knows they will be opened.

Let’s talk about just one of these, as an example. MS13-096 is a Microsoft security advisory that warns us that TIFF images could cause a buffer overflow in Windows. This overflow, then, could be used to execute arbitrary code on the user’s context. Remember what we said before: anytime I can write an execute my code on your machine, bad things will happen.

All of that said, doesn’t’ take a lot of technical expertise to write an exploit for that? I mean, you would need to make an image that exploited the flaw, safely put it into a Word document, then write more code to be injected into the overflow, and then have something that takes advantage of whatever we ran.

Well, the answer to that is yes, it is hard to write. So enter Metasploit. This penetration testing tool has a framework for the enablement, encoding, delivery and combination of exploits. Specifically, this one vulnerability can be baked in with already existing tools to deliver, run and get a remote shell using this exploit.

In fact, one already has.

Stealing hashes with UNC pathed templates

Not everything that Metasploit does revolves around a flaw in a software system. Sometimes you can use Metasploit to take advantage of the way software is SUPPOSED to work. For example, did you know it was possible to build a word document that uses a template that is on a UNC path? Neither did I!

Of course, in order to use that feature, Word will have to send it’s NTLM session hashes to the share. That’s only a problem if we have a listener collecting them on the other end of the wire. That’s exactly what Metasploit will do for us.

For this particular example, I use the word_unc_injector Metasploit module. This module allows me to create a Word document that calls to a template at an address of my choosing; I usually use an AWS instance for the target. This example is done in my local lab.

Once the document is made, I try and upload it into the site, as shown in Figure 1. Since it is expecting a Word document, and it got a Word document, we are in good shape.

Uplolading the sample file

Now we wait. When the user opens the file, Word will call out to the template as seen in Figure 2.

The Word opening dialog calling the network share

If it doesn’t find it, it just gives up after a while. Meanwhile, though, the NTFS session hashes are bring stores by my ‘template’ server, like Figure 3.

Woah Hashes

So what do we do about this and other document parser problems? Honestly, there isn’t much you can do. General security principles are best here:

  • Whitelist so you only are allowing the document types you want uploaded.
  • Don’t process files on the server.
  • Run virus scanners on all workstations, and the web server.

DoS with massive files

Sometimes installing or stealing things isn’t the best path at all. Sometimes, I just want to make your server freak out and crash, so I can see the error messages. I keep a Digital Download of Disney’s Brave on my testing box just for that purpose – 3.4 gigabyte file to upload a few times, just to see how your box handles it. Usually it isn’t good.

Only the beginning

These core categories of attacks are the most common, but they are 1) not everything and 2) much broader than presented here. There are several dozen parser exploits in Metasploit, and those are just the ones that are deemed worth the effort. It is much safer to just follow slightly more-strict-than-usual security policy when it comes to file upload and save yourself the trouble later.

Welcome to BlogEngine.NET 2.9

If you see this post it means that BlogEngine.NET 2.9 is running and the hard part of creating your own blog is done. There is only a few things left to do.

Write Permissions

To be able to log in to the blog and writing posts, you need to enable write permissions on the App_Data folder. If your blog is hosted at a hosting provider, you can either log into your account’s admin page or call the support. You need write permissions on the App_Data folder because all posts, comments, and blog attachments are saved as XML files and placed in the App_Data folder. 

If you wish to use a database to to store your blog data, we still encourage you to enable this write access for an images you may wish to store for your blog posts.  If you are interested in using Microsoft SQL Server, MySQL, SQL CE, or other databases, please see the BlogEngine wiki to get started.


When you've got write permissions to the App_Data folder, you need to change the username and password. Find the sign-in link located either at the bottom or top of the page depending on your current theme and click it. Now enter "admin" in both the username and password fields and click the button. You will now see an admin menu appear. It has a link to the "Users" admin page. From there you can change the username and password.  Passwords are hashed by default so if you lose your password, please see the BlogEngine wiki for information on recovery.

Configuration and Profile

Now that you have your blog secured, take a look through the settings and give your new blog a title.  BlogEngine.NET 2.9 is set up to take full advantage of of many semantic formats and technologies such as FOAF, SIOC and APML. It means that the content stored in your BlogEngine.NET installation will be fully portable and auto-discoverable.  Be sure to fill in your author profile to take better advantage of this.

Themes, Widgets & Extensions

One last thing to consider is customizing the look of your blog.  We have a few themes available right out of the box including two fully setup to use our new widget framework.  The widget framework allows drop and drag placement on your side bar as well as editing and configuration right in the widget while you are logged in.  Extensions allow you to extend and customize the behavior of your blog.  Be sure to check the BlogEngine.NET Gallery at as the go-to location for downloading widgets, themes and extensions.

On the web

You can find BlogEngine.NET on the official website. Here you'll find tutorials, documentation, tips and tricks and much more. The ongoing development of BlogEngine.NET can be followed at CodePlex where the daily builds will be published for anyone to download.  Again, new themes, widgets and extensions can be downloaded at the BlogEngine.NET gallery.

Good luck and happy writing.

The BlogEngine.NET team

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
This is a participatory session. To be prepared for this session, please have a virtual machine manager loaded with Samurai WTF. This is a training VM in Linux that has both the training sites, and the tools for testing, preinstalled.
If you are planning on attending and have any questions, please don't hesitate to email me at or call me at 614-402-7207. I'll be glad to fill you in.
Hope to see you there.

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:|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:

Please use it responsibly.


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 />
    <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
    <br />
    <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />

 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)
                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)
                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.


Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.



profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites