Day 6: ITSM Vulnerability Assessment techniques
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.blog comments powered by Disqus