Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2007-08-14 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

August 'Black Tuesday' overview

Published: 2007-08-14
Last Updated: 2007-08-15 18:02:50 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Overview of the August 2007 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS07-042 MSXML memory corruption vulnerability allows remote code execution with the rights of the logged on user.
Replaces MS06-061 and MS06-071
XML core services (via Internet Explorer)

CVE-2007-2223
KB 936227
No known exploits Critical Critical Important
MS07-043 OLE memory corruption vulnerability allows remote code execution with the rights of the logged on user.
Windows OLE
Office 2004 (mac)
Visual Basic 6

CVE-2007-2224
KB 921503
No known exploits Critical Critical Important
MS07-044 Input validation failure allows remote code execution with the rights of the logged on user
Replaces MS07-036.
Office for Mac 2004 and Excel viewer 2003 are also affected.
Office: excel

CVE-2007-3890
KB 940965
No known exploits Critical Critical Important
MS07-045 Multiple vulnerabilities allow remote code execution.
Replaces MS07-033.
Internet explorer

CVE-2007-0943
CVE-2007-2216
CVE-2007-3041
KB 937143
No known exploits Critical Critical Important
MS07-046 Unspecified input validation failures allow remote code execution.
Replaces MS06-001 ("WMF").
GDI

CVE-2007-3034
KB 938829
No known exploits
Details of the vulnerability are public
Critical Critical Important
MS07-047 Multiple vulnerabilities in "skins" allow remote code execution with the rights of the logged on user.
Replaces MS06-024
windows media player

CVE-2007-3037
CVE-2007-3035
KB 936782
No known exploits Important Critical Important
MS07-048 Multiple input validation vulnerabilities allow remote code execution with the rights of the logged on user.
Vista Gadgets

CVE-2007-3033
CVE-2007-3032
CVE-2007-3891
KB 938123
No known exploits Important Critical Important
MS07-049 A vulnerability in virtual PC allows the guest OS administrative users to run arbitrary code on the host OS.
Virtual PC (for windows and Mac)

CVE-2007-0948
KB 937986
No known exploits Important Critical(**) Critical(**)
MS07-050 Input validation vulnerabilities allow remote code execution with the rights of the logged on user.
Replaces MS07-004 ('VML')
VML (Internet explorer)

CVE-2007-1749
KB 938127
No known exploits
Details of the vulnerability are public
Critical Critical Important

 

We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): if installed and used in a security enhancing manner, see above as well.

--
Swa Frantzen -- NET2S

Keywords: mspatchday
0 comment(s)

strong -two factor- authentication and still vulnerable ?

Published: 2007-08-14
Last Updated: 2007-08-15 09:17:58 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Winfried wrote in about a story in Dutch about a bank in the Netherlands. The announcement of the bank in English is here: https://www.abnamro.nl/nl/overabnamro/en_internet_crime.html

This bank has -like most European banks- an online banking application for their customers using strong authentication. A hardware based off-line token that requires a pin code and generates a one time password. The juicy part for attackers is however the ability to transfer money to other accounts (even accounts that are abroad).

Now most such banks out in Europe use strong authentication, signing of transactions etc. still it's not safe apparently. So what can go wrong ?

 

Man in the Middle

The traditional attack against well protected website is to install something in between the client and the server. It will let pass through the authentication, but might change transactions (before they are signed) or add transactions (if they can be done without signing or if they can be grouped and the group signed as one action).

Where can the user detect this?  The one warning about a bad SSL certificate. If the user accepts the certificate, all his chances of detecting it become very slim to nonexistent. But we all know at least a dozen websites that do not have proper SSL certificates and as such teach users to accept certificates.

The attacker might show his hand in the process of applying the signature to a transaction, but most people do not always know the string of digits and operators they press on their hardware token are in fact account numbers and amounts of money to be transfered that they are signing. They just see it as numbers to type and get the result back to the website to move on.

Most banking websites I've used (I'm not a customer of ABN AMRO) do not tell or emphasize the meaning and the need to verify what you are signing. And if they allow you to use a temporary storage of transactions that you can sign in one go, it's unlikely you'll have to sign all accounts and amounts individually, so you're signing something (with a non-repudiable signature!) that you cannot verify as you cannot trust what you see from the man in the middle is also what he gave to the real application.

The bottom line is to make sure:

  • Have the right hostname (bookmark it)
  • Have the https
  • Have the little lock
  • Have a valid certificate

If you miss any of them ... stop.

Now that man in the middle attack is hardly news, so what's new out there now?

 

Trojan

Apparently this bank had a targeted attack against it March and again today.  The Trojan was mailed to the victim with instructions to install the software. Obviously such a Trojan can make all the interaction between the user and the remote website unreliable. If the client machine is unreliable every measure described above is insufficient.

It's worse than the man in the middle attack as all the signs of the man in the middle attacker can be completely hidden from the user.

In theory, the Trojan can completely change what the browser shows the user, with whom the users talks, if the SSL certs are valid, what one sees on the screen while signing transactions, the works.

Now the actual Trojan was not yet this advanced it seems, but it's a small step in addition to take and it's not going to get easier for those defending against this type of attackers.

 

The ABN AMRO attack

Freely translated from the Dutch article for the benefit of a global audience: 

Kaspersky is referenced as the source of how the trojan worked (the method of distribution is unconfirmed).

  • The malware tracks which websites are visited and passes it on to a hacked server.
  • As a https-site is visited, a second stage is downloaded and activated that logs traffic. These logs are also transmitted to the hacked server.
  • If the ABN AMRO-website is visited, a third piece of malware is downloaded and activated that specifically attacks their site.

ABN AMRO uses two factor authentication, but it apparently does not make a difference between the codes to log in and those to sign a transaction.

While this does make it easy for the attackers to do their thing, the Trojan could just as well work against much more robust implementations as well.

The third Trojan allows the user try to to log in, but tells the user the attempt failed, sets up a transaction in the real web application and asks the user to try to login again, confirming the transaction it set up behind the scenes.

Kaspersky also has a clean up page should anybody need it (in Dutch again):

https://www.kaspersky.nl/abnamro/uitleg.html 

 

Is this the end of strong authentication?

In my opinion absolutely not, but I hope all our readers will think twice before logging in on their online banking from e.g. a cybercafe while on holiday. The strong authentication alone will not defend you from everything.

Similarly I hope people signing transactions actually learn what they are signing and verify it before typing the numbers.

Banks should teach their users to verify what they sign and perhaps need to abandon systems where you can sign multiple transactions in one go or where you can transfer money without signing the transaction. Logging in once again isn't a non-repudiable signature.

Risk management could be used to determine maximum risks the bank is wiling to take in order to achieve ease of use for the customers, but care has to be taken on who takes the risk when technically non-reputable signatures have been used.

As Winfried put it: "nothing of an infected computer can be trusted".

A note to the US based readers and/or people working for US based banks: plain old passwords are much easier to attack than one time passwords and they can be attacked at any time. OTP (one time passwords) significantly raises the bar for an attacker, that it too can be overcome is no reason whatsoever not to make it harder on the attackers.

--
Swa Frantzen -- NET2S

Keywords:
0 comment(s)
Diary Archives