Jack Mannino

AthleTechz- Getting the Industry Back In Shape

2011-09-05T22:29:00.002-04:00

First blog post in a while. It's been an insanely busy year, which is a GOOD thing. Business is good, the OWASP Mobile Security Project is finally progressing at a healthy pace, and the world didn't end as predicted.

The majority of us that work in the IT field sit at a desk for extended periods of time every day. Whether it's security, development, or network administration, we generally spend a lot of time at a desk or sitting during meetings. As a result of being so sedentary and combined with the long stressful hours many of us work, there's a higher likelihood that we will pack on the pounds as the years progress.

As for myself, I left the military in the earlier part of the previous decade at a lean 6', 190 pounds. When I got married in 2007. I climbed to about 220 pounds. By 2010, I hit 245. Like many other guys that get married and add a few pounds, I started to make excuses. "I work a lot"...."It's because I eat at night"...."I can't eat healthy on the road"....and the list goes on. Since we moved to the DC area not too long before getting married, I didn't know many people outside of the IT industry. Most of the people I met through work were also techies, and also spent lots of time doing more of the same. While I once had people to play a pickup basketball game with, or head out for a run with, I no longer had the same network of active friends.

Anyone in the security consulting industry knows that work can be brutal. Long hours, tight deadlines for deliverables, crazy swing shift hours (can't test in production during working hours!), and "get it done now" requests by customers can make it challenging to live a normal and predictable lifestyle. As a result, we are sometimes forced to take shortcuts. On the road and juggling multiple tasks? Grab something quick to eat and head back to the hotel to do MORE work. Have to squeeze out an unexpected incident response task because a client was breached? You have to skip that Saturday morning hike you were looking forward to.

I lived this lifestyle for a few years. However, a few things changed in 2011. First, I made friends with some locals in the techie community that are into fitness and healthy living, just like I once was. My best friend from the military days moved to the area, giving me even more of a kick in the ass. It awoke "the old me" and got me back into working out consistently. By working out consistently, other things fell into place. I started eating better. I started sleeping more. And oddly enough, my time management skills improved. Not only do I think clearly these days, I feel better than I have in years and get more done every day. I'm still about 30 pounds from where I once was, but this is certainly a step in the right direction. Before the Spring of 2012, I should be back to where I was while in the military, in the best shape of my life.

The latest numbers suggest that nearly half of America will be obese by 2030. http://www.huffingtonpost.com/2011/08/28/half-america-obese-2030_n_937906.html . If this study was only targeted towards the IT field, my instincts tell me that this number would be much higher. Visit a security conference or look around your own office, and I guarantee you that we are probably already there in terms of 50% obesity. Combined with the long hours we work, this is shaving years off of our lives.

After considering my own personal situation and the factors that contributed to me getting out of shape, I thought it would be a great idea to create a group for techies to motivate each other to stay fit. You don't have to be a world-class athlete, just a techie that understands the pains of our field and wants to exercise more.

http://www.meetup.com/AthleTechz/

The long-term vision is for this group to spawn off leagues for playing sports like softball, football, or even volleyball. Maybe even some running groups that meet 2-3 times a week. I want people to be selfish and suggest the things THEY enjoy, with the goal of finding someone else that also shares that same desire to partake in the same activity. Post a meetup for bowling, golfing, ultimate frisbee, skiing, or whatever YOU enjoy. If you find a few others that also enjoy it and it encourages you to get away from the keyboard for a few hours to burn some calories, then this group has fulfilled its purpose.

Our first meetup is a hike on September 17. I chose a trail that isn't extremely brutal, but scenic and long enough to be both enjoyable and mildly challenging. I'm also trying to organize a flag football game at the beginning of October.

A few other friends have suggested ideas that they'll post as meetups in October and beyond. Hopefully people use this as not only a chance to get fit, but for a great way to do professional networking across niches and outside of our comfort zones. Network administrators and Java developers don't always get together, but within this group they would have an opportunity to co-exist in harmony!

I really hope this group gets some momentum behind it. This is something the industry needs...much more than new certifications and acronyms next to our names =)

-Jack

OWASP Summit Mobile Security Working Session

2011-02-04T05:59:00.002-05:00

While I unfortunately won't be in attendance next week in Portugal, I highly encourage anyone with an interest in mobile application security (or application security in general) to participate in the Summit remotely. More information on registering to participate is available on the OWASP wiki here. Believe me, I'd LOVE to be in Portugal vice stuck on the east coast right now, but our current workload simply won't allow me to escape next week.

There are plenty of other tracks to check out as well. Naturally, as I'm the co-lead of the OWASP Mobile Security Project this session is of extreme interest to me. The session is being chaired by Mike Zusman (the other co-lead of the OWASP Mobile Security Project) and David Campbell.

As for me, I will definitely be participating remotely. Some of the sharpest guys (and gals) in the industry will be locked away for nearly a week to drive initiatives that will shape the future of how we approach mobile application security going forward. We threw together a VERY rough draft of what a Top 10 Mobile Risks and Top 10 Mobile Controls list might look like, but in reality we aren't there yet. This was the product of a few brainstorming sessions between a few of us.

If you are interested in contributing to the project going forward, please get in touch with either myself or Mike. Our contact information is listed on the wiki page. There is a TON of work to be done at this point, so we really need as much help as possible to tackle our initiatives. I'd also recommend joining the mailing list as well to stay current on mobile application security trends and to exchange ideas with the experts.

-Jack

Scary, Scary Mobile Banking

2011-02-01T21:41:00.005-05:00

Short post to demonstrate really bad mobile payment sample code provided by Mastercard.

For a great tutorial on how to N-O-T develop a mobile payment application, take a look at the sample code provided by Mastercard here. For more Mastercard Open API goodness, check these examples out here and here.

In this snippet from the sample code, they are providing a placeholder for hardcoding your companyID and companyPassword in plaintext string format:

final double amount = Float.valueOf(amountInput.getText().toString());

final String currency = "USD";

final String companyId = "your-company-id-here";

final String companyPassword = "your-company-password-here";

final String messageId = "your-message-id-here";

final String settlementId = "your-settlement-id-here";

final String cardHolderName = cardHolderNameInput.getText().toString();

final String accountNumber = cardNumberInput.getText().toString();

final String expiryMonth = expirationMonthInput.getText().toString();

final String expiryYear = expirationYearInput.getText().toString();

And below, we append this to our request and send!!

request.append("<MerchantIdentity>");

request.append("<CompanyId>");

request.append(companyId);

request.append("</CompanyId>");

request.append("<CompanyPassword>");

request.append(companyPassword);

request.append("</CompanyPassword>");

request.append("</MerchantIdentity>");

Hardcoding your credentials is NEVER (I repeat, NEVER) a good idea. Please don't do this. Your companyID and companyPassword are used for both processing payments, and processing refunds. Fully decompiling an Android application is extremely trivial, as demonstrated here. There are also applications floating around that allow 1-click rooting. You don't have to be an uber elite expert to do this stuff.

What concerns me most is the de-centralization of highly sensitive information. This is a bigtime mobile trend. If you are writing code like this and giving 50 employees an Android phone or tablet, what is the likelihood that at least 1 of them will end up getting lost at some point? What is the likelihood that at least one of those devices will get owned at some point? What is the likelihood that a malicious employee would take this information and rob your company blind? Pretty high, in my opinion.

In a perfect world, this type of architecture would involve a very simple upstream web service and web server where the credentials could be stored in a secure way. The web service would ask for the credit card information, and THAT'S IT. There's less of a risk of data leakage with one target instead of 50.

There are lots of very important design aspects to consider when rolling out this type of capability. If you are in the business of losing money, then copy and paste this code and begin processing mobile payments. And don't even consider putting something like this in the Android market because I will find it ;)

-Jack

Dangers of Rooting Your Mobile Device

2010-11-07T21:14:00.008-05:00

Many people root or 'jailbreak' their Android and iOS devices in order to gain access to features limited by the security models of each respective platform. In exchange for added capabilities, these people are essentially accepting (with or without their knowledge) the fact that they've removed pretty much all security protections from their environment. This post will provide an overview of how the Android security model works, and detail some of the dangers of using a rooted environment. We will use Android as our platform of choice.

Each application installed in Android runs as a separate user in its own process space. Every application user has its own User ID (UID), and this configuration is designed to only allow that application to access associated files and databases. While it is possible to grant external applications the ability to access some of this information through Content Providers and by signing multiple applications with the same certificate, the default configuration does not allow it. The Android security documentation on the developer website has an excellent overview of how permissions are assigned to applications: http://developer.android.com/guide/topics/security/security.html

Android permissions such as the ability to read SMS messages, install packages, access GPS coordinates, and many more must be declared at the time of installation within the Android Manifest file. When a user installs an application, the requested features in the Manifest file are displayed to the user. If they agree that they want to allow the application to do something potentially dangerous such as make phone calls on their behalf or track their location, the application is installed with those rights granted to the code. Group IDs (GIDs) are assigned to each permission, and the application's UID is then placed into the respective group required to use the feature. If an application attempts to call an API feature that they have not been granted explicit access to, a security exception is thrown. This model is in place to prevent an arbitrary application from using dangerous features without a user's explicit consent, although most users really don't care about the permissions an application requests anyway.

