Numerous Swiss domain names temporarily hijacked

Last Friday at around 14:05 we noticed that our website (www.scrt.ch) along with some other services we use internally were no longer accessible. We immediately tried to figure out why that was and quickly noticed that our DNS requests were not returning the correct IP addresses.

As these responses were not only returned by our DNS server, but all servers globally, we had a short moment of anguish where we wondered whether we had forgotten to renew our domain name or if our account at our registrar had been hacked!

Thankfully none of these had happened as we observed that the DNS configuration at the registrar and in our name servers was not altered. So at 14:17 we contacted nic.ch to ask them whether they could tell us any more about what had happened. They informed us that they had received a change request from our registrar (Gandi) and that we should check with them. Following further discussion with them, they found that similar changes had been requested for 94 .ch and .li domain names.

We then contacted Gandi directly who told us that 751 of their domain names had been hijacked and they subsequently started to rollback the changes. By 15:05, everything was back in order, though we still haven’t received any news as to what made all of this possible in the first place.

Here’s some background information on the DNS protocol to better understand what happened.DNS resolution

Each time a web site or any resource is accessed using a fully qualified domain name such as www.scrt.ch, the DNS resolution process is run to obtain the IP address of the target system. DNS lookup walks through a hierarchical DNS structure which, abstracting any cache mechanism, works in the following manner:

  1. The client (eg a web browser, a mail gateway, a web proxy) queries its DNS resolver. In our case, the resolver is queried for the record www.scrt.ch. The resolver will then handle the resolution (recursive query) on behalf of the client.
  2. First, It will query one of the root DNS servers serving the internet globally. The root DNS server will consider the Top Level Domain (TLD), which in this example is .ch, and will provide the resolver with the IP address of the name server in charge of this TLD which for .ch is nic.ch (Switch).
  3. Then the resolver will query the name server at nic.ch which will in turn provide the resolver with the IP address of the name servers responsible for scrt.ch.
  4. Finally, the resolver will query the name server authoritative for scrt.ch and will get the IP address matching the record www.scrt.ch.

DNS configuration

As a domain owner, you must first use a registrar to register your domain name, which will handle most administrative tasks for you. The main information the registrar owns which is important for this discussion is the authoritative name servers for your domain.

The registrar will typically propagate this information through the DNS global infrastructure, which basically means informing the TLD registry about the IP addresses of the authoritative name server for your domain.

Here we are

The domain scrt.ch is registered at Gandi where we configure the IP addresses of our name servers. Gandi is responsible for propagating this information to nic.ch, enabling the resolution for our domain scrt.ch globally.

The attack

Last Friday, an attacker was able to compromise a technical provider used by Gandi to communicate with various TLD registries. This compromise allowed him to request changes to registries, including nic.ch, to modify the name server information for several domains, including ours.

At this point, a rogue DNS server was introduced in the DNS resolution path. Looking at the DNS resolution process described above, the hijack happened in step 3 where nic.ch was providing the rogue DNS server instead of the valid one to any resolver, allowing the attacker to redirect any requests for impacted domains to IP addresses owned by the attacker himself.

Gandi’s incident notification can be found here.

On our end, the impacts this attack had were:

  1. For an hour, the www.scrt.ch website was redirected to another host serving up an exploit kit that would try to infect vulnerable browsers. However, if you had visited our site previously, you would not have been affected as HTTP Strict-Transport-Security would have forced your browser to use a valid HTTPS which the attacker could not emulate, therefore resulting in a connection error. The only case where you might have been at risk is if you had never visited our site previously and you had an outdated vulnerable browser (and/or browser plugin), though if this is the case, attackers would probably not wait for you to visit our website to compromise you.
    If you want to check for the occurrence of a connection from one of your systems to the malicious web server, you can look for connections to the following IPs: 46.183.219.205, 46.183.219.206, 46.183.219.227.
  2. During the attack, all emails sent to scrt.ch addresses were not delivered to our server but to a foreign mail server which, according to tests performed during the attack, was not configured to accept emails for our domain. While it doesn’t seem to have been the objective here, this type of attack could potentially be used to read incoming emails while the name servers are poisoned.

