Wednesday, February 23, 2011

 

Facebook HTTPS: Is Done Better Than Perfect?	Posted by Sean @ 20:33 GMT

My Facebook account finally provided me with the option to use an HTTPS connection "whenever possible" last week.

The option is located under the Account Security section of the Account Settings page:



So I selected the option and saved my changes:



And now, Facebook defaults to a secure HTTPS connection:



Or so I thought… (more on that below).

Today I did a Facebook search for "http:// omg" and came across some spam.

Typical Facebook spam bait — see who stalks your profile:



Clicking the link prompted me with this notification:



Okay… well, I guess this application can only be viewed with an HTTP connection.

So I clicked the Continue button.

And this is the application's Request for Permission:



Hmm, so just who is the developer of "Who Spends Watching Your Profile?"?



Justn Bieber? Justn?

Right. Well, now we know the target group of this particular spammer.

Justn Bieber seems to spend his time commenting on a Justin Bieber fan page:



I reported the spam application to Facebook and moved on…

A bit later, I noticed that my connection was no longer secured:



Wait, what?

I checked my settings:



My security settings are undone? But the option is supposed to be "whenever possible", so the earlier prompt about switching to a "regular connection" was just temporary, right?

No.

I tested several times and each time I found an application that asked me to "continue" to a "regular connection", my default Account Security settings reverted to HTTP.

I'm not the first to notice this. Facebook is aware of the issue and is working to make SSL preferences persistent.

I'm sure there are cynics out there that will say that Facebook does stuff like this deliberately. Personally I don't think so. I think it's just an oversight on their part.

Why?

Take a look at this photo from Facebook HQ:



What do you see? (Not Katy Perry, look again.)

There, above the door. Do you see the words "move fast and break things" and "done is better than perfect"?

And I get it. I do. Facebook is driven to innovate.

They need to in order to grow and stay at the front of social networking (with Google eager to usurp them).

But is done really better than perfect when it comes to Account Security settings?

It doesn't need to be perfect, but personally, I think fully baked is better than half baked.

Half baked only causes confusion in the long run.

So then why do we get half baked results? Frankly, I blame Twitter (in part).

Seriously.

The Blogosphere is now the Twittersphere, and when Firesheep started making news last October, the Twittersphere started to tweet. And Facebook? They gave the masses what they were demanding, an HTTPS option.

And it probably doesn't really matter when it's fully baked… the Twittersphere probably won't notice anyway, it will be busy tweeting about the next trending topic.

Regards,
Sean
 
 

 
 

Tuesday, February 22, 2011

 

So It's a Scam AND Phishing Attempt	Posted by WebSecurity @ 03:00 GMT

Our earlier post about malicious links being spammed out on Facebook said that the links were phishing attempts. Well, turns out it's also an adware scheme.

So the links we saw being sent around led to a fake Facebook log-in page:



Looks like a plain vanilla phishing attempt so far. However, further testing with a dummy account showed that something a bit more interesting is going on.

If you enter your account details into the supposed log-in page, you're directed to this enticing notice:



Who doesn't want a free iPad, right? If you then click on the "Claim Now" buttons for any of the oh-so-lovely prizes, you then get taken to this site:



Still no prizes. If you click on the big shiny button on that page, you get this:



And if you do download that, you get a consolation prize of… adware. And you just paid for it with your account details. Shortly afterwards, Facebook notified us about some suspicious access activity in our dummy account:



No, that's not where we are. Clicking the "I don't recognize" button led to a new password creation page, from which we could recover the dummy account.

OK, so this scam is not terribly new or original. We blogged about a roughly similar scheme running around Twitter in August of last year.

Fortunately, the links directing users to these sites are now inactive, and most of the related sites seem to be down. Our product also detects and removes the downloaded adware.

Still, stay alert and stay safe.

Response Post by — Shantini
 
 

 
 

Monday, February 21, 2011

 

