testssl.sh – Test SSL Security Including Ciphers, Protocols & Detect Flaws

Use Netsparker


testssl.sh is a free command line tool to test SSL security, it checks a server’s service on any port for the support of TLS/SSL ciphers, protocols as well as recent cryptographic flaws and more.

testssl.sh - Test SSL Security Including Ciphers, Protocols & Detect Flaws


testssl.sh is pretty much portable/compatible. It is working on every Linux, Mac OS X, FreeBSD distribution, on MSYS2/Cygwin (slow). It is supposed also to work on any other unixoid systems. A newer OpenSSL version (1.0) is recommended though. /bin/bash is a prerequisite – otherwise there would be no sockets.

Features to Test SSL Security in testssl.ssh

  • Clear output: you can tell easily whether anything is good or bad
  • Ease of installation: It works for Linux, Darwin, FreeBSD and MSYS2/Cygwin out of the box: no need to install or configure something, no gems, CPAN, pip or the like.
  • Flexibility: You can test any SSL/TLS enabled and STARTTLS service, not only webservers at port 443
  • Toolbox: Several command line options help you to run YOUR test and configure YOUR output
  • Reliability: features are tested thoroughly
  • Verbosity: If a particular check cannot be performed because of a missing capability on your client side, you’ll get a warning
  • Privacy: It’s only you who sees the result, not a third party
  • Freedom: It’s 100% open source. You can look at the code, see what’s going on and you can change it. Heck, even the development is open (github)

Usage of testssl.sh SSL Security Testing Tool


Similarly there is also:

TLSSLed v1.2 – Evaluate The Security Of A Target SSL Or TLS (HTTPS) Web Server Implementation

You can get testssl.sh here:

Latest zip: testssl.sh-3.0rc2.zip

Or read more here.


Topic: Security Software

Four Year Old libssh Bug Leaves Servers Wide Open

The New Acunetix V12 Engine


A fairly serious 4-year old libssh bug has left servers vulnerable to remote compromise, fortunately, the attack surface isn’t that big as neither OpenSSH or the GitHub implementation are affected.

Four Year Old libssh Bug Leaves Servers Wide Open


The bug is in the not so widely used libSSH library, not to be confused with libssh2 or OpenSSH – which are very widely used.

There’s a four-year-old bug in the Secure Shell implementation known as libssh that makes it trivial for just about anyone to gain unfettered administrative control of a vulnerable server. While the authentication-bypass flaw represents a major security hole that should be patched immediately, it wasn’t immediately clear what sites or devices were vulnerable since neither the widely used OpenSSH nor Github’s implementation of libssh was affected.

The vulnerability, which was introduced in libssh version 0.6 released in 2014, makes it possible to log in by presenting a server with a SSH2_MSG_USERAUTH_SUCCESS message rather than the SSH2_MSG_USERAUTH_REQUEST message the server was expecting, according to an advisory published Tuesday.


The issue is to do with the fact the libssh server uses the same state machine to authenticate both clients and servers, the message dispatching code processes these requests with the same function and it doesn’t very which mode it’s running in.

This libssh bug is a case of clever exploration and understanding how a protocol works rather than fuzzing or brute-forcing to find a pretty serious vulnerability.

On the brighter side, there were no immediate signs of any big-name sites being bitten by the bug, which is indexed as CVE-2018-10933. While Github uses libssh, the site officials said on Twitter that “GitHub.com and GitHub Enterprise are unaffected by CVE-2018-10933 due to how we use the library.” In a follow-up tweet, GitHub security officials said they use a customized version of libssh that implements an authentication mechanism separate from the one provided by the library. Out of an abundance of caution, GitHub has installed a patch released with Tuesday’s advisory.

Another limitation: only vulnerable versions of libssh running in server mode are vulnerable, while the client mode is unaffected. Peter Winter-Smith, a researcher at security firm NCC who discovered the bug and privately reported it to libssh developers, told Ars the vulnerability is the result of libssh using the same machine state to authenticate clients and servers. Because exploits involve behavior that’s safe in the client but unsafe in the server context, only servers are affected.

A search on Shodan for this libssh bug shows about 6300+ sites using libssh, which isn’t exhaustive and also just the existence of libssh (like the GitHub implenmentation) doesn’t make it vulnerable.

It’s already fixed in the latest releases – libssh 0.8.4 and 0.7.6 – so go update your servers accordingly.

