Attack Surface [Guest Diary]
[This is a Guest Diary by Joshua Tyrrell, an ISC intern as part of the SANS.edu BACS program]
Managing the Attack Surface
You’ve begun the journey of reviewing your IT infrastructure and attempting to figure out how to protect yourself from those who might not have the greatest intentions. That’s great! Stop yourself though, before you get too far into the weeds of the different technologies available to you to defend yourself. Before you get to that point, there are some details that need to be fleshed out. Let’s have a look:
- What industry are you in? Depending on the service provided, you may already have a baseline that you need to be at, provided to you by those who came before you and have danced with those who mean you harm.
- Where and who do you do business with? If you’re a utility provider in Topeka, Kansas, does it make sense to have your online presence available to the general public outside of the Continental United States? Think about the potential risk versus limiting access to those who need to manage it.
- What does your organization actually need to be successful? What data do you actually need to survive, what devices are necessary, what software will get you to where you need to be?
These are all pertinent questions to either scaling up or scaling down your attack surface and working towards having chaos-free Friday nights.
Fortify the Exterior Walls
Defense-in-Depth is the name of the game in the 21st Century, but that doesn’t mean we shouldn’t be doing what we can to make sure the perimeter walls aren’t as imposing as possible. You use firewalls, yes, but are you using them to their maximum potential? Modern firewalls allow for geo-blocking, which is the blocking of traffic based on IP addresses correlated to countries. These databases are updated somewhat regularly, so there is maintenance to be done on your firewalls to make sure they’re up to date. If you’d like even stronger evidence for using geo-blocking, search for “Top 10 Countries where cyber attacks originate”. Lists have been generated by teams across the world to show where many of the world’s cyber criminals are calling home. Now though, what if you do have a business partner that resides in one of those countries that you may not want traffic widely from? Easy enough, create an exception for their ASN in the geo-fence.
Another tool at your disposal is reputation filtering. This process allows your firewall to reference the IP of either source or destination and forward or drop the packet as per the policy. This can be highly effective at reducing the amount of potentially malicious traffic that is not initially blocked by your geo-fence. Take heed though: Cloud Service Providers may be unintentionally flagged and dropped due to the nature of their business model. There is a way to help you navigate this mystery though, and that is to simply look at who the largest CSP’s are, and weigh that against historical traffic to your assets. You may want to allow AWS, Azure, GCP, and even DigitalOcean, but how about that small-time server farm in Seychelles? Or the Netherlands? Those you can probably block outright, after considering those initial questions we talked about earlier.
We spoke about traffic coming to the outer walls, but what about traffic trying to get out of the gate? You should consider blocking websites internally. i.e. social media sites. You can go one step further and segment your network to allow certain employees to access those sites, should it be within their role’s purview. If employees want to peruse social media while working, let’s say they’re on downtime, then force them to connect their devices to a well-segmented guest network. It is probably not worth allowing them to access these things from a network that also houses production environments though.
Email is one of the most widely abused mechanisms for delivering malware and social engineering. What can we do about it though? Well let’s set up an email gateway, so we can filter out the wheat from the chaff. Modern email gateways allow integration of services like VirusTotal, which would scan the email attachments and flag them for being potentially malicious. You could also integrate a sandbox, which would then scan and ‘detonate’ email attachments to find the malicious threats hidden in the mail. Obviously, before implementing these services you need to test them. That goes for all your possible interventions though; don’t just throw things into your infrastructure and hope for the best.
Another way to protect from bad emails is reputation filtering, much the same way we discussed earlier. There is a problem however- scammers, spammers and all the other generally not-so great people like to use free email services like Gmail, much like the rest of us. So, what could we do? We can’t just block inbound Gmail, that could be disastrous for communications. What we can do is server-side filtering to allow the free email services to go to some internal email addresses but not to another. Your customer service team might need to talk to people who are using Gmail, but how about your engineering team? Or your HR team?
You can safely assume that these protections can be costly, in terms of both finance and time. If you’re a smaller organization, these might not be feasible to do, at least in-house. You may have to source the assistance of a third party, or perhaps form a consortium with other like-entities and purchase the solutions from a vendor. When considering time, think about your mean time to recovery. If you’re organization is breached, how long do you have until there’s no coming back?
Harden your Outposts
You need to be better at managing your devices. You might find the tone accusatory, which is fine, it’s supposed to be. By reading that statement though, you probably just started doing an inventory of all the things you’ve done to protect your endpoints, to the best of your knowledge and ability. Let’s look at some of the top things you can do to make sure you’re best protected.
First, you need to inventory what you have. You cannot protect what you don’t know exists, so go ahead and run that internal nmap discovery scan to find that web server you stood up 10 years ago but then never touched again.
Now that you know what you have, let’s take a look at patches. Patching needs to be done, or if not, then you need a good excuse and mechanisms to protect the enterprise from issues that may arise from leaving a weakness in the network defenses. Depending on where that weakness is, you’ll need to increase the surveillance on the assets that connect to that unpatched or out-of-date asset. Patch management also needs to exist, don’t just run “Scan for Updates” on your Windows machine then let it update in the middle of the workday. Have yourself a testing environment, and stage those updates. If you need any other supporting evidence for this notion, then I’ll direct your attention to the recent global CrowdStrike outage.
BYOD, or “Bring Your Own Device”, is an idea that has taken off due to cost, but it does have its issues. The first issue is vulnerability management for that device. You have potentially hundreds or even thousands of different devices that you have no control of whether they are up to date with the latest security patches. If you cannot avoid BYOD, say because of cost, then you’ll need to really be up to date on what devices your employees are hooking to the network. Make a note of the devices they plan on using for work, and if they purchase a new one, have them reach out to your IT staff and let them know about it. If you cannot control what devices are accessing your data, then you’ll need to compensate by working even harder to manage your alerting mechanisms.
Data commingling is another issue. How to control what happens to the business data that is on that device? Applications as well, having no idea what these people are downloading on to their devices and the vulnerabilities they are introducing. More on Application Control: find the best possible software for what you need it to do and stick to that. It does you no favors to use several different IDEs for software development, or package management. This also assists in general IT operations, not just security.
Managing the attack surface is no easy task, and entire books could be and have been written on what to should do. I hope though, that what I’ve highlighted here today helps you down your path.
[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Scans for Moodle Learning Platform Following Recent Update
On August 10th, the popular learning platform "Moodle" released an update fixing CVE-2024-43425. RedTeam Pentesting found the vulnerability and published a detailed blog post late last week. The blog post demonstrates in detail how a user with the "trainer" role could execute arbitrary code on the server. A trainer would have to publish a "calculated question". These questions are generated dynamically by evaluating a formula. Sadly, the formula was evaluated using PHP's "eval" command. As pointed out by RedTeam Pentesting, "eval" is a very dangerous command to use and should be avoided if at all possible. This applies not only to PHP but to most languages (also see my video about command injection vulnerabilities). As I usually say: "eval is only one letter away from evil".
The exploit does require the attacker to be able to publish questions. However, Moodle is used by larger organizations like Universities. An attacker may be able to obtain credentials as a "trainer" via brute forcing or credential stuffing.
I got pointed to "Moodle" after seeing this URL in our "First Seen" list of newly accessed URLs:
/lib/ajax/service.php?info=tool_mobile_get_public_config&lang=en
This "public config" may return additional details in some cases, but from my tests with a demo instance of Moodle, it only returns:
{"error":"Coding error detected, it must be fixed by a programmer: Invalid json in request: Syntax error","errorcode":"codingerror","stacktrace":null,"debuginfo":null,"reproductionlink":null}
At least this URL could be used to find Moodle instances and probe them later with more specific exploits. I will have to add this case to our honeypot responses to get more details. These scans are not new, but we had only individual scans (one or two per day) so they never passed our threshold as "significant". Only yesterday did they pass the "line".
But in the meantime:
- Keep Moodle up to date (they do have a decent chart outlining support timeframes for different versions)
- Audit the "trainer" accounts, not just because of the vulnerability, but in general, they can cause damage to the system.
- Let me know if you have additional insight into Moodle. Is there something else that this URL could trigger?
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments