Day 11: ITSM Vulnerability Assessment techniques
Lesson 11: Welcome back! I know that the last few weeks have been a lull, and even before ShmooCon there wasn't a lot going on our security blog. However, you're in for a real treat since I'm back with the daily ITSM Vulnerability Assessment techniques!
It's no longer Spring break (well it is Spring break in most places this week), and I've done my fair share of partying over the past two weeks. I even passed out once (as opposed to blacked-out), something I wasn't aware that could happen to me in my 30's. But now it's time for writing and to get back into the swing of things.
If you're not already aware of the The New School of Information Security, please start there. If I'm going to be making recommendations on assessments or vulnerability research, I am certainly going to take the New School even more into account from now on. It's just the way we do things around here, and now that's it's formalized a bit -- we can proceed to some even better process-oriented approaches to managing risk with vulnerability assessment solutions.
Part I: Information assurance vulnerability assessment — Protecting the infrastructure
If you're reading this, then chances are good that you are connected to the Internet. Right now this very second, this blog or anything in between this blog and you is at risk from either side attacking either side. It's all at risk and should be protected.
This includes your Apple laptop and 802.11G Access point. This includes Marcin's web server and Wordpress installation (note: 2.5 is on the way!). But it also includes everything else in between. In stranger situations, it may also include your entire Google profile if you have this blog post cached via Google Reader. Now it's not just everything between your browser and our web application, but also everything in Google's infrastructure.
Should I say something about firewalls? Both network firewalls (including ones that see into applications) and web application firewalls are thought to protect this infrastructure, but in reality -- they are part of this infrastructure. How do you protect a firewall? With another firewall? With an IPS? How do you protect the IPS?
As a network engineer, I had many people over the years try to explain to me the concept of fiber miles and the speed of light problem outside of a vacuum. Yes, it's true that between the distance of Marcin's web server and my laptop (as I type this), there is a degree of latency caused by the speed of light problem. It's probably a few milliseconds (about 3 or 4 ms). Yet, if I send ICMP echo requests and get back responses, I'll see a round-trip time of 60-80 ms! If I use TCP to traceroute, it's the same or worse! What causes this?
Latency is caused by the performance hit required by processing packets (I'm not going to go into OEO conversions versus "all optical", but that's worth a look for the discerning reader), usually at the software level. Cisco and many other network vendors will claim that hardware acceleration will improve this (and in the case of TCAM driven IPFIB/MAC tables, it sometimes does a little), but the reality of the situation is that the latency increase is still in the software. Something has to drive every ASIC, every IC, and every FPGA.
Risk to our infrastructure is also imposed by software. There is no magical hardware device that can make your router or firewall more secure. The only thing protecting your access-point, router, firewall, IPS, or any other device is the software that runs on it -- and the often "burned-in" configuration. By reducing the number of devices, we not only increase performance -- but we also reduce the risk to the firmware and configuration running on network devices in a path.
Recommendation: Discontinue the use of firewalls and IPS devices by retiring them. Remove appliances from the paths between your software and the networks and applications that your software needs access to.
Routers make excellent firewalls and often have better capabilities than firewalls or IPS devices. Classic LAN's and even pre-existing WiFi infrastructure should be re-thought completely. There is no reason for me to exist on the same IP subnetwork or broadcast/multicast MAC/LLC layer as anyone else for any reason.
It's also my opinion that a router should not be considered a router unless it can run the TCP/IP routing protocols fully and safely. In other words, every true "router" should be able to run BGP-4 and BGP4+ with IPv6 and IP multicast along with IPSec and SSL VPN. Pyramid Linux on embedded hardware usually fits this bill more nicely than a random piece (read: junk) of network hardware purchased at Best Buy or from CDW.
If you happen to be stuck with Cisco, Juniper Networks, or something worse such as Extreme Networks, Foundry Networks, Dell PowerEdge, or D-Link -- I suggest moving to Pyramid Linux or Vyatta or something similar. You'll of course ignore my logic here, so my additional suggestion is to open your manual and start crying. Configuring off-the-shelf routers, switches, and network appliances in order to reduce risk is a losing battle.
See if you can get your router or switch to operate in bridge-only mode, thus reducing it's footprint since it will lack an IP address. Barring that, protection of the control plane is the utmost concern. All transits (IP prefixes that send IP traffic between each other) and trunks (Ethernet link-layer or 802.1Q framed "virtual LAN" Ethernet that sends MAC traffic between each other) must be protected from the physical layer up. In other words, nobody should be able to pull the wire, replace with their own wire (or splice it), or Optical/Copper TEMPEST assess any wire. This applies doubly to wireless.
Network service providers started to have problems with DDoS as early on as April/May 1997. Before DDoS, most of the attacks were SYN-based or just unicast UDP or ICMP floods. The Smurf attack changed this by allowing for an amplification of ICMP due to a few factors. Distributed attacks became possible, and these concepts quickly spread to both TCP and UDP.
Worse, TCP amplification attacks targeted not only web servers, ftp servers, and other obvious well-known services, but also BGP routers. Smurf DDoS heavily used the ISP network infrastructure itself as well for the primary reason that "you can ping it".
A few years ago, I got the chance to attend a presentation at NANOG by Ryan McDowell of Sprint. Sprint changed the way that their network allowed traffic to/from/between their routers. I highly encourage you to check out that presentation material, Implications of Securing Router Infrastructure. Much of the information is Cisco-specific (but the concepts apply equally well to any platform). Cisco has recently updated and combined all of these resources to form their Cisco IOS Network Foundation Protection (NFP) program.
For those that want a summary of the above, "don't allow any packets directly to your infrastructure, including TCP, UDP, or ICMP from any IP protocol -- but allow all of those through -- and make sure traceroute still works". There are additional problems such as sending traffic to foreign agencies (on the "do-not-do-business with" lists which probably partially match the "do-not-fly" lists). Certain protocols and ports (such as those seen on the SANS ISC, handlers, and DShield websites) are also nearly universally blocked.
On the LAN, I think there is something to be said for Cisco's Dynamic Arp Inspection (DAI), especially when combined with endpoint port-security (set to one static, and in some cases where that is infeasible -- 1 static and 1 dynamic where the static is reset every so often by scripts followed or preceded by a physical inventory audit). I've heard claims about AirDefense and similar technology preventing WEP attacks, but be sure to remain skeptical about such approaches and test for yourself. DAI, port-security, and AirDefense are certainly cheap alternatives to upgrading the entire infrastructure to NAC or other endpoint security solution. Thin clients may also provide value when trying to reduce risk to large-installation local area networks.
For further information, be sure to check out LAN Switch Security: What Hackers Know About Your Switches, Router Security Strategies: Securing IP Network Traffic Planes, End-to-End Network Security: Defense-in-Depth, CCSP SNRS Quick Reference Sheets, and the MPLS VPN Security Cisco Press titles.
Part 2: Software assurance vulnerability assessment — Session management
Best Session management attack tools
Burp Sequencer, stompy, w3af, OWASP WebScarab, Paros, Add 'N Edit Cookies, CookieCuller, CookieSafe, CookieSwap, Cookie Watcher, RSnake's Security Bookmarklet Edit Cookies
Best Session management attack helper tools
NIST FIPS-140-2, Burp Suite, User Agent switcher, Torbutton, RefControl, Vidalia, Torify
Session management is one of the only runtime, blackbox testing techniques that really must be done following all unit testing, integration testing, and functional testing. In a secure SDLC for web applications -- the testing of session management is usually tested earliest during SQA acceptance testing. While it may be possible for developers to write some tests for token strength, etc -- session management is one unique area that exists outside of the realm for what I normally consider good security in the SDLC testing.
In other words, use and learn these tools to your heart's content! They are extremely valid and useful for real world testing, and provide a lot of opportunity to learn more effective exploratory testing, especially when you think about concepts such as time and state. How does my User agent affect my session ID? How does the time of day? How does the load on the application? It's a great scenario for learning about combinatorial explosions, which is the bread-and-butter of any advanced vulnerability assessment.
blog comments powered by Disqus