The IP address block from ex-hosting company ConnectCom (AS34596), 193.238.36.0/22, has been transferred to Ukrainian operator ImperialNet on 29th June. The IP address block 195.149.108.0/24 was previously attributed to this operator.

ConnectCom is an entity which until recently was well-known for its proximity with the infamous Russian Business Network. From 2005 to late 2007, this bulletproof hosting provider used to host activities such as child porn, phishing scams, malware propagation websites, etc. In a two years’ lifespan, no single legitimate website could ever be spotted on RBN’s IP ranges, which is quite remarkable. Following its disappearance from the Internet, some of its IP ranges had been transferred to the US hosting company ThePlanet.

So, all's well that ends well! Unfortunately, there’s a bit more to this story: the recycling of freed IP space is a good principle; however, it may pose a threat to the new owners of these IP blocks. We security professionals have for years recommended network administrators to blacklist and null-route IP blocks belonging to RBN to prevent its malicious activity from spreading. As a consequence, these blocks still have today a “bad reputation”, and are associated to hundreds of fraud reports in search engines (link). Worse yet, these netblocks may still be listed by IP blacklists (link), URL-filtering products, or even intrusion detection system rules such as the “Emerging Threats” Snort ruleset (link).

As a result, the new legitimate owners of these netblocks may experience network communication failures, because their outgoing e-mails could be filtered out by their recipients’ networks, and their websites may not be accessed due to HTTP firewalls blocking outgoing traffic to bad IP blocks. This is not a pure theoretical case: in February, a /24 block of RBN's former IP ranges was assigned to a small French hosting company that was therefore immediately blacklisted by most of the networks that still relied on old IDS rules.

This story will repeat itself as soon as McColo and Intercage / Atrivo’s IP ranges are reassigned to other customers. IP blacklisting mechanisms now seem up to date and reactive enough, so network administrators do not hesitate anymore to block entire IP ranges; but the problem remains with the de-listing process. Moreover, the reassignment of an IP range formerly belonging to a bankrupt company, or following a network-wide migration, may lead to a data breach. The new owner of the netblock might indeed receive sensitive network traffic (such as e-mails) originally sent to the block’s previous owner.

Many thanks to “Bad Rabbit” for bringing the ConnectCom’s netblock migration to our attention.

Denial of service encouragement messages have been published on various websites since roughly a week. These messages target Iranian governmental websites; see, for instance, this blog post that was published on June 21st on Twitter.

This call to action was relayed through hundreds of Twitter user accounts (link, link, link). The choice of this specific social networking platform was indeed good, as hundreds of Twitter users read and copied the message on their own feeds; moreover, the call to action was incidentally published on dozens of news websites covering the events in Iran, as these websites automatically syndicate "twits" using search keywords related to Iran. The message could therefore be read directly next to press articles, giving the call to action a comfortable visibility in a short timeframe [link].

The tool enabling this attack was named "Page Reboot". It consists of a PHP script that opens on a single page dozens of redirect frames pointing at Iranian websites, being refreshed at a chosen rate. At the beginning of their attack, the hacktivists were using the PageReboot.com web service ; then they wrote their own script for an easier deployment on several web servers of their choice (such as WhereIsMyVote.info which is now offline). This way, the attackers could migrate the script whenever they want, so as to keep the attack up and running. An example of this is the website http://91.199.0.11/ that was hosted in France; this website was pre-configured to attack the following targets:

• http://www.Presstv.ir
• http://www.Leader.ir
• http://www.Kayhannews.ir
• http://www.farsnews.com
• http://www.farsnews.ir
• http://www.Irib.ir
• http://www.Irna.ir
• http://www.mfa.gov.ir/cms/cms/Tehran/fa/index.html
• http://www.Moi.ir
• http://www.Police.ir
• http://www.Justice.ir
• http://www.live.irib.ir
• http://www.iribnews.ir

This tool was set up by an individual identified under the nickname "Zampf". He also published on his Twitter feed technical details about the IT technologies deployed on the targeted Iranian governmental websites.

