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.)
Published: 2014-08-19 The SNMP module in Cisco NX-OS 7.0(3)N1(1) and earlier on Nexus 5000 and 6000 devices provides different error messages for invalid requests depending on whether the VLAN ID exists, which allows remote attackers to enumerate VLANs via a series of requests, aka Bug ID CSCup85616.
Published: 2014-08-19 The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) 6.2.0 and 6.3.0, does not properly enforce the method level restrictions for outbound messages, which allows remote authenticated users to access otherwise restricted JAX-WS handlers ...
Published: 2014-08-19 The isCallerInRole function in SimpleSecurityManager in JBoss Application Server (AS) 7, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 6.3.0, does not properly check caller roles, which allows remote authenticated users to bypass access restrictions via unspecified vectors.
Published: 2014-08-19 RESTEasy 2.3.1 before 2.3.8.SP2 and 3.x before 3.0.9, as used in Red Hat JBoss Enterprise Application Platform (EAP) 6.3.0, does not disable external entities when the resteasy.document.expand.entity.references parameter is set to false, which allows remote attackers to read arbitrary files and have...
Published: 2014-08-19 The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers...