DEV Community: Ax Sharma

Where did these mysterious PrismJS npm versions come from?

Ax Sharma — Fri, 16 Apr 2021 06:49:02 +0000

In 2015, strange 9000.0.x versions of PrismJS appeared on npm downloads, and nobody had a clue where they came from, or what purpose they served.

Roughly four years later, PrismJS 9000.0.1 and 9000.0.2 were removed from npm for the reasons described below.

But to date, no one seems to know anything more about this incident.

PrismJS is a lightweight, robust, and elegant syntax highlighting library that is based on Dabblet.

Its sheer popularity among developers is demonstrated by the 4.5 million weekly downloads PrismJS receives on the npm registry.

Prism is also the choice of the library for websites of famous tech brands like Stripe, Drupal, MySQL, React, etc.

Image source: prismjs.com

So, who published Prism 9000.0.x?

In November 2015, Rob Loach, a developer raised concerns about strange versions 9000.0.1 and 9000.0.2 that had appeared on npm.

Versions 9000.0.x published on 12th May, 2015, stood out as, at the time, the latest version of PrismJS was 1.3.0.

Also, the very first version 0.0.1 had been published on 13th May, 2015, so how come, the timestamp data from npm show 9000.0.x versions having been published a day prior to the initial release?

{ "name": "prismjs",  
"dist-tags": { "latest": "1.3.0" },  
"versions": \[ "0.0.1", "1.1.0", "1.2.0", "1.3.0", "9000.0.1" \],  
"time":  
{  
"9000.0.1": "2015-05-12T23:54:40.643Z",  
"9000.0.2": "2015-05-12T23:56:14.033Z",  
"0.0.1": "2015-05-13T00:37:38.541Z",  
"1.1.0": "2015-10-06T00:03:04.995Z",  
"1.2.0": "2015-10-07T17:35:20.776Z",  
"1.3.0": "2015-10-27T02:35:27.738Z" }  
}

Loach raised a GitHub issue for the maintainers of PrismJS to unpublish these “broken” versions from npm, and this is where it gets interesting.

PrismJS creator and an elected W3C member, Lea Verou asked another web developer at the time, “any ideas where the 9000 came from? Is it safe to remove?”

By July 2016, Golmote, a contributor to the PrismJS project responded with:

“I don’t know where those weird versions come from. They are dated at the time of the creation of the NPM package… so I guess they may have been mistakes, or automatically created maybe?”

Image source: GitHub issue

The chatter continued in the same thread for quite some time as access issues were being sorted—that is, maintainers trying to figure out who had access to PrismJS’ npm account.

Finally, npm was notified and began taking these 9000.0.x versions down sometime in October 2019.

A dependency confusion attack?

A particularly interesting incidence here is the choice of large version numbers itself: 9000.0.1 and 9000.0.2.

These version numbers of PrismJS were causing problems for some developers:

“Removing this would be great as it will help to keep a consistent versioning,” said software developer Harald Nezbeda at the time.

“Currently, this is causing also confusion in services… Updating to the latest version of the dependencies causes it to take 9000.0.1,” Nezbeda continued.

Another open-source CLI tool called updates, which checks for npm dependency updates, had to rewrite its version resolution logic to not pull the 9000.0.x versions.

Earlier this year, I broke news on how a researcher hacked over 35 big tech firms and earned over $130,000 in bug bounties by exploiting a novel kind of open-source supply chain weakness, called dependency confusion.

Incidentally, the said researcher, Alex Birsan, mentions using an example 9000.0.0 version in his proof-of-concept (PoC) dependency confusion demos, in his blog post released this February.

Other bug bounty hunters have used 9000.0.x versions in their copycat PoC demos as well [1, 2].

But the exact mechanics behind how conflicting dependency names and higher-numbered versions in open-source ecosystems that lack proper namespacing can be troublesome have been known to the developer community years before dependency confusion attacks made “news.”

“If I know of a package in use by a company through log analysis, bug report analysis, etc., I could potentially go register the same name in the default repo with a very high [semantic version] and know that it’s very likely that this would be picked up over the intended, internally developed module because there’s no namespace,” Sonatype CTO Brian Fox had said in his 2017 writeup.

In 2015 alone, for example, RubyGems had deleted a 9000.0.0 version of rails-assets-angular.

Why? Because it was malicious. Somebody had used it to pull a successful dependency confusion attack:

“Someone used bundler’s CVE-2013-0334 to perform [an]attack on our service and created rails-assets-angular gem with the same name as on our service.”

“Now every time someone [runs] bundle update, the RubyGems gem is installed instead of ours,” said developer, Adam Stankiewicz, who represents the official rails-assets.org service.

What is inside 9000.0.x versions?

But, what about the PrismJS 9000.0.x versions?

Although these versions have been pulled from npm downloads, and the entirety of the internet for good, I was able to dig into Sonatype’s automated malware detection system archives to retrieve a copy of the 9000.0.1 version:

The now-removed PrismJS version 9000.0.1 (Image source: Security Report)

While analysis is still ongoing, so far, there is no indication of any malicious code or exploit embedded within PrismJS 9000.0.1.

Considering, nobody—including PrismJS developers, knows where these weird 9000.0.1 and 9000.0.2 versions had come from, it is plausible that an attempted supply-chain attack was caught and subverted in time before the author of these 9000.0.x versions had managed to publish an outright malicious PrismJS version.

Still, the 9000.0.x versions did make their way into development builds of at least some open-source projects, inconveniencing their maintainers.

Fast-forward to 2021, dependency confusion attacks are being actively leveraged to target software projects named after renowned brands like Amazon, Slack, Zillow, and Lyft.

Moreover, novel brandjacking and typosquatting supply chain attacks are on the rise, like the newly discovered Linux and macOS malware hidden within a counterfeit component named after “Browserify”.

As these attacks continue to grow, it is worth checking your software development builds for suspicious dependencies, malicious components, and install automation solutions that can proactively detect and block these attacks from compromising your software builds.

Syndicated from securityreport.com

NodeJS malware caught exfiltrating IPs, username, and device information on GitHub

Ax Sharma — Fri, 02 Oct 2020 09:44:26 +0000

Multiple NodeJS packages laden with malicious code have been spotted on npm registry.

These “typosquatting” packages served no purpose other than collecting data from the user’s device and broadcasting it on public GitHub pages.

The findings were spotted by Sonatype’s automated malware detection systems and further investigated by the company’s Security Research team which includes me.

The packages previously present on the open source npm registry included:

electorn (intentional misspelling of a legitimate package “electron”)
loadyaml
loadyml
lodashs (intentional misspelling of a legitimate package "lodash")

All four packages were published by the same user “simplelive12” and have now been removed, with the first two having been taken down by npm as of October 1, 2020. The previous two packages were unpublished by the author themselves.

Once installed, electorn ran a script in the background every hour which collected the logged-in user’s IP, geolocation data, username, path to home directory, and CPU model information.

The malicious code within electorn and 3 other identical packages which exfiltrated user information

This information, part of which constitutes the device “fingerprint” was uploaded and published on GitHub in real-time.

Some of the information being published is base64-encoded but this can be trivially decoded by anyone who has access to it:

Sonatype’s Security Research team has accounted for these malicious packages into their products, and had notified both npm and GitHub teams of the malicious activity stemming from the components. This led to the takedown of these malicious packages.

To this date, all 4 packages have scores a little over 400 total downloads.

It is not exactly clear what was the purpose of collecting this data and why was it being published on the web for the world to see, however, incidents like these highlight the potential of typosquatting attacks on the open-source ecosystem.

We can only imagine what the next possible version of these packages could have been capable of – possibly carrying out even more sinister activities.

By tricking an unsuspecting developer into mistakenly installing a misspelled package, attackers can push their malicious code “downstream” into any other open-source projects that use the misspelled malicious component as a transitive dependency.

Adopting DevSecOps best practices and building security early on into your software development lifecycle can prevent “counterfeit components” such as electorn and loadyaml from entering, and thriving in your software supply chains.

Can a Windows wallpaper really hijack your Microsoft account password?

Ax Sharma — Tue, 22 Sep 2020 16:28:21 +0000

This month security researcher bohops demonstrated a credential harvesting trick that uses Windows theme files. Setting a Windows wallpaper location to a file present at a remote location, for example, a password-protected HTTP(s) page, instead of a locally present image, can be abused for phishing.

This happens because the password-protected website, using the HTTP Basic Access Authentication, would naturally prompt the user for a password to that website, before the wallpaper can be accessed.

Those not familiar with HTTP Basic Authentication can use the W3's Jigsaw link for a demo.

Head straight to https://jigsaw.w3.org/HTTP/Basic/ in your web browser (username and password are both "guest").

Now instead of a webpage, had a wallpaper or Windows theme lived there, and you provided this URL to Windows where a filename was expected, you'd be prompted for a username and password to that website in an identical manner.

Actually, other software programs do the same thing. Try inserting a remote resource (image, for example, from a password-protected URL) in Word, and you'd be presented with a similar dialog box.

Phishing attacks? Maybe...

Yes, in some ways, this "intended feature" can be abused for phishing attacks: if a naïve user on seeing a native system dialog box enters their Windows or Microsoft Account credentials as opposed to the website's.

However, I'd argue in that case the user really doesn't know what they are doing and need additional computer security training.

Moreover, in all cases - whether you were setting a remote wallpaper, or inserting an image into your Word document, the name of the website requesting the password is clearly displayed.

According to bohops, Microsoft stated they'd not be patching this bug as it was a "feature by design," but I'd argue why should they? What is a better way to allow HTTP Basic Authentication?

Maybe disable the option of allowing remote resources from being inserted in some locations (such as wallpapers and themes) altogether?

The only other way I can think that may help is, adding a warning to all such dialog boxes.

For example, whenever a user tries to access an HTTP Basic Auth-protected resource, a system-initiated prompt requesting the password should make it very clear to the user that this is not a solicitation for their Windows credentials.

After all, the chances of the (unknown) remote resource or wallpaper, and the user's Windows account sharing the same set of credentials are infinitesimally small.

NTLM "Pass-the-hash" hack: more serious

Further investigation conducted by Lawrence Abrams of BleepingComputer [full disclosure: I occasionally write for them] though reveals an additional attack vector.

Instead of a URL requiring HTTP Basic Authentication what if the remote wallpaper used a different protocol? For example, what if the remote wallpaper/theme lived at a Samba (smb) share?

When trying to access a remote Samba location (e.g. \\example.com\wallpapers\image.jpg), Windows would automatically try to authenticate to the share by sharing the user's NTLM hashes in the background to the remote server. This is called "passing the hash" authentication.

Now, this is a problem... Simply by adding an attacker-provided wallpaper or a Windows theme file to your system would initiate a connection to the attacker's server and share your NTLM hashes without your knowledge or explicit consent.

Although NTLM hashes are encrypted, it may not take that long for them to be cracked as history tells us.

"In a Pass-the-Hash attack, the sent credentials are harvested by the attackers, who then attempt to dehash the password to access the visitors' login name and password," writes Abrams.

"In a test previously done by BleepingComputer, dehashing an easy password took approximately 4 seconds to crack!" he continues.

Therefore, the short answer to the question, if Windows wallpapers can hijack your Microsoft Account credentials is, "yes, but it depends."

Whereas the HTTP Basic Authentication may be easier to spot for seasoned users, the "pass-the-hash" authentication hack is more subtle and its automatic nature makes it difficult for the end-user to prevent credential harvesting attacks.

A key point to note though, HTTP Basic Authentication transmits your credentials in plaintext over a network (unless the website requesting the password uses HTTPS), whereas NTLM "pass the hash" authentication would not transmit your actual plaintext password, but a hash of it.

Still, the risk remains from "pass the hash," given the attacker would now know your Windows username and potentially be able to guess or deduce your Windows password from the hash (if the password was weak).

Users should therefore refrain from using Windows wallpapers and theme files from untrusted sources.

A malware alert left hundreds of Bank of America customers panicking

Ax Sharma — Fri, 18 Sep 2020 07:58:08 +0000

According to reports, hundreds of Bank of America customers had trouble accessing their bank accounts yesterday due to Avast and AVG antivirus engines flagging the site as “malware.”

Naturally, seeing a virus alert when visiting their banking website would worry any customer.

“I’m using Home Banking site for Bank of America. When I try to log in I get: HTML:PhishingBank-COV [Phish] virus warning… Bank of America says everything is fine on their end and that it is an error with Avast,” stated a Reddit user.

Avast flagging Bank of America website as infected with phishing malware
Source: Astra Security via their customer(s)

A spokesperson at cybersecurity malware and threat monitoring company, Astra Security told SecurityReport.com, “We’ve received hundreds of hits on our system monitoring infections. And we spoke to multiple Bank of America customers about this who were concerned.”

One customer asked Astra, “When I log into my bank I get an anti-virus warning that there is an HTML:phishingBank-COV hack. Is this on my computer or coming from the bank?”

Multiple reports of panicking users surfaced

Other reports about the malware alert surfaced on Reddit, along with panicky Twitter users questioning what’s going on?

Some were concerned if Bank of America’s systems were compromised.

As it turns out, Avast team confirmed yesterday, this was indeed a false positive and removed by Avast from their antivirus engines.

However, surely the panic this alert created left many users startled.

If you see an antivirus alert when accessing websites, it always helps to be cautious, should it turn out that it was your system that had been infected.

The users who posted about the alert on forums, and made phone calls to the bank did the absolute right thing. In this case, however, luckily an automated false positive detection was the reason behind the “noise” and no real phishing infection occurred.

Bank of America customers, therefore, remain safe and should have their Avast antivirus definitions updated automatically by now.

A peek inside the “fallguys” malware that steals your browsing data and gaming IMs

Ax Sharma — Thu, 03 Sep 2020 09:18:13 +0000

This weekend a report emerged of mysterious npm malware stealing sensitive information from Discord apps and web browsers installed on a user’s machine.

The malicious component called “fallguys” lived on npm downloads impersonating an API for the widely popular video game, Fall Guys: Ultimate Knockout. Its actual purpose, however, was rather sinister.

