CTF-pwn-tips - Here record some tips about pwn. Something is obso

项目说明

CTF-pwn-tips
===========================

Catalog

* O
* Find string in gdb
* Binary Service
* Find specific function offset in libc
* Find '/bin/sh' or 'sh' in library
* Leak stack address
* Fork problem in gdb
* Secret of a mysterious section - .tls
* Predictable RNG(Random Number Generator)
* Make stack executable
* Use one-gadget-RCE instead of system
* Hijack hook function
* Use printf to trigger malloc and free
* Use execveat to open a shell

O

Assume that: char buf[40] and signed int num

scanf

* scanf("%s", buf)
* %s doesn't ha check.
* pwnable

* scanf("%39s", buf)
* %39s only takes 39 bytes from the input and puts NULL byte at the end of input.
* useless

* scanf("%40s", buf)
* At first sight, it seems reasonable.(seems)
* It takes 40 bytes from input, but it also puts NULL byte at the end of input.
* Therefore, it has one-byte-o.
* pwnable

* scanf("%d", &num)
* Used with alloca(num)
* Since alloca allocates memory from the stack frame of the caller, there is an instruction sub esp, eax to achieve that.
* If we make num negative, it will ha stack frame.
* E.g. Seccon CTF quals 2016 cheer_msg
* Use num to access some data structures
* In most of the time, programs only check the higher bound and forget to make num unsigned.
* Making num negative may let us o some important data to control the world!

gets

* gets(buf)
* No boundary check.
* pwnable

* fgets(buf, 40, stdin)
* It takes only 39 bytes from the input and puts NULL byte at the end of input.
* useless

read

* read(stdin, buf, 40)
* It takes 40 bytes from the input, and it doesn't put NULL byte at the end of input.
* It seems safe, but it may have information leak.
* leakable

E.g.

memory layout

* If there is a printf or puts used to output the buf, it will keep outputting until reaching NULL byte.
* In this case, we can get 'A'*40 + '\xcd\xe1\xff\xff\xff\x7f'.

* fread(buf, 1, 40, stdin)
* Almost the same as read.
* leakable

strcpy

Assume that there is another buffer: char buf2[60]

* strcpy(buf, buf2)
* No boundary check.
* It copies the content of buf2(until reaching NULL byte) which may be longer than length(buf) to buf.
* Therefore, it may happen o.
* pwnable

* strncpy(buf, buf2, 40) && memcpy(buf, buf2, 40)
* It copies 40 bytes from buf2 to buf, but it won't put NULL byte at the end.
* Since there is no NULL byte to terminate, it may have information leak.
* leakable

strcat

Assume that there is another buffer: char buf2[60]

* strcat(buf, buf2)
* Of course, it may cause o if length(buf) isn't large enough.
* It puts NULL byte at the end, it may cause one-byte-o.
* In some cases, we can use this NULL byte to change stack address or heap address.
* pwnable

* strncat(buf, buf2, n)
* Almost the same as strcat, but with size limitation.
* pwnable
* E.g. Seccon CTF quals 2016 jmper

Find string in gdb

In the problem of SSP, we need to find out the offset between argv[0] and the input buffer.

gdb

* Use p/x ((char **)environ) in gdb, and the address of argv[0] will be the output - 0x10

E.g.

gdb peda

* Use searchmem "/home/naetw/CTF/seccon2016/check/checker"
* Then use searchmem $result_address

Binary Service

Normal:

* ncat -vc ./binary -kl 127.0.0.1 $port

With specific library in two ways:

* ncat -vc 'LD_PRELOAD=/path/to/libc.so ./binary' -kl 127.0.0.1 $port
* ncat -vc 'LD_LIBRARY_PATH=/path/of/libc.so ./binary' -kl 127.0.0.1 $port

After this, you can connect to binary service by command nc localhost $port.

Find specific function offset in libc

If we leaked libc address of certain function successfully, we could use get libc base address by subtracting the offset of that function.

Manually

* readelf -s $libc | grep ${function}@

E.g.

Automatically

* Use pwntools, then you can use it in your exploit script.

E.g.

Find '/bin/sh' or 'sh' in library

Need libc base address first

Manually

* objdump -s libc.so | less then search 'sh'
* strings -tx libc.so | grep /bin/sh

Automatically

* Use pwntools

E.g.

Leak stack address

constraints:

* Ha leaked libc base address
* Can leak the content of arbitrary address

There is a symbol environ in libc, whose value is the same as the third argument of main function, char **envp.
The value of char **envp is on the stack, thus we can leak stack address with this symbol.

* 0x7ffff7a0e000 is current libc base address
* 0x3c5f38 is offset of environ in libc

This manual explains details about environ.

Fork problem in gdb

