Easter Egg locations remain safe, says Bunny spokesperson

Polish pisanki photo courtesy of Jarosław Pocztarski's Flickr photostreamReports surfaced late today that the Easter Bunny had a minor incident while hiding the last of his eggs during his traditional Easter mission.

Every year the Easter Bunny travels the world hiding brightly colored eggs and baskets with goodies for children to discover on Easter morning.

“It would be a tragedy if the locations of all the eggs and baskets were disclosed,” said an anonymous parent representing a children’s rights group.

Unfortunately it appears that the Easter Bunny had stored all of his data and maps of where his eggs were placed in one basket.

Easter Bunny and eggsFortunately Naked Security was able to reach a spokesperson for the Easter Bunny, who assured us that the locations of the treats were fully encrypted on Mr. Bunny’s netbook.

“The Easter Bunny takes the joy of children seriously, and despite the loss of his maps, Easter will proceed normally,” said the spokesperson.

Creative Commons image of Polish pisanki (eggs) courtesy of Jarosław Pocztarski’s Flickr photostream.

SSCC 57 – Infosec Europe 2011, Facebook privacy

Sophos Security Chet Chat logoPaul Ducklin from Sophos Australia joined me at Info Security Europe 2011 this week to help explain our open letter to Facebook.

Paul and I discussed the three points we outlined in our letter and other associated issues we have seen recently concerning safety and privacy on Facebook.

We also spoke about some of the booths and presentations at the show and shared our thoughts on what vendors should be sharing with the public at these shows.

If you prefer a news summary for the week in text format, visit the Sophos Security Hub for the latest selected hot topics or subscribe to our weekly newsletter, Sophos enews.

(21 April 2011, duration 11:44 minutes, size 7.5MBytes)

You can also download this podcast directly in MP3 format: Sophos Security Chet Chat 57.

Memory Forging Attempt by a Rootkit

Some time ago a new rootkit appeared that at first glance seemed more similar to initial variants of TDL3 than to the updated TDL4 variants we have seen this year. Like TDL3, it also parasitically infected a driver by inserting code in the resource directory of the PE file. In this case the name of the file it infected was hard-coded to volsnap.sys. Also similar to the early variants of TDL3, this rootkit also hooked some pointers in the dispatch table (IRP hook) of the driver below disk on the device stack of the hard disk.

But it was very interesting to see some of the anti-rootkit tools not showing the dispatch table hooks that are usually pretty straightforward to identify. Also this malware would not allow an external debugger (WinDbg) to break, which was annoying.

The reason for hooks not being reported was that the memory being read by the tools was not the actual memory! The dispatch table as “seen” by the tools appeared not to be hooked–whereas in reality it was hooked. The part that made it interesting was that the memory was being read at the correct address with a mov instruction and not using some system API that could be hooked. We know of some proof-of-concept ways to achieve this, but I had not seen this behavior before from a threat in the wild.

Obviously the motivation for malware authors to use such techniques is to prevent tools from showing their hooks so that administrators are not alarmed of suspicious activity.

So how does it fake memory on read access? This rootkit is using hardware breakpoints (DRX register setting) to monitor access to memory areas of the kernel that it patches. In addition to modifying the DR0 register, it hooks the KiDebugRoutine pointer so that it gets notification when the hardware breakpoint is encountered due to memory access. This rootkit installs IRP hooks and sets the DR0 register to the memory address where the IRP hook is installed. So when the memory of the dispatch table is read, a “fake” image with no hook in it is presented by the malware’s KiDebugRoutine hook. Here is a brief overview of the KiDebugRoutine hook code.

This is the beginning of the malware’s KiDebugRoutine handler code. If it encounters a breakpoint, then the malware simply increments the instruction pointer for the thread where the exception occurred and returns it as handled. Otherwise we take the jump.

Image here

KiDebugRoutine Handler: Snippet 1

Next comes the target from the above jump (loc_403BCC). If the exception occurred at a kernel mode address, then we jump to loc_404026.

image here

KiDebugRoutine Handler: Snippet 2

At the target of the above jump, first the exception is processed normally by checking access flags, clearing the DR6 register, etc. Then the following code is used to identify if this is a read access to the protected memory and if the malware wants to block this particular access. If both of these conditions are true, then the read location is altered to point to a memory area with contents the malware wants to forge. Thus anyone who the malware does not like ends up reading the wrong memory. The comments in the code below explain the details. The assumption about ESI in the code below is interesting.

image here

KiDebugRoutine Handler: Snippet 3

This technique has been discussed before, and this example shows again just how modern rootkits are adopting techniques and evolving rapidly. In fact, after this malware we have seen yet another update in the master boot record infecting the TDL4 strain that is still using DKOM to put a  fake device object on the device stack of the hard disk. At McAfee Labs we will continue to investigate and provide protection against such threats.

Anger after scam-exposing community shut down by Facebook

The Bulldog EstateIn a bizarre and hard-to-understand move, a Facebook page which claims it helped countless Facebook members stay safe online on the social network has been shut down… by Facebook.

The Bulldog Estate is one of a number of different resources on the internet dealing with the subject of Facebook scams, rogue applications, and the like. Other examples include Scam Sniper, FaceCrooks and Sophos’s own Facebook community.

On Monday 18th April, the Facebook page belonging to Scam Sniper was shut down by Facebook authorities:


Scam Sniper

Notice: The Sniper Has Been Shot. Facebook Disables The Admins Of The Facebook Fan Page Scam Sniper. http://goo.gl/RdlVF

Later that day, the same fate befell The Bulldog Estate’s Facebook presence, leading the scam-exposing site to say that Facebook had made a bad PR move:


The BULLDOG Estate

The BULLDOG Estate Facebook Page Has been Closed by Facebook, They Dont Like bad press, Watch… http://goo.gl/fb/K3ODY

The Scam Sniper Facebook page was eventually restored, but Tony Mazan, the owner of The Bulldog Estate, hasn’t had the same luck.

Mazan has been contacting Facebook since Monday attempting to understand why The Bulldog Estate’s Facebook page was closed, and how it might be recovered.

Today Mazan received a standard response from Facebook, which still wasn’t specific about the reasons that The Bulldog Estate’s Facebook presence had been killed off:

"Hi Tony

You created a Page that has violated our Statement of Rights and Responsibilities, and this Page has been removed. Facebook Pages may only be set up for the purpose of promoting a business or other commercial, political, or charitable organization or endeavor (including non-profit organizations, political campaigns, bands and celebrities), and only by an authorized representative of the entity or individual that is the subject of the Facebook Page. By creating a Facebook Page, you represent and warrant that you are authorized to do so by the person or entity that is the subject of the Facebook Page. Among other violations, Pages that are hateful, threatening, or obscene are not allowed. We also take down Pages that attack an individual or group or that promote or glorify violence, intolerance, racism or discrimination. Continued misuse of Facebook's features could result in your account being disabled."

This “explanation” clearly hasn’t satisfied the many fans of The Bulldog Estate, who have created pages urging Facebook to reinstate The Bulldog Estate, and left messages on Facebook’s official safety pages.

Tony Mazan“We helped countless members on Facebook and supported Facebook in trying to help Facebook users stay safe online, We do not advertise or make money from our help, our blog writers are volunteers, and our admins are volunteers,” Tony Mazan of The Bulldog Estate told Naked Security. “What we can not understand is why Facebook removed a real help group and yet there are thousands of rogue applications, thousands of hate filled pages, thousand of fake profiles. We are as real as it gets and get shut down.”

“Is it because Facebook security never gets comments like ‘We Love you’ or ‘thanks for always alerting us on time with user-friendly information’,” continued Mazan. “As one of our supporters said – you may shut the dog outside, but you will never silence the bark.”

Although the language used on The Bulldog Estate’s website doesn’t beat around the bush, it seems clear to me that the content they produce is beneficial and helps Facebook users avoid scams and other attacks.

Maybe Facebook needs to be a little less robotic in its shutdown of this scam-exposing community, and could work a little more closely with Tony Mazan and his colleagues to bring what is a helpful resource for its users?

Update: The Bulldog Estate reports that its Facebook page has now been restored, and that Facebook has apologised for its mistake.