My Security Planet » Tags

21 items tagged "Hacking"

tssci security

Virtual appliances for the security professional

Posted: March 18th, 2009, 6:35pm CDT by dre

Tags: Hacking [edit]
Virtual Infrastructure Security Facts
- The number of virtual servers will rise to more than 1.7 million physical servers by 2010, resulting in 7.9 million logical servers. Virtualized servers will represent 14.6% of all physical servers in 2010 compared to just 4.5% in 2005 (IDC)
- 60% of production virtual machines will be less secure than their physical counterparts through to 2009 (Gartner)
- More than 75% of respondents cited reducing infrastructure hardware and software costs as the critical driver in data center planning (Ziff Davis)
- Overall virtualization market has grown from approximately $560 million in 2005 to a forecasted $2.7 billion in 2009 (IDC)
- 10% of servers will be virtual by 2009, 60% by 2013 (Gartner)
- Fewer than 10% of organizations are doing anything special for virtualization security (Ziff Davis)
Virtual Appliances (VAs) have several advantages over Live CD distributions. They are easier to enable persistence and customize (especially for real performance in a VM, instead of via a bootable ISO). It’s easier to take snapshots that represent a “point-in-time” to rollback configurations — or prevent security scanners from running into loop or crash conditions. Cloning and templating can have significant advantages in terms of agility for testing and scaling architectures, in addition to aiding changes and repair processes.

Microsoft (including the free Hyper-V Server) and VMware (including the free ESXi) are the major players for hardware-VMM server virtualization, with the FOSS project, Xen, being prominent in some other product implementations.

Both VMware and Microsoft have their own disk formats for importing VMs (aka “Guests”) on to their Hosts (aka Hypervisor or Virtual Machine Monitor — VMM). There is also a third, open format called OVF (or Open Virtualization Format).
1. Microsoft: VHD (Virtual Hard Disk)
2. VMware: vmdk (virtual machine disk)
3. Open Virtualization Format: ovf
Sometimes, one-off scenarios will utilize tar, zip, or rar files to distribute VMs or encapsulated VMs, but this is becoming more and more rare.

Virtual Appliances

A Virtual Appliances is a pre-packaged VM. Normally, a VM is just like a new machine — no OS, no nothing. Virtual Appliances come with stuff, and usually only require booting into a DHCP-enabled network, where they self-configure themselves and become available via a web interface for further interaction.

You can find VAs at the following sources:
- VMware — [www.vmware.com] [www.vmware.com]
- Microsoft — VHD Test Drive Program, VHD Partners, VHDs by Product
For those of you still using the outdated OSI model (i.e. you stupid network security geeks, j/k ;> ), here is a general layout of what is available for you:
- Layer 7 – Stonegate Virtual IPS
- Layers 5&6 — Checkpoint VPN-1 Virtual Edition
- Layer 4 — X-m0n0wall
- Layer 3 — Vyatta Community Edition 5
- Layer 2 — HoneyMole
Certainly, if you haven’t read or seen Chris Hoff’s various recent presentations, then you’re going to screw this up. However, anyone with even a few weeks of virtual infrastructure experience will understand the application of the above VAs in a virtual infrastructure environment.

VMware is very useful for fuzz testing (as seen with Sulley and other frameworks which include interfaces to VMware monitors), and full-state or kernel debugging (as seen with Syser, the replacement to the classic SoftICE), but this is more often for the VMware Server/Workstation products, not their Virtual Infrastructure products (i.e. ESX, ESXi, Virtual Center, vCenter Server, and vSphere).

Many ISOs are moving to VAs.

Many demo-ware and software evaluations are moving from standalone installs directly to VAs (i.e. demo the new app on the new OS at the same time!).

Take these examples outlined in the next sections for a test drive.

Pen-test VAs

Would it be nice if you could setup a perfect pen-test environment, save it, and then clone it a bunch of times in order to tweak one specific thing and then run all your tests in parallel (say, with different credentials). Well this is exactly what Pen-test VAs are going to allow you to do. One machine: 4 web application security scanners.

Or better — run DRS (VMware’s Distributed Resource Schedule), which will automatically move VMs around contended Host resources. Say you have four physical machines, all with a dual-core 2.2GHz proc and 3GB of memory. Now say that you’re scanning some client machines in far away places (with constant ISP bandwidth churn on both ends — and in between). Let’s pretend you have this setup:
- IBM AppScan running default-mode with regular user credentials
- Acunetix WVS with AcuSensor tweaked specifically to the app using (at the very least) the web configuration files and structural layout. One of your co-workers is changing the configuration as he/she learns more about the app from the client and working with the Acunetix support team
- WebInspect running in four more VMs, two with admin rights — two others with user rights. They’re setup to do parameter tampering and see if they can pollute access controls from admin to admin, user to user, or any combination
If any of you know what CloudAV is… think what CloudWASS would look like. I call it “WhiteRockSec”, which is… “like WhiteHatSec, but on Crack”.

Of course nobody has built these VAs yet. In the meantime, you can use these two VAs to accomplish something similar:
1. OWASP Live CD VA
2. InGuardians Samurai Web Testing Framework
WAF VAs or as I like to call them: VA+WAF

VA+WAF is a Virtual Appliance that includes a WAF. To those of you who don’t love my humor, you’re bound to definitely hate me for flipping the script on this marketing terminology.

Because network vendors (F5, Citrix, Breach, Cisco, Barracuda, Imperva, et al) really like to sell expensive appliances, it’s likely that they aren’t too keen on the idea of selling a software-based VA that is equivalent to their mind like an ISO (anyone remember the presentation on how to reverse-ISO a Netscreen IDP onto cheap PC hardware?). So you don’t see too many of these around yet.

I did happen to find these two though:
1. Microsoft IAG 2007 Virtual Machine Trial
2. Security Enhanced Web Application Server with mod-security
AppDev/AppSec VAs

Again, there really isn’t much here yet.

Microsoft has:
Note well that the last link above, for the VSTS 2010 pre-release, has the VA in “vmc” format. “vmc format” was from Microsoft’s older product. Searching the Microsoft Download Center for vmc or vhd both have great results, but hopefully Microsoft will standardize on VHD or OVF. For now, you can convert in many ways — including the latest tool from Microsoft, the VMC to Hyper-V Import Tool.

Integrating AppSec with the above VSTS and TFS tools is relatively easy. For those not familiar with FxCop, StyleCop, and CAT.NET — you certainly should be. TFS has some great built-ins for Governance that apply equally well between quality and security. The TFS Team Blog has some decent postings on topic, not directly to security yet (but probably in the future). I’m working on additional ideas, heavily borrowed from the Microsoft Process Templates and Tools development center — and from watching how Microsoft uses TFS with their new MPT toolkit.

Security folk such as myself might want to just load Source Insight (or the Microsoft Express Editions) along with using the command-line CAT.NET or possibly SharpDevelop until Ounce O2 is widely available.

For Java, you can search the VMware Appliance Directory, but I found nothing useful. Currently, the easiest and cheapest way to get JEE AppDev/AppSec going is to use EasyEclipse. There is a commercial equivalent called Yoxos that also sounds very promising. I think most of us would be flying blind without a few Eclipse plugins such as Classlocator, Jupiter, Flow4J, IvyDE, FindBugs, and PMD. Build server ISOs such as Buildix would be wonderful to turn into a VA.

Again, us security folk would probably stick to Source Insight and/or SciTE along with the command-line versions of FindBugs and PMD. Static analysis tools are slowly turning to be out of vogue these days… so YMMV.

Summary

Learning Virtual Infrastructure is going to take some time, but the payoff is worth it. In no time, you’ll be turning your minimally-equipped Security Operations Center or appsec group into a real infrastructure to fear.

Download the hardware-VMMs to “whitebox supported” hardware (note: this doesn’t always have to be on an “official list” from the vendor). Try both the evaluation versions (Microsoft Windows Server 2008 R2 Beta with Hyper-V Role enabled ; VMware ESX and vCenter Server VA) and the free ones (Microsoft Hyper-V Server 2008 R2 Beta ; VMware ESXi). Download a few VAs in various formats and learn how to import and start them. You’re on your way!
Fun with WiFu and Bluesniffing

Posted: September 23rd, 2008, 9:52pm CDT by dre

Tags: Hacking [edit]
This is just going to be a long list of links with rants. I have taken up the duty of disseminating information on the latest in WiFi and Bluetooth penetration-testing for no real reason other than it’s on the tip of my tongue.

First, we have the BackTrack 3 project, which is basically mandatory if you want to be doing any wireless pen-testing. See if your laptop is supported:
- BackTrack Laptop Compatibility List
People like ErrataSec suggest Asus Eee PC, others say Acers, others say Apple. I have a Thinkpad. Whatever. You have what you have, and you will probably need to buy additional hardware. I’ll get to that in a second.

The only real software that is missing from BackTrack is this new python code called Pyrit. It’s not for pen-testing yet, but it certainly looks to build on the Church of WiFi WPA-PSK Rainbow Tables work.
- pyrit - Advancing in attacking WPA-PSK
Pyrit uses either the CUDA FPU acceleration and use of NVIDIA GPU’s on their video cards instead of the old standby OpenCiphers.org method of using FPGAs. Pretty neat stuff. If you can get a CUDA-enabled mobile product in any future laptop that you buy (minimum 256MB video RAM), then I highly suggest doing so based on this information.

The aircrack-ng wiki is really coming along. Check out How to Crack WPA/WPA2 if you are confused about the hows and whys of cracking WPA-PSK.

Pyrit also supports acceleration through the VIA Padlock hardware crypto accelerator found on the VIA C7-M CPUs. There’s a lot of motherboards that support VIA C7-M these days, many which you can find on iDotPC.com. I found this cute little laptop called the One Mini A110, which has lots of information dedicated to the VIA Padlock and Linux.

Of course, small is “in” with pen-testing. The ErrataSec guys had the FedEx iPhone trick at Defcon this year, and now it appears that others are trying to get into this business with $700-1000 phones. Yes, the NeoPwn is probably now available and soon to be sold-out, just like those iPhones.

The NeoPwn would probably be great for running aircrack-ng, but it would leave a bit to be desired for running Karmetasploit with a Caffe Latte twist.

Speaking of Caffe Latte, both the airbase-ng and aireplay-ng tools now support Caffe Latte as well as plenty of other attacks. Many other commercial tools, such as CommView for WiFi don’t even support half as much as the aircrack-ng tools. Aircrack-ng is quickly becoming the standard in WiFi and WEP attacks. Offensive-Security (from the makers of BackTrack) now has a certification and an online course available called BackTrack WiFu that features the aircrack-ng suite.
- [PDF] BackTrack WiFu information and course syllabus
While I prefer CommView for WiFi for Arp reinjection with Aircrack-ng GUI for the PTW attack because using them together is stable, easy, and extremely fast — I think that Wesside-ng looks very promising to automate the same. The problem is that there are so many one-off scenarios (just check out the PDF above for a short list!). The great thing about CommView for WiFi is that it’s easy for me to identify what is going on quickly so that I can adjust the attack. Saving packets 20,000 at a time is annoying, but Wireshark’s mergecap settles the issue for me before cracking with Aircrack-ng GUI with PTW.

The Backtrack WiFu PDF syllabus also mentions Easside-ng, which implements a very quick fragmentation attack against WEP. The wiki page compares Easside-ng to Wesside-ng, and you can see that they are very different. It also explains how they can work well together. I think attacking the AP is less exciting than attacking the clients (ala Karmetasploit or Caffe Latte), but it’s amazing how far this work has come along.

Tom Nicholson of NicholsonSecurity turned me onto Jasager, which is Karma on AP firmware (and a nice GUI interface to Karma!). It’s so hard to find good access points these days. A few sources are reporting success with the Asus WL-520GU, but I’ll believe it when I see it. I’d rather just go with a Soekris board or iDotPC running Pyramid Linux or similar.

If you’re really going to go out and buy something though, I suggest investing in CSR-BC4-EXT Bluetooth USB adapters. The Neopwn happens to come with a CSR-BC4 Bluetooth device (not sure if it is EXT or ROM), but I don’t think this is an accident. CSR, or Cambridge Silicon Radio, has a Bluetooth chipset that happens to be used by one of the only USB-based HCI sniffer vendors, Frontline. Some reverse engineers are apparently working an open-source implementation for firmware that can perform HCI sniffing. Until this time, many are copying the Frontline/FTE Comprobe firmware onto their CSR-compatible Bluetooth USB adapters. It is really difficult to find information about HCI sniffing! However, Remote-Exploit’s Forums have an awesome thread going on about it (if you have an hour or so to read it — it’s long).
- BT3 Tutorial: One bluetooth post to rule them all!
All of the information is contained in this tutorial, but many readers are frustrated by the disjointed information, further frustrated by rumors of bricking the hardware. I disagree — the information is there in entirety, you just have to read it. There are a few links that I’d like to post, as it summarizes some (but not ALL) of the information you’d need to get started. Yes, you really have to read the whole thread.
- Bluetooth sniffing for less (incomplete article, but some of the comments are quality)
- Bluetooth Dongle with CSR chipset and flash or external memory using Flash (also has quality comments)
- D-Link DBT-120 C1 USB Bluetooth adapter — do not blame me if this doesn’t work, but apparently this adapter has the CSR chipset with BlueCore 4 and is capable of External/RAM (not ROM). It may also be available at Fry’s Electronics (in the US). See this D-Link tech article for more details on how to identify the correct revision. It’s $16 anyways, so no big loss if it doesn’t work, right?
The point here is that if you read everything and take it all in, then Bluetooth penetration-testing is in your future. There are no shortcuts to the bleeding-edge. However, it is likely to be extremely rewarding. I somewhat believe the rumors that the pairing exchange could possibly be reinjected in order to sniff and crack any Bluetooth PIN. This would mean access to make phone calls, listen in to audio, and have full or partial access to a Bluetooth-connected device’s filesystem with the speed of access and ease of WEP attacks. If you look at what happened to WiFi and WEP, there are probably plenty of radio-based as well as client-side exploits to consider.

After sniffing the Bluetooth pairing exchange, you’ll still need to crack the BT PIN. n.runs provides the BTcrack tool for this purpose. Thierry Zoller’s research seems to run in line with Frontline, Codenomicon, and others — apparently he’s working on USB fuzzing according to his new blog.
What web application security really is

Posted: June 15th, 2008, 8:02am CDT by dre

Tags: Hacking [edit]
I wanted to do a post about “what web application security really is” because plenty of people out there don’t get it. They understand that “security attacks are moving from hosts to the Web”, but they have no idea what that means. To most people, web application security is the same thing as website security. I see people trying to approach web application security in the same way that they have tried host security in the past: penetrate (web application security scanner) and patch (web application firewall) — which won’t work.

Web application vulnerabilities are different from regular vulnerabilities in more ways than you would think

Web application vulnerabilities are not a one-time thing. In a similar way, buffer overflows are also not a one-time thing, however we’ve been lying to ourselves for 20 years about it. The nice thing about buffer overflows is that they have been historically found with random input testing (e.g. fuzz testing) or code review as “one-off scenarios”. A security researcher will find one, but that doesn’t mean it’s exploitable — better yet it doesn’t mean that the entire codebase is riddled with them (however, some repeat offenders obviously suffer from this problem).

With web application vulnerabilities, the more complex the app — the more likely an adversary can make his or her dreams into an exploit reality

In the case of web application vulnerabilities — one vulnerability means that there are often thousands of others — hence the claimed high rate of false positives in automated security review tools — with specific regard to SQL injection and XSS. What’s even more clever about web application vulnerabilities is that they often work together — they string together to form a bigger attack. A few little bugs equals one giant nasty bug. This also isn’t the situation with fat applications — a stack-based buffer overflow is usually one mean bug, but once it is patched properly the nightmare is [usually] over.

Web application profiling and Google Hacking read the developer’s minds like Jedi magic tricks

Another problem with web application vulnerabilities is Google. Yes, Google. Before Google’s code search, it was difficult to use Google to find a new buffer overflow. But such is not the case with web application vulnerabilities. All the blame isn’t on just Google’s search engine, but also MSN Live Search, Yahoo, and many others. It’s so easy to just find a login form and start playing with specific, exploratory characters. Buffer overflows require buffers of a certain length with enough room for shellcode to overwrite EIP (or execute via cute pointer tricks) in order to establish a reliable exploit. Web application vulnerabilities don’t worry about such restrictions. Once a web application is profiled (which could be as simple as an inurl:login.asp Google search), an intelligent adversary should already know numerous amounts of input techniques which will work against that specific type of application.

Web application vulnerabilities are like Legos for crimeware

Finally, adversaries aren’t moving away from client-side vulnerabilities. They’re just implementing the attacks differently. Web application vulnerabilities work well along with older host-based vulnerabilities. This isn’t only because web application vulnerabilities can get inside the firewall. They open up many different doors for attack. Using Inter-protocol exploitation, it is possible to send shellcode through an XSS/CSRF/XHR worm. But it’s also possible to send XSS worms through XSS worms or SQLi worms through XSS worms. Or XSS worms through SQLi worms. An adversary can put these types of attacks together however he or she wants.

Web app security today — The 2008 SQL Injection Attacks (January - present)

The 2008 SQL Injection Attacks have spawned a lot of talk and controversy about web application vulnerabilties. It appears that if web application vulnerabilities were not mainstream in crimeware — they now are.

The Microsoft Security Vulnerability Research and Defense blog had an excellent post regarding these SQL Injection Attacks. I think it dispells a lot of the myths about this attack, and it provide a lot of information on what to do about it. Of course, if you’re not used to the developer terminology (as an IT security professional or manager), it’s probably now as good as time as ever to read up, hire some experts, and get the word out.

There’s a lot of links, but the most important one is how to identify and fix the problem. What’s interesting is that a lot of the links talk about ASP.NET, but the attacks from Asprox’s fake “Microsoft Security Center Extension” SQL injection attack tool only seem to currently target Classic ASP.

If you have access to IIS logs, you can also run the SQLInjectionFinder.exe tool. Of course, if you run a web application security scanner, you may or may not find SQL injections in your Classic ASP web application — but this doesn’t necessarily mean that you are or aren’t hosting the Javascript malware. If you have a web application firewall, this doesn’t mean that your web application can’t be attacked via internal networks (assuming your web servers are listening on different interfaces) — and it certainly doesn’t mean that you aren’t hosting the Javascript malware.
- Web application security scanners cannot help in this scenario
- Web application firewalls also cannot help in this scenario
A better tool to test if you are hosting the Javascript malware would be to use a tool such as SpyBye.org. You can just set up your web browser to proxy through Spybye.org, or you can run it locally (e.g. to check your Intranet web applications) — and it can also integrate with ClamAV. TS/SCI Security (well, Marcin and I) discussed this strategy when we did the Network Security Podcast with Rich Mogull and Martin McKeay.

Many faces of the same SQL injection attack

Also mentioned in the Microsoft Security Vulnerability Research and Defense blog post on the SQL Injection Attack is that it’s not just one attack tool — it’s a bunch of tools and tactics. For those of you not familiar with Joe Stewart’s SecureWorks article on Danmec/Asprox, be sure to give it a full read. Additionally, check out the SANS article from Bojan Zdrnja on the 10,000 web site infection mystery solved. My favorite is a quote from eWeek’s article on Botnet Installs SQL Injection Tool:

Researchers are still investigating exactly what vulnerability on the Web sites is being exploited, Stewart said. The Web sites are English-language and their owners include law firms and midsize businesses.

A similar attack technique is currently being seen spreading game-password-stealing Trojans from China. Whether the tool is related or only the attack syntax is shared, it is clear that SQL injection attack activity is on the rise from multiple sources, Stewart wrote in his blog.

Why WAF’s are the wrong answer if you didn’t get it the first or second time

When I see WAF support from organizations like SANS supporting Jeremiah Grossman — as well as big companies like Imperva — I immediately question their reliabilty as sources for expertise. If the web applications serving malware are largely owned by law firms and midsize businesses, then these are likely outside of the scope of SOX, PCI-DSS, GLBA, HIPAA, and BITS Shared Assessments. Many of these organizations don’t even have the money or administrative staff to support WAF’s as an option.

What works in web application security: Take 2

What these companies need is an IT decision to remove, replace, or recode any web applications which clearly demonstrate an affinity for SQL injection vulnerabilities (especially ones written in Classic ASP). If replacement or recoding are used, then it would be a good idea to establish some software risk guidelines such as how web application software is acquired and tested before loaded by a web server. It’s not a matter of production or not — all applications, internal/Intranet/lab/test/etc — all of these applications need to be asset tagged and approved as tested. It’s now considered important enough to know what web applications your organization is running because of the risk involved by a SQL injection (or other web application vulnerability) “drive-by”.

Why we need action now

If we just let this malware sit dormant in web applications, we’re in for a lot of trouble. All that is required for adversaries is to flip a switch — and now they can deliver any new zero-day threat they desire. These could be websites you visit everyday. This could be web application code executed by your browser when you start it. It could even be your Intranet server, or a partner site you use. It could be your favorite online shopping site.

Don’t hesitate to make a decision. The next wave of these attacks may not work through an antiquated botnet or a standalone tool. They will probably target PHP MySQL applications, ASP.NET applications, both, or even more. There may not be simple tools such as SQLInjectionFinder.exe or SpyBye to help locate these vulnerabilities — and some could even stand the scrutiny of incident research for some time. How long did it take us to understand these SQL Injection attacks? Longer than 6 or 7 months?

If you think that implementing a WAF will save you (even in the short-term), please let us know why you believe this is the case. TS/SCI Security sees the WAF answer as FUD, lies, and/or short-sightedness. The best answer is to recode or replace while we still have the chance.
Qualities of good pen-testers

Posted: March 17th, 2008, 11:14pm CDT by dre

Tags: Hacking [edit]
Taking care of business

Before I get into this post, I wanted to give you some updates on progress of other projects here at TS/SCI Security.

First off, I’ve been working on the OWASP Evaluation and Certification Criteria Project and hope to announce something very soon. Secondly, you’ll want to take a look at today’s post on The New School of Information Security book (Acidus also did a writeup). As a side-note, there was an interesting data breach recently announced, which makes information on breaches even that much more relevant.

Lastly, I wanted to announce the return of the “Day X: ITSM Vulnerability Assessment techniques“. Expect a post everyday with new and relevant material.

Positive spin on pen-testers

Matasano posted last week on the Seven Deadly Pen-Test Sins, with follow-ups from two other blogs I’m aware of: Mike Andrews and BlogFranz. This should be a hot-topic!

At TS/SCI Security, we like to focus on the positive instead of the negative. Pen-testing, especially application pen-testing/review is an important topic to us. So here’s our rundown of what we feel is important to know about pen-testing, as a response to what Matasano wrote.

Seven things you can do to improve your pen-test results

1. Time Management. If you’re not already using GCalendar, RTM (with GCal), Twitter, Sandy, and Jott (thanks to Dennis Groves for some of these!) — take a look at how these can help you manage your time better.
- Good pen-testing takes time. If you haven’t gone through everything you need in #2, then you might need more time. What I’ve found is that pen-testers need to frame their pen-tests after good strategy consulting (1-2 days of a SWOT or similar analysis). If, like mentioned in The New School, the “basics” are not taken care of — then help the client work on asset, configuration, and change management before doing a vulnerability assessment.
2. Utilize applicable MITRE resources. CAPEC (for runtime testing) and CWE (for static analysis testing, which may include reversing) should be utilized throughout. Be careful to only choose the relevant aspects of each (relevant to the application, not your skill or other criteria).
- My favorite MITRE resource is the Introduction to Vulnerability Theory, which Marcin and I spoke about at ShmooCon in our talk on Path X. It may take some extra time to spell out exactly how the vulnerabilities were found using this method, but it will help future assessment work, including repeat client business.
3. Work with developers. Assuming that the dev team is already doing Continuous Integration (or something like it), Fagan inspection, using the V-Model (in the requirements phase), continuous-prevention development, integrating concepts from the Microsoft SDL (or similar secure SDLC), and automated integration testing — then get involved right away with a software walkthrough with all of the key players.
- Standard C and assembly code is difficult to reverse the design from, but they are becoming more easy to reverse. In the case of Java, C#, and C++ — UML can be extracted to elicit the design of the application. Using other tools such as Klocwork K7, Fujaba, or IBM Rational Rose on the UML diagrams will possibly provide faster program understanding. Left with the source code, GrammaTech CodeSurfer also aids understanding, but open-source tools such as Doxygen can also be of use.
4. Automate development-testing. While web application security scanners (or fat application-based fuzzers) collectively only typically find at-most 30% of the bugs with a large amount of false positives, there are plenty of developer tools that don’t have these problems.
- Developers should be made aware of integration testing with Canoo WebTest. Business analysts, customers, and test managers can submit table-driven test cases using FitNesse (a wiki that allows for collaborative test case design), along with additional tools such as HtmlFixture. I’ve spoke to the benefits of Dependency Injection before, as well as automating Continuous Integration both inside of the IDE as well as during the application builds.
- Automation is good for developers and the modern tools surrounding test automation are extreme improvements over last decade’s technology. However, test cases and test-first strategies still find only as much as half (possibly up to 70% or more) of the bugs. It’s good to combine exploratory testing with scripted (i.e. from a test case) testing. Allot some time with a buddy and explore the application as it wasn’t meant to be run after learning as much as you can from the developers and their automated tests.
5. Peer review your work. This one is easy. Find a friend and have him/her check your work. The more eyes you get on your pen-test and assessment work, the less likely you’re going to miss something.
- Consider a good workflow approach such as the open-source Review Board: Online Code Review Tool or the commercial Atlassian set of project management software, including JIRA, FishEye, and Crucicble. Many projects such as Adium do code review based on email notification of new source code revision control changes.
6. Stay up-to-date on both process and technology. Read forums/blogs/mailing-lists, trade journals/magazines, and books. Attend conferences. Keep it cheap and continuous if possible.
- I try to read every security-related book that pops up on Safari Library and ACM’s access to Books24×7. Audible/Amazon are certainly other resources, especially for non-technical solution learning. Checking yourself at least once a year on a certification or re-certification program will make strides in your professional development.
- Using GReader and sharing daily using it’s sharing features and OPML with your colleagues is important. Get involved in conversations on forums, IRC channels, blogs, and mailing-lists is likely the largest win here.
7. Go back to basics. Set a minimum bar of maturity with clients before you pen-test or do an assessment. The BITS Shared Assessments Standardized Information Gathering questionnaire is a nice start, especially combined with Visible Ops, ITIL, COBIT, ISO27K, PCI-DSS, PABP/PA-DSS, ISECOM, and OWASP information on process.

All of the above is going to go a long way towards improvements to what pen-testers and vulnerability assessors do. There’s very few good certifications out there for what we do, and it’s difficult to measure what we do. Put the cards on the table up front with your clients and teach them your methodology and approach.
Quick Shell Notes

Posted: March 7th, 2008, 11:34am CST by Marcin

Tags: Hacking [edit]

I’ve been doing some work lately with text files and have been using various shell command techniques to manipulate them for whatever purposes I need. This isn’t a HOWTO guide as much as it is a reference for myself and others that just need something quick to work off of.

The first command I reach for is the find utility. If you didn’t know, you can pass arguments to find that will get executed when find finds a match. This command will find all Nmap greppable output files and grep for lines with “Status: Up”:

$ find . -name *.gnmap -exec grep “Status: Up” {} ; Host: 192.168.1.1 () Status: Up Host: 192.168.1.10 () Status: Up Host: 192.168.1.40 () Status: Up Host: 192.168.1.42 () Status: Up Host: 192.168.1.102 () Status: Up Host: 192.168.1.103 () Status: Up

You can improve the above command further with `awk` to only print out the IP addresses that appeared online:

$ find . -name *.gnmap -exec awk ‘/Status: Up/ {print $2}’ {} ; 192.168.1.1 192.168.1.10 192.168.1.40 192.168.1.42 192.168.1.102 192.168.1.103

If you need to know what file the matching results came from, you can do the following:

$ find . -name *.gnmap -exec awk ‘/Status: Up/ {print $2}’ {} ; -print 192.168.1.1 192.168.1.10 192.168.1.40 192.168.1.42 192.168.1.102 192.168.1.103 ./nmap_scans/192.168.1.0_24.gnmap

Nmap results are pretty easy to go through, but what if you have Nessus nbe files? If you’ve ever seen a Nessus nbe file, it isn’t pretty. The following command will run through a nbe file and print out IP addresses and NetBIOS names in CSV format. Nessus PluginID 10150 identifies scanned hosts’ NetBIOS names.

$ find . -name *.nbe -exec awk -F ‘|’ ‘$5==”10150″‘ {} ; | awk ‘{print $63″|”$1}’ | awk -F ‘|’ ‘{print $1″,”$4}’ stacker,192.168.1.10 slaptiva,192.168.1.40 thinker,192.168.1.42

The last script I have found useful is when I need to pull text broken up over several lines back into one really long line. I accomplish this using awk, with the following command:

