Introduction

A patch was released in September of 2021, so users who updated their code won’t be exposed to this attack. Users who have not updated should do so as soon as possible. It is unknown how many of the ~167,000 applications that use this library are running vulnerable versions. The purpose of this exercise is to encourage developers to update to an adequately protected version, detailed throughout this blog.

What is SLO Generator?

According to their Github page, SLO Generator is a tool to compute and export Service Level Objectives, Error Budgets and Burn Rates, using Configurations written in YAML or JSON. In layman’s terms, it’s a tool for engineers who wish to track their web API performance. Many Google services, along with other projects wishing to record these metrics, use this tool.

SLO Generator Python library can be directly installed from PyPI with pip

Figure 1: Installing the SLO Generator Python library

Usage

Once installed, it is easy to generate the SLO report with the command line interface

“`slo-generator compute -f slo_config -c shared_config –export“`

Here, 

Compute argument to the slo-generator indicates that we want to generate a SLO report

The tool also provides the functionality to migrate older, version 1 configuration to newer, version 2 configuration.

“`slo-generator migrate -s old_config/ -t new_config -b error_budget_policy/config.yaml “`

For a successful migration, the migrate command needs 3 inputs from the user:

1. a directory containing old SLO configurations.
2. a directory containing newer slo configurations
3. a yaml file containing error_budget_policy

Exploitation

There are several techniques to find a potential vulnerability in older versions, such as manually combing through the source code, fuzzing the application, or analyzing recent patches to the application. 

Let’s analyze the recent patches first, attempting to discover any potential vulnerabilities. SLO Generator is an open-source tool; this information is all publicly available on their Github repository.

Looking through the release notes of version 2.0.1, we can see that they fixed the yaml loader security issue, meaning older versions of SLO Generator (i.e. v 2.0.0) would have the yaml loader vulnerability.

Figure 2: Version 2.0.1 fixes the yaml loader security issue

Looking at the changed files, we can see that in the patch, developers have replaced yaml.Loader, which is vulnerable, with yaml.SafeLoader.

Figure 3: Developers replace yaml.Loader with yaml.SafeLoader

Looking at the official documentation for pyyaml, it is mentioned that calling yaml.load on any untrusted data is as dangerous as pickle.load, a common attack path making it possible to provide malicious shellcode as input, causing remote code execution.

This indicates that if we can control the data which is passed to the yaml.load function, we can perform a python deserialization attack to get the code execution on the application.

Looking through the changes, we see there is a function called ‘ebp_v1tov2’, which is calling the yaml.load function on a variable called “conf”. As we can see on line 262, every file in the variable ebp_paths will be passed through yaml.load as “conf”.

Figure 4: Dissecting code line 264 for yaml.load

As per line 70, ebp_paths is a list containing files in error_budget_policy_path which we pass to the application.

Figure 5: Code line 70

Creating the Exploit

Our first step is to create a malicious python deserialization object that we store in a yaml path. Next, we call the migrate function with error_budget_policy_path pointing to our malicious file. Our malicious file will be loaded by the application and our code will be executed.

As generating a yaml deserialization payload is out of the scope, we will find a common deserialization payload and copy it to our attack yaml file as exploit.yaml.

Figure 6: Deserialization payload with exploit.yaml

Now, running the following command to exploit the application:

Figure 7: Command to execute payload

As SLO Generator is a widely used python library, a code execution vulnerability makes it more severe. A typical exploit scenario would be executed in a web application to migrate user-supplied configuration.

Solution

All instances of SLO Generator should be updated to the latest version. Most applications handle user-supplied yaml data. Yaml data should always be handled correctly. Avoid using unsafe functions such as yaml.load, and replace it with yaml.SafeLoad. At an absolute minimum, it is imperative that all instances be updated past ‘yaml loader security issue 173’ to protect against this exploit.

Key Takeaways

This exploit shows the severity of using unsafe functions such as yaml.load. Any application that processes user data directly should always handle data with extreme caution. From an attacker’s perspective, if an application is processing user input directly to a yaml.load function, the application could be vulnerable to the Python YAML deserialization attack.

Best Practices

