Are you using CAA records?

With the approval of ballot 187 the Certificate Authorities must check and respect the CAA records that are found in the DNS of a domain. This additional check is active since September 17, 2017. CAA stands for Certification Authority Authorization and  is a standard designed to help the owners of a domain by preventing the issuance of rogue or unauthorized SSL/TLS certificates for that domain.

Read more

PostgreSQL and SSL/TLS

Encryption of data in transfer is not only important for web servers and mail servers. You can also use SSL/TLS on database servers like PostgreSQL. This will make the usage of an SQL server on the internet a little bit more safe.

As a regular PostgreSQL user I sometimes have to lookup some settings to make PostgreSQL available over an SSL/TLS connection. Now it’s time to share some notes about this.

To allow the usage of TLS/SSL on the PostgreSQL database server, we have to edit some configuration files.

First: /etc/postgresql/9.6/main/postgresql.conf

# vim /etc/postgresql/9.6/main/postgresql.conf

Here we add the following configuration:

# - Security and Authentication -
ssl = on
ssl_ciphers = 'AES128+EECDH:AES128+EDH'
ssl_prefer_server_ciphers = on
ssl_cert_file = '/etc/postgresql/cert/cert.crt'
ssl_key_file = '/etc/postgresql/cert/private.key'
ssl_ca_file = '/etc/postgresql/cert/cacert.crt'
password_encryption = on

If you want to access the PostgreSQL server from a remote server, you also have to allow PostgreSQL to listen on the IP addresses on the network interface.

listen_addresses = '*'

Be sure that you set the right file system permissions on the certificate files.