Dancho Danchev's weblog [link] also presents other rudimentary DoS tools that could be downloaded by cyber-activists. These tools are executable files, which target similar websites. What seems different about this attack from previous "nationwide" DDoS attacks (in Estonia and Georgia for example) is the lower level of technical skills of the attackers: until now, no botnets seems to have been involved in this attack. As a result, the efficiency of the attack is unclear, as some targets appear undisturbed, others being slightly slowed down, and a few of them being taken completely offline.

Interestingly enough, this campaign seems to have started on IRC channels, such as #iran, #iranelection, #hackers, #iran09, #mousavi, #basij, #GR88, #neda (named after the woman who was shot to death, and whose agony was filmed on a cellphone and quickly spread all over the world). Far from being perfectly coordinated, this movement also has its detractors, which can also be read on Twitter: some people are calling to stop the DDoS attack, for various reasons -- one of them being that it would be more efficient to surgical-hack those government websites [link].

Anyway, these attacks clearly illustrate political activist campaigns on the Internet, and the ease even for unstructured activist groups to quickly develop technical tools in order to get itself heard.

This is the terrible conclusion after this three-day symposium: unfortunately, it's over ... This year, we're not going to make a report summarizing the various conferences, many blogs already do it, sometimes even in live.

It was an opportunity to reconnect with old colleagues and friends, meet new people, and assist once more to really exciting conferences. The subjects were very varied, ranging from abuse of BIOS features to implement a backdoor, to a talk on the real value of ISO 27001, through the now traditional legal intervention of Marie Barel, the failure of security in companies by Nicolas Ruff, or a reflection on the human being as a strong piece in the security. Although some subjects did not seem very exciting, the authors have often succeeded in generating interest for their work.

This year, our colleague Florent Marceau presented his work on automated malware analysis:

His approach implements a modified QEmu virtual machine to follow malicious code and the data it manipulates (Data tainting), in order to recover in clear-text ciphered bankers configuration files. Technical details of the implementation are available in the related paper.

The conference also provided an opportunity for Raphaël Rigo and Simon Marechal to present the resolution of the reverse-engineering challenge organized by Stéphane Duverger. The prizes were distributed to the winners, Florent won an iPod Touch, and I enjoyed a wonderful toothbrush that belonged to the creator of the challenge:

Rump sessions were more numerous than ever this year, with 23 interventions of 4 minutes each. As usual, the subjects covered were varied. I enjoyed the rump of Jean-Baptiste Bédrune who has discovered a weakness in the algorithm to generate WPA/WPA2 keys used in two french ISP "boxes". Special mention for the EthyloSSTIC rump, with a USB breathalyzer and its application which controls alcohol level prior to login on a system

Last but not least, the Social Event, which is the opportunity to meet and interact with participants and speakers, has been a real success. Organized this year in Coq Gadby, it brings together all participants in a large and pleasant place.

I now have to thank the whole Organizing Committee for the 7th edition of SSTIC, waiting impatiently for the 2010 opus.

Among viruses that have made the headlines since the beginning of the year, we can find a new variant of Virut/Virux/Scribble. This is a polymorphic PE file (.exe and .scr) infector, connecting to an IRC server waiting for commands. This latest version also infects HTML, PHP and ASP files on the system with an iframe pointing to a malicious page trying to exploit known vulnerabilities in Internet Explorer and Adobe Reader/Acrobat. Since analysis of the old and new versions have already been done, let's concentrate on the efficiency of some removal tools against this threat.

Such tools are quite useful during incident response missions. They make it available to scan a system without installing software on the system, and in some cases may detect viruses that were not spotted by the corporate antivirus.

In this post, we are going to work on a particular sample of Virut, which is currently detected by almost every AV vendor:

However, the few removal tools we tested were disappointing. Some of them didn't detect anything, some detected the virus in memory but not the infected files, and some detected the infected files but were not able to disinfect them. One of the tools requires that the system be rebooted in Safe Mode, which may not be feasible, especially if servers are infected. One of the tools even have a default mode which deletes infected files instead of disinfecting them, which is quite a funny behaviour when dealing with a PE infector...

