Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Tuesday November 14 2017, @03:12AM   Printer-friendly
from the still-better-with-than-without dept.

Submitted via IRC for SoyCow1984

Antivirus programs, in many cases, make us safer on the Internet. Other times, they open us to attacks that otherwise wouldn't be possible. On Friday, a researcher documented an example of the latter—a vulnerability he found in about a dozen name-brand AV programs that allows attackers who already have a toehold on a targeted computer to gain complete system control.

AVGater, as the researcher is calling the vulnerability, works by relocating malware already put into an AV quarantine folder to a location of the attacker's choosing. Attackers can exploit it by first getting a vulnerable AV program to quarantine a piece of malicious code and then moving it into a sensitive directory such as C:\Windows or C:\Program Files, which normally would be off-limits to the attacker. Six of the affected AV programs have patched the vulnerability after it was privately reported. The remaining brands have yet to fix it, said Florian Bogner, a Vienna, Austria-based security researcher who gets paid to hack businesses so he can help them identify weaknesses in their networks.

Bogner said he developed a series of AVGater exploits during several assignments that called for him to penetrate deep inside customer networks. Using malicious phishing e-mails, he was able to infect employee PCs, but he still faced a significant challenge. Because company administrators set up the PCs to run with limited system privileges, Bogner's malware was unable to access the password database—known as the Security Account Manager—that stored credentials he needed to pivot onto the corporate network.

"With the help of AVGater, I gained local admin privileges," Bogner wrote in an e-mail. With full control over the employee computer his exploit provided, he had no trouble accessing the credential store, which is commonly known as a SAM database. "So AVGater was VERY useful during several of our pentests and red-teaming assignments."

Source: https://arstechnica.com/information-technology/2017/11/how-av-can-open-you-to-attacks-that-otherwise-wouldnt-be-possible/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by TheRaven on Tuesday November 14 2017, @11:21AM (1 child)

    by TheRaven (270) on Tuesday November 14 2017, @11:21AM (#596749) Journal
    Over a decade ago, one of my colleagues published a paper showing that frameworks that do system call interposition are vulnerable to time of check to time of use attacks. A decade later, most AV vendors are still using this technique. The Symantec vulnerability in that list is my favourite, because it highlights the fact that AV vendors have absolutely no idea how to write secure code. Can you imagine the train of thought that would lead someone to decide that the best place to run some code that deals with malicious data in complex file formats is in the kernel? Any sane implementation would run the scanner in an unprivileged process with no access to anything in the system. At worst, if it's compromised then it would report false negatives, whereas in the Symantec version a compromise in the image decoder let the attacker run arbitrary code in the kernel.
    --
    sudo mod me up
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2, Informative) by Anonymous Coward on Tuesday November 14 2017, @05:39PM

    by Anonymous Coward on Tuesday November 14 2017, @05:39PM (#596876)

    FWIW, you can run ClamAV in just that manner, you startup clamd and have it drop privileges. You then use the clamdscan (note the "D" in the command name), which is privileged. All that program does is determine whether a file is one you wanted scanned or not and if it is, then the read-only file descriptor (or, if that is unavailable, a raw copy of the file) is sent via a UDS to the daemon. Much more secure because if there is a bug in the scanner itself, then you are only as vulnerable as the sandbox you put it in.