In our case, we have always treated emails as inherently insecure and make sure to use other channels and encryption to transfer sensitive information.

Despite the fact that this incident was entirely out of our control, we will be taking steps to further reduce the impact such an attack could have in the future and of course recommend these to all of you reading this, as such attacks can happen to anyone:

  • Preload Strict-Transport-Security into browsers for our website in order to protect even first-time visitors.
  • Monitor DNS resolution by not only querying authoritative name servers directly but by crawling the full hierarchy.
  • Discuss with nic.ch whether detection of such events could be improved. Having over 90 domains owned by different entities changed at the same time to point to a single name server is really suspicious.
  • Implement DNSSEC. While in this case the attacker could have been able to either suppress or update the DS record in the TLD zone, the cache mechanism would have mitigated the attack until DS record TTL’s expiration, as confirmed by a discussion with SWITCH-CERT.

For reference, blog posts of Gandi and SWITCH-CERT

A pentester’s take on (Not)Petya

By now, everybody has probably read many articles on the latest viral outbreak, ranging from detailed analysis of the virus itself to rants about why companies don’t apply updates in a timely fashion and why employees continue to open malicious attachments in emails.

In this post, I thought I’d take a step back and look at some of the virus’ features that make it interesting from my perspective as a penetration tester, as it mimics some of the attacks we use on a weekly basis during our penetration tests. It also highlights the importance of some of the recommendations we provide that are often overlooked because the threat is rarely fully understood.

Some of the details are still a little blurry, but one of the initial infection vectors seems to have been the update mechanism of a software used by many companies in Ukraine. This is far from the classic phishing attacks where everybody can blame the end user for the infection. And despite the fact that this new attack also uses the EternalBlue exploit to propagate internally, it is most likely not the entry point into any company, in part due to the recent WannaCry ransomware which urged companies to finally apply the appropriate updates. For once we can’t just blame missing updates and irresponsible employees!

The second interesting part of this particular malware is the fact that it leverages mimikatz-like functionality to steal passwords and re-use them to infect other machines using PsExec or WMIC. This is very similar to what is performed during targeted attacks or penetration tests. After compromising an initial host, the attacker moves laterally through the network with any compromised credentials in order to take control of as many other hosts until the desired sensitive data is compromised. Obviously, the more privileged the credentials that were initially compromised are, the easier it will be for the attacker to gain access to other hosts. In the case of the current outbreak, given the fact that there seems to be no recovery possibility, and on top of this your backups happen to be accessible on the network, you will lose everything.

If at any point during an attack a domain administrator account (or similarly privileged account) is compromised, it is pretty much game over for the company, as the attacker has essentially compromised the whole company, and recovering from this is an extremely painful process. Some people will say that their most sensitive applications and data are not located on Windows servers and therefore not impacted by this, but in all likelihood, the legitimate employees who have access to the data do it from a Windows workstation. An attacker could therefore profit from this legitimate access to compromise the “secure” data as well.

Given the Ukrainian connection to the infection vector, the impact in Switzerland will probably be relatively low, but it is not unreasonable to believe that a similar attack could be performed against software that is regularly used within this country too. I can certainly think of a number of banking software that are used by a majority of Swiss companies that might be an interesting target. It gets worse if you think about Adobe, Java or even Windows (anybody remember Flame?).

So what can we do to reduce the risk of this happening in the future?

The answer in my eyes lies within two of the fundamentals of information security that are unfortunately very rarely implemented correctly:

  • Network segmentation & filtering
  • Least privileges

Network segmentation is generally pretty well understood and most companies have dedicated VLANs for various types of devices, but too often there is no firewalling performed between the different networks, making it all too easy to move around laterally or exploit vulnerabilities in obscure protocols that run on exotic ports that could very easily be blocked.

On top of a network firewall, we often recommend the use of Windows’ integrated firewall to block off SMB and RDP ports to avoid lateral movement within the same subnet. Typically these ports should be accessed only by a restricted team to manage the workstations or for support purposes. These rules can for example be deployed by GPOs.

If these rules had been deployed in the case of the current outbreak, if an initial host was compromised, the attack would be contained to that machine, as it couldn’t use PsExec, WMIC or EternalBlue to replicate, therefore drastically reducing its impact.