$ awk ‘BEGIN {RS=”nn”; FS=”n”} {for (i=1;i printf “%s “, $i ; printf “nn” }’

The Handy One-Liners for Awk and Handy One-Liners for Sed have both been awesome references that I keep bookmarked. I have also found myself keeping UNIX Power Tools open all day as well.
Hardware VM security: past and present

Posted: February 5th, 2008, 4:35pm CST by dre

Tags: Hacking [edit]

Marcin and I were talking a bit about mainframe security today. I recalled how fantastic mainframes were while he had his hands in the trenches. Yes, I know that IBM renamed MVS to z/OS (as well as other things) years ago. However, the concepts remain the same: TSO, ISPF, and JCL are still there.

I tried to explain some of the differences between z/VM and z/OS. z/VM is based on VM/CMS, which ran an antiquated version of hardware virtualization concepts that we find in modern technology such as Xen. I also pointed Marcin to the Wikipedia entry for RACF, where we checked out and discussed all the links. Recently, I had also read Mainframe Basics for Security Professionals, so you can check it out if you want more information.

As we got deeper into the conversation, we talked less and less about mainframes and more and more about Xen. I related concepts of clustering from the Big Blue days of IBM, which ran AIX on SP2 clusters. What Xen and new-age hardware virtualization packages are lacking is not only security concepts, but also general improvements and refinement of technique.

The whole point of running multiple OSes on a single machine escapes most people. They mostly want it so that they can run Mac OS X and Windows on the same laptop. That’s the opposite of what this technology is meant to do. It’s for big servers with lots of processors and memory. It’s intended to be able to migrate, restore, route-around availability issues, and increase performance.

That’s correct: increase performance while also moving an OS between physical machines. Late at night, an entire mainframe-sized machine or two can be shutdown for maintenance and to save money on power — while another mainframe-sized machine picks up that work until early in the morning.

Some people say, “well if this computer is sitting here only running one task on CPU for 4 hours a day at 90%, then we can just run SETI@home the rest of the time it’s idling at 10%”. This is exactly the kind of attitude that caused the Dot-Com era way of thinking. The real goal is to move services off that machine when it’s not using them, and safely carry them out elsewhere.

Speaking of the laptop, think of Xen save/restore/migrate more like your laptop’s hibernate feature. When it comes up again, you’re back in business. Xen migrate makes moving an OS between machines “instant business”. The primary extra difficulty system administrators and IT people have with understanding Xen migration is that it requires shared storage. I’ve setup iSCSI with Xen and maintained it using CentOS (RedHat Enterprise Linux, or RHEL), even in a clustered configuration. When architecting this sort of solution — you really have to look at all the dependencies you create, otherwise you’re just adding more headache. For an introduction to the subject, check out this article on Live Migration of Xen Domains.

While separating out every service into its own guest seems like a great idea at first, it also would require installing many OSes and keeping them all up-to-date with patches. This would seem to lessen the security since most people install an OS using a CDROM or DVD using default configurations. They don’t want to take the time to setup and manage “more” machines, when they already have their fill with the current situation/mess they are in.

Enter VMcasting. VMcasting allows package updates to be distributed via RSS feeds to the guests. I had first heard about VMcasting from a company who makes both Enterprise Xen control software, as well as an open-source version — Enomalism. Enomalism has features that are very different than most of the other Xen Enterprise managers, including VMcasting. It supports sHype (a hypervisor access-control system similar to SELinux or RACF, with support of RBAC and TE), a firewall management application, centralized user management with LDAP controls, and a custom web API written in — you guessed it — Ajax. I can’t believe I just used Ajax and RSS in the same paragraph as describing the benefits of hardware virtualization as it applies to vulnerability management, but there you have it.

The additional benefit of Enomalism comes in the form of its EVA containers (Enomalism Virtual Appliances). An EVA is a package, but that package can contain multiple virtual machines, such as two web servers and two database servers. These can be pre-configured and ready to be put into a lab or staging environment right away. Speaking of labs, imagine setting up a security penetration-testing lab using EVA containers.

After recently also reading “Penetration Tester’s Open-Source Toolkit, Volume 2″, the updated section on Building Penetration Test Labs gives some excellent suggestions on using Pen-Test “system lab” LiveCD’s for learning purposes. Booting from CDROM as a virtual environment takes a lot of the work out, but imagine if you combined it into a bootable Pen-Test “network lab” with an EVA package.

Check out the authors’ website at DE-ICE.Net for a list of the LiveCD “system lab” packages. See if you can spend some time making them into an EVA container, but don’t VMcast and accidentally upgrade all of the out-of-date packages! Also of note would be the SecurityDistro website, which lists many of the FOSS LiveCD projects — be sure to check out their new Beta website portal (register and join the fourms!), which should roll into their main site very shortly.
Day 10: ITSM Vulnerability Assessment techniques

Posted: January 23rd, 2008, 1:06am CST by dre

Tags: Hacking [edit]

Lesson 10: You could say I’m a little late on posting something. However, we’ve been up to a lot of great research, hopefully much of which we’ll publish here over the next few weeks.

We had a few posts lately, some of with a change of heart. The latest must-read from the blog world comes from Nitesh Dhanjani at O’Reilly’s ONLamp, What Have You Changed Your Mind About?

So far, I’m the only person who has commented, and I didn’t really answer any of his questions. However, the post itself is quite insightful. It talks about data breaches in terms of strictly PII (Personally identifiable information), where PII comes from, and the problems inherent with static-identifiers. I give some defense suggestions in the comments.

Related to Nitesh’s post is Adam Shostack’s predictions on the SDL Blog, New faces and predictions for the New Year. Bryan Sullivan is also introduced to the team (recently joined from HP / SPI Dynamics) with his XSRF (CSRF) predictions. He’s probably referring to Web services, Ajax, Silverlight, and other RIA — which contain CSRF’s that may be more critical than the ones built-into HTTP. For an example, check out the JSON API Hijacking research from the Fortify Software paper, as well as made available in the books Ajax Security, the Web Application Hacker’s Handbook, and Hacking Exposed Web 2.0.

Part 1: Information assurance vulnerability assessment — Protective measures, Identification — multi-factor authentication — physical access control

Something you know. Something you have. Something you are.

This is the tenant of authentication for security systems. The first thing I think of — what about one-time passwords — OTP’s (a cross between something you know and something you have in the case of an RSA SecurID hardware token device, but this is more confusing when it’s software such as S/Key or OPIE)? What about a USB/Smartcard that contains RSA, DSA, or El-Gamal keys?

There is a company, StartCom, who not only provides free, usable SSL certificates — but that also sells Aladdin USB Tokens. StartCom is a great way to avoiding using your own private Certificate Authority (CA) if you have a need for this. However, the StartCom root-level CA’s are only shipped in Firefox, Safari, and Konqueror.

The Aladdin USB Tokens and Smartcards are very interesting, mostly because they are cheap ways of providing average sized keys (2048-bit) in hardware. The Aladdin eToken NG-OTP appears to be a great concept — combine the concept of secure keys with an OTP.

Even better would be to combine the OTP and hardware keys with Single Sign-On (SSO). Also interesting is to be able to combine both logical (system/network/application) and physical (proximity, photo ID badges, locks, man-traps) to create Integrated Physical and Logical Access.

Recommendation: Consider adding physical tokens, integrated access controls, SSO, and OTP’s. Testing the authentication and access controls would be extremely fun — it’s odd that I haven’t seen much research in this area of security much at all.

Many organizations don’t have any physical access controls other than a shared/copied key on tumbler locks and/or a security system (mostly for insurance purposes). I’ve seen a lot of complex systems, including ones that provide cameras, audio monitoring (it’s claimed that this can be used for calling the police more easiy than cameras).

I suggest avoiding surveillance systems (both the audio and video kind) and installing a simple wireless security system with alarm monitoring. Keep fire safes around to store documents in almost every office for anyone who wants one or is willing to use one.

There is the Home Security Store, which offers wireless alarm kits (from DSC as cheap as $245) and other wireless solutions — I suggest DSC Wireless products. The Home Security Store also appears to partner with Alarm Relay, who offers monitoring for $8.95/month. Cheap isn’t always good, but in this case it appears to be better than most systems that cost hundreds to install (where you’re leasing the equipment anyways) and at least $40/month for monitoring.

You might be thinking that it is strange that I suggest such a pragmatic approach to physical security, when I suggest such complicated concepts for application, network, system, and software security. Insurance is more clearly defined for physical security, where cyber-insurance and liability concepts are more “cutting-edge” and being worked out. We’ll cover cyber-insurance in a future post, but I suggest checking out the book “Geekonomics” by David Rice for more information on this topic.

Protecting your building doors, windows, locks, and walls is usually a better place to start. Be sure to check out No-Tech Hacking guides, lockpicking videos/presentations, and other material available out there. Try out these techniques against your own home and office.

I suggest to start with key bumping. There is a good triangle-shaped file you can get at most hardware stores, which works well alone or with a Dremel tool. I have both of these, a few key blanks of different types, a few key gauges, and some test locks. If you want to learn more check out the No-Tech Hacking book by Johnny Long, or attend the presentation at ShmooCon (recently announced speaker-list from earlier this evening!) — New Countermeasures to the Bump Key Attack by Deviant Ollam.

Part 2: Software assurance vulnerability assessment — Path traversal and Predictable resource locations (PRL’s)

Best Path traversal and PRL attack tools

Nikto, filefolderenum, http-dir-enum, FreeWVS, babelweb, Burp Suite, w3af, DFF Scanner, OWASP DirBuster, OWASP JBroFuzz, ProxMon, Paros, OWAS WebScarab, sn00per, WebRoot.pl, webfuzzer, Wapiti, Syhunt Sandcat Free, N-Stealth Scanner Free Edition

Best Path Traversal and PRL attack helper tools
FileMon, lsof, strace, truss, ktrace, ExtendedScanner, Inspekt, Orizon, ASP-Auditor, Milk, SWAAT, RATS, PHP-SAT, PHPSecAudit, PSA3, PFF, LAPSE.

I hate to say it, but PRL’s are one thing that commercial web application security scanners are better at than both open-source structural and functional testing tools — as well as possibly even static source code security analyzers. This is where WebInspect, AppScan, Hailstorm, NTOSpider, Acunetix WVS, Syhunt Sandcat, N-Stealth Scanner, and Sentinel really shine.

In tests of a commercial scanner vs. me, I would bet my money on the scanner to find all the WEB-INF/’s, .bak’s, and Emacs “~” files. For more information, check out some books that cover commercial scanners more in-depth such as Hacking Exposed Web Applications (2nd Edition), or Security Power Tools (Section 3.3). In related news, Romain Gaucher compares the commercial tool, Fortify SCA 5.0, to open-source PHP source code security analyzers.
SQL Injection Fun v.RIAA

Posted: January 20th, 2008, 3:37pm CST by Marcin

Tags: Hacking [edit]

What started as a simple DoS against the RIAA through a SQL injection vulnerability, originally posted to Reddit in tinyurl form.

UNION ALL SELECT BENCHMARK(100000000,MD5('asdf')),NULL,NULL,NULL,NULL%20--

led an attacker on to dump their entire database. I sure hope they don’t have backups — part of me thinks they deserve it and wants them to suffer… muwhahaha
Day 9: ITSM Vulnerability Assessment techniques

Posted: January 17th, 2008, 9:28pm CST by dre

Tags: Hacking [edit]

Lesson 9: Yesterday was a bit of a whirlwind, discussing BGP, Whois/RWhois, and the DOM all in one big post. I’ll try and keep it short and sweet today.

Arshan Dabirsiaghi (leader of the OWASP Anti-Samy Project), commented on yesterday’s post regarding how web application security scanners are immature. He thinks they are immature because of the technology. Missing elements such as “the input fields being vulnerable to XSS”, with results such as “we got kaput from the scanner”. He also said, “the loudest people in the room are the scanner marketing companies”.

What do you think?

I agree with Arshan that scanner marketing is out of control in their statements about the technology. When one scanner salesperson called me around Christmas-time, 2006, I told him that the technology just wasn’t mature enough. I said that I thought it might be by the end of 2007. Well, that time has come and gone, with really not too much more to show for technology improvements.

I was never a fan of these tools in the first place. I believe strongly in using them for verifying the results from automated and manual secure inspection. This precludes reliable exploitation or writing weaponized exploits (as much as I list w3af as a useful tool, I also do disagree in the approach and end goals). In other words, you don’t need BeEF or AttackAPI to demonstrate or perform pivoting in the case of an XSS finding. I would rather spend more time looking for more vulnerabilities, refining techniques, and working on the root-cause of the problem — which is always input validation and input/output encoding.

Part 1: Information assurance vulnerability assessment — Protective measures, file/disk encryption

Millions of records of sensitive or private information have been lost due to missing, stolen, or “borrowed” laptops, tape drives, disks, and other various data-containing hardware.

A search on Etiolated for “Stolen Laptop” claims that 7.5M records are involved over the past few years they’ve been tracking statistics. It appears to me that a lot of the reported incidents are due to this type of problem.

Yet, businesses do not have standard images on their laptops and other devices. As Vista sells more at the workplace, it is possible that this will change. Vista includes BitLocker, which is a full-disk encryption (FDE) implementation with varying results of success when implemented. Of course, getting access to revocation keys or private keys would make the implementations broken — this at least makes it so that two things are needed instead of just one.

Any internal threat agent could theoretically copy data off any drive, assuming account access (or escalation of privilege). Again, this is less likely to happen as more than one step is involved. In the future, we’ll be looking at other methods to further decrease the likelihood of this scenario occurring without solution prevention (or at least detection).

Recommendation: Hardware vendors that include software should have the default account already setup for FDE if the OS supports it. Hardening guides should be used to verify. If your company/organizations uses standard builds or images, then there are many solutions that can be used for partial or full-disk encryption.

OS vendors could also force FDE on install. This would be really nice.

For Linux laptops and servers, LUKS is the ideal solution. Many will prefer BitLocker on Windows laptops, and Server 2008 should have similar support. For those who haven’t upgraded yet, commercial solutions exist — although I prefer a thin client laptop such as SafeBook.Net.

While Mac OS X has FileVault (and the hardening guides usually recommend using it), you might want to take a look at TrueCrypt support for Mac OS X partial disk encryption.

TrueCrypt is also supported under Windows 2000/XP, although I prefer FreeOTFE. One of the reasons I prefer FreeOTFE is because it is also supported on Windows Mobile devices such as PDA’s and PDA phones.

If you want more information on setting up full-disk encryption with LUKS, BitLocker, TrueCrypt, or FreeOTFE — I suggest books such as Security Power Tools (Chapter 15, which also covers GPG and S/MIME), Windows Vista Annoyances, Ubuntu Hacks (Hack #70), and Network Security Hacks (2nd Edition, Hacks #39 and 33) from O’Reilly Press.

Part 2: Software assurance vulnerability assessment — Cross-site Request Forgeries

Best CSRF attack tools

OWASP CSRFTester, Chris Shiflett’s CSRF Redirector, PDP/GNUCITIZEN’s CSRF Redirector, CSRF dorks

CSRF can be tested with a variety of different tools. The presentation that goes along with the CSRFTester tool by Eric Sheridan of Aspect Security is an excellent guide. The CSRFTester is a simple Java-based tool.

Some CSRF redirector tools such as the ones by Chris Shiflett and pdp seem to work in similar ways, along for online testing, but be careful what gets logged to these sites! The CSRF dorks spawned out of the sla.ckers.org forums and Ronald picked it up to support a CSRF database project on his website.

My favorite thing about testing CSRF is looking at the level of defenses in use by a web application. Testing CSRF is so easy and simple compared to XSS or SQLi. If CSRF works with no active defenses — you can also assume that XSS and SQLi are possible in a lot of cases. It clearly shows a sign of no forethought into security. This provides a rough measurement of a web application’s security at ground zero.

When I say that CSRF has “levels of defenses” — this is also a classic example of how “levels of defenses” can be used to measure web application security testing techniques and methods, including web application security scanners. Romain Gaucher has been giving talks about using “levels of defenses” to benchmark scanners. I saw his first presentation at Verify Conference, but recently he has updated his talk and given it at the HICSS conference in Hawaii. He includes a link to his slides in that linked blog post, as well as a link to NIST SAMATE, which has a focus group on web application security scanners.
Day 8: ITSM Vulnerability Assessment techniques

Posted: January 16th, 2008, 1:05pm CST by dre

Tags: Hacking [edit]

Lesson 8: Two days ago we covered VoIP assessments, and yesterday we covered Intranets and the use of proxies. Most of last week also covered internal network infrastructure assessments, except for some topics such as PDA phones and WiFi devices.

Today I wanted to talk about reconnaissance, which some people refer to as footprinting. Besides the usual sources of trouble (i.e. Google), there are plenty of old school avenues to take when finding information about a company, organization, or person.

Of particular interest is to look at external network connectivity. How does an organization connect to the Internet? I talked about war dialing on Day 6, which has a similar goal and effort. However, war dialing is pure enumeration — start with a number and increment. Searching for external network information is much different as we will see.

We’ll also be covering DOM-based XSS tools in the software assurance section today. I hope you enjoy it.

Part 1: Information assurance vulnerability assessment — Footprinting the perimeter

Whether you know about it or not, your company or organization connects to the Internet the same way that everyone else does. Using the Border Gateway Protocol, version 4. If you don’t run it, then your upstream does — or possibly their upstream.

BGP-4 requires an autonomous system number (ASN) for every organization connecting. Usually these are ISP’s and very large Enterprises. Every owned IPv4 prefix is announced from one of these ASN’s (some organizations have more than one).

This information leaves a trail of data that anyone can query using a whois client. First of all, a Regional Internet Registry (RIR) must be contacted in order to acquire an ASN. If an upstream provider (an ISP) provides the IP prefix(es), this is known as provider-aggregated IP space (PA). Most RIR’s (well, ARIN who is the RIR for North America) loosely require that PA space have additional downstream information placed into their database. There have been two typical ways of doing this: Shared Whois IP (SWIP) and Referral Whois (RWhois). SWIP is in the RIR database, while RWhois is kept in a local ISP database, which can be queried by the RIR to keep information updated.

If an organization goes directly to an RIR to acquire an ASN or IP prefix(es), their IP space is known as provider-independent (PI). Getting PI space usually requires a minimum infrastructure size (a certain number of IP’s to be used). Detailed ASN and IP prefix information, along with organization information (such as contacts for billing, technical support, and abuse issues) is available in the RIR database. This is what is queried via whois/RWhois.

Similarly, you may be familiar with network information center type services (NIC) as provided by the original Network Solutions. Today, we call these domain registrars, and their antiquated whois services, which have access to their databases, may one day disappear. Network Solutions whois even still supports querying antiquated role handles, although I have no idea how to get one of these since around 1999.

Recommendation: Find and protect your Whois data. I suggest a service, such as the one from Namecheap, called WhoisGuard, when you setup your domains (or change them to this). Make sure that your modification of this information is protected by passwords (or better yet — PKI) in the safest manner possible.

Similarly, protect your RIR, RADB, and RWhois data. The RADB is a part of the IRR, with free IRR services available from ALTDB. If this information for your IP prefixes is not secure, then your entire traffic or source could be subverted. This could happen regardless of whether or not your organization runs BGP-4 because it could be a lack of precision by one of your upstream providers that could cause this to happen. Better — use a new type of service to provide assurance to your routing such as using a commercial service from Renesys or the free service from Packet Clearing House, Prefix Sanity Checker.

Querying live BGP information is best done with a Looking Glass server, PWhois, Network ThinkTank, FixedOrbit, and the Team Cymru Network Monitoring pages. My two favorite projects around this space have been Route Views and MERIT’s BGP Inspect, just because of how much data they maintain. Searching through an old BGP table snapshot, or an old copy of the RADB database (or Domain registrar, RIR, and other IRR data) — even in text format — can be extremely revealing about an organization’s network infrastructure.

Other services such as CompleteWhois maintain information about ASN/IP hijacking (and information on individual/group hijackers, which are often — but not always — spammers). The Web Security Authority combines some CompleteWhois information lists to create mod-security rules, which may be an interesting way to protect externally-facing web applications.

I also suggest getting away from the web and using your command line to query this sort of information. You’ll never know when an adversary will insert an XSS as whois database information (although one could argue that a client-side attack could also happen with command-line whois).

whois -h com.whois-servers.net tssci-security.com | grep Server:

This command tells us which domain registrar’s whois server to query for more information. (Note it is possible to change com.whois-servers.net to net, org, us, edu, and many other possibilities if the default com Whois server does not provide the detailed information you want). Whois-servers.net is basically a referral service for domain information. Let’s query the real (i.e. referred) domain registrar now:

whois -h whois.godaddy.com tssci-security.com

Here you can see that TS/SCI uses DomainsByProxy (a similar service as WhoisGuard, but provided by GoDaddy instead of Namecheap).

Try

whois -h whois.arin.net 64.135.2.110

You’ll see both the ARIN information, as well as the RWhois information. If we connect to that RWhois server, as seen below, there are other techniques you can use to gain more information about both the ISP and their customers.

nc rwhois.host.net 4321 %rwhois V-1.5:003eff:00 whois.host.net (by Network Solutions, Inc. V-1.5.9.5) -holdconnect on %ok -forward on %ok -limit 600 %ok -status %status limit:600 %status holdconnect:ON %status forward:ON %status objects:682 %status display:DUMP %status contact:hostmaster@host.net %ok host* -quit

(You’ll also want to check out other RWhois commands such as -security and -register from the RWhois specification, RFC 1714)

whois -h whois.radb.net 64.135.0.0/17 route: 64.135.0.0/17 descr: HOST-64-135-0-0-17-BLOCK origin: AS13645 notify: db-admin@host.net mnt-by: MAINT-HOST changed: db-admin@host.net 20040621 source: HOST whois -h whois.radb.net maint-host mntner: MAINT-HOST descr: HOST/BroadbandONE maintainer object admin-c: HNA-ORG-ARIN tech-c: HNA-ORG-ARIN upd-to: db-admin@host.net mnt-nfy: db-admin@host.net auth: CRYPT-PW IZVSxc8/dvNpk mnt-by: MAINT-HOST changed: db-admin@host.net 20040811 source: HOST whois -h whois.radb.net as13645 …

As you can see, there is quite a bit of information available from Whois/RWhois from Domain Registrars (which you can find using Whois-servers.net), RIR’s, IRR’s, and individually hosted RWhois servers. There is quite a lot to explore, so check out the specifications and also use the server “help or ?” functionality (e.g. `whois -h whois.networksolutions.com ?’).

Part 2: Software assurance vulnerability assessment — XSS on the DOM

Best DOM-based XSS attack tools

Web Developer’s View Javascript, FireBug, w3af, Burp Intruder, scanajax, ProxMon, OWASP Pantera, cruiser, CSpider.js

Any claims that an automated scanning tool can find all XSS is dead wrong when it comes to DOM-based XSS (or Flash based XSS, et al). There are already unique enough scenarios for finding some reflected or stored XSS, but DOM-based XSS vulnerabilities make this even more troubling. Do the right thing and check the source code in addition to dynamic testing. Commercial tools such as Fortify SCA 5.0 support Javascript and Ajax for just this purpose, but open-source tools Aptana, JSLint, JSONLint, and many of the language-specific static analysis tools mentioned in Day 7’s, “Best XSS attack helper tools” section may also be of use.
Day 7: ITSM Vulnerability Assessment techniques

Posted: January 15th, 2008, 7:03pm CST by dre

Tags: Hacking [edit]

Lesson 7: Today I wanted to bring the real meaning behind these techniques into the spotlight. Learning about how IT groups do real security is only part of this.

I’m also talking about what I’ve seen that IT security shops don’t do. What penetration-testers or auditors don’t recommend. What everyone misses. This is my way of shaping the industry in a way. I feel it’s extremely important.

You may laugh about some of the ideas or think they are trivial. That’s fine — let me know what you do and don’t like! You may also be lost in a sea of acronyms and content. This is why I make sure to recommend additional books you can read that explain the topics well.

I see all of this as a step-up for instructional capital around vulnerability assessments. I want to give everyone a chance to improve their skillsets, techniques, as well as toolchains.

Part 1: Information assurance vulnerability assessment — Network Access Control

This post is not about NAC, the common technology you may all be familiar with or studying/researching. The Cisco version of NAC is a poor concept. The endpoint security work in the IETF by Juniper Networks and the Microsoft work (or StillSecure and anybody else) is also a complete waste of time. This industry and these products are dead and or dying. So let’s just skip Cisco NAC and concentrate on the real topic: access controls in networks.

Is anyone here familiar with VLAN’s? How about VACL’s? What about Cisco’s new access control layer in the network? This is more along the lines of what I’m talking about. However, I don’t want to get into protecting the network infrastructure (that’s next week).

Recommendation: There is a concept, which is really more of a dream that I have. In the spirit of Martin Luther King Jr. (who was born on this day, 79 years ago) — I am going to get my favorite industry to believe in this dream. To believe in a network that has no traffic except SSL, GPG, and SSH (or any of the other secure channel technologies talked about on Day 5). Every packet that flies over the WiFi, the Ethernet, and between servers is all wrapped in happy encryption. All ports are closed unless they speak SSL.

But wait — what about DNS? Surely, DNS must be used for the local Intranet — to get to local servers and printers, and to get to an SSL VPN or automatically-configured SSL proxy (so that packets can go to/from the global Internet). But Internet-aware DNS can be restricted internally, so that only the SSL proxy has access to the Internet. This keeps people from tunneling SSH in DNS or other strange network affairs.

All other services besides some Intranet DNS, a little printer port access, and SSL can be completely shut down and shut off. We don’t need it anymore. This is 2008, not 1998. Certainly, there will be exceptions at some companies or organizations — but these can be monitored with compensating controls. Even Intranet servers and printers should technically be behind an “Intranet proxy” which works in a similar way as the Internet SSL proxy. All traffic can thus be wrapped in SSL, so that printers can be accessed via HTTP (although it would be nice if they supported SSL natively). The Intranet proxy could then whitelist scripts coming from the Internet to prevent cross-site printing or other unwanted script execution.

Better - the SSL proxies can be configured with concepts from ClientVA and Whitetrash. All client-side applications that access the Internet not only are passively verified for their version numbers (also don’t see: NAC scanning which actively verifies by scanning), but they are additionally only allowed to certain URI’s via a whitelist.

I’m not really big on Windows or Apple file sharing for distributed clients. iSCSI might be ok on a server backend network, but these sorts of protocols don’t belong on a safe network regardless of how they are encrypted. I’m mostly referring to SMB, which is safe to turn off in 2008. We have Intranet wiki software that allows flies to be uploaded instead.

Intranet web servers that do allow file uploads/downloads should have the presence of web shells or malicious Javascript detected. Some network-IPS devices do block some web shells or malicious Javascript content, but this is hit or miss. It’s best to run a utility such as SpyBye locally, or utilize a commercial tool such as Nessus or PVS to detect malicious Javascript. While on the server, documents can also be scanned for versions by using Metagoofil or OfficeCat.

Also, ideally all user clients would be thin clients — but this is possibly a dream for a different day.

Part 2: Software assurance vulnerability assessment — Stored XSS

Best Stored-XSS attack tools

w3af, HTMangLe, Hackvertor (or anything Gareth Heyes writes), PostInterceptor, Tamper Data, Burp Suite, Paros, OWASP WebScarab, XSSscan.py, Acunetix XSS Scanner, Syhunt Sandcat Free, Wapiti, OWASP CAL9000, Wfuzz, SPIKEproxy, Gamja, screamingCSS

Best XSS attack helper tools
Web Developer, RSnake’s Security Bookmarklet methodToggle, .mario’s Encoding tools, Dean Edwards’ Packer, JSMin, RSnake’s XSS Cheat Sheet, OWASP SWFIntruder, HackVertor (and everything else Gareth Heyes writes), HTMangLe, ExtendedScanner, Hunting Security Bugs’ Reference for ASP.NET Control Encoding and Web Text Converer, WhiteAcid’s XSS Assistant, Net-Force Tools’ NF-Tools, Hunting Security Bugs’ Overlong UTF, RefControl, User Agent Switcher, ProxMon, OWASP Pantera, AppPrint, AppCodeScan, FindBugs, FxCop, Pixy (for PHP), Milk (for Java), SWAAT (for ASP, JSP, PHP), ASP-Auditor (for ASP.NET), XSSDetect (for .NET), Mod-Security, PHP-IDS, CORE GRASP, Inspekt, RATS, PSA3, PFF, PHP-SAT, PHPSecAudit, Orizon, LAPSE

Unlike black-box testing Reflected-XSS, it is highly recommended that every time that you change a parameter or POST a form — that each test string be unique. Know which tool you used and where in the application your vector was initially sent. Stored-XSS can pop up anywhere throughout the web application much in the same way that a fuzzer can crash a fat application by sending a sequence of strings. This is the reason why humans are needed and manual testing must be done to expose all flaws.

However, I am highly impressed with the accuracy and methods used when doing manual code review for finding XSS. There are plenty of SQL injection and XSS that can only be found by looking through the source code. Often, either finding the source code through information disclosure or other means (identifying an open-source application or component is the easiest/obvious way) will allow finding the most obscure of stored-XSS vulnerabilities.
Day 6: ITSM Vulnerability Assessment techniques

Posted: January 14th, 2008, 7:12pm CST by dre

Tags: Hacking [edit]
Lesson 6: Last week was great as I started out talking about a variety of topics including –
- Day 1 — Physical network segmentation / Browser tools
- Day 2 — Kernel protection in network drivers / Crawling tools
- Day 3 — Sandboxing / HTTP tools
- Day 4 — Web application defenses / SQL injection tools
- Day 5 — Secure channels / Reflected-XSS attack tools
Over the weekend I spent some time playing with some of my favorite tools. I learned a few things about them. For the browser tools, I installed the SecurityQA Toolbar, written by Tim Newsham. It has a restricted evaluation, which is an IE BHO. The evaluation is very restricted, but I’m sure that the full-copy from iSecPartners works amazing just based on what I’ve seen from the interface. Not only is it limited in the types of attacks one can do (no blind SQL injection, XML injection, OS command injection, XSS/CSRF/HRS testing, no directory traversal, and no ActiveX testing — but all of these look to be available in the full commercial product. There is only one attack vector for even the attacks that do work (and you can see the ones for the attack vectors that are grayed out). The reports and the wizard are fantastic — certainly a browser-based tool that has a future.

Firebug Lite is one of my favorite external browser tools that works with browsers. However, I found out a method to use Firebug with IE using bookmarklets. Besides just Internet Explorer, I also found some useful tools for Opera, such as the Opera developer tools, as well as Firefox crawling using spider.xpi. I also learned a few other things that I’ll save for later. Also, I’m leaving out a separate “Part 2″ section today because I’ve already given you some new software assurance tools to check out. We’ll cover Stored-XSS tomorrow!

Information assurance vulnerability assessment — “Technology X over IP”

TCP/IP used to be a fascinating protocol because you could run it both on and off the Internet. When I first got into TCP/IP, friends and I would run local networks that did not connect to the Internet. By, this I mean that there was no firewall. DEC hadn’t even invented the TCP/IP firewall until at least a year or two after I got online. We ran a local LAN using TCP/IP and even had our own DNS… e.g. domain.lan or domain.local. This worked really well.

Once Network Address Translation became popular, local LAN’s based on TCP/IP went away. So did DECnet, AppleTalk, Novell IPX/SPX, and OSI. Everything became connected to the Internet, and Intranets became something you had internally but thought were safe behind a firewall. I knew right away that these networks were not safe, as the most powerful attacks and backdoors I had seen at that time were all based on the client-side (IRC grok, ssh client backdoors, etc).

Circa 1995-1996, I was already much aware of using ptrace(2) in a way that a reverse engineer would use UHooker today. Yet, I was also playing with the first IP telephony systems using Dialogic boards (similar to the Digium PRI and FXO/FXS PCI cards) under Solaris x86 and connecting them to ISDN (both PRI and BRI), POTS, and T1 CAS — even as trunks to other IPBX’s (e.g. MiTel) at the time. With Asterisk, Trixbox, and ShoreTel — we now refer to these as IP-PBX’s, but it’s the same acronym. Before I got bored of ISP access engineering (this was around 1997-1998 when Internet data centers started popping up all over the country), I also got to play a little with SS7 and setting up IMT trunks on Cisco AS5300’s and Lucent Portmaster 4’s.

On my mind the entire time was why on earth would any telecommunications provider want to connect this stuff to the Internet? It’s one thing to keep your SS7-connected Portmasters out-of-band for management access and allow dial-up users to be on the modems for said devices. But it’s another huge issue to allow integration of RIPv1 (and years later, RIPv2 to provide CIDR support), RADIUS, DNS, DHCP, and all the other features (I think I even ran BGP-4 on a Portmaster) available at that time. Nobody ever changed the paradigm… the devices worked and they didn’t suffer a lot of security problems (none that I knew about at least).

Today, telecommunications fraud is huge… growing by at least 10% per year. In 2003, a survey conducted by the Communications Fraud Control Association put the losses at $35 to $40 billion dollars per year. This puts 2008 at over $60B in telecom fraud losses at the most generous level.

We are facing a new scenario today. Some of the most complex modern applications happens to be those based on voice and video communications, as well as the popular web applications we already spoke about. Network drivers, even Bluetooth, WiFi, and IRda are dangerous because of their scope but not necessarily their complexity. Microsoft models the design of these types of network drivers using SAL (their Standard Annotation Language) and also provides a lot of software verification with tools such as SLAM (a model-checker). Many IP communications and web applications do not get the benefit of formal methods testing.

I recently saw the season finale for the TV show, “Hero”, where a prominent Cisco IP Video Communications web interface was utilized in the show instead of the classic Hollywood security surveillance room. I think they even used it in one of those Vegas shows. The first thing I thought of is what a bad idea it would be to use this sort of system. Combining internal communications system and web applications on the Internet is asking for the worst kind of trouble. See also: SCADA.

Asterisk alone had suffered two of the most popular types of web application attacks last year. The first one I already mentioned in my post Ajax security opens up a whole new can of worms, where I mention Wade Alcorn’s work on XSS Interprotocol Exploitation. This start with an XSS that allows a buffer overflow to be passed through the client-side browser to an Asterisk server. Even more recently, Asterisk-Addons allowed a SQL injection to run remote commands.

Recommendation: Test your VoIP (and Video-over-IP systems if you have them) and maintain strict vulnerability management over these sorts of cross-technology converging worlds. In my opinion, MITRE OVAL isn’t enough — although integrating these concepts into OVAL-Compatible solutions would be a good start. Use reconnaissance, footprinting, and enumeration tools such as iWar (a VoIP-enabled war dialer to bring you back to the 1983 WarGames era). Also utilize full-knowledge to gain access to known 800/WATS and DID numbers. Check PBX or IP-PBX configurations for correct DID assignments.

I’ve mentioned before that while WiFi has WVE, it doesn’t have a software weakness enumeration program. Voice and video/surveillence communications systems should also have their own CWE-like programs. Peter Thermos and Ari Takanen created these sorts of CAPEC and CWE models for VoIP in their book on, “Securing VoIP Networks”. They call these the VoIP threat and VoIP vulnerability categories, respectively — and even compare the VoIP vulnerability categories to both CWE and OWASP Top Ten. Using these along with binary analysis is a good place to start to define where systems are weakest and require testing, as per my usual recommendation.

The guys over at Learn Security Online have some great content. One of my favorites was submitted by a user named Sandro Gauci last month, where he demonstrates how to use SIPVicious to “get the job done” (login required — get their free registration!). It’s definitely a must read when thinking about penetration-testing or VoIP systems.

I also recommend additional reading such as the “Securing VoIP Networks” book mentioned above and the “Hacking Exposed VoIP” (of which the author’s blogs are great reads if you can find them). There’s also a recent SANS paper by David Persky available in their Reading Room - VoIP Issues.

Sorry about the lack of a Part 2, Software assurance section today. I promise waiting one more day for a better Stored-XSS post will be worth it.
Day 5: ITSM Vulnerability Assessment techniques

Posted: January 11th, 2008, 2:47pm CST by dre

Tags: Hacking [edit]

Lesson 5: After the first week, many of these assessment techniques don’t all fit together or seem congruent. Mid next-week, I think a lot of these pieces will start to come together to form a big picture. The recommendations I’ve given so far are not things I’ve seen or heard from the community of security professionals. Many people are asking for examples, but my question is — what exactly do you want to delve into? If anything, I would rather spend my time introducing the concepts so that you can explore the details for yourself.

Part 1: Information assurance vulnerability assessment — Secure channels

There has been constant debate about how to create a secure channel over a network, especially say, the global Internet. The two leading systems are SSL and DNSSEC.

SSL has had various problems over the years, but it’s the top dog. DNSSEC will likely never become popular, and the complexity behind it rivals IPSec. SSL VPN has all but replaced IPSec today as well. SSH is in use but isn’t seen as a consumer-level technology, not even with SSHTerm / Ajaxterm. Other abominations such as SNMPv3, S-BGP, and Kerberos-enabled protocols, encrypted IMAP/POP3, et al — these are bound to be around and unpopular for another ten to twenty years.

Off-topic and unrelated, yet on my mind as I write this: I can’t believe that people still use TFTP for router/firewall images and configurations. I’m sorry did I say, “people still use”? I meant, “vendors left implemented for over 13-14 years because that’s how long SSH and SSL have been around for”.

Drive-by-pharming, which involves using CSRF (possibly aided by XSS or other attack vector) to modify Intranet/home routers and firewalls, often changes the router DNS servers. DNS hijacking in this way could create a situation where browser rootkits are always installed on Intranet users’ browsers universally. RSnake’s Using DNS to enable XSS and the subsequently linked LURHQ paper are must reads.

Similarly, DNS cache poisoning can cause the same effect. ARP cache poisoning, ditto. We’ve seen BIND 9 exploits and ARP spoofing malware throughout 2007. The only interesting defenses in the research community have also ended up in failure, as seen by the PRIV8 SCM Firefox Add-on. It appears that this research has been duplicated by OpenDNS and DNSstuff, as I recently read in this article from Dark Reading on Hacking a New DNS Attack.

Sure, there are issues with Firefox add-ons (which I knew about the first time I installed an extension). I love how every security professional thinks their research is new when they apply an old concept (e.g. arp cache poisoning) with a bleeding-edge technology (e.g. Firefox add-ons).

Recommendation: There were plenty of exploits available for both Microsoft’s DNS server and ISC BIND last year. Do you want to repeat the same mistakes and headaches this year? Consider alternatives, or push vendors to provide reliable DNS server software that has high assurance properties. CoDoNS is an interesting research project that needs more attention and support.

Every book worth it’s weight on network security and system administration has a section on DNS server security. Go read that section now. I also suggest reading Domain Contamination from Amit Klein.

Monitor your DNS servers. I also suggest monitoring external DNS and co-operating with other organizations to form a strong passive DNS infrastructure for replication. Recently, source code was released for dnslogger-forward in order to create sensors for this purpose.

As for SSL, I’m getting quite upset about what once was a great technology. I mean, what good is it when browsers have serious problems that remain unfixed for years? Please be sure to read heise Security’s article on Bugs in Mozilla browsers facilitate man-in-the-middle attacks. Try out the test page that they link to and see the problem for yourself.

Certificates are a nuisance and all of this is being wrapped up under the umbrellas of liability and Certificate Authority god-complexes. Sure, SSL works today and DNSSEC doesn’t, but I’m pretty sure both are wrong and we’ll see the demise of both over time. If anyone besides myself thinks that Enigform and mod_auth_openpgp are the future of secure HTTP channels, please holler.

For more information, you would think I’d recommend DNS & BIND, but it turns out that one of the authors is a spammer (yes, Cricket Liu is an evil, bad spammer — how’s that for irony?) and BIND software just plain sucks. Instead, I suggest you read “The dotCrime Manifesto”, by Phillip Hallam-Baker.

Part 2: Software assurance vulnerability assessment — Reflected XSS

Best Reflected-XSS scanning tools

XSSscan.py, XSS-Me, HttpBee, Acunetix XSS Scanner, Syhunt Sandcat, w3af, Wapiti, OWASP CAL9000, Wfuzz, Grabber, SPIKEproxy, WebFuzz, Gamja, Burp Intruder, Burp Repeater, Paros, OWASP WebScarab, screamingCSS, gunzip webfuzzer, N-Stealth Scanner Free Edition

I’ll cover Stored-XSS, DOM-based XSS, and XSS attack helper tools next week! I will go into more detail about finding XSS once more techniques/tools are suggested. Here’s a few suggested tools to play with over the weekend.

I don’t usually repeat tools if they aren’t particularly interesting for helping individual attacks. However, you’ll want to go back and review how Reflected-XSS can be found using HTTP request tampering tools or browser-based tools. In the case of Reflected-XSS, these can be found in both parameters and forms, as well as in binaries (UXSS), emails, images, QuickTime/Flash and other media files, and pretty much just about everywhere.

Rational Survivability

How To Say "Whoops! We Need To Rethink Our Train System's Control Plane" In Polish...

Posted: January 11th, 2008, 1:44pm CST by beaker

Tags: Hacking [edit]

My dear friend Murray (sorry if that expression of warmth comes as a surprise, Murr...) sent me this story from the Register:
Polish teen derails tram after hacking train network
A Polish teenager allegedly turned the tram system in the city of Lodz into his own personal train set, triggering chaos and derailing four vehicles in the process. Twelve people were injured in one of the incidents.

The 14-year-old modified a TV remote control so that it could be used to change track points, The Telegraph reports. Local police said the youngster trespassed in tram depots to gather information needed to build the device. The teenager told police that he modified track setting for a prank.

"He studied the trams and the tracks for a long time and then built a device that looked like a TV remote control and used it to manoeuvre the trams and the tracks," said Miroslaw Micor, a spokesman for Lodz police.

"He had converted the television control into a device capable of controlling all the junctions on the line and wrote in the pages of a school exercise book where the best junctions were to move trams around and what signals to change.

"He treated it like any other schoolboy might a giant train set, but it was lucky nobody was killed. Four trams were derailed, and others had to make emergency stops that left passengers hurt. He clearly did not think about the consequences of his actions," Micor added.

Transport command and control systems are commonly designed by engineers with little exposure or knowledge about security using commodity electronics and a little native wit. The apparent ease with which Lodz's tram network was hacked, even by these low standards, is still a bit of an eye opener.

Problems with the signalling system on Lodz's tram network became apparent on Tuesday when a driver attempting to steer his vehicle to the right was involuntarily taken to the left. As a result the rear wagon of the train jumped the rails and collided with another passing tram. Transport staff immediately suspected outside interference.

The youth, described by his teachers as an electronics buff and exemplary student, faces charges at a special juvenile court of endangering public safety. ®
Yes, yes. I know, it's not a SCADA system...as fun as that would be to bring up again, I don't need any death threats, so I won't mention it...directly. But if you read about the recent security design debacle of the Boeing 787 Dreamliner and then look at this, it doesn't take much of a logic jump to see why we should be worried about how command/control systems are implemented.

My next piece of chicanery is to steal one of Mogull's Wii Guitar Hero controllers, hack it, and cause it to electrocute his cat every time he hits C# on Stairway to Heaven...

/Hoff

tssci security

Day 4: ITSM Vulnerability Assessment techniques

Posted: January 10th, 2008, 3:45pm CST by dre

Tags: Hacking [edit]

Lesson 4: We’ve touched on some of the critical-path ways to assess and protect your infrastructure including network segmentation and OS/application sandboxing. Often, the weakest area of technology is what you can’t segment or sandbox effectively, which today is why we will be covering web applications.

Part 1: Information assurance vulnerability assessment — Web applications

With all the various web applications across any given infrastructure, it’s difficult to know where to start. Consolidation of web servers isn’t an easy task — the thought there is that somehow you could put all of your web applications behind a giant web application firewall such as mod-security in reverse proxy mode.

The questions arise, which is more helpful to balance the risk of our web applications — web application firewalls, enforcing use of secure frameworks / secure configurations, or secure inspection? Is it some combination of the three? Is there a one-size-fits-all solution?

The answer varies, dependent on what web applications you have. If you have a large mix of PHP, ASP.NET, ASP classic, Java/JSP/JEE, Ruby on Rails, ColdFusion, and Zope/Django/TurboGears/Pylons/Python then it’s obviously hard to know where to start. HTML/CSS/XHTML, XML/XSL(DTD)/XSLT, Javascript, Actionscript, VBScript/VBA, ActiveX, Flash, and Java Applets just complicate this further. It’s very common to also house large amounts of CGI written in Perl, Tcl, Python, Unix shell, C/C++, Visual Basic, Applescript and several other languages you’ve probably never heard of.

There are many more books written on scaling Enterprise applications with .NET and JEE, but just how popular are these in comparison to PHP, ASP classic, or ColdFusion? According to the The State of Web Development 2006/2007, web applications are developed in order of popularity: PHP, Classic ASP, ASP.NET 2.0, ASP.NET 1.1, Static HTML, Java/JSP, Perl, ColdFusion, Ruby, and Python. Also interesting is the use of point-technologies such as Flash, Javascript libraries, and Ajax (also in order of popularity).

Of the above, the most secure are likely Static HTML, Java/JSP, and ASP.NET 2.0. PHP and Classic ASP require quite a lot of work to secure, so it may be best to concentrate on these technologies first, in addition to watching out for Flash, JS, and Ajax gotchas.

Recommendation: Install Hardened-PHP wherever possible, and front your PHP applications with CORE GRASP and PHP-IDS. Move applications that require medium or high assurance to a framework such as HDIV, which requires JEE developers (however, can be used with SpringMVC, Struts2, or Struts1 — in my order of preference). Utilize Anti-XSS libraries to bring all legacy .NET and Java code up to par if HDIV or the latest .NET frameworks cannot be used.

You’ll detect a repeatable pattern here when I give a recommendation of how to begin the secure inspection of any application. Start with bytecode or binary analysis and then determine where the applications are most weak. In the case of Classic ASP, utilize tools such as OWASP DN_BOFinder. Java/JEE bytecode-testing is best handled with FindBugs. .NET applications can be tested with FxCop and dotnetids. Bytecodes and binaries can be sent to Veracode for further inspection.

PHP applications usually have source code available, especially since most are of the open-source, off-the-shelf variety. I recently read an excellent post on using PSA3 (one of the best open-source web application tools available) and PHPSecAudit to identify web application vulnerabilities in PHP source code. Beyond these tools, also take a look at the Php Fuzzing Framework (PFF) — and make your custom functions stand the test under the stress of the PHP interpreter. Commercial scanners such as Chorizo-Scanner also include advanced server-side testing with the Morcilla PHP extension, although you might learn more using CORE GRASP and PHP-IDS during a dynamic/hybrid assessment.

Flash, Javascript libraries, Ajax, RIA’s, Java applets, and ActiveX components also need to be evaluated for security purposes. Fortunately, there are many open-source tools that simplify this process. Consider taking a look at my older post on 2007 Security testing tools in review, or the ones on Crawling or Ajax security. Specialty applications such as forums, CMS’s, Wiki’s, and blogs sometimes have their own scanning tools (e.g. I know of ones for phpBB, WordPress, and Joomla).

Also be sure to keep an eye on configuration files. Bryan Sullivan has written a few great articles on securing configuration of web applications in a part one and two of a series, in addition to earlier work on .NET configuration files. There is more information available on secure web application configurations in the “Web Application Hacker’s Handbook”, the “Developers Guide to Web Application Security”, and the latest Apache Cookbook, 2nd Edition.

Part 2: Software assurance vulnerability assessment — SQL Injection

I was going to make today’s part two lesson about XSS, but decided to change it to SQLi when I saw that 70k websites were owned via an automated botnet attack in the past two days.

Best SQL injection attack tools

SQL Inject-Me, SQL Power Injection Firefox Plugin, sqlmap, sqlninja, SQL Brute, sts-scanner, w3af, Wapiti, HttpBee, OWASP SQLiX, SQL Power Injector standalone, MSSQLScan, Paros, Burp Suite, OWASP WebScarab, ISR-sqlget, Scully, FG-Injector, PRIAMOS, Grabber, Bobcat, Watchfire Exploiter, Syhunt Sandcat, gunzip webfuzzer, mieliekoek.pl, wpoison

Best SQL injection attack helper tools
Absinthe, squeeza, SQL Hooker, HackBar, PMD SQL Injection Rules, SQL injection cheat sheets, ExtendedScanner, AppPrint, AppCodeScan, FindBugs, FxCop, RATS, SWAAT, Pixy, Milk, PSA3, PFF, PHPSecAudit, Inspekt, PHP-SAT, Orizon, LAPSE, PQL, SPIKEproxy, ASP-Auditor, PHP-IDS, dotnetids, CORE GRASP, Mod-Security

If you want to check out these tools in order, that is the preferred way to learning. There are quite a lot of tools mentioned here, and quite a lot utilize very different testing methods. Some testing tools such as HttpBee can be distributed, while many others are command line tools. My favorite black-box tools are usually the browser-based tools such as sqlime, sqlpowerinjector.xpi, and HackBar — but there are many good command line tools such as sqlmap and sqlninja.

More often than not, securing the database and access controls are just as important as making sure that all source code uses parameterized queries if you want to prevent these kinds of attacks. Using declarative controls along with an RBAC system can lower the attack surface. Making sure that command shells and out-of-band channels (RDBMS use of DNS, SNMP, et al) are locked-down should also be top-priority.

I’ve worked with developers who think that they don’t need to use parameterized queries on internal infrastructure. However, because of Web services (SOAP, RPC) and second-order injection (plus other ways to get closer/inside the database) — it should be realized that all queries need to use prepared statements. Packages such as DBMS_ASSERT from Oracle and Mod-Security from Breach claim protection against SQLi — however, they are not panaceas and should be checked for what they do and don’t protect against.
Day 3: ITSM Vulnerability Assessment techniques

Posted: January 9th, 2008, 10:22am CST by dre

Tags: Hacking [edit]

Lesson 3: After the first few days, we’ve covered securing WiFi, as well as basic software assurance tools to get you started with a web browser and crawler. This is just the beginning.

Part 1: Information assurance vulnerability assessment — Sandboxing insecure defaults and unnecessary services

Sandboxing is often referred to by many things, such as exploitation countermeasures, trusted paths, secure attention keys, and chroot jails (OS-level virtualization). Ruby on Rails, Java, and the .NET CLR provde virtual machines very similar in effect to OS-level virtualization, but at the application-level.

It is unfortunate that many operating systems include quite a lot of services, applications, and functionality that isn’t required or properly sandboxed from other applications. There are also basic issues such as updating OS and applications while scanning networks for known vulnerabilities (widely described as vulnerability management).

Laying out kernel options, as well as disks mount options at build/install time are two major ways of sandboxing applications. One of my favorite ways to reduce the attack surface to Linux is the versatile GRSecurity. GRSecurity must be compiled into the Linux kernel. It allow Low/Medium/High security settings.

In the low setting, GRSecurity improves a few things, including race conditions on temporary directories, as well as improving chroot sandboxing. Medium security places restrictions on all sorts of insecure defaults, as well as improving chroot even further. The high security feature of GRSec is the most advanced, and includes PaX code. PaX is an implementation of ASLR. Some programs are broken because they require executable memory addresses, but PaX can be controlled with the `paxctl’ command line utility.

If you’re not familiar with GRSecurity, but have used SELinux — then you might be familiar with access control concepts, such as the differences between discretionary and mandatory controls. GRSecurity controls role-based access controls (RBAC) using the `gradm’ command line utility. SELinux can turn a discretionary system into a mandatory access control system (MAC), hardened by domain and type enforcement. We’ll cover access control, sometimes referred to as authorization, much more in later posts.

Windows does have equivalents for these — at least if you’re using Windows XP SP2 or Window Server 2003. Other versions of Windows may support these concepts a bit differently. Instead of changing mount points, Windows cannot do much here — but temporary file directories can be encrypted and the paging file can be cleared on shutdown. Access controls can be locked down further with CORE Force (a strong firewall and access control system from CORE Security).

Other operating systems have some equivalents, such as the BSD/MacOSX ports of systrace. There even exists SEBSD and SEDarwin projects that implement stronger access controls in similar ways as SELinux. Spending a few hours on a hardening guide when you install your OS can be extremely worthwhile in the long-run. This improves security exponentially when you’re using a install server and standard images.

Recommendation: Deciding when and how to sandbox which applications should be based on measurements from past vulnerability management experiences. Using Nessus and patch management (e.g. OVAL-Compatible solutions from MITRE) will give you this information over time. I recommend a system to track vulnerability management reports such as Inprotect or Simpleness.

CVE, NVD, OVAL, and OSVDB information can also lead you to discovering potential places you would like to sandbox more functionality or find out more about these vulnerabilities. Applications seen as “at risk” can be handled by binary analysis to determine areas needed for secure inspection. Instead of using only bugreport and IDA/HexRays/BinDiff/ImmDbg — I suggest moving highly critical (or high at risk) applications to a CWE-Compatible full-solution service such as Veracode. As the CWE-Compatible program expands to include CWE-Effective, medium-risk applications can move to the standard program while high-risk applications can move to the more effective solutions.

Running Nessus + Nikto, as well as using the CIS benchmarking solutions can augment measuring the success of a vulnerability management program. They can help you find out if you’re missing a critical sandbox (or just need to tweak the configuration a bit), or have not hardened your standard images (and maybe not in a standard way). Combine with various hardening guides, found all over the Internet.

For more information via books, however, you could also read, “Network Security Hacks, Second Edition” from O’Reilly Press, “The Craft of System Security”, or any of the various books on SELinux.

As a final note: whatever you do, make sure you get a safe channel/sandbox for your patch management delivery system. Which is why these tools need review such as OVAL, and probably multiple, third-party review (or first-party review through one of three CWE-Effective/Compatible solutions such as Veracode). Good application risk analysis also goes a long way.

Part 2: Software assurance vulnerability assessment — HTTP

Since we already mentioned Nikto today in the information assurance section of this post, I might as well introduce all of the good tools for learning HTTP. If you thought using your browser as your primary security tool was over, it has only begun. There are various great tools, and most of the best ones are available as an add-on.

Best HTTP request tampering tools

Tamper Data, Burp Proxy, Paros, OWASP WebScarab, Hunting Security Bugs’ “Companion Content” Web Proxy Editor, OWASP Pantera, w3af, curl

Best HTTP request tampering helper tools
metoscan, Syhunt Sandcat, N-Stealth Scanner Free Edition

You also may want to check out RFC 2616 and 2617, in addition to others you may come across (ie. the HTTP specifications). There is also an httpbis Working Group within the IETF and possibly even with some detectable activity.

It should be said that parameter (GET) and form-based (POST) tampering is 98% of web application security testing. All of the other vulnerabilities/attacks come from one of these two. Ever want to learn the difference between HTTP Splitting and HTTP Smuggling? Well, you best understand HTTP GET and POST attacks, including at the very least, concepts of header injection and knowledge of ASCII characters.
Day 2: ITSM Vulnerability Assessment techniques

Posted: January 8th, 2008, 10:16am CST by dre

Tags: Hacking [edit]

Lesson 2: We hope that you are enjoying the format of these, as well as the content. Yesterday, I talked about how rogue AP’s/clients can be scanned for without adding infrastructure or spending active time walking around the office. I also introduced software assurance tools, including most of the popular and best browser-based tools. Browser-based tools can really get you started with learning how to approach testing for web application vulnerabilities — whether or not you plan on using code inspection or a purely black-box approach.

Part 1: Information assurance vulnerability assessment — Kernel protection, network drivers

Once when I was performing a full network vulnerability assessment, the client asked me, “What is the worst that can happen from a WiFi attack?”. We talked about how easy it was to break WEP and WPA, and I mentioned how this could be done using Rainbowtables, as well as using injections to speed up the traffic (or that small packet traffic such as ARP could easily be predicted) including a discussion about OpenCiphers’ use of relatively cheap hardware to perform NSA-grade attacks.

However, this was not the end of the discussion. I then spoke about how some WiFi drivers have had problems, including the FreeBSD 802.11 Management Frame Integer Overflow vulnerability, discovered by Karl Janmar. I made the assumption that many WiFi drivers could be vulnerable to remote root upon boot.

One of the best initial ways to perform a vulnerability assessment on unknown code such as WiFi drivers is to utilize binary analysis. These sorts of rough tests can provide information that is not normally available. Using tools such as GDB, IDA Pro, OllyDbg, and ImmDbg isn’t available for system drivers at runtime, so other tools such as KGDB, SoftIce, RR0D, and WinDbg must be used instead. Some tools such as bugreport might also be able to be used, assuming you can also have objdump produce a disassembly. Just poking around can produce a lot of useful information on where to start with other kinds of vulnerability assessments, such as using CAPEC to model attack-paths or moving to other techniques such as reverse engineering, static analysis, and dynamic analysis.

Other software such as BinDiff can be extremely useful to identify areas of code in binaries that change over time. Particular useful is to utilize BinDiff and IDA/HexRays to identify weaknesses in WiFi drivers after a patch to a vulnerability is released. Fuzzers aren’t usually specific to WiFi, although there is at least one 802.11 fuzzer. The vulnerability research community has mostly adopted scapy for this purpose. I suggest also checking out file2air and UTScapy.

WiFi drivers present a unique problem for vulnerability research. Their closed-source is often a contention point, especially from the OpenBSD camp. Great projects such as WVE produce content on wireless vulnerabilities. However, because of the complexity and importance that these drivers maintain the highest assurance levels — I firmly believe that we need more. I would like to see both a CAPEC-specific wireless attack-path classification (similar to WASC TC), as well as a WiFi driver weakness program similar to CWE or OWASP T10-2007. This should be driven by the vendor community, who should provide open standards for pen-testing AP’s and drivers.

Theo de Raadt has been a proponent of both open drivers and open documentation. Clearly, both open documentation and source code would allow at least some third-party selective review. Vendors of all WiFi software/hardware should also open their documentation, hardware, and software for third-party selective review. If you are a big client to one of these vendors, please push them to these ends. In order to prove the need, consider fuzzing before purchase.

Recommendation: Use hardened WPA2 to protect your WiFi clients. WPA2-Enterprise is simply too complex for most needs — consider using HostAP with per-MAC WPA2-Personal PSK’s, or other AP that provides such support. Make sure to make the SSID and PSK for every AP/client as random and long as possible. Regularly scan Windows WiFi clients using WiFiDEnum from Aruba Networks. For further information, please check out the books, “WarDriving and Wireless Penetration Testing” (especially the last section on Device Driver Auditing), and “Hacking Exposed Wireless” (by Johnny Cache and Vinnie Liu).

Part 2: Software assurance vulnerability assessment — Crawlers and spiders

Best HTTP crawlers

Burp Spider, Paros, OWASP WebScarab, w3af, larbin / FEAR::API, Heritrix, wget, curl, Offline Explorer Pro

Best Javascript/DOM link crawlers
Burp Spider, w3af, scanajax, urlgrep, sts-scanner, CSpider, Syhunt Sandcat

Best Ajax crawlers
OWASP Sprajax, scanajax, w3af, Ruby mechanize, crawl-ajax (RBNarcissus), crawl-ajax (Watir), FireWatir, scRUBYt, Syhunt Sandcat

There’s not much more to say about crawling, as I’ve already said it a million times. These should get you started. Again, the order is important. If you’ve never crawled an application using Burp Spider, today is your lucky day.

Some of these tools such as FEAR::API, Ruby mechanize, RBNarcissus, Watir (including offshoots like FireWatir, Watij, and Watin), and scRUBYt may require some knowledge of programming, although if you read my past posts — there are many links to get you started. Other tools such as curl provide libraries in several languages (libcurl for C, PHP-CURL, et al) that are also usually worth checking out.

Even if you’re only interested in static analysis (which we’ll get to next week), application understanding that comes from how a crawler works on a website is important knowledge.
Day 1: ITSM Vulnerability Assessment techniques

Posted: January 7th, 2008, 2:37pm CST by dre

Tags: Hacking [edit]

Lesson 1: These techniques are in two-parts, 1) Information assurance strategies, and 2) Software assurance tools. My feeling is that vulnerability assessments are typically done less strategically/operationally in IT environments (relying too much on tools and point-and-click scanners), while not hands-on enough for IT dev shops (or unknown where to start).

Part 1: Information assurance vulnerability assessment — Network segmentation, Physical

This is a bottom-up strategic approach using the OSI model. Start with Layer-1 and move up to the application layer. Physical security is extremely important. Host all computers at a data center and utilize thin clients locally, if possible.

How about the network? Keep network ports off by default and check/verify structured cabling. The largest problem here would be rogue AP’s or other WiFi-related security problems. WEP is worst of these, but WPA-Personal can also present problems with weak passphrases. This time last year, TJX had a data breach that started with an attack on WEP.

However, RF is all around and available in many devices. Not only will rogue AP’s present a physical layer network segmentation problem, but clients will as well. Clients are devices such as PDA’s, PDA phones, and also anything with both a radio and software. Other technologies such as copper wire, lasers, and infrared can also carry network traffic across segmented networks via the physical layer.

Scanning for all of these devices is not easy. Using Kismet and BTScan, even with advanced tools such as WiSpy — it can be impossible to perform such scanning at all times. There aren’t enough good vulnerability assessment tools for brute-forcing passwords along with scanning, and this activity takes even more time. When was the last time you made sure that BTScan was checking for unsafe OBEX passwords?

Recommendation: Vendors (secure AP vendors especially) should provide AP’s that present false AP information, for WiFi, Bluetooth, IRda, and possibly other common RF technologies. They should present a captive portal stating that connecting to this AP is against corporate policy, and that they are being monitored while administration has been contacted. Integration with SIEM is ideal to backup these claims.

If your WiFi vendor solution could also scan employee devices, this should detect rogue clients (e.g. Blackberrys, iPhones, Windows Mobile devices, etc). Again, integration with SIEM technology is an ideal way of notifying a possible breach. Checking to see if packets can loop between network types is a great way of detecting rogue AP’s and clients, but be careful how it’s implemented. All network traffic can be locally queued and/or blocked.

When a vendor can’t provide a solution, you may want to roll-your-own. I suggest Soekris boards, CM9 miniPCI cards, and Pyramid Linux.

I’ll talk more about the software-side of assessing radios on Day 2. If you’d like more information, please check out the books, “Blackjacking” by Daniel Hoffman, and the infamous, “Wi-Foo” and “Hacking Exposed: Cisco Networks” by the Arhunt team.

Part 2: Software assurance vulnerability assessment — Browsers and extensions

Best browser tools

bookmarklets, Firefox’s Tools->Page Info (with View Cookies), Nikhil’s Web Development Helper, Cooxie, Web Developer, FireBug, Microsoft Script Debugger, DOM Inspector, InspectThis, Cert Viewer Plus, HOOK, FlashTracer, XPath Checker, XPather, View Source Chart, viewformattedsource, UrlParams, IE Developer Toolbar, HttpWatch Basic, TamperIE, Tamper Data, Modify Headers, LiveHttpHeaders, Header Monitor, PrefBar, Technika, Fiddler, FireBug Lite, JS Commander, VBScript, Applescript, about:config

bookmarklets are the best browser tools because they are cross-browser, cross-OS, and multi-attack-functional. I use them in IE7, Firefox 2, and Opera 9.

I listed most of the other tools in a sort of important order. Feel free to explore them in this order. Some are Firefox only, and some are IE only. Some are external browser tools but had to be listed regardless (e.g. Fiddler, FireBug Lite, and JS Commander). I’ve listed VBScript and Applescript because they can be used to control the browser. In my past blog posts on Why crawling doesn’t matter, I talked about similar ways of “driving the browser” and called these “browser-drivers”.

I am not going to spend any time in the near-future on the internals of bookmarklets or browser add-ons, although I may touch on some of these other tools more when it comes to specific attacks. The point of this is to introduce you to tools which you may have not used or heard of. I would really like to leave you with further information on bookmarklets, so here are a few links to RSnake’s, Awardspace, and Squarefree. Some of my favorites are: Find Redirects, Show JS Vars, generated source, view cookies, netcraft, Alexa, http headers, and Edit Cookies. I have taken the code from Ajax Security in order to compose a “HOOK-lite” for Javascript function monitoring.

var ret = ""; for(var i in window) { if(typeof(window[i]) == 'function') { ret += i + " | "; } } alert(ret);

You can paste the above into Technika and click “Run”. Technika requires Firebug and Firefox.
Cross-site scripts are the cockroaches of the Internet

Posted: December 18th, 2007, 8:14am CST by dre

Tags: Hacking [edit]

I made an epic post to the LSO forums a few minutes ago. I felt the need to re-post a portion of it here. While meeting Joe earlier this evening, who is one of the founders of LearnSecurityOnline, I was inspired to think and write about XSS and a variety of other web application security anecdotes. I guess pizza+beer (thanks, Joe!), a trip to Borders, and coffee really help with my writing technique.

XSS can live in everything — the HTTP requests/responses, the HTML, the stylesheets, Webmail, RSS feeds, “Design-mode” HTML editors, Javascript, Actionscript, VBScript, Flash files, images, PDF’s (even without a browser!), QuickTime files, the DOM, XmlHttpRequests, XML data from Web services or in JSON, unexposed Ajax functions that Firebug can’t even see, offline Ajax applications, inside databases, attached to cookies, in logfiles, cached content in proxies, cached content on your disk, in your browser bar (i.e. bookmarklets), and inside of your Javascript Engine in your browser, lying dormant — waiting for just the right moment to jump out, scare the living shit out of you (assuming an alert box), and attack.

Cross-site scripts are like the cockroaches of the Internet.

The best way to get rid of XSS is just to simply “get rid” of it. Find the root-cause of the problem and squash it. This is best done as developer Fagan inspection, whether during requirements analysis (early), design review (too late), programming phase (way too late), or build-time aka “integration” (fucking ridiculously late).

If a QA professional, a security professional, or an unwanted adversary has to spend any cycles on XSS — guess what? They’re going to find some! The statistics say that XSS is present in 90% of websites. This is because only the top 10% of websites know anything about software assurance. They simply “squashed” XSS because they “had to” (or because the developers are smart aka “not lazy”). Did you know that basically every commercial web application security scanning company has had XSS exposed in their website at some point? Now you do!

Do the right thing and don’t test for XSS. Don’t even bother. Just grab the source code and start inspecting for “oh it looks like XSS is possible here — back to the drawing board!”.

Don’t test — but do ask the question, “Hey, do you guys know that your site is vulnerable to XSS?“.

The only correct answer is “Yes, but we’ve put Fagan inspection processes in place to prevent damage to our reputation/brand, our customers, and have implemented precautions such as NoScript and LocalRodeo to prevent submarine-XSS attacks against our IT administrators and key personnel within our organization. The potential XSS variants that exist in our applications are all undergoing regression testing and have been protected with the best we have in modern day WAF technology such as the commercial Fortify Defender, Imperva SecureSphere, and/or the open-source equivalents CORE GRASP, PHP-IDS, and dotnetids”.

Any other answer means, “No, and we have no idea how to deal with that!”. Go directly to Remediation — Do not press the back button; Do not collect 200 OK’s.
Ajax Security opens up a whole new can of worms

Posted: December 17th, 2007, 9:42am CST by dre

Tags: Hacking [edit]
Update on the TS/SCI Security Blog

First of all, I would like to announce that I will be retiring the long, diluted threads that have recently appeared on the TS/SCI Security Blog. This is the last of the “longer” threads I’ve been saving up for our readers before I embark on a new journey.

What should you expect? Well, I’ve decided to start a blogging theme called “A Day-In-The-Life of an Enterprise Security Team”. This theme will consist of 20 short posts, all pertaining to what I see as the future of Enterprise-class Information Security Management teams. The posts will demonstrate how they should conduct their strategic, operational, and tactical security measures. The primary focus will be defense (hardening, protections) and security testing (penetration-testing, inspections, audits).

These new posts will be available over the course of the next few weeks, possibly bleeding into the new year. Be sure to tune in as we uncover the latest in defense/testing trends! I know that Marcin is working on a few upcoming posts as well, which will hopefully be staggered throughout the “Day-In-The-Life” theme.

For this post, I’m excited to talk about the Ajax Security book by Billy Hoffman and Bryan Sullivan. The last blog post, Collaborative Systems and Ajax/RIA Security uncovered some of the highlights of the book, but here are my last words and review before moving on to bigger and better things.

Ajax Security: What was good

The book, Ajax Security, covered a lot of new material that hadn’t been seen or talked about in the press or the security industry. The authors introduced Ajax security topics with ease and provided greater understanding of how to view Javascript malware, tricks, and the aberrant Javascript worms from a security perspective.

Here are some of the “new” concepts that I enjoyed most:
- Hijacking Ajax apps
Covered a great deal of material about how both Ajax frameworks and on-demand Javascript cannot hide or obfuscate their internal functionality. Some code to the tool, HOOK, was made available in one of the chapters. I was able to test and verify that it works as prescribed. The tool basically monitors new Javascript functions as they are “lazy-loaded” (see the last blog post for more information on “lazy-loading”) with Javascript’s use of browser interactivity.
- Attacking Offline Ajax apps
Normally Ajax is worried about client-side code being changed (i.e. function clobbering) by hijacking Ajax apps as described above. The solution is to reduce trust of client-side problem domain logic before it is brought back to the server-side. If input is taken, it should always be processed through a whitelist filter (with an additional blacklist to prevent specific-attacks) before being executed server-side or passed on to another internal service. If client-side problem domain logic is expected to follow a certain path of execution, the end result of such flow execution should match expectations. The server-side should therefore provide the input validation to support expectation-matching. Client-side validation can be easily bypassed by changing the control flow execution (that’s what an in-browser debugger such as Firebug can do when the code is easily available for viewing and editing).

In the case of offline application the reverse is true. Using a tool such as GGHOOK (written to steal offline data created by the offline Ajax application framework, Google Gears), the local database objects are available to whatever code is resident in the Javascript Engine. Injecting SQL queries to pull data back to the Internet (and send it to a place you are certain to not want it to go) is one easy way to access this offline data and defeat the integrity of the application.

In order to prevent this access and subsequent querying of local objects, client-side code in the Ajax problem domain logic must be validated for input. So, basically the reverse is now true for offline applications! Instead of server-side input validation - a client-side validation is necessary to keep data safe.
- Ajax proxy exposure of third-party XML/JSON data
Ajax relies on XHR’s (XmlHttpRequests) to send data back and forth between client-server, but also server-server transactions. This is very useful when information is not purposefully published via a Web Service such as SOAP or REST. The server-to-server XHR traffic can be used to send XML or JSON data between third-parties that expose their API’s to the public (or semi-privately).

Ajax proxies therefore allow creation of “mashups”. The third-party provides access to its data/API via another hosted site. Mashup access for clients is now hosted by the web application of the first-party site to the third-party site, where the first-party acts as a “go-between”. Often, the third-party also acts as a first-party to other sites — and sometimes regular clients as well (but possibly restricted by the number of transactions per second or number of API calls a day).

A hostile client can attack this Ajax proxy infrastructure in a variety of ways — choosing to go direct to the third-party to attack the sites that re-host data/content/API-access or attack the third-party via the first-party site. Worst of all, “Aggregate Sites” will access all kinds of API’s and content (think: RSS) and bring it to one central location, usually a home portal such as iGoogle. Hostile clients can then attack any of the aggregated content before it gets to the home portal. The web becomes a serious of interconnected transitive trust relationships that can be exploited.

Best parts about the book

I really enjoyed the suggested defenses against “mashup” attacks as well as JSON API Hijacking. Without going into detail (I don’t want to ruin the book and the authors’ hard work), I can say that the explanations are not only better than mine — but that the imagination and creativity for optimal solutions were clearly first and foremost in the authors’ intentions. This is really where their good intentions shined.

The authors also did a great job in the first few chapters, as well as in two other chapters (”Request Origin” and “Worm” ones, specifically) exposing all of the intricacies of Ajax, HTTP, HTML, and XHR abuse issues. They showed that with great power comes great responsibility. The level of attack capability that HTTP/XHR can muster is scary indeed. Whether it’s a simple HTML IFrame or a complex XHR — the authors show both the good and evil sides of the equation.

It’s quite possible that many Star Wars Ajax security fans will be calling Billy Hoffman, the great “Obi-Wan”, and pdp “Lord Vader” to represent the “light” and “dark” sides that is The Force behind the power wielded by Ajax. Case in point is the IFrame, which is used to “jail” the aforementioned “mashup” Ajax technology.

What was missing [and we’ll hopefully see in a second edition!]

There was a lot missing, and I’m sure I can’t remember all of it right now. Let’s start with what I gathered from my last blog post, which covered Zimbra in rough detail.

Zimbra, GMail/GDocs, and many others have this “Design Mode” theme in common where the site allows you to edit HTML (usually mail) content inside the browser. Web spiders and crawlers have a difficult time replaying this data, so it is currently impossible for web application security scanners to test “Design Mode” portions of websites.

Web application security testing tools have these and other issues that are being worked out as the tools come into maturity. The authors didn’t provide solutions or even discuss these sorts of problems, although they did cover a lot of related “Presentation Layer” information. You definitely don’t want to miss out on what they have to say about attacking that layer! There hasn’t been a lot of research that I’ve seen, and some of the attacks seem incredibly daunting.

For example, caching content locally for browsers to access could be subverted (say, on a kiosk). The authors recommend “no-cache”, but I looked to the standards and there’s a bit more to it than they cover in the book. I’m working on a document that describes ways of handling this particular issue, but clearly more research will need to come about in this area. Hopefully more sites will be adding SSL and automatic HTTP redirect to SSL (which is another fix for the “Aggregate Sites” problem spoken to above).

New can of Javascript Worms opened!

Here comes the best part! I know that a lot of you are curious if the book covers Samy. Of course it does! The book also covers the less exciting but discussion-relevant Yammaner worm. I was very excited to read this chapter, but also afraid of some of the “dark side” prescriptions it gave.

However, it also leaves many of us in the dark about Javascript worms. I have seen and heard complaints about the weak, “low-priority” aspects of XSS. I have explained Rager’s xss-proxy concept and it falls flat on the weak attention span of most buffer-overflow obsessed pen-testers and vulnerability researchers. For the few brave enough to listen to me talk 5 minutes about XSS, you’ll eventually get the “XSS Tunneling” piece. Even fewer will get to realize the full-picture.

XSS is the root-cause of a few advanced attack vectors, and Ajax makes them turbo-speed. I discovered this on my own after viewing a disturbing video about XSS worms, and spoke up about it on the ha.ckers.org blog. It’s possible that I subconsciously read about the basics of this new attack vector from Wade Alcorn, who introduced a less complete concept a few months earlier. I also led a short discussion (that same week) about these techniques at the OWASP Chicago chapter meeting.

Wade Alcorn is the author of the browser exploitation framework (BeEF for short), an iteration of the xss-proxy code. If you know about “second-order” SQL Injection or “second-order” XSS (i.e. stored), then think of BeEF as “second-order” Javascript malware. In this announcement on the bindshell blog, Wade introduces the concepts of Inter-Protocol Communication (IPC) and Inter-Protocol Exploitation (IPE). In the IPE paper, an example exploit that attacks an Asterisk server from what begins as a simple XSS is the crux of this extremely innovative research.

Clearly, Wade put two and two together to come up with this meta-level concept. Before announcing his Inter-protocol Exploitation and Communication papers, Wade had announced a vulnerability in the Asterisk server two years earlier. Combine BeEF with Metasploit, and you have yourself a nice hole through any firewall. Even before RSnake, hackathology, and dk of BlogSecurity/MichaelDaw picked up on the Inter-protocol topic, there was already early discussion on RSnake’s blog related to JS Spam and IMAP+XSS. Even earlier work had been done (much of it is now called OS Command Injection, MX Injection, SMTP Injection, Mail Command Injection — all really the same thing) labeled as the HTML Form Protocol Attack and Extended version.

Two weeks after I envisioned the “new Web worm vector”, Wade made The Register for an article on “Worms 2.0!”. I wouldn’t be surprised if he was the author behind the Find, Exploit, & Cure XSS w0rms video on milw0rm that inspired my delayed vision. Earlier that same month, two exploits were released for the Yahoo messenger: one for the Webcam Viewer and the other for its Uploader. The XSS w0rms video demonstrated an attack against Meebo, where all meebo users could have their YIM (or AIM, MSN, etc) buddies enumerated and attacked via an XSS worm. Combine these concepts and the attack effectively crosses the Fourth Wall from a XSS-based web application worm to a shellcode-based “fat applications” worm.

Other interesting Javascript worm attack vectors include Exponential XSS, including a more popular subset known as “Cross Webmail Worms”. This is no surprise given that webmail is most likely to be untested due to “Design Mode” issues. A proof-of-concept of a XWW (cross webmail worm) called Nduja connection claimed the ability to propagate between separate webmail providers, but work in a similar way as Yammaner.

I found it odd and surprising that many of these attack vectors were not discussed in the Ajax Security book, especially in the chapter on Javascript worms. Maybe the popularity and interest in web application worms has died down. One of the best resources on web application worms (outside of the links already provided) is to read the bulk of posts by pdp on the GNUCITIZEN blog.

pdp even uses some of Billy Hoffman’s code, showing exactly how “Good Javascript” can become “Javascript Malware” by simply re-purposing it. The authors of Ajax Security demonstrate this concept in great detail in the book. I’m curious as to what will happen with the release of HOOK. Will the ultimate hack for Javascript de-obfuscation and function monitoring also enable new Javascript malware strains or novel attack vectors? Probably not, but I’m sure it will lead to exciting new research in such a blossoming field. What’s next for Javascript and the web application Rich Internet Application frameworks such as Ajax? I guess we’ll soon find out!
Collaborative systems and Ajax/RIA security

Posted: December 13th, 2007, 5:34am CST by dre

Tags: Hacking [edit]

Office collaboration services look like 1985

Microsoft Outlook and Exchange server have been the staple for office collaboration for over 10 years, with a model that has been around since Novell and Lotus in the mid-80’s. Collaboration services are clunky, bloaty, and every IT administrator and techie hates both of them with a serious passion. Outlook Web Access… — never mind, I’m not even going to finish this sentence. When people say that Microsoft stifles innovation this is exactly what they are talking about. I don’t mean to pick on Microsoft — because Apple, IBM Lotus Notes, and the open-source community (no CTO is going to approve anything with `Squirrel’ in the name) have not stepped up to provide anything equivalent.

SaaS makes collaboration worse

Everyone and every organization does their mail, address-books, calendaring, time management, conference-room reservations, and public folder sharing a little different. Some people like to download everything from the server and save it locally. Others keep all their mail on the server. Some do both. Email retention and anti-spam are a big deal for a lot of Enterprises, so much that people even outsource these or all collaboration services.

Organizations are also moving their data more online, to Google Analytics, Salesforce, NetSuite, et al. Do you trust your CRM or ERP to a SaaS solution, even if you are a small business? Even if you do trust them, how are you going to integrate these solutions, especially with your Exchange server?

Google’s answer is their GApps, an integration of GPages, GMail, GTalk/Chat, GDocs, and all their GAPI’s. Have you heard of an SMB or Enterprise that has moved their collaborative efforts to GApps? My guess is that not many have.

I’ve seen many businesses struggle with SaaS and outsourcing of collaboration services. When considering outsourcing, a normal strategy is to look at moving 20 to 40 percent of non-core business services to managed services. Groupware should be considered a core business service/need in a large majority of cases, as it really drives the day-to-day business and contains much of the documented and hidden processes that occur inside any organization.

It’s almost 2008. Stop using Exchange server already

Enter Zimbra’s Collaborative Suite (ZCS) — a groupware server with Outlook compatibility that was recently purchased by Yahoo for $345M. Zimbra has been around for at least 2.5 years, so that fact that you haven’t heard of them is strange. Even Mike Rothman daily debates switching over everything to Zimbra, but his worry about costs shouldn’t scare you.

Zimbra’s ZCS Server runs on Linux (or Mac OS X). Linux can handle all of your Windows clients, file sharing, and printing with Samba, can run LTSP to PXE boot your environment into FreeNX/Windows-TS, and can cluster it all for free. I’ve done so using Ubuntu LTSP inside Xen guests on CentOS along with keepalived. The architecture becomes lightweight if you have a 5U chassis (and cold, empty standby) with 24 spindles and 8 TB of hardware RAID-1 running CentOS and IET. Then you have two powerful 1U or 2U machines running CentOS with cman/fencing, clvmd, and iSCSI-initiators mounting filesystems as OCFS2. Xen guests are booted from the shared storage. For an example without shared storage, see clustering Zimbra from Ben Rockwood.

Compare the above reference architecture to Exchange. You’ll need NLB for everything except Exchange clustering, which requires MCS because of MS SQL Server. To get anywhere near the equivalent of the above, you’ll want VirtualIron or VMWare ESX Server. The enormous licensing costs are building in my head as I think it through. There is no way to do this with shared storage, and this is a heavyweight solution with lots of overhead.

The differences in clients are very similarly disparate — Zimbra is lightweight and Exchange/Outlook is not. There are a few other solutions such as OpenGroupware+ZideLook or DeskNow that provide similar Outlook compatibility as Zimbra. They have support for the DAV’s, iCalendar, and other good groupware features. Zimbra, however is especially unique in many ways.

Zimbra on Ajax security

The benefits and drawbacks to using Ajax are summarized very well in a ComputerWorld article by Paul Krill. Scott Dietzen, president and CTO of Zimbra, elaborated very well to both points in this excellent article. He says that he favors Ajax to Flash, and Ajax frameworks to Flex2. I would say that any RIA framework is capable of providing these sorts of services, but Ajax has been around the longest.

The interesting part is when Dietzen talks about Ajax security:

Dietzen did cite AJAX security issues such as cross-site scripting attacks, in which user data can get interpreted in the browser, creating a breach. Also noted as a security concern was use of source code in the browser.

[ … ]

Blocking execution of user JavaScript inside of an application is important for combating server-side scripting attacks, according to Dietzen. Obfuscation and minimization technologies to remove white space can be used as security measures, he said. On the positive side, there is no caching of user data on the desktop with AJAX. Dietzen also advised that sensitive code not be put in a browser.

With the recent release of the book, Ajax Security, by Billy Hoffman and Bryan Sullivan — hopefully Ajax developers and CTO’s such as Dietzen will be able to be armed with the best resources for protecting their applications and userbase.

Collaborative systems need Web services support

Zimbra has support for SOAP, REST, and JSON, but certainly Web services will also need to be provided securely. I couldn’t even imagine how great it would be to combine my collaborative Office tools with my collaborative personal research. If I could even import/export betwen my Google Reader RSS feeds and my Office feeds (using OPML), that would be extremely useful. Web services take this sort of technology to the next level.

It would be great to combine XMethods and mashups into your groupware system for a number of reasons. This level of customization is going to be a driver for innovation in groupware products. I’d like to see some of best mashups done with Enterprise data and shared as groupware. ChicagoCrime and HousingMaps are great, but we can do many more interesting things in the Enteprise.

The security of Web services and Ajax gateways/proxies for building mashups comes into question here. The commercial version of SOAPSonar only costs around seven-hundred dollars, and supports XSD-Mutation, and automated vulnerability assessment/detection. There are plenty of open-source tools for testing web services, such as those mentioned in my post on 2007 Security Testing tools in review. If well tested, Zimbra (and others like it) will be able to provide mashups along with Web services support, and do so securely. JSON is also vulnerable to API hijacking, and the Ajax Security book provides interesting solutions to its defense that you absolutely have to check out.

Collaborative systems need offline applications support

Exchange has beat out many open-source groupware services because of the requirement for supporting offline applications. Users cite issues such as travel and intermittent Internet connectivity, while others simply prefer working both offline and on. Zimbra has amazing offline application support, here are some quotes from the ComputerWorld article:

“The answer for occasionally connected apps is to provide a cache on the client side that allows the application to interact locally with a data set, and then synchronize over the network when the network is available,” said Dietzen.

Offline AJAX systems can be developed by using a set of caching APIs in JavaScript that enable this. These are accessible via offerings such as Google Gears and the Dojo offline tool kit.

[ … ]

But Zimbra used another approach. “What we did at Zimbra is we actually took Zimbra server code, which was written in Java, and we created a microserver that runs on my local client,” said Dietzen.

Zimbra also has a great PDF presentation called Ajax Unplugged, where they compare their Zimbra Desktop offline technology, including Zimlets, to Adobe Apollo, Dojo.Offline, Joyent Slingshot, and Mozilla’s Firefox 3 Offline support and XULRunner. The Ajax Security book dedicates an entire chapter, but only details Google Gears and Dojo.Offline, while minimally mentioning WHATWG (FF3 work), Joyent Slingshot, and Adobe Apollo. I’m also partially surprised that there was no mention of Zimbra, who has chosen to build their own solution.

However, Billy and Bryan’s coverage of the attack surface for Ajax offline applications is no joke. Apparently, Billy Hoffman plans to release a new tool to take advantage of some of these attacks against Google Gears in a tool called GGHOOK. GGHOOK is based on another tool called HOOK (covered in an earlier chapter on Ajax function hijacking) — both of which will be released on his website shortly. The biggest take from the book’s chapter on offline applications is how client-side input validation has become relevant again. The sad part is that the Ajax frameworks aren’t providing a lot in the way of client-side input validation for this purpose.

One of the largest problems for a system like Zimbra is XSS for the client-side data stores. We all know that XSS is capable of stealing cookies and controlling the browser, but imagine the damage it would be able to do in this scenario, especially as wormable. Thankfully, ZCS Server is a local solution and doesn’t even have to be Internet accessible, which would minimize some of the damage from this theoretical attack. In the case of Google Gears, all of the data can be stolen using GGHOOK, which locates the Google Gears database object and queries the local SQLite tables. Ajax security testing will also be important to solve these sorts of issues.

Zimbra innovations

Besides providing Web services into the Zimbra/Zimlets API, providing a feed reader, and taking Zimbra offline — they have also done some other notable things to increase collaboration.

Dietzen mentioned the AJAX technique of AJAX Linking and Embedding (ALE), in which one document can be embedded inside another. This expands content-sharing.

He also cited a technique called [ Lazy Loading ] which cuts down loading time for Web pages. With lazy loading, the page loads but other parts of the application, such as calendaring, are loaded only as needed.

Besides supporting various mail thick-clients, including Outlook and Apple Mail — Zimbra has their ZCS web client aka “clientless mode”. With the “lazy loading” support, this makes using Zimbra more powerful, faster, and cleaner than using a fat application client. However, it also exposes it to all of the web application and Ajax security problems.

Documents embedded in documents and HTML/JS embedded in HTML/JS are interesting concepts for web applications. The ALE specification provided by Zimbra is a good way of engineering this type of technology. Modern browsers have a concept known as “design mode” where the browser becomes the HTML editor.

Similarly, there’s design mode in GMail, GDocs, and other web applications you may be familiar with. It has been argued between web application security scanner vendors that if scanning Ajax is difficult — scanning “design mode” is nearly impossible. I’d like to see more specifications such as ALE come out, possibly as a standard. If so, testing Ajax-driven “design modes” could be much easier to automate.

Issues with Ajax security testing tools

Google has ways of automating their Ajax testing — they use distributed Selenium (using grid technology) and WebDriver in order to accomplish these tasks. For commercial solutions, I like froglogic’s Squish for Web more than PushToTest or HP Mercury Interactive’s QTP — but all of these are viable Ajax testing solutions. Combining security-driven fault-injection tests into these data-driven frameworks is currently the best way to test for Ajax security issues.

For theory, your best current bet is to read the Ajax Security book. The authors fail to mention tools that test Ajax. Well, they mention their own commercial scanner (nice, guys!) and one other open-source tool. I haven’t mentioned it before, avoiding it as a topic for several reasons — not even on my post about Why crawling doesn’t matter. Billy and Bryan are quick to point out that the tool not only requires MS SQL Server, but also that the tool only tests the Microsoft ASP.NET AJAX framework (possible future support of GWT is mentioned). Here’s a link to it anyways, as maybe the attacks in it are worth re-purposing — the OWASP Sprajax Project.

The future of Ajax security testing tools is ripe for both the Technika Security Framework and the future-work in the w3af scanning tool, as each will be well-balanced browser-drivers. Until such a time, we are stuck with either quality testing tools (which lack the vulnerability and attack data), commercial web application security scanners (which lack critical testing capabilities), and less than a handful of open-source tools such as the Blueinfy tools, OWASP Interceptor tool, and w3af’s DOM-based XSS module.

The largest issue that I see with Ajax security testing is the lack of secure static analysis techniques and tools. JSLint and DeHydra could be starting places for work in this area. The recently released commercial tool, Fortify SCA 5.0, just added some support for secure static analysis of Javascript/Ajax issues, but this is largely limited to XSS, Javascript function hijacking, and JSON API Hijacking (which was discovered by Fortify).

Ajax isn’t the only security problem

The issues presented in this post are only scratching the surface of the overall problem. It appears that people who already place active attention into Ajax security issues are failing to follow-through with coverage of all the theories — let alone running code. For example, Zimbra may understand XSS and Javascript obfuscation. HP SPI Dynamics and Fortify may support minimal Ajax testing for security issues. The real problems begin when we combine Web services, offline applications, and “design mode” HTML/JS editors. This becomes especially compounded with multiple Ajax and RIA frameworks.

Other logical security-related issues and design flaws will creep out. Using Firebug, it is incredibly easy to control the execution flow of Javascript-based applications. Ajax improves performance and speed, so surely timing and side-channel attacks will become relevant. Since Javascript is embedded in HTML/CSS content and browsers — affecting the “presentation” of applications is a major attack vector that we will need to supply a lot of attention to.

Yesterday, I spent a little while playing with Dust-Me Selectors, a Firefox extension mentioned in the Ajax Security book for testing for unused CSS rules. It has a “Run automatically” mode that I tried out, which demonstrated the power of CSS data mining. Javascript on-demand hijacking (or framework hijacking) involve problems with leaking information about Javascript functions. In a similar way, CSS data mining involves problems with leakage of CSS content resources.

I’ve also mentioned Flash and other RIA frameworks in the past, but I don’t want to go too much in-depth in this post. Hopefully, I’ve opened up your mind to a few of the problems with modern applications and testing them for security.

My Security Planet » Tags » Hacking

Feeds

21 items tagged "Hacking"

Posted: March 18th, 2009, 6:35pm CDT by dre

Tags: Hacking [edit]

Posted: September 23rd, 2008, 9:52pm CDT by dre

Tags: Hacking [edit]

Posted: June 15th, 2008, 8:02am CDT by dre

Tags: Hacking [edit]

Posted: March 17th, 2008, 11:14pm CDT by dre

Tags: Hacking [edit]

Posted: March 7th, 2008, 11:34am CST by Marcin

Tags: Hacking [edit]

Posted: February 5th, 2008, 4:35pm CST by dre

Tags: Hacking [edit]

Posted: January 23rd, 2008, 1:06am CST by dre

Tags: Hacking [edit]

Posted: January 20th, 2008, 3:37pm CST by Marcin

Tags: Hacking [edit]

Posted: January 17th, 2008, 9:28pm CST by dre

Tags: Hacking [edit]

Posted: January 16th, 2008, 1:05pm CST by dre

Tags: Hacking [edit]

Posted: January 15th, 2008, 7:03pm CST by dre

Tags: Hacking [edit]

Posted: January 14th, 2008, 7:12pm CST by dre

Tags: Hacking [edit]

Posted: January 11th, 2008, 2:47pm CST by dre

Tags: Hacking [edit]

Posted: January 11th, 2008, 1:44pm CST by beaker

Tags: Hacking [edit]

Posted: January 10th, 2008, 3:45pm CST by dre

Tags: Hacking [edit]

Posted: January 9th, 2008, 10:22am CST by dre

Tags: Hacking [edit]

Posted: January 8th, 2008, 10:16am CST by dre

Tags: Hacking [edit]

Posted: January 7th, 2008, 2:37pm CST by dre

Tags: Hacking [edit]

Posted: December 18th, 2007, 8:14am CST by dre

Tags: Hacking [edit]

Posted: December 17th, 2007, 9:42am CST by dre

Tags: Hacking [edit]

Posted: December 13th, 2007, 5:34am CST by dre

Tags: Hacking [edit]