As first reported by ZDNet and analyzed by the npm security team, the component when included in your development builds would run alongside your program, and access the following files:

/AppData/Local/Google/Chrome/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Roaming/Opera\x20Software/Opera\x20Stable/Local\x20Storage/leveldb
/AppData/Local/Yandex/YandexBrowser/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Local/BraveSoftware/Brave-Browser/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Roaming/discord/Local\x20Storage/leveldb

The file list comprises the local storage leveldb files of different web browsers, such as Chrome, Opera, Yandex, and Brave, along with any locally installed Discord apps.

LevelDB is a key-value storage format mainly used by web browsers to store data especially that relates to a user’s web browsing sessions.

The “fallguys” component would pry on these files and upload them to a third-party Discord server, e.g. via webhooks.

A peek inside npm “fallguys”

Npm removed the malicious package, but fortunately we retain a copy of all components in a secure archive, so the Sonatype Security Research team was able to quickly analyze the malware. In fact, we got this into our data well before the news broke so Nexus users are safe!

In this Nexus Intelligence Insights post, we share a first look inside “fallguys”.

Vulnerability identifier: sonatype-2020-0774

Vulnerability type: Embedded Malicious Code

Impacted package: fallguys as formerly present in npm downloads

CVSS 3.1 Severity Metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS3.1 Score: 10 (Critical)

While “fallguys” package was likely created with malicious intent from the beginning, the package exhibits outright suspicious behavior in version 1.0.6.

There are three files found in version 1.0.6. One is a README which touts the malware being a *Fall Guys *game API to gain some trust from the user and the other two files include the application manifest (“package.json”), and the main “index.js”.

The README.MD file present in“fallguys” npm malware (Image source: Sonatype)

The manifest reveals nothing out of the blue, but in “index.js” we see a whole lot going on:

The very first constant “_0x13e5” is a cryptic array containing different strings and locations of multiple “leveldb” files the malware would eventually begin reading. This is all part of the obfuscation process, to jam different strings the application would need into a single array and read from this array.

For example, on line 30, the variable assignment obtains a value from this very “_0x13e5” array at an obfuscated subscript address “_0xe64ed6” (15093462).

There is also mention of strings such as “username”, “email”, “phone”, “Token grabber”, etc. but their purpose doesn’t become immediately obvious to an analyst.

Obfuscated code in index.js file of “fallguys” with Discord webhooks (Spread out by us to make it more legible; Image source: Sonatype)

On line 37, we see the “webhook” variable containing the URL to the attacker’s Discord app which is where data read from the “leveldb” files we list above, would be posted to:

var webhook = 'https://discordapp[.]com/api/webhooks/746189410042904617/RQVJEOhzAblK5FlkQ-WIXkWfKfg5BFCdsjTeVueAIrVLaQMTvHgbuhuqFafPZYHfwnEq'

At the time of writing, our tests confirm the webhook endpoint is no longer responsive and was likely brought down by Discord:

Discord webhook where “fallguys” malware would post sensitive information to

The “send” function also has a nested JSON object which appears to contain the profile metadata with bits such as the author name, avatar thumbnail, username, email, etc.

The “send” function within the malicious “fallguys” component (Image source: Sonatype)

Mostly your browser data, nothing else

In an age where adversaries find innovative ways to pollute the software supply chain via attacks such as Octopus Scanner, or leverage typosquatting techniques to mine Bitcoins, it is certainly odd for malware to exclusively target browser data stores and Discord files without touching more sensitive areas of a system.

“The malicious package appears to have been performing some sort of reconnaissance, gathering data on victims, and trying to assess what sites the infected developers were accessing, before delivering more targeted code via an update to the package later down the road,” states the ZDNet report.

Thankfully, this malware was caught early and has only been downloaded around 300 times. However, we may not always be so lucky.

Our New Normal

According to our 2020 State of the Software Supply Chain report, next-generation software supply chain “attacks” are far more sinister because bad actors are no longer waiting for public vulnerability disclosures. Instead, they are taking the initiative and actively injecting malicious code into open source projects that feed the global supply chain.

By shifting their focus “upstream,” such as with open-source malware in “fallguys,” bad actors can infect a single component, which will then be distributed “downstream” using legitimate software workflows and update mechanisms.

Our 2020 report also shows that this is happening at a rapidly increased rate. In fact, there was a 430% increase in next-generation software supply chain attacks over the past year. Keeping this in mind, it is virtually impossible to manually chase and keep track of such components.

Sonatype’s world-class security research data, combined with our automated malware detection technology safeguards your developers, customers, and software supply chain from infections like these.

DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of malicious intent. Sonatype Nexus customers were notified of sonatype-2020-0774 within hours of the discovery, and their development teams automatically received instructions on how to remediate the risk. Their browsing history and gaming IMs are safe.

If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to find out quickly.

Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.

Do airplanes still use floppy disks for updates? Why?

Ax Sharma — Mon, 17 Aug 2020 07:49:30 +0000

Airplanes are a luxury for most people to own, let alone toy with—given all the national security regulations. This year’s DEF CON, however, revealed a fascinating finding leaving many, including myself, surprised.

July this year, British Airways announced it would retire its BOEING-747 fleet “due to the downturn in travel caused by the COVID-19 global pandemic,” as stated by their spokesperson.

This enabled security researchers, Ken Munro and Alex Lomas of Pen Test Partners to get their hands on a BOEING-747, and show us what goes on behind the scenes in the aircraft.

In their DEF CON presentation, the researchers gave a thorough walkthrough of the aircraft and pointed out something that Gareth Corfield of The Register wasted no time in reporting on.

They revealed a critical component of the BOEING-747 jet, the “navigation database loader” which uses 3.5″ floppy disks for updates, even in 2020!

The “diskette stowage” compartment next to the component has a number of floppies as the video (provided at the bottom) gives a quick glimpse of.

To update the navigation database, Lomas explained, an engineer would have to visit the aircraft every 28 days, with a set of floppy disks.

But why floppy disks?

In times where smartphones and IoTs are abundantly ubiquitous, and airlines brag about their inflight entertainment systems equipped with USB ports and Wi-Fi, why would such a critical nav system still rely on these legacy diskettes?

To be clear, not all airplanes do.

Jeff Carrithers, President of GlobalAir.com and a former aircraft researcher, has shed light on the matter:

“The aircraft you are referring must be a vintage aircraft. Floppy disk are no longer used in any modern era aircraft. The vintage aircraft may only have the legacy system still in place because the cost of updating the navigation system would be too cost prohibitive.”

Carrithers further stated this is a remnant of legacy aviation hardware from the seventies. “At a guess, this aircraft would be a commercial or military aircraft made in the early ’70s. Some private aircraft still use CDs to update their navigation systems,” he continued.

These points were further confirmed by a Flight Operations Expert from Simpfly, José Godoy who said, “Most aircraft flying out there have been designed in the 1980s or early 1990s when floppy disks were the ‘state of the art’ technology.”

Godoy said one can find these legacy technologies replaced from time to time whenever a newer fleet is launched:

“A good example is the A320, with the original project from the 1980s which uses floppy disks, while his new version, the A320neo, from 2010s, has ‘retired’ the floppy disks.”

