New Attack Sneaks Rootkits Into Linux Kernel

April 15, 2009 – 4:48 AM

Kernel rootkits are tough enough to detect, but now a researcher has demonstrated an even sneakier method of hacking Linux.

The attack attack exploits an oft-forgotten function in Linux versions 2.4 and above in order to quietly insert a rootkit into the operating system kernel as a way to hide malware processes, hijack system calls, and open remote backdoors into the machine, for instance. At Black Hat Europe this week in Amsterdam, Anthony Lineberry, senior software engineer for Flexilis, will demonstrate how to hack the Linux kernel by exploiting the driver interface to physically addressable memory in Linux, called /dev/mem.

“One of bonuses of this [approach] is that most kernel module rootkits make a lot noise when they are inserting [the code]. This one is directly manipulating” the memory, so it’s less noticeable, he says.

The /dev/mem “device” can be opened like a file, and you can read and write to it like a text file, Lineberry says. It’s normally used for debugging the kernel, for instance.

Lineberry has developed a proof-of-concept attack that reads and writes to kernel memory as well as stores code inside the kernel, and he plans to release a framework at Black Hat that lets you use /dev/mem to “implement rootkit-like behaviors,” he says.

The idea of abusing /dev/mem to hack the Linux kernel is not really new, he says. But the rootkit connection is a new spin on it: “People have known what you can do with these /dev/mem devices, but I have never seen any rootkits with dev/mem before.”

Source:
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=216500687&cid=RSSfeed

PIN Crackers Nab Holy Grail of Bank Card Security

April 15, 2009 – 4:41 AM

Hackers have crossed into new frontiers by devising sophisticated ways to steal large amounts of personal identification numbers, or PINs, protecting credit and debit cards, says an investigator. The attacks involve both unencrypted PINs and encrypted PINs that attackers have found a way to crack, according to the investigator behind a new report looking at the data breaches.

The attacks, says Bryan Sartin, director of investigative response for Verizon Business, are behind some of the millions of dollars in fraudulent ATM withdrawals that have occurred around the United States.

“We’re seeing entirely new attacks that a year ago were thought to be only academically possible,” says Sartin. Verizon Business released a report Wednesday that examines trends in security breaches. “What we see now is people going right to the source … and stealing the encrypted PIN blocks and using complex ways to un-encrypt the PIN blocks.”

The revelation is an indictment of one of the backbone security measures of U.S. consumer banking: PIN codes. In years past, attackers were forced to obtain PINs piecemeal through phishing attacks, or the use of skimmers and cameras installed on ATM and gas station card readers. Barring these techniques, it was believed that once a PIN was typed on a keypad and encrypted, it would traverse bank processing networks with complete safety, until it was decrypted and authenticated by a financial institution on the other side.

But the new PIN-hacking techniques belie this theory, and threaten to destabilize the banking-system transaction process.

Source:
http://blog.wired.com/27bstroke6/2009/04/pins.html

Improving Security with URL Rewriting

April 9, 2009 – 3:54 PM

Most web application security experts frown on the practice of passing session or authentication tokens in a URL through the use of URL rewriting. Usually these tokens are passed between the server and the browser through HTTP cookies, but in cases where users configure their browsers to not accept cookies, this is impossible. Some web application frameworks – including ASP.NET – will detect this condition and revert to the cookieless URL rewriting method for passing session tokens. For example, a user who requests the page http://www.contoso.com/welcome.aspx would be redirected to http://www.contoso.com/{SID}/welcome.aspx, where {SID} is that user’s unique session identifier.

Again, most web application security people will tell you that this technique is fraught with peril. It can lead to session hijacking vulnerabilities (a man-in-the-middle sniffs the session identifier out of the URL) as well as session fixation vulnerabilities (an attacker creates his own session and tricks a victim into using it). I once identified enabling cookieless sessions as one of the top ten configuration mistakes made by ASP.NET developers. However, if we make one small change in the way we perform the URL rewriting, it becomes a powerful technique for improving security rather than weakening it.

Instead of rewriting the session id into the URL, we keep the session id in a cookie as usual, but add a second unique token (a “canary” token) into the URL. At the same time, we associate this new canary value with the session id and store it in server session state. Whenever the user makes a request back to the server, the request must include the matching canary or the server will consider the request a forgery. Some diagrams might help explain this a little better.

Source:
http://blogs.msdn.com/sdl/archive/2009/04/09/improving-security-with-url-rewriting.aspx

Windows Kernel Again Found Vulnerable

April 9, 2009 – 3:34 PM

Recently, our APAC threat intelligence team discovered a couple of Windows kernel zero-day vulnerabilities in the field, which could be potentially used for malicious purposes. These were discovered in some discussion forums in China.

One of these issues exists in Windows NT/2000/XP according to the description provided. The issue arises due to insecure win32 syscalls, the buffer being supplied from usermode. This can lead to a Blue Screen Of Death (BSOD) if the kernel address is overwritten, leading to a Denial of Service (DoS) condition. However, this issue requires admin privileges and hence cannot lead to a privilege escalation. But a deeper look suggests that this could be used to subvert or install kernel mode hooks, which can be used for malicious purposes.

Besides this issue, another kernel bug with similar behavior was found recently in the field. In this case it involved atapi.sys.

The cause of this bug is also the same: It doesn’t verify the data passed from user mode and results in a buffer overflow. In most cases it will also cause a BSOD.

From the point of view of software design, data passed from user mode should never be trusted and must be always validated. Many of the known Windows local vulnerabilities exist because of this reason. Microsoft noticed this problem and fixed many potential defects in the kernel’s main module. However, many defects still exist in the win32k kernel part because it’s extremely complex. Most kernel vulnerability diggers are now targeting this module and have discovered many vulnerabilities in the past two years. With Windows 7 we will hope that kernel security will grow stronger.

We’ve notified Microsoft of both of these issues before posting this blog and technical details have been omitted here as the vulnerabilities are unpatched. We’ll do a follow up post after the issues are resolved.

Source:
http://www.avertlabs.com/research/blog/index.php/2009/04/09/windows-kernel-again-found-vulnerable/

Conficker wakes up, updates via P2P, drops payload

April 8, 2009 – 5:41 PM

The Conficker worm is finally doing something–updating via peer-to-peer between infected computers and dropping a mystery payload on infected computers, Trend Micro said on Wednesday.

Researchers were analyzing the code of the software that is being dropped onto infected computers but suspect that it is a keystroke logger or some other program designed to steal sensitive data off the machine, said David Perry, global director of security education at Trend Micro.

The worm also tries to connect to MySpace.com, MSN.com, eBay.com, CNN.com and AOL.com as a way to test that the computer has Internet connectivity, deletes all traces of itself in the host machine, and is set to shut down on May 3, according to the TrendLabs Malware Blog.

Because infected computers are receiving the new component in a staggered manner rather than all at once there should be no disruption to the Web sites the computers visit, said Paul Ferguson, advanced threats researcher for Trend Micro.

“After May 3, it shuts down and won’t do any replication,” Perry said. However, infected computers could still be remotely controlled to do something else, he added.

Source:
http://news.cnet.com/8301-1009_3-10215678-83.html?part=rss&subj=news&tag=2547-1009_3-0-20