These results are a bit surprising considering that, as shown above, antivirus products from the same vendors detected the sample correctly.

Dr.Web's CureIt! is the tool that worked best on our sample. It didn't detect the virus in memory, but detected the infected file and disinfected it:

The file was given back its original size of 70 656 bytes. Now, let's check that the file has correctly been disinfected. Here are the main modifications induced by the infection:

• a marker was added in the Reserved field of the MZ header, to prevent reinfection

• in the PE header, SizeOfImage was increased and Checksum zeroed

• the .rsrc section was enlarged and its characteristics were modified to allow writing and execution, needed for in place depacking

• the payload was added at the end of the file in the .rsrc section, from offset 0x11400 to 0x15dff (virtual addresses 0x1014000 to 0x10189ff)

Only 4 bytes of code were modified at offset 0x68e5 (virtual address 0x10074e5):

They correspond to the overwrite of a call to GetStartupInfoA by a jump to 0x1014369:

This virtual address corresponds to the offset 0x11769 in the file and points in the middle of the payload.

Now, let's have a look at how Dr.Web disinfected our file. It deleted the payload from offset 0x11400 and patches 5 bytes:

• 1 byte to decrease the size of the .rsrc section from 0xda00 to 0x9000 (RawSize field)
• 4 bytes from offset 0x68e5 to replace the jump to the payload by the original call to GetStartupInfoA

We can therefore conclude that our sample has successfully been disinfected (beware that this is only a specific case, several infection methods can be used by the virus). However, the tool was not able to detect the malicious iframe in HTML, PHP and ASP pages, which may be a real problem if a web server has been infected.

Several editors have chosen Tuesday may 12th to release their patches:

• Microsoft with the traditional « Patch Tuesday »
• Apple with the 10.5.7 version of Mac OS X
• Adobe with new Acrobat Reader versions for 7.x, 8.x and 9.x branches

The first patch, MS09-017 (Ref Lexsi 11515), fixes no less than 14 CVE concerning different Microsoft Powerpoint versions (2000, XP, 2003 and 2007). The fix is rated « critical » for Office 2000 and « important » for other versions. Amongst the fixed vulnerabilities, we recognize CVE-2009-0556, which is exploited in the wild since the beginning of April.

The particularity of this bulletin is that some of these vulnerabilities affect Powerpoint versions that have no fix at this time. Indeed, Office 2004 for Mac is affected by the famous CVE-2009-0556 but is not concerned by the MS09-017 patch. Same case for CVE-2009-0224 (undisclosed vulnerability until now) which affects not only Windows versions but also Office 2004 and 2008 for Mac, as well as Works 8.5 and 9.0. This is not common for the Redmond editor who usually waits for a patch to be applicable to all vulnerable versions before releasing it.

Microsoft explanation is that unlike Mac versions, fixes for Windows versions of Powerpoint were ready and tested before the monthly cycle release. Furthermore, only CVE-2009-0556 is actively exploited on internet, and Microsoft doesn't know of exploitation code for any but Windows versions of Powerpoint. Finally, the two other vulnerabilities (CVE-2009-0224 and CVE-2009-1130) which concerns among others Office 2004 for Mac have been responsibly reported to Microsoft (which means they have not been disclosed before the Microsoft patch release).

Some people already feel outraged by this behavior, described as inconsistent regarding the editor demands when a vulnerability is submitted to him : no timeline for patch release and no possibility of disclosure unless you want to be called « irresponsible ».

Both points of view have their arguments. When you think that with methods such as differential binary analysis, exploitation codes disclosure after a patch release is a matter of days (or even hours), it is likely that Mac users will find that time passes slowly during the coming month. Did that justify for the rest to wait one more month, whereas vulnerability exploitations are confirmed ?

Talking about confirmed vulnerabilities exploitation, Adobe has released 7.1.2, 8.1.5 and 9.1.1 versions of Acrobat Reader (Ref Lexsi 11625) fixing CVE-2009-1492 and CVE-2009-1493 flaws. The 7.1.2 for Mac is expected before end june.