What are “navigation databases” in an aviation context?

Jeff Hall, a senior consultant with and Wesbey Associates and a former private pilot explained that the navigation databases are not maps in the context of Google Earth of MapQuest.

“It is location and frequency information about flight navigation aids and airports in particular countries or regions. This is used in conjunction with programming a flight path when the pilots get on board for the flight.”

“The flight cases that pilots used to carry had the physical navigation charts from Jeppesen. Now those charts are stored on iPads or tablets that the pilots carry,” said Hall.

Godoy also weighed in on the subject, “navigation database comprises routes (composed by airways, waypoints and navigation aids) and airport information (runways, approach and departure instrument procedures).”

What’s with the 28-day mark?

It’s to do with how the U.S. government regulatory body, Federal Aviation Administration (FAA) would update the U.S. airport databases every four weeks, explained Carrithers.

The FAA would then mail these floppy disks to flight departments, aircraft control towers, airlines, and weather services around the country.

“This was all pre-internet and WAN networks were limited to single buildings, [unless] you were with the CIA or other secret organizations. But all large commercial or military aircraft were just starting electronic navigation systems in the cockpits,” Carrithers continued.

What about the security implications?

This is what’s debatable and I can understand both sides of the argument.

Arguably, leaving physical access the only possible way of accessing a critical system, such as via floppy disks, makes it much more secure than expanding the attack surface by opening up remote network access.

If the ground staff tasked with pushing the updates need physically go into the plane to update its navigation loader, the approach is far safer than Wi-Fi-powered “smart updates.”… But that makes ground staff the weakest link in the security chain.

“In theory, it would be more secure from a hack outside the aircraft. But it would probably not have any security protocols to login. Just put the floppy in the drive and it is on and then download it to a hard drive and overwrite the base code. Basic DOS prompts,” explained Carrithers.

What about malware and viruses?

Hall acknowledged, using floppies to provide updates is more secure than doing so over-the-air. But, floppies aren’t exempt from the risks of viruses and malware as expected from any external media device. Although this hasn’t caused any notable problems on airplanes thus far, as Hall states:

“I don’t recall an airplane ever becoming infected using floppy disks as the FAA and airlines had strict procedures for scanning disks for viruses and malware before they ever got near an airplane. But there were a number of incidents over the years where ATMs got infected by floppy disks and CDs performing updates on them.”

Further, these airplanes aren’t running widely used commercial OSes like Windows or Linux which attract malware attacks, “but special non-stop operating systems that are Unix derivatives, so it’s not as easy to infect as one might think,” Hall continued.But the other concern that remains is the use of outdated technologies in aviation.

“If it ain’t broke, don’t fix it!”

Aircraft use multiple legacy systems but the approach works and has worked sufficiently well for years.

“So much about aviation is old-school: the hardware, the software, the infrastructure. And ESPECIALLY the way people in aviation THINK,” said Patrick Smith, an airline pilot and the host of AskThePilot.com.

Reflecting on Carrithers’ previous comment, Smith said, “What is a ‘modern era’ aircraft? The 787 and A350, maybe? Most other planes are based on platforms developed in the 1980s or even the 1970s.”

[Full disclosure: Smith had no knowledge of Carrithers’ comment. I had posed to him a general question: if modern aircraft still relied on floppies]

Inconvenience: too many disks!

If it’s too expensive to replace floppy disk readers with say, a USB interfaced system, it’s understandable.

Moreover, USB ports can’t always be trusted. A cybersecurity professor had recently crashed an in-flight entertainment system using nothing but a USB mouse (CVE-2019-9019).

But using floppies is downright inconvenient. Each diskette can store a mere 1.44 megs. This means a typical update of navigation database may require a series of 8 or so floppies, loaded in a particular order.

A higher-capacity CD-ROM would likely be more efficient and eradicate errors—by that I mean, you wouldn’t have to worry about messing up the sequence in which the diskettes are to be inserted.

ACI Jet, a global aviation services company recently published a blog post titled, “Can data loading be fun?*” *which actually discusses this very issue.

“In any environment other than aviation, database loading would be easy and cheap (don’t say it). Being that the hardware required is on an aircraft, however, means that you’re likely doing this with archaic media such [as] Zip or floppy disks.”

The post describes the process of pushing the updates may sound easy but can take hours on older systems that have “spotty availability” and are unreliable. And, this nuisance has to be repeated every 2-4 weeks.

In the same blog post, the company lists some products which can take the plain out of the update process. These include capabilities like USB interfaces and wireless updates powered by an iPad app.

The company’s Avionics Manager, Brian Ford stated, “We routinely work on aircraft that use ZIP disks and PCMCIA cards to update databases, along with proprietary software to load said cards.”

“The ‘if it ain’t broke, dont fix it’ concept may be how people rationalize it, but ultimately the development cycles for getting hardware approved for aircraft moves glacially show compared to consumer electronics.

Much of that is due to the reliability, safety, and testing requirements to get the approval of the regulatory agencies involved. That means that once a piece of hardware in approved and installed, that design is unlikely to be improved upon.

If there are features that could be added to justify the cost of a hardware upgrade (perhaps Wi-Fi loading through an iPad vs. proprietary PC software that may require older hardware) then we can start to see components with modern interfaces like USB, such as in the article of ours you mentioned”

Now, for your viewing pleasure, here’s the original DEF CON video stream by Munro and Lomas:

Why don't Hulu or Netflix use 2-factor authentication?

Ax Sharma — Sun, 12 Jul 2020 10:53:04 +0000

Streaming service accounts get compromised all the time either due to data breaches, credential stuffing attacks from leaked databases, or simply because of users employing weak passwords.

How accessible a streaming service makes it for a rightful account owner to attempt recovery is what counts.

However, in the case of Hulu it may not be so simple, especially when a compromised account is too old, and let me explain why.

Yes, it happened to me (shame!). An ages-old disposable Hulu account I hadn’t used since college days, and which was setup with a lax password to trial the service, got compromised in January 2020. Personally, I didn’t care that much as this was a throwaway account to begin with, but it’s still better to keep what’s yours to yourself, so I attempted a recovery.

Not only had the attacker changed the account’s password, but additionally changed the email address linked to the account.

Image: Hulu sends out email alert when account email is changed (Source: Security Report)

Now, to be fair, Hulu did send out a security notification to the original email address informing me of the change, along with the “new” (attacker’s) email. Hulu’s recommendation was to call the 877 number to attempt an account recovery, “if you did not make this change.”

Mind you, calling U.S. toll-free (800 or 877) numbers from outside the U.S. can be incredibly painful. As of January 2020, which is when the account got compromised, I was no longer living in the U.S.

Once I did manage to get to the number via a VoIP phone, it had 30+ minute wait times at the time. After dialing on multiple occasions and eventually giving up on long hold times, I tried to find alternate means of contact: such as a web chat or ticketing system.

In what can be described as a catch 22, Hulu Help form requires you to log in first before contact with support can be initiated. Granted the security feature prevents unauthorized changes for existing users, it does nothing to help users whose accounts have already been hacked.

Image: Hulu Help online form requires a login first prior to initiating contact with support

