Video

Adrian Wiesmann - You hack, we laugh: Watch 31337 h4x0r5 at work

Feb 16 2012

New version of Kippo-Graph: 0.6.4

This is the release of a new version of Kippo-Graph, fixing some issues. Updating is recommended.

There was some errors on some of the charts concerning the date values. The SQL query I’ve been using didn’t work correctly with the coming of a new year, plus the custom function I’ve been using for parsing had another bug registering the correct day, perhaps because 2012 is a leap year.

The above issues are now fixed, plus there are some other small fixes. Also, a new chart has been added: successes per week.

Download it from here: kippo-graph-0.6.4

MD5 Checksum: 15D2FD7D243DFFB749C9F0FB6B143734
SHA-1 Checksum: 4FA6DFA240EB59211FEF3B13A71DA5A86F1E8EA8

PS. As soon as I tidy up the code a bit, Kippo-Graph will be moved to a project hosting environment so updating can be easier using SVN/git.

CHANGES:

Version 0.6.4:
- Removed dayofyear2date(), has a bug that adds +1 day in all 2012 dates (leap year?).
+ Changed SQL queries to timestamp values and date() parses the results - fixed graphs.
+ Added successes per week graph - updated gallery.
+ Small fixes.

For comments, suggestions, fixes, please use the Kippo-Graph page: http://bruteforce.gr/kippo-graph

Feb 13 2012

Kippo is being detected by Metasploit

So… I saw a new issue today in Kippo’s website that was posted some days ago.

It seems that Kippo is not only recognizable by a human attacker (see: Kippo reveals itself with ‘w’ and ‘uptime’ commands), but also without actually hacking into it.

Apparently, a Metasploit Framework‘s module can detect a Kippo installation. The Ruby script in question is located at msf3/modules/auxiliary/scanner/ssh/ and is called ssh_version.rb.

At first I thought that this could be due to yet another hardcoded string inside the code, but the version returned above is not anything out of the ordinary. So, I looked into it a bit and after some Google-Fu I found this presentation from a developer of metasploit: Detecting Medium Interaction Honeypots.

Inside he describes how Kippo can be recognized. More specifically, Kippo does not follow the correct key exchange sequence of an SSH server. Here are two examples of Wireshark captures from a real OpenSSH server and an emulated one (honeypot):

As you see above, in a normal connection attempt, the Server returns its protocol/version, then the Client responds with its own and requests a key exchange, to which the Server replies back and the keys are then exchanged using the Diffie-Helman protocol, and an encrypted connection is established.

While in Kippo, the Server prematurely sends a Key Exchange Init packet, thus messing up the sequence. This can be checked, and thus Kippo can be recognized. Here is the exact snippet that does the job:

The solution? Unfortunately I’m not sure at this time as I haven’t been able to invest some time in it.
Perhaps the developer of Kippo will try to fix it, as an issue/bug (num. 48) has been filed already.

Video

Defcon 18 - You spent all that money and you still got owned - Joseph McCray

Video

The Last HOPE: Ghetto IDS and Honeypots for the Home User

Jan 28 2012

New version of Kippo-Graph: 0.6.3

I’m pleased to release yet another updated version of Kippo-Graph: 0.6.3.

It includes:
New data for the Kippo-Input component: passwd, executed scripts and interesting commands tables.
Two more graphs (successes per day and human activity bar chart) and fixes to others.

Download it from here: kippo-graph-0.6.3

MD5 Checksum: 3B40524D0AC157C82661582014AB5BE0
SHA-1 Checksum: 31D0A2872BD346529E2D5535266822F7861E0C1E

CHANGES:

Version 0.6.3:
+ Added passwd, executed scripts and interesting commands tables.
+ Added successes per day graph - updated gallery.
+ Added human activity per day vertical bar chart - updated gallery.
+ Fixed successful logins from same IP graph.
+ Changed top 10 SSH clients graph to horizontal.
+ Small UI fixes, etc.

For comments, suggestions, fixes, please use the Kippo-Graph page: http://bruteforce.gr/kippo-graph

Jan 25 2012

Securing a server with Artillery

Artillery is project started by Dave (ReL1K) Kennedy with the aim to secure a linux web server.

Its description reads:

Artillery is a honeypot/monitoring/prevention tool used to protect Linux-based systems. Artillery will setup multiple ports on the nix system and if anything touches it will automatically blacklist them. In addition, it monitors the filesystem for changes and emails the changes back to you. It also detects SSH brute force attacks and automatically blocks them as well.

It can’t be really categorized as a honeypot since it doesn’t allow any interaction with the system, but I wanted to give it a try as an intrusion prevention tool and secure a VPS that I use for project hosting. Artillery essentially does three things: 1) it opens up various ports on the system and checks for connections. If someone abuses them it automatically adds a DROP iptables rule for that IP. 2) It checks SSH logs for brute force attempts and bans the abusing IP as well, 3) it can monitor some folders for changes, for example /var/www/.

Let’s use Artillery and see it in action. I’m using Debian 6 but the same would apply to any other distribution.

Installation is pretty straightforward:

1. First of all you will need SVN:

apt-get install subversion

2. Download the latest version of Artillery:

svn co http://svn.secmaniac.com/artillery artillery/

3. Run the installer (as root). Select no when asked to start Artillery now:

python install.py

This will install Artillery at /var/artillery. Take note of this, because the downloaded files are no longer useful (you can delete them) and any configuration has to be made in the new directory.

Take a look at the /var/artillery/config file where you can set various options. Read the comments above each choice and it should be pretty straightforward. The PORTS variable is the most interesting one since these are the ports Artillery will bind to and listen for connections. One thing to notice here is that Artillery has MySQL’s port 3306 included in the list, so if you run a MySQL server be sure to remove it. The same thing applies for some other common ports like 21 (FTP), 22 (SSH), 53 (DNS). Something for SSH: in order not to mess with Artillery at all and accidentally lock yourself out of the system, I recommend changing your SSH port anyway (for example to 2222). Generally be careful with the automatic lockout feature (don’t test it by logging into dummy ports on your system because you will be banned).

4. Reboot your system (if possible) or run the restart_server.py script. That’s it, you are ready. You can check that Artillery works correctly using:

netstat -antp

where you should see something like this (sample):

One thing you will notice is that Artillery will get results very quickly. I think this is mostly due to port 445 (SMB) because from my experience with Dionaea honeypot it gets a big amount of traffic from infected Windows computers.

While writing this post it had already banned some hosts:

5. You can check for banned IPs using:

iptables -L

and you will get a list of all the IPs (or hostnames as they are auto-resolved) with their DROP rules. For a text-based list of all the IP addresses you can view the banlist.txt file where every banned IP is written to.

Artillery is being developed and hopefully new versions will include even more functionality. I think it is a simple-to-understand and promising tool to enhance the security of a server. More results from its operation will be published in the future!

Page 24 of 29« First...10...2223242526...Last »