As anyone with even a beginner's knowledge of Linux would expect, running as root gives you complete control to do pretty much whatever you want. Assuming a phone is rooted, there is no limit the amount of evil a malicious app can perform. For many years, we've preached the virtues of"least privilege" access. An administrator should NEVER browse the web using a highly privileged account. Likewise, those of us Linux and OSX users use a regular account for daily activities, while using 'sudo' to perform something sensitive such as changing system settings or installing software.

The code below can be used by an application to test whether or not it is running on a rooted device. If it fails, you know that root access is not possible without an additional exploit. If you are developing highly sensitive mobile business applications within your organization, this type of check may be useful to track down users who are exposing your information in really dangerous ways. It can also be used by malicious applications to determine if it is running as root, which allows the application to do really bad things, or download additional code that can do really bad things. This extremely simple code can be called within the main Activity at startup. You'll need to import java.lang.Runtime to do this:

public boolean isRoot (View v) {

try

{

Runtime cmd = Runtime.getRuntime();

cmd.exec("su");

CharSequence result = "You are root";

Context context = getApplicationContext();

Toast toast = Toast.makeText(context, result, 10);

toast.show();

return true;

}

catch (Throwable t)

{

CharSequence result = "You are not root.";

Context context = getApplicationContext();

Toast toast = Toast.makeText(context, result, 10);

toast.show();

return false;

}

So assuming that we are playing with a rooted device, what can we REALLY do with this power? Lots of things, such as:

Trojan other legitimate applications
Wipe a device
Read all files and databases
Install other applications
Exfiltrate data
Install reverse shells
Log keystrokes
Enable a user's microphone
Access GPS
Read and send SMS messages
Make phone calls
And much, much more

You may be asking yourself,"but don't you need to be granted the explicit right to do so?" Recall that these permissions are declared within the Manifest file for each application, and are defined within the /etc/permissions/platform.xml file as well. As root, you have the ability to read and write to both of these files. You can edit platform.xml directly, and as root you'll have the ability to remove a package and re-install a trojaned version with your own permissions (and code). As a malicious application author, a rooted phone is your best friend. There is no need to compromise the device because the owner has already done this for you.

I'm working on some particularly nasty proof of concept applications that demonstrate some of the more malicious things someone can do to a rooted device, or really mobile devices in general. Debating whether to release it or save it for Shmoocon and Blackhat DC :-)

Storing Data On Mobile Devices The Wrong Way

2010-10-05T15:21:00.002-04:00

Storing sensitive data such as credentials in plain text is a bad idea, especially for mobile applications. Mobile devices certainly have a much greater likelihood of being lost than a desktop computer or server. As a good developer, you owe it to your users to protect their information at all costs.

This tutorial will show you how to check an Android device to determine if sensitive information is being blatantly stored in the clear. If you are professionally testing an Android application, you should be closely examining what the application stores on the device in its data directory as well as in other places such as system logs and sqlite databases. We'll be using ADB to browse the file system and take a closer look at some of the files present on the device. We will also use the sqlite3 utility included with the Android SDK to examine a client-side database. Our victim application will the popular Evernote app, which has been written for pretty much every mobile platform in existence.

Assuming Evernote is installed to either a physical device or to a virtual device running in the Android Emulator, we'll use ADB to browse to the directory where the application stores its information. The application stores this information under /data/data/com.evernote.

Jack@Android_Fun =>>> ./adb shell
# cd /data/data/com.evernote
# ls
cache
databases
shared_prefs
lib

Let's examine the contents of the "shared_prefs" directory. Many applications use a similar directory structure, so you should always look for this stuff in the /data/data/com.whateverapp directory. The file "com.evernote_preferences.xml" is where application-specific information is stored for Evernote. Outputting the contents of this file gives us the following:

# cd shared_prefs
# ls
com.evernote_preferences.xml
# cat com.evernote_preferences.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="serviceHost"><string name="username">happy_gilmore</string>
<boolean name="ACCOUNT_CHECKED" value="true" />
<string name="password">MyPassword123</string>
<int name="servicePort" value="0" />
<boolean name="NotifyUploadStatus" value="true" />
</map>
#

Whoa!! That sure looks like a password to me. Right there in the clear. Rule #1 of mobile development: NEVER DO THIS!! If you absolutely must store credentials on the device, it should be hashed (and salted) using a secure hashing algorithm such as SHA-2. Never, ever do this. Your users deserve better.

The sqlite3 utility included with the Android SDK allows you to work with the client sqlite databases that many applications use to store client-side information. The following command output shows you how to open a database, list tables, and execute a simple "select" statement:

Jack@Android_Fun =>>> ./adb shell
# cd /data/data/com.evernote
# ls
cache
databases
shared_prefs
lib
# cd databases
# ls
Evernote.db
webviewCache.db
webview.db
# sqlite3 Evernote.db
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
android_metadata note_tag resource_attrs tags_table
data_cache_state note_thumbnails resources
error_log_table notebooks saved_searches
note_attrs notes search_history
sqlite> select * from notes;
65f00f4b-676b-4f45-a9d0-2dcbf5bc1bc2|d7aede0e-ec5d-4ab8-8670-5070d5c0a35e|My Banking Information|289|1?j?4????s|1286304619000|1286304825000|0|1|4|1|5|0|0|0
8ea7f9c7-30b0-4112-98d3-4d78b81e79d5|d7aede0e-ec5d-4ab8-8670-5070d5c0a35e|My Personal Information|321|”??^?A??FdJ|1286305164000|1286305164000|0|1|7|1|5|0|0|1
sqlite>

Take the time to do your due diligence to ensure that these very simple to prevent issues don't manifest themselves. While you may think you've caught every instance of where data may be potentially be exposed, taking a close look at the application in use may prove otherwise.

Gaining unauthorized physical access to a mobile device is a very real threat. Even if a user password protects their device, gaining access to data is as easy as plugging the phone in and attaching it to ADB. Also never assume that the user's device won't be rooted (or jailbroken for iOS devices), effectively negating most of the built-in "protection". All it takes is a single malicious application to be installed on a rooted device for this information to be easily extracted.

We have only begun to scratch the surface of the vulnerabilities present within mobile platforms. While you cannot protect against the unknown, minimizing the surface for potential issues by writing code that addresses issues we DO know about today is the only way to ensure your applications withstand the test of time.

As an eye opener, take a look at every application installed on your mobile device. I guarantee you that at least one application (likely many more) is exposing your information in a similar and insecure fashion.

Reversing Android Apps 101

2010-09-28T17:03:00.013-04:00

First blog post in a long time, so I figured I should start back off with something I've been getting a lot of questions about lately, which is how to get started with learning more about Android application security.

I think the absolute best way to understand what's going on is to start looking at real world applications. This tutorial will show you how to download an Android application and convert it back into a format that we prefer, which is its original Java code. Hopefully this will be the first tutorial of many, so be sure to check back from time to time.

I hope this post can be of use to developers as well, in order to better understand that the code they allow to be distributed on mobile devices can easily be decompiled. If you are storing hardcoded credentials or reference other things you don't want the user (or bad guys) to know about, you should re-evaluate that design choice.

My disclaimer is that this should not be used for malicious purposes, etc etc and all of the other stuff no one will likely listen to.

To get started, you will need these applications on your box:

-Android SDK
-dex2jar
-apktool (JAR and dependencies)
-JD (or a similar Java decompiler)

The first step is to download the Android SDK (Software Development Kit). You will rely on this heavily when testing applications and interacting with Android devices. There are many useful utilities bundled with it including Android Debug Bridge (ADB) and the emulator.

The next step is to download an interesting application to rip open. Most of us are Twitter fans, so why don't we take a look at the Twitter application for Android?

At this point, you have 2 choices:

-Download it to your physical Android device
-Download it to a virtual device running in the Android emulator

By default, the virtual devices available using the emulator that comes with the Android SDK do not have the Google Market application installed. You can either 1) spend time finding ways around this or 2) install an image that has the software pre-loaded. Here is an excellent tutorial on how to go that route, although you may want to use a more up to date image than the ones referenced. They use older versions of Android.

Android Emulator Tutorial

Assuming you have either plugged your phone in or started an Android virtual machine, in the tools folder of the Android SDK folder, you'll find several utilities incuding ADB. I recommend familiarizing yourself with it, as you will use it almost constantly if you are working with the Android platform.

ADB allows us to do many things including connect to the device and have shell access. We first need to figure out where the application we downloaded is stored. Under the /data/app/ directory, we will find all of the APK files for applications we've downloaded. Under /system/app is all of the applications included with your Android distribution. For this tutorial, we are concerned with /data/app as this is where our Twitter application will be located.

Now that we know what we want to download, we need to transfer the file to our local system for further analysis. This can be achieved also by using ADB.

