I have received interesting and mixed feedback from posting the above "bug".
First I'd like to clarify that a vulnerability is measured by the impact it causes, not how easy it is to find it and not by how technically challenging a vulnerability is.
Secondly, vendors appear to not like it but remotely controlling the availability of an application is a security issue. It is the A in the CIA concept. If you are interested in that discussion I wrote a small blog rant about the "Denial of service is not a security issue" mindset of certain vendors.
Third, I just hand over the facts, nothing more. If vulnerability database maintainers do not perceive Denial of service conditions in browsers as a security issue, they would not add it to the database, and yet they do. Doesn't prove anything but underlines my reasoning.
Is this bug a vulnerability? - yes. Is is critical ? Clearly no. Stop seeing the world in Black or White. Something can be a vulnerability and still not be critical for the general public. However make no mistake, some bugs that are (for example) rated medium can become critical for certain companies that use the products in certain ways or critical parts of an infrastructure rely on that particular application.
This is the reason I give no risk rating, what for ? I can't assess the risk an customer runs in specific environments when this vulnerability hits the product, I have no way to assess the risk whatsoever. I think it is highly misleading to have a vendor rate risk for a vulnerability. What I give is a description of the impact, with an description of the impact the customer of that product is actually able to assesses the risk, he is the only one that can.
To illustrate this point take the bug above and think about several scenarios where this bug might actually pose a problem. Have one ? Fine. I have one too; what about for example Internet Kiosk vendors ? i.e the terminals at airports or cities that give access to the internet. Browse to the PoC and the terminal can no longer be used - so, for terminals offering pay for access service, this might mean actually income loss. (I am aware that some "restart" the whole OS or the envrionment periodicaly to clean up the mess left behind) Still I think you'll get the point here, there are a lot more scenarios like this.
There is more then the typical End-user at home sitting before his pc that kills the process and restarts firefox.
During my years doing security consultancy, one of the most astonishing things I learned is the immense variety of how applications are used by different companies. There is no way to summarise risk.
As you may or may not know, I reported quite some Anti-virus bypasses and evasions lately. Most of them have been categorised and rated by vulnerability database maintainers, such as NIST, Secunia, X-force and others now.
I am especially interested in the risk ratings assigned to them. It is quite difficult to rate them - imo you can only rate them in a particular scenario, case by case.
The ratings couldn't be more different.
Ratings :
Xforce : Risk Rating - Medium (Xforce only knows 3 risk ratings, High Medium or low)
NIST : CVSS scoring of 10 (to put that in perspective, 10 is as critical as it can get)
I think this reflects the current state of risk management and risk assessment pretty well. "Highly subjective" to say the least.. NIST for instance rates Confidentiality, Integrity and Availability as completely compromised. While I surely don't think bypasses deserve a 10, I don't think the risk is very low (Secunia). I would rate it similar to Xforce
This is just in : As it appears the IIS 5 / IIS 5.1 / IIS 6 Webdav unicode bug also allows to bypass IP/Domain filters if any are in place. Whoops. So in summary :
bypasses password/authentication
bypasses IP Address and Domain name restrictions.
If interested read more about the webdav unicode bug here.
This post is nothing new, for some it might be. At least I consider it important enough to re-publish this information for those fiddling with RSA / DSA and keys that were used to generate affected by the openssl debian fiasco.
Must read:
RSA public keys are not private Why : Secure auto-updates and why to use a block cipher prior to signing than to use RSA to encrypt and sign.
The Debian PGP disaster that almost was Why : Learn that you should consider all your DSA keys (the keys themselves) compromised if you generated signatures using the vulnerable debian openssl version at any time. I am not sure everybody got this.
I. Background
Quote: "Clam AntiVirus is an open source (GPL) anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail gateways. It provides a number of utilities including a flexible and scalable multi-threaded
daemon, a command line scanner and advanced tool for automatic database updates. The core of the package is an anti-virus engine available in a form of shared library. "
II. Description
The parsing engine can be bypassed by manipulating CAB (Filesize) archives in a "certain way" that the Clamav engine cannot extract the content but the end user is able to.
III. Impact
To know more about the impact and type of "evasion", I updated the description at http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html
Subscribe to the RSS feed in case you are interested in updates
Release mode: Coordinated but limited disclosure. Ref : [TZO-34-2009] - F-prot RAR,ARJ,LHA bypass Vendor : http://www.f-prot.com Status : Current version not patched, next engine version will be patched CVE : none provided Credit : Given in the History file OSVDB vendor entry: none [1] Security notification reaction rating : good Notification to patch window : n+1 (no patch for current build)
F-PROT Antivirus for Windows on Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Exchange (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 File Servers : (High: complete bypass of engine)
F-PROT Antivirus for Solaris SPARC / Solaris x86 Mail Servers (High: complete bypass of engine)
F-PROT Milter - for example sendmail (High: complete bypass of engine)
F-PROT Antivirus for Linux on IBM zSeries (S/390) (High: complete bypass of engine)
F-Prot Antivirus for Linux x86 Workstations (unknown)
OEM Partners affected :
Autentium (all versions)
OEM Partners with unknown status :
Sendmail, Inc.
G-Data
I. Background
Quote: "FRISK Software International, established in 1993, is one of the world's leading companies in antivirus research and product development.
FRISK Software produces the hugely popular F-Prot Antivirus products range offering unrivalled heuristic detection capabilities. In addition to this, the F-Prot AVES managed online e-mail security service filters away the nuisance of spam e-mail as well as viruses, worms and other malware that increasingly clog up inboxes and threaten data security."
II. Description
The parsing engine can be bypassed by a specially crafted and formated RAR archive.
The bug results in denying the engine the possibility to inspect
code within RAR archives. There is no inspection of the content
at all and hence the impossibility to detect malicious code.
IV. Disclosure timeline
DD/MM/YYYY
07/05/2009 : Send proof of concept, description the terms under which I cooperate and the planned disclosure date.
No reply
09/05/2009 : Resending PoC file asking to please acknowledge receipt
19/05/2009 : Frisk acks receipt and states that "I have confirmed that this issue is indeed present in F-Prot engine versions 4.4.4 and earlier. It is not present in the 4.5.0 engine, which is the current development version, and is scheduled for release in the near future"
20/05/2009 : Ask for patch timeline
22/05/2009 : Frisk states that there will be no patch for versions below 4.5.0 and that the next version 4.5.0 is not affected (dev build)
"As a side note, F-PROT 4.4 and older also had a similar issue with ARJ and LHA/LZH files - failing to detect the archive if it was not at the beginning of the file"
10/06/2009 : Ask Frisk whether 4.5.0 has been released now
no reply
18/06/2009 : Release of this advisory.
[1]
F-prot is encouraged to leave their security contact details at http://osvdb.org/vendor/1/Frisk%20Software%20International
to facilate communication and reduce lost reports.
I. Background
Quote: "Clam AntiVirus is an open source (GPL) anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail gateways. It provides a number of utilities including a flexible and scalable multi-threaded
daemon, a command line scanner and advanced tool for automatic database updates. The core of the package is an anti-virus engine available in a form of shared library. "
II. Description The parsing engine can be bypassed by manipulating CAB,RAR,ZIP archives in a "certain way" that the Clamav engine cannot extract the content but the end user is able to.
Subscribe to the RSS feed in case you are interested in updates
Release mode: Coordinated but limited disclosure. Ref : [TZO-33-2009] - F-prot TAR bypass / evasion Vendor : http://www.f-prot.com Status : Current version not patched, next engine version will be patched CVE : none provided Credit : Given in the History file OSVDB vendor entry: none [1] Security notification reaction rating : better than last time Notification to patch window : n+1 (no patch for current build)
Affected products (all versions up to 4.5.0 which is not released yet)
F-PROT AVES (High: complete bypass of engine)
F-PROT Antivirus for Windows (unknown)
F-PROT Antivirus for Windows on Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Exchange (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 File Servers : (High: complete bypass of engine)
F-PROT Antivirus for Solaris SPARC / Solaris x86 Mail Servers (High: complete bypass of engine)
F-PROT Milter - for example sendmail (High: complete bypass of engine)
F-PROT Antivirus for Linux on IBM zSeries (S/390) (High: complete bypass of engine)
F-Prot Antivirus for Linux x86 Workstations (unknown)
OEM Partners affected :
Autentium (all versions)
OEM Partners with unknown status :
Sendmail, Inc.
G-Data
I. Background
Quote: "FRISK Software International, established in 1993, is one of the world's leading companies in antivirus research and product development.
FRISK Software produces the hugely popular F-Prot Antivirus products range offering unrivalled heuristic detection capabilities. In addition to this, the F-Prot AVES managed online e-mail security service filters away the nuisance of spam e-mail as well as viruses, worms and other malware that increasingly clog up inboxes and threaten data security."
II. Description The parsing engine can be bypassed by a specially crafted and formated TAR archive.
III. Impact The bug results in denying the engine the possibility to inspect code within TAR archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.
28/04/2009 : Send proof of concept, description the terms under which I cooperate and the planned disclosure date.
No reply
11/05/2009 : Resending PoC file asking to please reply
20/05/2009 : Frisk replies that it was unable to extract the PoC file with "tar" and hence see no bypass.
20/05/2009 : Inform Frisk that the PoC extracts fine with Winzip
22/05/2009 : Frisk send a lenghty e-mail re-discussing bypasses/evasions
22/05/2009 : I state that I will not discuss this topic any further, everythinghas been said and written multiple times. Either Frisk patches or they do not.
22/05/2009 : Frisk states that the changes to the parsing code are minor i.e not relying on the checksum. The patch will be included in the next releaes candidate 4.5.0 and credit will be given in the History file
Comment: I give it some time to 4.5.0 to be released.
10/06/2009 : Ask Frisk if 4.5.0 has been released now
no reply
14/06/2009 : Release of this advisory
[1]
F-prot is encouraged to leave their security contact details at http://osvdb.org/vendor/1/Frisk%20Software%20International to facilate communication and reduce lost reports.
Several news stories seem to allude that Microsoft is artificially downplaying the threat, citations of myself are used to underline the headline in an "us against Microsoft" kind of way. I want to clarify that I have the utmost respect of the MSRC team and I don't suspect Microsoft to willingly downplay anything. They also claim I am from Belgium, I am obviously from Luxembourg. The bug also is not the same as the IIS4/5 one, it's root cause is similar. That's about it.
About:The video above shows the different Webdav settings and the different impacts they have. Note that code execution is only possible if these pre-conditions are met. I am not sure how often this kind of setup exists, if I had to guess i'd say not often. Credit: Rangos. 1. Updates
25/05/2009 - Update:As Nicolaos wrote in the comment section of this post. IP/Domain filters can be bypassed the same way. In other words if you have a filter for certain IP adresses, you can bypass them. Update : Todd Manning over at Breakpoint labs did comprehensive tests on which Unicode encodings work. The answer is a lot - IPS/IPS vendors should update their signatures. Update : Sharepoint and OWA are not affected by this bug - more infohere Update : Skull security has a good write uphere , they patched cadaver to exploit this vulnerability.Nmap script here. Update: Video detailing the different settings and the different impacts (up to remote code execution) Credit: Rangos Update: Nmap IIS6 Webdav scanner added to tools section. Update: Webdav Network scanner added to tools section.Update : Microsoft SRD Team gives more insight and details (Must read) Update : Microsoft advisory : http://www.microsoft.com/technet/security/advisory/971492.mspx Update : For IIS 6 : Write access is not allowed per default - as such you can only "upload" content if IUSR_anonymous is granted write access. This is not the case per default. Update : IIS5 and IIS7 are NOT affected - IIS5 and 5.1 are affected (according to MS) Update : It is unclear how this affects Exchange 2003 (which allows access to inboxes over webdav)
Below is a summary by Microsofts SRD Team, please note that the below enumeration leads to think that the chances that your setup is vulnerable is VERY unlikely. IMHO this is not the case, take a standard install of IIS6, enable Webdav, setup a protected folder requiring basic auth. And that's it, you are vulnerable.
You are not at risk if : (Source : Microsoft SRD Team)
An IIS server not running WebDAV is safe. The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default.
An IIS server not using IIS permissions to restrict content to authenticated users is safe.
An IIS server that does not grant filesystem access to the IUSR_[MachineName] account is safe.
An IIS server that hosts web applications using only forms-based authentication is probably safe.
You are at risk : (Source Microsoft SRD Team, except italics by myself)
IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled (default for IIS5);
AND the IIS server is using IIS permissions to restrict a subfolder of content to authenticated users;
AND file system access is granted for the restricted content to the IUSR_[MachineName] account;
AND a parent folder of the private subfolder allows anonymous access; THEN an anonymous remote user may be able to leverage this vulnerability to access files that normally would only be served to authenticated webserver users.
4 Test tools
Specificaly for this vulnerability: Metasploit added test script to the trunk
For PROPFIND the "translate:f" option is NOT required (only for GET requests)
Breakpoint labs analysed how the various UTF encodings affected the flaw - lot of variations work.
Recommendation : until the impact is 100% clear you should temporarily disable Webdav or follow the mitigation recommendations from Microsofts SRD team
5. Details
Kingcope a.k.a Nicolaos Rangos released another pwnie grade vulnerability yesterday and it's resemblance to the IIS unicode flaw from 2001 was so similar that my jaw first dropped.
Here are a few facts, these are subject to modifications as the news unfolds:
Webdav is not enabled by default on IIS6, IIS7 + Webdav is not affected
IIS 5 and IIS 5.1 are also affected.
Enabling Webdav applies to all websites and doesn't have to be enabled per site.
You can actually upload content to the web server, if the IUSR_anonymous has write access to webdav folders. (To any other folder if the account has write access to other folders)
This seems to have a similar (root cause) then the 2001 Unicode IIS4/5 bug , but not exactly the same
"Translate:f" is required for GET requests, PROPFIND works without the translate optiion.
Mitigation :
Temporary disable Webdav. This is not easy if you have Sharepoint services running. See here
Backround
In 2001 a path traversal bug was found in IIS4 and IIS5 that lead to a series of serious compromised and massive exploitation (MS01-026). It was bad really bad, the simple path traversal was used to compromise systems remotely mainly through calling (t)ftp.exe to upload arbitrary content.
The path traversal was possible due to Microsoft's introduction of UNICODE support into IIS. The flaw was by design, a typical logical fallacy. Unicode conversion was added AFTER the security checks and not before, resulting in the path "..%c0%af.." to be considered a VALID path, yet it is nothing else then "../.." in ascii. More details can be found here.
MS01-26 - 2001
Here is the logic flaw that lead to the vulnerability in 2001. I quickly drafted this in Visio, below is the way it was supposed to work:
Figure1 IIS4/5 how the security check was supposed to work (click to enlarge)
Here is how it was implemented :
Figure 2 - IIS4/5 how the security check was implemented (click to enlarge)
In other words Microsoft, certainly through the late addition of Unicode support to IIS, failed to realize that converting chars to Unicode representation should happen before any "security" checks. So the flaw was one of logic, Unicode conversion after the security check.
Fast forward 2009 - Kingcope releases a similar vulnerability.
MS09-971492 - 2009
The bug discovered by Rangos seems to suffer from a similar logic mistake when requesting source (translate:f) that has been introduced in the Webdav component. It appears that unicode characters are removed after the security checks.
Example: Uploading arbritary content to an asp page - Creating ASP files only works if "Script Source Access" is enabled and IUSR_Anonymous has write access to the folder. Creating INC files works even if with "script source access disabled". (Source : Hubert.Seiwert)
PUT /protected%c0%af/hello.asp HTTP/1.1
Host: 192.168.171.142
Translate: f
Content-Length: 27
<%response.write("hello")%>
The server will however not execute this asp page - currently no code execution is known to be possible, even if write access is enabled (see exception below). The reason is that you can't simply issue a GET request to the asp page you just created - it's password protected and execution over webdav fails.
However code execution would be possible in scenarios where :
IUSR_Anonymous has write access to the folder in question
If you map the root (or any other) WWW folder to the webdav folder (an hence can issue a simply GET request to the uploaded file)
Subscribe to the RSS feed in case you are interested in updates
Release mode: ZDI (see previous timelines to know why this went to ZDI) Ref : [TZO-37-2009] - Apple Safari Remote code execution (CSS) Vendor : http://www.apple.com Status : Patched (http://support.apple.com/kb/HT3613) Credit : http://support.apple.com/kb/HT3613 CVE : CVE-2009-1698
Affected products :
Apple Safari versions prior to 4.0
Affected systems :
Mac OS X v10.4.11,
Mac OS X Server v10.4.11,
Mac OS X v10.5.7,
Mac OS X Server v10.5.7,
Windows XP or Vista
I. Background
Wikipedia quote: "Apple Inc. (NASDAQ: AAPL) is an American multinational corporation which designs and manufactures consumer electronics and software products. The company's best-known hardware products include Macintosh computers, the iPod and the iPhone."
II. Description
Calling the CSS attr attribute with a large number leads to memory corruption
III. Impact
Viewing a maliciously crafted web page may lead to an unexpected application termination or arbitrary code execution.
Subscribe to the RSS feed in case you are interested in updates
Release mode: No credit = no cooperation Ref : [TZO-36-2009] - Apple Safari & Quicktime DoS Vendor : http://www.apple.com Status : Not patched (enough time was given) Credit : none given ("can't find a place to credit") Discovered : 18.11.2008 Zoller, 12.06.2009 Alexios Fakos (probably plenty of others) Security notification reaction rating : good Notification to patch window : n+1
Wikipedia quote: "Apple Inc. (NASDAQ: AAPL) is an American multinationalcorporation which designs and manufactures consumer electronics and software products. The company's best-known hardware products include Macintosh computers, the iPod and the iPhone."
II. Description A null pointer is being dereference when CFRelease() is called on NULL.
III. Impact
The browser will crash, your data might be lost.
IV. Proof of concept (hold your breath)
Link
V. Disclosure timeline
DD/MM/YYYY
18/11/2008 : Send proof of concept file and a description that failed to give the correct impact
25/11/2008 : Apple acknowledges receipt and reproducibility :"After investigating this issue further, we've determined that the crash your test case triggers is caused by dereferencing a null pointer and not from a format string issue"
20/01/2009 : Ask for an update
23/01/2009 : Apple sends an encrypted and signed PGP mail, fine, however the mail is encrypted with their own key
23/01/2009 : Ask for the mail to be resend as I don't have Apple's private key
24/01/2009 : Apple states that "Regarding the QuickTime null dereference you reported, this bug is still being worked on by our engineers and is not addressed in QuickTime 7.6"
26/01/2009 : Ask apple for a fix time line as this is an ridiculously easy to fix vulnerability
27/01/2009 : Apple states "Regarding the QuickTime null deref issue, it is currently set to be part of the next QuickTime update. [..] Additionally, we do not intend to describe this crasher in our security advisory.
Note: No Security advisory = no credit, should have published here.
28/01/2009: Apple states "Given that we are handling this as a crasher and not as a security exposure, it stands to reason that you may want to disclose it without waiting for the update that addresses it and without further coordination with Apple.We do appreciate the fact that you reported it to us and are intending to address it in the next available update"
[..] [Several discussion about CIA, why a DoS against the iPhone is worth a security advisory, when it isn't against safari.. etc. I spare you the details] [..]
29/01/2009: Ask why I should hold disclosure for a DoS in a particular portable apple product but disclose DoS in other apple products. Asked apple to make a choice, either DoS is a security issue and I won't disclose or it isn't and I disclose all of them, including the one in the very portable apple product
30/01/2009 : Apple answers that : "Your QuickTime and Safari issues constitute denial of service.We consider any denial of service issue to be security related, and they are important to fix. We plan to fix the ones you reported in the next available updates." [..] I was not able to locate a suitable place for crediting the QuickTime crasher"
Fast forward 5 months, and Apple releases a stream of code execution bug fixes for Quicktime.
01/06/2009 : Ask for an update and if the DoS condition has been fixed
02/06/2009 : Apple states that "According to our bug tracking system the null-dereference crasher issue is not yet addressed in QuickTime. We are investigating now to see if for some reason the latest version has picked up changes that address this issue and will send you feedback today about it."
In summary, no credit, no advisory, and 7 months of time to (not) fix a single line of code.
Subscribe to the RSS feed in case you are interested in regular updates
Release mode: Coordinated but limited disclosure Ref : [TZO-33-2009] - F-prot TAR bypass / evasion Vendor : http://www.f-prot.com Status : Current version not patched, next engine version 4.5.0 will be patched CVE : none provided Credit : Given in the History file OSVDB vendor entry: none [1] Security notification reaction rating : better than last time Notification to patch window : n+1 (no patch for current build ,vendor not sure when 4.5 will be deployed)
Affected products (all versions up to 4.5.0 which is not released yet)
F-PROT AVES (High: complete bypass of engine)
F-PROT Antivirus for Windows (unknown)
F-PROT Antivirus for Windows on Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Exchange (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 Mail Servers : (High: complete bypass of engine)
F-PROT Antivirus for Linux x86 File Servers : (High: complete bypass of engine)
F-PROT Antivirus for Solaris SPARC / Solaris x86 Mail Servers (High: complete bypass of engine)
F-PROT Milter - for example sendmail (High: complete bypass of engine)
F-PROT Antivirus for Linux on IBM zSeries (S/390) (High: complete bypass of engine)
F-Prot Antivirus for Linux x86 Workstations (unknown)
OEM Partners affected :
Autentium (all versions)
OEM Partners with unknown status :
Sendmail, Inc.
G-Data
I. Background Quote: "FRISK Software International, established in 1993, is one of the world's leading companies in antivirus research and product development.
FRISK Software produces the hugely popular F-Prot Antivirus products range offering unrivalled heuristic detection capabilities. In addition to this, the F-Prot AVES managed online e-mail security service filters away the nuisance of spam e-mail as well as viruses, worms and other malware that increasingly clog up inboxes and threaten data security."
II. Description The parsing engine can be bypassed by a specially crafted and formatted TAR archive.
The bug results in denying the engine the possibility to inspect code within TAR archives. There is no inspection of the content at all and hence the impossibility to detect malicious code.
IV. Disclosure timeline
DD/MM/YYYY
28/04/2009 : Send proof of concept, description the terms under which I cooperate and the planned disclosure date.
No reply
11/05/2009 : Resending PoC file asking to please reply
20/05/2009 : Frisk replies that it was unable to extract the PoC file with "tar" and hence see no bypass.
20/05/2009 : Inform Frisk that the PoC extracts fine with Winzip
22/05/2009 : Frisk send a lengthy e-mail re-discussing bypasses/evasions
22/05/2009 : I state that I will not discuss this topic any further, everything has been said and written multiple times and to please only state if either Frisk patches or not.
22/05/2009 : Frisk states that the changes to the parsing code are minor i.e not relying on the checksum. The patch will be included in the next releaes candidate 4.5.0 and credit will be given in the History file
Comment: I give it some time to 4.5.0 to be released.
10/06/2009 : Ask Frisk if 4.5.0 has been released now
Subscribe to the RSS feed in case you are interested in updates.
Release mode: Coordinated but limited disclosure Ref : [TZO-32-2009] - Norman generic evasion (RAR) Vendor : http://www.norman.com Status : Patched (with decompression engine version 5.99.07) CVE : none provided Credit : http://www.norman.com/support/security_bulletins/69333/en OSVDB vendor entry: Norman is not listed as a vendor in OSVDB Security notification reaction rating : ok Notification to patch window : 77 days
Affected products :
The vulnerabilities have been fixed in Norman's compression library (NCL) 5.99.07, relased on Norman's Internet update servers as an automatic update 03 June 2009. This solves the vulnerability for all updated Norman's products except for Norman Network Protection
Norman Virus Control single user and corporate versions
Norman Internet Control
Norman Virus Control E-mail plugins
Norman Endpoint Protection
Norman Secuirty Suite
Norman Network Protection
Norman Virus Control for Lotus Domino
Norman Virus Control for Exchange
Norman Virus Control for Linux
Norman Email Protection
Norman Email Protection Appliance
Norman Online Protection
Norman Virus Control for AMaViS
Norman Virus Control for MIMEsweeper
Third party vendors that use the Engine
OEM vendors known to use the Norman engine :
- eeye Blink
I. Background
Quote: "Norman ASA is a world leading company within the field of data security, internet protection and analysis tools. Through its SandBox technology Norman offers a unique and proactive protection unlike any other competitor"
05/03/2009 : Send proof of concept (RAR Size), description the terms under which I cooperate and the planned disclosure date.
No reply
13/03/2009 : Re-Send proof of concept (RAR Size), indicating this is the last attempt to responsible disclose.
14/03/2009 : Norman acknowledges receipt
23/03/2009 : Send proof of concept (RAR Method)
23/03/2009 : Asking for an update for the RAR Size sample
02/04/2009 : Norman confirms reproduction of RAR Method PoC and that they will release the patch a.s.a.p
02/04/2009 : Norman promises to get back with release dates/advisory information as soon as they have some firm dates
06/04/2009 : Norman confirms reproduction of RAR Headflags PoC 20/04/2009 : Norman confirms reproduction of the CAB PoC and that all reported vulnerabilities have been patched internally.
22/04/2009 : Ask for a list of affected versions/products
no answer
27/04/2009 : Norman sends in the patched decompression DLL for me to if the patch is correct
28/04/2009 : Send TAR PoC file
no acknowledgement
07/05/2009 : Ask for an update to all reported bugs
no reply
08/05/2009 : Inform Norman that as I no longer receive any replies I assume that the patch is deployed and set that the final disclosure date to the 1.06.2009
09/05/2009 : Norman states they probably can't make the 1/06/2009
09/05/2009 : Propose to postpone disclosure upon request
28/05/2009 : Ask for an update as 01.06.2009 still is set
30/05/2009 : Norman asks to postpone the disclosure by a week as they have to finish Q&A
09/06/2009 : Ask norman whether the Q&A has been finished
09/06/2009 : Norman replies the patches where deployed on the 3rd of June
Subscribe to the RSS feed in case you are interested in updates
Release mode: Coordinated but limited disclosure. Ref : [TZO-31-2009] - Ikarus multiple evasions through CAB,RAR,ZIP Vendor : http://www.ikarus.at Status : Patched (after engine version 1.1.58) CVE : none provided Credit : t.b.a OSVDB vendor entry: Ikarus is not listed as a vendor in OSVDB Security notification reaction rating : good Notification to patch window : 77 days Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html
Affected products :
IKARUS virus utilities (scan-time)
IKARUS myM@ilWall
IKARUS Content Wall
IKARUS security.proxy
I. Background Ikarus Software GMBH is an Anti-virus company based in Austria.
II. Description The parsing engine can be bypassed by a specially crafted and formated RAR (Headflags and Packsize),ZIP (Filelenght) and CAB (Filesize) archive.
III. Impact The bug results in denying the engine the possibility to inspect code within the RAR, ZIP archives. There is no inspection of content at all.
80% of all attacks come from within the enterprise - so the dogma.
After the Verizon report that stated that the insider threat is grossly exagerated here is another interesting piece from Taosecurity :
Did you know that the 80% statistic is based on a 17 year old report with questionable procedures?
Did you know that this is know since a 2001 CSI/FBI study quoted Dr. Eugene Schultz ? [1]
There is currently considerable confusion concerning where most attacks originate. Unfortunately, a lot of this confusion comes from the fact that some people keep quoting a 17-year-old FBI statistic that indicated that 80 percent of all attacks originated from the [inside].
Quote: "For the past five years, incidents caused by insiders accounted for 7% or less of all Web intrusions. In 2003, outsiders accounted for 53%. About one-quarter of respondents said they “don’t know” the origin of their Web incidents, and 18% said “both” the inside and outside participated."
While the 80% myth seems busted, insiders apparently caused more financial damages than outsiders.
It seems to appear to the public that, as an example, Symantec does not suffer from the same bugs as reported in other vendors products, as I have not released any advisories for them. This is not the case. Symantec and some other vendors seems to either play the "collect all bugs, publish one advisory game" delaying the patches and exposure window in an unnecessary fashion or take a rather long time reproducing simple bugs, which isn't really any better.
My reaction to this is to stop submitting vulnerabilities to such vendors and only continue to submit POC files once patches are issued. To remove the incentive to collect multiple bugs and release one advisory, I will publish one advisory per bug, regardless of how many patches there are released.
Currently on the "Stop to submit POC files" list are :
Subscribe to the RSS feed in case you are interested in updates
Release mode: Forced disclosure Ref : [TZO-30-2009] - Kaspersky PDF evasion (Forced disclosure) Vendor : http://www.kaspersky.com Status : Silent fix that doesn't work - No appropriate patch CVE : none provided Credit : none given OSVDB vendor entry: No [1]
Security notification reaction rating : Catastropic
Not only did the headquarter not answer, they (tried) to patch this vulnerability silently, only to fail at it. See Timeline.
This is not the first time that Kaspersky did not answer but patched bugs without credit, advisory or anything. This was however the last time I will not disclose, I am no longer part of an entity that tolerates irresponsible non-disclosure.
A professional reaction to a vulnerability notification is a way to measure the maturity of a vendor in terms of security. Kaspersky is given a grace period of two (2) weeks to reply to my notifications. Failure to do so will result in details of all the other reported bugs be released in two (2) weeks.
Kaspersky® Anti-Virus for Windows Server Enterprise Edition
Kaspersky® Anti-Virus for Novell NetWare
Kaspersky® Anti-Virus for Linux File Server
Kaspersky® Anti-Virus for Samba Server
Kaspersky® Security for Microsoft Exchange 2007
Kaspersky® Security for Microsoft Exchange 2003
Kaspersky® Anti-Virus for Lotus Notes/Domino
Kaspersky® Anti-Virus for Windows Workstation
Kaspersky® Anti-Virus for Linux Workstation
Kaspersky® Anti-Virus for Linux Mail Server
Kaspersky® Mail Gateway Kaspersky® Anti-virus for MIMEsweeper
I. Background
Quote: "We develop, produce and distribute information security solutions that protect our customers from IT threats and allow enterprises to manage risk. We provide products that protect information from viruses, hackers and spam for home users and enterprises and offer consulting services and technical support. "
II. Description
The PDF files are not parsed correctly, a PDF file starts with the magic byte "%PDF" and ends with the magic byte "%%EOF", everything in between those markers is parsed and interpreted. Furthermore PDF files are read from the bottom to the top.
Adobe Acrobat nor the FoxitReader care too much about the data that comes prior the magic byte, the kaspersky engine does, not only does it care, it fails to detect the malware inside the PDF file.
I will spare you the details, a PDF file is bascialy a container that starts with %PDF and ends with %%EOF.
What follows are the details of this evasion, note this one is generic and the easiest one, there are plenty more. What you read below is true as amazing as it might seem, you can't have it more simple.
Example of a malicious PDF file : %PDF Malicious content here %%EOF
Doing :
Enter stuff here, like random text. %PDF Malicious content here %%EOF
This has the result that the malware is no longer being detected. Note: Not a single byte of the malware itself been altered, and strictly speaking the content that represent a PDF file hasn't been changed at all.
This has been tested with several malicious PDF files and represents a generic evasion of all PDF signatures and heuristics.
Kaspersky was given the PoC file directly through myself and F-Secure, they went ahead an patched this by adding a signature for the POC file, adding a PE header in front of a PDF file (with a PDF extension) still evades detection and the exploit still triggers when opening the file with Adobe. Thus the patch is flawed by design.
Thus the root cause is :
The PDF file is not parsed from the bottom to the top, it's important to support the format the same way the end-user application does.
The PDF magic byte (was) read from at static offset
Heuristics are apparently not good enough to detect simple shellcode in a PDF file
Kaspersky was given the sample directly through myself and F-Secure, they went ahead and silently patched this by adding a signature for the PoC file. After analysis the patch proved to be incomplete, by adding a PE header in front of a PDF file (with a PDF extension) detection is still evaded and the exploit still triggers when opening the file with Adobe. A professional reaction to a vulnerability notification is a way to measure the maturity of a vendor in terms of security. Kaspersky is given a grace period of two (2) weeks to reply to my notifications. Failure to do so will result in details of all the other reported bugs be released in two (2) weeks. III. Impact
The heuristics can be bypassed by a special formated PDF "container", this leads to the bypass of malicious PDF files, old or new. This is not a bypass that relies on archive structures but relies on evading certain
code paths in the av engine "through various means".
Note: Certain vendors confirmed this to bypass their engine at runtime.
IV. Timeline
DD/MM/YYYY
15/05/2009 : Send proof of concept, description the terms under which I cooperate and the planned disclosure date.
no reply (note - there where receipt acknowledgements (nothing more) for 2 other reports but not this one )
xx/05/2009 : F-Secure sends the same sample to Kaspersky
01/06/2009 : Re-sending the proof of concept, description the terms under which I cooperate and the planned disclosure date.No reply
03/06/2009 : F-Secure informs me that the sample was submitted to Kaspersky
03/06/2009 : Informed F-secure to communicate with Kaspersky and please ask them to reply to my notifications.
03/06/2009 : Kaspersky Moscow visits my blog, searches for "AVP" and "Kaspersky". Obviously they received both reports. No reply
04/06/2009 : I discovered that the PoC file is now detected by the latest Kaspersky update.
04/06/2009 : Discovered that adding a few bytes evades the AV engine again
+5minutes
09/06/2009 : Release of this advisory on the blog, tweet. Hoping for any reaction prior to sending it to bugtraq et al.
13/06/2009 : Release to Bugtraq et al and start of grace period.
14/06/2009 : Kaspersky sends me an e-mail and promises to get back with updates.
Note (in all fairness): Kaspersky US did acknowledge the receipt of 2 other bugs,however they couldn't provide any information or any reaction as Moscow simply didn't answer them.
Disclaimer: The views and opinions expressed on this blog are my personal views and are not intended to reflect the views of my employer or any other entity.
An Interview With the Target & Home Depot Hacker
-
In December 2023, KrebsOnSecurity revealed the real-life identity of
Rescator, the nickname used by a Russian cybercriminal who sold more than
100 million ...
What to Do With Products Without SSO?
-
First, let’s get this out of the way: SaaS vendors that lock Single Sign-On
(SSO) behind enterprise-only plans are disadvantaging their customers and
the i...
Is Telegram really an encrypted messaging app?
-
This blog is reserved for more serious things, and ordinarily I wouldn’t
spend time on questions like the above. But much as I’d like to spend my
time writ...
What a lovely sunset
-
Oh, hi. Long time no blog, eh?
Well, it is time to sunset this blog, I will be deleting it in the next few
weeks.
So long, and thanks for all the fis...
Rebooting
-
I’ve recently had some time to catch up on reading and research. I’ve
decided to start writing again here about cryptography, embedded systems,
and securit...
Satori Updates
-
I've continued to update Satori little by little out there on github.
Both updating the underlying code and fingerprints. Always happy to have
new id...
The Future of the FTC: Part II
-
A previous blog post discussed FTC Chairwoman Slaughter’s first priority as
the newly designated chairwoman – the COVID-19 pandemic. The FTC’s second
prior...
WeirdAAL update - get EC2 snapshots
-
I watched a good DEF CON video on abusing public AWS Snapshots
https://www.youtube.com/watch?v=-LGR63yCTts
I, of course, wanted to check this out. There a...
SSTIC 2018
-
Nous sommes en 2018. Fuites de données, attaques massives, failles
structurelles, le monde constate chaque jour un peu plus à quel point la
sécurité est ...
En français svp?
-
Mir stelle fest, datt graff vereinfacht, zu Lëtzebuerg 100.000 Lëtzebuerger
schaffen, 100.000 net-Lëtzebuerger Residenten an 200.000 Frontalieren. Datt
ënn...
Rogue One Sequel already being filmed!
-
There’s some really interesting leaked photos and analysis by Charles
Goodman. “Leaked photos from the Rogue One sequel (Mainly Speculation –
Possible Spoi...
VulnHub Stapler 1 Solution 2
-
You can find Solution 1 here.
After spending a night on this, I finally managed to solve the 2nd way to
get limited shell on this box. Let's see how this ...
McAfee SiteList.xml password decryption
-
Recently, a very good friend of mine (@Sn0rkY) pointed me out the story of
a pentester who recovered the encrypted passwords from a McAfee
SiteList.xml fil...
Learning SDR
-
I recently launched Software Defined Radio with HackRF, an instructional
video series that I hope will make it easier than ever for people to learn
the bas...
USENIX Security Symposium Slides
-
We're very happy to present the paper
Revisiting SSL/TLS Implementations - New Bleichenbacher Side Channels and
Attacks
by Christopher Meyer, Juraj Somo...
New Insights into Email Spam Operations
-
Our group has been studying spamming botnets for a while, and our efforts
in developing mitigation techniques and taking down botnets have
contributed in d...
RSA Announces End of RSA Security Conference
-
Aims to bring clarity to cloudy marketing messages through exhibit hall
chotskies Bedford, MA., – April 1, 2014 – RSA, the security division of
EMC, today ...
Samsung Galaxy S5 could be cheaper than Galaxy S4
-
Good news for would-be Samsung Galaxy S5 customers - the main smartphone
may end up being more economical as opposed to Galaxy S4 was when it
established. ...
Why I _am_ Speaking At RSA 2014
-
There’s been quite a bit of drama with regards to whether or not to boycott
the RSA conference over a deal that the RSA security vendor had made with
the N...
Router backdoor reloaded...
-
S i vous avez aimé l'histoire de la backdoor D-Link, vous allez A-DO-RER
celle-ci. C'est encore sur /dev/ttyS0 que ça se passe, où on apprend que
les route...
One year after, end of Magnificent 7 project !
-
It has been a year already since the start of the Magnificient 7 program !
So what happened during this year ? We added some features to enhance your
analy...
Mobile Device Forensics - Course Update
-
It's been a few weeks since the last update, but things have been busy. The
Fall 2012 term is now in Week 5 (wow, the semester is flying by). We've
covered...
NWScript JIT engine: Wrap-up (for now)
-
Yesterday, I provided a brief performance overview of the MSIL JIT backend
versus my implementation of an interpretive VM for various workloads.
Today, I’l...
.png)
