testssl.sh – Test SSL Security Including Ciphers, Protocols & Detect Flaws
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 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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 |
userid@somehost:~ % testssl.sh testssl.sh <options> -h, --help what you're looking at -b, --banner displays banner + version of testssl.sh -v, --version same as previous -V, --local pretty print all local ciphers -V, --local <pattern> which local ciphers with <pattern> are available? (if pattern not a number: word match) testssl.sh <options> URI ("testssl.sh URI" does everything except -E) -e, --each-cipher checks each local cipher remotely -E, --cipher-per-proto checks those per protocol -f, --ciphers checks common cipher suites -p, --protocols checks TLS/SSL protocols (including SPDY/HTTP2) -y, --spdy, --npn checks for SPDY/NPN -Y, --http2, --alpn checks for HTTP2/ALPN -S, --server-defaults displays the server's default picks and certificate info -P, --server-preference displays the server's picks: protocol+cipher -x, --single-cipher <pattern> tests matched <pattern> of ciphers (if <pattern> not a number: word match) -c, --client-simulation test client simulations, see which client negotiates with cipher and protocol -H, --header, --headers tests HSTS, HPKP, server/app banner, security headers, cookie, reverse proxy, IPv4 address -U, --vulnerable tests all vulnerabilities -B, --heartbleed tests for heartbleed vulnerability -I, --ccs, --ccs-injection tests for CCS injection vulnerability -R, --renegotiation tests for renegotiation vulnerabilities -C, --compression, --crime tests for CRIME vulnerability -T, --breach tests for BREACH vulnerability -O, --poodle tests for POODLE (SSL) vulnerability -Z, --tls-fallback checks TLS_FALLBACK_SCSV mitigation -F, --freak tests for FREAK vulnerability -A, --beast tests for BEAST vulnerability -J, --logjam tests for LOGJAM vulnerability -D, --drown tests for DROWN vulnerability -s, --pfs, --fs, --nsa checks (perfect) forward secrecy settings -4, --rc4, --appelbaum which RC4 ciphers are being offered? special invocations: -t, --starttls <protocol> does a default run against a STARTTLS enabled <protocol> --xmpphost <to_domain> for STARTTLS enabled XMPP it supplies the XML stream to-'' domain -- sometimes needed --mx <domain/host> tests MX records from high to low priority (STARTTLS, port 25) --ip <ip> a) tests the supplied <ip> v4 or v6 address instead of resolving host(s) in URI b) arg "one" means: just test the first DNS returns (useful for multiple IPs) --file <fname> mass testing option: Reads command lines from <fname>, one line per instance. Comments via # allowed, EOF signals end of <fname>. Implicitly turns on "--warnings batch" partly mandatory parameters: URI host|host:port|URL|URL:port (port 443 is assumed unless otherwise specified) pattern an ignore case word pattern of cipher hexcode or any other string in the name, kx or bits protocol is one of the STARTTLS protocols ftp,smtp,pop3,imap,xmpp,telnet,ldap (for the latter two you need e.g. the supplied openssl) tuning options (can also be preset via environment variables): --bugs enables the "-bugs" option of s_client, needed e.g. for some buggy F5s --assume-http if protocol check fails it assumes HTTP protocol and enforces HTTP checks --ssl-native fallback to checks with OpenSSL where sockets are normally used --openssl <PATH> use this openssl binary (default: look in $PATH, $RUN_DIR of testssl.sh) --proxy <host>:<port> connect via the specified HTTP proxy -6 use also IPv6. Works only with supporting OpenSSL version and IPv6 connectivity --sneaky leave less traces in target logs: user agent, referer output options (can also be preset via environment variables): --warnings <batch|off|false> "batch" doesn't wait for keypress, "off" or "false" skips connection warning --quiet don't output the banner. By doing this you acknowledge usage terms normally appearing in the banner --wide wide output for tests like RC4, BEAST. PFS also with hexcode, kx, strength, RFC name --show-each for wide outputs: display all ciphers tested -- not only succeeded ones --mapping <no-rfc> don't display the RFC Cipher Suite Name --color <0|1|2> 0: no escape or other codes, 1: b/w escape codes, 2: color (default) --colorblind swap green and blue in the output --debug <0-6> 1: screen output normal but keeps debug output in /tmp/. 2-6: see "grep -A 5 '^DEBUG=' testssl.sh" file output options (can also be preset via environment variables): --log, --logging logs stdout to <NODE-YYYYMMDD-HHMM.log> in current working directory --logfile <logfile> logs stdout to <file/NODE-YYYYMMDD-HHMM.log> if file is a dir or to specified log file --json additional output of findings to JSON file <NODE-YYYYMMDD-HHMM.json> in cwd --jsonfile <jsonfile> additional output to JSON and output JSON to the specified file --csv additional output of findings to CSV file <NODE-YYYYMMDD-HHMM.csv> in cwd --csvfile <csvfile> set output to CSV and output CSV to the specified file --append if <csvfile> or <jsonfile> exists rather append then overwrite All options requiring a value can also be called with '=' e.g. testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl <URI>. <URI> is always the last parameter. Need HTML output? Just pipe through "aha" (ANSI HTML Adapter: github.com/theZiz/aha) like "testssl.sh <options> <URI> | aha >output.html" userid@somehost:~ % |
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
|
1 |
curl -L https://testssl.sh |
|
1 |
wget -O - https://testssl.sh |
Or read more here.
Topic: Security Software
Four Year Old libssh Bug Leaves Servers Wide Open
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.
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
CHIPSEC is a platform security assessment framework for PCs including hardware, system firmware (BIOS/UEFI), and platform components for firmware hacking.
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:
Or read more here.
Topic: Hardware Hacking
How To Recover When Your Website Got Hacked
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.
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:
Topic: Countermeasures
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 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