| | |
| June 22, 2005 | |
| | |
| In This Issue |
 Tech Talk News & Articles Reader Q&A Announcements |
| Tech Talk |
Your Defense is Offensive While this flaw does not lead to IPFW to be used as an attack vector it does show that security issues within security products have existed for quite some time. Lets look at some of the newer, more serious issues out there. More Relevant Issues Starting with a security technology that everyone has been convinced that they need, firewalls. When you search online vulnerability databases such as OSVDB (www.osvdb.org) using the simple word; 'firewall' you will find approximately 160 different vulnerabilities. Of course not all of these are serious enough to be used as an attack vector but some are. The first of which is OSVDB ID 4412 – Checkpoint Firewall-1 SmartDashboard Overflow. This vulnerability allows a remotely authenticated user to elevate their privileges and execute arbitrary commands. This issue is over a year old and according to OSVDB, there are no known patches or workarounds for it but exploit code does in fact exist. The level of exposure to a vulnerability such as this is limited, as you do need to be an authenticated user which would lead one to assume that various log files will offer evidence of your dirty deeds of course those log files are only good if stored in a secure manner and that the evil user doesn't know to cover up the evidence. Obviously, allowing code be executed on your firewall is a bad thing and the scenarios where this can be abused are endless. Also under the category of abusing firewalls we find a handful of Zone Alarm vulnerabilities. According to OSVDB there are sixteen different ways one could abuse Zone Alarm. However, out of those sixteen vulnerabilities only two offer the ability to be used in an attack other than your run of the mill denial of service. The first of which was discovered by eEye Digital Security, and is an overflow that was present in the SMTP processing agent. Those of you familiar with this vulnerability are probably getting ready to correct me by saying that this is not remotely exploitable as it requires the malformed SMTP RCPT TO string to come from the client are only partially correct. Yes, the malformed command must come from the client side but that does not rule out the potential to abuse this flaw. For example, a malicious web link could be easily crafted and used to trick users into sending an email with the correct malicious string causing either the system to simply crash or, even better from an attacker's perspective, to execute commands with system privileges. Probably the easiest and most reliable attack to initiate here, not that I would know anything about attacking systems, would be to upload and execute something, netcat perhaps, that can give you system level shell or backdoor access to the system. Using the netcat example, simply executing it to listen on port 53 or some other non-obvious port is pretty common and as far as I know netcat is not on any of the Anti-Virus vendor hit lists. The second vulnerability in Zone Alarm is very similar albeit more difficult to achieve as it requires abusing a specific device driver installed with Zone Alarm. Again, this needs to be achieved on the client side and this vulnerability is more prone to crashing the system than it is successfully executing commands but the potential is there and it does work. In order to prevent this paper from turning into one about nothing more than broken firewalls which would ultimately lead into a rant that may in fact be construed as anti-firewall technology I will move on to another popular security technology – Intrusion Detection Systems (IDS). As you probably know, there are host based (HIDS) and network based (NIDS) intrusion detection systems for the purpose of this paper I will not distinguish between the two and do what makes most NIDS and HIDS vendors cringe and simply lump them together. If one wanted to go old school there was a vulnerability found back in 1999 that affected the Dragon IDS system and allowed attackers the ability to execute commands on the IDS host. Of course, this paper is meant to demonstrate practical real world attacks so we will fast forward to attacks that are relevant enough to work in today's environments. For my first example, I will use the Snort vulnerability that was found just over two years ago. I have personally witnessed environments still running older versions of Snort which is why I am using it as an example. Basically, an attacker can send a specially crafted packet that will cause a heap overflow and execute commands. Let's think about this one for a minute. Here you have a system that is typically installed on sensitive network segments and is typically in a position to see most network traffic. A smart attacker, wouldn't abuse the sensitivity of this system and rather use this vulnerability to gather data. For example, if one was to use this vulnerability to obtain a remote shell, one could use this system to capture sensitive information as that is essentially what it is already doing. Luckily, this vulnerability has been fixed and is not present on any new versions of Snort. My next example for those that are good at noticing patterns was discovered by eEye Digital Security. OSVDB ID # 4702 explains how a flaw in the way RealSecure, Preventia, and BlackIce reassemble SMB packets can be abused to run arbitrary code with SYSTEM privileges. This vulnerability can be exploited with only one simple SMB packet and to quote the eEye advisory, code execution is effortless. So once again, we have a system that is typically used in sensitive locations offering the ability for an attacker to access sensitive data. Much like the Snort attack, a smart attacker would not abuse this flaw but silently use it to gather sensitive data. In fact this combined with the fact that there are numerous ways to bypass IDS signatures, in general and not just ISS IDS products, and an attacker could easily gain and maintain access to the system. If cautious the attacker could pull this off without being detected. Another example of the same IDS products leaving organizations open to attack is the ICQ Protocol overflow that was used in the Witty worm. The witty worm is a great example of how so called systems designed to protect you can leave you vulnerable. All of the above examples are known and have been known for quite some time. Most of them have been addressed by the vendors although that does not mean that there are still systems that can be attacked using these methods. The next scenarios are ones that may or may not have been thought of or reported but does illustrate how the very infrastructure we have built to protect our networks can in fact be used against us. Patch & Systems Management At Blackhat Amsterdam 2005, Chris Farrow presented a talk that was researched and written by me. This talk outlined many of the flaws in the current patch and systems management process including some ideas on how these flaws can be abused. Most of these attack scenarios are completely theoretical and while variations or portions of the attacks outline have in fact occurred no one has performed an attack against the patching or systems management infrastructure, YET. During the Blackhat talk, the following disclaimer was given in point form;
Before we dive into the specific flaws in the various products lets look at the anatomy of a Microsoft patch. Patches released by Microsoft are digitally signed, these signatures are available on the patch download server and Microsoft controls the patch process with an XML file named mssecure.xml. As a bare minimum this seems like a reasonable way to handle patch distribution but can you think of any other vendors out there that do not even bother to do this bare minimum? Patch and Systems Management products can be lumped into two categories. Agent based and Agentless technologies. Obviously, the agent based systems require an agent to be installed on the host systems in order for them to be managed or patched. The agentless systems do not require an agent but usually require privileged credentials or some sort of trust relationship on the network. Most of these systems communicate over the following protocols;
Patches are fed to the master systems either directly via Windows Update over HTTP. Some systems download new patches for each run while others store the patches in a central repository. Some systems are able to simply push out patches and configuration changes while others require custom scripts to be created. So far, while explaining at very high level how most vendors have approached patch and systems management I have already uncovered some potential flaws that should be investigated. They are;
The second point, during testing and research for the original Blackhat talk it was found that some agents only check that the machine name sending the commands matches that of the console and then simply does what it is told by this machine. Obviously this is a huge mistake in terms of security as an attacker can easily not only discover the machine name but also spoof it. The patch repositories on some systems by default have extremely weak directory and file permissions leaving the very patches themselves vulnerable to modification. While some systems combat this by checking the digital signature each time it issues a patch, others simply check once, save the patch in the directory and then assume that it is a valid patch as long as the file name matches. These are all weaknesses in the patch products themselves but as with any weakness, it is useless unless there is a legitimate attack vector to go along with such weakness. The first potential attack vector comes from the internal threat which admittedly is not as sexy or cool as an external attack.
The second attack scenario is in fact an external attack scenario and abuses a couple flaws found specifically in the Microsoft patch process. The first issue with the Microsoft Patch process is that it is a regularly scheduled process. This gives an attacker a window of opportunity – more on this shortly. The second issue that that while Microsoft publishes a XML file containing everything a user needs to validate a patch. That XML is distributed from the same systems that the patches are distributed from. You will see why this can be a problem in the following scenario.
Solutions & Conclusion The above scenarios are nothing more than scenarios based on high level research of vulnerabilities and how specific products work. While products that run and "secure" Microsoft environments were used in all of the examples these flaws can in fact extend to other operating systems. The bottom line and the entire point of this paper is that organizations need to start putting more thought and research into what products they use to protect their infrastructures. Basing purchasing decisions on who has the cutest booth babes at the various conferences may make sense for general IT products and services but not when selecting a security or systems management vendor. Steve Manzuik – Security Product Manager, eEye Digital Security |
| News & Articles |
| The following articles represent the opinions of their respective authors. They do not necessarily represent the opinions of eEye Digital Security. BusinessWeek: Computers' Insecure Security NewsFactor: Hackers Eye Security Software as New Target for Malware Sydney Morning Herald: Security Claims Asking for Trouble SecurityFocus: Flaw Disclosure Hurts Software Maker's Stock |
| Reader Q&A |
Q: What steps should I take to secure my wireless device? |
| Announcements |
Advisory: HTML Help File Parsing Buffer Overflow Seminar: Post-Patch Day Vulnerability Expert Forum Products: Blink® 2.0 Beta Available for Evaluation |
| Etcetera |
Microsoft Begs To Be Hacked Microsoft's Security Response Center: How Little Patches Are Made |
HOW TO SUBSCRIBE FEEDBACK DISCLAIMER NOTICE |
Etcetera