Naturally, because the email address was changed to the attacker’s, a “forgot password?” link wouldn’t work. So contacting support via the online help form wasn’t an option.

Hulu also offers a “forgot your email” feature too but with a caveat: it requires your Hulu billing information. But in the event of account compromises like this one, the email has already been altered to the attacker’s, so how could this help?

Also, if the account is exceptionally old, was using a PayPal billing agreement, or is a “cancelled” account (from a billing perspective) the user’s credit card information, even if they can readily locate it, would no longer be applicable.

Image: Hulu forgot email form requires user’s billing information associated with the compromised account.

The question remains, what happens if the user is indeed able to locate their billing information for an account, but it still doesn’t work?

Email changed twice?

Could it be the attacker had removed the associated “card on file” or changed it to theirs? Or better yet, changed the email at least twice in a row so as to purge your original email from Hulu’s systems, along with the “newly set” attacker’s email (o*****l@mailsac.com) that Hulu notified the victim of, via a courtesy email.

This would leave no viable way for the user to identify themselves to Hulu, unless Hulu support staff has visibility into every such logged event.

In that case, what other option does the user really have other than being indefinitely locked out of their account?

When the user calls Hulu and does manage to get through their long wait times, they may not be able to identify themselves at all. Maybe the billing information and date of birth could help here.

I was able to call the 877 number of Hulu weeks later, at an unpopular time of the day, and the matter was sorted in a matter of minutes.

The Hulu rep on the phone, Teresa, asked me for my Hulu email address but it is unclear if the old address brought up any records. She then asked me to confirm the new email address on the account. Further, because the date of birth is immutable in the Hulu system that is what helped the representative verify my identity and in saving the day. The representative reverted the email address back to my original one.

“Your account is a cancelled account. Although your email address was changed,” said the rep, “none of your [billing] information was compromised. Hulu does not keep any credit card information on cancelled accounts, we use a different service for that.”

“It looks like you went through a different type of service anyway (PayPal) when you had signed up for Hulu using this email address.”

This was a simple close and shut case with a friendly representative who had no problem understanding the email addresses, spelled out over the phone and the overall situation.

However, countless stories have surfaced on the internet that bring to light the distress users experienced when “all the information [was] changed” from their hacked Hulu accounts.

Streaming services like Hulu should already be aware of these issues considering multiple members have shared their experiences on Hulu’s community forums:

In January 2020 alone a user named AStork posted in Hulu Community forum, “Alerting me when a new device is activated does me no good if that person took control of my account by changing the email address on the account.”

*AStork *further added, “Please send an email when the email address for the account is trying [sic] to be changed. That should be BASIC so that the owner of the account is authorizing the change, not the hacker. I couldn’t take control of my account without waiting over an hour on hold and then not knowing the gift card number that was added to pay for the subscription led to even further delays.”

Whereas others complained that their entire information had been changed, and they had to spend a considerable effort in reaching Hulu support:

“My account was completely stolen, they changed my password, my email, and my account information. The sad part is I had to Google customer service number for Hulu because you can’t get into any support options without even logging in, which I couldn’t do for my stolen account,” said user beazneez.

A spokesman from Hulu, Paul, responded within the forum, “Hey everyone! As of last fall, we now alert you via email when a new device is activated on your account.”

This idea and the original post were quickly shot down by yet another customer DeathHarb commenting in the same thread, “I’m sorry but this post is bullsh*t. They already do this. The problem is they ALLOW this to happen instead of requiring an extra verification, which was my idea which they deleted.”

Easy preventative solution

A preventative solution to situations like these that companies can implement is actually really simple: to request verification from the user via email, before the email address can be changed to another one, and to implement delays in between subsequent email changes.

For example, instead of Hulu just notifying the user that their email address was changed after it has already been changed, how about sending them a verification link which explicitly asks the user if they’d like to authorize the email change, by clicking the link? This would come in handy in the event of a compromise before any damage occurs.

Additionally, when changing email addresses, there should be a delay implemented in between subsequent requests. That means, say an attacker managed to change your email to theirs, they should not be able to change the account email a second time until at least 72 or so hours have elapsed, as an example. This would allow some time for the rightful account owner to attempt recovery.

For comparison, what happens when a Netflix account email address gets changed?

Image: Courtesy notification sent by Netflix when an account email is changed.

Unfortunately, Netflix doesn’t have the preventative security features I suggest here either. But at least they reduce the user’s dependence on telephone support by enabling contact with Netflix online and via live chat, from anywhere in the world.

Moreover, Netflix offers a proper knowledge base article educating users on mitigating this specific event when their account email is changed without permission.

Lessons learned

Incidents like these are reminders for users to enhance protections, such as using strong passwords and multi-factor authentication, where applicable. They are also motivators for companies to step up their security policies.

Steaming services are now more popular than ever, but they often trade off basic security for offering enhanced user experience, which is understandable. For example, even today Netflix and Hulu have not implemented two-factor authentication as it may cause issues with their older smart TV apps. But that is only an assumption.

When asked as to why, neither companies have responded to our request for comment.

Surely, Hulu does not let you sign up, even for a trial, without collecting billing information (PayPal or credit/debit card) which is a deterrent for casual surfers and adversaries wanting to “test drive” the Hulu platform aimlessly. And of course, collecting billing info upfront also helps with marketing and lead conversion efforts.

But, Hulu or Netflix require no re-verification of billing information or an explicit email verification sent out to the original address, during account email changes. Given such simplicity, account compromises can realistically leave users in the dark, if remediation policies around these are not properly orchestrated.

What to do when your account gets compromised?

If your account gets compromised, get in touch with Hulu or Netflix support as soon as possible with the available information ready, including your date of birth, billing details, and (if visible) the new email address set by the attacker.

With neither services offering two-factor authentication, as a general advice, users should use strong passwords, preferably generated by a password manager for their streaming service accounts, and never share the same password between any two websites. This may not totally prevent an account compromise, especially if you’re sharing your Netflix creds with a college buddy, it can still prove to be an effective deterrent strategy.

PlayStation discloses “severe” kernel vulnerability

Ax Sharma — Tue, 07 Jul 2020 07:11:48 +0000

PlayStation has disclosed a severe use-after-free vulnerability, after over three months since it was reported.

The vulnerability discovered by researcher Andy Nguyen exists in PS4 Firmware versions 7.02 and below. After constructing a demonstrable Proof of Concept (PoC) exploit, the researcher had responsibly reported the flaw to the company in March 2020.

If exploited in conjunction with a WebKit/Chromium vulnerability (such as CVE-2018-4386, in PS4 firmware versions up to 6.72), an attacker could:

Achieve a fully chained remote attack on a console.
Steal or modify user data.
Dump and run pirated games on the console.

“Due to missing locks in option IPV6_2292PKTOPTIONS of setsockopt , it is possible to race and free the struct ip6_pktopts buffer, while it is being handled by ip6_setpktopt,” states Nguyen in the HackerOne coordinated disclosure made public yesterday.

“This structure contains pointers (ip6po_pktinfo) that can be hijacked to obtain arbitrary kernel R/W primitives. As a consequence, it is easy to have kernel code execution. This vulnerability is reachable from WebKit sandbox and is available in the latest FW, that is 7.02,” the disclosure continues.

