Malware is widely bypassing AV and other controls, getting backed up like any legitimate data, and re-infecting enterprise systems during restore.
Anonymous: 10 Facts About The Hacktivist Group
(click image for larger view and for slideshow)
When malware slips past antivirus, it can get swept up in an enterprise's system backup and ultimately reinfect systems when the company restores applications from its contaminated backup.
Oliver Friedrichs, head of Sourcefire's cloud technology group, says this cycle occurs more often than you'd think. Friedrichs recently analyzed data collected from more than 2 million Sourcefire users during a one-month period and found that backup and file restoration applications often inadvertently restore malware.
His findings: During a one-month period, DropBox, a cloud-based file-sharing and backup service, restored 17,705 threats; Maxtor Backup and Restore's MaxSynch, 5,076 threats; 2BrightSparks SynchBack backup software, 165 threats; and FreeFileSync, 104 threats. These were users that had been running traditional AV products.
"We've historically talked about backing up malware as a hypothetical ... we assume it's been happening, but there hasn't been a clear way to see how frequently it's been taking place," Friedrichs says. "This [analysis] is a confirmation and affirmation that it is happening. We should be concerned about it and aware of backing up malware and then restoring malware."
Friedrichs says this demonstrates how malware is widely bypassing AV and other controls and then getting backed up like any legitimate data or files. Once the backup is "polluted," he says, if it is used to restore a system, [the malware] would also be restored onto the system once again.
Is this an AV or a backup problem? Gleb Budman, co-founder and CEO of cloud-based backup service provider Backblaze, says his firm had explored whether it should provide malware scanning as part of its online backup service. But it just didn't make sense, for two reasons: "We encrypt all of the files [backed up] so they can't be scanned in our data center," Budman says. "We could scan on your client AV in our backup agent on your system--we thought about that--but if a user is already running AV, they would run it, then we would run it, and we'd be using up system resources twice. That seems kind of silly."
Most external hacks of databases occur because of flaws in Web applications that link to those databases. In this report, Protecting Databases From Web Applications, we'll discuss how security teams, database administrators, and application developers can work together to improve the defenses of both front-end Web applications and back-end databases to prevent these attacks from succeeding. (Free registration required.)
Dark Reading Must Reads - September 25, 2014Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Published: 2014-09-30 ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.
Published: 2014-09-30 The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.
Published: 2014-09-30 The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.