Mac users could feel harmed. That is not taking into account the MacOS X 10.5.7 version release, which will eventually be the last Leopard update. This version fixes no less than 68 vulnerabilities, of which 21 are new (Ref Lexsi 11700), where you can note a kernel vulnerability (CVE-2008-1517) allowing a local privilege escalation and 3 vulnerabilities (CVE-2008-3529, CVE-2009-0162 and CVE-2009-0945) fixed by the new 3.2.3 Safari version.

Bad luck comes in threes, Mac users of the Sophos antivirus who wish to fix the 68 vulnerabilities will have to be patient: the editor indicates that they shouldn't upgrade to the new Leopard version if they want to continue receiving infection alerts by mail ...

We have modified some behavior on our blog: our posts will systematically be written in french and translated into english (and vice versa), and therefore new feeds are available in french (RSS or Atom) and in english (RSS or Atom). As some team members didn't resist to the call of Twitter, you can now follow our adventures on our dedicated page !

No less than 21 vulnerabilities have been published during the April Microsoft Patch Day, spread among eight bulletins. Five of them are rated critical because a remote attacker can exploit them to execute arbitrary code:

MS09-009: two vulnerabilities in Excel (Ref Lexsi 11548 and 11344), including the 0-day vulnerability dating back to February.

MS09-010: four vulnerabilities in WordPad and Office text converters (Ref Lexsi 11549, 11034 and 10724), including the already known vulnerability used in targeted attacks. In the FAQ, the following text: "Exploit code is publicly available of a variant of this issue that may cause a Denial of Service condition in WordPad" seems to refer to an exploitation code published on Milw0rm in September 2008.

MS09-011: a vulnerability in the DirectShow component of DirectX (Ref Lexsi 11550).

MS09-013: three vulnerabilities in Windows HTTP Services (Ref Lexsi 11552), an API used by, for example, UPnP.

MS09-014: six vulnerabilities in Internet Explorer (Ref Lexsi 11553).

Two bulletins are rated important:

MS09-012: four vulnerabilities in Windows (Ref Lexsi 10015 and 11551). This privilege escalation had been presented by Cesar Cerrudo in his Token Kidnapping conference during HITB 2008.

MS09-016: two vulnerabilities in Microsoft ISA server and Forefront Threat Management Gateway (successor of ISA) (Ref Lexsi 11555), one of them allowing an attacker to cause a denial of service.

Finally, one bulletin is rated moderate:

MS09-015: one vulnerability in the SearchPath component of Windows (Ref Lexsi 8970), fixing a known vulnerability allowing an attacker to execute arbitrary code with Internet Explorer if he is able to drop a malicious file with the same name as a system library on the victim's desktop. By default, Apple Safari before 3.1.2 downloaded every file on the desktop, thus allowing this vulnerability to be easily exploited.

It is worth noticing that the 0-day in PowerPoint that became public at the beginning of the month has not been fixed.

NB: two CVE belong to two different bulletins, explaining why there are only 21 vulnerabilities and not 23

The MSRT has also been updated to delete the Waledac malware family, whose main goal is to search the infected system for email addresses to send spam to, as well as retrieve sensitive information such as passwords.

It must be remembered that a part of the Conficker.C payload that was spread by P2P tried to connect to a Waledac domain. Moreover, Waledac authors have just launched a new campaign, promoting a piece of software allowing you to retrieve SMS messages from your neighbour's phone...

Oracle has also released its April 2009 Critical Patch (Ref Lexsi 11556), fixing 43 vulnerabilities in different products (Database, Application Server, WebLogic, etc).

As we already mentioned, variant C of Conficker incorporates a sophisticated peer-to-peer mechanism, allowing for payload transfer between infected hosts without any attempt to connect to the famous domain names. This mechanism has been active for several weeks. However, during the last few days, a payload has begun to be distributed through it.

Analysis of this payload is in progress. Below is the first available information regarding the Conficker update itself (which seems to be only a part of the payload):