• Always keep all dependencies up to date with a dependency manager.
• Never use unsafe functions to directly process user data.
• Check for and install updates/patches when available.

Conclusion

Although this version of SLO Generator has been updated since September 2021, it nonetheless highlights the importance of proper and timely stewardship of software tools. As we have explored in this blog, it is relatively easy for an attacker to create an exploit for an out-of-date version. There are thousands of web applications being built with libraries such as these. Dependencies can be a useful tool, but can also come back to haunt you if not looked after properly. Lookin’ at you, Log4j.

References

1. Agrawal, A. (2014, November 18). Understanding Python pickling and how to use it securely. Synopsys blog.

https://www.synopsys.com/blogs/software-security/python-pickling/#:~:text=Dangers%20of%20Python%20pickling,data%20received%20over%20the%20network.

#exploit #python #google #slo_generator #YAML #vicarius_blog

Intro

In short, Threat Intelligence (aka Threat Intel) is the process of analysing data and information, with the use of techniques and tools with the goal to generate meaningful insight and patterns as to how you would mitigate potential risk that are associated with existing or emerging threats that are targeting orgs, industries, governments, etc.

We are generally interested in who is attacking us, why, and what are their capabilities. Also, we care about what IOCs and artefacts we should look for, when investigating our environment (for a particular group/threat actor).

Since Threat Intel tries to understand the connection between your operational environment and the threat actor, it usually gets broken down into the following:

• Strategic Intel
• Technical Intel
• Tactical Intel
• Operational Intel

Strategic Intel – Here, you look at your org’s threat landscape, mapping the risk areas based on trends, patterns and emerging threats that might be able to impact your business’ decisions.

Technical Intel – IR teams use this intel to create an attack surface to analyse and create defence mechanisms. Usually done by looking at the IOCs and artefacts that are tied to the threat actor.

Tactical Intel – Assessment of the TTPs used by the threat actor.

Operational Intel – Investigates the threat actors’ intent and motives for the attack. This intel may be used to understand what some of the critical assets are the org has that can be targeted. (people, technologies, etc.)

Abuse.ch

This project started as one man’s initiative but is today a community driven threat intel platform for cyber threats. In their own words:

abuse.ch‘s main goal is to identify and track cyber threats, with a strong focus on malware and botnets. We not only publish actionable threat intelligence data on cyber threats but also develop and operate platforms for IT security researchers and experts enabling them sharing relevant threat intel data with the community.

Their platforms are:

Malware Bazaar – For sharing malware samples with the community and threat intel providers

Feodo Tracker – Tracking botnet C&C infrastructure associated with Emotet, Dridex and Trickbot

SSL Blacklist – Resource for collecting and providing blocklist for malicious SSL certificates and JA3/JA3s fingerprints

URL Haus – For sharing malware distribution sites with the community and threat intel providers

Threat Fox – Resource for sharing IOCs (Indicators of Compromise) with the community and threat intel providers

Yaraify – Resource for hunting suspicious files with YARA. Also, for sharing your YARA rules with the community

 

Malware Bazaar

This platform acts as a malware collection and analysis database.

You can upload malware samples through browser/API, consequently adding to the intelligence database. This threat intel can also be integrated into your SIEM.

You can also hunt for malware setting, by making alerts that would match different signatures, YARA rules or vendor detection.

 

Feodo Tracker

This platform looks to share intel on botnet C2 (command & control – C&C) servers that are associated with Dridex, Emotet (Heodo), TrickBot, etc.

This is done by giving the C&C servers db’s to the security analysts that can then investigate any IP address they deem suspicious or have seen already. There’s also information on IP and IOC blocklists, and mitigations used to avoid infections by botnets.

SSL Blacklist

This tool identifies and detects malicious SSL connections, further blacklisting the SSL certificates used by botnet C&C servers. It also identifies JA3 fingerprints which can help you detect and block botnet C&C comms within the TCP layer.

You can sift through the SSL certs and JA3 fingerprints, but you can also download them and add them to your deny list/threat hunting ruleset.

URL House

