Posted by Tate Hansen
Sun, 24 Sep 2006 06:04:00 GMT
In a
recent post we talked about if it is possible to prioritize the deployment of solutions which are widely accepted to reduce risk to a business (without completing a threat assessment). A list you can say to someone "Well, without knowing your details I can say the most frequent threats or highest risks for
most companies is from
THESE THINGS, but we really should do a threat assessment first".
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=4fcfc1652464f1b60c02afecb75d332a
From 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
Tags breaches, ClearNet Security, security, Tate Hansen, threat assessment, virus statistics | 1 comment
Posted by Søren Maigaard
Fri, 22 Sep 2006 11:23:00 GMT
Overskrift
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.
1 comment
Posted by Tate Hansen
Tue, 19 Sep 2006 21:21:00 GMT
When competing for security assessment projects it is often painful for the customer to distinguish the level of service or effort between proposals. We used to respond to RFPs with the intention of satisfying all the services the customer is soliciting – of course in the end in nearly every case that isn’t what wins the bid.
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
Intermediate: 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
Intermediate: 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
Tags Audit, ClearNet Security, penetration test, scan, security, security assessments, Tate Hansen, vulnerability | no comments
Posted by Søren Maigaard
Mon, 18 Sep 2006 07:31:00 GMT
Cisco VPN group name and password
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 :)
Tags Cisco, ClearNet Security, Penetration Testing, Soren Maigaard, VPN | no comments
Posted by Tate Hansen
Thu, 14 Sep 2006 20:55:00 GMT
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?
Tags ClearNet Security, prioritize, risk equation, security, security tools, Tate Hansen | 7 comments