Source: Ars Technica


Topic: Exploits/Vulnerabilities

CHIPSEC – Platform Security Assessment Framework For Firmware Hacking

Use Netsparker


CHIPSEC is a platform security assessment framework for PCs including hardware, system firmware (BIOS/UEFI), and platform components for firmware hacking.

CHIPSEC - Platform Security Assessment Framework


It includes a security test suite, tools for accessing various low-level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X and UEFI shell.

You can use CHIPSEC to find vulnerabilities in firmware, hypervisors and hardware configuration, explore low-level system assets and even detect firmware implants.

What does CHIPSEC Platform Security Assessment Framework Do?

CHIPSEC has a bunch of modules focusing on areas such as Secure Boot, System Management Mode (SMM/SMRAM), BIOS and Firmware security, BIOS write protection etc.

Modules such as:

– SMRAM Locking
– BIOS Keyboard Buffer Sanitization
– SMRR Configuration
– BIOS Protection
– SPI Controller Locking
– BIOS Interface Locking
– Access Control for Secure Boot Keys
– Access Control for Secure Boot Variables

CHIPSEC Firmware Hacking Warnings

1. CHIPSEC kernel drivers provide direct access to hardware resources to user-mode applications (for example, access to physical memory). When installed on production systems this could allow malware to access privileged hardware resources.

2. The driver is distributed as source code. In order to load it on Operating System which requires kernel drivers to be signed (for example, 64-bit versions of Microsoft Windows 7 and higher), it is necessary to enable TestSigning (or equivalent) mode and sign the driver executable with test signature. Enabling TestSigning (or equivalent) mode turns off an important OS kernel protection and should not be done on production systems.

3. Due to the nature of access to hardware, if any CHIPSEC module issues incorrect access to hardware resources, Operating System can hang or panic.

You can download CHIPSEC here:

chipsec-v1.3.6rc1.zip

Or read more here.


Topic: Hardware Hacking

How To Recover When Your Website Got Hacked

The New Acunetix V12 Engine


The array of easily available Hacking Tools out there now is astounding, combined with self-propagating malware, people often come to me when their website got hacked and they don’t know what to do, or even where to start.

How To Recover When Your Website Got Hacked

Acunetix has come out with a very useful post with a checklist of actions to take and items to prepare to help you triage and react in the event of a compromise on one of your servers or websites.

When addressing such an event, it can be helpful to have a short checklist of tasks to perform in your recovery process. Doing the right things in the right order will be key to maximise your chances of successful and complete recovery, as well as mitigation of future events.

Preparation tasks – These make NO CHANGES to your website or any related or underlying components at all.
Action tasks – Things you need to do, with the obvious initial focus being blocking further access to any malicious actors.

Website Got Hacked Checklist

The list looks like this to deal with when your website got hacked:

  • PREPARE: Reaction plan
  • PREPARE: Battle sheet
  • ACTION: Take your system offline
  • PREPARE: Clone your system to a testbed or staging server
  • PREPARE: Scan your website for vulnerabilities; identify/confirm intrusion point
  • ACTION: Fix the vulnerability
  • ACTION: Bring the fixed version of the site back online with a clean OS/Web Server
  • PREPARE: Monitor your new and improved website
  • PREPARE: Make a Reaction Plan for FUTURE events.

The guide has a combination of basic forensics, proactive prevention moving forwards and general good sense when dealing with a compromise in terms of best practice.

Read the full post with details here:

How to Recover from a Hacked Website Event


Topic: Countermeasures
HTTrack - Website Downloader Copier & Site Ripper Download

HTTrack – Website Downloader Copier & Site Ripper Download

HTTrack is a free and easy-to-use offline browser utility which acts as a website downloader and a site ripper for copying websites and downloading them for offline viewing. HTTrack Website Downloader & Site Ripper HTTrack allows you to download a World Wide Web site from the Internet to a local directory, building recursively all directories, […]

Topic: Hacking News
sshLooter - Script To Steal SSH Passwords

sshLooter – Script To Steal SSH Passwords

sshLooter is a Python script using a PAM module to steal SSH passwords by logging the password and notifying the admin of the script via Telegram when a user logs in rather than via strace which is not so reliable. It also comes with an installation script install.sh to install all dependencies on a target […]

Topic: Hacking Tools