As an analyst, this is an awesome tool for you to perform some validation for your investigation. You can look through the database for URLs, hashes, domains and other malicious filetypes. You can also contribute with your own malware URLs in order to help others protect their networks.

URL House can also give you information on AS numbers, TLDs and associated countries.

ThreatFox

The ThreatFox platform is made with the idea of sharing and exporting IOCs that are associated with malware. You can export the threat intel from ThreatFox in many formats (JSON, CSV, MISP events, Suricata IDS ruleset, Domain Host files, etc.)

Recap

Threat intelligence (aka TI or Cyber Threat Intelligence) is what you would use to supply information regarding threat landscape – TTPs, threat actor groups, etc.

To be considered threat intel (TI) the data must become actionable, and to become actionable, you would want to analyze it first. Thus, the data needs some context in order to qualify for becoming a viable piece of threat intel.

The threat intelligence usually changes quickly, as the threat actors change their TTPs often.

Companies and vendors can share their threat intel within ISACs – Information Sharing and Analysis Centers.

Another breakdown of the TI process can be like this:

• Strategic – Helping management make informed decisions when it comes to security and strategy.
• Operational – Interacting with IOCs and learning more about how threat actors do their work
• Tactical – Interacting with the TTPs and attack models to learn more about the specific threat actor group and its patterns of attack

I also suggest checking out these two great resources to learn more about APTs and their techniques (TTPs):

• https://docs.google.com/spreadsheets/u/1/d/1H9_xaxQHpWaa4O_Son4Gx0YOIzlcBWMsdvePFX68EKU/pubhtml
• https://www.mandiant.com/resources/insights/apt-groups

(I will add a few more links at the end of this article)

Conclusion

Okay! So, I looked into the TI process for a bit. This is a big landscape, with a lot of events that are constantly happening. To stay current, you would need to find good resources to follow, as well as create an adequate process at your company on how to handle it, why, and in what ways/cases.

The most interesting part (at least for me) is the fact that when you investigate this behaviour (let’s say you’re using the aforementioned Feodo Tracker to investigate C2 botnet servers) you’re actually learning about what the adversary does and this is the most precious thing to have. You’re learning realistic things, that are happening all the time around the globe, all the while trying to prevent your organization from getting compromised.

You’re not only being proactive, but you’re also learning about what is really used in some of those breaches you can usually read about. This is invaluable, as it can give you the edge against adversaries, when it comes to securing your environment against them.

Stay safe out there, and gather some TI!

Additional Resources

• https://www.nationalisacs.org/member-isacs-3
• https://www.circl.lu/doc/misp/
• https://github.com/MISP/
• https://threatconnect.com/
• https://otx.alienvault.com/
• https://www.ecb.europa.eu/pub/pdf/other/ecb.tiber_eu_framework.en.pdf
• https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/pf/ms/sb-tiber-eu.pdf
• https://www.enisa.europa.eu/topics/national-cyber-security-strategies/information-sharing

Cover image by Alexandre Debieve

#threat_intel #abuse.ch #ioc

Intro

Alrighty! This one has long been on my to-do list! OpSec! Why, how, when, who… how much and how long… Let’s see! Let’s answer some questions. Whether you’re sleuthing for some OSINT investigation, or your country is blocking you from watching your favorite shows on Netflix, you need to figure out your specific OpSec needs, and behave accordingly.

This one is a particularly interesting topic, as it combines a lot of elements – from purely technical to some psychological/behavioural ones.

Before I go further into the topic, I would emphasize that this is my opinion. You can always argue the technicalities, sure, but the methodology is unique – as it should be – again, in my opinion. (Though in this article I am not discussing that many technical aspects)

This is quite logical, as we all have different needs, and are encapsulated within different contexts. What’s true in my case might not necessarily be true in yours. So, with that in mind one might ask – what’s there to learn, then? And it is a valid question! However, we’re interested in the approach here – which is also unique to each and every one of us.

My goal here is to help you be more involved in taking the control of your own privacy and having a healthier and safer online presence which surely accounts to a large portion of your life in general, as we’re all getting more and more dependent on myriad of online services.

Now that I’ve made the intro, and safely fenced off from the personal aspect involved in this topic – let us proceed.

