Looks like Symantec have finally fixed some security issues I raised with them back in January 2012 for Symantec Message Filter 6.3.
It took them 6-months - so I am not impressed with their patching-cycle, or their focus on IT Security generally (this is supposed to be a security product after all).
Basically, as I described at BlackHat EU back in May 2012, this product-installer had versions of Tomcat and MySQL which were 7 years old, with default content and no patches (so the product had well-known third-party exploits right out of the box).
Additionally (which I felt I couldn't describe at the time, because it was 0-day) there were session-management and information-disclosure issues in the administrative UI, plus Cross Site Request Forgery (CSRF) of administrative-functions and XSS.
More detail is here:
http://www.symantec.com/security_response/securityupdates/detail.jsp?suid=20120626_00&fid=security_advisory&pvid=security_advisory&year=2012
The CVEs are:
CVE-2012-0300
CVE-2012-0301
CVE-2012-0302
CVE-2012-0303
Wednesday, 27 June 2012
Thursday, 21 June 2012
More on Exploiting Security Gateways
Here is a quick update on some of my exploit-development research into finding exploits in Security Gateways.
This is the video from my presentation at BlackHatEU 2012 back in May, which shows some typical examples of exploits I had found in the period from October 2011 to March 2012 (all of the issues in the demo videos have now been addressed).
If you are interested in the technical side, the white-paper that went with this presentation can be found here:
http://www.nccgroup.com/en/learning-research-centre/security-testing-audit-compliance-resources/white-papers/
Since then I have continued my research project, and to-date have found around 80 exploits (most of which are in Security Gateways, though I have also started to look at some other types of appliances as well). Fixes and updates have been released for at least 25 of these exploits so far, though the majority are still in the respective vendor's patch-cycle (this means that these products are improving, which is a positive outcome).
Some vendors are very reactive, a few vendors (especially Symantec and Barracuda) don't seem to be able to turn around fixes within a reasonable timeframe (Symantec still have not addressed serious issues I raised with them back in January 2012 - despite me chasing them). The good news is that many vendors address issues within a couple of months or so, and some within a few days - which is excellent!
As for a briefest of summaries; this research is continuing to uncover more and more similar issues, showing alarming trends in the insecurities of security-product Web UIs. For example:
Basically speaking, almost all of the Security Gateways I looked at could be compromised by an attacker, and used as an entry point to break into corporated networks.
More recently, and of particular interest I have been looking at ways of exploiting these systems via insecure backup/restore functions, using request forgery to perform arbitrary file-upload. I feel this is an interesting attack-vector because it usually results in a "root shell" - maybe I will do a post on that at some point to explain how the attack works.
Anyway, there are plenty more similar products out there, so I will continue looking. If you have any suggestions of products you think I should look at (especially security appliances) let me know.
This is the video from my presentation at BlackHatEU 2012 back in May, which shows some typical examples of exploits I had found in the period from October 2011 to March 2012 (all of the issues in the demo videos have now been addressed).
(this video is around 40 minutes, and may take a minute or so to start depending on your connection)
If you are interested in the technical side, the white-paper that went with this presentation can be found here:
http://www.nccgroup.com/en/learning-research-centre/security-testing-audit-compliance-resources/white-papers/
Since then I have continued my research project, and to-date have found around 80 exploits (most of which are in Security Gateways, though I have also started to look at some other types of appliances as well). Fixes and updates have been released for at least 25 of these exploits so far, though the majority are still in the respective vendor's patch-cycle (this means that these products are improving, which is a positive outcome).
Some vendors are very reactive, a few vendors (especially Symantec and Barracuda) don't seem to be able to turn around fixes within a reasonable timeframe (Symantec still have not addressed serious issues I raised with them back in January 2012 - despite me chasing them). The good news is that many vendors address issues within a couple of months or so, and some within a few days - which is excellent!
As for a briefest of summaries; this research is continuing to uncover more and more similar issues, showing alarming trends in the insecurities of security-product Web UIs. For example:
Almost all Security Gateway products had
- Unauthenticated information disclosure
- XSS with session-hijacking
- CSRF of admin functions
- Command-injection
- Privilege escalation
Several had
- Direct authentication-bypass
- Stored out-of-band XSS and OSRF
A few had
- Gateway Denial-of-Service
- There were a wide variety of more obscure issues
Basically speaking, almost all of the Security Gateways I looked at could be compromised by an attacker, and used as an entry point to break into corporated networks.
More recently, and of particular interest I have been looking at ways of exploiting these systems via insecure backup/restore functions, using request forgery to perform arbitrary file-upload. I feel this is an interesting attack-vector because it usually results in a "root shell" - maybe I will do a post on that at some point to explain how the attack works.
Anyway, there are plenty more similar products out there, so I will continue looking. If you have any suggestions of products you think I should look at (especially security appliances) let me know.
Friday, 16 March 2012
BlackHat EU 2012 - Day two and three summaries
I have been enjoying myself at BlackHat Europe 2012, soaking up some of the leetness, absorbing some of the technologies I am less familiar with, meeting great people, and talking with them about things which really interest me - which is all good.
BlackHat EU 2012 - Day two
BlackHat EU 2012 - Day two
My Presentation seemed to go well, with several interested people coming up to ask various questions afterwards, maybe due to the fact that I described and showed around 10 exploits I recently discovered in common security products (all patched now BTW - but some very interesting, some creative, and several rather ironic - for example: "a spam the reconfigures the spam-filter", "a URL that owns the URL-filter").
My favourite presentation of Day two was "Data mining a mountain of Vulnerabilities" with Chris Wysopal.
This was quite a dry subject, but very well presented. Lots of data on vulnerabilities, with statistics on vulnerabilites sorted by application language, platform, horizontal and vertical markets, (among many other things)
Really interesting data, and something I feel that I might consult when doing application testing.
Chris had some really interesting graphs, the one above showing clearly that most web-apps contain at least one of the most serious flaws.
Day three
Some really interesting presentations today on mobile/smartphone security. It's hard to choose the best one really, as the following three were very good, and looked like the conclusions were based on very solid research (and many hours of work).
- "Secure Password Managers" and "Military-Grade Encryption" on Smartphones: Oh Really? by Andrey Belenko + Dmitry Sklyarov
- Hmm... so password managers on smartphones are not very well coded - not a surprise really but, a lot of work has been done by these guys to review some of the most popular ones and find some bugs
- Apple vs. Google Client Platforms by Felix 'FX' Lindner
- A great talk this, delivered in FX's highly amusing style
- The Mobile Exploit Intelligence Project by Dan Guido + Mike Arpaia
- Interesting perspective from acedemia on the stats behind mobile exploits, it seems that the hype might be just hype (at least on the iOS platform, more potential on Android though, but still, not a great deal of real platform-pwnage happening)
Anyway, I am in the airport on the way home, and it has been a very good week...
Thursday, 15 March 2012
McAfee Security Gateway patched this week for the issues I reported
Fair play to McAfee for fixing these issues, giving an accurate description of the issues and crediting me with the discovery. This is probably one of the best customer notifications I have seen from the vendors I have dealt with during my research project.
https://kc.mcafee.com/corporate/index?page=content&id=SB10020
Affected Software: McAfee Email and Web Security 5.x, McAfee Email Gateway 7.0
NGS00153 – Reflected XSS
McAfee Email and Web Security Appliance Software 5.x/ McAfee Email Gateway 7.0 is prone to reflective XSS allowing an attacker to gain session tokens and run arbitrary Javascript in the context of the administrators browser and the McAfee Security Appliance Management Console/Dashboard.
NGS00154 – Logout Failure (I would have called this session-management issues, but whatever)
When an administrator closes the Management console/Dashboard without clicking logout and returns to the Dashboard later, they appear to be logged out, however, this is simply the state of the Javascript in his browser, and the session-token is still be active on the server-side. If an attacker gains a session-cookie (perhaps using XSS, or by some other means), they can make a dummy login attempt (with a dummy password) and simply edit the (failure) response. They will then be logged-in, and can use the Dashboard as if he had logged-in as the administrator.
NGS00155 – Password Reset issue
Any logged-in user can bypass controls to reset passwords of other administrators.
NGS00156 – Session Disclosure
Active session tokens of other users are disclosed within the Dashboard.
NGS00157 – Weak Encryption of Backups
Password hashes can be recovered from a system backup and easily cracked.
NGS00158 – File Download Issue
Arbitrary file download is possible with a crafted URL, when logged in as any user.
NGS00159 – File Content Leakage
File contents disclosure as if root user, when logged in as any user.
https://kc.mcafee.com/corporate/index?page=content&id=SB10020
Affected Software: McAfee Email and Web Security 5.x, McAfee Email Gateway 7.0
NGS00153 – Reflected XSS
McAfee Email and Web Security Appliance Software 5.x/ McAfee Email Gateway 7.0 is prone to reflective XSS allowing an attacker to gain session tokens and run arbitrary Javascript in the context of the administrators browser and the McAfee Security Appliance Management Console/Dashboard.
NGS00154 – Logout Failure (I would have called this session-management issues, but whatever)
When an administrator closes the Management console/Dashboard without clicking logout and returns to the Dashboard later, they appear to be logged out, however, this is simply the state of the Javascript in his browser, and the session-token is still be active on the server-side. If an attacker gains a session-cookie (perhaps using XSS, or by some other means), they can make a dummy login attempt (with a dummy password) and simply edit the (failure) response. They will then be logged-in, and can use the Dashboard as if he had logged-in as the administrator.
NGS00155 – Password Reset issue
Any logged-in user can bypass controls to reset passwords of other administrators.
NGS00156 – Session Disclosure
Active session tokens of other users are disclosed within the Dashboard.
NGS00157 – Weak Encryption of Backups
Password hashes can be recovered from a system backup and easily cracked.
NGS00158 – File Download Issue
Arbitrary file download is possible with a crafted URL, when logged in as any user.
NGS00159 – File Content Leakage
File contents disclosure as if root user, when logged in as any user.
BlackHat EU 2012 - Day one summary
I am currently enjoying BlackHat Europe 2012
My favourite presentation for Day 1 was:
Jeff Jarmoc - SSL/TLS interception proxies (and transitive trust)
Really interesting research (to me) as it was kind of adjacent to some of the research I have been doing, and Jeff has looked at some very similar products that I have, but from a different perspective.
Jeff described his research into an issue that I have felt could be a problem (but that I hadn’t investigated, and he has done a great job with his investigation, so this answers some of the questions I had in the back of my mind ;o).
Put simply; When companies implement content-security for encrypted web-traffic (anti-virus, exe-blocking and content analysis for HTTPS traffic) the way to do this is usually to get all the clients within the environment to trust the proxy’s CA cert. Then, traffic is decrypted on the proxy and scanned (the proxy handles the external encryption to the target site) and the traffic is then re-encrypted internally to the client (using the proxy’s trusted cert).
The issue is; “What happens when there is a problem with the cert of the original target site?” and the answer is - “These issues are largely ignored, and the information is dropped, so that everything looks fine on the client-side”.
To paraphrase the reason for this is dropping the baby is that; “SSL was not designed to do this, and this solution is hard enough to implement as it is, so vendors of these products try to make the product set-up and management as easy as possible, and iron-out any of these minor ‘issues’ by ignoring them”.
However, this causes a big security hole because certificates that are spoofed, expired or revoked are often made to look like they are “fine and dandy” to the client – which from a security-perspective, in short, is crap.
Great presentation Jeff!
Quote of the day: “Humanity needs crime, otherwise we would have stomped it out by now.. and the internet needs crime too..”
(Whitfield Diffie, philosophising about “life, the internet and everything”)
My favourite presentation for Day 1 was:
Jeff Jarmoc - SSL/TLS interception proxies (and transitive trust)
Really interesting research (to me) as it was kind of adjacent to some of the research I have been doing, and Jeff has looked at some very similar products that I have, but from a different perspective.
Jeff described his research into an issue that I have felt could be a problem (but that I hadn’t investigated, and he has done a great job with his investigation, so this answers some of the questions I had in the back of my mind ;o).
Put simply; When companies implement content-security for encrypted web-traffic (anti-virus, exe-blocking and content analysis for HTTPS traffic) the way to do this is usually to get all the clients within the environment to trust the proxy’s CA cert. Then, traffic is decrypted on the proxy and scanned (the proxy handles the external encryption to the target site) and the traffic is then re-encrypted internally to the client (using the proxy’s trusted cert).
The issue is; “What happens when there is a problem with the cert of the original target site?” and the answer is - “These issues are largely ignored, and the information is dropped, so that everything looks fine on the client-side”.
To paraphrase the reason for this is dropping the baby is that; “SSL was not designed to do this, and this solution is hard enough to implement as it is, so vendors of these products try to make the product set-up and management as easy as possible, and iron-out any of these minor ‘issues’ by ignoring them”.
However, this causes a big security hole because certificates that are spoofed, expired or revoked are often made to look like they are “fine and dandy” to the client – which from a security-perspective, in short, is crap.
Great presentation Jeff!
Quote of the day: “Humanity needs crime, otherwise we would have stomped it out by now.. and the internet needs crime too..”
(Whitfield Diffie, philosophising about “life, the internet and everything”)
Saturday, 11 February 2012
Apache Range header DoS vulnerability can be a Security Gateway killer
Linux-based appliance UIs can be vulnerable to a serious Denial of Service vulnerability. I am talking here about the Apache Range header DoS vulnerability from August 2011.
This exploit works by making a series of HTTP requests with overlapping ranges in the "Range" or "Request-Range" request headers and results in memory and CPU exhaustion.
For an unpatched Apache server, in many cases a remote unauthenticated attacker could exploit this issue to make the system unresponsive - with only a few packets.
Now, usually this exploit relates to a webserver hosting a website (or multiple websites) so has a limited scope.
However, in the case where the target is the product UI of a Security Gateway, this can mean that the Gateway becomes unresponsive, and if this is a multi-protocol Gateway or Firewall UI - the attacker could potentially disrupt network connectivity (affecting a whole network, rather than a single system).
I have seen several instances recently where a Security Gateway completely freezes up after a few dozen malicious packets, and the system requires a hard-reset (power-cycle) to recover. All network traffic stopped, and the Web UI and even the console were completely unresponsive.
In each of these cases, the Web UIs were often left exposed to the internet (a simple "Google Dork" found dozens of the affected product UIs exposed to the internet).
The solution to this problem is simple, these products need to be patched, but it seems that various vendors of Security Gateways (and other appliances) are not keeping up with their patch-managment, or are unaware of the problem.
This is an example of how to test for this issue (here using Nmap):
(You need the nmap *.nse script from here if you want to test this http://nmap.org/nsedoc/scripts/http-vuln-cve2011-3192.html )
nmap -Pn -sS --script http-vuln-cve2011-3192 -p T:(port here) (ip address here)--script-args http-vuln-cve2011-3192.path=(vulnerable resource here)
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-02-11 20:12 GMT
Nmap scan report for
Host is up (0.22s latency).
PORT STATE SERVICE
(port)/tcp open https
| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 OSVDB:74721
| Description:
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| http://seclists.org/fulldisclosure/2011/Aug/175
| http://nessus.org/plugins/index.php?view=single&id=55976
| http://osvdb.org/74721
|_ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
Nmap done: 1 IP address (1 host up) scanned in 3.32 seconds
(It is very important to get the URL to a vulnerable resource correct, otherwise you may miss the issue, GIFs work quite well, but try a few resources)
To be absolutely sure that the vulnerability is exploitable, it can be exploited with Metasploit (make sure you do this in legal and test conditions, such as in a test lab or on a VM you own).
/pentest/exploits/framework/msfcli auxiliary/dos/http/apache_range_dos RLIMIT=50 RHOST=(ip address here) RPORT=(port here) URI=(vulnerable resource here) E
Here is some detail from Apache on how to address the problem:
http://httpd.apache.org/security/CVE-2011-3192.txt
...but if you are a customer using one of the affected appliances, you won't be able to fix this yourself, you will need to get in contact with your respective vendor, and get them to "pull their finger out" with their patch-management - and then maybe wait a month or so before they fix it.
This exploit works by making a series of HTTP requests with overlapping ranges in the "Range" or "Request-Range" request headers and results in memory and CPU exhaustion.
For an unpatched Apache server, in many cases a remote unauthenticated attacker could exploit this issue to make the system unresponsive - with only a few packets.
Now, usually this exploit relates to a webserver hosting a website (or multiple websites) so has a limited scope.
However, in the case where the target is the product UI of a Security Gateway, this can mean that the Gateway becomes unresponsive, and if this is a multi-protocol Gateway or Firewall UI - the attacker could potentially disrupt network connectivity (affecting a whole network, rather than a single system).
I have seen several instances recently where a Security Gateway completely freezes up after a few dozen malicious packets, and the system requires a hard-reset (power-cycle) to recover. All network traffic stopped, and the Web UI and even the console were completely unresponsive.
In each of these cases, the Web UIs were often left exposed to the internet (a simple "Google Dork" found dozens of the affected product UIs exposed to the internet).
The solution to this problem is simple, these products need to be patched, but it seems that various vendors of Security Gateways (and other appliances) are not keeping up with their patch-managment, or are unaware of the problem.
This is an example of how to test for this issue (here using Nmap):
(You need the nmap *.nse script from here if you want to test this http://nmap.org/nsedoc/scripts/http-vuln-cve2011-3192.html )
nmap -Pn -sS --script http-vuln-cve2011-3192 -p T:(port here) (ip address here)
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-02-11 20:12 GMT
Nmap scan report for
Host is up (0.22s latency).
PORT STATE SERVICE
(port)
| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 OSVDB:74721
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| http://seclists.org/fulldisclosure/2011/Aug/175
| http://nessus.org/plugins/index.php?view=single&id=55976
| http://osvdb.org/74721
|_ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
Nmap done: 1 IP address (1 host up) scanned in 3.32 seconds
(It is very important to get the URL to a vulnerable resource correct, otherwise you may miss the issue, GIFs work quite well, but try a few resources)
To be absolutely sure that the vulnerability is exploitable, it can be exploited with Metasploit (make sure you do this in legal and test conditions, such as in a test lab or on a VM you own).
/pentest/exploits/framework/msfcli auxiliary/dos/http/apache_range_dos RLIMIT=50 RHOST=(ip address here)
Here is some detail from Apache on how to address the problem:
http://httpd.apache.org/security/CVE-2011-3192.txt
...but if you are a customer using one of the affected appliances, you won't be able to fix this yourself, you will need to get in contact with your respective vendor, and get them to "pull their finger out" with their patch-management - and then maybe wait a month or so before they fix it.
Friday, 20 January 2012
An update on my research into attacking Security Gateways via the Web UI – and Blackhat Europe
I haven't written much on my blog for the past few months. This is because I have been very busy with my exploit-development research.
A while back I had the idea to combine web-attacks with Security Gateways, mix things up, and see what happens. This has been very productive, and a lot of fun.
In short, over the past 4 months, I have raised 30+ PoC exploits with vendors of Security Gateways. I have looked at quite a few Gateway products, and discovered serious vulnerabilities in almost all of the ones I have investigated.
Whilst Security Gateway products provide good security features for the protocols and services they protect, if a gateway product is not secure in itself, it can be attacked directly and compromised.
If an attacker can gain control of the gateway of an organization, this is a very powerful position for further attacks; such as traffic-sniffing and powerful man-in-the-middle attacks, disabling network protections, and pivoting the attack to target other systems and users on the internal network.
We often take the security of security-software for granted, assuming that – because the software has come from a company that understands security, then the product is very likely to be secure.
This is frequently an incorrect assumption in regard to Security Gateway UIs, as usually the developers that design, code and test the UI are not “security” people, and are more focused on UI design, functionality, usability, supportability and branding, than on security.
There are a huge variety of web application attacks that have been historically used against public-facing websites and their users. Many of these attacks are transferable to web-based product UIs, and this can have a very interesting impact when applied to Security Gateway UIs.
Most of the serious issues I have found in Security Gateway products have been caused by one or more of the following:
I am currently working to complete a white-paper detailing some of the common findings, and I have recently been informed that I have been accepted to speak at Blackhat Europe on this subject. I will release the white-paper at Blackhat, so more information to come...
... and if you are going to Blackhat Europe, I might see you there!
A while back I had the idea to combine web-attacks with Security Gateways, mix things up, and see what happens. This has been very productive, and a lot of fun.
In short, over the past 4 months, I have raised 30+ PoC exploits with vendors of Security Gateways. I have looked at quite a few Gateway products, and discovered serious vulnerabilities in almost all of the ones I have investigated.
Whilst Security Gateway products provide good security features for the protocols and services they protect, if a gateway product is not secure in itself, it can be attacked directly and compromised.
If an attacker can gain control of the gateway of an organization, this is a very powerful position for further attacks; such as traffic-sniffing and powerful man-in-the-middle attacks, disabling network protections, and pivoting the attack to target other systems and users on the internal network.
We often take the security of security-software for granted, assuming that – because the software has come from a company that understands security, then the product is very likely to be secure.
This is frequently an incorrect assumption in regard to Security Gateway UIs, as usually the developers that design, code and test the UI are not “security” people, and are more focused on UI design, functionality, usability, supportability and branding, than on security.
There are a huge variety of web application attacks that have been historically used against public-facing websites and their users. Many of these attacks are transferable to web-based product UIs, and this can have a very interesting impact when applied to Security Gateway UIs.
Most of the serious issues I have found in Security Gateway products have been caused by one or more of the following:
- Lack of input-validation (leading to attacks such as XSS and Command-injection)
- Predictable URLs and parameters (and therefore CSRF)
- Excessive privileges of running services
- Direct file browsing
- Session-management issues
- Weak session-tokens
- Password Guessing
- Authentication bypass
- Verbose information disclosure
- Out-of-date 3rd party software
- Arbitrary file upload
- Standard installs with poor configurations
- Trivial Denial of Service vulnerabilities
I am currently working to complete a white-paper detailing some of the common findings, and I have recently been informed that I have been accepted to speak at Blackhat Europe on this subject. I will release the white-paper at Blackhat, so more information to come...
Subscribe to:
Posts (Atom)