The researcher announced more details about the vulnerability through a Twitter thread:

Here you are, https://t.co/cdVyvdqGZ6, PS4 kernel exploit for FW 7.02 and below. Vulnerability discovered on 2019-06-09.

This must be chained together with a WebKit exploit, for example https://t.co/1BYe1aFGCe for FW 6.50.
— Andy Nguyen (@theflow0) July 6, 2020

Nguyen provided a sample local privilege escalation C exploit associated with this vulnerability. It can be chained with other exploits, such as that for CVE-2018-4386) to obtain remote access.

C exploit provided by the researcher for PlayStation kernel vulnerability (Source: Security Report)

Nguyen has been awarded a $10,000 bounty award for finding and responsibly reporting this vulnerability.

As of April 22, 2020, the vulnerable devices were patched by PlayStation after rating this vulnerability as a high severity. Firmware versions 7.50 and above contain the fix released by the company.

Incidents like these are a great reminder of the times how even seemingly innocuous IoTs such as gaming consoles can become targets of attackers and potentially be abused by nation state actors. Keeping your devices up to date at all times is an advice not to be taken lightly.

Originally published on and syndicated from Security Report

Hacking the antivirus: BitDefender remote code execution vulnerability

Ax Sharma — Tue, 23 Jun 2020 08:00:53 +0000

What happens when the very antivirus designed to keep you and your organization safe becomes a threat vector for the attackers to exploit?

Yesterday, I broke the news story on Bleeping Computer about a remote code execution vulnerability which was recently discovered and disclosed by security researcher and blogger Wladimir Palant.

Palant explained how the vulnerability, CVE-2020–8102, impacted BitDefender versions up until the one released recently: “An automatic update to product version 24.0.20.116 or later fixes the issue,” stated the company in an advisory.

Vulnerability Identifier: CVE-2020–8102
Date disclosed: June 22nd, 2020
Impacted components: Bitdefender Safepay
CVSS Score: 8.8
CVSS 3 Metrics: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

The vulnerability when successfully exploited can let attackers execute remote code on a Bitdefender user’s machine from any malicious website they control!

Vulnerability origins

Like many leading antivirus products and in an effort to provide overall system security, BitDefender acts as a Man-in-the-Middle (MitM) proxy intercepting and inspecting encrypted HTTPS connections.

Most of these products have a component geared towards online security, referred to by Safe Browsing, Safe Search, Web Shield, etc.

The vulnerability stems from the fact how BitDefender handles SSL certificates. When an invalid SSL certificate is presented by a website, most modern browsers let the user decide: to accept the certificate at their risk, or to navigate away. Likewise, BitDefender in an effort to offer safer browsing experience to users, provides its customized version of such a webpage:

Image: Invalid certificate error page generated by Bitdefender (Source: Wladimir Palant)

If a user still ignores HSTS warnings and continue to access the website at their own risk, that often poses no issues.

But, a key finding here, as Palant pointed out, is the URL itself within the address bar of the web browser remains constant. This causes Bitdefender Safepay to share security tokens between that (potentially malicious) page and any other website hosted* on the same server *and being accessed within Bitdefender’s Safepay virtual browsing environment.

Shared session tokens

Ideally these session tokens should not be shared between websites.

“The URL in the browser’s address bar doesn’t change. So as far as the browser is concerned, this error page originated at the web server and there is no reason why other web pages from the same server shouldn’t be able to access it. Whatever security tokens are contained within it, websites can read them out — an issue we’ve seen in Kaspersky products before,” Palant stated in his report.

Palant was able to verify this behavior by running a PoC. He setup a local web server and accessed it via Safepay. Initially, the server was designed to present a valid SSL certificate, but switching to an invalid one shortly after.

Once the certificate was switched to an invalid one, an AJAX request was made to download the SSL error page. Now, the same-origin policy in any web browser would naturally allow this request if it felt the same-origin was maintained, and so did Bitdefender Safepay.

“This allowed loading a malicious page in the browser, switching to an invalid certificate then and using XMLHttpRequest to download the resulting error page. This being a same-origin request, the browser will not stop you. In that page you would have the code behind the 'I understand the risks' link," Palant explained.

Image: The security tokens injected during a website by Bitdefender Safepay (Wladimir Palant)

These “security tokens” are hardcoded values that don’t change during a session; which is alright, but the same tokens are shared between different websites due to this bug, which is a problem.

Additionally, Safe Search and Safe Banking features of the component don’t implement any further protections, “As it turns out, all functionality uses the same BDNDSS_B67EA559F21B487F861FDA8A44F01C50 and BDNDCA_BBACF84D61A04F9AA66019A14B035478 values, but Safe Search and Safe Banking don't implement any additional protection beyond that," said Palant.

Remote code execution

This means, if a victim is tricked into accessing an attacker-controlled website via Safepay, the attacker can now have visibility into these tokens. And because these tokens are shared between the “isolated” banking websites accessed during a session, the attacker now has the ability to compromise those sensitive websites running in the same Bitdefender Safepay browser session.

But it doesn’t stop here. the attacker-controlled site can abuse the same token functionality to execute arbitrary code remotely on the victim’s machine, via a crafted AJAX request.

Image: Script to perform remote code execution (Source: Palant)

In just one example, Palant demonstrated how an AJAX request with a “data:” URI could be used to instruct the victim’s machine to launch a command prompt window running “whoami”:

Image: Remote executable downloaded and executed (Source: Palant)

Bitdefender has issued an automatic security update in version 24.0.20.116 and above to patch this vulnerability.

Yes, a fix has been released to safeguard affected users, but vulnerabilities like these pose a greater question: how secure are antivirus products themselves?

In spite of best intentions, such as providing a secure browsing environment, what happened here certainly wouldn’t sit well with Bitdefender users.

Unless one is super-duper sure when playing Man-in-the-Middle (MitM), it is probably best to leave encrypted connections alone: just as they were meant to be.

Originally published at https://securityreport.com on June 23, 2020.

NHS contact-tracing app code hints at security and privacy bugs early on

Ax Sharma — Mon, 25 May 2020 06:43:27 +0000

NHS recently announced plans to unveil their own coronavirus contact-tracing app, as opposed to joining leagues of Apple and Google, to have better visibility into citizen movements.

Suffice to say, the plan has certainly raised eyebrows of privacy activists, lockdown sceptics, and opponents of “big government.”

On the bright side, the NHS coronavirus app is open source, with code for beta versions of Android and iOS apps released on GitHub as of last week.

At this time, it also seems the app is *voluntary *to install for those willing to provide data on their movements, self-report coronavirus infections, and ultimately alert those who’ve been in close contact with them, as a safety practice.

The idea is to offer more insight to the government and each other, and better promote social distancing through sound use of data.

While the government developing a project of such national scale so rapidly is a bold move, it is commendable that they chose to open source it.

Because of this, we can hope any security vulnerabilities shall be discovered and remedied before adversaries get a headstart. After all, for an app like this, adequate security and user privacy controls are a must.

Dissecting the code

Commits don’t lie. I’ve said this before, if the source code reveals too much about what’s lacking in terms of security, malicious actors—hackers who are well qualified to read it, may begin exploiting the vulnerabilities before the “good guys” can patch them.

