Data Cube Systems

Google’s Engineering Director has promised that its forthcoming Chrome OS will see ‘the end of malware’.

Google is promising what the latest issue of New Scientist magazine refers to as “a carefree antivirus nirvana” with its forthcoming Google Chrome OS.

Linus Upson, Google’s Engineering Director, has promised the company is: “Completely redesigning the underlying security architecture of the OS so users don’t have to deal with viruses, malware and security updates. It should just work.”

Chrome browser patched

Ironically, Google is also in the news this week due to security flaws in its Chrome browser.

Two of the most recent Google Chrome web browser security flaws (one relating to malicious code exploitation in the Chrome tab sandbox and one relating to memory corruption in the browser tab processes) have now been fixed.

You can see the full run-down of all the latest changes over on Google’s Chrome site.

So is the cloud computing future really going to be more secure than our current system of downloading regular security patches to constantly fix the software that’s sitting on our hard drive?

“Downloading updates is always going to be a step or two behind the cloud approach because it takes a while to get a fix out to a PC to install it,” argues Paul Jackson of Forrester Research.

And while Jackson agrees that “the cloud approach allows patches to be applied much faster” he notes that any web-based OS is still going to be at risk from malware targeting the browser or Linux.

Robert Caunt, an analyst from CCS Insight in London, notes that Google has a good record on security to date: “Its Gmail spam filter and search engine’s phishing-detection is good. They know what needs doing.”

Major computing brands such as Nvidia, Dell, Asus, Acer and others have already confirmed that they will be fully supporting Google’s Chrome OS. Stay tuned for further Chrome OS news updates as and when we get them.

On the surface, April 1 came and went without a peep from the dreaded Conficker megaworm. But security experts see a frightening reality, one where Conficker is now more powerful and more dangerous than ever.

In the first minute of April 1, Conficker did exactly what everyone knew it was going to do: It successfully phoned home for an update. And while it was fun to imagine what nasty payload that update may have included (it was fun, wasn’t it?), the result was not outwardly catastrophic; rather than a blueprint for world domination, the update contained instructions on how to dig in even deeper.

“The worm did exactly what everyone thought it was going to do, which is update itself,” security expert Dan Kaminsky, who helped develop a widely-used Conficker scanner in the days leading up to April 1, told us. “The world wants there to be fireworks, or some Ebola-class, computers-exploding-all-over-the-world event or God knows what, but the reality is…the Conficker developers have cemented their ability to push updates through any fences the good guys have managed to build in February and March.”

And here’s why that is deeply, deeply scary. As we explained, Conficker has built a zombie botnet infrastructure by registering hundreds of spam DNS names (askcw.com.ru, and the like), which it then links up and uses as nodes for infected machines to contact for instructions. In its earlier forms, Conficker attempted to register 250 such DNS names per day. But with the third version of the software, the Conficker.c variant which has been floating around for the last month or so, the number of spam DNS takeovers was boosted to 50,000 per day—a number security pros can no longer keep up with.

What the April 1 update did was simple: It provided instructions for linking up with the thousands, perhaps tens of thousands of new nodes registered by Conficker.c over the last few weeks, effectively growing the size of the p2p botnet to a point where it can not be stopped.

“It’s not about ownage, it’s about continued ownage,” says Kaminsky, citing a favorite quotation of one of his hacker buddies. “It’s not about how you get into the network, it’s about, ‘How do you be [there] a year from now?’” And the answer is: “You do a lot of the things the Conficker developers are doing.”

“This is not something where the guys wrote it, it’s out, then they’re going to go out and play Nintendo. They’re frankly trying to build something that is a sustainable network for months or years to come,” Kaminsky says.

Kevin Haley, director of Symantec Security Response, raises another good point: “The first [of April] would have been a pretty bad day to choose [to do something with Conficker], because everyone was watching to see what was going to happen. Whoever’s behind this is as lot more patient than we are.”

As far as what comes next? More waiting. Good methods now exist for detecting and cleansing Conficker from infected machines on a network (and, let’s not forget, a months-old security patch from Microsoft is all you need to protect yourself), but by now the size of Conficker’s infected army of nodes spread around the world is big enough to function with devastating consequences even if most PCs are secure.

So we’ll just have to keep waiting to see what this thing does.

Summarizing the lifecycle of a trojan horse as “configuration, infection, action, deletion” would be too brief and you would miss a lot of important and valuable information that makes you understand how they are constructed, how the internal structure looks like and how to breathe life into them. I want to give you the whole, big picture of the trojan horse lifecycle, beginning from the stage of configuration over to its deletion and all the steps in between.

Configure and bind

What a trojan horse needs first are its configuration settings. The information it knows what to do once it is executed on the target system. At this point we have to know the trojan horse is divided into two different parts: the client and the server. The server is the part that is installed on the victims systems, the client is the controlling component on at the attackers side.

The names server and client in this context are a little confusing because normally a client is the one that connects to a server and sends commands to it. This is the way the setup was in use some years ago. The attackers on the client machines connected to the servers on the infected victim machines. But nowadays it works exactly the opposite. The infected victim systems establish a reverse connection to the controlling master system. The reason why it works today like this lies in the history; since the Internet access providers and the hardware vendors began selling only NAT routers with integrated firewall functionality and the computers were equipped with desktop firewalls. From then on it was impossible to an attacker to connect to their servers on the victim systems. A new technique was needed and so the malware developers decided to let the infected systems establish a reverse connection to their controlling system. But instead of changing the notation of client and server that way it makes sense again (in networking terminology a client normally connects to the server) they kept it as it was and changed the notation how the connection is established, namely in reverse, a reverse connection.

1. Normally, integrated into the client, you find a tool with which an attacker builds and configures a new trojan packet. Settings like the clients hostname to which the server has to connect back, the servers ID to recognize it after it was installed on the system, whether to install it on the target system at all or execute it only and let it disappear after the reboot, how to start it automatically after a reboot (via registry, as a service etc.) amongst other things. So first the configuration GUI on the client takes a raw, unconfigured damage routine and customizes it according the attackers settings.

2. The second component that is configured by the configuration GUI is the dropper. The dropper is the part in a trojanized packet that installs the damage routine on the target system. It saves it in a safe place on the targets file system, it ignites it and also makes sure it gets started automatically after a system reboot.

3. The last step the configuration GUI performs is to join/bind the previously configured damage routine, the dropper and the last piece I didn’t mention so far: the entertainer file which the victim is expecting to see when double clicking the trojanized file.

Propagate and drop the malware

Once the trojan horse is configured and all the components are merged and glued together to one package the next step is to propagate it. It depends on the creativity of an attacker how to release the package into the wild and how to convince the big mass of victim(s) to execute it. Some common ways are …

• Sending it via email and pretending to be a familiar person
• Sending a victim an email with a link to a homepage containing malicious content that installs the trojan automatically
• Spread it in file sharing networks to install it on random victims computer

This are only some few examples to show which ways exist at all but I will go into the details later in an other article/chapter dedicated especially to this subject.

Executing the dropper

1. After the package reaches the victims machine and was executed the dropper component becomes active first. The dropper extracts the damage routine and the entertainer to the victims harddrive.

2. After extracting them it has to decide what happens with the damage routine, i.e. where to put it exactly. Has it to be copied to a specific directory and do we have to execute it? For example, we don’t have to execute a simple hosts file (with our new bogus host name entries) that contains only text data. A password recovery routine instead we have to execute.

3. The dropper has to decide whether it is necessary to start the damage routine automatically after a reboot. If the dropper was configured to do so there are several ways to do it as for example using the Windows ini files, the system registry etc. I don’t go deeper into this subject here because it would be to much information and has to be covered in a separate chapter/article.

4. If everything is installed and configured according the attackers wishes the last thing the dropper has to do before deleting itself is to start the entertainer file. This is necessary so everything behaves as expected and the victim doesn’t become suspicious.

Executing the damage routine

After the dropper has finished the installation it is up to the damage routine to do its job. Silently, in the background, without attracting the victims attention, collecting sensitive information as account information, documents, emails, the browser history file, modifying system settings, etc. But also here I don’t go into the details what the damage routine does exactly and how it does it. I will cover this subject later in an other chapter/article.

Removing the malware

At the end of any lifecycle there is normally the death of the object. There are two ways the life of a trojan horse will finish :

1. The trojan horse has finished its work and removes all the files it generated over time it was running on a target system, cleans the system log file entries and just making sure no traces are left after removal. At the very end it deletes itself from the system. The trojan horse commits suicide.

2. The trojan horse was not able to avoid detection on a target system and a copy of the damage routine was sent to a AV (Anti Virus) company to analyze its behaviour and subsequently create a fingerprint. The fingerprint pattern is sent to the AV company customers and the trojan horse will finally be detected, stopped and removed from the system. The trojan horse gets murdered.

Beset by malicious worms after failing to convince enough server administrators to take its out-of-band Security Bulletin, MS08-067, seriously, Microsoft (NSDQ: MSFT) is taking computer security to the streets: It has formed a cybersecurity posse to dismantle the Conficker/Downadup worm’s infrastructure and has offered a $250,000 reward for information leading to the arrest and conviction of those responsible for the outbreak.

Microsoft warned last October that a vulnerability in its Server service could be exploited by a worm. Cybercriminals heard that warning and made the threat real, infecting as many as 9 million computers by mid-January. At that time, Qualys CTO Wolfgang Kandek estimated that between 25% and 30% of vulnerable systems remained unpatched.

And the problem continues more or less unabated today. Symantec said in the past five days it has seen an average of almost 500,000 infections per day with W32.Downadup.A and more than 1.7 million infections per day with W32.Downadup.B.

Jose Nazario, manager of security research for Arbor Networks, in a blog post on Thursday, called Conficker/Downadup a “savage Windows worm.”

The total number of machines infected at any given time varies as a consequence of disinfection efforts. But rest assured that the number represents a very large botnet.

So it is that on Thursday, Microsoft announced a partnership with technology companies, academic organizations, and Internet infrastructure companies to fight the worm in the wild. Its partners in this worm hunt include ICANN, Neustar, VeriSign, CNNIC, Afilias, Public Internet Registry, Global Domains International, M1D Global, AOL, Symantec, F-Secure, ISC, researchers from Georgia Tech, Shadowserver Foundation, Arbor Networks, and Support Intelligence.

Together, the coalition is working to seize Internet domains associated with the worm.

“The best way to defeat potential botnets like Conficker/Downadup is by the security and domain name system communities working together,” said Greg Rattray, ICANN’s chief Internet security adviser, in a statement. “ICANN represents a community that’s all about coordinating those kinds of efforts to keep the Internet globally secure and stable.”

In a phone interview, Kevin Haley, director of security response at Symantec (NSDQ: SYMC), said that there had been a lot of independent efforts to deal with the worm. The time was right, he said, to tackle it as a community.

According to Symantec, researchers have reverse-engineered the algorithm used to generate a daily list of 250 domains that the worm depends on to download updates. Armed with that knowledge, the coalition is taking control of the domains registered through coalition partners and using them to log and track infected systems. The group also is investigating domains overseen by registrars that aren’t part of the coalition, though it’s not clear how much leverage can be applied in such cases.

The worm won’t be entirely stopped by such tactics; it also includes a peer-to-peer update mechanism. But it’s a start.

Perhaps in recognition of the difficulty of getting help from registrars outside the coalition, particularly in countries with a tradition of tolerance for cybercrime, Microsoft said that residents of any country are eligible for its $250,000 reward. In many parts of the world, that kind of money will buy just about anything.

The last time the security community acted in unison like this was during the spring and summer of 2008, when several dozen companies and organizations came together to deal with the DNS vulnerability identified by security researcher Dan Kaminsky. But that was a bug fix rather than a worm-hunting posse.

Haley doesn’t expect this sort of community policing of the Internet to happen more frequently, nor would he rule out further actions of this sort. “The groups that stepped in filled a void,” he said. “As long as this is effective, we’ll continue to look for opportunities.”

The popular virus scanner AVG released an update yesterday that caused their software to mark user32.dll as a virus. Since this is a rather critical file, AVG’s suggestion to remove it caused problems for users around the world who are now advised to restore the file through the Windows Recovery Console. AVG just posted an update about this (FAQ item 1574) in the support section of their site. Their forums are full of complaints.