Hosting Kali in the Cloud – Catch those Reverse Shells where they matter!

Hello,

if you want to host Kali in the Cloud I can recommend the host Vultr!

You can prepay your account with PayPal and Bitcoin and fire up a Kali VM in 30 Minutes by “wgetting” the Kali minimal Iso to the hoster and booting via KVM and performing the Kali Installation Routine.

The prices are roughly half of comparable AWS Instances!

So just try it out, setting up a Kali VM and playing around a bit did cost me roughly 19 USD Cents…

You also can see you Account Balance and detailed per Server monthly fees in the Webinterface! If the VM is powered down it does not cost you anything.

Disclaimer: The link above and below are including a referral to my account!
If you like Vultr and stumbled onto it via my blog please use this link to sign up!

http://www.vultr.com/?ref=6834090

Feel free to post any comments or questions below!
I will be happy to reply quickly!

Best regards
Sebastian

Posted in pentesting | Tagged , , , , , , , | 9 Comments

security onion – vmware-config-tools.pl cant find kernel headers

Hello,

if you try to install VMware Tools on Security Onion and it cant find the Kernel Headers even if the “linux-headers-$(uname -r)” package is installed try the following:

sudo ln -s /usr/src/linux-headers-$(uname -r)/include/generated/uapi/linux/version.h /usr/src/linux-headers-$(uname -r)/include/linux/version.h

and run vmware-config-tools.pl again. Worked like a charm for me!

Regards
Sebastian

Posted in miscellaneous | Leave a comment

Only use a stager if there is a stage to perform on – shell/reverse_tcp vs. shell_reverse_tcp

Hi,

just a quicky:

(If you don’t know what this is about maybe you want to brush up your knowlege in offensive security)

If you need to generate a simple reverse shell payload with metasploit (msfpayload | msfencode) be aware of the difference between shell/reverse_tcp and shell_reverse_tcp!

shell/reverse_tcp is just a stager that connects back to metasploit and loads the actual payload (shellcode)! So if you are sitting in front of your netcat listener the stager will miss its intended stage and will not perform a pretty act (a shell) for you…

If you are just using msfpayload you will see a splitted output (Stage 1+2) that will remind you. However if you pipe directly into msfencode then you will get no feedback in the output!

You can also look at the rapid7 module listing:
https://www.rapid7.com/db/modules/payload/linux/x86/shell_reverse_tcp
https://www.rapid7.com/db/modules/payload/linux/x86/shell/reverse_tcp

Regards
Sebastian

Posted in InfoSec | Tagged , , , , | Leave a comment

fail 2 package – fail2ban does not recognize debians auth.log timestamp format

Hello,

I just set up fail2ban on a Debian 6.0.9 and had some trouble getting it to work.
After some google research I found out that debian logs with a different time stamp to the auth.log than expected by fail2ban.

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633223

Strangely I found this problem a couple of times on google but no solution for it.

I fixed it quick and dirty by just substituting the timestamp with a wildcard in the “/etc/fail2ban/filter.d/sshd.conf”:

...
failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from \s*$
            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from \s*$
            ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$
            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s*$
            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$
            ^%(__prefix_line)sUser .+ from  not allowed because not listed in AllowUsers$
            .*authentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=(?:\s+user=.*)?\s*$
            ^%(__prefix_line)srefused connect from \S+ \(\)\s*$
            ^%(__prefix_line)sAddress  .* POSSIBLE BREAK-IN ATTEMPT!*\s*$
            ^%(__prefix_line)sUser .+ from  not allowed because none of user's groups are listed in AllowGroups\s*$

...

with this modified line (4th from the bottom) fail2ban is now working fine for me!

If you are running ssh on a non-standard port like I am make sure to edit the [ssh] section of the “/etc/fail2ban/jail.local” config file:

...
[ssh]

enabled = true
port    = all
banaction = iptables-allports
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6
...

Regards
Sebastian

Posted in InfoSec, network | Tagged , , , , , , , , | Leave a comment

muscle up with brute force – build john with multi cpu support to crack those hashes faster!

Hello,

im currently doing the Penetration Testing with Kali Linux (PWK) course from the awesome Offensive Security Team which also brings you the famous Kali Linux (formerly BackTrack).

(if you don’t care and just want to crack password skip to the next headline!)

This post is not about PWK or the subsequent OSCP certificate, but I will just give you a brief idea what PWK is about:

PWK/OSCP is a Pentesting training with certification at the end. Basically you sign up for an online course and receive video tutorials and a pdf script to get you into the basics of hacking systems (enumeration, exploitation, post exploitation and so on).

With beginning of your course time you get an openvpn account which lets you connect to a huge network of machines that let you practice and sharpen your skills on a variety of machines and operation systems. You can connect to the lab with a Kali VM, that comes with all needed tools, in a matter of minutes.

Do not think its just the same as downloading metasploitable2 and some other vulnerable machines! It gives you much more complex setups to exploit! (I wont spoil anything here tough).

When your lab-time is over and/or you exploited all the machines in the lab (50+) you can schedule the OSCP exam and prove that you are a worthy addition to the security/pentesting community :)

This is accompanied by a really great IRC channel with great people: Other students and a bunch of admins that are always available to help and set you on the right track!

As im just in the middle of the lab time and have not taken the exam yet I will not go deeper about this topic in this post.

Let me just assure you it absolutely rocks and is worth every cent! I can say that I have learned more linux/unix knowhow than I learned in the last 2 years on my job!

Now shut up and tell me about john!

During the PWK course it has become second nature for me to obtain password hashes and cracking them (mostly with JohnTheRipper aka john).

Sadly Kali only comes with a single core threaded version of john. If you have a nice quad core cpu (like in a decent macbook for example) this means you are waiting four times longer on your clear text passwords than you need to!

Here is an easy guide how to compile the newest build of john with multi core support:

1. Go to /opt (or any other location you want to put it) and clone the git repository:

cd /opt
git clone https://github.com/magnumripper/JohnTheRipper.git

2. go to the src directory and edit the “Makefile” file to comment in the 2 lines for Multi-CPU support:

vi JohnTheRipper/src/Makefile

remove the # before those two lines and save the file (:wq in vi)

# gcc with OpenMP
OMPFLAGS = -fopenmp
# gcc with OpenMP on 32-bit x86 with SSE2
OMPFLAGS = -fopenmp -msse2

3. Build john for i686 and x64 architecture (or any other you might have):

cd JohnTheRipper/src
make linux-x86-64-32-sse2

4. john will be build under ../run and now has the option – – fork=x

cd ../run
./john --fork=4 /root/loot/somehashfile.txt

Thats it! Depending on your CPU you will have 2x-$(max cores of your cpu)x times the performance cracking the password hashes you really need to get cracked :)

Regards
Sebastian

 

Posted in InfoSec | Tagged , , , , , , , , , , , | 2 Comments

catch those malwares – outbound firewalling with openwrt / iptables

Hi,

ever wanted to do strict outbound firewalling on your openwrt router? For example only allow http and https outbound by default and get logging for everything that tries to connect to any different port on the internet?

You can to this quite easily by adding a couple of custom iptables lines to your openwrt firewall config file (/etc/firewall.user):

############ OUTBOUND Configuration ###################

#REJECT EVERYTHING
iptables -I zone_lan_forward -j zone_lan_dest_REJECT

#Enable Logging
iptables -I zone_lan_dest_REJECT -j REJECT
iptables -I zone_lan_dest_REJECT -p tcp -j REJECT --reject-with tcp-reset
iptables -I zone_lan_dest_REJECT -j LOG --log-prefix "REJECTED ON LAN: "
############ ALLOW SPECIFIC OUTBOUND TRAFFIC ##############
iptables -I zone_lan_forward -i br-lan -p tcp -m tcp --dport 80 -j zone_wan_dest_ACCEPT -m comment --comment "ALLOW HTTP"
iptables -I zone_lan_forward -i br-lan -p tcp -m tcp --dport 443 -j zone_wan_dest_ACCEPT -m comment --comment "ALLOW HTTPS"

Let me explain these lines one by one:

iptables -I zone_lan_forward -j zone_lan_dest_REJECT

This command will insert a rule at the top of your “zone_lan_forward” chain (which gets all traffic that is to be forwarded to the internet/wan interface) and will “jump” (-j) the packets over to the “zone_lan_dest_REJECT” chain.
All rules for traffic that we want to allow will be inserted later on and thus be above this rule. So this reject-rule only gets hit by traffic that we do not explicitly allow!

iptables -I zone_lan_dest_REJECT -j REJECT

This command will create a rule inside the “zone_lan_dest_REJECT” chain that will reject all traffic with an icmp uncreachable.

iptables -I zone_lan_dest_REJECT -p tcp -j REJECT –reject-with tcp-reset