Basics

At its core, OpSec is just managing risk. In the personal case (one I’m looking at), the risk comes from whatever you deem worthy of incorporating into your model. Thus, you’d also want to have a threat model – no need to go overboard here though. This is just meant in a context of you identifying what information you’d want to protect at all costs i.e., no leaks, or if there’s some that you might be fine with being discovered. I purposefully lead with the first sentence above, as you will probably encounter many definitions – but the bottom line is always about that I/O of your personal information. You want to control both I and O in the I/O, but you definitely have to focus on the O – in other words, your model and the way you conduct yourself should be in sync with what you’re trying to achieve. Again, based on the model.

You want to prioritize as well. Best practices are best practices for a reason but will deteriorate rapidly if applied blindly (without context to match). I debated with myself whether to include best practices at the end of this article and opted for it in the end. The argument against it was backed by the second sentence of this paragraph. I am counting on you here!

Traditionally, there are stages when it comes to OpSec (well, for 3 letter agencies and Military it really makes sense) and I will mention that here as well. However, I want to emphasize that I am doing that for the contextual and historical reasons, as well as for you to be more informed. In the end, though, you’re not required to draft any complex models based on the ones Military uses. Their threat model is surely different than yours, so their OpSec needs are too. The methodology/approach is what you should focus on. Thus, before taking any action first, take a pause and contemplate on it. The future you will be better off i.e., safer online.

Defining OpSec

Okay! I am now going to reference some definitions so you can see how that compares to what I’ve been trying to convey.

1 – (Published by Range Commanders Council, U.S. Army White Sands Missile Range – full .pdf document found here)

The OPSEC is a process of identifying, analyzing, and controlling critical information indicating friendly actions attendant to military tactics, techniques, and procedures (TTPs), capabilities, operations, and other activities to:

• Identify actions that can be observed by adversarial intelligence systems.
• Determine what indicators adversarial intelligence systems might obtain that could be interpreted or combined to derive critical information in time to be useful to adversaries.
• Select and execute measures that eliminate or reduce to an acceptable level the vulnerabilities of friendly actions to adversary exploitation.

As you can see, this is very applicable for us as well! TTPs of the well-known ATPs are already documented by MITRE (since I am talking about the Cyber domain), and aside from the specific stuff regarding military operations, this definition seems quite solid!

To digress for a bit:

Unless you’re a CEO of large Enterprise that’s targeted by advanced threat actors, you might care more about the TTPs. In an average guy wants to prioritize his privacy online scenario those ‘TTPs’ are quite different in nature. However, the goal is the same – a script kiddie trying to mess something up for the fun of it might not invite ATP levels of controls, yet they can still devastate you. Take it all into account and assess critically. Start with the basics, and build from there, don’t go overboard just to get pwned by a newbie hacker that bought a phishing kit on the Darkweb.

Circling back to the definitions, let’s do one more:

2 – (Published by the Department of the Navy, US Marine Corps – the .pdf can be found here)

OPSEC is a capability that identifies and controls critical information and indicators of friendly force actions attendant to military operations, and incorporates countermeasures to reduce the risk of an adversary exploiting vulnerabilities. When effectively employed, it denies or mitigates an adversary’s ability to compromise or interrupt a mission, operation, or activity. Without a coordinated effort to maintain the essential secrecy of plans and operations, our enemies can forecast, frustrate, or defeat major military operations. Well-executed OPSEC helps to blind our enemies, forcing them to make decisions with insufficient information.

This is it …a capability that identifies and controls critical information… and incorporates countermeasures to reduce the risk of an adversary exploiting vulnerabilities…

As you can see the proactive nature is what lies at the heart of OpSec. You taking into account stuff that could compromise your vulnerabilities and drafting a plan to mitigate that before it occurs. There is no reactive OpSec! At that point, you’ve already been pwned, and depending on the criticality of the breach you’re in some (deep) trouble. This also means that one misstep in your (not so) robust model is enough to take it all down. And it makes sense – a hacker just needs to find one way in and they’re off to the races!

Stages of OpSec – OpSec process