Of course, this greater transparency. at the same time, is a benefit of open source too. Bugs catch the attention of the public eye, get reported sooner, and are typically resolved faster than they would have in a proprietary system.

The very first iteration of source code attracts a lot of interesting GitHub issues which are obviously still open, given the recency of release.

Android repository

There’s already and allegedly at least one security (crypto-related) bug in the Android and iOS code which, from the looks of it, doesn’t generate “private keys” correctly, as per the norms of cryptography.

Because the keys are generated on an external web service rather than user’s device itself, the guarantee of privacy is rendered moot, in a strict cybersecurity context.

The issue reporter Michael Brown states, “this implementation flaw is separate from the basic design flaw of any centralised approach to contact tracing. The basic design flaw allows a government to trace the movements and meetings of its citizens.

This implementation flaw additionally allows the government to forge records of such movements and meetings, and to create valid digital signatures for the forged records.” Of course, whether such malpractices will happen in practice is hard to comment on.

Still, the flaw goes to the heart of cryptography basics, and the premise of data confidentiality and integrity which can only be guaranteed if the private key remains… private.

What good would be so much data if its integrity remains questionable?

Another GitHub issue, just short of turning into an online debate, concerns whether ProGuard should be enabled in the build or not. ProGuard is a widely used open-source tool for obfuscating* and optimizing code.

Since this is a “privacy sensitive” app, a commentator spotted, we might be better off leaving ProGuard out altogether. This would enable the security research community to easily reverse engineer and analyze the finalised live versions of Android APKs, for greater transparency.

Lastly, there’s the obvious shared devices social practice awaiting a solution. It isn’t unusual for members of the same household to share each others’ digital devices, especially kids using their parents’ iPad, for example, which could lead to discrepancies in data reporting.

*Obfuscation: scrambling source code so as to make it virtually incomprehensible and too cryptic for a human to read, in a quest to achieve security via obscurity.

iOS repository

From the discussion on GitHub, it appears the Apple version of the app isn’t immune from the “secretKey” (private key) bug either. There’s also slight disapproval of the “centralized” data approach the app apparently employs.

In the same thread, there is justification provided for how the centralized data approach might be anacceptable privacy tradeoff for the overall greater goal the app aims to achieve.

Some users surmised that the Google Analytics tracking functionality might constitute a GDPR violation as the code, at this time, does not ask for prior consent from the user. That one might be easy to work around via legal disclaimers and terms of service, in my opinion.

Privacy first

The biggest concern here is the privacy of the citizens, and the slightest but possible risk of the app becoming a doorway to government surveillance.

Even if no credible findings exist yet to indicate the plausibility of such adversarial motives, not every member of the public may feel comfortable enough trusting the app.

As if socially distancing strangers on the street wasn’t awkward enough, do we now want to become GPS beacons, transmitting our coordinates every minute – to the government and to everyone using the app?

There’s obviously the privacy concerns experts have raised, but the use of bluetooth technology and recent security vulnerabilities impacting bluetooth devices warrant taking a closer look.

As stated, once released on app stores, it seems the app would be voluntary to install. Researchers suspect, however, that the data reporting efforts of the app will be fruitful in “curbing the spread of coronavirus if at least 56 to 60 per cent of the population download it.”

Given the low adoption rates of similar apps in other nations, the projections can’t be too optimistic. For example, only one in five people (20%) have signed up for Singapore’s TraceTogether app.

Why so much time, effort, and money has been spent on this potentially “useless and unlawful” app is difficult to justify. No solution is perfect, and we are trying to find innovative ways to combat the *unknown*unknowns brought forward by COVID-19.

While the design of the app, and its planned objectives may make some cringe, the fact that it’s open source at least provides a slight degree of reassurance to beta testers.

☢️ Dissecting DEFENSOR: a stealthy Android banking malware

Ax Sharma — Sat, 23 May 2020 11:18:14 +0000

Android malware apps are nothing new, but this one is of particular interest in how it implements no such functionality that can be readily detected by security products. The apps named DEFENSOR ID and Defensor Digital rely mainly on Android's Accessibility Service to conduct malicious activities, and go undetected.

In fact, a blog post released May 22nd 2020 by malware researcher Lukas Stefanko of ESET states, "the banking trojan was available on Google Play at the time of the analysis. The app is fitted with standard information-stealing capabilities; however, this banker is exceptionally insidious in that after installation it requires a single action from the victim – enable Android’s Accessibility Service – to fully unleash the app’s malicious functionality."

The blog post also demonstrates at the time of its inception, no antivirus engine detected this malware sample.

Even today, only 5-6 detection engines are flagging these two apps, according to VirusTotal. This raises concern for the next iteration of malware that may be nothing but a slight modification of these apps.

Android Accessibility Service

To make smartphones more accessible to users with special needs, the Accessibility Service allows for the device to extend permissions to an app to read screen content (e.g. for providing text to speech synthesis capability). You can imagine how useful would such a functionality be to a malicious app.

Existing detection models can reliably predict when certain combinations of permissions requested by an app may pose problems. But because the Defensor apps mainly relied on obtaining Accessibility Service permissions from the user, along with some other minimalistic ones, no red flags were raised anywhere. The permissions requested by the app include the following, of which the critical ones are highlighted:

android.permission.INTERNET
android.permission.SYSTEM_ALERT_WINDOW
android.permission.BIND_ACCESSIBILITY_SERVICE
com.secure.protect.world.permission.C2D_MESSAGE
android.permission.ACCESS_NETWORK_STATE
android.permission.FOREGROUND_SERVICE
android.permission.REQUEST_DELETE_PACKAGES
android.permission.SYSTEM_OVERLAY_WINDOW
android.permission.WAKE_LOCK
android.permission.WRITE_SETTINGS
com.google.android.c2dm.permission.RECEIVE

In practice, this means the app can capture credentials entered by the user on mobile banking apps, read or generate SMS messages, read emails, read Two-Factor Authentication (2FA) codes generated by authenticator apps — thereby bypassing 2FA, steal cryptocurrency private keys, and so on, and upload all of this vital information to an attacker-controlled server!

The app also requests the WAKE_LOCK permission, letting it override the default screen timeout setting, and keeping the device turned on persistently. This would give malware an extended opportunity to launch other apps and to continuously capturing sensitive information.

The screenshots provided by ESET demonstrate this behaviour:

Indicators of Compromise (IOCs)

To make things easy for the security community, malware researchers at ESET have thankfully provided two useful IOCs identifying the malicious apps that have now been yanked from the Google Play store.

Package Name	SHA-1 Hash	SHA-256 Hash	ESET detection name
com.secure.protect.world	F17AEBC741957AA21CFE7C7D7BAEC0900E863F61	BBFB6DEDC01492CA3AC0C4F77343A22162518B306660E9CE958F2A6369FFAF13	Android/Spy.BanBra.A
com.brazil.android.free	EA069A5C96DC1DB0715923EB68192FD325F3D3CE	B5A64791728AA641838D2A478375F5D46F91C91B8DF0CDE34B21DDA2D4D7D8A1	Android/Spy.BanBra.A

