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 *.torproject.org 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 nu.nl, 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 Google.com 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.

SOCKS Proxy

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

ssh -D 127.0.0.1:1080 10.0.0.1
~/.ssh/config:

Host 10.0.0.1
DynamicForward 127.0.0.1:1080
You can then use tsocks or similar to use non-SOCKS-aware tools on hosts accessible from 10.0.0.1:

tsocks rdesktop 10.0.0.2

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 127.0.0.1:10521:127.0.0.1:1521 user@10.0.0.1
~/.ssh/config:

LocalForward 127.0.0.1:10521 127.0.0.1:1521

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 0.0.0.0:10521:127.0.0.1:1521 10.0.0.1
~/.ssh/config:

LocalForward 0.0.0.0:10521 127.0.0.1:1521

Example 3

In this example, 10.0.0.99 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 127.0.0.1:10521:10.0.0.99:1521 10.0.0.1
~/.ssh/config:

LocalForward 127.0.0.1:10521 10.0.0.99:1521

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 127.0.0.1:8000 on the SSH server.
Command line:

ssh -R 127.0.0.1:8000:127.0.0.1:80 10.0.0.1
~/.ssh/config:

RemoteForward 127.0.0.1:8000 127.0.0.1:80

Example 2

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

ssh -R 127.0.0.1:8000:172.16.0.99:80 10.0.0.1
~/.ssh/config:

RemoteForward 127.0.0.1:8000 172.16.0.99:80

Example 3

The SSH server will be able to access TCP port 80 on 172.16.0.99 (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 172.16.0.99:80.  This can sometimes be insecure.
Command line:

ssh -R 0.0.0.0:8000:172.16.0.99:80 10.0.0.1
~/.ssh/config:

RemoteForward 0.0.0.0:8000 172.16.0.99:80

Configuration Files


~/.ssh/config

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.

Host 10.0.0.1
Port 2222
User ptm
ForwardX11 yes
DynamicForward 127.0.0.1:1080
RemoteForward 80 127.0.0.1:8000
LocalForward 1521 10.0.0.99:1521
The above lines are explained more fully in the other subsection on this page.

~/.ssh/authorized_keys

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 mykey.pub # 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 mykey.pub # 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@10.0.0.1

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 -X 10.0.0.1
SSH -Y 10.0.0.1 # less secure alternative - but faster

~/.ssh/config:


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

Source: http://pentestmonkey.net/cheat-sheet/ssh-cheat-sheet


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.

Source: http://www.thehackernews.com/2011/08/andosid-dos-tool-for-android.html


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 *.google.com 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: http://pastebin.com/ff7Yg663
Source: http://nakedsecurity.sophos.com/2011/08/29/falsely-issued-google-ssl-certificate-in-the-wild-for-more-than-5-weeks/


Update from www.f-secure.com:

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

What can you do with such a certificate? Well, you can impersonate Google — assuming you can first reroute Internet traffic for google.com 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 www.google.com. This is about the Gmail servers at mail.google.com and Google Docs at docs.google.com and maybe Google+ at plus.google.com.

We saw a similar attack in May (via Certificate reseller instantssl.it 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 https://www.diginotar.nl/Portals/0/Extrance.txt:

Diginotar

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 https://www.diginotar.nl/Portals/0/owned.txt:

Diginotar

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 https://www.diginotar.nl/Portals/0/fat.txt:

Diginotar

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


Source: http://www.f-secure.com/weblog/archives/00002228.html

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
Sniff-n-Spit
TFTP Theft
isr evilgrade
spiderpig
Bruter
Cain & Abel
KrbGuess
Medusa Parallel Network Login Auditor
Ncrack
RSYaba
Windows Credentials Editor
thc-hydra
Dangerous Kitten
Syringe
shellcodeexec
subSeven
winAUTOPWN
DB Audit
ExploitMyUnion
Havij
OScanner
SFX-SQLi
Safe3 SQL Injector
Scrawlr
Toolza
bsqlbf
hexjector
sqlmap
sqlninja
Inguma
(OAT) OCS Assessment Tool
NeoPwn
Phone Creeper
androidAuditTools
FireCat
PeachFuzzer
Scapy
SpiderLab Tools
hping
pentbox
6tunnelDDOSIM
DDOSIM


Download List: http://www.wupload.com/file/127947423/List_of_Attacking_Application.docx 
Source: http://r3stricted.com/book/export/html/32

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.

Supported

dogowar

droiddream

droiddreamincluded

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

droiddreamlight

droidkungfu

droidkungfu2

geinimi

  • http://blog.mylookout.com/2011/01/geinimi-trojan-technical-analysis/
  • 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;")

golddream

nickyspy

walkinwat

Source: http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares


If you like my blog, Please Donate Me
 

Sponsors

lusovps.com

Blogroll

About

 Please subscribe my blog.

 Old Subscribe

Share |