Nowadays, every company has one or several firewalls, but are unfortunately rarely used to their full potential. They can be used for a lot more than just routing traffic from one subnet to another. It takes a little time to set them up correctly to allow only authorised, necessary traffic, but this remains one of the best preventive measures against virus outbreaks and attacks.

For the second aspect of “least privileges”, I have very rarely encountered a company that truly performs this well at all levels, and I will group several different weaknesses that we see in pretty much every penetration test we perform:

  1. Use of excessive privileges by services
  2. Use of the same local administrator password on multiple hosts
  3. Excessive use of domain administrator (or other privileged) accounts

Before delving into why these issues are so important, I have to mention that access to a Windows workstation or server can be granted to either local users that are defined on the host itself, or domain users (as long as the machine is part of a domain) that are defined in the Active Directory.

It is also important to understand that apart from in certain circumstances, a user with local administrator privileges can use tools such as mimikatz to recover not only the NTLM password of all locally defined accounts, but also the plain-text password (or some times only NTLM hash) of any domain account authenticated to the host. Given that the NTLM hash can essentially be used as a password thanks to pass-the-hash techniques, all local accounts and any connected domain accounts can be completely compromised by a local administrator.

This should illustrate quite well why the three weaknesses above are so important.

  1. Any compromised service that is running with local administrator (SYSTEM) privileges will give the attacker the possibility of compromising all the local and connected domain accounts. Some of the services that we exploit the most that are nearly always affected by this are Tomcat, JBoss and SQL Server.
  2. If a local administrator account is compromised and that the same password is used on other hosts, an attacker can very easily use pass-the-hash attacks to compromise all of these other servers. Essentially, by using the same password on multiple machines, you’re transforming a local administrator account into a “global” administrator account. Microsoft has published a tool called LAPS which makes it pretty easy to manage a separate password for all domain-connected Windows machines, though it is also possible to simply disable the account all together.
  3. “Domain admin” accounts should only ever be used to connect to a domain controller and as sparingly as possible. They should never be used in day-to-day administration tasks. As was explained above, any time you connect to a server or workstation that has previously been compromised by an attacker, you are gifting him your account and privileges. It is therefore pretty obvious that privileged accounts should be used as sparingly as possible to avoid this scenario. We’ll often recommend segmenting the Active Directory into various groups granting access to only a limited subset of the company’s servers or workstation to reduce the impact the compromise of such an account can have.

It is well understood nowadays that it is not a question of “if” an attacker or virus gets in, but “when”. This does not mean that securing your perimeter is pointless, but it means that you have to prepare for a breach and do your best to reduce its impact.

So I’ll wrap this up with the following recommendations that cover the points mentioned above and that we give in most of our penetration tests:

  • Use your firewalls for what they were designed for and filter access between your various subnets
  • Use Window’s built-in firewall to restrict access to management ports
  • Use LAPS or a similar password management system to avoid having the same password on multiple systems
  • Disable local administrator accounts if you don’t actually use them
  • Avoid running services with local admin privileges when it is not required
  • Make sure your day-to-day accounts do not have admin privileges, and have separate accounts for administrative tasks. (It seems obvious, but given recent pentest results, it’s worth mentioning that the passwords for these accounts should be different…)
  • Put your privileged accounts in the “Protected Users” group to avoid credentials theft
  • Only use your domain admin accounts on domain controllers, and use them as sparingly as possible
  • Make sure your backups are stored securely and that they are recoverable even in the case of a complete domain compromise

Often in the past it has been difficult to promote security within a company because it has always been hard to establish the business impact of a breach, but by reading the current news, you’ll see many companies crippled by the fact they have lost control of all their Windows machines, and maybe in some cases their backups. I’ll let you imagine the consequences that could have in your company.

Heap Overflow Vulnerability in Citrix NetScaler Gateway (CVE-2017-7219)

After presenting my findings on the Swisscom router at the CybSecConference last year, I started looking for a new product to analyze. I quickly found that it’s possible to download virtual “demo” appliances of Citrix products, so I went on to download a Netscaler VPX, which at the time was at version 11.10 (b50.10). The goal as always was to discover a way to compromise the device remotely, which is what led me to discover a heap overflow vulnerability which allows an authenticated user to compromise the device with root privileges. During the research, I (un)fortunately wasn’t able to find a way to exploit the flaw without credentials.