ZeuS Mitmo Strikes Again: Polish ING Bank	Posted by Sean @ 13:50 GMT

Breaking news from Poland today: A variant of the ZeuS trojan is targeting the mobile phone based, two-factor authentication used by ING Bank Slaski (Polish ING Bank).

Security consultant and blogger, Piotr Konieczny, has details on his blog, Niebezpiecznik (Google Translate).



From the details that we've gathered so far, this appears to be the same type of ZeuS Man-in-the-mobile attack that took place in Spain last year. Spanish security company, S21sec, first reported on ZeuS Mitmo here.

ZeuS Mitmo is designed to steal mTANs, and computers infected with a ZeuS Mitmo trojan will inject a "security notification" into the Web banking process, attempting to lure the user into providing their phone number. If a phone number is provided, the user will receive an SMS link pointing to the mobile component, ZeusMitmo.

—————

Updated to add on February 23rd: SHA1 hashes related to this case (thank you, Piotr).

Trojan-Spy:W32/Zbot.AHSO: f85d51e4f171b2a3c3a42bf306d86c6587069cf0
Trojan-Spy:SymbOS/ZeusMitmo.B: 1045daa75c457aa5d8883531ea29b5c8dcf9cc2d

—————

Updated to add on February 24th: Nokia has revoked the certificate used by Symbian based ZeusMitmo.B.

For this to have a practical effect, you should configure your Symbian phone to perform an online certificate check by default. See our March 26, 2010 post for details.

There's also a Windows Mobile binary associated with this new Mitmo case. Axelle Apvrille has written about it over on Fortinet's blog.

Here's the SHA1 and our detection name:
Trojan-Spy:WinCE/ZeusMitmo.A: e93d8723c23523fc064d331bd97985fe3280ea09
 
 

Friday, February 18, 2011

 

Another Facebook Phishing Scam Run	Posted by WebSecurity @ 06:21 GMT

Phishing scams in Facebook. It's not new and it's not sophisticated. But they still catch the unwary and they're still happening now, with only minor tweaks in tactics.

At 2010's end, we saw a run of phishing links being sent around via the chat feature. We're seeing a new run at the moment. The following links are sent (from hijacked accounts) through chat messages and posts on the Walls of randomly selected friends:

  •  http://apps.facebook.com/dealscentral[...]/dsuguo[...]/
  •  http://apps.facebook.com/reallytimeto[...]/
  •  http://apps.facebook.com/backseatdriver[...]/
  •  http://apps.facebook.com/fishingfor[...]/

The links look as if they would go to an App, but they instead just take the user to pages that look like the real Facebook log-in page:





Obviously, those page URLs aren't legit.

Nothing fancy here, but stay alert and stay safe anyway. This looks to be a small run at the moment, and it would be nice if it died out quick. At time of writing, the first phishing link listed above is no longer active, but the others still work.

You can read more about phishing, or learn how to report a suspected scam, on Facebook's Security Page.

Regards,
Shantini
 
 

 
 

Thursday, February 17, 2011

 

Analysis of MBR File System Infector	Posted by Response @ 04:48 GMT

It is very common to see Portable Executable (PE) file infector viruses. It is a bit more unusual to see file infection via the raw file system — in this case, a Master Boot Record (MBR) file system infector.

Partly this is because PE infectors are less troublesome to create — they can be more robust, are easier to develop, and to control. In contrast, MBR infectors are more complex and their size is limited to 62 sectors (7C00H). Also, there's less room for error — a small mistake or bug in an MBR file system infector causes the system to be unbootable.

So an MBR file system infector such as Trojan:W32/Smitnyl.A (98b349c7880eda46c63ae1061d2475181b2c9d7b), which appears to be distributed via some free file-sharing networks, seems worth a quick analysis, even if it only targets one portable executable system file and the infection is straightforward compared to common virus file infectors.

Smitnyl.A first infects the MBR via raw disk access. Then it replaces it with a malicious MBR containing the file infector routine (stored at sector 32).