chown postgres:postgres -R /etc/postgresql/cert
chmod -R 700 /etc/postgresql/cert
chmod -R 600 /etc/postgresql/cert/*

When you are connecting from a remote system, you also want to add an extra line in the pg_hba.conf configuration file like this:

# My custom hosts (change your IP address here)
hostssl   all        all md5

Now you can login from a remote host using SSL/TLS. Let me explain quickly how to create a user, database and a password to test the connection:

Create a PostgreSQL user:

sudo -u postgres createuser testuser

Create a PostgreSQL database:

sudo -u postgres createdb testdb

Connect to PostgreSQL, create a password and give the test user the right privileges to the database.

sudo -u postgres psql

SQL commands:

psql=# GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser ;

Now, test the connection:

sebastian@desktop:~$ psql -h --u testuser -d testdb -W
Password for usertestuser: 
psql (9.6.6)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128, compression: off)
Type "help" for help.


Here you can see that you can connect with SSL (Protocol TLSv1.2).

That’s it! Feedback is welcome!

Zone transfers in The Netherlands

There are many things told about zone transfers and why it is important to restrict the use of zone transfers. The DNS zone can contain sensitive information like DKIM keys or information about the internal infrastructure. And because of this I actually thought it was not so common anymore.

A while ago I ran into a nameserver with an insecure zone transfer (AXFR) setting. Allowing zone transfers for the whole world will also allow the bad guys extract useful information from a zone that can be used to create a map of the network infrastructure. The bad guys can use this information to plan their attacks. Then I got curious about the number of nameservers that still offer the zone transfer option today.

The scope

My plan was to check all the nameservers that are used by the .NL gTLD. For this I started with a list of 3.3 million .NL domain names. I also wanted know the nameservers of domains that are related to the .NL domain names. You can have a domain like: which has is own set of nameservers, but you can use the mail servers of your ISP onder the ISP domain: which has its own set of nameservers. So the domain is related to for the email service that you user and that can also be interesting for possible attackers. I also did this for the domains of the nameserver hosts.

All together I found a total of 5,469,224 domain names. For each domain I extracted the nameservers from the DNSwhich I tested in combination with this domain.

Harvesting information

The period I tested this was December 2017.

The results

In total I found 72,656 nameservers. In these nameservers I found 10,524 nameservers on which I could perform a zone-transfer. So 12.65 % of all checked nameservers are leaking zone information of their domains.

When we take a look at the .NL domains. From the total of 3,271,088 domains that I tested it was possible to do an AXFR on 216,953 domains thru (one of) its nameservers. That is 6.6% of all .NL domains.

Later on, I did the same tests on 1,038,148 .BE domain names from Belgium and 2,212,192 .FR domain names for France. They had a better score. From the .BE domain names, 5.2% allowed an AXFR and from the .FR domain names was this 3.0% that allowed AXFR.

Some notable situations

A big domain trading company had about 47,000 domain’s on 2 of their nameservers. I notified the company, and they secured the zone-transfers on the nameservers.

One of The Netherlands biggest ISP’s was leaking information of about 16,000 domains on one of their nameservers. They secured transfers the same day that I notified them.

There was also a well known MSP/Cloud provider leaking zones with very much interesting information of about 3700 domains on their nameservers. They noted my AXFR requests in their SOC and closed the zone transfer possibility almost the same time I notified them.

And last but not least, there is a large (and cheap) web hosting provider in The Netherlands. In their network I found 227 nameservers leaking information about 74,512 domains!!!

Distribution of domains on nameservers. Blue = hosting provider with 277 nameservers. Orange and Yellow = domain trading company. Green = large Dutch ISP. Red is “the rest”.

DNS enumeration

DNS enumeration is part of the reconnaissance phase (which is the first phase) of an attack. If you manage your own nameservers you can monitor them for AXFR requests from not trusted hosts. With this information you can be warned of a possible attack on your digital infrastructure.

If you want to check if one of your nameservers has zone transfers enabled, you can go this website and fill in your domain name:

How to secure zone transfers

Most nameservers have multiple options to secure zone transfers. The most common options are:

  • Disable zone transfers completely (us an other method to synchronize)
  • IP address filter / ACL
  • TSIG (Transaction SIGnature) that works as a shared secret
  • A combination of an IP access list and a TSIG

Choose the method that is safe and also works with your DNS infrastructure.

Follow up

I will try to contact most of the owners of the nameservers and hope they will close down zone-transfers. Maybe I run this scan again in six months and compare the results.

For our Dutch readers: Nameservers lekken gevoelige informatie .

Links to background information:

Don’t trust all SSL / TLS certificates

Earlier I did a story about CSR checkers from CA’s and their resellers. This was a nice thing to do and an eye opener for some people. I went for the certificate checkers no! I generated my own CA and self-signed certificate and checked some websites with it.

In my FakeCA root certificate and the leaf certificate on it, I set some XSS information. A simple JavaScript alert. You easily can do this with OpenSSL for example. So I setup my test site and went testing. It wasn’t very difficult to find my first vulnerable website.


Read more

Wat is SSL / TLS inspection

SSL / TLS inspection is een techniek welke al lang bestaat maar die men steeds vaker toe gaat passen. Normaal gesproken gaat het internetverkeer vanuit de werkplekken binnen een bedrijf via een firewall en/of naar een website of internetapplicatie. Nog niet heel lang geleden ging het meeste verkeer over een on-versleutelde HTTP verbinding. Dit verkeer was makkelijk te controleren en bijvoorbeeld tegen te houden als er iets schadelijks tussen zit. Tegenwoordig is een versleutelde HTTPS verbinding de norm. Doordat HTTPS verkeer versleuteld is, is het moeilijk om bijvoorbeeld virussen of malware in dit verkeer te detecteren of is er geen controle op de informatie welke verzonden word naar een derde partij. Steeds meer bedrijven zien dit als een probleem.

Normaal SSL/TLS verkeer door een firewall naar een website

Versleutelen, ontsleutelen en weer versleutelen

Om SSL / TLS inspection te kunnen toepassen is er een “Man in the Middle” nodig (MitM). Deze MitM is vaak op basis van een proxy server en vangt het versleutelde verkeer op en ontsleutelt het zodat er gekeken kan worden wat er in zit. Vervolgens gaat het weer verder naar het doel. Om dit zonder SSL/TLS foutmeldingen op de werkstations te doen binnen een netwerk, is er een interne certificate authority nodig met een eigen root certificaat. Over het algemeen zit deze functionaliteit in de firewall zelf. Het root certificaat zal op de werkstations geïnstalleerd moeten worden in de certificate stores waar nodig.

TLS / SSL verkeer via een firewall en proxy voor SSL/TLS inspection naar een website.

Welke stappen worden doorlopen?

Een gebruiker gaat vanaf een werkstation (met het interne root certificaat) naar bijvoorbeeld om een bestelling te plaatsen.

  • De gebruiker gaat in de browser naar
  • De gateway binnen het netwerk vangt dit verkeer af en stuurt dit naar een proxyserver.
  • De proxyserver vraagt onderwater bij de interne CA een certificaat aan voor welke op het interne root certificaat zal worden uitgegeven.
  • De proxyserver stuurt het verzoek op zijn beurt weer door naar de website.
  • De website geeft antwoord aan de proxy server.
  • De data in dit antwoord gaat weer door de inspectie en zal hierna doorgegeven worden aan de browser van de gebruiker.
  • Doordat het werkstation dit root certificaat vertrouwd zal de browser geen foutmelding geven en gewoon een slotje aangeven in de browser.

Welke componenten zijn nodig hiervoor?

Om SSL / TLS inspectie technisch toe te kunnen passen zijn de volgende componenten nodig in het netwerk.

  • Een proxyserver. Deze proxyserver is nodig om het verkeer te kunnen scannen op malware, virussen en documenten welke het bedrijf niet via het internet mogen verlaten.
  • Een interne certificate authority met een geldig zelf gegenereerd (self signed) root certificaat welke geïnstalleerd zal moeten worden op de computers en andere apparaten.
  • Een firewall welke bijvoorbeeld het https verkeer transparant doorstuurt naar de proxyserver, of instellingen in de browsers binnen het netwerk waarin staat dat de proxyserver gebruikt moet worden.

Wat zijn de voor en nadelen?

Natuurlijk zitten er aan voor en nadelen aan deze oplossing vast welke niet alleen van technische aard zijn maar ook organisatorisch. Hoe zal er worden omgegaan met de privacy van de gebruikers?

Waarom doen?

  1. Application Control. Toegang tot bijvoorbeeld cloud applicaties als Dropbox of OneDrive kan beperkt worden.
  2. Intrusion Detection / Protection. Doordat het verkeer te analyseren is kunnen intruders makkelijker gevonden worden.
  3. Antivirus en antimalware. Verkeer is door deze techniek te scannen op virussen en malware waardoor deze bij de ingang van het bedrijf al te stoppen zijn.
  4. Filteren. Het internetverkeer is te filteren op websites en diensten welke niet zijn toegestaan te bezoeken of te gebruiken binnen het bedrijf.
  5. Data Loss Prevention. Omdat de bestanden die verstuurd worden via het internet nu te lezen zijn, is het mogelijk om bepaalde bestanden tegen te houden, of bij te houden welke medewerker wat naar wie verstuurt. Dit onderwerp is de laatste tijd een hot-issue! Niemand wil natuurlijk dat er data vanuit het bedrijf uitlekt naar buiten toe aan partijen die hier schade mee kunnen aanrichten of waarbij bijvoorbeeld persoonsgegevens gelekt worden.

Waarom niet doen?

  1. Privacy problemen. Ja, ook werknemers hebben recht op hun privacy. Maar hierdoor dus goede afspraken en leg deze vast in het internet protocol van uw bedrijf.
  2. Technieken die de MitM tegenhouden kunnen voor problemen zorgen. Zorg ervoor dat de websites en applicaties die deze technieken gebruiken wel bezocht kunnen worden door uitzonderingsregels te te passen.
  3. Public Key Pinning, een techniek die nog niet heel erg ver doorgevoerd is, en eigenlijk ook weer op zijn retour is door de risico’s die eraan vastzitten. De browsers met HPKP ondersteuning zullen een foutmelding geven bij het bezoeken van deze websites. Deze kunnen dus ook op de lijst van uitzonderingen toegevoegd worden.
  4. Het afzwakken van de SSL / TLS implementaties. Oudere firewalls met de mogelijkheid voor SSL/TLS inspection dwingen soms een lagere TLS standaard af dan dat de website aanbied. Als een website TLS 1.0 tot en met 1.2 aanbiedt, maar de firewall eigenlijk alleen maar TLS 1.0 ondersteunt, is de beveiliging van deze website dus eigenlijk afgezwakt. Het is daarom belangrijk om dit goed in te stellen en te voorkomen. Ook is er geen verschil te zien tussen een domain validated en een extended validated certificaat.
  5. Omgaan met verlopen of ingetrokken certificaten van de website. Hoe gaat SSL/TLS inspection daarmee om? Omdat de certificaten door de interne CA worden gegenereerd en uitgegeven zullen deze gewoon geldig zijn volgens de browser. Wat nou als een bezoeker een website bezoekt waarvan het certificaat verlopen of ingetrokken is? Stel dit goed in zodat hier geen problemen door kunnen komen.

Zo zijn er nog veel meer redenen om wel of geen SSL/TLS inspection toe te passen is. Indien deze techniek wel toegepast zullen gaan worden binnen het bedrijf, zorg er voor dat niet al het verkeer door de SSL/TLS inspection heen hoeft te gaan door uitzonderingen op de regel toe te staan. Denk aan websites en applicaties van overheden, financiële of medische instellingen. Data van en naar onder andere deze instellingen moeten altijd zo veilig mogelijk verstuurd worden.


Natuurlijk is SSL / TLS inspection ook andersom in te zetten. Denk aan een reverce proxy of een web application firewall. Deze vangen ook het SSL/TLS verkeer af bij binnenkomst waarna deze onversleuteld geïnspecteerd kan worden om zo zaken als SQL-injections of Cross-Site scripting te detecteren en te blokkeren.

Waar zijn deze technieken te vinden?

Tegenwoordig zijn deze technieken terug te vinden in de modernere firewall’s. Vaak maken ze je het ook gemakkelijk door veel instellingen vooraf al goed te zetten. Denk aan firewall’s van bijvoorbeeld Fortinet, CheckPoint en SonicWall, ze kunnen het over het algemeen allemaal. Vaak hebben ze ook de optie om als web application firewall te dienen. Leveranciers als Barracuda, Qualys, Symantec (met Blue Coat) en CloudFlare hebben specifieke web application firewall oplossingen.

Hou er rekening mee dat het helaas ook wel eens mis kan gaan:

Maar kijk naar alle SSL vulnerabilities van de afgelopen tijd, die zijn ook niet mis.

AXFR can leak sensitive information

Many services are depending on DNS and it is getting more and more used for serving information. Sometime’s companies are putting some inside information in their DNS that others do not need to know.

Maybe the information that is in the DNS looks innocent,  but if you are a target for criminal hackers, or state sponsored hackers, the can get very much information from your nameserver. That is why we advice to disable AXFR for the whole world. If you have AXFR enabled, you can leak information of you digital infrastructure that can be used by criminals to get a more complete overview of your company.

I do not know if it’s “by design”, but the fourth nameserver of DNS provider is accepting AXFR commands. I asked them multiple times if why this is open for everyone, but the do not respond to my e-mail.

With a simple dig command, we can get the whole DNS zone of EasyDNS, or one of it’s customers.


sebastian@nw4allws01:~$ dig @ -t AXFR;
<<>> DiG 9.10.3-P4-Ubuntu <<>> @ -t AXFR;
(1 server found)
;; global options: 300 IN SOA 1509041294 3600 600 1209600 300 300 IN NS 300 IN NS 300 IN NS 300 IN NS 300 IN MX 0 300 IN A 300 IN TXT "google-site-verification=9lCtJVFGHp_WlDRhU9LpYB84rGYjlh-SMjxGUgpP6Eg"
... snip...

Look at the domains and It is not very pretty. Certum is also a CA (certificate authority), so they do need to keep their infrastructure safe!

dig @ -t AXFR
dig @ -t AXFR

Screenshot from 2017-11-10 13-01-52

Background information:

Update: They fixed it 10 minutes after sharing.




WiFi for free! Is it?

People love free WiFi, and that comes with a cost. If you look around many people using their laptops and tablets in the coffee shops, in dinings and restaurants. You will find a MacDonalds ie Starbucks in every city.

Would it be awesome to take advantage of that? Back in the days you build a custom BackTrack, Kali or other Linux distribution with your custom WiFi access point toolkit. You also had to find the right WiFi USB stick with the right functionality.

Now days, you buy a WiFi Pineapple and you are ready to go. I bought my first WiFi Pineapple years ago to give some demonstrations about how easy it is to set up a trap for the innocent free WiFi users.

A few weeks ago they ordered for me the WiFi Pineapple NANO tactical kit. I was surprised to see how Hak5 did some good work on the hard and software. They really made it easy to dig in WiFi networks on the go. I also like the redesigned webinterface. It is clean and simple.

Summarizing this story, the WiFi Pineapple is still a great tool for recon, attacks and also site surveys. Beside the Pineapple, I’ll keep using my Raspberry Pi’s and and “old” Intel NUC to get some more possibilities. I’ll write about that later.