Still think allowing users to upload files to your server is OK?

There has been quite a bit of buzz surrounding the newest Flash attack. Please review this site for a quick write-up. I want to make it clear this attack vector is different than a remote vulnerability in Flash. This attack is focused on an individual uploading a flash file to a server and then having it execute when a user visits the site.

Adobe has a nice write-up out lining the issue and their initial response to the problem here. I really like the write-up and the quote of a core axiom of computer security: "If you allow a bad guy to upload programs to your web site, it's not your web site anymore." That is very true.

However, in the article they re-state that the issue at hand is the Same Origin Policy issue. Mike Bailey of Foreground Security neatly breaks down where the Adobe response fails to completely address the issue here.

The point he makes is Adobe draws similarities between Javascript and SWF files. He shows that this comparison has some very interesting limitations. First, simply uploading a .js file to a webserver does not mean the file can be executed. However, if someone were to upload a .swf file to the server it can be executed within the context of the server. Now… Here is where it gets interesting, if a user loads a .swf file to a server and changes the extension, it can still execute within the context of the server. Who thought this was a good idea?

His point is that the scenarios where .swf files can be executed is far more pervasive then the .js counterparts that Adobe discusses.

The reason this fascinates me is that it is outside the bounds of what penetration testers would normally look for in a web application. Because this attack vector is not a remote exploit, it does not get the buzz that it deserves. The point is that when we are testing we need to look for vulnerabilities and attacks that attackers would use. This attack vector is definitely in that category. Further, this is not something that is easily fixed with a patch.

There are two things we need to take from this. First, file upload attacks have to be in your arsenal. Second, from the defensive side, Adobe is right. As much as I would like disagree with the technical aspects of their response to this vulnerability, they are correct. If you design your web infrastructure to allow file uploads and for those uploads to be executed, there are going to be serious security ramifications. What would be the alternative? Flash could try fix their plugin to at least validate file extensions before executing, or possibly require the content-type headers in the HTML (not in the file) before executing the flash, thus bringing it more in line with the analogy with Javascript they discussed in their write-up.

