It’s been about a month since we released Clawback, and we’ve received some good feedback. Others are asking how works and how it can help them? So, I’ve set up a small demonstration just to show how it would work in a couple scenarios that we’ve seen before.
Author Archives: Adam Hostetler
What’s the data leakage that DLP can’t detect?
During our engagements, we routinely look for source code or other internal sensitive information that could have been inadvertently posted. The team has been doing this as part of our standard engagements for quite awhile, and we routinely identify information through this method that clients are always thankful of being notified about. “But I have DLP!” – quite frequently, DLP won’t detect uploads to sites like Pastebin or Github.
New Attacks Against Misconfigured Amazon S3
Over the past few years we have seen plenty of news about data being stolen from misconfigured Amazon S3 buckets and other cloud based services. Now attackers are figuring out ways to further abuse these systems beyond simply stealing data.
Magecart, a threat actor group involved in a large amount of attacks, has a currently active campaign targeting S3 hosted sites; the attack infected these sites with malicious javascript that steals customer’s credit card data.
Their attack methodology involves specifically looking for buckets that have write permissions enabled for everyone. When one of these buckets is found, it looks for javascript in the bucket – increasing the likelihood that it’s being used to host a site, or serving assets for a site hosted elsewhere. Javascript files are then edited by the attacker and the Magecart malicious javascript is injected into it.
The javascript runs in the customer’s browser, looks for specific forms, and sends that data to another server when it is submitted. Without detailing this further, as there are many other good breakdowns of exactly what this attack entails that are available. The key take away here will be what can you do to make sure a site you have isn’t hosting this code.
Vendor Printer Management and Security
Over the past couple years we’ve encountered increasing numbers of customers using various print management vendors. Many that we have encountered are using the same application suite to manage the printers, and by default it has a blank admin password. In most of the instances we’ve observed this parameter has not been changed, or a strong password set. Likewise most of the managed printers also are not configured to use authentication or are using the default credentials.
When we encounter this one of the “benefits” this application affords us, due to the fact that it keeps a fairly detailed inventory with model number, is that it allows us to pinpoint areas of attack and compromise. Printers that we know have issues, or printers with functionality such as saving to network shares, SNMP etc. can be leveraged without doing activities that would be easily detectible on the network.
OSINT Yourself
If you’re unfamiliar with the term “OSINT” (open-source intelligence) it boils down to finding information that’s publicly and freely available about you, your company or anything else. How can this help you? OSINT covers a very broad array of sources and uses, and one way it can be used is to help verify your external network surfaces, and if user emails have been found in datadumps from compromised sites.
Micro Podcast – Amazon AWS
In this episode of the MSI podcast, we discuss recent issues involving AWS misconfigurations that led to incidents, common problems, the importance of proper configurations to avoid these issues and how we can help you identify them in your environment.
If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.
Do You Have Production Data in your Test Environment?
We’ve talked about development servers, and the perils of internet facing development environments. Now, let’s talk about what is IN your development environment.
Another issue we run into fairly often with dev environments,…they are set up to use production data, and sometimes this data is piped in directly at night with no modification. This introduces a risk of not only exposing this data through vulnerabilities within the development environment but could allow a contractor or unauthorized employee to view sensitive information.
There’s Still Treasure in the Trash
Most businesses have processes and policies for handling sensitive data on paper, whether thats selectively shredding papers or shredding everything, along with training about what goes in trash bins and what goes in shredding bins. However, how many are ensuring that these policies and processes are being followed? Brent asked
When was the last time you did a dumpster dive or wardial against your organization? You know these old school tactics still work, right? Yeah….
— L. Brent Huston (@lbhuston) June 27, 2018
Which got me thinking about this. I couldn’t remember the last time an organization actually asked us about it beyond reviewing policies. I know this problem didn’t disappear, even as we move more and more away from paper. Paper still gets used, people write stuff down, things get printed, and no solution completely ensures that that paper doesn’t end up in the wrong bin. I know from doing it. I found something useful in almost every engagement that we’ve done in the past, whether it was an administrative password, or contact information that I can use for phishing.
Recently, some researchers performed a trash inspection of some hospitals in Toronto. What they found didn’t surprise me. They found PII and PHI, a good bit of it. A resident in Palolo Hawaii found these too. A nuclear security complex was found to be dumping trash that had classified documents in it. None of these were reported breaches, just there for the taking. Who knows if anyone malicious found them too?
Let’s keep working on the most prevalent topics of the day, such as phishing defense and training, but we can’t forget all of the things that were an issue in the past, because they’re still an issue now even if they’re not making the big headlines in the current moment.
Cloudy With a Chance of Misconfigurations
Many organizations have embraced cloud platforms now, like Amazon AWS or Microsoft Azure, whether they are using it for just a few services or moved part or all of their infrastructure there. No matter the service though, configuration isn’t foolproof and they all require specific knowledge to configure in a secure way.
In some cases we have seen these services configured in a way that isn’t best practice, which led to exposure of sensitive information, or compromises through services that should not have been exposed. In many instances there are at least some areas that can be hardened, or features enabled, to reduce risk and improve monitoring capabilities.
So, what should you be doing? We’ll take a look at Amazon AWS today, and some of the top issues.
One issue, that is seemingly pervasive, is inappropriate permissions on S3 buckets. Searches on S3 incidents will turn up numerous stories about companies exposing sensitive data due to improper configuration. How can you prevent that?
Firstly, when creating your buckets, consider your permissions very carefully. If you want to publicly share data from a bucket, consider granting ‘Everyone’ read permissions to the specific resources, instead of the entire bucket. Never allow the ‘Everyone’ group to have write permissions, on the bucket, or on individual resources. The ‘Everyone’ group applies literally to everyone, your employees and any attackers alike.
Secondly, take advantage of the logging capability of S3, and monitor the logs. This will help identify any inappropriately accessed resources, whether through inadvertently exposed buckets, or through misuse of authorization internally.
Another common issue is ports unnecessarily exposed on EC2 resources. This happens through misconfigurations in VPC NACLs or Security Groups, which act as a firewall, sometimes found configured with inbound traffic allowed to any port from any ip. NACLs and Security Groups should be configured to allow the least amount of traffic to the destination as possible, restricting by port and by ip. Don’t forget about restricting outbound traffic as well. For example, your database server probably only needs to talk to the web server and system update servers.
The last issue we’ll discuss today is the IAM, the Identity and Access Management interface. Firstly, you should be using IAM to configure users and access, instead of sharing the root account among everyone. Secondly, make sure IAM users and keys are configured correctly, with the least amount of privileges necessary for that particularly user. I also recommend requiring multifactor authentication, particularly on the root account, any users in the PowerUsers or Admins group, or any groups you have with similar permissions.
That’s all for today. And remember, the good news here is that you can configure these systems and services to be as secure as what is sitting on your local network.
Malicious libraries and plugins
How closely do you inspect what 3rd party plugins and libraries you use with software and development? We kind of tend to take for granted that once we vet a library or plugin and add that into our usage, then it’s likely to never be a threat in the future. However, over the last few years attackers have started increasing abuse of this trust. A type of watering hole attack that reaches a larger amount of people than a typical focused attack.
There’s 3 main ways this has happened:
- Attackers buy the plugin/library from the original author or assume control of one that is abandoned
- Development system or other system in chain is compromised by attacker
- Attackers create releases that mimic popular and established libraries/plugins in name and function
This has affected a wide range of software, from web applications to web browsers to text editors/IDE’s. Let’s take a brief look at a few instances.
WordPress Display-Widgets plugin. This plugin was sold by the original developer, and at that time had several hundred thousand active installations. The new developers then added code to it that downloaded and installed a plugin that added spam the site.
The Node.js package repository was found to have malicious packages that looked like real packages, differing slightly in the name in an attempt to fool anyone trying to find specific packages. The malicious packages generally tried to send sensitive environment data back to a server.
Python also experienced something very similar. Package uploaded in an attempt to fool anyone not paying close enough attention. Not relying on just misspelling the name, but with names that look legitimate, such as “bzip” for the real package “bzip2file”.
Those are just a few examples, Chrome and Firefox have both had similar issues multiple times as well. So how do we protect against this? Partly some of this has to be on the software that allows the plugins to run. There are some bad policies and practices here, such as WordPress letting anyone claim “abandoned” plugins.
Some things you can do yourself are to install any libraries/plugins (for python, ruby etc) with your systems package manager. If you use pip, gem or the like, make sure you are using the correct plugins, avoid misspellings or “close enough” names. Check the reputations of plugins via Twitter or search for reviews and info on plugins, by name, in your search engine. If you find any anomalies report them on social media and forums associated with your language. Try not to use plugins that have been abandoned and recovered by another developer with no reputation.