Slashdot Mirror
Walmart Photo Keychain Comes Preloaded With Malware
Blowit writes "With the Christmas holidays just past and opening up your electronic presents may get you all excited, but not for a selected lot of people who got the Mercury 1.5" Digital Photo Frame from Walmart (or other stores). My father-in-law attached the device to his computer and his Trend Micro Anti-virus screamed that a virus is on the device. I scanned the one I have and AVAST did not find any virus ... So I went to Virscan.org to see which vendors found what, and the results are here and here." Update: 12/29 05:44 GMT by T : The joy is even more widespread; MojoKid points out that some larger digital photo frames have been delivered similarly infected this year, specifically Samsung's SPF-85H 8-inch digital photo frame, sold through Amazon among other vendors, which arrived with "W32.Sality.AE worm on the installation disc for
Samsung Frame Manager XP Version 1.08, which is needed for using the SPF-85H as a USB monitor." Though Amazon was honest enough to issue an alert, that alert offers no reason to think that only Amazon's stock was affected.
No one has disassembled the binary yet to see what it does? Does it call SetWindowsHookEx or something?
This is old news. It has happened before. Case and Point.
If our elected representatives no longer represent us, do we still live in a Democracy?
Write them a letter telling them what you found. Try this link http://walmartstores.com/contactus/feedback.aspx to get to their headquarters, where something might get done about it. Include enough technical detail for them to replicate the problem, especially the model number or any other identifying information from the package.
If you want someone to care enough to write back, try to not sound accusatory or threaten to sue them. I'm sure they get enough of that on a daily basis.
John
Looks to me like they used some kind of packer to make the exe's small to not take up a lot of space on the device (understandably). A lot of scanners will automatically detect packing as malware and, due to the nature of how a packer works, trojan is the logical choice. I have a similar problem with anything I compile with delphi since a lot of malware is developed in delphi.
My 2 cents worth...
this time it seems like it was the vendor's screwup, which is very rare, but it's very easy for someone to have a clean USB stick, then plug it into an infected PC and unknowingly get a trojan written to the USB stick.
i recently had close call myself when i took my PSP to work and plugged it into a workstation (i had some utilities and e-books saved on the memory stick). when i got home and plugged the PSP into my desktop, i noticed the PSP memory stick was displayed with an odd icon in My Computer. so i looked at the root directory and found a suspicious .exe file that i hadn't placed there, which was also referenced by a new autorun.inf file.
with thumbdrives, external hard drives, portable media players, and other flash memory devices becoming increasingly common, i expect more and more malware writers will exploit them as an infection vector, especially as autoplay is usually enabled by default on Windows systems. the only reason i had autoplay disabled was because i found it annoying, and that's the only reason i lucked out.
Keep in mind that it might be a false positive. Those happen, and sometimes you find the same false positive in more than one AV product when they simply copy from each other instead of creating their own definitions from the real thing.
An example is the game The Witcher, which triggered a false AV protection in ESET Nod32 antivirus. Then, suddenly, a couple of months later, a couple of other products also started seeing a virus here. There was none -- the packer that had been used by the game had also been used for a virus, and the signature was copied from NOD32 to some less successful AV programs without further ado.
So, don't just take it on face value that there is a virus -- especially not when none of the really big players with low false positive rates can detect it. It may be one, but don't blindly assume so.
It's not a virus, it's just a exe packer they used.
Virus scanners have been labeling PE Packers as viruses for ages now, simply because a virus could be packed with them, and it's easier to pick out a packer header than a virus contained in it.
A lot of false positives are caused by this, and this looks like one of those cases based on what you linked. "Generic" "NSPack" "PossibleThreat" in the VirSCAN links give that away.
EXE/PE Packers simply compress a binary and decompress it on the fly, simply to save space or "load faster". Likely Walmart's programmers used one to keep the app's size small on a small device like that.
I've dealt with this situation in size-coding competitions before, and it's not fun. A lot of false positives are caused simply because a packer was used.
Fortunately, some of the better virus scaners actually unpack the software before checking it, or look for valid virus signatures instead of a simple Packer.
This basically is just a case of virus scan companies being lazy.
You think they buy virus scanner software in a Chinese factory? No, these guys cut every corner they can to meet those razor thin profit margins.
“Common sense is not so common.” — Voltaire
Care to explain how a rootkit could be considered anything but malware?
If they do nothing else, they compromise the security of a system.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
For Windows XP, SP2 ... Tweak UI allows disabling of AutoPlay either by device type (eg CD) or drive letter, and the setting is stored in the user registery under [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer], but Tweak UI only shows the settings if the user is an Administrator.
However according to Microsoft's TechNet web-site, the NoDriveTypeAutoRun setting in HKCU is ignored if there is a corresponding entry in HKLM, so to disable AutoPlay on all drive types for all users:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer]
"NoDriveTypeAutoRun"=dword:000000ff
If AutoPlay is enabled, actions per content type can be set per user by right-clicking the drive in Explorer, then selecting the AutoPlay tab. The options are stored in [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\UserChosenExecuteHandlers]. The default (which is to prompt the user) can be restored by deleting the entries.
Note that there doesn't appear to be an option for "data only". So far as I know, if AutoPlay is enabled (which it is by default), you can't disable AutoRun.inf. However, if the user is not an administrator, Explorer will prompt for an Administrator logon before doing anything.
Technically, kernel level debuggers can be classified as rootkits, as they use rootkit techniques to gain the level of access they need to be able to work.