SNMP v3 trouble
SNMP typically isn't the most loved protocol when it comes to security, most of this stems from the older versions. The current version (SNMPv3) has a way to do authentication using a keyed-Hash Message Authentication Code (HMAC) HMAC.
It seems CERT is coordinating a vulnerability regarding this: "Implementations of SNMPv3 may allow a shortened HMAC code in the authenticator field to authenticate to an agent or a trap daemon using a minimum HMAC of 1 byte." Which obviously isn't the right thing to do.
Cisco has a security advisory on the topic, as will other vendors without much doubt.
--
Swa Frantzen -- Gorilla Security
Linux ASN.1 BER kernel buffer overflow
Basic Encoding Rules (BER) is an encoding format in ASN.1 . The linux kernel implementation has a buffer overflow in it allowing a kernel compromise. It affects the CIFS and ip_nat_snmp_basic modules.
Updates available in Linux 2.6.25.5
More information:
- CVE-2008-1673
- Changelog at kernel.org
--
Swa Frantzen -- Gorilla Security
Ransomware keybreaking
Some interesting bits about some new "ransomware". It's malware that encrypts the victim's data and asks to be sent money for the decrypting software. As such there is nothing spectacularly new were it not that it seems the attacker seems to have properly used cryptography to get it done: RC4 for the bulk of the work and then a 1024 bit RSA key public key to hide the RC4 key.
Well so far it looks like the malware author upped the ante and made it harder for the AV world to beat him. Especially since the largest RSA key ever to be publicly broken only weighs in at 663 bit length, not 1024 (which makes a huge difference!).
Kaspersky launched a project to ask for help in breaking the key. This would take about a year with millions of computers, so it's not something trivial to take on.
But there are a few problems here beyond the cryptographic challenge.
First, how do we know the attacker won't change the key before we're done. After all, it'll take him merely minutes to swap the key in a new strain of his malware and we're set for another year ? This isn't a race we're going to win.
It gets worse when reading Eran Tromer's writing over at MIT:
How do we know this public key (or his next key, or the one after that), is a key the attacker actually has the matching private key for? How do we know for sure this key doesn't belong to somebody else and by giving out the private key to thwart the apparent attacker we're actually helping him in his real attack against somebody else. This could be settled by letting -through the right trickery- proof the attacker that he actually has the key.
But suppose we don't get the proof, how do we know it's not even far worse and that this public key belong to some infrastructure we rely on to keep things safe ? Imagine the key belonging to a CA used to sign SSL certificates ... we'd be causing a whole lot of damage by making such a secret key known. Imagine the key belonging to a bank's https site, it would become vulnerable to a MitM attack without the customers getting so much as to have to click next on their attempts to connect (yeah, why browsers even allow you to do that, but that's another story).
I'd propose old fashioned police work instead: follow the money, seize the private key (if he has it) and throw the criminal(s) in jail for a very long time.
Some links:
- Kaspersky press release
- Description of the malware on viruslist
- Kaspersky stop Gpcode forum
UPDATE: Chris wrote in to remind us that backups are a great way to recover files.
- You do make backups?
- You do keep them around for long enough?
- You keep them off-line?
- You do test the restore every so often?
More on backups from our awareness tips by Mike Poor.
UPDATE: A reader pointed us to a zdnet blog that seems to report on contacting the bad guys behind the attack. For those considering this: be extremely careful doing this. not just not to encourage them in continuing, but far worse for your own safety.
--
Swa Frantzen --- Gorilla Security
June 2008 Black Tuesday Overview
Overview of the June 2008 Microsoft patches and their status.
# | Affected | Contra Indications | Known Exploits | Microsoft rating | ISC rating(*) | |
---|---|---|---|---|---|---|
clients | servers | |||||
MS08-030 | A vulnerabilities in the Bluetooth stack allows code execution when a large number of SDP (Service Discover Protocol) requests are made. | |||||
Bluetooth CVE-2008-1453 |
KB 951376 | No publicly known exploits | Critical | Critical | Important | |
MS08-031 | Multiple vulnerabilities in MSIE allow code execution and cross domain information leaks. The memory corruption gives access to the same rights as the logged-on user has. The vulnerability in parsing headers allows for HTTP Request Splitting, HTTP Request Smuggling and more (See CVE-2008-1544 for more details). Replaces MS08-024. |
|||||
MSIE CVE-2008-1442 CVE-2008-1544 |
KB 950759 |
Details on attacking CVE-2008-1544 are publicly available | Critical | PATCH NOW | Important | |
MS08-032 |
A vulnerability in the Speech API accepts commands sent to it over the speakers of the computer, allowing an attacker access to the same rights as the user has. The speach recognition must be enabled for this to work. |
|||||
ActiveX Kill Bits CVE-2007-0675 |
KB 950760 | Publicly discussed | Moderate | Important | Less Urgent | |
MS08-033 |
Multiple input validation vulnerabilities allow code execution in DirectX. Affected are MPEG streams in ASF and AVI files and parameters of SAMI (Synchronized Accessible Media Interchange) files. |
|||||
DirectX |
KB 951698 |
No publicly known exploits | Critical | Critical | Important | |
MS08-034 |
Privilege escalation vulnerability in WINS allows an attacker to gain complete control of a vulnerable system by sending crafted packets to the WINS server. |
|||||
WINS |
KB 948745 |
No publicly known exploits | Important | Less Urgent | Critical | |
MS08-035 |
Input validation failure in the LDAP implementation part of AD leads to a Denial of Service. |
|||||
Active Directory CVE-2008-1445 |
KB 953235 | No publicly known exploits | Important | Less Urgent | Critical | |
MS08-036 |
Multiple input validation failures in the PGM packets allow a Denial of Service. PGM is active when MSMQ (Microsoft Message Queuing) is installed on a system. |
|||||
PGM (Pragmatic General Multicast) CVE-2008-1440 CVE-2008-1441 |
KB 950762 | No publicly known exploits | Important | Important | Important |
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- 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.
--
Swa Frantzen -- Gorilla Security
Upgrade to QuickTime 7.5
Apple released earlier QuickTime 7.5, which a.o. fixes a number of security bugs.
Apple's security improvements include fixes for:
- CVE-2008-1581: PICT images can lead to an heap overflow and code execution
- CVE-2008-1582: AAC coded media can lead to code execution
- CVE-2008-1583: PICT images can lead to an heap overflow and code execution
- CVE-2008-1584: Indeo video codec can lead to a stack buffer overflow and code execution - note the fix: "This update addresses the issue by not rendering Indeo video codec content."
- CVE-2008-1585: handling of file: URLs in QuickTime files could lead to an attacker controlled application launch and code execution - note the fix: "This update addresses the issue by revealing files in Finder or Windows Explorer rather than launching them."
--
Swa Frantzen -- Gorilla Security
VLC: needs upgrading too!
One of those little things your users might manage to get installed for themselves is VLC.
Well they too have a new release that passed by all too quietly in the last few days. Barry reminded us about it.
So VLC Media Player 0.8.6h is the one you want to upgrade to, it fixes "security vulnerabilities in the Mozilla and ActiveX plugins, in the libpng, libid3tag, libvorbis libraries and in the Speex codec."
From their release notes:
- Updated GnuTLS and libgcrypt (CVE-2008-1948, CVE-2008-1949, CVE-2008-1950)
- Updated libxml2 (CVE-2007-6284)
0.8.6g (source release):
- Removed VLC variable settings from Mozilla and ActiveX (CVE-2007-6683, VideoLAN-SA-0804)
- Removed loading plug-ins from the current directory (CVE-2008-2147, VideoLAN-SA-0805)
- Updated libpng (CVE-2008-1382)
- Fixed libid3tag denial of service (CVE-2008-2109)
- Fixed libvorbis vulnerabilities (CVE-2008-1419, CVE-2008-1420, CVE-2008-1423)
- Fixed speex insufficient boundary check (CVE-2008-1686, oCERT-2008-004)
Make sure to be warned by the smallest vendor/software maker of who you use software or soon or later you'll miss one getting its patch before you discover it's been exploited.
--
Swa Frantzen -- Gorilla Secuity
Comments