diff options
| author | Ewout Wieten <ewout@ewy.one> | 2024-04-04 18:53:55 +0200 |
|---|---|---|
| committer | Ewout Wieten <ewout@ewy.one> | 2024-04-04 18:53:55 +0200 |
| commit | 2ad40b803f5c9ecba24c4225741eab523e37486d (patch) | |
| tree | 28fbc650c9b8e2691081d5c6708b7dc560ee2bfa /entry/escape | |
| parent | efb77902d34d02ae3a283173ec30f146d2c01814 (diff) | |
add escape entry
Diffstat (limited to 'entry/escape')
| -rw-r--r-- | entry/escape/index.html | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/entry/escape/index.html b/entry/escape/index.html new file mode 100644 index 0000000..3a8df91 --- /dev/null +++ b/entry/escape/index.html @@ -0,0 +1,38 @@ +<!DOCTYPE html> +<html lang="en"> +<head> + <title>Escaping the Strigo environment | ewy.one</title> + <meta charset="UTF-8"/> + <link rel="stylesheet" type="text/css" href="/reset.css"/> + <link rel="stylesheet" type="text/css" href="/terminal.css"/> + <meta content="Escaping the Strigo environment" property="og:title" /> + <meta content="Babies first exploit" property="og:description" /> + <meta content="https://blog.ewy.one/entry/escape" property="og:url" /> + <meta content="#3E3B37" data-react-helmet="true" name="theme-color" /> +</head> +<body> +<header> + <h1>Escaping the Strigo environment</h1> +</header> +<main> + <h2>Introduction</h2> + <p> + Recently I was blessed by my employer to attend an in-person training for <a href="https://elastic.co">Elastic</a>, who have partnered with <a href="https://strigo.io/">Strigo</a> to provide a cloud lab platform. During the training, we were expected to interact with several components of the Elastic stack: we have access to a shell and two Elastic stack instances which run containerized in the instance. Everything we need to gain permanent, unfeathered access to the AWS EC2 instance this is running on, has already been provided. + </p> + <h2>Becoming root</h2> + <p> + As-is, the webshell runs as a regular user (<pre>elastic</pre>) without password. Unless you brute force the password, there is no way to gain superuser access. Thankfully, as members of the <pre>docker</pre> group, we can run containers with root privilege. Then, by running any container with a volume of <pre>/etc/passwd</pre>, you can remove the <pre>x</pre> between the :'s for the <pre>root</pre> user. This <pre>x</pre> is simply a placeholder that tells the system that the real password is stored and encrypted, usually in <pre>/etc/shadow</pre>. Now that the <pre>x</pre> is gone, the root user will be passwordless. That's pretty cool: we gained root access in our containerized environment. But what happens next is such a disaster, that container root is an insignificant oversight: + </p> + <h2>Escaping the container</h2> + <p> + Since this container needs to run its own containers, it has access to the EC2 instance's docker socket, mounted in <pre>/run/docker.sock</pre>. This means that if we apply the steps from the previous paragraph, we can gain root access on the machine in question. With the root access, you can insert your own public key in <pre>/root/.ssh/authorized_keys</pre> (not necessary, but it's nice). Use any of the web-based services that return your IP and ssh into the server. + </p> + <p> + Congratulations! You just got a free server. Do as your heart desires - run minecraft, host files, borrow source code, or mine cryptocurrency. The sky is the limit! + </p> +</main> +<footer> + <a href="/"><< Return</a> +</footer> +</body> +</html> |