======================
TL;DR;
======================

A heap overflow in the “ping” functionality allows an authenticated VPN user to trigger a use-after-free condition in order to execute arbitrary commands on the appliance. (CVE-2017-7219)

The following Metasploit module can be used to exploit the vulnerability (use at your own risk…), though it will probably only function against the version that was analyzed.

======================
DETAILS
======================

As mentioned above, I began by downloading the virtual appliance and started it up on my machine. Since I’ve never used or configured a Netscaler appliance in the past, it took a while to get things going and configuring it in some kind of standard mode.

Once the appliance is started, it is possible to log into the console with the standard nsroot account. This gives access to a “limited” shell, but Citrix were nice enough to add a shell command which gives root access to the box, so I used this to extract the filesystem and analyze what was going on.

Going through the various files on the system, I found one that seemed promising which was named /netscaler/nsvpnd. As it’s name hints at, it is used to handle requests sent to the VPN web interface. Though only authenticated requests seem to get here, as authentication itself is performed by another binary on the system.

One of the requests that is performed by the nsvpnd binary is the ping request.

This results in the following HTTP request:

POST /cvpn/aHR0cDovLzEyNy4wLjAuMQ/fs/ping HTTP/1.1
Host: 
[...]
Cookie: NSC_AAAC=b2f85f0b72ef21c82eac5ac4d314a4170af182cd945525d5f4f58455e445a4a42; NSC_FSSO=0
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 41


host=127.0.0.1&nsc_nonce=kPIueluG6ubF37J0

Apparently the /cvpn/aHR0cDovLzEyNy4wLjAuMQ part of the URL is not actually required, so it can safely be removed. In any case, this request is eventually handled by one of two vulnerable functions that contain an unbounded strcpy with our host parameter, as shown below.

This is where the overflow happens, though we are not overwriting a stack variable, but one of the members of a struct, which is expected to be at most 256 bytes long. Our parameter on the other hand can go up to 512 bytes, which is what allows us to overflow this buffer.

So it is possible to write up to 256 bytes after the host member of the structure, therefore overwriting any other members of the structure after the host, which is where things get interesting. One of the following members is actually a pointer to another structure (a parameter list) on the heap which was previously allocated and eventually gets free‘d by the application when the request has completely been processed.  This means we can essentially free an arbitrary memory location.

Before going any further, a quick analysis of the system and binary show that FreeBSD uses jemalloc instead of dlmalloc, the heap is not executable, but the stack is, and ASLR is not enabled (this was 2016 after all). Another thing that was helpful in exploiting this particular issue is that all requests to the web interface are handled by one single process, which means we can actually interact many times with the process by sending multiple HTTP requests if required.

At this point, my idea to gain code execution was the following:

  1. Find a function pointer somewhere in the application, as well as the size that was used to allocate that memory
  2. Free the memory address of this function pointer
  3. On the next malloc of the appropriate size, the same address should be returned
  4. Overwrite the function pointer with user-controlled data (a pointer to my shellcode) when it is copied to this memory address
  5. Trigger the function pointer to call my shellcode

The only remaining problem is getting a shellcode to some predictable location. Thankfully, as mentioned earlier, ASLR is disabled, the stack is executable and the value we send in our host parameter is actually stored on the stack! All we need is to get this address and plug it into the function pointer to get the shellcode to execute. Obviously, despite ASLR being disabled, the stack will not always be exactly at the same place, so I used a super-l33t technique consisting of pre-pending my shellcode with lots of NOPs (because 2016).

So we can now break down each step and look at how we can achieve them:

  1. With some reverse engineering and debugging, I found one function pointer that was always allocated at address 0x2840a0c0. This function seems to be used to decode parameters sent in the HTTP requests. The memory address is initially allocated at 0x08097fb9 with a call to malloc(32).
  2. Use the overflow to overwrite the pointer to the parameter list with 0x2840a0c0. The address is then free‘d when the request has finished being processed. Here, we also need to take a note of where our host parameter is located on the stack, as this is where we will store our shellcode.
  3. While searching through the binary’s code, I found one place where a malloc is called with a length which can be specified by the VPN user directly. This is when providing the username and password to log into a SMB server. There may be other parts of the code that could be exploited in a more reliable manner, but this is the first I found and decided to go with it. The only problem is that it means we need to initiate a SMB login to a server that is accessible to the Netscaler appliance.
  4. As long as our password is between 16 and 32 characters, the previously free‘d address is returned and we can therefore overwrite the function pointer with the value of our password. It must therefore be the address of our shellcode, which we discovered was placed on the stack when performing the ping.
  5. The function pointer is actually called at regular intervals by the application while processing data, so we can just wait until it is called to get our code executed.

As you’ve probably deduced by now, in order to exploit the vulnerability, we are going to use two separate HTTP requests. The first one is used to put the shellcode on the stack and trigger the overflow, while the second is used to overwrite the function pointer with the address of our shellcode and actually execute our payload. This is summarised here:

Request 1 (ping host)

→ Start of host value contains shellcode which is conveniently placed on the stack

→ Use overflow to overwrite pointer to parameter list with 0x2840a0c0

→ When the request has been entirely processed, the program frees the address 0x2840a0c0

Request 2 (smb login)

→ Specify a password parameter of length between 16 and 32, this forces malloc to return the address that was previously freed.

→ Password value (shellcode location) overwrites function pointer that was previously located there

→ While processing the request, the overwritten function pointer is called, executing the shellcode

So that’s pretty much it. The following MSF module, should be able to exploit the flaw, but use it at your own risk. I’ve only tested it on a controlled lab environment.

For those of you who participated in our Insomni’hack teaser this year, you’ll notice many similarities with “The Great Escape – part 2” challenge, as it was very much inspired by this flaw.

======================
TIMELINE
======================

  • 08.12.2016: Initial report sent to Citrix
  • 09.12.2016: Case opened by Citrix to investigate the issue
  • 14.12.2016: Vulnerability acknowledged and reproduced by Citrix team
  • February-March 2017: Rollout of fixed Netscaler versions
  • 12.04.2017: Release of security bulletin: https://support.citrix.com/article/CTX222657

 

SCRT is proud to announce the opening of its new office in Bern

To sustain its growth and continue to maintain relations of proximity with its customers and partners, SCRT is glad to announce the opening of its new office in Bern.

SCRT is one of the leaders in Information Security in Switzerland, with headquarters in Préverenges (Vaud) and a branch office in Bordeaux (France). This new SCRT location will facilitate the provision of professional IT Security Services to new and existing clients in the German speaking part of Switzerland.

Ideally located in the Monbijou district, close to the train station, this office offers a dynamic, welcoming and optimal setting for our customers and staff. SCRT will continue to offer the same services at our new address in Bern and ensure our well known proximity and reactivity all over Switzerland.

We look forward to welcoming you!

SecureIT – Valais

Voici les slides de ma présentation de Vendredi dernier pour Secure-IT. J’y ai présenté quelques-unes des techniques les plus communément exploitées en test d’intrusion pour compromettre un domaine Windows ainsi que les différentes remédiations possibles.

Pour ceux qui n’auraient pas le temps de parcourir la totalité des slides, voici un bref résumé des recommendations:

  • Désactiver WPAD et les protocoles de résolutions de noms LLMNR et NetBios
  • Utiliser un système come LAPS pour gérer les mots de passe des administrateurs locaux
  • Limiter l’utilisation des comptes privilégiés (surtout les “admins du domaine”)
  • Utiliser AppLocker pour empêcher l’exécution de programmes non autorisés
  • Améliorer le filtrage réseau entre les VLANs internes et même au sein du même VLAN (Firewall local)
  • Limiter les privilèges utilisés par les applications (notamment Tomcat et serveurs SQL)
  • Utiliser un système de corrélation de logs pour pouvoir détecter les anomalies sur le réseau

L’utilisation de tests d’intrusion de type “Red Team” ou “Purple Team” permet ensuite de valider la pertinence des logs et des alertes remontées, ceci dans le but d’accélérer la réponse à incident pour pouvoir palier à une réelle attaque.