Sep 2, 2011

Attackers behind CA hack also targeted Tor

The development team behind anonymisation network Tor is reporting that twelve certificates for the domain * were generated during the attack on Dutch SSL certification authority DigiNotar. Six certificates for the project's domain were illegally issued on July 18 and six more on 20 July – despite the fact the DigiNotar detected the intrusion on 19 July and claims to have revoked all of the fraudulent certificates.
The Tor developers say that the security of its anonymisation network has not been directly compromised by the fake certificates; however, an attacker could have used the certificates to modify the Tor web site and deliver a modified version of the Tor client to users. The Tor team bemoans DigiNotar's failure to actively inform them of the incident and that they had to call the CA to obtain a list of serial numbers for the fraudulent certificates. DigiNotar told the Tor team that they had long revoked the certificates involved.
There is, however, no sign that this has actually happened – the Tor team has failed to find any indication that the serial numbers in question have been revoked in the public certificate revocation list (CRL). Interestingly, the certificates as issued were only valid for one month and expired on August 19. The Tor developers suspect that this may be why DigiNotar deemed it unnecessary to add the certificates to the CRL.
According to a reportDutch Language on Dutch web site, other prominent victims included blog hosting site WordPress, Yahoo, the Mozilla Firefox Addon directory and Iranian blog portal Baladin. The attack does not appear to have been motivated by financial gain – the report states that no certificates were issued for financial institutions.
At least one certificate was incorrectly issued for and used to eavesdrop on Iranian Google users – indeed this is how the incident was first detected. Since version 13, Google Chrome includes a list of trusted CAs which might conceivably issue certificates for Google domains. Where the CA is not on this list, as in the current case, Chrome displays a warning. The Google certificate was issued on July 10, and was, according to DigiNotar, "overlooked" when cleaning up the mess following the intrusion.
The total number of certificates issued is a matter of speculation. One clue is a change in the Chrome source code, which blacklists serial numbers from 247 DigiNotar certificates. It also remains unclear whether, following its slip-up with the Google certificate, all fraudulent certificates really have been revoked. The Internet Storm Center reports that the number of revoked DigiNotar certificates was significantly lower during July and August than in previous months. Google has been joined by Mozilla and Microsoft in distrusting the CA as a whole.

If you like my blog, Please Donate Me

Aug 31, 2011

SSH Cheat Sheet From PentestMonkey

SSH has several features that are useful during pentesting and auditing.  This page aims to remind us of the syntax for the most useful features.
NB: This page does not attempt to replace the man page for pentesters, only to supplement it with some pertinent examples.