Using our US Navy document, we found this neat little graphical representation of OpSec stages

From 1. to 5. you’d have:

1. Identification of critical information
2. Analysis of threats
3. Analysis of vulnerabilities
4. Assessing the risk
5. Applying countermeasures

This is also what you’d get if you Googled for “OpSec stages.”

However, it might be hard(er) for you to analyse threats – as you’re just a civilian, so you’re not really the target, but you still can end up being a target. Just some more food for thought.

(Also, note that the process is circular)

Anonymity vs Privacy

This is the hot stuff right here! VPNs are there for your privacy not anonymity. That’s what TOR is all about. You need to understand this distinction.

The idea is that privacy is you keeping some things for yourself, and this can include your actions. On the flipside, anonymity is supposed to keep your identity private, but not your actions.

This is a very, very, brief overview, but it’s a start. Check out this blog for a bit more information on these two terms. Or this one.

Good (best?) practices

It’s a bit unrewarding to say best practices which is why I purposefully added good to the title. Let’s review some:

• Don’t talk openly (about your ‘mission’ critical stuff) – Duh!
• Don’t operate from home – If you intend on doing anything that needs to keep that level of separation from your real persona. If you’re just trying to do normal stuff where that’s a non-issue, then you can adjust accordingly. (I am not trying to help you operate a botnet, also, those guys already know this stuff.)
• Encrypt everything – this is a great one, though, again, it might not be necessary in your case. You might want to encrypt and safely store only the most critical data. Also, this does require a fair bit of technical knowledge.
• Create personas – This is the anonymity part. If you really need to do something but it is not a great idea to do as ‘you,’ create another persona and be them. Great example of this are sock puppets, or something like OSINT CTFs I like to participate in.
• Don’t contaminate – This one ties to the previous one. If you have personas, don’t cross-contaminate them, as in this case they are actually working against you, and you’d be better off just using other controls to protect the real you. It can backfire. Significantly.
• Don’t trust – I mean… you’re on the Internet after all, adopt a healthy amount of paranoia if you haven’t already.
• Be paranoid – See the previous one. Even if nobody’s out to get you personally, that doesn’t mean that they’re not out to get you. That’s just the Internet for you.
• Don’t give people power over you – Just don’t. Don’t overshare, be careful. Anything you say can and will be used against you is very, very, true in this context as well.

Technical good (best?) practices

• Don’t be the only guy using TOR on a network that’s monitored. It’s how they caught this guy.
• Don’t do stuff on your own infrastructure that might get you in trouble
• VPN provides privacy! Not anonymity
• Isolate/segment your environment if there’s a need – I’m thinking VMWare, VirtualBox, etc.
• Check for DNS leaks
• If your use case is such, use Tails/Qubes OS/Whoonix
• Strong passwords! (And a password manager – I prefer KeePass, as it keeps the stuff locally and you can add more functionality through plugins, such as 2FA)
• Encrypt your disk, encrypt important stuff – where needed
• Protect yourself against WebRTC leaks
• Educate yourself on browser fingerprinting – there’s a lot of stuff online (as well as right here on Vsociety!) There’s this article, too.

Conclusion

I am hoping I’ve piqued your interest with all this OpSec talk. It might seem like an overkill to someone who’s maybe coming from a different field, but I assure you it is not! The Internet is a hostile place, and in a hostile environment you’d act accordingly, right? If you’re on vacation in, let’s say, a gorgeous but realistically dangerous place like some cities in Latin America, you would be careful. Do the same when online. Know where you’re threading, and act accordingly.

This is all for now! I hope I’ve made a decent introduction for some of the upcoming articles that will focus on the Darkweb, all the while bringing this fascinating topic closer to you. Stay tuned!

 

Some additional cool stuff to check out

https://www.youtube.com/watch?v=zXmZnU2GdVk

https://www.youtube.com/watch?v=8u7yyFYvzC4

https://www.youtube.com/watch?v=9XaYdCdwiWU

https://www.youtube.com/watch?v=eQ2OZKitRwc

Cover image by ueberform

#opsec #privacy #anonymity #best-practices #vicarius_blog