Our industry is continuously inundated with new and innovative offensive techniques. Or, in this case… off-FIN-sive. While leveraging typical Internet of Things (IoT) devices has become commonplace, seeing atypical devices leveraged in novel attacks is something of a treat from our research teams’ perspective.
This week, news broke of an attack focused on an American casino. The result of said attack was ultimately the exfiltration of ~10GB of sensitive company data.
What makes this interesting is the particular connected device leveraged in the attack. The attackers behind the campaign were able to compromise a connected fish tank as a bridgehead of sorts. Once the connected fish tank was compromised, they were able to use it to gain persistence and perform further actions within the targeted environment (internal scanning, lateral movement, data manipulation and movement).
In the end, the attackers were able to move the near 10GB of company data to an external server in Finand (of all places). The actual need for a smart/connected fish tank may be open to debate, but in this case, the off-FISH-al purpose of the Internet connectivity is reported to be specific to remote monitoring and management. Not at all dissimilar from various SCADA, ICS and similar systems.
The lessons gleaned from this attack are also similar. When dealing with these types of devices, we need to be highly aware of the points of exposure and properly manage any associated risk. Mitigate or remove exposure and ingress/egress points where possible, and do not take any of these technologies for granted when it comes to patching/firmware/updates, etc.
Vendors can carp on about the convenience of Internet connectivity as much as they like, but the more we connect to the external world, the more we have to stay on top of the associated risk.
Last week, much of our industry was enveloped in the annual Black Hat and DEF CON conferences in Las Vegas. Covering all the valuable research that was shared between these two conferences (as well as BSidesLV and others) will have to be reserved for another blog and another time. However, one very important event that occurred at DEF CON this year was the first ever Voter Hacking Village.
Similar to other events (Car Hacking Village, etc.) the goal here was to create a totally open and rich environment for researchers to attempt to hack/exploit/break current voting machines and systems. All of these systems are currently in use in modern elections within the United States.
As could be predicted, researchers were able to compromise various machines/systems within the first 90 minutes. This is a subject near and dear to Cylance, and the criticality cannot be stressed enough.
Voting machine and system security has been a hot topic for many years and in every review, study and test, the same weaknesses and vulnerabilities continue to be exposed. So far, little has been done to fully overhaul the systems, let alone the overall guidance and requirements around how these systems are to be secured at the universal level.
We have yet to see a binding and required standard for how these systems are to be secured, and there are no standards that any of these manufactures are held to. The most current ‘Guidelines’ (Voluntary Voting System Guidelines Version 1.1) are exactly that - voluntary.
We still have a long way to go with regards to the security of these systems. Cylance has recently been at the forefront of research behind these systems. Some of our current research (including specific compromises on Sequoia Voting machines) can be found here:
Efforts like the Voter Hacking Village should be applauded. Allowing researchers and engineers full access to these systems can go a long way to both expose vulnerabilities, but also foster and environment of remediation and mitigation - especially when the actual manufacturers are both involved and supportive.
The more we (the industry) can get the likes of Dominion, Sequoia, Diebold, WinVote and others to participate, the better off we will be both as an industry and as a secure nation, able to increase and extend our ‘faith’ in the voting infrastructure going forward.
We are all familiar with typosquatting-type attacks when it comes to URL/DNS hijacking and similar. However, a recent wave of said attacks recently targeted npm (the users of it, rather). It was recently discovered that approximately 40 malicious packages were made available via npm’s repository.
Upon discovery, the packages were quickly isolated and removed. However, it appears as though they were present for close to two weeks before they were removed. The malicious packages were published on July 19 and removed on August 1.
According to a statement on npm’s blog, a user named ‘hacktask’ posted the packages with the intent to collect and exfiltrate data from “tricked” users. Based on information relayed in the same blog, there were 2770 total downloads spanning the 38 malicious packages.
For users and environments that were potentially exposed/compromised, it is recommended that the malicious packages be removed and promptly replaced with the legitimate pages, followed by a review and reset of any potentially exposed credentials.
The bigger lesson here is that attacks like typosquatting are absolutely not exclusive to the tried and true environments (URLS and similar). Software repositories, app stores, and beyond can all be used as attack vectors for this style of attack. A full list of the malicious packages can also be found on npm’s blog.
What can be done to protect against these types of attacks? With attackers and package spammers becoming more adept at these systems, it’s becoming more and more difficult to prevent and rapidly react. There is no single silver bullet.
It is always a good idea to double and triple check package names and download counts for anything you are installing. As per Ivan Akulov’s blog post, “If a package is popular but the downloads number is low, something is wrong.” npm is currently evaluating new and innovative measure to curtail this type of malicious activity.