DDos Mafia | TechSNAP 303

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Ansible vulnerability

“Ansible is an open-source automation engine that automates cloud provisioning, configuration management, and application deployment. Once installed on a control node, Ansible, which is an agentless architecture, connects to a managed node through the default OpenSSH connection type.”
Similar tools are Puppet, Chef, SaltStack, cfEngine
Summary: Command execution on Ansible controller from host
Why is this important? First, if one of your ansible-controlled hosts is compromised, they can execute a command on your ansible controller.
So what you might ask? Your ansible controller accesses all your systems….
Computest notes: Not a full audit, might be other issues
Affected versions: < 2.1.4, < 2.2.1
A big threat to a configuration management system like Ansible, Puppet, SaltStack and others, is compromise of the central node. In Ansible terms this is called the Controller. If the Controller is compromised, an attacker has unfettered access to all hosts that are controlled by the Controller. As such, in any deployment, the central node receives extra attention in terms of security measures and isolation, and threats to this node are taken even more Seriously.
Fortunately for team blue (team blue is the defense team), in the case of Ansible the attack surface of the Controller is pretty small. Since Ansible is agent-less and based on push, the
Controller does not expose any services to hosts.
A very interesting bit of attack surface though is in the Facts. When Ansible runs on a host, a JSON object with Facts is returned to the Controller. The Controller uses these facts for various housekeeping purposes. Some facts have special meaning, like the fact “ansible_python_interpreter” and “ansible_connection”. The former defines the command to be run when Ansible is looking for the python interpreter, and the second determines the host Ansible is running against. If an attacker is able to control the first fact he can execute an arbitrary command, and if he is able to control the second fact he is able to execute on an arbitrary (Ansible-controlled) host. This can be set to “local” to execute on the Controller itself.
Because of this scenario, Ansible filters out certain facts when reading the facts that a host returns. However, we have found 6 ways to bypass this filter.
Bypass #1: Adding a host – Ansible allows modules to add hosts or update the inventory. This can be very useful, for instance when the inventory needs to be retrieved from a IaaS platform like as the AWS module does. If we’re lucky, we can guess the inventory_hostname, in which case the host_vars are overwritten and they will be in effect at the next task. If host_name doesn’t match inventory_hostname, it might get executed in the play for the next hostgroup, also depending on the limits set on the commandline.
Bypass #2: Conditionals – Ansible actions allow for conditionals. If we know the exact contents of a “when” clause, and we register it as a fact, a special case checks whether the
“when” clause matches a variable. In that case it replaces it with its
contents and evaluates them.
Bypass #3: Template injection in stat module – The template module/action merges its results with those of the stat module.This allows us to bypass the stripping of magic variables from ansible_facts, because they’re at an unexpected location in the result tree.
Bypass #4: Template injection by changing jinja syntax – Remote facts always get quoted. Set_fact unquotes them by evaluating them.
UnsafeProxy was designed to defend against unquoting by transforming jinja
syntax into jinja comments, effectively disabling injection.
Bypass #5: Template injection in dict keys – Strings and lists are properly cleaned up, but dictionary keys are not.
Bypass #6: Template injection using safe_eval – There’s a special case for evaluating strings that look like a list or dict. Strings that begin with “{” or “[” are evaluated by safe_eval [2]. This allows us to bypass the removal of jinja syntax: we use the whitelisted Python to re-create a bit of Jinja template that is interpreted.
Computest is not aware of mitigations short of installing fixed versions of the
software.
Ansible has released new versions that fix the vulnerabilities described in this advisory: version 2.1.4 for the 2.1 branch and 2.2.1 for the 2.2 branch.
The handling of Facts in Ansible suffers from too many special cases that allow for the bypassing of filtering. We found these issues in just hours of code review, which can be interpreted as a sign of very poor security. However, we don’t believe this is the case.
The attack surface of the Controller is very small, as it consists mainly of the Facts. We believe that it is very well possible to solve the filtering and quoting of Facts in a sound way, and that when this has been done, the opportunity for attack in this threat model is very small.
Furthermore, the Ansible security team has been understanding and professional in their communication around this issue, which is a good sign for the handling of future issues.

