Netsparker's Weekly Security Roundup 2018 – Week 02
In this week's edition of our security roundup: directory listings can lead to account takeover, accessibility and security of US government websites and certification authority with AlwaysOnSSL.
Table of Content
- Directory Listings Can Lead Directly to Account Takeover
- Are US Government Websites Accessible and Secure?
- AlwaysOnSSL – A New, Free Certification Authority
Directory Listings Can Lead Directly to Account Takeover
Directory listings are one of the most frequently encountered issues in the Information Leak category. They occur when developers fail to properly configure their web servers. As with our other web security warnings, let's not underestimate this one!
This week, we examine an experiment carried out by Nishaanth Guna, a 22 year old Security Researcher who previously worked with AppKnox and Ernst & Young. Guna has blogged about a straightforward way to use Directory listings to achieve account takeover. He'd encountered one during one of his penetration tests.
He started his penetration test by enumerating the subdomains of his target domain by searching for them in the Certificate Transparency logs. He used the following short and elegant bash script to conveniently query the crt.sh website from his command line:
[nishaanthguna:~/essentials]$ curl --silent https://crt.sh/\?q\=%.domain.com | sed 's/<\/\?[^>]\+>//g' | grep -i domain.com | tail -n +9 | cut -d ">" -f2 | cut -d "<" -f1
This is the list of domains his script returned:
Guna performed a port scan of all the domains he found and noticed that one of them had port 8080 exposed. Much to his surprise the subdomain in question returned, a list of directories and files.
One of them was called mailgun-webhook.log and was used by the administrator to store the results of Mailgun's webhook requests. Webhooks are endpoints to which programs or websites can send notifications, in case a specific prerequisite is satisfied. Mailgun can send a notification to a webhook whenever the user clicks the link, when there is a spam complaint or when a user opts out of receiving further emails.
So, what's the problem?
The bad news is that this log file contains not only email addresses, but also password reset links. Guna even wrote a script in bash, that would request a password reset link and then automatically set the victim's password to 'testpassword!!'.
curl https://domain.com/mailgun-webhook.log | tee direct.txt
if grep -Fxq "reset" direct.txt
echo "[+]Found a Password Reset link"
link=$(cat direct.txt | grep -i reset | cut -d "," -f6 |
cut -d "\\" -f1 | head -n 1)
curl '$link'-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)'
--data 'password=testpassword%21%21&confirmation=testpassword%21%21' --compressed
echo "[+]Password changed to testpassword!!"
echo "[-]Reset link not found"
Our recommendation is that you turn off the Directory listing feature, and move log files that contain sensitive data out of the public directory (for the reasons illustrated in Guna's experiment).
For further information on Guna's security research, see Directory Listing to Account Takeover.
Are US Government Websites Accessible and Secure?
A report published by the Information Technology and Innovation Foundation (ITIF) in November 2017 found that 91% of websites used to access US information and services have speed and connection issues, and lacked both a user-friendly mobile interface and basic security precautions. The report was based on an examination of 4500 websites from 400 different domains, and the top 500 most popular websites were included in the research.
In March the same year, they published their research on the 300 most popular websites. The results highlighted that many government websites are slow, lack a user-friendly mobile interface, and suffer from accessibility problems and security issues.
By the time the November report was published, ITIF was able to incorporate their research into the progressions on the 300 government sites. Their findings were as follows:
- Their security investigation was based on only two criteria: DNSSEC and HTTPS implementation. They found that 71% of the sites passed SSL implementation, an increase from the 67% reported in March.
- Eighty percent of the sites were DNSSEC-enabled. This represents a decline from 90% in March.
- An index called Majestic Million is used instead of the Alexa Top list. While Alexa collects data from the Alexa Toolbar, Majestic Million (a reverse search engine) claims that their page rank estimations are based on backlinks (https://majestic.com/reports/majestic-million).
- According to the report, 70% of government sites included in the research used SSL, while 8% did not. In addition, they found also that older and insecure versions of SSLv3 were used, cryptographic attacks such as POODLE and DROWN were possible, and some sites did not use perfect forward secrecy.
For further information about this research, see Benchmarking US Government Websites.
AlwaysOnSSL – A New, Free Certification Authority
We're all familiar with Let's Encrypt, a certificate authority (CA) that provides free TLS certificates. It plays an important role in the increase of secure connections, just like a new CA called AlwaysOnSSL. AlwaysOnSSL, provided by CertCenter (who sell Symantec and DigiCert certificates) is based in Germany. They similarly offer free TLS certificates.
So, what's the difference between the two?
- At first glance, the most noticeable difference is that Let's Encrypt certifications signs certificates for a period of three months, if you use your own CSR file. AlwaysOnSSL, on the other hand, signs certificates for up to 12 months.
- Let's Encrypt does not offer options for creating certificates from a web interface. This is only possible by integrating third party services into Let's Encrypt, such as https://www.sslforfree.com/. However, with AlwaysOnSSL, you can easily create certificates from the website.
- It's important to note that there is an option to create private keys via the web UI in AlwaysOnSSL. However, in Let’s Encrypt, this process is carried out on the client side. Creating a private key on a third party service is risky. In addition, the feature that provides uploading your Certificate Signing Request (CSR) file has recently been added to the options offered by AlwaysOnSSL. Ownership is verified with a DNS Entry or file upload, methods used by other services. When choosing the DNS entry option, you have to create a TXT entry in the domain's DNS records. Once the necessary conditions are met, signing (certification) happens within minutes.