Image 1 & 2: Overwriting original MBR, Part 1 (top) and Part 2 (bottom)




Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.

The original MBR is stored at sector 5, while the infector payload starts at sector 39 with size A00H. This payload will be overwritten to the Windows critical system file, userinit.exe.

Image 3 & 4: Hex views of infected MBR (left) and original MBR (bottom)




Image 5: Hex View of MBR File System Infector Routine


Image 6: Hex View of Userinit Infector Payload


Why Userinit? Possibly because it is one of the processes launched automatically when the system starts, allowing the malware to execute automatically when the system starts.

Smitnyl infects Userinit from the first stage of the boot sequence. When the MBR is loaded to 0x7C00, it determines the active partition from the partition table and also the starting offset of boot sector.

It then checks the machine�s file system type:

Image 7: Determine Boot Sector Type


If an NTFS file system is found, it parses the Master File Table (MFT) and reads the attributes of $ROOT (.) file record to locate the $INDEX_ALLOCATION attribute, in order to determine the raw data of Userinit in the disk (assuming the MFT is parsed correctly). Smitnyl will check for the Windows path from $ROOT down to the System32 directory, where userinit.exe is located.

Image 8 & 9: Locate Userinit.exe, Part 1




The malware uses the get_userinit_data_content_addr routine to find the userinit.exe file, which then uses the Extended Write Function (with function number ah = 43H) to offset and write the infector payload at sector 39. During the userinit.exe infection routine, the malware also checks for the presence of an infection marker at offset 0x28 (more on that later).

Image 10 & 11: Locate Userinit.exe, Part 2




After the machine is successfully booted up with the infected MBR, userinit.exe should be infected and launched automatically. One way to identify the infected userinit.exe is by checking the file properties.

Image 12 & 13: userinit.exe Properties, original & infected


Fortunately, the difference is pretty obvious.

Let see the infected file in hex view:

Image 14: Infected Userinit


Remember we mentioned the infector routine will check the infection marker 0x55AA before infecting? So what is it trying to do when it is executed? Its major payload is to launch an encoded executable, located at sector 45:

Image 15: Encoded Executable File at Sector 45


It has some preliminaries to do before it starts decoding and launching the final payload:

  •  Check for the presence of 360safe antivirus. If found, 360safe IE browser protection is disabled.

Image 16: 360safe IE Protection Registry Key Checking


  •  Create a fake explorer.exe in a temporary folder — this is the decoded executable.

Image 17: Fake Explorer with Decoded Executable


Image 18: Fake Explorer with Decoded Executable


  •  After decoding, it launches %temp%\explorer.exe using ShellExecute — this serves as a decoy to hide the infection. At the same time, it will execute the real explorer.exe using Winexec.

Image 19: Execute fake explorer.exe and launch original explorer.exe


Once the preliminaries are done, the payload is launched.

Image 20: Final Downloader Payload


Fortunately, there is nothing special about the final payload — it is merely a downloader. The infected userinit.exe disables 360safe's IE browser protection so that the downloader can retrieve files from the remote server http://[...].perfectexe.com/.

Response Post by — Low Chin Yick
 
 

 
 

Wednesday, February 16, 2011

 

Trojan:Android/Adrd.A	Posted by Response @ 08:46 GMT

A few days back, Mikko tweeted about a new Android trojan named ADRD (we detect it as as Trojan:Android/Adrd.A).

ADRD was mostly found included in several applications from a third-party application provider in China, with the applications repackaged to contain the trojan. So far, most of the infected applications have been wallpaper-related.

Here is an example of an infected application:



An installed application infected with ADRD may show these permissions:



These permissions enable ADRD to start its routine during phone start up, changing of data connection such as enabling/disabling network data access. Some of its permissions may include access to the SD card, the phone and the Access Point Name(APN) settings.

ADRD's functionality appears to involve contacting a remote host, which may be:

  •  adrd.tax[..].net
  •  adrd.xiax[..].com