This command will do the same as the one before, only that it will specifically reset tcp connections so they do not have to timeout slowly but get a tcp rst instantaneously. This saves you a lot of waiting for tcp timeouts.

iptables -I zone_lan_dest_REJECT -j LOG –log-prefix “REJECTED ON LAN: “

This command will log every packet hitting the “zone_lan_dest_REJECT” chain with a prefix of your liking (i chose “REJECTED ON LAN: “). You can grep on this prefix lateron.
Again notice the order of the commands. This command needs to be issued last so it will be sitting in front of the REJECT rules (see iptables -L output below for visualization).

iptables -I zone_lan_forward -i br-lan -p tcp -m tcp –dport 80 -j zone_wan_dest_ACCEPT -m comment –comment “ALLOW HTTP”

Now the traffic rules: This command inserts a rule at the top of the chain “zone_lan_forward”. Notice that this will insert this rule above the rule created from the first command I explained. Thus the traffic hitting this rule will be allowed instead of beeing “jumped” to the “zone_lan_dest_RECET” chain!

-i br-lan = incoming interface (check your routers config, e.g. ifconfig and see which interface holds your default gw ip)

-p tcp -m tcp = specifies the tcp protocoll and makes the connections state trackable (i dont use the state information in this example, you could leave the -m tcp option out)

–dport 80 = allow http / destination port 80

– j zone_wan_dest_ACCEPT = jump the packets to the accept-chain where they will be sucessfully routed

– m comment –comment “ALLOW HTTP” = comment the rule for human readability of the ruleset!

(I am only going to explain one rule as an example as these rules are quite self-explanatory and documentation of default iptables syntax is quite good on the internet and in the manpages)

You can also add this via the LuCI webfrontend:

iptables-LuCI

After you safed the /etc/firewall.user file (or the Custom Rules form in LuCI) make sure to restart the firewall:

/etc/init.d/firewall restart

The resulting iptables ruleset should look something like this:

root@router:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
delegate_input  all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
delegate_forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
delegate_output  all  --  anywhere             anywhere            

