# Writeup

# Initial Recon:
Upon decrypting, the whereabouts of the challenge had to be figured out. Conveniently the file was dockerized, featuring an ngnix proxy and an docsnotebook repo, seemingly being written in emacs. As the "gold rush" for early first bloods demands, the codebase was mostly checked for hardcoded stuff, like the SSL Keys, in an attempt to get some cheesy quick solutions. Nothing really of worth was noted. Another thing of interest is to recognize early on where flags are stored and how the admin bot would use the application. The App has basic login/regi functionality, and a feature to export notes in the 'orgmode' lang.

# Emacs / Org
The webserver with its routes is written in emacs,... esoteric is almost an understatement. Given the "export" feature of the webapp, it was early on of interest what kind of features the org lang has. The [file inclusion](https://orgmode.org/manual/Include-Files.html) feature was examined first - just to notice very much later down the road how its being blocked in export.el. Trying to circumvent the removal of the include directive, one stumbled accross the `#+MACRO` feature, so an early idea was to read files via:
```
#+MARCO lol #+$1: "/etc/passwd" :line 1-
{{{lol(INCLUDE)}}}
```
which didnt work. Didnt quite debug into this, as time was pressing and the network was about to open. While checking the MARCO documentation it was noted how it could eval lisp code.

## The network opened
Now, it first of all was paramount to understand how the admin bot uses the application and how the flags are being stored. Basically a lowercase hexdigit username with variable length, creating notes to test and then the flags are stored just as a note which is not being exported, named flag, thus the resulting file is `flag.org` inside a pseudorandom directory within the `/srv/files` dir.

## Epxloitation
Having now some understanding where we want to go, the rest of the chall was basically figuring out how emacs/lisp works and how to get our RCE to work. since eval itself doesnt do any shell expansion and i didnt look into the code too hard to find an LFI to leak the filenames, bash -c with shell expansion does the trick and thus the first (naive) exploit was:

```
#+MACRO: lemao (eval (call-process "/bin/bash" nil t nil "-c" "cat /srv/files/*/flag.org"))
{{{lemao}}}
```

For to the author unknown reasons the output was still sorta distorted (beginning and end cutoff or included, like `emao}}}` being still there wereas one would thing the macro takes care of the substitution?), so some coding to fixup the mess was needed.

## Patch
As mentioned, the service already included a mitigation to not export scripts which include certain keywords. This allowed us to simply re-use that same code in the *export.el* and add more keywords to the blocklist and thus foil other teams attempts. The original mitigation was:
```
(while (search-forward "#+include:" nil t)
(delete-region (point-at-bol) (point-at-eol)))
```
Our patch just used that same code and blocked more words, such as `eval`, `call-process`, `insert-buffer`,... mainly just checking the traffic once exploited and manually adding another word to the list.

Lateron, some changes to the initial payload has been made to foil simple attempts, i.e change hardcoded strings, make more use of shell expansion or make use of different functoins than eval and call-process. Overall quite a rookie mistake to dump out the exploit in its initial form, but oh well, live and learn :)