Who is Anna-Senpai, the Mirai Worm Author?

Way too long to go into full detail, so I will only outline a few interesting bits
+On September 22, 2016, this site was forced offline for nearly four days after it was hit with “Mirai,” a malware strain that enslaves poorly secured Internet of Things (IoT) devices like wireless routers and security cameras into a botnet for use in large cyberattacks. Roughly a week after that assault, the individual(s) who launched that attack — using the name “Anna-Senpai” — released the source code for Mirai, spawning dozens of copycat attack armies online.
After months of digging, KrebsOnSecurity is now confident to have uncovered Anna-Senpai’s real-life identity, and the identity of at least one co-conspirator who helped to write and modify the malware.
+Before we go further, a few disclosures are probably in order. First, this is easily the longest story I’ve ever written on this blog. It’s lengthy because I wanted to walk readers through my process of discovery, which has taken months to unravel. The details help in understanding the financial motivations behind Mirai and the botnet wars that preceded it. Also, I realize there are a great many names to keep track of as you read this post, so I’ve included a glossary.
The story you’re reading now is the result of hundreds of hours of research. At times, I was desperately seeking the missing link between seemingly unrelated people and events; sometimes I was inundated with huge amounts of information — much of it intentionally false or misleading — and left to search for kernels of truth hidden among the dross. If you’ve ever wondered why it seems that so few Internet criminals are brought to justice, I can tell you that the sheer amount of persistence and investigative resources required to piece together who’s done what to whom (and why) in the online era is tremendous.
As noted in previous KrebsOnSecurity articles, botnets like Mirai are used to knock individuals, businesses, governmental agencies, and non-profits offline on a daily basis. These so-called “distributed denial-of-service (DDoS) attacks are digital sieges in which an attacker causes thousands of hacked systems to hit a target with so much junk traffic that it falls over and remains unreachable by legitimate visitors. While DDoS attacks typically target a single Web site or Internet host, they often result in widespread collateral Internet disruption.
A great deal of DDoS activity on the Internet originates from so-called ‘booter/stresser’ services, which are essentially DDoS-for-hire services which allow even unsophisticated users to launch high-impact attacks. And as we will see, the incessant competition for profits in the blatantly illegal DDoS-for-hire industry can lead those involved down some very strange paths, indeed.
Talks about the variants of the IoT botnet, mentions Minecraft webservers were a frequent target.
Goes into a lot of detail of DDoS protection services, how Minecraft customers would come under attack, and how a competing DDoS protection company made threats directly preceding attacks
Discusses how the attacks where are way to boost business by not attacking your own customers, but by attacker customers of other DDoS proection services.
Boils down to the classic: nice business you have here, it’d be a shame if anything happened to it.

TechSNAP Career Challenge

I was at the [Grace Hopper Celebration(https://ghc.anitaborg.org/) of Women in Computing is the world’s largest gathering of women technologists. It is huge. I met people from many different technology areas (medicine, robotics, software design, someone who built a chip for the iPhone).
I was there on behalf of The FreeBSD Foundation to give a talk about how to contribute to open source.
Many were students and often were not sure of what part of technology they wanted to pursue.
I’ve seen many people go for years in their careers then suddenly discover a passion they previously didn’t know about and their life completely changes.
This point was mentioned to me by a Google Employee who gave me this list of steps which I then incorporated into my talk, then I wrote a blog post about it.
Seeing the eyes light up made me think we need to send this wider.
Allan Jude suggested I include this into the show
Here is what you do
Here is what I challeng our listeners to do:
Take this challenge
Blog about it
Then send us your blog URL and tell us what you got out of the challenge

Feedback:

Bareos/bacula for which I suggest my jail snapshot script
Malware in the browser

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Ansible vulnerability

Who is Anna-Senpai, the Mirai Worm Author?

TechSNAP Career Challenge

Feedback:

Round Up: