enowars5-service-stldoctor

slides.md (5069B)

title: STLDoctor
output: index.html
controls: false

--

<style>

.footnote {
	font-size: 16pt;
	position: absolute;
	color: gray;
	bottom: 0px;
	right: 0px;
}

.slide-content {
	position: relative;
}

.slide-content > ul >li {
	padding: 7px 0px;
}

.slide-content > p > img {
	width: 100%;
}

</style>

--

<!-- Recap of the service and the problems I
encountered preparing for the CTF and during the CTF -->

# STLDoctor 💉

--

### Index 🗄️

- Service recap
- Optimization
- ENOWARS 5
- Reflection

--

### Refreshing Memories 💾

- Plaintext service written in C
- Users upload STL files for parsing
- Private and public storage (2 flagstores)
- 1. Vuln: Deserialization
- 2. Vuln: Hash preimage

<img style="width:300px !important; height:240px; position:absolute; bottom:80px; right:70px;" src="media/stldoc.png">

--

### Since Last Meeting ⏩

<!-- Of these three, we want to take a closer look
at the performance improvements necessary -->

- Performance improvements
- Added service fluff

<img id=img1 src="media/stl1.png">
<img id=img2 src="media/stl2.png">
<img id=img3 src="media/stl3.png">

<style>
	#img1 {
		position: absolute;
		left: 2.5%;
		bottom: 7%;
		width: 30%;
	}
	#img2 {
		position: absolute;
		left: 35%;
		bottom: 7%;
		width: 30%;
	}
	#img3 {
		position: absolute;
		left: 67.5%;
		bottom: 7%;
		width: 30%;
	}
</style>

--

### Issues 😒

<!-- since there were some slow io operations and
either memory leak issues with pwnlib (witout patch)
or engine request issues with the patch,
sooo I decided to refactor to use enochecker3 for asyncio

also noticed that I was checking the same thing multiple times
in the checker, so tried to condense functionality -->

- Slow search / list operations
- Enochecker memory leak without patch
- Engine error on worker restart with patch
- Logs not showing up in ELK

--

### Solutions 💡

- Index files with locks for directory listing
- Refactored checker for asyncio
- Condensed checker functionality
- Increase docker-compose log size

--

# ENOWARS 5

--

### OSError 💢

- Checker throws `INTERNAL_ERROR` on bad connection
- Fixed in c97789ad.. of enochecker3

<img style="" src="media/stldoc_dead_offline.png">

--

### Checker Overload 💥

<!-- all of a sudden all checker tasks are being aborted.
Since all tasks were aborted, all workers must be affected
and a blockage of a single worker could not have been the
cause.. 
During the ctf we found the checker at high load..
Suspected that OFFLINE/unresponsive teams could be slowing
down the service since then the timeouts are too large and the
queue couldnt be emptied fast enough -->

- Checker tasks being aborted for every team

<img style="height: 80%" src="media/stldoc_dead_r432.png">

--

### Checker Overload 💥

<!-- MEME CREDIT: Liikt -->
<img style="height: 80%" src="media/stldoc_dead.png">

--

### Anomaly 👽

<!-- service didnt timeout except on vulnboxes where everything
seemed to be running weirdly, so unsure how to debug -->

<img style="" src="media/enowars5-timeout.png">

--

### Feedback 🤔

- 1. flagstore exploited after ~4h (R190)
- 2. flagstore not exploited

<!-- MEME CREDIT: [KuK] cluosh -->
<img style="position:absolute; right:0px; height:300px; width:450px" src="media/player-meme-struggling.png">
<img style="position:absolute; left:0px; height:300px; width: 400px;" src="media/player-meme-hashfunc.png">

--

### Conclusion 🎉

- Relatively good uptime
- Not too easy / hard
- Users found vulns interesting
- No (known) unintended vuln
- Had a lot of fun

--

--

### Slow IO 🐌

<!-- Noticed that running 'ls' on the service upload directory
takes very long
implementation in e.g. glibc actually pretty sane (see end slides)
but bad cache performance / buffer not used / docker overlay fs -->

- Enumerating files in a directory is expensive
- Index file per directory containing file names
- File locks to ensure exclusive writes

<img style="position:absolute; bottom: 30%; left:10%; width: 70% !important;" src="media/dirlist.png">

--

### Investigating `readdir(..)` 🔍

<!-- What makes readdir slow? actually looks like a sane implementation.
We buffer an amount of entries and rebuffer when we run out.
My guess is that we can buffer more with a regular file (also we have the choice).
Better cache performance?
Although the read is from one location, is probably just an abstraction
Source: GLIBC 2.0.2-->

`__readdir(..)`:

<img style="" src="media/readdir.png">

--

### Investigating `readdir(..)` 🔍

`__get_dir_entries(..)`:

<img style="" src="media/getdirentries.png">

--

### Checker Overload

<img style="" src="media/stldoc_dead_r17.png">

--

### Checker Overload

<img style="" src="media/stldoc_dead_r469.png">

--





<script>
	// var slide_headers = document.querySelectorAll(".slide-content > h3");
	// for (var i = 0; i < slide_headers.length; i++) {
	// 	var img = document.createElement('img')
	// 	img.src = "logo.png";
	// 	img.style = "height: 2.4ex; padding-right: 10px; float:right";
	// 	slide_headers[i].append(img);
	// }
</script>