| |
Home / Weblog / August 2009
Analyst's Diary
| Aleks | August 31, 2009 | 08:23 GMT |
comments (1)

|
On 28th August, the latest update for MaxOS X was released - Snow Leopard. Version 10.6 differs in one very telling way from previous versions - for the first time in Apple's long history, the company's implemented an antivirus scanner. Rumours about the antivirus function in the release build of Snow Leopard surfaced a few days ago. Screenshots showing a window detecting one of the well-known Trojans for MacOX were published on the Internet. The effect was pretty explosive - it wasn't so long ago that Apple made a very inconsistent statement about the necessity (or rather the lack of it) for antivirus for their operating system. Official company spokespeople declined to comment on this issue prior to the release of version 10.6, hinting that after 28th August, they might be able to say more. And now the release date has been and gone, with the facts of the matter that managed to leak out having now been confirmed. Those diligent researchers who managed to get their hands on build 10a421A found out it included this file: System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist which contains 5 very simple signature records for two Trojan programs This is something Apple developed itself, and it's got nothing in common with Clamav, as some people thought. It's pretty clear why Clamav hasn't been used - Apple didn't want something with a GPL license (which is how Clamav is licensed) in its code. And Apple isn't linked to any of the AV companies currently in existence. Intego, a company which develops its own AV for MacOS did some research which highlighted these key points:
- The built-in antivirus only scans files which have been downloaded via Safari, Mail, iChat, Firefox, Entourage and a few other browsers. It doesn't scan files from other sources - for instance, torrent or ftp files.
- The antivirus is only able to detect two Trojans, even though the AV industry knows of several dozen malicious programs which target the Mac operating system.
- The antivirus updates itself via Apple standard updates.
A number of experts have expressed the opinion that this sort of AV solution can't provide proper protection, and, what's more, lulls the user into a false sense of security. I'm in complete agreement. This antivirus is clearly analogous to the Microsoft Removal Tool for Windows, and this sets up a whole range of challenges for Apple. It means that Apple is de facto entering into competition with other antivirus companies and has become a member of the antivirus industry, If the company's done that, then it should have all the appropriate departments - a virus lab, a monitoring service, antivirus technical support etc. At the moment Apple doesn't have any of these things. But it does have its "antivirus". Is Apple ready to follow Microsoft, which ended up getting involved in antivirus and consequently dedicating a lot of time and resources both to antivirus and modifying other of its products in order to solve security issues? I'm not sure. Additionally, the appearance of an antivirus in MacOS may nudge virus writers into creating large numbers of malicious programs for this platform. It's a red rag to a bull - and someone's already waved it. On the one hand, Apple isn't offering its users any real protection with this antivirus. On the other, it's now not only entered into competition with other antivirus companies but it's also joined the cybercrime arms race. Right now it looks to me as though Apple's got itself into a very unenviable position. P.S. You can get the beta version of Kaspersky Anti-Virus for MacOS here :)
| Aleks | August 29, 2009 | 19:25 GMT |
comments (3)

|
There's been a lot of fuss in the media lately, with news from all the major antivirus companies being printed and reprinted. And all the news is on the same topic – something we haven't seen since Kido (Conficker) and the latest Adobe vulnerabilities. The source of all the fuss? Virus.Win32.Induc.a. Induc was such an unusual case that initially we just published a short blog giving technical details about the virus. Now there's time to step back, take a breath, and assess Induc's real impact. The name relates directly to the virus functionality. Once it's on the victim machine, it checks to see if Delphi is installed – it targets versions 4.0, 5.0, 6.0 and 7.0. If it detects one of these versions of Delphi, it copies the .pas file it's going to use (in this case, sysconst.pas) to \Source to \Lib and adds its code to the file. It makes a backup of sysconst.dcu, calling it sysconst.bak, and compiles the infected .pas file, which results in a new sysconst.dcu containing malicious code. The infected .pas file then gets deleted. So we've got a virus which adds its code to a file with a .dcu extension – you could say the code is "in dcu". Swap a couple of letters around (which is what we usually do when naming viruses) and you get Induc. (Of course, sometimes viruses get given different names by different antivirus companies. Everyone calling this virus Induc is a sign that we really were the first to add detection and disinfection for this piece of malware – it's usually the first name given that tends to stick.) Once the virus has successfully injected its code into sysconst.dcu, any Delphi program compiled on the machine will be infected. There's no other payload apart from the fact that Induc can spread itself. The interesting thing is the way in which it spreads – it's doesn't infect exe files, but programming language compilation files. This isn't a new approach. Some of you might remember a similar virus from the 1990s, a virus which targeted MS-DOS and infected Pascal files. There are other examples from the more recent past: Lykov, for instance, which appends its code to Visual Basic program source files, first appeared in 2003. Its successor, Lykov.b, which infects VB.NET program source files, showed up a couple of years later. But as far as we know, no-one's tried to directly infect the service files of a compiler before. This approach is so unusual that it doesn't fit anywhere in our current classification system. Induc isn't a virus in the strict sense of the word, because it's doesn't directly infect files. It modifies a single system file rather than every file which it finds. Induc can't be called a worm, and it can't be called a Trojan either, even though it does possess certain hallmarks of such types of malware. So Induc really is something new. The second interesting point is how widely the virus has spread. The day after we added detection, data from Kaspersky Security Network showed Induc was one of the 70 most common malicious programs. It wouldn't be any surprise if Induc appeared in our Monthly Malware Statistics in August. It's possible that there are millions of copies of Induc around the world – maybe an epidemic no smaller than the one caused by Kido! The third interesting point is the applications infected by Induc – the virus ended up on developers' computers among others, and some of these developers were creating very popular applications. For instance, we've seen several infected versions of AIMP media player as well as QIP, the popular instant messaging client. Induc's been detected in applications around the world, on software sites, and on magazine giveaway software CDs. The fact that Induc's been found in legitimate applications, many of which have been whitelisted by vendors, has created another problem. This time it's a headache for the industry which offers whitelisting, in the main, via in-the-cloud technologies. Once infected files were detected in the databases of clean files, these databases had to be cleaned. This highlights the weakness of such databases, and if similar incidents happen in the future, trust in whitelisting will certainly start to suffer. Disinfecting infected files isn't a trivial matter. Although it's possible, it can have negative results: a lot of programs (for instance, QIP) perform an integrity check on startup using a checksum. However, as QIP was infected at compilation stage, the checksum created includes the malicious component, so once disinfected, QIP won't work correctly. However, programs which don't perform this integrity check still run correctly after disinfection. When we started to receive infected files, we noticed almost straight away that some Trojan programs designed to steal bank account data were infected with Induc. The authors of these Trojans had themselves fallen victim to a virus – they must have compiled their Trojan files using an infected version of Delphi. All the infected Trojans we saw came from Brazil, even though they'd been created by different groups of virus writers. None of this means that Induc itself was written in Brazil – it's just that this country is one of the few where Delphi is the most widely used programming language (it's pretty popular in Russia too). But let's leave these infected Trojans and move on to the very important question of how long the virus remained undetected in the wild – and why. Just to be clear - the virus was initially identified on 12 August 2009 by a Russian programmer called Aleksandr Alekseev, who's also known as Gun Smoker. He was the only person who came across this virus who wasn't only able to get to grips with what was going on, but he also spread the news throughout the computing community and sent suspicious files to antivirus companies. Thanks, Gun Smoker! Gun Smoker's published a detailed article on his findings (over here, but in Russian only). According to him, infected files first appeared by January 2009. Our data shows infected files dating from November – December 2008, but unfortunately, when compiling files, Delphi doesn't save the link date so we can't tell exactly when these files were created. But we can say with some certainty that Induc has been in the wild for a year. This means we've got an unprecedented situation – a malicious program which stayed 'invisible', undetected by antivirus companies for more than a year. This is even more impressive than Rustock, the rootkit which we covered last year. Before anyone starts pointing a finger, I'd like to defend the antivirus industry: Induc was around for so long because it doesn't do anything which could be detected by current antivirus technologies. Induc doesn't steal data, establish any network connections, and doesn't send spam – it doesn't do anything detectable. If it had any real functionality, Induc would have been identified long ago. And this leads us on to another question – "what will happen if this propagation routine becomes common?" Induc is clearly proof of concept code – maybe it was written to win a bet, or maybe it was created by accident. Of course, the idea used in Induc could be taken up by cybercriminals, but they're not really interested in simple propagation; they want to be able to do something on the infected system. Everything that they can do gets detected by the technologies currently in use. Or, to take a slightly different view, nothing would go undetected for such a long period of time. We're pretty sceptical that Induc's propagation routine will get taken up by cybercriminals – there are plenty of simpler ways to conduct attacks. Nevertheless, Induc's taught us all some valuable lessons. It's shown the antivirus companies that whitelisting isn't perfect, and nor is early threat detection all it might be. It's shown software developers that they need to understand how their programming languages really work. And finally, Induc's shown everyone who uses a computer that even trusted applications may not be as clean as they look.
How much does a credit card cost? |
| Dmitry | August 17, 2009 | 17:15 GMT |
comment

|
The credit crunch means we're all increasingly aware of bank charges, interest rates, and how we can save a few extra pennies. Financial advisors have written pages on how transferring an existing credit card balance to another card issuer could save you money, and most people are shopping around for the best offers. Of course, the APR and other rates don't worry cybercriminals. All they want to do is get their hands on credit card numbers and then use them or sell them on. Who cares if the card owner gets stung with additional charges? What is interesting, though, is the fluctuating price of card data. I was analysing a bit of malware which led me through a number of redirects to a site offering stolen credit card numbers. A sliding scale of prices according to country, and varying availability. And not only are they offering cards from lots of different sources, but the guys behind this are providing a full service, with technical support available from 0900 – 2200 in English and German, and their own type of guarantee:  That the German credit card data costs more, but is guaranteed for a much shorter period seems to contradict free market principles. It seems as though there's demand for numbers from particular countries. This is probably because it's easier to use stolen card numbers from certain countries - this might be because bureaucracy means it takes longer to get the card blocked, because the card issuer returns funds to the victim without too many questions, because there are fewer checks when the card is used on the Internet, or because there's less likely to be a criminal investigation due to local restrictions on law enforcement – the list is pretty long. But even with such a short product life span, these guys aren't doing this for fun - the site is clearly set up as a business, and links to other sites offering cybercriminal services and information.
Induc, the innovative file infector |
| Denis Nazarov | August 17, 2009 | 14:34 GMT |
comments (4)

|
We recently added detection for a file infector to our databases, for something we call Virus.Win32.Induc.a. Since then, we've had a load of questions about it. It doesn't currently have a malicious payload, and it doesn't directly infect .exe files. Instead, it checks if Delphi is installed on the victim machine, looking for versions 4.0, 5.0, 6.0 and 7.0. If the malware does find one of these Delphi versions, it copies SysConst.pas to \Lib and writes its code to it. It then makes a backup of SysConst.dcu, calling it SysConst.bak (dcu files are kept in \Lib). It then compiles \Lib\SysConst.pas giving an infected version of SysConst.dcu. The modified .pas file gets deleted. "uses windows; var sc:array[1..24] of string=('uses windows; var sc:array[1..24] of string=(', 'function x(s:string):string;var i:integer;begin for i:=1 to length(s) do if s[i]', '=#36 then s[i]:=#39;result:=s;end;procedure re(s,d,e:string);var f1,f2:textfile;', 'h:cardinal;f:STARTUPINFO;p:PROCESS_INFORMATION;b:boolean;t1,t2,t3:FILETIME;begin', 'h:=CreateFile(pchar(d+$bak$),0,0,0,3,0,0);if h<>DWORD(-1) then begin CloseHandle', " The result – any Delphi program compiled on the computer gets infected. (We've already had a company contacting us to complain about something they thought was a false positive.) Maybe this particular virus isn't that much of a threat: it's not the first time we've seen this propagation method, the code itself is primitive, there's no other payload, and there are far easier ways to infect machines. But in the past we've seen new infection routines get picked up, tweaked, and taken further. We'll be keeping an eye on this one, just in case.
Not just Twitter, Jaiku too |
| Fabio | August 14, 2009 | 20:30 GMT |
comment

|
Yesterday Arbor Networks reported that malware (which we detect as Trojan-Banker.Win32.Banker.alwa and Trojan-Banker.Win32.Banker.alwe) was using Twitter as a control system to command infected machines. But it's not just Twitter being used by this malware, but Jaiku as well. You might never have heard of Jaiku, but it's very similar to Twitter. And it's being used in the same way, with someone sending commands encrypted in Base64 to an account: Decrypting some lines we can see two links: http://bit.ly/****** http://bit.ly/****** that lead to a page with more Base64 code: This code gets downloaded by the malware, decrypted and saved as an infection component, updating the malware sitting on compromised machines. So Brazilian cybercriminals are right on the money when it comes to finding new attack vectors; although Jaiku isn't anywhere near as popular as Twitter, this attack shows they're out to find as many victims as they can.
Twitter and Adobe – what's the difference? |
| Roel | August 12, 2009 | 02:40 GMT |
comment

|
Today we got another DDoS attack on Twitter. A lot of people are asking why Twitter doesn't seem to be coping with attacks like these. And at the same time there are more and more people jumping on the bandwagon saying stay away from Adobe products. What's the link? Two extremely high profile companies which are being targeted by various cyber criminals around the world. In addition, both of these companies have less than outstanding track records when it comes to security issues. But that's pretty much where the parallel ends. Looking at Twitter over the course of this year what conclusions can we draw? Firstly, Twitter's security doesn't seem to be significantly better than at the beginning of the year. That's a personal opinion, for sure, but that's the way I see it. Secondly, the service is continually increasing in popularity. Twitter is everywhere, and I mean everywhere – check the mainstream media and you'll see dozens of references to Twitter every day. The attacks on Twitter haven't had any real impact on its popularity. Given the service's current business model (whatever that may be), only the DDoS attacks seem to be causing Twitter any real pain. And that same business model might be the reason why Twitter doesn't seem to be investing heavily in security. Maybe fortunately for the Internet community Adobe isn't in the same position. The constantly growing call to move away from Adobe means the company will feel the impact on its business and cause it to invest in security. While it's clearly the market leader, it lacks one critical advantage - there are good mainstream alternatives. As I see it, Adobe's in the same situation as Microsoft some seven years ago. However, Microsoft's main competitor wasn't as mature then as Adobe's is right now. Adobe has a number of competitors in a few areas: There's competition for PDF readers/editors and a number are emerging as viable replacements to Adobe Acrobat/ Reader. Competition for Flash is less clear. Because the Flash format is still proprietary it's pretty much impossible for others to make Flash players that can hold their own against Adobe's own Flash player. There are open source alternatives but their functionality is limited. And it doesn't solve the issue of creating and editing Flash files. The most likely competition for Adobe is going to come from Microsoft. Silverlight hasn't made a real breakthrough so far, but if Adobe (Flash) security issues persist this is undoubtedly going to open a window of opportunity for Silverlight. Abobe or Twitter leaders might well think right now that their best investment is in business areas (i.e. pushing the services/ products) rather than in security. (This particularly goes for Twitter, with the business press reporting that it doesn't currently appear to have a profitable business strategy.) But given today's Internet climate, it's blindingly clear that any good medium to long term strategy has to include security – and this covers secure coding, prompt incident response etc. From my point of view, strategies like this can't kick in soon enough. It's not that I care about the business so much, as the communities that use the services. If we're being encouraged to tweet, share, and spread our data – let's make sure everything we use is as safe as possible (there's no such thing as true safety, but let's do the best we can, eh?)
| Stefan | August 07, 2009 | 15:57 GMT |
comments (1)

|
There’ve been a lot of theories flying around about why Twitter and other services went down yesterday. I've heard rumors about it being linked to political tension between Georgia and Russia, others blame Iran for the outages. Anyone who's saying where the attack is coming from can only base their conclusions on pure speculation. There is no real data to prove who's behind it, and if there would be any clue about the origins of this attack, it would be in the access logs on the victim servers. It doesn't really make sense for *any* government to launch such a DDoS attack just to silence somebody, anybody. An attack can last from a few minutes to a few hours - and after that what? Everything is back to normal, all communications are possible again. Personally, I don't see any advantage that a government would achieve by disrupting access to Twitter or Facebook for 2 or 3 hours. The only thing that I'm sure is going to happen after these incidents is that Twitter will gain even more popularity as a result. Everybody's talking about it, the story is all over the news, all over the world - so the only thing that will happen is that Twitter will be even more popular after this. UPDATE: We've been contacted by quite a few journalists asking about this case, and about Cyxymu - some commentators believe the attack was directed against him. With regard to individuals, I'm sure that governments or intelligence agencies have more direct and efficient methods for silencing somebody, if that was the case. DDoS-ing social networks doesn't make sense, it is like using a tank to kill a mosquito. Also, it's worth noting that Cyxymu only had about 100 followers on Twitter when the attacks started - so I am wondering how big his influence really was to even consider him as the root cause of the DDoS attacks. People will always be in love w ith conspiracy theories. It would be nice after incidents like this if everyone put the energy they have into securing systems, rather than generating more hot air.
| Michael | August 07, 2009 | 11:40 GMT |
comment

|
Can you spot the difference between these two pictures? There's very little - it's a recycled scam. The only difference is a new wave of phishing mails and someone's learned how to spell a little better!
| Stefan | August 06, 2009 | 16:12 GMT |
comments (1)

|
The URL which Koobface was spreading from (see this post for an overview) has now been brought down so attacks are blocked.
| Stefan | August 06, 2009 | 15:17 GMT |
comment

|
As the previous attacks was reaching peak activity, Twitter went offline. The guys at Twitter are yet unsure of the cause of the problem (http://status.twitter.com/post/157160617/site-is-down). Most likely the Koobface attack and Twitter going down at the same time is just a coincidence - but hey, there's a good part about this story too: at least we're not seeing new malicious tweets anymore. UPDATE:Seems Twitter has changed its IP address during the downtime we're currently seeing. The server is responsive to pings, but not HTTP requests. Signs of a DDoS attack? UPDATE 2: Twitter has confirmed it is "fighting against" a denial-of-service attack.
| Stefan | August 06, 2009 | 13:26 GMT |
comment

|
Once again, there's a new wave of Koobface. But this time, the tactics have changed. There's a new twist to the social engineering, with links from infected messages leading to a very well designed Facebook lookalike page (far more convincing than the previous YouTube page) And Koobface is now sending unique tweets. Messages sent in previous attacks were all the same: "My home video :) [URL]" Now there's a random component being added, with strings like "HA-HA-HA!!", "W.O.W.", "WOW", "L.O.L.", "LOL", ";)" or "OMFG!!!" at the end of each tweet, so the malicious tweets look like this: They are also adding a random component to the Koobface landing page so now, the URL gets shortened to a different bit.ly URL each time (see my post about the dangers of short URLs) making it harder for Twitter to filter and delete infected messages. i.e. http://u*******.se/pub1icm0vies/?[RANDOM] -> http://bit.ly/[RANDOM] This week everyone's been talking about how Twitter started to use the Google Safebrowsing API to block tweets containing malicious URLs. It is definitely going to stop some attacks, but as we're seeing with the current attack, it won't eradicate the problem completely. It's clearly a step forward, but a single swallow doesn't make a summer. We detect the malicious binary as Net-Worm.Win32.Koobface.d and the script that is doing the redirect on the landing page as Trojan-Clicker.HTML.IFrame.ob. Currently we’ve identified almost 100 unique IP addresses hosting Koobface. We'll keep you posted! UPDATE: We're working on getting the main Koobface page taken down.
| |