and sending the phone's info — specifically, the International Mobile Equipment Identity (IMEI) and International Mobile Subscriber Identity (IMSI). Data being transmitted is DES encrypted.

The remote host will reply with a list of links, one of which ADRD will randomly select and connect to using its simple internal random generator. When the selected link is contacted, it returns a predefined search string that ADRD processes and runs the search in the background.

Example:

1. The ADRD random number generator produces a number pointing to its array of list obtained from the remote host,
let us say http: //59.[...].12.105 /g /g.[...]?w=959a_w1.

2. This link actually contains the search criteria that the ADRD will use,
an example would be:

http://wap.baidu.com/s?word=%e5%[...]e5%89%a7%e7%85%a7 &vit=uni&from=979a

which ADRD will process and run in the background.

Another functionality is the possible downloading of an APK named myupdate.apk, which is saved to /sdcard/uc /folder. This is possibly for its update component.

ADRD's network access may lead to high data usage, which in turn may lead to high data charges. ADRD appears to be distributed only in Chinese markets and may only be specific to Chinese networks, as we've seen it connect to "cmnet", "cmwap" (China Mobile Net), "uniwap", and "uninet" (China Unicom).

Response Post by — Zimry Ong

—————

Updated to add on Feb 11, 2011: Aegislab (who discovered this trojan) have shared some of their samples with us and we did several comparisons to verify these were the same ADRD we had discovered. As it turns out, there are several mostly minor differences between the two sets. Most of the changes are actually fixes of URL handling and improved exception handling on most of its routine. So we are guessing that this trojan has probably been in the wild and fixed at some point.

Since there is not much change in its functionality, we have decided to still detect them as Trojan:Android/Adrd.A. Here are some SHA1s of the Android Application (APK) for reference:

53dc08f08005f374a957afa44607ab52f205b684
2161f757a8adcd48bd37f6d78ce1201a0bde4dab

By the way, it may come to your attention that some other AV vendors are classifying ADRD as a Geinimi variant (179e1c69ceaf2a98fdca1817a3f3f1fa28236b13), so hopefully if you are closely following Geinimi or ADRD, you will not get confused. From our point of view, Geinimi and ADRD differ due to the fact that Geinimi can be classified as a a classic Backdoor for its vast command and control commands, whereas ADRD can be classified as a classic Trojan-Clicker.
 
 

 
 

Tuesday, February 15, 2011

 

News of AutoRun's Death Has Been Greatly Exaggerated	Posted by Sean @ 13:56 GMT

Last week, I applied Microsoft Updates to one my Windows XP test machines and noted an optional update which restricts "AutoRun entries in the AutoPlay dialog to only CD and DVD drives".



You can see from the image above that the update is optional.

Yet, a Microsoft blog post about the update called it an "important, non-security update".

Important updates are automatically applied by Microsoft Updates.

And so there was much rejoicing and AutoRun was declared dead.

But not so fast!

Larry Seltzer's technically accurate (based on Microsoft's statement) story about trimming AutoRun was followed up by another story with a correction from Microsoft.

"The functionality change to Autorun is, for the moment, marked as Optional for Windows XP. Users who have automatic updates set to install both Optional and Important updates have already begun to receive the update. We plan over the next few weeks to re-set the change to Important, allowing it to reach the remainder of the Automatic Update-using XP community."

"Microsoft says that this was a miscommunication and not a mistake."

And so AutoRun lives on, and even after Microsoft adjusts the update from optional to important for Windows XP, update KB971029 only limits non-optical media functionality.

So… to limit AutoRun, manually run Microsoft Updates. To completely kill AutoRun, click here and use the "fix it for me" option.

Regards,
Sean
 
 

 
 

Sunday, February 13, 2011

 

Stuxnet, Once Again	Posted by Mikko @ 17:41 GMT

Stuxnet — the most important malware we've seen in ages — has some interesting features when you look at it from a forensic viewpoint. For example, whenever it infects a new system, it records the date & time and some system information about the computer it just infected.

Which makes it possible to create a timeline of how Stuxnet spread.

We shared all Stuxnet samples we had collected with Symantec. Overall, they were able to collect more than 3000 unique samples from multiple security vendors.

Then they cross-references the samples to dig up some interesting facts. Such as:

  •  Stuxnet was a targeted attack on five different organizations.
  •  They were targeted in June 2009, July 2009, March 2010, April 2010, and May 2010.
  •  All targeted organizations have a presence in Iran.

You can find more information from their blog post.





 
 
 

 
 

Friday, February 11, 2011

 

Nokia Windows Phone & Security	Posted by Mikko @ 11:44 GMT

Nokia announced today that they will adopt Windows Phone as the primary operating system for its future smart phones.

Coming from the world's largest mobile phone manufacturer, this is a historic announcement.

While the vast majority of PC malware is written for Windows, Windows Phone 7 is a entirely different ballgame.

The security model of Windows Phone 7 is quite different from Windows XP/Vista/7/et cetera, and includes features such as Application Certification, Isolated Storage, and Application Isolation. For example, third party applications can not run in the background because of security concerns.

Windows Phone 7 and XBOX are the only Microsoft platforms where applications must be pre-approved by Microsoft before users can run them.

As a result, we don't expect any major mobile malware outbreaks just because of Nokia's partnership.





 
 
 

 
 

Wednesday, February 9, 2011

 

Restrict USB Autorun: Update for Windows (KB971029)	Posted by Sean @ 13:13 GMT

Among yesterday's optional software updates from Microsoft was Update for Windows XP/Vista/non-Windows 7 (KB971029).



It's an "important, non-security update" that restricts "AutoRun entries in the AutoPlay dialog to only CD and DVD drives".

Excellent. This could really help curb AutoRun worms. If you're using an older Windows computer, we highly recommend you go and apply this optional update.

You'll need to visit update.microsoft.com and select "Custom" updates.



And you'll find KB971029 in the "Software, Optional" category.



This update restricts USB AutoRun functionality in the AutoPlay dialog. You may also wish to take further steps and disable AutoPlay completely. See here and here for posts on that topic.

---

 
 

 
 

Are you sure SHA-1+salt is enough for passwords?	Posted by Jarno @ 08:39 GMT

The anarchic Internet group called Anonymous recently hacked HBGary Federal and rootkit.com, an online forum dedicated to analyzing and developing rootkit technologies. All user passwords at rootkit.com have been compromised.

Given this compromise, I'd like to point out one of my favorite topics in application security — password hashing.



It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be.

Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords.

And this is the assumption any security design should be based on; an attacker has access to everything that is on the server.

Salt is primarily intended to prevent precomputed attacks, also known as rainbow tables. And a common assumption has been that as long as precomputed attacks are prevented, passwords are relatively safe even if attacker would get the salt value along with user password.

But MD and SHA hash variants have been designed for computational speed, which means that an attacker can easily get billions of brute force attempts per second when using a video graphics display card for processing.

See: http://www.golubev.com/hashgpu.htm

Which means that even with single ATI HD 5970, an attacker can cover password space equivalent to a typical rainbow table (2^52.5 hashes) in 33 days. And it's a safe bet that a serious attacker will have more than one card for the job.

When an attacker has your salt values and code, the only thing that is protecting user accounts is the strength of passwords they are using, and people are not very good sources of entropy. By combining dictionary attack and brute force techniques it will not take very long to break a significant proportion of passwords, even for a large site with many accounts.

So what should be done to avoid this?

The first thing to consider is that passwords are very much like safes in the real world, what matters is not only the length of the code needed to open the safe that protects the contents, but also how long each attempt takes.

This clearly means that SHA1 or any other plain hash algorithm is clearly a no go for secure password authentication.

What you want to use is something that will not be trivial to brute force. Instead of doing 2300 million attempts per second, you want something that limits an attacker to 10,000 or 100,000 attempts per second.