When you use gdb to debug a binary with fork() function, you can use the following command to determine which process to follow (The default setting of original gdb is parent, while that of gdb-peda is child.):

* set follow-fork-mode parent
* set follow-fork-mode child

Alternatively, using set detach-on-fork off, we can then control both sides of each fork. Using inferior X where X is any of the numbers that show up for info inferiors will switch to that side of the fork. This is useful if both sides of the fork are necessary to attack a challenge, and the simple follow ones above aren't sufficient.

Secret of a mysterious section - .tls

constraints:

* Need malloc function and you can malloc with arbitrary size
* Arbitrary address leaking

We make malloc use mmap to allocate memory(size 0x21000 is enough). In general, these pages will be placed at the address just before .tls section.

There is some useful information on .tls, such as the address of main_arena, canary (value of stack guard), and a strange stack address which points to somewhere on the stack but with a fixed offset.

Before calling mmap:

After call mmap:

Predictable RNG(Random Number Generator)

When the binary uses the RNG to make the address of important information or sth, we can guess the same value if it's predictable.

Assuming that it's predictable, we can use ctypes which is a build-in module in Python.

ctypes allows calling a function in DLL(Dynamic-Link Library) or Shared Library.

Therefore, if binary has an init_proc like this:

Then we can use ctypes to get the same value of addr.

Make stack executable

* link1
* link2
* Haven't read yet orz

Use one-gadget-RCE instead of system

constraints:

* Have libc base address
* Write to arbitrary address

Almost every pwnable challenge needs to call system('/bin/sh') in the end of the exploit, but if we want to call that, we have to manipulate the parameters and, of course, hijack some functions to system. What if we can't manipulate the parameter?

Use one-gadget-RCE!

With one-gadget-RCE, we can just hijack .got.plt or something we can use to control eip to make program jump to one-gadget, but there are some constraints that need satisfying before using it.

There are lots of one-gadgets in libc. Each one has different constraints but those are similar. Each constraint is about the state of registers.

E.g.

* ebx is the address of rw-p area of libc
* [esp+0x34] == NULL

How can we get these constraints? Here is an useful tool one_gadget !!!!

So if we can satisfy those constraints, we can get the shell more easily.

Hijack hook function

constraints:

* Have libc base address
* Write to arbitrary address
* The program uses malloc, free or realloc.

By manual:

> The GNU C Library lets you modify the behavior of malloc, realloc, and free by specifying appropriate hook functions. You can use these hooks to help you debug programs that use dynamic memory allocation, for example.

There are hook declared in malloc.h and their default are 0x0.

* __malloc_hook
* __free_hook
* ...

Since they are used to help us debug programs, they are writable during the execution.

Let's look into the src of malloc.c. I will use __libc_free to demo.

It checks the value of __free_hook. If it's not NULL, it will call the hook function first. Here, we would like to use one-gadget-RCE. Since hook function is called in the libc, the constraints of one-gadget are usually satisfied.

Use printf to trigger malloc and free

Look into the source of printf, there are several places which may trigger malloc. Take .c line 1470 for example:

We can find that malloc will be triggered if the width field is large enough.(Of course, free will also be triggered at the end of printf if malloc has been triggered.) However, WORK_BUFFER_SIZE is not large enough, since we need to go to else block. Let's take a look at __libc_use_alloca and see what exactly the minimum size of width we should give.

We have to make sure that:

1. size > PTHREAD_STACK_MIN / 4
2. size > MIN(__MAX_ALLOCA_CUTOFF, THREAD_GETMEM(THREAD_SELF, stackblock_size) / 4 ?: __MAX_ALLOCA_CUTOFF * 4)
* I did not fully understand what exactly the function - THREAD_GETMEM do, but it seems that it mostly returns 0.
* Therefore, the second condition is usually size > 65536

More details:

* __builtin_expect
* THREAD_GETMEM

conclusion

* The minimum size of width to trigger malloc & free is 65537 most of the time.
* If there is a Format String and the program ends right after calling printf(buf), we can hijack __malloc_hook or __free_hook with one-gadget and use the trick mentioned above to trigger malloc & free then we can still get the shell e is no more function call or sth after printf(buf).

Use execveat to open a shell

When it comes to opening a shell with system call, execve always pops up in mind. However, it's not always easily a due to the lack of gadgets or others constraints.
Actually, there is a system call, execveat, with following prototype:

According to its man page, it operates in the same way as execve. As for the additional arguments, it mentions that:

> If pathname is absolute, then dirfd is ignored.

Hence, if we make pathname point to "/bin/sh", and set argv, envp and flags to 0, we can still get a shell whatever the value of dirfd.

项目信息

开发语言：未知

Star 数：1828

技术要点

该项目属于CTF思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Here record some tips about pwn. Something is obsoleted and won't be updated. Sorry about that.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。