Yesterday, on March 02, 2010, when I started Seagate Backup Manager from my desktop I had no freakin idea that my AV alerts n HIPS logs are going to scream their lungs out.
I've a 320 gb portable, a 500 gb external n another 500 gb external backup drives. I had the 320 gb plugged in. Upon starting the backup manager, the system came to a disturbingly slow run. A 100% CPU hog started. Ofcourse, at that time, I thought it appeared to be due to the 2 VMs running on my box. Since that hadn't occurred even when I work on my VM lab - around 6 workstation VMs n 2 server VMs - something didn't look right. So I checked & found there is this known bug / behavior with Seagate Backup Manager. Ok, so rebooted the box and started up again with what I had been doing earlier.
And then the AV alert pop ups suddenly seem to go berserk. McAfee AV started detecting n deleting / cleaning up exploits, trojans n the alerts stood there on the screen.
Here's a portion of alerts screens I captured:
So I decided to check HIPS logs as well. I found there were several continuous attempts to access outlook files and address books, primarily. All were denied, of course.
Here's some of the screens from my box's HIPS logs:
As you can see above, the exploits do not seem specific to windows. There are generic trojans, backdoors, and linux exploits as well. The hips logs also suggest a behavior of a typical trojan / virus attempting to access email program files n address book.
I checked for any outbound connections when I started this app again later . There were no suspicious destinations at all. It appears to me this is kind of a scheduled activity build inside the application. I recall using this app post lunch hours and nothing had came up then.
In my opinion, this is what might have happened when I started the Seagate backup manager:
1. Application gets started, calls 'home'
2. Receives exploits / trojans / virus / backdoor etc.
3. Executes them
After recent Energizer backdoor disclosure, it had been speculated that backdoor was actually being an administrative function for developers. Now looking at yesterday's incident, with another widely used brand, I find the these behaviors could very well be more than just speculations or errors from developers.
It may not be incorrect to consider these incidents as calculated and planned attack vectors. Today when even big corporations are consistently receiving security advisories, then it is impractical to believe the HDD vendors are secure. Compromise of their server(s), responsible for pushing product updates on to the end-clients, can cover a broad target surface for an attacker(s) over a short period of time.
As long as vendors are not held accountable, I believe we cannot expect them to respond proactively. And till then, it remains the responsibility of the Information Security pupils to find the holes n get them fixed, as has been since long.
Please feel free to share your experience and thoughts over this finding / incident.