We will not be using the shell this time, but rather the "pull" command which allows us to select and retrieve files from the Android device. The general format for this command is: adb pull apk_file destination_directory

Now that we have the APK file, we'll need to unzip it. The APK is simply in standard ZIP format, so any of your existing ZIP compatible utilities will work.

After unzipping the APK file, there are two things you should be primarily concerned with at this point: looking at the manifest file, and getting the .DEX file into a more desirable format to work with. The manifest contains juicy information like permissions, intent filters, and lots more. If you aren't familiar with the manifest file and how its used with Android applications, I highly recommend reading the documentation on the Android development site:

Manifest Intro

If you try to open the AndroidManifest.xml file that was just unzipped, you'll find that it isn't in plain text. We'll use apktool at this point to convert it into a format we are comfortable with. We'll use apktool to decode the entire APK, and then the manifest file should be much easier on the eyes:

After running apktool, this is what the AndroidManifest.xml file should look like when viewed in a text editor or Eclipse:

The classes.dex file in the originally unzipped APK file is the crown jewel here. It contains all of the application's code, but in the Dalvik Executable format.

There are tools such as dedexer and apktool that will convert .DEX into smali assembly format, but again we are concerned with looking at the Java code. We can use dex2jar to achieve this:

dex2jar.bat path_to_classes.dex

Once we've run dex2jar, there will be a classes.dex.dex2jar.jar file in the folder where the original .DEX file was located. Simply unzip this JAR file. Upon unzipping it, we see a bunch of .class files.

Nothing to worry about, this is familiar territory at this point. Simply use your favorite Java decompiler to convert from bytecode to easily readable code.

We now have complete access to the entire client application. In the tutorials to come, I'll show you some things you should be paying close attention to when reviewing or designing an Android application.

GoDaddy XSS

2010-05-14T13:35:00.005-04:00

Just a quick poll. Contacting them directly didn't work, blasting them on Twitter didn't get their PR people to respond, and releasing it to the masses will only cause innocent people to be exploited. I guess all we can do is take guesses at how long it will take them to pull their heads out of their asses.

-Jack

How long will I have to email the GoDaddy security team and Twitter-blast them before they acknowledge and fix their Webmail XSS? (Reported April 30)customer surveys

New Career

2010-04-01T14:07:00.002-04:00

Update: Now that it's April 2nd, I can say that this was my semi-weak attempt at an April Fool's day joke. :-)

It has been a great ride in the security industry, but all good things must come to an end.

When I first started out, there were vulnerabilities everywhere. No one patched, and the last thing on people's minds was worrying about how someone could get into their websites.

Nowadays, security is better than ever. The web is reasonably secure thanks to Web Application Firewalls and XSS filters in browsers. And web scanners and source code review tools have become so advanced that skilled analysis isn't even required anymore!! Even Flash is pretty damn secure. There really isn't much left to do.

I'll be announcing my new business venture in the near future.

-Jack

Marketing Fail

2010-03-09T01:00:00.003-05:00

This one is an oldie but goodie. Every time I see it I get a good chuckle out of it. Read the following paragraph and then check out the actual product. And yes, XSS does make remote administration quite easy =)

"XSS makes both local and remote Web-based central management of XyLoc simple. If a user forgets his Key, there are several options the administrator can choose. Users can be provided with override passwords, so they can access their workstations in the case of a forgotten Key. The XSS records each user override, and can notify the administrator of this action through the XSS auditing feature (see below). If the user is not assigned an override password, the XyLoc administrator can issue a temporary override password on each of the user's computers, or suspend the user's current Key and issue a temporary Key. New employees are quickly assigned Keys, and Keys used by outgoing employees can easily be disabled. Every aspect of managing a XyLoc installation can be performed quickly and easily using the XyLoc Security Server."

Oops....

2010-03-08T18:58:00.007-05:00

So hopefully you've arrived at this blog post in the intended way, which was via re-Tweeting. Did anyone realize that the URL was slashdot.org.tinyurl.com/ye74fag? Probably not. Did anyone notice that it WAS a TinyURL and then attempt to figure out where the TinyURL led to before deciding whether or not it was worth clicking on? Probably not. Were you all using NoScript? Probably not. The script on my site will tally up the metrics of those of you that were letting JavaScript run wild on an untrusted site. Nothing malicious, just an Ajax GET request to a page that doesn't exist and an alert box. You can look at the source if you don't believe me. Nothing malicious.

So nearly all of my followers on Twitter are security professionals, yet many of us (including myself) get lazy at times and fail to do our due diligence. We interact with the same people every day, we pass around their links and they pass ours around. Its routine. We start thinking that we know who is sitting behind the other keyboard, even though we may have never met them and we don't really know anyone that knows that person either. We are all one big family.

If we as the people who should "know better" can get duped into clicking on things we shouldn't and trusting people we shouldn't, what makes anyone think the people that don't understand WHY they shouldn't click on things or talk to strangers will resist the temptation to press the shiny red button? They won't. Not without a ton of training, likely to the point where they dread even using the web.

Please feel free to re-Tweet this again and again. Most of us need a friendly reminder every now and then that we aren't above the law.

-Jack

Android (In)Security

2010-02-28T21:06:00.002-05:00

The fact that this type of vulnerability exists in 2010 just blows my mind. There is an extremely simple method to bypass authentication on the Motorola Droid by simply calling the phone and hitting the back button. Yes, that's it. Doesn't matter if you've protected the phone with a security pattern, or even if you've exhausted your maximum number of attempts at guessing the right pattern. A simple phone call along with the back button will get you into the device. No password or security pattern required. The phone is pretty much wide open to anyone with physical access to the device.

Upon discovering this, I was pretty sure that SOMEONE else had to realize this was possible. Turns out several people in Android forums claim to have reported it to Google, but still no fix.

So, who is ready to start rolling Android phones into the enterprise? I didn't think so.

-Jack

Urban Legend: "HTML 5 Will Kill Flash"

2010-02-25T19:00:00.003-05:00

Before I begin my rant, a quick history lesson:

In the earlier part of the decade, Microsoft released a new web framework called ASP.NET. It was the successor to the often criticized Classic ASP platform, and solved many of the issues plaguing ASP.

Fast forward to the present:

It's 2010. ASP.NET has been around for close to a decade, and yet Classic ASP applications are still all over the place. Some are maintained, some aren't. Many are still as vulnerable as they were nearly a decade ago and yet they still continue to be deployed in production. Why hasn't Classic ASP completely fallen off the face of the Earth yet?

There are several reasons. The first is cost. Developing a complex application is a significant investment. Any organization making such an investment wants to receive a maximum return on that investment. Developing an application and then phasing it out within 2 years isn't practical. Developers are also creatures of habit, and sadly some dread learning something that's completely foreign to them. Learning a completely different framework is an undertaking, and since many development shops are ran like true sweatshops, this implies that any and all learning will be done on their own time. Not to mention, a ton of existing code could also be recycled for use in other projects as well.

Now that the history lesson is over, how does this apply to the Flash vs HTML 5 debate? Many of the same things are true today. Flash is everywhere. Stating that HTML 5 will crush Flash in a hurry is essentially stating that the entire web will be written overnight. I'm not a psychic, but I can predict that this simply won't happen and isn't even close to possible. With the economic downturn in recent years, employers aren't hiring as fast as expected and those that have retained most of their employees are doing so on a shoestring budget. If it isn't broken, they won't fix it. Period.

Adobe also pretty much controls the RIA market. Silverlight has barely made a dent, and probably won't do much more than take a tiny piece of Adobe's market share away. Flash, Flex, and AIR fanboys are loyal to Adobe and will not openly embrace a shift away from what they know.

Even if HTML 5 makes possible many things that are only possible using Flash today, do any of you REALLY think that Adobe will go down without a fight? They have a market penetration that others can only fantasize about. They also have the unique advantage of being platform-independent. Therefore, any standards they push will be deployed universally. In the browser world, this isn't the case. Microsoft, Google, Mozilla, and others are all implementing the standards but far from uniformly. Rather, each of them are battling like schoolgirls to implement the newest and coolest features that the other vendor lacks. Adobe doesn't have to worry about this. Design a new feature, roll it into the next release cycle. Enough said.

Since Adobe has the luxury of doing things their own way without the support of the rest of the browser community (and without conforming to standards), they are in a great position to come up with new ways to push the boundaries of what can be done on the web. They make a ton of money from the products they sell, and therefore they will do anything they can to keep developers hooked on sipping the Adobe Kool Aid.

