http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2011-09-06 05:14:46 - Jack Mannino : 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 wwwhuffingtonpostcom 2011 08 28 half-america-obese-2030_n_937906html 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 50pourcents 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 wwwmeetupcom 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 needsmuch more than new certifications and acronyms next to our names -Jack http://www.secuobs.com/revue/news/327187.shtmlhttp://www.secuobs.com/revue/news/327187.shtml Secuobs.com : 2011-02-04 13:35:50 - Jack Mannino - 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 http://www.secuobs.com/revue/news/282969.shtmlhttp://www.secuobs.com/revue/news/282969.shtml Secuobs.com : 2011-02-02 05:13:19 - Jack Mannino - 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 FloatvalueOf amountInputgetText 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 cardHolderNameInputgetText toString final String accountNumber cardNumberInputgetText toString final String expiryMonth expirationMonthInputgetText toString final String expiryYear expirationYearInputgetText toString And below, we append this to our request and send requestappend requestappend requestappend companyId requestappend requestappend requestappend companyPassword requestappend requestappend 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 http://www.secuobs.com/revue/news/282335.shtmlhttp://www.secuobs.com/revue/news/282335.shtml Secuobs.com : 2010-11-08 05:56:07 - Jack Mannino - 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 developerandroidcom guide topics security securityhtml 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 javalangRuntime to do this public bool isRoot View v try Runtime cmd RuntimegetRuntime cmdexec su CharSequence result You are root Context context getApplicationContext Toast toast ToastmakeText context, result, 10 toastshow return true catch Throwable t CharSequence result You are not root Context context getApplicationContext Toast toast ToastmakeText context, result, 10 toastshow 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 platformxml file as well As root, you have the ability to read and write to both of these files You can edit platformxml 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 - http://www.secuobs.com/revue/news/263128.shtmlhttp://www.secuobs.com/revue/news/263128.shtml Secuobs.com : 2010-10-13 14:55:12 - Jack Mannino - The purpose of this post isn't to show off anything overly complex it isn't hard , nor is it to spread fear and uncertainty The goal of this post is to spread awareness regarding just how weak the current crop of mobile security applications are Armed with only a moderate skill level and the ability to follow this tutorial, it is possible to make mobile security applications completely irrelevant I decided to give a few Android mobile security applications a try over the weekend I was especially curious to see how difficult it would be to circumvent them to gain access to a locked down mobile device The results were certainly less than impressive While I dabbled with several applications, I'm only going to demo how to defeat McAfee's WaveSecure You can use the same methodology for pretty much all of them though There are a few components to the WaveSecure suite The main application can be used to locate a device via GPS, remotely wipe the device, alert the device's owner or friends when a SIM card is changed, and to lock down the device WaveSecure Uninstall Protection can be installed as a backup security solution in the event the main application is uninstalled by a thief If the main application is uninstalled, the uninstall protection should kick in to lock the device to prevent unauthorized access Assuming the user locked the device using WaveSecure as opposed to the built-in screen lock capability, it's ridiculously easy to completely bypass this protection It can be done in way under a minute actually The first step a smart criminal would take after stealing or finding a device would be immediately switch the phone into Airplane Mode By doing this, you completely take away the user's ability to remotely wipe the device No communication no ability to send commands to the device This capability is available even if a device is locked The next step would be to plug the device into a computer and fire up ADB Even with a locked phone, ADB can be used for shell access Starting ADB as root allows us to access and modify the data app directory, which is where applications are installed by default SD card otherwise Let's blow away the main WaveSecure application Jack Android_Fun adb root daemon not running starting it now on port 5037 daemon started successfully adbd is already running as root Jack Android_Fun adb shell cd data app ls comwsandroiduninstall_listenerapk comwsandroidapk rm comwsandroidapk When we remove the main application, the uninstall protection kicks in and notifies us that the application was removed Still no access The next step is just as easy, remove the WaveSecure Uninstall Protection application rm comwsandroiduninstall_listenerapk At this point, any and all protection provided by WaveSecure has been completely taken away Enjoy your new phone Added bonus if the user didn't set an additional password or security pattern Conclusions 1 Don't put much faith in the protection these applications claim to provide 2 Don't take your eyes off of your phone if I'm around -Jack http://www.secuobs.com/revue/news/256556.shtmlhttp://www.secuobs.com/revue/news/256556.shtml Secuobs.com : 2010-10-05 23:01:32 - Jack Mannino - 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 comevernote Jack Android_Fun adb shell cd data data comevernote 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 comwhateverapp directory The file comevernote_preferencesxml is where application-specific information is stored for Evernote Outputting the contents of this file gives us the following cd shared_prefs ls comevernote_preferencesxml cat comevernote_preferencesxml happy_gilmore MyPassword123 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 comevernote ls cache databases shared_prefs lib cd databases ls Evernotedb webviewCachedb webviewdb sqlite3 Evernotedb SQLite version 3622 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-2dcbf5bc1bc2d7aede0e-ec5d-4ab8-8670-5070d5c0a35eMy Banking Information2891 j 4 s1286304619000128630482500001415000 8ea7f9c7-30b0-4112-98d3-4d78b81e79d5d7aede0e-ec5d-4ab8-8670-5070d5c0a35eMy Personal Information321 A FdJ1286305164000128630516400001715001 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 http://www.secuobs.com/revue/news/254511.shtmlhttp://www.secuobs.com/revue/news/254511.shtml Secuobs.com : 2010-09-29 03:14:25 - Jack Mannino - 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 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 AndroidManifestxml 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 AndroidManifestxml file should look like when viewed in a text editor or Eclipse The classesdex 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 dex2jarbat path_to_classesdex Once we've run dex2jar, there will be a classesdexdex2jarjar 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 http://www.secuobs.com/revue/news/252634.shtmlhttp://www.secuobs.com/revue/news/252634.shtml Secuobs.com : 2010-06-18 18:44:08 - Jack Mannino - June 18, 2010the day Jack Mannino coined the phrase Gregrolling It took a long time, but finally someone more ridiculous than Rick Astley came along That man's name is Gregory Evans Gregrolling is simple There are 3 easy steps Step 1 Send your friends shortened links to this video on YouTube Number 1 Hacker Step 2 Wait for friend to get angry Step 3 Laugh -Jack http://www.secuobs.com/revue/news/232932.shtmlhttp://www.secuobs.com/revue/news/232932.shtml Secuobs.com : 2010-05-14 20:49:55 - Jack Mannino - 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 http://www.secuobs.com/revue/news/222285.shtmlhttp://www.secuobs.com/revue/news/222285.shtml Secuobs.com : 2010-04-01 21:22:23 - Jack Mannino - 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 http://www.secuobs.com/revue/news/208110.shtmlhttp://www.secuobs.com/revue/news/208110.shtml Secuobs.com : 2010-03-10 02:48:50 - Jack Mannino - http ec2-184-73-72-87compute-1amazonawscom testhtml http://www.secuobs.com/revue/news/200081.shtmlhttp://www.secuobs.com/revue/news/200081.shtml Secuobs.com : 2010-03-09 01:46:57 - Jack Mannino - 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 jack-manninoblogspotcomtinyurlcom ygkqxnd 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 http://www.secuobs.com/revue/news/199569.shtmlhttp://www.secuobs.com/revue/news/199569.shtml Secuobs.com : 2010-03-01 04:47:34 - Jack Mannino - 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 http://www.secuobs.com/revue/news/196481.shtmlhttp://www.secuobs.com/revue/news/196481.shtml Secuobs.com : 2010-02-26 02:01:20 - Jack Mannino - Before I begin my rant, a quick history lesson In the earlier part of the decade, Microsoft released a new web framework called ASPNET 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 ASPNET 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 http://www.secuobs.com/revue/news/195772.shtmlhttp://www.secuobs.com/revue/news/195772.shtml Secuobs.com : 2010-02-17 08:15:00 - Jack Mannino - 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 http://www.secuobs.com/revue/news/192648.shtmlhttp://www.secuobs.com/revue/news/192648.shtml Secuobs.com : 2010-02-11 02:01:59 - Jack Mannino - 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, ssnztxt 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 http://www.secuobs.com/revue/news/190738.shtmlhttp://www.secuobs.com/revue/news/190738.shtml Secuobs.com : 2010-01-19 08:56:02 - Jack Mannino - 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 bickeringeven 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 http://www.secuobs.com/revue/news/183032.shtmlhttp://www.secuobs.com/revue/news/183032.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 upFirst, 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 127001 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 wwwwhatismyipcom 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 http://www.secuobs.com/revue/news/182918.shtmlhttp://www.secuobs.com/revue/news/182918.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 lifeand 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 20 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 2009not 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 35 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 thembut 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 vulnerabilitiesand 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 itwithout 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 forumsnevertheless 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 http://www.secuobs.com/revue/news/182917.shtmlhttp://www.secuobs.com/revue/news/182917.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182916.shtmlhttp://www.secuobs.com/revue/news/182916.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 techniqueready 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 accountsthus 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 attacksmany 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 http://www.secuobs.com/revue/news/182915.shtmlhttp://www.secuobs.com/revue/news/182915.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182914.shtmlhttp://www.secuobs.com/revue/news/182914.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182913.shtmlhttp://www.secuobs.com/revue/news/182913.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182912.shtmlhttp://www.secuobs.com/revue/news/182912.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 legalbetter 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 servicesyes 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 http://www.secuobs.com/revue/news/182911.shtmlhttp://www.secuobs.com/revue/news/182911.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182910.shtmlhttp://www.secuobs.com/revue/news/182910.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 serviceseveryone 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 sizesso 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 againthen 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 http://www.secuobs.com/revue/news/182909.shtmlhttp://www.secuobs.com/revue/news/182909.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182908.shtmlhttp://www.secuobs.com/revue/news/182908.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - So this one is pretty interesting, and happens in a lot more instances than I originally thought it would The public crossdomainxml 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 crossdomainxml, 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 10xxx 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 comemight have shifted my submission for Shmoo to this area Lots of fun stuff to explore -Jack http://www.secuobs.com/revue/news/182907.shtmlhttp://www.secuobs.com/revue/news/182907.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 Manninostop 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 http://www.secuobs.com/revue/news/182906.shtmlhttp://www.secuobs.com/revue/news/182906.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 bitly, 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 zima, I took a TinyURL link and shortened it via zima Then, I took the zima URL and shortened it via TinyURL I did this twice, TinyURL to zima, then zima to TinyURL and finally TinyURL to zima 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 zima 8ac792 http://www.secuobs.com/revue/news/182905.shtmlhttp://www.secuobs.com/revue/news/182905.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 http://www.secuobs.com/revue/news/182904.shtmlhttp://www.secuobs.com/revue/news/182904.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 lieif 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 http://www.secuobs.com/revue/news/182903.shtmlhttp://www.secuobs.com/revue/news/182903.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - Update 1 7 2010 The site is undergoing a facelift, and should be back up within the next few days 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 http://www.secuobs.com/revue/news/182902.shtmlhttp://www.secuobs.com/revue/news/182902.shtml Secuobs.com : 2010-01-18 23:25:56 - Jack Mannino - 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 Bwhen 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 tagsguess 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 tonightdoesn't happen often -Jack http://www.secuobs.com/revue/news/182901.shtmlhttp://www.secuobs.com/revue/news/182901.shtml