Until they do (and I don't expect this to happen any time soon) we will have a new vector to test for in our engagements.

-strandjs

John Strand will be teaching SANS Network Penetration Testing in
London from 11/30 to 12/6 2009, and SANS hacker techniques and Incident Response in New Orleans from 01/10/10 till 01/18/10.

We've been asked a number of times for advice on RFID equipment that can be used to start experimenting with RFID technologies. We've heard your request loud and clear; I'm going to give you a rundown of what is in my current kit.

Start at the Beginning

The first reader that I picked up was the PhidgetRFID board.

It was inexpensive, included all the bits and pieces I needed for interfacing (USB built in) along with some sample applications and open community. It reads uniqely numbered EN4x02 series tag quite well. This reader is read only, and operates in the 125 kHz spectrum.

Moving On Up

Shortly there after I realized that I wanted to write tags. Of course I was familiar with the RFIDIOt project and I wanted a writer that would work with that particular code. I picked up an ACG reader with USB interface from Major Malfunction (the author of RFIDIOt) in order to help support the project.

It was expensive and it needed to be imported to me from the UK but I couldn't find an equivalent reader elsewhere that could come close to the cost. I picked up the ACG LF USB reader, which works like a champ reading and writing to all manners of tags. If I had to do it again, I'd upgrade to the ACG LAHF USB which wasn't available at the time. While I was there, I also picked up the ultra cheap USB Keyboard Wedge Verification LF Reader just for fun.

Unfortunatley the next project that I wanted to purse involved the reading of ISO 14443A/B tags, which wasn't supported by my ACG reader (the upgraded model does, hence my recommendation for the upgrade). In order to support the reading of ISO 14443A/B tags, I picked up the Omnikey Cardman 5321, which also has a smart card reader as well.

Ooh, two hacking tools in one! I did acquire this reader much cheaper here in the US. The supplier no longer has them available but there are several that are Google-able. In typical fashion I wanted to be able to read ISO 14443A/B tags in order to read PayPass RFID tags which I found out isn't supported by RFIDIOt...yet. A chat with Major Malfunction at Defcon revealed that he is close to being able to support the PayPass chips.

Going Standalone

I was also fortunate to be able to acquire some Parallax modules form the Defcon Wireless village RFID scavenger hunt a few years ago. Thorn put them together in a kit to build a standalone EN4X02 reader with serial LCD display.

It worked great, but I've got some new plans for the modules, such as integrating them with an Arduino and a few extra goodies for good measure.

The Latest Goods

A few weeks ago I picked up a VivoPay Paypass 3000 reader off of ebay for a few dollars (under $10).

It was "tested and working" and it does appear to be that way. Unfortunatley I need to construct a serial adapter for it and my tools seem to be missing. I have some headed my way this after noon, so this is an ongoing project.

The neat option with this reader is the PayPass support. It will read the card and handle all of the over the air encryption. The module handles all of the decryption, and hands off the clear text of the tag voa serial; this is the paort that would be handed to the Point of Sale System. Bonus, let's use the intended purpose of the hardware do the crypto for us, and interface with 3ric's pwnpass script. Stay tuned for more goodies with this one.

[Update: During the writing of this post, I was successful in building the serial adapter and testing it with the tools from VIVOtech, as well as the pwnpass script. However, I think that this reader has an old version of firmware that cannot understand the commands issued to it. I have to call VIVOtech to get ahold of the latest firmware, which I'm told is fairly easy to do.]

You'll note that I don't have any inventory of active RFID equipment; all of my gear is passive. I haven't had any experience with any active gear, and for me, the cost is more prohibitive.

Right now, that's what I've got in my kit and I've found I can read just about any type of tag that I can encounter, from passports to physical security cards. Some are a work in progress, but they are just a matter of time. Scan away! Also, I'm more than willing to let you scan my RFID implant in person should we meet.

Larry "haxorthematrix" Pesce

All:

For your listening pleasure I have (finally!) edited the podcaster meetup audio. You can hear the likes of:

• PaulDotCom Security Weekly
• Security Justice
• Exotic Liability
• Securabit
• The Network Security Podcast
• SMB Minute
• GRM N00bs

At this meetup we took questions from the audience, performed strip teases, and did some general ranting.

Special guest appearance by none other than Twitchy!

Direct Audio Download

Audio Feeds:

PaulDotCom will be running a Hacklab in Boston at SANS Boston 2009 hosted by strandjs this Friday August 7th from 6:00PM till ???. "Hack Naked" T-shirts will be on sale for $10!

We will be at the:

Hyatt Regency Boston
One Avenue de Lafayette
Boston, Massachusetts, USA 02111
Telephone: 617 912 1234
Fax: 617 451 2198

The even will take place on the fourth floor. This event is open to the public, so come on down and hack some systems. Better yet, bring some cool systems to hack.

That and it is kind of my birthday.

-strandjs

PaulDotCom will be running a live Hacklab event from
SANS Denver this Sunday (07/12) from 6:30 till ??? @:

Grand Hyatt Downtown Denver
Second floor conference center
Longs Peak room.

There will be a network and systems for people to attack. We may even
throw in a cool presentation or two.

Come on down and check it out.

-strandjs

At least for just a second or two.

There is a problem that I have been fighting with. Lately many security testers are becoming like the TSA... Trained to look for very specific things.

For example, TSA agents appear to be focused on looking for things like scissors, containers with the ability to hold more then 3 to 3.4 ounces of fluid. Rather then looking for threats we are focusing our TSA to look for specific things.

And that is the problem with many penetration tests today, they are looking for specific things. Many of us are reducing our craft to the search for XSS, XSRF and SQLi vulnerabilities (just to name a few). However, I would say that a test that looks for only those types of vulnerabilities is sub-par at best.

Here is why. We need to be looking at how the application and the network functions. We need to understand how it is transferring data from the back end to the web front-end. We need to try to understand how the data is being segmented and protected. All of this requires us to try and understand how the application works. Trying to understand how something worked used to be the goal and definition of hacking.

Do you see the difference in perspective? If you are hunting for missing patches and other vulnerabilities you will find them, but you are missing out on the bigger (and probably more important) picture.

This goal with looking for specific vulnerabilities is weakening our profession in two ways. First, it is locking us into very small and well defined roles. Unfortunately, this type of mindset is driving many of the audit standards that help us get work. Audit standard X says we should look for Y vulnerability, so that is what we look for. Second, and somewhat related, there are a number of outstanding tools that are automating that process. If at any point in your career the opportunity exists to replace you with a tool your employer/customer will do it.

If we continue to allow this to happen the modern penetration tester will quickly become a thing of the past. We will have been replaced by a number of tools that look for the same defined sets of vulnerabilities.

The reason I am writing this is the past couple of tests I have been on the tools have turned up squat. In-fact a couple of the customers use the exact same tools I use on a regular basis. However, I have been able to find fairly major holes in their applications or network architectures without tools. I just start messing around with different applicants and accounts. To be honest, this approach is where I started. I strongly believe that this is where a good number of you started as well. We probably do our best work this way.

Automation and tools are great. I love all of the wonderful tools I have on my computers. But they are not sufficient to do a penetration test. If they are, we are all in big trouble. Run the tools, automate and print reports.

However, when the tools are done running. It is time to get back to basics. Consider a new definition of "Hack Naked", put all of your tools away and just use what you have at your disposal. A browser, a OS and a couple of test accounts are all you need.

-strandjs

One of the most asked questions we have gotten since we started PaulDotCom is: "How do I get started in information security?". This is a great question, and the following guide will get you started:

1. Be curious - The first and most important characteristic you need to succeed in information security is curiosity. I have to say that I started by being curious. I was 7 years old and I took a class on how to use an Apple IIe computer (back then you had to write programs to make the computer do anything). I remember sitting in front of the Apple IIe (my parents eventually bought one) and staring at the glowing screen and the green flashing cursor, just wondering what I could make it do. I watched the movie "War Games" and wanted a modem so bad, but my parents forbid it, saying that I would cause global thermo-nuclear war (I told them I only wanted to play chess, but they didn't believe me). I guess that's part of your homework, go back and watch two of the best hacker movies on the planet, "War Games" and "Sneakers".
2. Work in information technology - Most people I encounter who want to get into information security want to know, "How do I become a hacker?". I don't think its something that you become, I think its something that you are, coupled with something that you are shaped into. The best information security professionals are those that have been "In The Trenches", working as a help desk technician, systems administrator, or network engineer. Working in these positions will gain you an understanding of how things work, which lays the foundation to learn how to break them and make them do things they were not intended to do.
3. Setup a home network/lab - First, setup a home lab. VMware makes free versions of their software, and there are thousands of pre-configured virtual hosts available on their web site. Don't just focus on setting up security tools either, try to setup a file server using Samba and lock it down (for example). This exercise can provide valuable experience. For example, I was on an interview once for one of my first UNIX systems administrator jobs and they asked me if I had experience with NFS. I said, "Sure do! I run it at home." They looked puzzled at first, but when I could answer all their technical questions about NFS, they, well, hired me. I also brought pictures of my computers at home to the interview. Now, I don't recommend that, but its one of those funny interview stories and it happened to work for me. However, it could have very easily had the opposite effect.

Actual picture Paul brought to his interview
4. Get involved with local groups - This is a great place to meet people in the field, exchange ideas, and ask questions. Its important to network as this is most likely how you will get a job in the field! Local groups in my area, for example, include 2600, defcon (DC401), Linux user groups, and several others. Also, there may be a "Hacker Space" in your area as well, so be certain to find one and participate in it. If there is no group of any kind in your area, then create one!
5. Go to conferences - Defcon is one of the larget conferences on the West Coast, and Shmoocon is a popular conference on the East Coast. This is another great place to network and there are several smaller conferences all across the country (such as NOTACON). SANS is a great place to learn and network, but most starting out in the field may not have an employer who will pay for training. There are many options, such as SANS @home online training or becoming a facilitator for SANS.
6. Read blogs & listen to podcasts/webcasts - There is so much information on the web about our field that it is overwhelming. While you may specialize on certain systems or technologies, you need to have some level of understanding in all areas on technology. Keeping up with all this can be a full-time job in and of itself. My suggestion is to use an RSS news reader and subscribe to as many technology and security related resources as possible. Need some help getting started? You can download all the feeds from here and import them into your RSS news reader. Podcasts are free, and iPods are very cheap now, so you should be listening to podcasts. Of course we produce our own weekly show called PaulDotCom Security Weekly, and this thread in our forum discusses many of the other great podcasts on the net. Webcasts are free ways to get good information, and are available from SANS, Whitehat World, and many others.

Hacking Naked Helps Too
7. Take training classes and get certification - We've talked about SANS already, and there are several other places to get great training. Backtrack is a great security live CD distribution (also a great place to start for beginners) and its associated training classes have gotten great reviews. Don't shy from certification, but don't spend too much time getting certifications to pad the resume. Strike a balance - get a few certifications and see where it takes you, then spend some time and resources getting real-world experience. Get involved with an open-source project - even if you may not feel like you have the technical chops to participate in many open source projects. That's okay, if you are good at writing documentation and/or testing, you can be a valuable resource. This tack gets you familiar with the technology and gets you networked in the field.
8. Socially Network - Not only are social networks fun to hack, but they are one of the best ways to network in the field. Twitter has become a great tool for this, and even has the "Security Twits" group consisting of security people using Twitter. They have meetups at various conferences. Facebook and LinkedIN can also be valuable networking tools to help you meet people and find a job.
9. Write about stuff - A great addition to your resume are publications. Find a topic that you like and write something on it and submit it to various magazines and online resources to get published. This is looked upon favorably by employers, and gives them writing samples as well. Also, have a blog. Blog about stuff that you do, what you think about security, etc... If you keep it focused on security, you'll be in good shape. If you start blogging about farm animals and creamed corn, it may not be as useful. For examples of some of the things we have written, you can check out the papers page. For examples of presentations, see the presentations page.
10. Manage a machine that gets hacked - I know this sounds strange, but many people we interview say they got their start when their machine got hacked. This is not to say that you would let a machine get hacked (be careful if you plan to do this and setup honeypots/honeynets), but this can provide valuable experience and further motivate you to explore the field of information security.

I want to thank the members of the PaulDotCom mailing list for sharing their ideas and thoughts on this subject. You can read the full thread in the archives that inspired this post.

Paul Asadoorian
PaulDotCom

Here at PaulDotCom Security Weekly we have this thing for wireless of all kinds. Wireless cards, cables, antennas, 802.11, RFID...the list goes on. We're always on the lookout for something neat and useful. We found that in the Asus EEE line of netbooks. They are small, usually feature Atheros wireless cards, and have a huge modding community. The small form factor is also something that works well for wireless assessments, whether covert or sanctioned. The size is conducive to easy transport in a small space or as a second laptop while traveling.

To those aims, the Asus 4G Surf (amongst others in the EEE family) works well, however the small internal wireless antennas don't offer much flexibility or range. We need to take some cues from the EEE modding community and extend the hardware to support a better antenna. So, here's how to add an external RP-TNC antenna connector to the Asus EEE 4G Surf.

Tools and parts you will need:

A small Phillips screwdriver

Electrical tape

A drill and appropriately sized drill bits

A flat instrument for gently prying the case apart (such as a plastic putty knife or a fingernail)

A u.FL to RP-TNC pigtail (about 6 inches works well)

First, we need to get this little machine open. To do that we need to remove the memory door cover on the underside by removing two small Philips screws.

Then we need remove the rest of the screws on the underside of the case. While we are there, remove the battery and set it aside.

Once removed, we need to remove the keyboard to access the screws underneath. To do this, loft the rear of the keyboard and push in the 3 small retaining tabs (near the screen). The keyboard should lift up from the rear allowing you to carefully disconnect the ribbon cable in the front.

Removing the keyboard will reveal several screws on the metal plate underneath the keyboard.

Separate the top section of the case from the bottom; start at the bottom right and work your way around to the screen and down the left hand side. Once you reach the left hand side, rotate the top of the case slightly in a counter clockwise direction in order for the case to make it past the ethernet and sound ports.

Once the top has been separated, remove the main board from the case to access the underside of the board and wireless card. Next, remove the several small cables to separate it from the case.

Last but not least, remove the microphone from the case. It should pop out easily and stay attached to the board.

All that is left holding the board hostage in the case are three small clips at the front edge of the laptop. Pushing the tabs aside with your finger will liberate the board.

In order round the corner on our hack, we will also need to separate the display from the base. This will allow for safety while drilling the hole for the RP-TNC connector and allow us to wedge it all back together. The display can be removed by removing one screw from the outer edge of each hinge and then it should lift straight out.

I found an interesting place for the RP-TNC connector. At the right hand edge of the laptop, what appears to be the "hinge", there is a small silver disc. This disc is just a sticker; peel it off and we are left with a spot that looks as if it was made for the connector. I used my handy drill press in the workshop to create an appropriate hole where the sticker used to be (I believe that it was 5/16ths of an inch). This could certainly be accomplished with a hand drill as well.

Due to the cramped quarters in this section of the case, I had to route the pigtail connector for the external RP-TNC connector through the right hand display hinge. Fortunately, this is also how cables are passed into the display form the main compartment.

At this point we can start the reassembly process. I found that it was easiest to attach the RP-SMA external connector to the case first, and then reinstall the display.

The final step before reassembly is to attach the u.FL end of our pigtail to the wireless card. I elected to leave one of the internal antennas attached, and placed a small piece of electrical tape over the other, and disconnected internal antenna connector. We don't want this nice conductive connector inside of the case causing a short!

In order to complete the reassembly (just follow the disassembly steps in reverse, yes it is that easy), we need to modify the top half of the case in order to accommodate the internal parts of the RP-TNC connector. On the underside of the hinge cover, we need to remove a small bit of plastic. I did this with my Dremel and a small grinding stone.

Reassemble, and we are done! Attach an appropriate RP-SMA antenna of your choice and begin your assessments, now with more power!

As a bit of an update, I quickly discovered that the location of the external connector was just a bit too tight. It pushed out the side of the case a little bit and as a result, compromised the connection on the inside of the connector. This quickly failed.

I added some additional space to the outside of the case with a new connector, utilizing the same location. I added a spare dome shaped piece, with an extra large hole drilled on the inside to accommodate the flange on the external connector. Fasten the connector to the dome, and a little two part epoxy later and we have a solid connector with plenty of room. Here's a look at the final result:

Now, any idea where the dome shaped piece came from? Glad you asked! It was a plastic foot that was supposed to be affixed to the bottom of some piece of furniture. It met with all sorts of power tools in the workshop for holes, trimming and finishing. Now, what to use the three other feet on...?

Enjoy! Let us know how your hacks turn out.

- L

Resources

EEE 4G Surf from Asus: http://eeepc.asus.com/global/product700-spec.html

EEE User Forums: http://forum.eeeuser.com/

FAB Corp u.FL to RP-TNC Pigtail http://www.fab-corp.com/product.php?productid=2680

One of the questions that we get on a regular basis is "Are there any good tools for SQL Injection?"

There are a number of great tools that do this commercially like Core Impact and Cenzic Hailstorm. However, many tools will simply alert you that a SQL Injection vulnerability exists then leave it at that.

We are penetration testers so proof is kind of important. Simply stating that you found a SQL injection vulnerability because your tool said so is not enough.

To that end, I would like to introduce you to sqlmap.

First up, I would like to say thanks to the developers Bernardo Damele A. G. and Daniele Bellucci.

Now I would like to show you a short video of the tool.

Why does this tool rock?

Glad you asked.

First, it has the ability to process results from burpsuite and webscarab with the -l option:

Like..

# ./sqlmap.py -l /tmp/webscarab.log/conversations/

It also has the ability automatically dump data. For example it can dump the database version and the tables in the database.

To do this you would use the --dump-all switch like:

# ./sqlmap.py --dump-all -u "testurl.com"

Next, it has the ability to use googledork search strings. Yep, thats right googledorking and SQL Injection... Honestly, does it get any better?

# ./sqlmap.py --dump-all -g "site:testsite.com ext:php"

The above command will have google crawl a website and pull all pages with a php extension. After sqlmap has a nice list of targets it tries to attack them.

Finally, and in my humble opinion most importantly, it can get you a SQL shell.

To do this use the --sql-shell option and it will try to give you a shell.

# ./sqlmap.py --sql-shell -g "site:testsite.com ext:php"

Very nice!!!

Once again, I want to drive home the importance of proof. Our jobs as testers is to demonstrate risk. To do that we need to act like a threat and interact with a vulnerability. Simply stating that a tool said there is a vulnerability is not enough. Also, we should be after what the attackers are after.... Data! What better place to get data then a SQL database?

strandjs

We have been promising for a few week a write-up on SSLStrip and now we have finished it!!!!

SSLStrip from John Strand on Vimeo.

SSLStrip basically strips the SSL session between the attacker and the victim. This allows the attacker (or tester) to see all of the data that is being sent to the user in clear text. As far as the server is concerned it is a valid encrypted session. There are a few interesting things going on with this attack. First from a pen-test perspective it only articulates even more how dangerous man in the middle attacks are when leveraged correctly. Funny thing about that... arp cache poisoning is just as effective as it was 5 years ago. It is getting clearer and clearer to me that if an attacker gets access to an internal network it is pretty close to being over. So if you are doing pen-testing and you don't Man in the Middle... Get on board and start doing it. Now for the second issue. User training. We tell our users that they need to be careful to not click on links for strangers and be carefull what websites they should not go to, but we rarely demonstrate that risk. Why do organizations do pen-tests? The do it to demonstrate risk. Otherwise they tend to do nothing. Is there any reason why we would expect anything less from our users? The reason I bring this up is that when we do user education we really need to be doing some live demonstrations. For example, we need to demonstrate a browser being compromised. We can also use tools like SSLStrip to demonstrate why that HTTPS is so important. We can also use tools like Web Monkey in the Middle from Dsniff to demonstrate why those certificate pop-ups are kind of important. I know I am tilting at windmills with user education. Just a hopeless romantic I guess. strandjs