In conclusion, get used to Flash, get used to Adobe, and get used to thinking about how to secure all of the above. Placing your bets on false hopes won't make the web a safer place today. Even if by some miracle Adobe's technologies are gone in 10 years (they won't be), is thinking about what security should look like in a decade going to solve the problems of today?

-Jack

ISSA DC

2010-02-17T01:07:00.004-05:00

Many thanks to the gracious hosts at the ISSA DC Chapter this evening for taking time out of their busy lives to listen to me rant about web application security for an hour. We had some serious audio/video issues to start things off, but overall it was a great experience and I met some awesome new people.

-Jack

Don't Search For Your Social Security Number, Ever!

2010-02-10T17:59:00.011-05:00

Last night I listened to the February 3 OWASP Podcast, and one of the topics discussed was why you shouldn't be searching for your SSN via Google. The reason this is bad should be fairly obvious, but having this information in Google's hands and in the hands of someone with malicious intentions is slightly different. Unless you can (or want to risk) compromising Google's systems, your search requests simply end up within their stockpile of information and hidden from the rest of the world. Or do they??

This is something I've been thinking about for a bit, but their discussion certainly got me thinking harder about the "how" portion. Then it hit me. Google Adwords and Analytics!! The big disclaimer here is that I have not, and will not attempt this theory. While I populated this information in Adwords, I did not let this ad campaign run nor did I allow it to begin collecting numbers. I am merely sharing this idea with all of you to hopefully get your brains spinning around the possibilities of such an attack. The potential attack has several components- the ability to monitor the frequency and identity of social security numbers that are requested through search engines, and the ability to launch targeted phishing attacks based on those searches. My goal is not to enable the criminals of the world to carry out such evil deeds, but rather to educate the community and spread the word about the possibilities of such activities taking place.

The very nature of Google's business model ensures that they wouldn't consider this an issue, and while I don't fully support their level of integrity when dealing with our data, in this case I have to agree with them. While you read this posting, think back to when Google's CEO Eric Schmidt stated the following:

"If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place, but if you really need that kind of privacy, the reality is that search engines including Google do retain this information for some time, and it's important, for example that we are all subject in the United States to the Patriot Act. It is possible that that information could be made available to the authorities."

Now onto the evil....

Step 1 Generate a List of Every Possible Social Security Number.

I wrote a quick Perl script to do this, using both the regular 9-digit format as well as with dashes inserted. If you notice, the ssn array gets cleared at every 100,000 numbers and prints to an output file. I ran the script without this and it slowed my box to a crawl, since there were upwards of two billion values being held in memory. Below is the code to do this. If you run it on a Windows machine, simply change /usr/bin/perl at the top to c:\perl\bin or wherever your Perl directory is located.

#!/usr/bin/perl
use strict;

open(OUTFILE, ">ssnz.txt");
my @ssnz_array;
my $elementsInArray = 0;
my $ssnWithDashes = "";

print "Now generating SSNz\n";

for (my $count = 100000000; $count < 1000000000; $count++)

{

$ssnWithDashes = $count;

$ssnWithDashes =~ s/(\d\d\d)?(\d\d)?(\d\d\d\d)/$1-$2-$3/;

if ($elementsInArray != 100000)

{

push(@ssnz_array, "$count\n", "$ssnWithDashes\n");

$elementsInArray++;

}

else

{

push(@ssnz_array, "$count\n", "$ssnWithDashes\n");

print OUTFILE @ssnz_array;

@ssnz_array = ();

$elementsInArray = 0;

print "Completed $count\n";

}

print OUTFILE @ssnz_array;

Step 2- Create Google Adwords and Analytics Accounts

In this step, several things must be done. The first is to create a new ad campaign and ad group using Google Adwords. I named my new campaign “SSNs Are Awesome”, and the ad group to display my ad “All your SSNs Are Belong To Me”.

Within this ad group, I created an ad that would be displayed every time an SSN is searched for on Google. There will obviously be a certain level of false positives, but somewhere within the noise you should find some treasures. The goal of this ad is to lure people searching for their SSNs to visit this website. If someone is searching for their SSN, they are either curious as to whether or not its floating around on the web, or they may be worried about the possibility that their identity has been stolen. Using fear as our bait here, my example ad says “You may be at risk because your Social Security number was found!”

The next step to this process is uploading the SSNs.

Through a bit of trial and error, I discovered that Google imposes a limit of 2,000 keywords per ad group. Therefore, you would have to create a bunch of ad groups in order to cover the entire range of SSNs. I'm sure that with a bit of tinkering its possible to automate this process though.

The final step is to also create a Google Analytics account. Within Analytics, you want to add a site to monitor (which gets created in Step 3), and take the Analytics Javascript and embed it within the HTML body of your main page. The reason for adding Analytics to this page is so that you would be able to tie the actual strings used in the search engine to the requests to your page, even outside of what may trigger an Adwords ad to be displayed or clicked. The result- a lot more information to harvest and even more potential personally identifiable information that can be tied to an SSN.

Step 3- Create A Site To Collect Additional Information

Simply having an SSN isn't enough. A real criminal would want additional information to tie the SSN to a real person. Getting personally identifiable information is the primary goal of the site that would be getting linked to through the previously created ad.

This is where things get exciting. Not only can we extract information through the Adwords statistics, we can also use the Referer header from the Google search to tie the SSN to the visitor. Even if they don't enter any information, someone evil would now know their SSN and their source IP address, allowing them to conduct further recon if they chose to.

Below is an example of how your search request will always be sent via the Referer header from Google to any site you traverse to through your search results. The sensitive example SSN information is highlighted in red:

What types of evil things could be done from such a site? We could simply use the SSN that was parsed through the Referer header, and create a convincing page displaying their SSN to them and politely asking them to give us more personal information so we can "determine if their SSN is on the web and remove it for them".

As a backup plan in case they are either too lazy to enter this information or if they think the site is suspicious, perhaps dropping a keylogger or something of that nature on the box would be a good idea. Since the SSN is already known at this point, access to their personal accounts such as email and social networking sites would more than likely give an attacker all of the information required to fill in the blanks.

Moral To The Story- Don't Search For Sensitive Stuff!

While Google's business tactics and integrity can and always will be questioned, the bottom-line is that exposing this information to the world should be minimized. I think all of us have at one point or another searched for things we shouldn't have. If those of us that should "know better" do this stuff, you can be confident that those who don't understand what really happens with their data are doing this stuff frequently. Using the tactics described above, you could substitute any type of data to achieve similar results. Corporate espionage, personal spying, identity theft, and many other scenarios can easily unfold by using a little trial, error, and Google's massive horde of personal information.

-Jack

Should We Buy More Tools?

2010-01-19T01:52:00.003-05:00

Short answer: in most cases, absolutely not. Tools alone do not make an application security program successful. In fact, I'd go as far as saying that taking a tool-centric approach to any security program is doomed from the start. Let me explain why with a "purely hypothetical situation."

All too often I've run across organizations that have deep enough pockets to run a very tight ship, yet somehow fail miserably. This evening we will pick on the Federal Government sector. Most groups in the Federal or DoD space have to budget several years in advance to procure actual consultants or contractors to perform a particular subset of services. However, at the end of each fiscal year they fight over huge pots of money. Those that are fortunate enough to justify why they have a rightful claim to some of the funding often go out and spend a considerable amount on tools and other software solutions that they hope will serve as a band-aid for another year or so.

Here is a scenario that ends up unfolding time and time again: Agency A purchases a few licenses for a web vulnerability scanner and a source code analysis tool. Meanwhile, they expect their same mid-level (maybe even "senior") security teams to perform this work properly without any training, hands-on experience, or in-depth knowledge of what they are up against. Armed with new and expensive tools but lacking knowledge of fundamentals, best-practices, etc etc they begin scanning everything. And scanning. And scanning. And scanning. At some point a savvy developer bursts his/her bubble and says "Everything in this scan report is a false positive. Did you verify them first? Did you tune your rules or did you just use the default rules?" The "security" team member responds with "Tune what? Why and how would I verify the results? I'm not a developer. That's your job."

The outcome is that 1) The development team has absolutely no respect, trust, or faith in the security team 2) The security team feels disgruntled at the lack of appreciation for their tireless scanning efforts, and 3) The organization somehow feels invincible in the end because they had no "real" issues to deal with other than internal bickering....even though there were likely thousands of actionable issues that were overlooked. Not to mention severe gaps in their development processes, organizational policies regarding anything and everything related to good application security practices, and ultimately any sense of their true exposure to risk. Therefore, why bother to put forth additional time and effort in building and maturing an application security program. They haven't been attacked. No critical issues were proven to exist. And even though they develop systems critical to our national infrastructure, they aren't a target (really?). Everyone wins, right??

Wrong.

-Jack

Web Browser Exploitation Via Barcode Scanning

2010-01-12T09:33:00.004-05:00

Update 1/18/2010: Tested this idea using ShopSavvy (an Android-based barcode scanning app), and with the default configuration it automatically followed the embedded URL. Very interesting way to attack mobile browsers, especially as the popularity of these applications continue to grow.

Yes, you read that correctly. Until yesterday, I wasn't very interested in barcode scanning software. Until @rybolov gave a short demo on barcodes and brought to my attention the fact that you can embed URLs in them. All it really took were the words "web" and "browser" to get my attention. Anyone that knows Mike in person has surely heard him rant at length about barcode security. There's a chance he even mumbles stuff about barcodes in his sleep.

The only piece of software I have at my disposal is BeeTagg, which is a free Blackberry application. Using an open-source program called Zint, you can create your own barcodes. You can use BeeTagg to scan them using the camera on your phone.

To test this with Zint, you want to create a barcode using the QR Code symbology. Under the "general" tab, enter your URL within the "Data to Encode" field, as shown below:

Next, you want to save this as either a .png or a .svg file. This allows you to print your barcode and do whatever you want with it.

The barcode shown below links to my blog. Try scanning it using whatever barcode reading software you have:

BeeTagg will recognize the URL, but will not automatically follow it. Even with completely relaxed security permissions, a user will at least be prompted that a browser connection attempt was made. Of course you can use a URL shortening service to obfuscate the destination, but regardless a user at least has to click "Yes" in order to connect with their mobile browser. I haven't been able to figure out how to bypass this requirement yet, at least on a Blackberry.

My real curiousity lies within how other barcode scanning applications handle this behavior. Many point of sale systems use Windows XP or some Unix/Linux variants. I'd be very interested to see how many of those automatically follow links. If they were to blindly follow links embedded within barcodes, in theory you could trivially pop some of those systems with browser exploits. Imagine going to the grocery store and owning Internet Explorer 6 using only a milk carton!! =)

In a perfect world, point of sale systems would be properly isolated from production networks. In addition, these very same systems shouldn't be allowed to access the internet via 80 and 443. I'd be willing to bet that many organizations with similar point of sale systems have completely overlooked the fact that this type of behavior may or may not be possible.

If anyone has access to the hardware and software described above, try scanning the image below. If the application automatically instantiates your browser and requests the URL embedded within the barcode, be afraid =) If you can get the browser to fire off, please post a comment or shoot me an email. I'd love to know if I'm right.

-Jack

Not Educating Your Clients? FAIL

2010-01-06T21:33:00.007-05:00

How many of you that have brought in external consultants for some type of security engagement felt like you paid a lot of money for something you really didn't understand? Or better yet, how many of you have brought them in and felt like after they left you had less of an understanding of your environment and what your true risks were? It seems as though its becoming standard practice for a lot of groups to test for a few days (or simply run automated tools), crank out a templated report, and give a short presentation at the end of an engagement without detailed guidance for making the world a better place. Is there any value in this? Maybe, but for what you've likely paid not NEARLY enough.

While many would argue that our job security lies in customers knowing as little as possible about what goes on, I argue that you can achieve the same level of job safety as well as build additional trust and loyalty by not leaving them in the dark. Here is what I consider "leaving your customers in the dark":

1- Using misleading contract language to give the illusion that you are performing something a lot cooler than you really are. Not to mention billing for 30 hours of "reporting" when you are really having your consultants use an automated report generating tool.

2- Stating that your "methodology" requires performing several thousand "unique" checks" (doesn't Nessus/WebInspect/Appscan do that?? hmm). When asked about your methodology, you state that its "proprietary, super secret stuff".

3- Delivering a cookie-cutter report pulled directly from the output of these same tools, without ANY level of analysis or correlation of threats. Correlation example- Threat A is kinda sorta bad, and so is Threat B....when they both exist together, this is REALLY REALLY BAD. That additional layer of analysis and articulation to a client could mean the difference between them getting owned or properly prioritizing their mitigation tasks.

4- Not offering meaningful guidance for risk mitigation strategies, or better yet, how to prevent them from happening over and over.

Getting back to the education part, based on the 4 steps above, how much do you think this client learned throughout the engagement? Answer: not much. Not only do they have absolutely no idea what you did for 40/80/120 hours, they don't know what they are doing right. All they were likely told is "you have 38 instances of XSS, validate input and HTML encode output." No custom guidance stating how THEY should validate their input (what if they have to allow HTML tags...guess stripping all special characters goes out the door). Also, don't assume that just because there were no findings in a specific area that they'll figure out on their own that they did something right. If they have a particular area or approach to securing something that works extremely well, explain it to them so they continue to do it this way!!

Also, unless you are rolling your own in-house stuff that you don't want to release to the public (which you DO have the right to keep "proprietary"), give them advice on resources they can leverage in order to continue to build upon the security improvements that they **hopefully** gained through the services you provided. If you tell them that your toolset is "proprietary" even though it consists of Burp, Nikto, and ::insert_scanner_here::, you are truly doing them a disservice.

I guarantee that if your customers trust you, see the value in what you provide to them, and most importantly they IMPROVE year after year (read that again: IMPROVE), they'll keep coming back. Stop believing all of the "cost per vulnerability found" stuff. If you are using the number of vulnerabilities your consultants discover as your sole criteria for bringing them back, you are making a big mistake. Instead of saying "wow, finding 20 instances of XSS was only $10k", say "wow, we had 7 less XSS findings than last year, and now we truly understand the threat vectors of these vulnerabilities".

2 blog entries tonight...doesn't happen often =)

-Jack

nVisium Security

2010-01-06T21:12:00.008-05:00

Update 1/7/2010: The site is undergoing a facelift, and should be back up within the next few days.

Update 1/18/2010: The site has received a facelift, and is back in action =)

The website is live, but still has plenty of content, functionality, and sexiness that needs to be added. In the coming months I'll be releasing most of my code through nVisium Security's site, in addition to whitepapers and links to presentations. I'll be adding a blog and RSS feed in the very near future, so as soon as I post it to the production site I'll update you all to keep an eye on it.

Here is the link: nVisium Security

Tell me what you think, what needs to be improved in terms of aesthetics etc. Feel free to post comments on my blog, or send me an email if they are REALLY bad =)

Always fun to juggle startup stuff in addition to performing engagements for clients, business development, AND keeping my skills + knowledge on the cutting edge.

-Jack

2010 and Beyond

2009-12-28T22:58:00.002-05:00

Another year has gone by, and looking back at 2009 it certainly was one to remember in the application security world. There were more notable newsworthy incidents than in previous years. Major attacks took place on nearly all major social networking sites, plenty of financial institutions, and tons of government sites. Application security has finally taken center stage, and rightfully so. Nearly everything we do nowadays happens on the web. As more of our routine functions both from a business perspective as well as in our personal lives shift to the web, the criticality of these vulnerabilities will grow more and more. If your organization relies heavily upon web-based technologies and you haven't begun taking security seriously yet, its never too late to start!

Putting it all into perspective, what should we take away from the events of 2009?

1- Solid application security is not, and will never be as simple as pressing a button and letting someone else worry about it. Throwing money at a problem is not the same as solving it. While the art of security can never be deemed a "perfect science" there are plenty of things we can do to get close. Running a simple scanner (source code or runtime) against a pre-production application is not the same as building security into your architecture and design. Implementing a web application firewall is not the same as identifying the root cause of your vulnerabilities and ensuring that your developers learn from their mistakes and begin writing more secure code.

2- A major incident is extremely expensive to triage. If your company is an e-commerce company, have you REALLY crunched numbers to estimate how much money it'll cost to be down for 4-5 days? If you estimate your losses to be upwards of a million dollars a day yet bringing on 2-3 additional full-time application security engineers would cost a few hundred thousand, why on earth would you take such a risk? Everyone thinks "it won't happen to us" until it actually happens to them. The numbers don't lie....if it hasn't happened to you yet, it will. It may already have happened but your attackers weren't interested in raising any red flags.

3- Web technologies are moving at the speed of light right now, and will continue to do so for the foreseeable future. Things moved fast in 2009, and will do the same in 2010. With the emergence of the HTML 5 standard, 2010 is going to be a very interesting year.

Happy New Year to all of you!!

-Jack

New TSA Protections

2009-12-27T18:12:00.002-05:00

My wife and I returned to the US last night after a much needed vacation. On the flight back into the US, we were exposed to TSA's latest and greatest set of security measures put into place in response to this week's incident.

The following list is what TSA put into place immediately following the botched attempt at blowing up an aircraft:

-No electronics are to be used in the last hour of flight
-In the final hour, no one shall have a pillow or blanket on their lap
-No standing or moving around the plane is permitted in the last hour

Yup, thats it. I wish I was making this stuff up. Someone tried to blow up a plane and used a blanket to hide what he was doing, and somehow removing the ability for all passengers to have anything on their laps is going to prevent this from happening again? If a potential bomber manages to get the materials onboard, I'm sure a quick trip to the bathroom mid-flight would be sufficient to prepare his/her weapon. Our reactive (not proactive) solution might work for about a week, until the next person waiting in line to do something similar plans a workaround to address the "no blankets" issue.

To address the obvious shortcomings in the latest security techniques, here are my proposed additions to the new strategy:

-In addition to standard blankets, passengers cannot wear Snuggies in the final hour of the flight

-All passengers will be shackled to their seats for the final hour of the flight

-TSA reserves the right to sedate all passengers with Nitrous Oxide, at random

-All seats onboard the aircraft will have commodes installed so that passengers can't use that lame old "I have to pee" excuse to get up anymore

-Jack

Fun with URL Shortener Chaining

2009-12-02T22:33:00.007-05:00

While trying to think of a clever way to RickRoll my friends on Facebook earlier without any sort of link previewing taking place, I started messing around with some of the shortening services. TinyURL disallows shortened URLs that are already TinyURL shortened, as shown below:

However, TinyURL DOES allow shortened URLs from other services, and other services also allow this behavior as well. If you try chaining a shortened URL through bit.ly, your users/victims will be prompted with a warning like this one:

However, there are plenty of other URL shortening services out there. You can find some other ones here. Using zi.ma, I took a TinyURL link and shortened it via zi.ma. Then, I took the zi.ma URL and shortened it via TinyURL.

I did this twice, TinyURL to zi.ma, then zi.ma to TinyURL and finally TinyURL to zi.ma again. Only by repeating this sequence twice, Facebook essentially gave up on trying to resolve the origin of the link.

My real curiousity is in how this technique would work against web malware filters such as those found within IE and Firefox, as well as what Google provides via its search engine?? Is this technique already being used heavily? What if a site KNOWN to host malware were inserted into an IFRAME on a good site, and using this technique the link was chained through multiple iterations. Would they still flag this behavior when indexing the site and making the determination as to whether or not its a "safe" site?

Thoughts??

-Jack

http://zi.ma/8ac792

Jack's X-Mas List

2009-11-25T18:11:00.000-05:00

Dear Santa,

I know I'm likely to be on your naughty list this year, but I still want gifts anyway. Why? Because I'm Jack Mannino....stop asking questions. My list is short and sweet, and its for the greater good of the security community. Please see my demands below:

1- I want people to focus less on certifications, and more on learning the fundamentals behind whatever they are working on. If someone's job is to assess web applications, I don't want to hear about the 10 domains of CISSP. I also don't want to know about how he/she learned about some cool tools while taking the CEH boot camp. I want them to understand HTTP, be able to understand and manipulate Javascript, and know a thing or 2 about SQL itself. If they want to charge $200 an hour but are unable to tell me what the difference between a 302 vs 500 status code is, they deserve a big lump of coal in their stocking! If you are a "penetration tester" and you can't tell me what the TCP handshake is, you should get coal as well!

2- The world would be a better place if there was less "marketing" and more "doing" going on. Don't try to convince me that your product is better than the next guy's because its cheaper and "more mature." Show me how it is. When you send salesmen out that have zero experience in the field, I am largely unimpressed. Also, don't try to convince people that your product is superior because it helps meet compliance standards. Convince them that it ultimately makes them more secure by showing them real data and evidence, not something staged to work perfectly against Hacme Bank.

3- If you give me just 1 gift this year Santa, I'd like for it to be for people that don't actually enjoy security to find new jobs. Maybe they can come to the North Pole and work for you? When people say "nah, I don't bother with this stuff outside of work", it takes away the holiday cheer!! It demoralizes those of us that genuinely love what we do, and makes it harder to achieve progress.

Thanks Santa,

Jack

Internal Web Server IP Leakage Via Public Crossdomain.xml Files

2009-11-14T01:00:00.005-05:00

So this one is pretty interesting, and happens in a lot more instances than I originally thought it would. The public crossdomain.xml file for this particular server shown below has references to internal web servers via "allow-access-from-domain." What this means is that the developers have given their internal servers the ability to read data from the Flash domain of their external server. Without going too deep into the nitty gritty of Flash and crossdomain.xml, read Adobe's (much better) explanation here.

What you will see (and should take away) from this picture below is that these are internal resource addresses of very critical resources, likely internal websites.

This gives you the immediate connection that there is a sort of transitive trust likely present. As the external site trusts the internal site, the internal site likely trusts the external site. If XSS or any method exists to have users execute malicious Flash objects while visiting the external site from within the NAT gateway (where the 10.x.x.x addresses are relevant), it may be possible to easily launch attacks on internal web servers. The Flash objects could contain scripting and attack code to launch from within the INTERNAL USER's browser, with code to do things like perform SQL Injection on an internal server. Internal web servers won't typically be afforded much attention, and they often go without proper code reviews or development processes. It is assumed that because they are internal, they are unreachable. Not at all the case.

More to come...might have shifted my submission for Shmoo to this area. Lots of fun stuff to explore.

-Jack

The Hidden Costs of Fully Outsourcing

2009-11-05T02:57:00.001-05:00

With the boom in outsourcing and fully managed IT services as well as Software As A Service (SaaS) and "the cloud", a huge amount of debate has already taken place. Tons of cost models are out there comparing the benefits of each, but sometimes it helps to look past the raw numbers. When an organization completely outsources EVERYTHING, they do so at the cost of developing internal capabilities to mirror the exact same services being rendered. This leads to vendor lock-in, and when an organization eventually decides to begin managing their processes internally they are essentially starting from ground-zero. If 4-5 years have gone by, they've likely had a large staff turnover. In addition, anything they owned internally may be severely dated, both from a technology and best/most efficient practices perspective. The end result is that a huge investment may be required in order to maintain the same level of capability on their own.

Looking at it from that angle completely changes the outlook on the overall dollar amount. While it may have been cheaper while things were good (no benefits to pay, 401k matching, etc), upon a messy breakup they end up investing roughly the same amount of money. So does that mean outsourcing is a terrible idea? Not at all. A certain level of external expertise is an absolute requirement. These services should be used in a way that compliments their existing capabilities rather than replaces them. The ability to maintain flexibility and freedom can often be cheaper, as well as a lot less of a headache.

And the debate rages on.......

-Jack

Commoditized Security Is Optional

2009-09-11T19:33:00.001-04:00

So after watching Bruce Schneier's hour long sales pitch for outsourcing all of your IT solutions, it really made me wonder what standards most companies are using nowadays to truly evaluate who they outsource to. Just because a company is large, "reputable", or acknowledged by Gartner does not mean that they can 1-cater to ALL of your needs or 2-offer you the strongest technical solution. In fact, in my opinion the larger a company gets the less likely it will be that their service offerings will be tailored upon to what you ACTUALLY NEED. While a company may excel in software development, or data center virtualization, it doesn't have any bearing as to whether or not they can provide solid web application security services. Similarly, if a company is well-known for their security services, it doesn't necessarily mean that they'll do well at IT help desk management.

Since security is obviously a highly lucrative field for many companies to pursue, naturally they've flooded the market with their services....everyone wants to make a buck. There are companies that "do everything", and there are companies that are highly specialized. Something each and every one of you with procurement power should ask yourselves is "Would I take my car to someone for repair that is well-known for fixing boats, or should I take my car to the guy that fixes cars (and more specifically, Toyota's)." The same concept applies here. One could argue in defense of the do-it-all types that their solutions may have a more "worldy" view of the security field vice looking at knowing a lot about a specific niche. The main argument against these do-it-all companies would be that as a result of their business model, the skills that their consultants bring to the table might be very diluted. Using web application security as an example, rather than knowing a ton about Javascript, Flash, and various server-side web technologies and frameworks, they know a little about each, in addition to knowing how to lock down routers, firewalls, operating systems, and spam filtering. So what you are essentially paying for in the end is just a little bit of what you need, and a lot of what you really don't need. This is the same concept as going to the store and buying a variety pack of underwear that comes in different sizes...so while all you needed was 3 pairs of large underwear, you are now the proud owner of small, medium, and extra-large underwear that you really don't need.

This isn't to say that all companies offering highly specialized services are perfect. In the end, you really need to do your homework on them, what they do, what they've done, and ultimately, what they plan to do for you. If they offer you an in-depth application assessment, but upon asking them what their "methodology" is, they say its a 4 step process: step 1- blindly run a scanner, step 2-validate scanner noise, step 3-send you a bill, step 4- repeat steps 1-3 again and again...then it may be time to evaluate another vendor. If you are using a SaaS vendor that says "we scan, don't really tweak our scanner, don't really look at the output, and we just hand you a report loaded with stuff", keep looking for the right vendor. Price is always important, but receiving top-notch services for that price is more important in my opinion. While the price of an in-depth assessment will differ greatly from what a SaaS provider offers, you should also understand the differences in levels of effort put forth. Both have their place in the overall security process (a discussion for a rainy day), but again do your homework!! Ask them what differentiates them from their competitors, aside from price and what their public relations people have branded them upon. If their proposals are made up of marketing fodder, generic contract speak that doesn't even remotely pertain to you, and an overall "solution" that seems like its a template with your name on it, this might be an indicator of what their services will be like. Ask them what they've done to improve the broader state of security, how they plan to address any complexities in your environment, or even better: ask to speak to the security person that will actually be performing the work, instead of a sales person who will tell you exactly what you want to hear. If the person who you'll ultimately be paying for can't answer questions that they weren't coached on or prepared for in advance, has no clue about your specific technology, and can't name at least 1 online resource they use to remain current with their respective field, it might be time to look elsewhere.

Getting back to the beginning of this post, while a lot of organizations may indeed be increasing their level of outsourcing over time I don't feel that they should simply "bow" to the larger companies that would love for nothing more than to push all of the smaller companies out of the market (or acquire them). What you get is what you pay for, and if you don't do your own due diligence prior to breaking the piggy bank, it may end up costing you a lot more than you realize. Outsourcing is here to stay, but companies that choose to drive innovation will avoid commoditization, no matter how badly Bruce Schneier wants you to believe it =)

-Jack

Up Next: More Blogging!!

2009-09-01T23:28:00.002-04:00

I'll be posting much more often in the coming weeks and months. For those of you that still haven't deleted me from your RSS feed lists, look for some web application security posts that'll hopefully be informative and inspire some healthy debates.

-Jack

My Response to a Dangerous Idea

2009-06-20T16:12:00.003-04:00

This post is in response to Jeremiah Grossman's latest entry titled "Legalize It (Hacking GOV and MIL websites)". Before reading the rest of my post, please read his first, which is here.

So to sum it up, such an initiative as the one he has described would be far from free, and I intend to explain my theory within the next few paragraphs.

One thing I'd like to state upfront is that I acknowledge similar activities are ongoing as we speak. I am not taking a naive and utopian view of how this stuff wouldn't happen regardless of whether or not it is legalized or encouraged. My underlying theme should be interpreted to be that opening this stuff up to the general public from legality and encouragement perspectives may not be the most cost-effective solution afterall, nor the safest, which I will tie up with recommendations for better solutions at the end of this post.

So why is this both a dangerous suggestion and an irresponsible one at best? First, Department of Defense systems aren't Paypal. They aren't intended to drive profits, but rather intended to support the needs of warfighters. It really all starts off with understanding the needs of the organizations in question, before making recommendations for what they need. Unlike Paypal, who can allocate as much funding as possible to tolerate increased loads being placed on their systems (downtime = lost revenue), many groups within the government survive on shoestring budgets, believe it or not. As someone who has been around the DoD for quite some time in his career, I can attest to the fact that legalizing such behavior would likely require many entities to upgrade their infrastructures to even come close to handling the likely volume of traffic that would be generated. Every script kiddie, and every researcher trying to make a name for himself, would be throwing tons and tons of traffic at targets that were never intended to handle such a considerable load. So rather than finding a few holes and smiling at the end of the day, you'll be denying legitimate and in many instances, critical applications, from being utilized for their original intent. An alternate solution to this would involve tons and tons of red-tape being placed around the initiatives in order to maintain some type of positive control, which in government terms = sucking the value out of the process. The very first time someone messes up by either testing during off-limit production hours, testing from an alternate source address that isn't registered, or DoS'ing a site, it'll be a real nightmare.

Secondly, consider what the ramifications would be for both legal and incident handling personnel. Imagine being an incident handler on an already undermanned team that was already overloaded with say X unique and credible leads to follow per day. Suddenly, you have X plus a million daily, with most of them being the result of loud and obnoxious traffic generated by automated tools. So should these groups simply say "ok, its legal...better not investigate this", or should they still do their jobs, which is to determine what may or may not be live and ongoing attacks, or what may or may not be pre-attack probing? Wouldn't this lead to attack identification efforts being increased exponentially? If this were to occur, what would be a definite side effect? INCREASED MANNING REQUIREMENTS!! The last time I checked, adding team members wasn't free.

Surely it isn't feasible to think that opening up and encouraging pentesting efforts by the general public would be without the risk of questionable entities going above and beyond the "engagement rules" set forth by the respective agencies. So instead of being able to state with confidence that any incidents that may occur are inherently true incidents, there would be a sudden blurring of what is real and what isn't. As if it wasn't already borderline impossible to keep up with pre-attack probing and actual attacks in the average security operations center (SOC), it would only get much worse. The result would not only increase the loads placed on incident handling groups, but also on legal personnel as well. Each case could have its own set of unique twists and turns based on the type of technology in use, and could quickly become very costly to pursue offenders.

There are some companies in this world that I'll agree that this type of open environment is well suited for. Twitter, Facebook, Google's myriad of online services....yes. These "big 3" are all in existence for the sole purpose of generating revenue. They are also very homogenous organizations in comparision to the government and DoD, which have very intricate reporting structures both within, and to external agencies as well. The "big 3" do not deter anyone from accessing them, and never will do so, because they are all profit-driven. Therefore, it wouldn't make sense to discourage this behavior. For government systems, it pretty much will never be the intent for the general public to have a want/need to access them. Public companies encouraging researchers and anyone else in between to test their applications, enable a collaborative community in doing so. It results in publicity, both good and bad. Publicity = garners interest. This is exactly what profit-driven companies want.

Government systems do not exist for these same reasons. The information contained within them is often classified or considered "sensitive","for official use", or "secret" and above for a reason. The collaborative communities putting forth research efforts and pentesting efforts should therefore come from within as well. Rather than opening pentesting and security initiatives up to the general public, it should be done in a controlled manner, such as paying for the talent to perform the work. In doing so, the work can be coordinated and optimized, so that testing is not detrimental to critical operations. My view is that if there is a considerable cost associated either way, it might as well be invested in a way that will ultimately lead to better processes being created internally, vice the same widespread dangerous coding and general lack of security that exists today. It doesn't make sense to spend a ton of money developing an application, only to place it online and then get knocked over 3 hours later by a script kiddie. The cleanup efforts are enormous, and the wasted time and resources in fixing bugs that should have been identified in development, is downright sinful. Bringing the true talent in, and paying for it, could prevent this stuff in the development lifecycle, as well as in pre-deployment testing. Repeatable processes lead to greater cost savings, as opposed to leaving it in the hands of the unknown and simply hoping for the best.

I do not disagree with Jeremiah's point that too few organizations within the government have the capability to perform rigorous testing on their applications. In fact, I praise him for making this point, and reiterating it many times through his blogging, Twittering, and press statements. It is certainly an issue that affects everyone, whether we realize it or not. You certainly don't have to be a warfighter to benefit from the increased security afforded to the ones keeping us safe day in, and day out.

-Jack

CacheSearch Firefox Add-on

2009-05-20T01:04:00.003-04:00

If you spend a lot of time analyzing content the web application you are testing allows to be cached within the browser, I'd highly recommend giving CacheSearch a try. Just type in something you hope ISN'T being cached (ie- credentials, account numbers, social security numbers, etc), and hit enter. This is a really efficient way to test for this class of vulnerabilities. You can find it here.

-Jack

Are Secret Questions Secretly a Good Idea? That's Probably the Only Secret!!

2009-05-15T03:00:00.002-04:00

Passwords aren't going away anytime soon, as much as we all wish they would. None of the global web single sign-on solutions seem to make any sense, and it isn't exactly cost-effective to issue smart cards and RSA tokens to the masses. So face it, for at least the foreseeable future, passwords are here to stay.

So here is the scenario: Users are forced to use extremely complex passwords (12-14 characters, alphanumeric + special characters, no dictionary words, etc)...and what happens? They can't remember their passwords. They continuously lock their accounts out (if account lockouts are actually in place). Solution: reset your password by answering a super secret question!!

While a user's password may have been something funky like vd8#720zS@&#!,9$, a secret question implementation can effectively result in their password being reduced to something as simple as "mom". Imagine that upon entering a valid username + the answer to the question "Who bakes your favorite pies?", you are greeted with either a full-blown login to the site, or a "change password" prompt? What we've done is taken a weak approach to securing access to our sites, and have found ways to make it even weaker by adding external functionality that can completely circumvent it.

I've read lots of stuff where users are advised to use complex answers rather than stuff that can be easily tied back to them. So, here is the million dollar question: if a user can't remember their complex passwords, what makes anyone think they'll remember a complex answer to a secret question?

The point to this rant is to get people to really think hard about how they've implemented the usage of secret questions within their web applications. If you lock accounts out after 3 failed login attempts, but don't do the same for invalid attempts at answering secret questions (and return an instant login when correctly guessing at an answer), then congrats, you've effectively negated your account lockout policy. You have put your users at risk, in exchange for something slightly more user-friendly.

-Jack

Horrible Forgotten Password/Secret Question Implementations

2009-03-21T23:12:00.002-04:00

I've really been giving this a lot of thought recently, and have a few tricks up my sleeves in the coming months. Although the idea of "secret questions" is flawed to begin with, the implementations themselves are even worse. Horror stories ranging from questions like "What is your favorite color?", to a lack of eventual lockouts resulting from brute-force guessing, to guessing an answer and being greeted with an instant "reset password" function.

I am extremely curious to hear some similar horror stories from those of you that read this blog from time to time. Please feel free to post your experiences with poor secret question implementations.

-Jack

"But you need to be an authenticated user to do that, so who cares?"

2009-01-22T21:41:00.002-05:00

How often do we all hear that line from developers (or a similar phrase) who either don't firmly grasp the vulnerabilities that exist within their applications, or from those who are simply too jaded to admit that their code actually contains dangerous bugs? The purpose of this post is to drive home the fact that gaining authorized access to an application doesn't necessarily have to stem from finding flaws in the authentication or session-handling mechanisms, but can be obtained through perfectly legal ways (sort of).

So what type of low-tech techniques can we use to gain initial access to an application with minimal work and without raising a single red flag? Even for a site that requires a valid PAID subscription? Here is a great technique....ready? PAY FOR A SUBSCRIPTION!! If it is a banking application, walk into a bank with $50 and open a checking account. If it is a porn site, pay for the damn porn!! Now you have access to all sorts of likely unprotected goodies.

Once you get inside of the application, what types of things may be easily discovered through passive and seemingly innocent means? Maybe the session stuff isn't as strong as it seemed at first glance. Perhaps the session tokens that are issued upon a successful login are 128-bits in length, yet follow a pattern that could only be discovered in a reasonable amount of time by having an actual authenticated session. Maybe the attacker determines that account lockouts aren't actually implemented, and that he has an unlimited amount of opportunities to slowly brute-force the passwords of other users. Or, what if he creates multiple accounts and observes that a certain pattern is followed when assigning usernames, even though the usernames themselves are reasonably complex? These clues would not have been readily available without a valid account, because the application was effective at returning uniform responses for invalid usernames, invalid passwords, and locked accounts....thus making attempts to enumerate accounts futile.

This simple recon performed with a legitimate account may have very well taken weeks or months (as well as thrown up a ton of red flags) to perform without the account. Armed with this new knowledge, this same attacker now has the ability to easily get himself access to a dozen or so accounts. He will use these accounts that do not trace back to him to bombard the soft, chewy center of the application with a ton of attacks...many of which will have a high likelihood at being successful because Mr. Hollywood Developer himself took for granted the fact that someone in this world was slightly more creative than he was.

Just food for thought......

-Jack

National Collegiate Cyber Defense Competition

2009-01-19T01:54:00.002-05:00

Just got home last night from the Mid-Atlantic Regional round of the CCDC. For those of you that haven't heard of it, check it out here. If you are ever invited to participate, I'd highly recommend it. It was certainly one of the more personally rewarding experiences I've had in quite some time. While many in the security field take things for granted or do this line of work solely to feed their families, the students were truly in awe of what was happening before their eyes as we pounded them for 8 hours.

Tim and the guys at White Wolf Security hosted the event, and my hat goes off to them for the awesome job they did with the event. The college students got a mega-dose of reality by seeing what skilled and seasoned attackers were capable of doing to their networks. It is one thing to learn security in an academic environment, but certainly a completely different ballgame in reality. It was a very humbling experience for them once shells were getting popped left and right, and services magically began either crashing or getting uninstalled =). Hopefully this experience sticks with them throughout their careers in the security field, as they will be light years ahead of many of their entry-level peers because of it.

Looking forward to attacking the other schools next week. Heading back up to Lancaster, PA with my buds Ken Johnson and Rob Fuller (aka Mubix) to cause even more chaos =) Hopefully this time around we get more sleep. Probably not likely though. We hijacked a conference room at the Marriott for the night and turned it into our very own geek kingdom.

-Jack

Security Predictions for 2009 (most of them suck..mine are better)

2008-12-15T18:23:00.000-05:00

Its that wonderful time of year again, when all of the big security industry pundits start throwing their predictions around for the upcoming year. Some of them really read like a fortune cookie. "You will find love and happiness in security and in life...and your lucky numbers are 4, 13, 18, 24, 37, and 52." And then some of them are just blatantly obvious, like the projected increase in iPhone malware hoopla that various SANS members discuss here.

What it really boils down to is that another year has gone by, and rather than focus on what has been fundamentally broken for ages, we are all yet again focused on the "new and cool" versus the "old and screwed." Most of the attention has shifted to Ajax-ified applications and the Web 2.0 world. Meanwhile, most companies still have broken web-facing Classic ASP and ColdFusion applications, begging to be destroyed by anyone with the balls to do it. The new stuff is so much cooler, sure. Ajax apps are much more fun and robust to mess with, sure. Finding innovative new ways to abuse Flash and the plethora of RIA technologies is really cool, sure. Performing a sanity check on that dusty old Classic ASP application, to ensure that your application written in 2001 (which you can't get budgeting approved to re-code and phase out) incorporates the best-practices of 2008/2009...not so cool?

With all of that said, here is my list of 3 predictions for the web application security industry in 2009. Enjoy!! =)

1). SQL Injection and Cross-Site Scripting will not go away.
All of the modern frameworks have made significant strides to make SQL Injection harder for developers without security exposure to screw up and introduce into their applications. There are tons of input validation libraries out there that claim to "cure" everything, including SQLi and XSS. Microsoft has even introduced LINQ to SQL in the 3.5 version of the .Net framework, which makes it even easier to write database code without knowing a damn thing about SQL. So how the hell does this stuff even exist within modern applications? The reason is because developers still don't understand security (yea, newsflash huh). Developers still live in a fantasy world where suppressing ODBC errors and using stored procedures makes them invincible (or at least the book from Microsoft Press told them so). Lots of developers still don't understand why browser input should not be trusted. Most of them have been spoon-fed the awful idea that because they have implemented rigorous client-side Javascript routines to validate and scrub any potentially dangerous input, that they should sleep well at night. If you believe that, then I also know a chick named Sarah who wants your vote in 2012!!

The lesson to be learned here is that unless we take a step back and look at the underlying problems first before jumping to add layers of complexity and obfuscation on top of them, we will still be talking about these issues in 2015. We can come up with new security frameworks and methodologies daily, and even get up on a soap box every morning to preach the virtues of using them..but in the end, if developers don't truly grasp the underlying concepts, then baking security into the development life cycle won't cure a damn thing.

2). Some new security appliance will be marketed as the Holy Grail.
Instant gratification is a wonderful thing, especially when it shuts your CIO up and also satisfies your compliance needs. However, it is a terrible thing when we begin to actually buy into the idea that we can fix a problem by throwing hundreds of thousands of dollars at it, all while not actually fixing the problem itself. So now the Mighty Pillars of PCI Compliance say something like "Thou shall blindly throw a WAF (Web Application Firewall) onto thy network and be free of glaring vulnerabilities...and liability."

I actually find this pretty disturbing, as most rational people should. So not only do we have applications filled with the same holes we've been seeing for years already, but now we throw another layer of complexity on top of it...without fixing the problem!! Does anyone else see an underlying theme forming here?

Needless to say, in 2009 we will see another "game changing" product marketed to the masses that won't do much aside from setting them back another couple hundred thousand dollars. And it'll make them salivate like dogs while they eagerly await the next big thing to arrive in 2010.....

3). This won't be the year people start to sweat the small stuff.
So even when we finally kick the dead horse of input validation so hard that developers start to listen (out of fear for how hard we can really kick), now we have a whole other world of tiny problems that nobody will even come close to caring about. Session tokens will still be set without the 'secure' flag, session identifiers will still be issued without salting them with source addresses and enforcing IP restrictions on their usage, etc. These are the little things that some feel are so low on the priority totem pole that they are a waste of time and resources to address. So, that one tiny little XSS within one of your authenticated forums....nevertheless certainly dangerous on its own, by neglecting to fix all of the little tidbits of proper session-handling, you've turned something bad into something much worse.

Little things definitely add up in the security world. Sadly, in this day and age of compliance, most companies are spending so much of their time and financial resources ensuring that they meet the absolute minimum requirements. So much in fact that they actually feel as though anything not deemed a medium or above risk by the respective compliance body that pimps them out, is more of a burden than a necessity.

-Jack

Proxying Burp through Tor and Privoxy

2008-09-19T19:05:00.000-04:00

Haven't seen any guides to do this, so I figured I'd write one. Note: These steps work on a Fedora box. If the files are in different places on other flavors, just figure out where they are, and it should be the same process. This guide also assumes that you have both Tor and Privoxy installed. If not, you can get Tor here, and Privoxy here.

So, setting it up....First, you need to configure your browser to point to Burp for outbound HTTP and HTTPS (8080 is the default port). Then, you need to set your SOCKS proxy to point to your Tor service running on 9050 by default.

The next step is to configure Privoxy to proxy all of its upstream requests to the Tor service running on 9050. In Fedora, the file is /etc/privoxy/config. Use nano (or pico, or whatever editor you want really), and hit control+w (in nano and pico) to bring up a search prompt. Search for "9050", and it should bring you to a commented out line containing:

Uncomment the line that forwards to the SOCKS service running on localhost at 9050.

After you configure Privoxy, you will need to configure Burp to point at Privoxy. Under the "comms" tab, scroll down a bit until you see the proxy settings option. Privoxy listens on 8118 by default, so you will use 127.0.0.1 for the host address, and 8118 as the port, as illustrated below:

The final step is to fire up the Tor and Privoxy services. To verify that you are being routed through the Tor network, visit www.whatismyip.com. If you did everything right, your web requests should not reflect your source IP when you access the server.

Enjoy =) If you can't get it working, post your comments or issues and I'll walk you through it.

-Jack