Waiter, theres a compiler in my shellcode! Not so loud, or - - PowerPoint PPT Presentation

▶
waiter there s a compiler in my shellcode
SMART_READER_LITE
LIVE PREVIEW

Waiter, theres a compiler in my shellcode! Not so loud, or - - PowerPoint PPT Presentation

Dec 21, 2023 249 likes •749 views

Waiter, theres a compiler in my shellcode! Not so loud, or everybody will want one! Josh Stone NolaCon, 2019 Waiter by Adrien Coquet from the Noun Project Introduction: Josh Stone 30 years programmer 19 years infosec 15 years married

slide-1
SLIDE 1

Waiter, there’s a compiler in my shellcode!

Josh Stone NolaCon, 2019

Waiter by Adrien Coquet from the Noun Project

Not so loud, or everybody will want one!

slide-2
SLIDE 2

Introduction: Josh Stone

30 years programmer 19 years infosec 15 years married 14 years cancer survivor Parent of 3 kids BJJ blue belt CGA for life Yeah, older than I look

slide-3
SLIDE 3

Introduction: Josh Stone

Currently a researcher working for the R&D team at FusionX, part of Accenture Security. NOTE: this presentation covers EvilVM, which is a personal project not connected to my work at

  • Accenture. Opinions

expressed are mine, not my employer’s, etc.

slide-4
SLIDE 4

Premise: why EvilVM?

Most programming languages and development platforms are not designed for malicious software use cases.

screw by Arthur Shlain from the Noun Project Hammer by John Caserta from the Noun Project

slide-5
SLIDE 5

RCE: the central use case

Programming languages enable you to write programs to run

  • n your computer.
slide-6
SLIDE 6

RCE: the central use case

Programming languages enable you to write programs to run

  • n your computer.
slide-7
SLIDE 7

RCE: the central use case

Programming languages enable you to write programs to run

  • n your computer.

Hackers write programs to run

  • n someone else’s computer.
slide-8
SLIDE 8

RCE: the central use case

Your Computer Others’ computers Use resources Avoid notice Create files Leave no evidence Install dependencies Leave forest undisturbed Permission granted Fight defensive suites Use OS interfaces Subversive channels Restart whenever HA / resilient Static / unchanging Live updates during use Defined use case Use case changes often

slide-9
SLIDE 9

Design: small

Most friendly languages make large binaries, or require large runtimes

  • r dependencies.
slide-10
SLIDE 10

Design: flexible execution

slide-11
SLIDE 11

Design: remote IO

slide-12
SLIDE 12

Design: wide capabilities

slide-13
SLIDE 13

Design: dynamic code loading

Sword by Vertigophase from the Noun Project Zombie, Axe, Pickaxe by Lluisa Iborra from the Noun Project hacker by Kamaluddin from the Noun Project

Key Key Logg Logger er RA RAM Scraper Scraper DLL DLL Inject Injector

slide-14
SLIDE 14

Design: virtual machine

First thought, build a small injectable VM, compile and load code remotely. But concept morphed as I realized I could put the whole language in the agent. Didn’t want to name it Evil, though, so EvilVM it is, anyway.

Computer by Denis Shumaylov from the Noun Project

slide-15
SLIDE 15

EvilVM: intro

Server console for control / interaction. Multiple concurrent sessions Dynamic code loading REPL / direct Compiler interaction

slide-16
SLIDE 16

EvilVM: intro

Native code compiler for stack-based language:

slide-17
SLIDE 17

EvilVM: intro

Same environment, any IO layer: TCP Agent connects over socket HTTP Agent uses wininet for comms Streams Use STDIN/STDOUT streams Memory Read IO from memory Easy to add more. IO is a simple stream of bytes in and out; all code is protocol agnostic.

Tunnel Up by Alone forever from the Noun Project Zombie by Lluisa Iborra from the Noun Project hacker by Kamaluddin from the Noun Project

abcd... --> <-- ...dcba

slide-18
SLIDE 18

EvilVM: intro

EvilVM is small, about 5-10KB, depending on IO transport, trim level, and encapsulation methods:

slide-19
SLIDE 19

EvilVM: intro

EvilVM is a position independent shellcode, which can be packaged or encoded however you

  • like. It requires no dependencies other than

kernel32.dll.

slide-20
SLIDE 20

PLT: compilers are big

So how do we fit our programming language into a small payload, that runs fileless, and deploys flexibly?

slide-21
SLIDE 21

PLT: compilers are big

http://venge.net/graydon/talks/CompilerTalk-2019.pdf

GCC LLVM Clang V8 Swift Rust GHC Chez Scheme Turbo Pascal

500,000 1,000,000 1,500,000 2,000,000 2,500,000 2,200,000 1,200,000 800,000 660,000 530,000 360,000 180,000 87,000 14,000

Compiler Codebases

