From 4c219e50af4437894cd9b89017711204c51e5c3b Mon Sep 17 00:00:00 2001
From: Ewout Wieten <ewout@ewy.one>
Date: Thu, 4 Apr 2024 19:12:50 +0200
Subject: make pre italic

---
 entry/escape/index.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'entry')

diff --git a/entry/escape/index.html b/entry/escape/index.html
index b8c1557..ce90b3a 100644
--- a/entry/escape/index.html
+++ b/entry/escape/index.html
@@ -11,7 +11,7 @@
     <meta content="#3E3B37" data-react-helmet="true" name="theme-color" />
 </head>
 <style>
-pre {
+code {
     display: inline;
     font-style: italic;
     margin: 0;
@@ -29,11 +29,11 @@ pre {
     </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:
+    As-is, the webshell runs as a regular user (<code>elastic</code>) without password. Unless you brute force the password, there is no way to gain superuser access. Thankfully, as members of the <code>docker</code> group, we can run containers with root privilege. Then, by running any container with a volume of <code>/etc/passwd</code>, you can remove the <code>x</code> between the :'s for the <code>root</code> user. This <code>x</code> is simply a placeholder that tells the system that the real password is stored and encrypted, usually in <code>/etc/shadow</code>. Now that the <code>x</code> is gone, the root user will be passwordless. That's codetty 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.
+    Since this container needs to run its own containers, it has access to the EC2 instance's docker socket, mounted in <code>/run/docker.sock</code>. This means that if we apply the steps from the codevious paragraph, we can gain root access on the machine in question. With the root access, you can insert your own public key in <code>/root/.ssh/authorized_keys</code> (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!
-- 
cgit v1.3