20160423

Buffer Overflow - SLMail

Well, of course there is a module that will do the exploit for you, but I have joined the many people who have put together a video on how to do a buffer overflow using SLMail, Immunity Debugger, mona commands, and Kali Linux, and put the video on  YouTube.  Probably easier if you just watch the video, but the 'in a nutshell' version is:
1) Find a spot we can crash a program.
2) See if someone has already written a Proof of Concept for us.
3) See if it works.
4) Fix the parts that do not work.
5) Profit.

In the video we go from vulnerable service, and proof of concept, to a bind shell and a connection in msfconsole.

Hat tip to Offensive Security, whose Penetration Testing with Kali course was my first exposure to this level of detail in how a buffer overflow works.  The same exercise is presented within that course, along with many others.


Kali Bugs

I stumbled upon a slight error in Kali today.  It was easily reproducible, so I went over to bugs.kali.org/ to report it.  I had to register to report, but that was pretty painless.  If you find things that you think (or know) are wrong, I encourage you to report them, too.

Oh, my thing? When I used the Applications --> Reverse Engineering --> NASM shell menu button, I got this:

So, I reported it as a broken link.  Hopefully it will be fixed for all users soon.

Update: After i did a little bit of apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y the menu was fixed.

20160421

An expect script for bandit labs

If you have tried the bandit series of labs over at over the wire you have experienced trying to paste an SSH password in to the prompt, only to be unable to see what you pasted and needing to hope for the best.  But, you can use an expect script like this one to log in for you, and that will save you a second here and there.

This is the script:
#!/usr/bin/expect
set level [lindex $argv 0]
set password [lindex $argv 1]
spawn ssh bandit$level@bandit.labs.overthewire.org
expect "password: "
send $password\r
sleep 2
send ls\r
expect "$ "
interact

You can invoke it with script_name # PASS, where script_name is whatever you name the script, # is the level number you are on, and PASS in the password for that level.  If you name the script ssh_bandit, you can get to the first level (level 0) with:
ssh_bandit 0 bandit0

To look at the script line - by - line, we can see it:
1) Tells bash what program to use to run the script.
2) Sets the level variable to the first argument value.
3) Sets the password variable to the second argument value.
4) Starts an SSH session as the bandit<level#> user @ the server.
5) Waits for the password prompt.
6) Sends the password, and return.
7) Waits two seconds.
8) Sends the ls command, and a newline. (This is handy because you will often want to do a directory listing first thing.)
9) Waits for a prompt.
10) Switches to interactive mode.  (Without this, typing exit to leave the SSH shell exits the bash shell.)

(Note: This may not cover the first connection for you, since the bandit server's key may not be in your known hosts, and it does not account for this variation.  Feel free to improve upon it.)

20160417

Standard Shell to Meterpreter Shell in Metasploit

TL;DR: sessions -u 

As we use various exploit modules we may or may not be able to employ a meterpreter payload directly with the module.  Inside the exploit module context, the show payloads command while show which payloads are available. Once a session is established without meterpreter, the sessions -u command can be used to upgrade the basic shell to a meterpreter shell.  You can see the play-by-play in screenshots on YouTube, complete with narration.

Enjoy, and good luck.

20160410

OpenVAS for my home network

I have been playing with OpenVAS now and then for a few years now.  I thought I would try it on my own network to see what I could find.  I had set up the system before (covered here), so I simply ran openvas-feed-update and navigated over to the main page in Iceweasel, as in the following picture:

After clicking on the 'Start Scan' button, I was treated to this view:

I clicked on 'Scan Management --> Reports' to see the result, as here:
In the picture above, you can see the worst result is the result in the 'Security' field.

Taking a look at the report:

We can see there is one host responsible for most of the flaws, while a 'TCP timestamps' flaw is seen on four other hosts.  The host with IP address 192.168.1.24 is my Cisco switch.  I may go on a separate quest to see if I can squash these flaws.  But, for now, they can stay.  On, and TCP timestamps? One is my small router, one is a printer, one is my Mac Mini, and one is my iPhone.