Lines of code

slide-22
SLIDE 22

PLT: compilers are big

  • R. G. Loeliger’s “Threaded Interpretive Languages“, 1981

https://tinyurl.com/y4j94d6z

Lightweight, memory constrained environments were de rigueur back in the day. The RCE use case bears remarkable similarity to the early days of hobbyist computing. I found inspiration in Forth, a programming language invented by Chuck Moore in 1970, and based on a unique code execution and compilation paradigm.

slide-23
SLIDE 23

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

slide-24
SLIDE 24

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

int main() { printf(“%d\n“, 3 + 4); }

slide-25
SLIDE 25

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

Main printf “%d\n“ + 3 4

slide-26
SLIDE 26

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

Main printf “%d\n“ + 3 4

slide-27
SLIDE 27

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

slide-28
SLIDE 28

PLT: compilers

Typical compiler: Lexing Parsing Transformation Code generation Linking

slide-29
SLIDE 29

PLT: stack based language

Forth compiler: Lexing Parsing Transformation Code generation Linking

Single-pass lexing amounts to splitting fields on whitespace

slide-30
SLIDE 30

PLT: stack based language

Forth compiler: Easy Lexing Parsing Transformation Code generation Linking

Traditional Forth compilers have no syntax tree or intermediate form.

slide-31
SLIDE 31

PLT: stack based language

Forth compiler: Easy Lexing Parsing Transformation Code generation Linking

No intermediate form means in- place transformation

  • f the program.
slide-32
SLIDE 32

PLT: stack based language

Forth compiler: Easy Lexing Parsing Transformation Code generation Linking

Code generation

  • ccurs linearly,

normally with

  • nly two cases:

constants and function calls.

slide-33
SLIDE 33

PLT: stack based language

Forth compiler: Easy Lexing Parsing Transformation Easy Code gen. Linking

Code is compiled at run-time, so there is usually no compatible analog for linked bodies of

  • bject code.
slide-34
SLIDE 34

PLT: stack based language

Forth compiler: Easy Lexing Parsing Transformation Easy Code gen. Linking

Forth compilers can be made VERY SMALL, and level of sophistication is up to the programmer.

slide-35
SLIDE 35

PLT: forth ecosystem

Forth has two stacks, the data stack for temporary storage, and the return stack for nested execution. Code is usually reverse polish notation, putting arguments before the function call. (2 + 3) * 5 2 3 + 5 * if(x and 1) ... x 1 and if ... quad(a, b, c) a b c quad Formally, functions do not technically take arguments, but all have the same type signature: stack fun(stack)

slide-36
SLIDE 36

PLT: forth ecosystem

Maps names to addresses in

  • memory. Almost all

variables, functions, etc., are definitions in the dictionary.

The Dictionary

slide-37
SLIDE 37

PLT: forth ecosystem

create a new dictionary entry while true: read a word from input if word in dictionary: if word is normal: compile a function call else: execute it else: if word is a number: compile a constant else: break

The ’:’ compiler

slide-38
SLIDE 38

PLT: linear compilation

The initial dictionary contains only what is needed by the compiler. The rest is added in the core API.

slide-39
SLIDE 39

PLT: linear compilation

if ... else ... then are just compiler extensions that add conditionals to the language:

slide-40
SLIDE 40

PLT: linear compilation

So are begin ... while ... repeat, structures, etc. It’s a PROGRAMMABLE COMPILER.

slide-41
SLIDE 41

Demo: configure / connect

slide-42
SLIDE 42

Demo: keylogger

... : testkeys 256 0 do i testkey loop ; : keylog begin key? until testkeys 8 ms repeat ;

slide-43
SLIDE 43

Demo: keylogger

... : dodown wasdown? if drop else dup keystate set report then ; : testkey dup isdown? if dodown else keystate unset then ; ...

slide-44
SLIDE 44

Demo: keylogger

slide-45
SLIDE 45

Demo: exploration

slide-46
SLIDE 46

Demo: abstraction

slide-47
SLIDE 47

Summary: project status

Still very ALPHA, with unstable API, and lots of changes. but, for the bold of heart: EvilVM is open source, under the MIT license and can be found at: http://evilvm.ninja/ https://github.com/jephthai/evilvm/

slide-48
SLIDE 48

Summary: project status

On the list for enhancement:

  • More resilience (maybe Erlang OTP-

Inspired model for HA / self-healing)

  • Higher-layer, user-friendly scripting

language, built on top of parsing library

  • More transport layers (ICMP, etc.)
  • LOTS of demonstration videos and

tours through the system

  • More documentation
slide-49
SLIDE 49

EOP: questions?

You can find me online: yakovdk gmail.com

  • Josh5tone
  • http://thestone.zone/

http://joshstone.us/ Special thanks to the Color Graphics Array for making this presentation possible.