Eraser – Windows Secure Erase Hard Drive Wiper
Eraser is a hard drive wiper for Windows which allows you to run a secure erase and completely remove sensitive data from your hard drive by overwriting it several times with carefully selected patterns.
Eraser is a Windows focused hard drive wiper and is currently supported under Windows XP (with Service Pack 3), Windows Server 2003 (with Service Pack 2), Windows Vista, Windows Server 2008, Windows 7,8 ,10 and Windows Server 2012.
Secure drive erasure methods are supported out of the box. Erases files, folders and their previously deleted counterparts. Works with an extremely customizable scheduler.
Why a Secure Erase Hard Drive Wiper is important?
A lot of people underestimate the importance of this, especially if you are throwing out an old hard disk or selling something on that contains a hard disk (an old laptop or desktop).
Your first thought may be that when you ‘delete’ the file, the data is gone. But that is not true, when you delete a file, the operating system does not really remove the file from the disk; it only removes the reference of the file from the file system table.
The file remains on the disk until another file is created over it, and even after that, it might be possible to recover data by studying the magnetic fields on the disk platter surface.
Before the file is overwritten, anyone can easily retrieve it with a disk maintenance or an undelete utility.
That is why it’s critical to erase your disks properly before finding them a new home (be that a bin, recycling plant or selling them on).
Depending on the value of the date, select one of the below secure wipe algorithms.
Secure Erase Hard Drive Wiper Methods
Pseudorandom data, 1 Pass, The fastest wiping scheme. Your data is overwritten with random data (if you use a CSPRNG the data is indistinguishable from random noise.)
British HMG IS5 (Baseline), 1 Pass, Your data is overwritten with zeroes.
Russian GOST P50739-95, 2 Passes, GOST P50739-95 wiping scheme calls for a single pass of zeroes followed by a single pass of random data
British HMG IS5 (Enhanced), 3 Passes, British HMG IS5 (Enhanced) is a three pass overwriting algorithm: first pass – with zeroes, second pass – with ones and the last pass with random data.
US Army AR380-19, 3 Passes, AR380-19 is data wiping scheme specified and published by the U.S. Army. AR380-19 is three pass overwriting algorithm: first pass – with random data, second with a random byte and the third pass with the complement of the 2nd pass
US Department of Defense DoD 5220.22-M (E), 3 Passes, DoD 5220.22-M (E) is a three pass overwriting algorithm: first pass – with zeroes, second pass – with ones and the last pass – with random data
US Air Force 5020, 3 Passes, US Air Force 5020 is a three pass overwriting algorithm with the first pass being that of a random byte, followed by two passes of complement data (shifted 8 and 16 bits right respectively)
US Department of Defense DoD 5220.22-M(ECE), 7 Passes, DoD 5220.22-M(ECE) is seven pass overwriting algorithm: first, fourth and fifth pass with a random byte, its 8 right-bit shift complement and 16 right-bit shift complement; second and sixth passes with zeroes, and third and seventh pass with random data
Canadian RCMP TSSIT OPS-II, 7 Passes, RCMP TSSIT OPS-II is a seven pass overwriting algorithm with three alternating patterns of zeroes and ones and the last pass – with a random byte
German VSITR, 7 Passes, The German standard calls for data to be overwritten with three alternating patterns of zeroes and ones and in the last pass with random data
Schneier’s Algorithm, 7 Passes, The Bruce Schneier algorithm has seven passes: first pass – with ones, the second pass – with zeroes and then five times with random data
You can download Eraser here:
Or read more here.
Topic: Privacy
Web Security Stats Show XSS & Outdated Software Are Major Problems
Netsparker just published some anonymized Web Security Stats about the security vulnerabilities their online solution identified on their users’ web applications and web services during the last 3 years.
Data-based stats like these, which are not based on surveys, can be pretty useful – at least to get a broad overview of what is going on. These statistics also serve a solid purpose – they help all developers, security professionals and anyone who works with web applications better understand what might be going wrong.
XSS is way more common than SQL Injection
SQL Injection has been the most critical web application vulnerability in the last decade according to the OWASP Top 10 list of most critical web application security flaws (yeah come-on guys, we are still waiting for the new version!). Though the Netsparker statistics show us that it is the other way round, at least in terms of volume.
26% of the identified vulnerabilities, 40,908 to be exact, were a mix of reflected and DOM Cross-site scripting (XSS) vulnerabilities. Only 2% of the identified vulnerabilities were SQL Injections.
That is a big discrepancy, though this is not a surprise according to the authors. They said:
Developers have a lot of resources to write code that is not vulnerable to SQL Injections, such as prepared statements. New frameworks by default protects against SQL Injection and makes it quite hard to write insecure SQL code. On the other hand XSS vulnerabilities are much more complex to address and even when the framework has built-in protection, it’s very easy to make mistakes
Outdated & vulnerable software is still a major web application security risk
Update your apps, your server, your software – Apple, Google, Microsoft are constantly harping on this topic but it doesn’t seem to help that much.
It’s one of the easiest best practices to follow, especially in modern times with automated updates and patch management software easily available.
It seems not to be the case that people are following it with 5% of the identified issues related to outdated software.
If Equifax and Mossack Fonseca had their software up to date, last year we wouldn’t have had two of the biggest data breaches on the internet.
Accuracy is key to more secure web applications
There are several other statistics from which we can learn something from, an interesting one for me was the fact that Netsparker automatically verified around 80% of the identified vulnerabilities.
False positives are a big problem in automated vulnerability and security scanning as someone has to manually spend hours verifying the results and weeding out the false positives. With Netsparker automatically doing this, a smaller team can do more effective work and a larger team can be more productive doing less manual verification.
Read The Netsparker Scan Web Security Stats Report
The report is much more detailed and has much more statistics, so please read the Netsparker scan statistics report for all the numbers and common security issues that make web applications vulnerable to malicious hacker attacks and can save you from some embarrassment.
Topic: Countermeasures
CTFR – Abuse Certificate Transparency Logs For HTTPS Subdomains
CTFR is a Python-based tool to Abuse Certificate Transparency Logs to get subdomains from a HTTPS website in a few seconds.
You missed AXFR technique didn’t you? (Open DNS zone transfers), so how does it work? CTFR does not use dictionary attack or brute-force attacks, it just helps you to abuse Certificate Transparency Logs.
What is Certificate Transparency?
Google’s Certificate Transparency project fixes several structural flaws in the SSL certificate system, which is the main cryptographic system that underlies all HTTPS connections. These flaws weaken the reliability and effectiveness of encrypted Internet connections and can compromise critical TLS/SSL mechanisms, including domain validation, end-to-end encryption, and the chains of trust set up by certificate authorities. If left unchecked, these flaws can facilitate a wide range of security attacks, such as website spoofing, server impersonation, and man-in-the-middle attacks.
From: http://www.certificate-transparency.org/
Usage of CTFR to Abuse Certificate Transparency Logs
|
1 2 3 |
$ python3 ctfr.py --help -d --domain [target_domain] (required) -o --output [output_file] (optional) |
Example:
|
1 |
$ python3 ctfr.py -d facebook.com -o /home/shei/subdomains_fb.txt |
This is quite a new and novel technique compared to more traditional scripts like DNSRecon – DNS Enumeration Script.
You can download CTFR here:
Or read more here.
Topic: Hacking Tools
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. […]
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 […]
Topic: Hardware Hacking