New information and my analysis

ESET researchers have done a brilliant job of presenting their comprehensive analysis of these apps and their documented behaviour. Further to their report however, I'd like to add a bit of my own findings.

Command & Control (C&C) domains

The attacker controlled C&C domains are still up — well at least one of them, and that's problematic.

Domain	IP address	Task
empresasenegocios.online	132.148.42.16	Command & Control (C&C)
atendimentoempresarial.digital	184.168.221.46	Command & Control (C&C)

The URLs specifically used by the app to establish communication between the attacker-controlled server include:
https://empresasenegocios.online/remoteControl/
https://empresasenegocios.online/remoteControl/api/main/index/
http://atendimentoempresarial.digital/remoteControl/api/main/index
http://atendimentoempresarial.digital/remoteControl/

Interestingly, VirusTotal reports most antivirus engines are still not flagging these URLs, except for FortiNet which flags just one of the empresasenegocios.online URLs as phishing:

Nevermind the fact, the empresasenegocios.online domain still has a fancy admin panel for the attackers to log into and glance over the juicy details of their victims 🍿:

Here's also a preview of the API:

And the domain continues to be hosted on GoDaddy's shared hosting, with its beautiful cPanel and WebMail interfaces accessible:

empresasenegocios.online/cpanel:

empresasenegocios.online/webmail:

At least, atendimentoempresarial.digital domain has its GoDaddy parking page showing up for now. While that's no guarantee that the domain's malicious ownership or activities have ceased, so far there are no strong signs indicating ongoing activity either.

The WHOIS records of these domains didn't reveal anything particularly interesting other than Sãu Paulo, Brazil addresses and phone numbers, which could very likely be fakes, along with two email addresses belonging to the anonymous ProtonMail service: appdados@protonmail.com and notificador@protonmail.com.

The Takeaways

Enforcing BYOD policies

Because prominent antivirus engines are not detecting apps like these — even now, advice to "scan your mobile device" is futile.

SOC analysts and Security Ops professionals are strongly advised to enforce a corporate mobile device policy which restricts employee access to Google Play app store on their work devices.

Apps like these pose significant threats to an organization's secrets especially when an organization has a relaxed Bring Your Own Device (BYOD) policy, allowing for corporate email accounts to be accessible on an employee's personal mobile device (e.g. Gmail's Android app managing both personal and work accounts of a user would not be immune to attacks like these, and could easily infiltrate corporate trade secrets to malicious actors).

Network monitoring and blocks

Additionally, extensive network monitoring in your SIEM/EDR products should be setup for these servers, with network blocks implemented, given at least one of these domains is still active. That way, any device on your corporate network would be prevented from inadvertently making calls to these domains.

Note: The IP addresses appear to belong to GoDaddy's shared hosting, therefore blocking these could potentially block legitimate websites. It is best to block the malicious domains for the time being.

DEFENSOR ID and Defensor Digital were just two of the apps which have been identified and removed from the Play store, but given their stealthy behaviour, we do not know as of yet how many other apps might be using these servers or leveraging the Accessibility Service weakness.

The 'forgotten' ZEE5 data leak you didn't hear about.

Ax Sharma — Sun, 10 May 2020 07:40:02 +0000

In an exclusive story reported on my blog about a month ago and on no mainstream media outlet, credentials of some 1,023 Premium accounts were found floating on the web. These user accounts belong to the popular video-on-demand streaming service, ZEE5.

The origins of the incident date back to April 12th 2020, when a new data set titled, “Zee5 Premium” (archived here) emerged on Pastebin revealing email addresses and full plaintext passwords of some Premium users. The discovery was brought to light by notifications having been sent out by the data breach monitoring service, HaveIBeenPwned, which had likely detected the newly published paste automatically, and messaged its subscribers (and only its subscribers).

Naturally, surprised to see this on HaveIBeenPwned with no public report by any news outlet, and a total lack of correspondence from ZEE5, I reached out to ZEE5's support staff on April 15th, to request them to pass these findings on to the appropriate teams so they could investigate. They were quick to respond to the support request, even during the COVID-crisis times (which is respectable), and acknowledged they had passed the findings to the "the relevant team for their review." They further added, "[We] appreciate your time & patience in the interim. We'll update you once we hear from them."

To this date, however, there's no record of an email having been sent out to impacted ZEE5 customers, advising them to change their passwords, or a public statement acknowledging the data incident. Not to forget, if this was a case of data breach (we don't know yet), ZEE5's negligence in storing passwords in plaintext, without use of any hashing or salting is problematic, if this is indeed what happened.

It is not exactly known if this was a leak, a breach, or a classic case of credential stuffing...

...that is, the party behind the set had corroborated an already-compromised set of creds. from elsewhere against ZEE5's servers in an automated fashion, and published the ones that worked. This is plausible.

But semantics don't change the importance, or seriousness of these findings.

At the very least, ZEE5 could have automatically reset passwords of the impacted accounts.

Moreover, the content of the paste is rather interesting in how it reveals the origins of the user's premium plan (e.g. promotional offers), the expiration date of the plan, along with the auto-renewal setting; almost as if it's been pulled from an API, post successful authentication.

Their authentication REST API endpoint is rather dumb simple:

https://userapi.zee5.com/v1/user/loginemail?email=FAKE@example.com&password=testttt

A failed authentication attempt returns the JSON message:

{"code":2120,"message":"The email address and password combination was wrong during login."}

Whereas, a successful login returns a beautiful token eventually granting access to the user's account:

{"token":"eyJhbGc....8IND4sZBNpMLMQ"}

In times, where APIs are increasingly falling prey to credential stuffing, there does not appear to be a hard limit on the number of requests that can be made to ZEE5's API, or any additional captcha-style security roadblocks to prevent automated login attempts.

The multi-language video streaming company claims to serve over 190 countries, with its member base exceeding a whopping 150 million, according to some sources. The company delivers video content over multiple platforms — the web, smart TVs, mobile apps, etc. One would assume an operation of this scale would take security incidents seriously.

ZEE5 falls under the corporate umbrella of massive Essel Group, the powerful conglomerate behind numerous Indian television, entertainment and news channels, and with significant ownership in Dish TV.

That does not exempt Essel or ZEE5 from the corporate responsibility of ethically catering to its customers.

My motivation behind writing this piece stems from an ethical standpoint. I believe ZEE5 users impacted by the breach must be informed that their credentials were compromised at some point, and that they should change their password - not only on ZEE5, but anywhere else they've used it. And this is something the company has not done yet, which puts both their customers and reputation at risk.

How to protect yourself?

First things first, change your ZEE5 password immediately, whether your email address appears on the list or not. You may head straight to HaveIBeenPwned to see if you’re impacted by this incident, should the list be no longer available.

If this was a case of data breach and not credential stuffing, there remains a small possibility that ZEE5 is inadvertently continuing to store even newly set passwords in plaintext. My advice in such a case is to set a strong but disposable new password and not use it on any other site. Also, remove any overly personal information from your account — and if at all possible, request your account to be deleted permanently.

Remember, also, to change your password on any other website where you’ve used the same email address and password combination, as for your ZEE5 account.