Day 8: ITSM Vulnerability Assessment techniques
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.
This is valuable info.
> 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).
Not just DOM-based XSS, even reflected and stored, especially in Web 2.0 applications. The scanners just don’t understand the technology well enough. And this message has to be evangelized loudly because right now the loudest people in the room are the scanner marketing companies.
Just yesterday we ran one of the big named automated scanners against a client’s Backbase application with at least 30% of the input fields being vulnerable to XSS and we got kaput from the scanner due to the Ajaxy nature of the app.
> Best DOM-based XSS attack tools
> Web Developer’s View Javascript, FireBug, w3af, Burp Intruder,
> scanajax, ProxMon, OWASP Pantera, cruiser, CSpider.js
You certainly suggest a lot of tools, and in a dream world we’d be able to utilize all of them. Unfortunately, assessment times are usually scoped fairly tight, internally or externally. I don’t think many people would be able to use a lot of these tools and still get maximum coverage in other areas like authentication, access control, etc. What can you say about prioritizing toolsets in a real world assessment?
I said the same thing myself once when I talked with dre about that. A lot of it comes down to how much time you have spent with each tool and how good are you with it. The more time you spend, the quicker it becomes to use, and then just naturally, it becomes a part of your toolset.
Not to mention, some tools have overlapping areas of functionality.
@ Arshan:
You certainly suggest a lot of tools, and in a dream world we’d be able to utilize all of them. Unfortunately, assessment times are usually scoped fairly tight, internally or externally.
I don’t think people should be using all these tools. I’m recommending some based on an order of preference. This ordered list is mostly for learning what the tools are capable of for assessment work.
In the case of doing a vulnerability assessment on a large web application — I could point you towards a world full of resources. It’s not just tools, but I happen to be talking about those here.
As I said in the first post of this thread, “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)”.
Short answer: personally, if speed is important; I would use JSView and FireBug for DOM-based XSS findings if source code wasn’t available. If it was, I’d use Fortify SCA and a combination of open-source and commercial tools that would be largely language dependent (Milk, LAPSE, Orizon, PMD, FindBugs, jCUTE for Java; PSA3, PhpSecAudit, Inspekt, Pixy, PHP-SAT, PFF for PHP; ASP-Auditor, XSS-Detect, PREsharp, FxCop, Compuware SecurityChecker for .NET; DN_BOFinder, PREfast, PREfix, AppVerif, CUTE, Compuware SecurityChecker for Classic ASP; plus RATS, SWAAT, AppPrint, AppCodeScan, AppScan DE, and DevInspect for most languages).
I know that’s not a short answer, but wait until you see the long answer, below.
I don’t think many people would be able to use a lot of these tools and still get maximum coverage in other areas like authentication, access control, etc. What can you say about prioritizing toolsets in a real world assessment?
When testing a large application, I would use my CPSL methodology, if at all possible.
The recommended toolsets have an equal priority (unless they are CWE-Effective or CWE-Compatible). AFAIK, I recommend 5 kinds of tools
1) A requirements analysis tool such as IBM Rational Requisite Pro or the free tool from NASA SATC’s ARM
2) Secure design inspection tools that work with UML 2.0, such as IBM Rational Rose or better Klocwork K7. There is also an open-source tool called Fujaba that can be used to move between UML and Java source code
3) A CWE-Compatible static analysis tool. Right now, only Veracode would fit into this category (so, clearly, they would be prioritized first), but aspiring CWE-Compatible tools such as Armorize, Klocwork K7, GrammaTech CodeSonar, Ounce Labs, and Fortify SCA would fit into this category. Milk/Orizon/LAPSE/PMD/FindBugs or ASP-Auditor/XSS-Detect/SWAAT/PREsharp/FxCop could be FOSS replacements for the above as long as CWE is customized into the tools
4) Manual secure code review with a workflow tool such as Atlassian Crucible, although Trac could be a FOSS alternative
5) Final verification with another CWE-Compatible tool that is capable of fuzzing/fault-injection for integration testing. No tools are currently CWE-Compatible and allow for integration testing (however I would like to see this change). The best tools are FOSS tools such as CUTE, Canoo WebTest, or Windmill that would be modified to support CWE and CAPEC testing. Alternatives in the commercial world include AppScan DE or DevInspect — although these are difficult to automate for continuous integration when they are built into the IDE — and they also integrate less well with unit testing. One of the more interesting tools that I’ve come across lately for this purpose is UTScapy (although built more for protocol dissection and packet mangling than for web application testing, although still valid for modern application testing)
My views on vulnerability assessments are quite different, as you can see. The rest of the methodology outside of the tools is also important. There are a few enhancements that I’m working on to the CPSL process, such as integrating ideas from OWASP ESAPI as well as work I’ve done on the OWASP Web Security Certification Framework.
The most important section of the CPSL methodology is the continuous-prevention part, where reusable unit tests that assert the behavior of known security-related bugs are used at build-time. It’s like regression testing, but better.
I think you’ve got good advice here, and it needs to be read in a particular way by developers who are integrating security into their daily life. My advice would be to start slow, and work up to the complex stuff.
Get and install WebScarab, then after a while get something plugged into ypur IDE, then really by that time they will start to realize what they need from this list of resources. I’d be careful to not overwhelm them.
I’m glad you are looking at ESAPI, because that is a CSO’s dream and there aren’t enough people using it.
@ Arshan:
Nah. Developers don’t need to know anything to make this sort of thing happen. All they need to know is that they wrote a bug and it’s considered an error. And that they should be writing unit tests that assert for that particular bug’s behavior. Once you teach them these things — the rest will be self-taught or easily preached.
In other words, I wouldn’t go slow. I wouldn’t wait to have Ounce or Fortify SCA as part of the system integration nightly builds. I wouldn’t wait to mark at least the top twenty or so vulnerabilities that apply to any one project as errors.
I also wouldn’t wait to get Fagan inspection working throughout the development culture of any organization. Then I’d combine Klocwork K7 along with MITRE CAPEC and CWE know-how for any given moderator of any given project.
WebScarab? I never even mentioned that. Giving WebScarab to a developer or quality engineer is a complete waste of time and money. Even WebGoat is a waste, in my personal opinion.
Developers need to learn how they already learn. You can’t throw any of this stuff at them. You integrate it silently; and when they start complaining — you throw in the idea of a reward system for programmers who can write good, reusable unit tests to find software weaknesses. For the programmers that continually make the same security mistakes over and over — it’s best to penalize/punish them until they can get up to par with the rest of the team.
If putting Armorize, Fortify SCA, or Ounce into the build server or integration process is overwhelming developers, then turn down the sensitivity. While I agree that requirements and UML aren’t required/necessary for every project — they should certainly take up 10% of the time and budget of any project — and security should be a part of that process, especially looking at criteria such as MITRE CAPEC, attack-modeling, and Application Architectural Risk Analysis.
The most difficult part of my CPSL is the verification of fuzzing/fault-injection tools that are run during integration, but I provide ways of making this easier. Some of these might run very clean assuming how these compare to the continuous-prevention unit tests that the developers have used throughout the process. It’s up to everyone to make improvements; not just the CSO and his/her team.