add angelshark post, add tarpit draft

1 files changed, 192 insertions, 0 deletions

diff --git a/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php b/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php
new file mode 100644
index 0000000..26824da
--- /dev/null
+++ b/drafts/2021-10-06-write-your-own-ssh-tarpit-in-rust-with-async-std.php
@@ -0,0 +1,192 @@
+<?php
+$title = "Write Your Own SSH Tarpit in Rust with async-std";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+<p class="description">
+	A software tarpit is simple and fun. Long story short, it's sort of a reverse denial-of-service attack. It usually works by inserting an intentional, arbitrary delay in responding to malicious clients, thus wasting their time and resources. It's kind of like those YouTubers who purposely joke around with phone scammers as long as possible to waste their time and have fun. I recently learned about <a href="https://github.com/skeeto/endlessh"><code>endlessh</code></a>, an SSH tarpit. I decided it would be a fun exercise to use Rust's <code>async-std</code> library to write an SSH tarpit of my own, with my own personal <em>flair</em>. If you want to learn more about <code>endlessh</code> or SSH tarpits I highly recommend reading <a href="https://nullprogram.com/blog/2019/03/22/">this blog post</a> by the <code>endlessh</code> author.
+</p>
+
+<h2>Goals</h2>
+
+<p>
+	So what does an SSH tarpit need to do? Basically, an SSH tarpit is a TCP listener that very slowly writes a never-ending SSH banner back to the client. This all happens pre-login, so no fancy SSH libraries are needed. Really, the program just needs to write bytes [slowly] back to the incoming connection and never offer up the chance to authenticate (see the blog post above to learn more). So now I'm getting a to-do list together. My program needs to...
+</p>
+
+<ol>
+	<li>Listen for incoming TCP connections on a given port</li>
+	<li>Upon receiving an incoming connection, write some data to the TCP stream</li>
+	<li>Wait a little bit (say 1-10 seconds) and then repeat step 2</li>
+	<li>Upon client disconnect, continue working on other connections and listening for new ones</li>
+	<li>Handle many of these connections at the same time with few resources</li>
+</ol>
+
+<p>
+	Additionally, to spruce things up and have more fun, I'm adding the following requirements:
+</p>
+
+<ul>
+	<li>The listening port should be user-configurable (to make debugging easier)</li>
+	<li>Client connection and disconnection events are logged, so I can see who is stuck in the pit and when</li>
+	<li><em>The data written back to the client should be user-configurable</em></li>
+	<li>The data is written one word at a time</li>
+</ul>
+
+<p>
+	That's right. It's probably a waste of resources, but I want to be able to feed the attacker whatever information I want. For example, I want to be able to pipe a Unix Fortune across the network to the attacker very slowly. I want to relish in the knowledge that if the attacker manually debugs the data coming down the pipe, they'll see their fortune.
+</p>
+
+<h2>Implementation</h2>
+
+<p>
+	I've chosen Rust and the recently-stabilized <a href="https://async.rs/"><code>async-std</code></a> library for a variety of reasons. First, I like Rust. It's a good language. Second, <code>async-std</code> offers an asynchronous task-switching runtime much like Python's <code>asyncio</code>, or even JavaScript's <code>Promise</code> (even though things work a little differently under the hood). Long story short, it allows for easy concurrent programming with few resources and high performance. Everything I could want, really. It also comes with a variety of useful standard library API features reimplemented as asynchronous tasks.
+</p>
+
+<p>
+	For starters, I need to include <code>async-std</code> as a dependency. I'm also going to pull in <a href="https://docs.rs/anyhow/1.0.44/anyhow/"><code>anyhow</code></a> for friendlier error handling.
+</p>
+
+<p>
+	<a href="https://git.53hor.net/53hornet/fortune-pit/src/commit/4fa2c2a100dba6b264cc232963f6d797ffb671cf/Cargo.toml">Cargo.toml:</a>
+<pre>
+<code>
+[package]
+name = "fortune-pit"
+version = "0.1.0"
+edition = "2018"
+
+[dependencies.async-std]
+version = "1"
+features = ["attributes"]
+
+[dependencies.anyhow]
+version = "1"
+</code>
+</pre>
+</p>
+
+<p>
+	Now I've gotta actually write some code. I already said I wanted to listen for incoming TCP connections, so I'll start with a <code>TcpListener</code>.
+
+<pre>
+<code>
+use anyhow::Result;
+use async_std::net::TcpListener;
+
+#[async_std::main]
+async fn main() -> Result<()> {
+    let listener = TcpListener::bind("0.0.0.0:2222").await?;
+    Ok(())
+}
+</code>
+</pre>
+
+Better yet, I'll make the bind port configurable at runtime. In a live environment, it would be best to run this on port 22. But for testing purposes, as a non-root user, I'll run it on 2222. These changes will let me do that at will. I'll also print a nicer error message if anything goes wrong here.
+</p>
+
+<p>
+<pre>
+<code>
+use anyhow::{Context, Result};
+use async_std::net::{Ipv4Addr, SocketAddrV4, TcpListener};
+use std::env;
+
+#[async_std::main]
+async fn main() -> Result<()> {
+    let listener = TcpListener::bind(read_addr()?)
+        .await
+        .with_context(|| "tarpit: failed to bind TCP listener")?;
+    Ok(())
+}
+
+fn read_addr() -> Result<SocketAddrV4> {
+    let port = env::args()
+        .nth(1)
+        .map(|arg| arg.parse())
+        .unwrap_or(Ok(22))
+        .with_context(|| "tarpit: failed to parse bind port")?;
+
+    Ok(SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), port))
+}
+</code>
+</pre>
+
+There. Slightly more complicated, but much more convenient.
+</p>
+
+<p>
+	Now I need to actually do something with my <code>TcpListener</code>. I'll loop over incoming connections and open streams for all of them. Then I'll write something to those streams and close them.
+
+<pre>
+<code>
+use anyhow::{Context, Result};
+use async_std::{
+    io::prelude::*,
+    net::{Ipv4Addr, SocketAddrV4, TcpListener},
+    prelude::*,
+};
+use std::env;
+
+#[async_std::main]
+async fn main() -> Result<()> {
+    let listener = TcpListener::bind(read_addr()?)
+        .await
+        .with_context(|| "tarpit: failed to bind TCP listener")?;
+
+    let mut incoming = listener.incoming();
+    while let Some(stream) = incoming.next().await {
+        let mut stream = stream?;
+        writeln!(stream, "Here's your fortune!").await?;
+    }
+
+    Ok(())
+}
+
+fn read_addr() -> Result<SocketAddrV4> {
+    let port = env::args()
+        .nth(1)
+        .map(|arg| arg.parse())
+        .unwrap_or(Ok(22))
+        .with_context(|| "tarpit: failed to parse bind port")?;
+
+    Ok(SocketAddrV4::new(Ipv4Addr::new(0, 0, 0, 0), port))
+}
+</code>
+</pre>
+
+And it works! If I <code>cargo run -- 2222</code>, passing my port as the first argument, I get a very basic TCP server. I can test it with <code>nc(1)</code>.
+
+<pre>
+<code>
+$ nc localhost 2222
+Here's your fortune!
+^C
+</code>
+</pre>
+</p>
+
+<p>
+	Great. But not there yet. First of all, my client immediately receives a response. I want to keep feeding information to the client over and over until it gives up. I don't want it to time out waiting for nothing. I also want the user to pick what gets written.
+</p>
+
+<p>
+	So let's read in whatever the user wants to send along on STDIN. I thought this would be better than reading a file because it's really easy to send files to STDIN with pipes or redirection. It also lets you write the output of commands like <code>fortune(6)</code>.
+
+<pre>
+<code>
+</code>
+</pre>
+</p>
+
+<h2>Improvements</h2>
+
+<p>
+	The SSH RFC specifies that lines written for the banner cannot exceed 255 characters including carriage return and line feed. This program imposes no such restriction, although it would probably be fairly easy to break up incoming text into 255 character lines and write those one word at a time.
+</p>
+
+<p>
+	It's probably also worth noting that should any lines begin with <code>SSH-</code>, they're interpreted as SSH protocol version identifiers, causing the client and server to begin their authentication dance. Normally, unless the following data is valid, this results in a disconnect. In a worst-case scenario, if you pipe a completely legitimate protocol version, the client will successfully attempt authentication.
+</p>