Equifax Website Taken Down After Distributing Adware
U.S. credit monitoring bureau Equifax has taken down one of its websites following reports that it was redirecting users to adware served in the form of a fake Flash Player update.
The first report came from an independent security analyst named Randy Abrams, who was served the unwanted application when he tried to get a free or discounted credit report from Equifax using an option on the company’s website.
“TrustedID [an Equifax service] gave me the heads up that Experian had falsified personal information in my file,” Abrams said in a blog post. “After verifying that Experian did, in fact, falsify the data (it was due to incompetence and apathy) I decided to see if the misinformation had propagated to Equifax. As I tried to find my credit report on the Equifax website I clicked on an Equifax link and was redirected to a malicious URL. The URL brought up one of the ubiquitous fake Flash Player Update screens.”
Abrams managed to replicate the attack and recorded a video as his browser was redirected to the scam page. The program served as the Flash Player update was Mediadownloader.exe, a known adware program.
In a discussion on Hacker News, some users tracked the apparent compromise to a web analytics script loaded by the website and which apparently attempted to load further resources from a third-party domain name that might have been hijacked.
Equifax has been under the spotlight recently for a massive data breach that resulted from a failure to patch a known Apache Struts flaw on one of its websites in a timely manner. This latest compromise, however, does not appear to be the result of a vulnerability and is something that could happen to many websites due to the complex ecosystem of third-party scripts they load, from advertisements and traffic analytics tools to various JavaScript frameworks.
Some of these attacks—but not all—could be prevented by using Content Security Policy (CSP), a security mechanism that allows websites to tell browsers what are the external origins that scripts are allowed to be loaded from. Unfortunately, CSP has very low adoption—recent scans show only 2 percent of websites from the Alexa Top 1 Million use this security mechanism.
Obviously, if attackers manage to compromise an origin that’s whitelisted by a site’s CSP policy they would still be able to load malicious content into it, but at least the mechanism would close other attack avenues and would make the job more difficult for hackers.
Outlook Exposed Encrypted Emails for At Least 6 Months
If you use Microsoft Outlook and used it to send email messages encrypted with S/MIME in the past six months, they might have been compromised. Researchers from security firm SEC Consult found that the program sent unencrypted copies of messages along with their S/MIME encrypted versions for emails that had been formatted as plain text.
“In the context of encryption this can be considered a worst-case bug,” the researchers said in a blog post.
S/MIME (Secure/Multipurpose Internet Mail Extension) is an IETF standard that allows users to encrypt or digitally sign emails by using digital certificates. It’s supposed to protect email messages from being intercepted and read en route to their recipients even if the email traffic between servers is not protected by TLS and even if the email servers are compromised. In other words, S/MIME provides end-to-end encryption where only the intended recipient has the private key to decrypt the message.
The vulnerability found by SEC Consult is tracked as CVE-2017-11776 and was patched by Microsoft Oct. 10. However, some researchers don’t agree with the way the company described the flaw.
“An attacker who exploited the vulnerability could use it to obtain the email content of a user,” Microsoft said in its advisory. The company rated the flaw as important but said that exploitation is unlikely.
“Outlook S/MIME bug is absolutely reproducible, I just did it,” security researcher Kevin Beaumont said on Twitter. “Does not need an attacker. Microsoft have classified it wrong.”
The SEC Consult researchers agreed, saying in their blog post that “to trigger the vulnerability, no active involvement by an attacker is required” and that “an attacker might remain completely passive.”
However, there is a requirement for the attacker to be in a position to intercept the traffic (if not encrypted by TLS) or to be in control of an email server along the email’s path.
There is one other limiting factor for this vulnerability: It only happens for S/MIME encrypted emails that are formatted as “plain text” and not “HTML.” The default formatting for new emails in Outlook is HTML unless the message is a reply to an email that was already formatted as plain text.