Chain delegate_forward (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
zone_lan_forward  all  --  anywhere             anywhere            
zone_wan_forward  all  --  anywhere             anywhere            
reject     all  --  anywhere             anywhere            

Chain delegate_input (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
syn_flood  tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
zone_lan_input  all  --  anywhere             anywhere            
zone_wan_input  all  --  anywhere             anywhere            

Chain delegate_output (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
zone_lan_output  all  --  anywhere             anywhere            
zone_wan_output  all  --  anywhere             anywhere            

Chain reject (4 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain syn_flood (1 references)
target     prot opt source               destination         
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50
DROP       all  --  anywhere             anywhere            

Chain zone_lan_dest_ACCEPT (3 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain zone_lan_dest_REJECT (2 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "REJECTED ON LAN: "
REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
reject     all  --  anywhere             anywhere            

Chain zone_lan_forward (1 references)
target     prot opt source               destination     
zone_wan_dest_ACCEPT  tcp  --  anywhere             anywhere             tcp dpt:https /* ALLOW HTTPS */    
zone_wan_dest_ACCEPT  tcp  --  anywhere             anywhere             tcp dpt:www /* ALLOW HTTP */
zone_lan_dest_REJECT  all  --  anywhere             anywhere            
zone_wan_dest_ACCEPT  all  --  anywhere             anywhere             /* forwarding lan->wan */
zone_lan_dest_REJECT  all  --  anywhere             anywhere            

Chain zone_lan_input (1 references)
target     prot opt source               destination         
zone_lan_src_ACCEPT  all  --  anywhere             anywhere            

Chain zone_lan_output (1 references)
target     prot opt source               destination         
zone_lan_dest_ACCEPT  all  --  anywhere             anywhere            

Chain zone_lan_src_ACCEPT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain zone_wan_dest_ACCEPT (9 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain zone_wan_dest_REJECT (1 references)
target     prot opt source               destination         
reject     all  --  anywhere             anywhere            

Chain zone_wan_forward (1 references)
target     prot opt source               destination         
zone_wan_dest_REJECT  all  --  anywhere             anywhere            

Chain zone_wan_input (1 references)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc /* Allow-DHCP-Renew */
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request /* Allow-Ping */
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https /* Allow-OpenVPN */
zone_wan_src_REJECT  all  --  anywhere             anywhere            

Chain zone_wan_output (1 references)
target     prot opt source               destination         
zone_wan_dest_ACCEPT  all  --  anywhere             anywhere            

Chain zone_wan_src_REJECT (1 references)
target     prot opt source               destination         
reject     all  --  anywhere             anywhere

Inspecting the logs

To see dropped connections you can use the “logread -f” command.

You should then manually allow all the connections you really want (add more lines after “allow http” and see all the junk that wants to phone home being dropped :)

I am currently thinking about redirecting the reject-logs to a central syslog server and build a small php/mysql frontend for log analysis.

You could also just forward all these logs to a splunk server…

Plese Note that this will not automatically show you all malware that could reside in your network. A lot of malware is likely to “phone home”/contact its c&c server via http/https. If you want to catch those you have to create a logging chain and rule for your accepted http/https traffic as well and create some kind of IP/URL tracking, blacklisting/whitelisting and possibly alerting!

Maybe I will create another blogpost regarding this.

Feel free to asks questions or post comments below!

Regards
Sebastian

Update 2014-09-14:

As requested in the comments here a screenshot of my “Netzwork -> Firewall -> General Settings”

general settings

Posted in OpenWRT | Tagged , , , , | 8 Comments

openvpn in bridge mode on ESX Server – arp problem

Hello,

just a quick one because it just drove me insane:

If you are setting up an openvpn server in bridge mode in a virtual machine on VMware ESX(i) hypervisor make sure to enable promiscuous mode on the vSwitch:

promiscesx

openvpn needs to be able to go into promiscuous mode to get the ethernet packets that are addressed to the vpn clients mac adresses. By default the virtual switch will prevent this for security reasons (arp spoofing).

If you are not comfortable with that use routing instead of briding openvpn configuration.

Regards
Sebastian

 

Posted in miscellaneous | Tagged , , , , , | Leave a comment

Please delete your logs first, we can alert you later…. – Checkpoint Local Log Storage

Whats wrong with the Picture below?

local log storage

“… start deleting old log files.” must be at least 5MBytes greater than “… issue alert.”

Okay so it is not just recommended but enforced that I have to first delete log files and get alerted about it later?

Gladly its not. This seems to be just a misleading “Error Message”. But what is enforced in the Smart Dashboard GUI is that Stop logging needs to happen before automatically deleting logfiles. This can be argued but I can at least see a logic in that.

However what I would really like would be a “Warning/Suggestion” instead of taking the decision out of my hand and forbidding me to set this up the way I want to.

Keeping in mind Checkpoint’s main targeted market are large enterprises which should have admins that are capable of deciding such things for themselves.

Also what good are 5MBytes nowadays?!The screenshot is taken from a R76 Mgmt.

Regards
Sebastian

Posted in Checkpoint | Tagged , , , | Leave a comment

No fancy software – Android Backup and Restore

Just in case you did not know:

You can backup and restore all configuration and apps on an android device with the Android sdk:
http://developer.android.com/sdk/index.html

Backup: adb backup -apk -shared -all -f filename

And after a factory reset or reflash:

Restore: adb restore filename

Regards
Sebastian

Posted in miscellaneous | Tagged , , , | Leave a comment

Android Porn – How to break and restore a Nexus 7 to stock Android

Hello,

I just tested Ubuntu 13.10 Touch (current stable channel) on my Nexus 7 (first edition) and it was performing horribly. Constant freezes and lockups…

When I tried to restore Android Stock I got the device in a state where it just showed failed boot and no adb connections possible.

After some heavy googleing I could restore it like this:

  • downloaded and installed android sdk: http://developer.android.com/sdk/index.html
  • export platform-tools directory to path (only for unix oses)
  • boot Nexus7 into “fastboot” screen (with big green start box)
  • verified osx did detect the device “fastboot devices” -> should list a device with status “fastboot”
  • downloaded 4.3 factory image from https://developers.google.com/android/nexus/images#nakasi
  • extracted tgz file (do not extract the zip file that lies beside the flash scripts
  • executed “flash-all.sh” (Edit: the flash-all script is located in the nexus firmware tgz!)

During all of this I also saw an inconsistent reliability of the adb/fastboot connection. Sometimes I needed to unplug and replug the nexus 7 a couple of times until it got recognized by adb/fastboot and could successfully be flashed.

Maybe this helps someone…

Regards
Sebastian

Posted in miscellaneous | Tagged , , , , , , , | 24 Comments