Set up a SOCKS proxy on that lets you pivot through the remote host (
Command line:

ssh -D

You can then use tsocks or similar to use non-SOCKS-aware tools on hosts accessible from

tsocks rdesktop

Local Forwarding

Make services on the remote network accessible to your host via a local listener.
NB: Remember that you need to be root to bind to TCP port <1024.  Higher ports are used in the examples below.

Example 1

The service running on the remote host on TCP port 1521 is accessible by connecting to 10521 on the SSH client system.
Command line:

ssh -L user@


Example 2

Same thing, but other hosts on the same network as the SSH client can also connect to the remote service (can be insecure).
Command line:

ssh -L


Example 3

In this example, is a host that’s accessible from the SSH server.  We can access the service it’s running on TCP port 1521 by connecting to 10521 on the SSH client.
Command line:

ssh -L


Remote Forwarding

Make services on your local system / local network accessible to the remote host via a remote listener.  This sounds like an odd thing to want to do, but perhaps you want to expose a services that lets you download your tools.
NB: Remember that you need to be root to bind to TCP port <1024.  Higher ports are used in the examples below.

Example 1

The SSH server will be able to access TCP port 80 on the SSH client by connecting to on the SSH server.
Command line:

ssh -R


Example 2

The SSH server will be able to access TCP port 80 on (a host accessible from the SSH client) by connecting to on the SSH server.
Command line:

ssh -R


Example 3

The SSH server will be able to access TCP port 80 on (a host accessible from the SSH client) by connecting to TCP port 8000 on the SSH server.  Any other hosts able to connect to TCP port 8000 on the SSH server will also be able to access  This can sometimes be insecure.
Command line:

ssh -R


Configuration Files


It’s sometimes easier to configure options on your SSH client system in ~/.ssh/config for hosts you use a lot rather than having to type out long command lines.
Using ~/.ssh/config also makes it easier to use other tools that use SSH (e.g. scp and rsync).  It’s possible to tell other tools that SSH listens on a different port, but it’s a pain.

Port 2222
User ptm
ForwardX11 yes
RemoteForward 80
LocalForward 1521
The above lines are explained more fully in the other subsection on this page.


During a pentest or audit, you might want to add an authorized_keys file to let you log in using an SSH key.
The authorized_keys file lives in a user’s home directory on the SSH server.  It holds the public keys of the users allowed to log into that user’s account.
Generate a public/private key pair like this:

ssh-keygen -f mykey
cat # you can copy this to authorized_keys
If you want to shortest possible key (because your arbitrary-file-write vector is limited), do this:

ssh-keygen -f mykey -t rsa -b 768
cat # copy to authorized_key.  Omit the trailing user@host if you need a shorter key.
Connect to the target system like this (you need to know the username of the user you added an authorized key for):

ssh -i mykey user@

X11 Forwarding

If your SSH client is also an X-Server then you can launch X-clients (e.g. Firefox) inside your SSH session and display them on your X-Server.  This works well with from Linux X-Servers and from cygwin‘s X-server on Windows.

Command Line:

SSH -Y # less secure alternative - but faster


ForwardX11 yes
ForwardX11Trusted yes # less secure alternative - but faster

SSH Agents

SSH agents can be used to hold your private SSH keys in memory.  The agent will then authenticate you to any hosts that trust your SSH key.
This has the following advantages:

  • You don’t have to keep entering your passphrase (if you chose to encrypt your private key)
  • But you still get to store your private SSH key in an encrypted format on disk.
Using an SSH agent is probably more secure than storing your key in cleartext, but agents can be hijacked.

Using an SSH Agent

First start your agent:

eval `ssh-agent`
Then add your keys to it – you’ll need to enter your passphrase for any encrypted keys:

ssh-add ~/dir/mykey

Hijacking SSH Agents

If you see SSH agents running on a pentest (process called “ssh-agent”), you might be able to use it to authenticate you to other hosts – or other accounts on that host.  Check out ~/.ssh/known_hosts for some ideas of where you might be able to connect to.
You can use any agents running under the account you compromised.  If you’re root you can use any SSH agent.
SSH agents listen on a unix socket.  You need to figure where this is for each agent (e.g. /tmp/ssh-tqiEl28473/agent.28473). You can then use the agent like this:

export  SSH_AUTH_SOCK=/tmp/ssh-tqiEl28473/agent.28473
ssh-add -l # lists the keys loaded into the agent
ssh user@host # will authenticate you if server trusts key in agent
This command illustrates how you could inspect the environment of every ssh-agent process on a Linux system.  It should yield a list of unix sockets for SSH agents.

ps auxeww | grep ssh-agent | grep SSH_AUTH_SOCK | sed 's/.*SSH_AUTH_SOCK=//' | cut -f 1 -d ' '

Agent Forwarding

If you enable SSH agent forwarding then you’ll be able to carry on using the SSH agent on your SSH client during your session on the SSH server.  This is potentially insecure because so will anyone else who is root on the SSH server you’re connected to.  Avoid using this feature with any keys you care about


If you like my blog, Please Donate Me

AnDOSid the DOS tool for Android

A new product released by SCOTT HERBERT for Android mobile phones,Its AnDOSid - the DOS tool for Android Phones. The rise of groups like Anonymous and LuzSec, as well as constant India / Pakistan cyberwar has raised the issue of cyber-security high(er) in the minds of web owners.

Pentesting tools exist to simulate such attacks and help website security people defend against them, however for the most part they currently only exist for desktop computers. Mobile phones have, over the last few years, grown from simple devices that send and receive calls to mobile computing platforms which can be purchased for less than $100 a device.

AnDOSid fills that gap, allowing security professionals to simulate a DOS attack (An http post flood attack to be exact) and of course a dDOS on a web server, from mobile phones. AnDOSid is actively being developed and I welcome feedback from the security community as to how you would like the application to evolve.

What's in this version:

  • Requires Internet access to send the http post data
  • Requires phone state to access the IMEI (one of the two identifiers sent with each post)

AnDOSid can be downloaded from the
Android Market place and costs just £1 or Rs.74.58/-Only.


If you like my blog, Please Donate Me

Aug 30, 2011

Falsely issued Google SSL certificate in the wild for more than 5 weeks

Reports surfaced this morning that accuse the government of Iran with trying to perform a man-in-the-middle attack against Google's SSL services.
A user named alibo on the Gmail forums posted a thread about receiving a certificate warning about a revoked SSL certificate for SSL-based Google services.
The certificate in question was issued on July 10th by Dutch SSL certificate authority DigiNotar. DigiNotar revoked the certificate today at 16:59:03 GMT, but many browsers do not check for revoked certificates by default.
The certificate was valid for * and raises serious questions about who the certificate was issued to, and how it was signed.
Was DigiNotar compromised? Were the perpetrators able to acquire the CA's certificate and sign their own bogus certificate? Or was DigiNotar tricked into signing the certificate for someone pretending to be Google?
The answer to that question is nearly irrelevant as it is simply more evidence that the current CA infrastructure that we have decided to "trust" is totally untrustworthy. It doesn't matter how this happened, it has happened before and unfortunately will happen again.
I recently wrote about Moxie Marlinspike's new project Convergence, which proposes to eliminate the use of certificate authorities and replace the idea with a system of notaries and proxies. I am a big fan of Moxie's project and if you are a Firefox user you may wish to give it a try.
The evidence that Iran was using this certificate to spy on its citizens is circumstantial at best.
We don't know whether this was government initiated or just another random individual like the last Comodo certificate hack.
No httpsEither way, placing trust in more than 600 certificate authorities to be honest and not screw up is quite a leap of faith. Be sure to enable certificate revocation 
checks in your browsers and take a close look at alternatives like Convergence.

Update: Mozilla have announced out of an abundance of caution that they are releasing new versions of Firefox, Firefox Mobile and Thunderbird to revoke the trust of DigiNotar's root certificate for signing certificates.
I presume this is because DigiNotar has not explained how the Google certificate was signed and to prevent further abuse. This could cause issues for websites who have purchased certificates from DigiNotar.
It remains to be seen whether other browsers will follow in Mozilla's foot steps, but it may be prudent to remove DigiNotar from your trusted certificates until there is further clarification.
Update 2: Google is following Mozilla's lead by marking DigiNotar untrusted in the next release of the Chrome browser.

Certificate is here:

Update from

Somehow, somebody managed to get a rogue SSL certificate from them on July 10th, 2011. This certificate was issued for domain name

What can you do with such a certificate? Well, you can impersonate Google — assuming you can first reroute Internet traffic for to you. This is something that can be done by a government or by a rogue ISP. Such a reroute would only affect users within that country or under that ISP.

But why would anybody want to intercept Google? Well, this is not really about the search engine at This is about the Gmail servers at and Google Docs at and maybe Google+ at

We saw a similar attack in May (via Certificate reseller in Italy). That case was tied to Iran. So is this one. It's likely the Government of Iran is using these techniques to monitor local dissidents.

Iran does not have its own Certificate Authority. If they did, they could just issue rogue certificates themselves. But since they don't, they need such certificates from a widely trusted CA. Such as Diginotar.

How was Diginotar breached? We don't know yet.

But here's something we just discovered.

This is a screenshot of the page online right now at


Diginotar's portal has been hacked. Somebody claiming to be an Iranian Hacker has gained access.

This would look like a smoking gun. Obviously this has to be connected somehow to the rogue certificate.

But if you keep looking, you'll find this page from


Another Iranian hacker group?

If you keep digging deeper, you'll find that although these web defacements are still live right now, they are not new. Much worse: they were done years ago.

Here's another one, done in May 2009 by Turkish hackers at


In fact, these hacks are so old, it's unlikely they are connected to the current problem. Or at least so we hope.


If you like my blog, Please Donate Me

Aug 29, 2011

Attacking Applications List

If you want know what attacking application can do, lease go the Source. This post just list the some app. not all and not detail of the app.

Process Hacker
TFTP Theft
isr evilgrade
Cain & Abel
Medusa Parallel Network Login Auditor
Windows Credentials Editor
Dangerous Kitten
DB Audit
Safe3 SQL Injector
(OAT) OCS Assessment Tool
Phone Creeper
SpiderLab Tools

Download List: 

If you like my blog, Please Donate Me

Open Source database of android malwares

this post is just example or some part of the list of android malwares, if you want to see all in the list, please go to the Source.

This database is open source and anybody can send comments (or an email to androguard (at) t0t0 (dot) fr) in order to apply modifications on signatures or to add new signatures.

You can test if an application contains a malwares in the androguard example database, or add/remove new signatures. For now, we use similarity distance to search a signature in an application. For more information go to this page.
This database is an example of how it's possible to use androguard in order to detect parts of your application in another one.
If you are interesting about android malwares, it's possible to download few of them on the website of contagiodump.
On this page, you will find information about android malwares. Firstly, you will have links of different analysis of each malware. Next you can find which techniques has been used to add the sample in androguard database, but it's more interesting to check directly the signature. Of course, by using the similarity distance, we can detect variants of each malware.





  • SIGNATURE : METH_SIM ('Lcom/android/providers/downloadsmanager/c;', 'handleMessage', '(Landroid/os/Message;)V')





  • SIGNATURE : METH_SIM ("Lcom/dseffects/MonkeyJump2/jump2/h;", "onCreate", "(Landroid/os/Bundle;)V"), ("Lcom/dseffects/MonkeyJump2/jump2/e/i;", "a", "(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String;)Z"), ("Lcom/dseffects/MonkeyJump2/jump2/a/j;", "d", "()V"), ("Lcom/dseffects/MonkeyJump2/jump2/a/j;", "g", "()Landroid/content/Intent;")





If you like my blog, Please Donate Me