As has become almost a weekly tradition, another major security hole was reported last week (June 8). This report, from Talos, is about a hole that allows malicious files to be launched when anyone clicks on a PDF from within the Google Chrome browser.
The attack leverages "an exploitable heap buffer overflow vulnerability in the Pdfium PDF reader. By simply viewing a PDF document that includes an embedded jpeg2000 image, the attacker can achieve arbitrary code execution on the victim’s system. The most effective attack vector is for the threat actor to place a malicious PDF file on a website and and then redirect victims to the website using either phishing emails or even malvertising," said the Talos alert. "A heap buffer overflow vulnerability is present in the jpeg2000 image parser library as used by the Chrome's PDF renderer, PDFium. The vulnerability is located in the underlying jpeg2000 parsing library, OpenJPEG, but is made exploitable in case of Chrome due to special build process."
It's a slight—but important—variation on the click-on-an-email-attachment method of infecting a machine and potentially taking it over. What many people outside the security profession don't quite grasp is that clicking on a link on a Web site absolutely is downloading a file. How do they think those images and words appear?
It's an interesting twist because consumers have been taught to avoid opening unknown attachments—and to not visit unknown sites (which, admittedly, is a more challenging demand)—but opening a PDF that appears to be inside a trusted site doesn't seem to violate the rules. And yet it does.
This all comes down to a simple rule that security folk have been preaching for 20 years: Only click/open something that you anticipate, that you expected to come.
This gets us into the latest cyberthief trickery, which is to impersonate someone the targeted victim knows. That might be via stealing the contacts list and then sending messages, seemingly from the first victim, to hundreds of other victims found on the first victim's contacts list. The messages would seem to be coming from a friend. But it's still not expected and the phrasing may be off.
The second sneaky method is what I call the LinkedIn Research (LR) attack. The contacts list attack is designed to send out to a huge number of potential victims, hoping to entrap however many people fall for it. The LinkedIn Research attack is much more time-consuming—and therefore expensive, for the cyberthief—but it's quite effective.
The LR attack targets a high-value potential victim, such as a key bank employee who handles money-transfers. Then they fake a message from a company executive who orders a wire transfer and says that it must happen right away. I ran into one bank that was almost victimized by the fraud, until someone noticed that the message was phrased far more politely than this executive ever speaks in e-mails. The "please" gave it away. See? Sometimes being rude does pay dividends.
What impressed the bank is that the executive being faked was a temp and that his name appeared nowhere on the site. But the temp happened to have just added this gig to his LinkedIn account. The fact that few outsiders would have known of this person's existence is what gave the attack initial credibility.
It's not just clicking on attachments that is an age-old problem that isn't going away. Why are SQL injection and cross-site scripting attacks still so common?
Here's the problem. IT has historically attacked such security diseases with training—which employees attend in body but rarely pay attention—and guidelines, which are also ignored because there is rarely any visible enforced consequences to ignoring them. It may be time to take a hit on functionality/productivity and program rules that block such actions. I'd really rather not need a supervisor's signoff to click on an attachment, but if employees endanger network security because they won't learn, what is the viable alternative?