• this update is spreading via the MS08-067 vulnerability, like variants A and B (remember that this spreading vector was not present in the original C variant) and opens a listening port. It seems that no other means of propagation have been added.
• it will stop operating on 05/03/2009
• it uses the SSDP protocol

Some AV vendors already detect this new variant, such as Trend Micro or ESET.

It seems that the payload is able to download a binary from goodnewsdigital[dot]com, a domain name already known to be adversely used by the Waledac family of viruses.

Faced with this still unclear situation, the best thing to do is to look for machines infected by Conficker.C and disinfect them. This can be done in several ways:

• Nmap scan
• scan through the open P2P ports
• Snort module

Stay tuned!

In previous posts, methodologies and tools related to the detection and eradication of Conficker were discussed:

• generic VBS script to remove Conficker A/B/C
• using mutexes to build a digital vaccine against Conficker C
• TCP and UDP ports generation used by Conficker C's P2P mechanism

The proof of concepts that were developed are now available for download (password: lexsi). Be careful, technical users only

Updated, 04/03/2009: The P2P ports generation tool has been updated to fix a bug causing a one day lag in the generation (one day per week, the generated ports are those of the day before), because of an incorrect structure initialization before using it in mktime.

As everybody has said and repeated, on April, 1st 2009, the latest variant of the Conficker worm will begin to generate domain names to try to connect to and retrieve a potentially malicious payload.

We saw that the new update mechanism is now based on the generation of 50000 domain names per day, among which 500 will be contacted to try to download an update. Statistically, this corresponds to updating 1% of the infected machines by registering a unique domain name. Would the authors be willing to reduce their botnet to 1% of its size?

Not at all! The obfuscated functions in the worm are used by an impressive Peer-to-peer communication mechanism, allowing Conficker to communicate with its peers to propagate an update. The small percentage of machines that have downloaded an update through the domain names could communicate it to all other machines in (relative) discretion.

This mechanism, previously studied by the SRI, is based on several threads managing communications with other peers, including two threads dealing with UDP communications and two threads for TCP communications. Observation of UDP packets sent through the Internet gives the impression of a pair of randomly generated IP and port, and it would be interesting to find a link between the address and the port, in order to have an effective detection of the P2P traffic of the worm.

Once we have traced the different threads, we always encounter the same function to generate the different ports, based on the IP address of the infected machine and a parameter that we will determine later.

This large cryptographic-looking block is present twice in the function. The first block only takes into account the host's IP address (in the eax register on the previous screenshot), and generate a first pair of TCP / UDP ports in esi and esi+4. They only depends on the IP address. Before entering the second block, we note that the register eax is xored by the first argument of our generation function.

The second block is nearly identical to the first, and results in the generation of a new pair of TCP / UDP ports in esi+8 and esi+C.

The argument passed to our function is the result of the function called just before. Studying it shows that its result is in edx in the following screenshot:

eax contains the timestamp of the current date. We note that the value 0x54600 is subtracted from our timestamp, which is the number of seconds in 4 days. The timestamp is then multiplied by 0x6EF5DE4D then edx is shifted by 12 bits to the right. These two operations are in fact a compiler optimisation to perform a division by the value 604800, which corresponds to the number of seconds in a week. Our parameter is identified, it is the number of weeks since the 1st January 1970!

Now that this information is available, it is possible to create a tool taking an IP address and a date as parameters to determine pairs of TCP and UDP ports used by the peer-to-peer mechanism at that date and for this address.

lexsi:~/conficker$ ./conficker_ports 192.168.111.2 05 02 2009
Used UDP ports : 45804 / 35543
Used TCP ports : 17116 / 62114

lexsi:~/conficker$ nmap 192.168.111.2 -P0 -p 1-65535
Interesting ports on 192.168.111.2:
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
17116/tcp open  unknown
62114/tcp open  unknown

This enables us to determine if unidentified traffic is due to Conficker or not, ensuring that the IP address and port are in accordance with the algorithm. Better yet, it is possible to scan the network, looking for TCP ports opened by the worm, which be very wise one day before the beginning of Conficker's update!

Note that publishers of rogue security software begin to use the buzz around conficker to distribute false removal products.