Posts by The Reg-ular 12 publicly visible posts • joined 1 Jan 2008
The article has a link to the story about the metadata in the image, but neither you vultures nor that other rag posted the original picture. Of course, the picture has been removed from its original location on TwitPic, and the uncensored image on El Reg has been processed with Photoshop according to the metadata in that image. In the interest of journalistic integrity, please post the original image that is the subject of this article so that others can independently verify claims about the metadata.
It's the antithesis of "streamlined". The 4.x paradigm has all the object management confusion of the OS/2 Workplace Shell (remember "Create Shadow"?) and all the usefulness of Active Desktop(tm).
Some folks can't have too many RSS notifiers, clocks, calendars, sticky notes, stock tickers, weather bugs, and media players jumbled together on their desktop, or too many overlapping ways to arrange commonly -- and even uncommonly -- used items.
People that prefer KDE 4 over 3.5 seem to be the type that would put xeyes in their .xinitrc because they had some screen real estate left over that didn't beep, blink, fade, scroll, or flash (on virtual desktop #14). KDE 4.x enables them, as they are less obsessive than Blackbox themers and generally afraid of vi. Hence I think the market for write 'em yourself python powered screen bling is overestimated.
PS -- Tard.
Good eye! The entire trojan does not fit in the MBR, What the old school VXers call the dropper -- the .EXE (or more likely then, .COM file; remeber those?) that placed the data on the disk -- placed a small snippet of code in the MBR to load the rootkit/bootkit code stored on sectors at the END of the disk. The r/bootkit code can also hide OS-hosted components that can still update and reinstall the code in the MBR and unallocated sectors, so no, FDISK /MBR may not disable the Trojan completely, but it makes it more likely that detection might work on subsequent reboots, at least until the pre-OS code is reinstalled.
"Only rarely do we come across crimeware that has been continually stealing and collecting personal information and payment card data, and compromising bank accounts as far back as 2006."
Actually, the first Torpig attacks were launched in late 2005. That was before the MBR infection functionality was added (the versions known as Mebroot) at the turn of 2008, based on the BootRoot research project at eEye way back in 2005.
Given what's been learned from other long-lived crimeware operations, like Coreflood, and about the capabilities of the Torpig attackers, I would be surprised that only half a million accounts have been compromised thus far.
The encoded format of the stolen data sent to the attacker's (yes, mostly Russian) web sites remains essentially unchanged. This tool will decode logs of Torpig/Anserin/Sinowal/Mebroot network activity, so incident responders can tell what exactly the bad guys were able to get a hold of (assuming the activity is logged and retained):
http://www.secureworks.com/research/tools/untorpig/
Quoting Elia Florio at Symantec:
"The main problem is that some versions of Microsoft Windows allow programs to overwrite disk sectors directly (including the MBR) from user mode, without restrictions. As such, writing a new MBR into Sector 0 as a standard user is a relatively easy task. This issue has been known for quite some time, and still affects the 2K/XP families, while Vista was partially secured in 2006 (after Release Candidate 2) after a successful attack demonstration made by Joanna Rutkowska. The attack is called the 'Pagefile Attack'."
... so Evil Bill it is.
The two arrested were not Pinch authors, just a couple of resellers who ran some dropzone servers. What happened to these guys anyway? The typical catch-and-release to make a point? See it's still being echoed as an example as Russian law enforcement success in this very article. Some success.
That model in the driver seat is must be a member of Little People of America (I'm all for modeling industry's promotion of non-conformist body types). Either that, or s/he's too young to drive.
For large sedans and SUVs, 20 inches is the bare minimum wheel diameter for da-shizzleness in America. According to advanced mathematical models using geometric transformations and taking into account typical human physiology, that person is approximately three and a half feet (1.07m) tall.
This is a typical marketing tactic. If this person modeled jewelry, a half-carat promise ring would look like the Hope Diamond.
Like all green cars, they are not made for tall and/or fat folks (i.e., most Americans). I suspect they are made like this on purpose. Subjecting oneself to the cramped ride at least twice daily is a modern form of self-flagellation engineered to appeal to those suffering from Liberal Guilt.
Of course it has not a plug; you might as well put a "clean coal addict" bumper sticker on it.
It should sell well on both American coasts but nowhere else. Unfortunately, it will never have the range to get from one to the other.
Russian citizens are sensitive to this. Maintaining access to live radiation level readings is Russian law. That law was made to help prevent another Soviet-style cover-up like that of the the 1975 leak. Any lack of data can be seen as a cover-up and possible violation of this law and its mandate.
It seems that instead of covering up a real leak, they are covering up the fact that there was simple failure of the systems for which they're responsible. The officials still maintain that it was a coordinated hacker attack.
Paris, because the Handicam Niteshot mode makes her glow like spent fuel rods.
This is because CA has decided to block the use of the Dean Edwards JavaScript "packer" code. JavaScript that uses the wrapper code:
eval(function(p,a,c,k,e,r...
... is being blocked and reported as JS/Snz.A. A lot of site have packed versions of JavaScript libraries such as MooTools, JSQuery, and so on. Many sites use Dean Edwards' on "IE7 pactch" JavaScript which is, of course, packed using his tool.
Following its use in a successful XSS worm that infected 600,000 users of a social networking site, many other hacker groups have begun using it, too. They are taking advantage of the fact that it has been whitelisted as a "legitimate" (non-underground) tool and, until now, not blocked.
There is simply no good way to tell if the packed code is benign or malicious. Given recent events, there is a much larger chance today than in the past of it being malicious. There, more anti-virus, web filtering, IDS/IPS, and firewall vendors will begin blocking it.
Have the bad guys won, then? No!
Research has shown that these packers are not effective in doing what they are designed to do, which is to reduce page load times. For most JavaScript "in the wild" (as some like to say), their space-saving advantages are offset by the addition of the unpacker stub code. Readability and auditability (Firefox says that's not a word) are sacrificed, too -- is that packed file name mootools.js really MooTools, or is it a downloader for the latest Storm Worm EXE? It's not easy to tell. Besides, the load time is usually only impacted once in a long while, when it's first loaded into the browser's cache.
The biggest drawback is execution time. By a wide margin, whatever gains are made in load time are lost in execution time. Some benchmarks I ran show these packers adding significant overhead to the code -- enough to impact the user experience negatively. On my test systems, four different publicly available packers added an average of 600 ms to execution time for each script. IE7 is by far the worst. The String maniplulation done by the unpacking code, fo some reason, executes very slowly in IE7, adding between 3 and 12 seconds!
This happens every time, because the packed version is what's stored in the cache.
While use of these packers is usually well-intentioned, it doesn't generally have the desired benefits for end users.
With no real-world advantages today, these scripts are primarily used to prevent casual ripping of copyrighted script, offers a layer of security through obscurity, and provide camouflage for hackers' exploits and malware.
I think we should urge developers way from the use of packers. I think more security companies should proactively protect their clients from packed scripts instead of waiting to write a signature based on every attack already underway.
Bravo, CA, for taking the initiative. Clients of companies that are too conservative in blocking packed scripts, just because some people use them with good intentions, are sitting ducks for the next XSS worm or 0-day exploit and whatever payload it delivers.
Oh, happy new year!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