And while using salt values is vital to proper implementation, it is not a silver bullet which will make your problem go away.

This requires a password hashing scheme that fulfills the following properties:

  •  Computational time required can be adjusted easily when processing power increases
  •  Each user can have unique number of iterations
  •  Each user hash is unique so that it is impossible to find out if two users have same password by comparing hashes

There are several such schemes to choose from:

  •  PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
  •  Bcrypt http://www.openwall.com/crypt/
  •  PBMAC http://www.rsa.com/rsalabs/node.asp?id=2127

Each of the alternatives has their strengths and weaknesses, but all of them are far stronger than general purpose hash implementations such as SHA1+salt.

So if you are working with passwords, pick one of the schemes above, determine the number of iterations it takes your server check the password for the desired length of time (10, 200ms, et cetera) and use that. Have a unique salt value and iteration count for each user — anything that forces the attacker to focus on each account separately rather than being able to try against all accounts on each iteration.

Updated to add: I had accidentally put HMAC on the list of suggested schemes when I should have put PBMAC. Props to Matthew and Sagres for pointing out the error.

---

 
 

 
 

From Brain to Stuxnet: 25 Years of Computer Viruses	Posted by Mikko @ 07:57 GMT

We've just published a video going through the last 25 years of PC malware history in 9 minutes.

The video contains several demos of what old viruses used to look like.

Check it out here.


 
 

 
 

Tuesday, February 8, 2011

 

Safer Internet (Update) Day	Posted by Sean @ 16:46 GMT

February 8th is Safer Internet Day, a day devoted to making the Internet a better place for children. And before your child goes online… make sure their computer is up to date with secure software. There are lots of updates and patches to install this month.

Microsoft's Security Bulletin includes a critical update for Internet Explorer that affect all versions of IE.



Note that the least affected OS is Windows XP Service Pack 3. That's because Service Pack 2 was retired from the update cycle last year. Children are often provided "hand-me-down" computers. Before giving a child old hardware, make sure the current service pack is installed. You should also consider an alternative browser.

But then again, alternatives aren't worry free either.

Google recently patched Chrome to version 9.0.597.84.

VLC media player, another popular alternative, has a flaw when parsing an invalid MKV file that could allow a malicious attacker to trigger an execution of arbitrary code. VLC media player 1.1.7 addresses this issue, so either update, or avoid untrusted downloads (and sites if you have the VLC plugin installed).

Adobe is also publishing an update today for Adobe Reader and Acrobat. Affected versions include Adobe Reader X (10.0) and earlier versions for both Windows and Macintosh.

Updated to add: There is also a security update available for Adobe Flash Player.
 
 

Monday, February 7, 2011

 

Taking Poika Out on the Town	Posted by Mikko @ 15:19 GMT

We Finns hate the Swedes.

It's a hockey thing.

You see, hockey is the national sport in Finland. And we almost always lose to Sweden.

But when we don't lose, we celebrate heavily.

One tradition we have is that our hockey team take the Trophy with them everywhere. And the trophy is always called "Poika" (Finnish for "Son").

Now, F-Secure has just won the AV-Comparatives Product of the Year award.

Here's the Trophy we got:



We figured we have to keep up the tradition.

Here's our Poika out on the town:


Poika by our HQ


Poika outside the Helsinki Cathedral


Poika in downtown Helsinki


Poika in the Park


Poika alone in the snow


Poika in the Esplanadi Park


Poika by Valtioneuvoston Linna


Poika by the Sea


Poika and the Market Square


Poika looks at the frozen sea


Poika heating it up in the Sauna


Poika and the Kiasma art gallery


Poika and the House of Parliament (left)


Poika chilling it out with Nikolai II

P.S. In the latest test from both AV-Comparatives and AV-Test.org (link) we beat everyone else. The tests included both detection rates as well as speed. Which makes us the The Best Antivirus in The World�.