How do we connect to SSL sites? Here we need something that can understand
SSL – a proxy that will "convert" my normal HTTP into HTTPS. SSL proxy is
just such a program - it's available for FreeBSD and Linux as a package and
RPM respectively. Let us see how we would run whisker against a SSL site
https://xxx.co.za. The procedure looks like this - we will discuss it step
by step afterwards:
# host xxx.co.za
xxx.co.za has address 168.xxx.240.30
/# ssl proxy
No remote address given
usage: ssl proxy [-L <local address>] [-l <local port>]
[-R <remote address>] [-r <remote port>] [-s] [-n] [-c <certfile>]
[-k <keyfile>] [-v <verify file>] [-V <verify dir>] [-C] [-P]
sslproxy -h prints short help
valid options are:
-L <local address> IP address where proxy will bind (default=0.0.0.0)
-l <local port> port number where proxy will bind
-R <remote address> IP address or host name the proxy will connect to
-r <remote port> port number the proxy will connect to
-s run as server proxy, not client proxy
-n do automatic SSL negotiation for net bios
-p <protocol> protocol to use, may be: ssl23 (default), ssl2, ssl3, tls1
-c <certfile> use the given certificate in PEM format
-k <keyfile> use the given key in PEM format (may be contained in cert)
-v <verify file> file containing the CA's certificate
-V <verify dir> directory containing CA certificates in hashed format
-C use SSL compatibility mode
-P require valid peer certificate
/# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem >&
/dev/null
/# perl whisker.pl -h 127.0.0.1 -p 7117
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: 127.0.0.1
= Server: Microsoft-IIS/4.0
---cut----
The first step is to find the IP number of the host. Next we set up the
SSLproxylistening on port 7117 and going to the server on port 443 (SSL).
The proxy will verify the server certificate with the CA certificate
Class3.pem that was exported from a browser and looks like this (I add it
here so save you some time):
-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQDknv3zOugOz6URPhmkJAIyMA0GCSqGSIb3DQEBAgUAMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xh
c3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05
NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMyBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAyVxZnvIbigEUtBDfBEDb41evakVAj4QMC9Ez2dkRz+4CWB8l9yqo RAWq7AMfeH+ek7maAKojfdashaJjRcdyJ8z0TMZ1cdI5709C8HXfCpDGjiBvmA/4
rCNfcCk2pMmG57GaIMtTpYXnPb59mv4kRTPcdhXtD6JxZExlLoFoRacCAwEAATAN
BgkqhkiG9w0BAQIFAAOBgQBhcOwvP579K+ZoVCGwZ3kIDCCWMYoNer62Jt95LCJp
STbjl3diYaIy13pUITa6Ask05yXaRDWw0lyAXbOU+Pms7qRgdSoflUkjsUp89LNH
ciFbfperVKxi513srpvSybIk+4Kt6WcVS7qqpvCXoPawl1cAyAw8CaCCBLpB2veZ
pA==
-----END CERTIFICATE-----
The final step is to get whisker to scan local host on port 7117. The proxy
listens on port 7117 and "converts" the HTTP request to SSL on the target
machine. Notice that we append a >& /dev/null & to the proxy command to
ensure that we can easily read the output. Testing the proxy can be done by
just firing up the proxy and connecting with a browser to
http://127.0.0.1:7117.
Let us assume that we have found a vulnerability on the host and we want to
use it. We would then simply edit the exploit to point to port 7117 and
execute the exploit against 127.0.0.1 (we will look at this in more detail
later). Why not bind the proxy to port 80? The reason I have it on port 7117
is because I don't want to stop and start my web server every now and again -
if you are not running a web server you should not have a problem binding to
port 80. The other reason might be that you do not have root rights on the
host - an ordinary user can execute programs that bind to port above 1024.
SSL – a proxy that will "convert" my normal HTTP into HTTPS. SSL proxy is
just such a program - it's available for FreeBSD and Linux as a package and
RPM respectively. Let us see how we would run whisker against a SSL site
https://xxx.co.za. The procedure looks like this - we will discuss it step
by step afterwards:
# host xxx.co.za
xxx.co.za has address 168.xxx.240.30
/# ssl proxy
No remote address given
usage: ssl proxy [-L <local address>] [-l <local port>]
[-R <remote address>] [-r <remote port>] [-s] [-n] [-c <certfile>]
[-k <keyfile>] [-v <verify file>] [-V <verify dir>] [-C] [-P]
sslproxy -h prints short help
valid options are:
-L <local address> IP address where proxy will bind (default=0.0.0.0)
-l <local port> port number where proxy will bind
-R <remote address> IP address or host name the proxy will connect to
-r <remote port> port number the proxy will connect to
-s run as server proxy, not client proxy
-n do automatic SSL negotiation for net bios
-p <protocol> protocol to use, may be: ssl23 (default), ssl2, ssl3, tls1
-c <certfile> use the given certificate in PEM format
-k <keyfile> use the given key in PEM format (may be contained in cert)
-v <verify file> file containing the CA's certificate
-V <verify dir> directory containing CA certificates in hashed format
-C use SSL compatibility mode
-P require valid peer certificate
/# sslproxy -L 127.0.0.1 -l 7117 -R 168.xxx.240.30 -r 443 -v Class3.pem >&
/dev/null
/# perl whisker.pl -h 127.0.0.1 -p 7117
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: 127.0.0.1
= Server: Microsoft-IIS/4.0
---cut----
The first step is to find the IP number of the host. Next we set up the
SSLproxylistening on port 7117 and going to the server on port 443 (SSL).
The proxy will verify the server certificate with the CA certificate
Class3.pem that was exported from a browser and looks like this (I add it
here so save you some time):
-----BEGIN CERTIFICATE-----
MIICPTCCAaYCEQDknv3zOugOz6URPhmkJAIyMA0GCSqGSIb3DQEBAgUAMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xh
c3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05
NjAxMjkwMDAwMDBaFw0wNDAxMDcyMzU5NTlaMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMyBQdWJsaWMgUHJp
bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAyVxZnvIbigEUtBDfBEDb41evakVAj4QMC9Ez2dkRz+4CWB8l9yqo RAWq7AMfeH+ek7maAKojfdashaJjRcdyJ8z0TMZ1cdI5709C8HXfCpDGjiBvmA/4
rCNfcCk2pMmG57GaIMtTpYXnPb59mv4kRTPcdhXtD6JxZExlLoFoRacCAwEAATAN
BgkqhkiG9w0BAQIFAAOBgQBhcOwvP579K+ZoVCGwZ3kIDCCWMYoNer62Jt95LCJp
STbjl3diYaIy13pUITa6Ask05yXaRDWw0lyAXbOU+Pms7qRgdSoflUkjsUp89LNH
ciFbfperVKxi513srpvSybIk+4Kt6WcVS7qqpvCXoPawl1cAyAw8CaCCBLpB2veZ
pA==
-----END CERTIFICATE-----
The final step is to get whisker to scan local host on port 7117. The proxy
listens on port 7117 and "converts" the HTTP request to SSL on the target
machine. Notice that we append a >& /dev/null & to the proxy command to
ensure that we can easily read the output. Testing the proxy can be done by
just firing up the proxy and connecting with a browser to
http://127.0.0.1:7117.
Let us assume that we have found a vulnerability on the host and we want to
use it. We would then simply edit the exploit to point to port 7117 and
execute the exploit against 127.0.0.1 (we will look at this in more detail
later). Why not bind the proxy to port 80? The reason I have it on port 7117
is because I don't want to stop and start my web server every now and again -
if you are not running a web server you should not have a problem binding to
port 80. The other reason might be that you do not have root rights on the
host - an ordinary user can execute programs that bind to port above 1024.
No comments:
Post a Comment