Nov 17 2014

PowerShell Encoding & Decoding (Base64)

PowerShell provides an easy method for Base64 encoding and decoding.

Encoding:

$Text = ‘This is a secret and should be hidden’
$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)
$EncodedText =[Convert]::ToBase64String($Bytes)
$EncodedText

The result is this base64 encoded text:
VABoAGkAcwAgAGkAcwAgAGEAIABzAGUAYwByAGUAdAAgAGEAbgBkACAAcwBoAG8AdQBsAGQAIABiAGUAIABoAGkAZABlAG4A

Decoding:
Decoding the base64 encoded blob using PowerShell is simple.

$EncodedText = “VABoAGkAcwAgAGkAcwAgAGEAIABzAGUAYwByAGUAdAAgAGEAbgBkACAAcwBoAG8AdQBsAGQAIABiAGUAIABoAGkAZABlAG4A”
$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))
$DecodedText

 

 

Nov 16 2014

PowerShell: Find All Users in Active Directory the Optimal Way

Today I Learned (TIL) that the best way to find all users in Active Directory via LDAP query is to search for: (samAccountType=805306368)
and NOT: (&(objectClass=user)(objectCategory=person))

Reference: http://www.selfadsi.org/extended-ad/search-user-accounts.htm

Nov 16 2014

PowerShell 101: Easy Script Timing

There are times when you want to know how long it takes for a script to run. One of the Measure-* cmdlets can be useful, but there is a simpler way to time how long it takes to run a script (or piece of code).
The StopWatch .NET method is an ideal method for script timing.

More info on using the StopWatch .Net method:
http://technet.microsoft.com/en-us/magazine/2009.03.heyscriptingguy.aspx

# START OF SCRIPT
$CurrentUserName = $env:UserName
$ScriptProcessStartTime = Get-Date
write-output “” `r
write-output “Script initialized by $CurrentUserName and started processing at $ScriptProcessStartTime `r ”
$ScriptTimer = [System.Diagnostics.Stopwatch]::StartNew()
write-output “” `r

## SCRIPT BODY

## END OF SCRIPT
$ScriptProcessEndTime = Get-Date
write-output “Script started processing at $ScriptProcessStartTime and completed at $ScriptProcessEndTime.” `r
write-host “Total Processing Time: $($ScriptTimer.Elapsed.ToString())”

 

Nov 15 2014

Owning Networks and Evading Incident Response with PowerShell

 

PowerShell provides an easy method to bypass antivirus and other protection methods:

Up until several months ago, I was a member of a penetration test team tasked with compromising data centers and evading detection. Industry standard tools such as Metasploit (an attack toolkit that includes a backdoor named Meterpreter) and Mimikatz (a password dumper) worked well, but I was a paranoid attacker and was worried that running these tools (compiled as unsigned EXE files) would get me detected.

I started to take a look at PowerShell after reading a blog post by Matt Graeber on launching Meterpreter using PowerShell. Since antivirus pays no attention to PowerShell scripts, I was able to use Meterpreter without launching a suspicious EXE and without having to worry about disabling antivirus.

I wanted to go a little further though. Instead of just loading Meterpreter, I wanted to be able to load unmanaged DLLs and EXEs (both are actually Windows PE files) without calling LoadLibrary or CreateProcess (because these APIs can be monitored by AppLocker and other similar tools).

The solution to this problem was to write my own PE loader. Instead of relying on Windows APIs (LoadLibrary, CreateProcess) to load PE files in memory, I wrote a PowerShell script Invoke-ReflectivePEInjection that roughly recreates the functionality provided by the Windows API. The benefits of Invoke-ReflectivePEInjection are over the Windows APIs are:

 

Read the rest at PowerShell Magazine

Read more about Mimikatz and Active Directory Kerberos hacking here.

 

Nov 15 2014

Active Directory Replication Overview & USN Rollback: What It Is & How It Happens

If you have experienced event id #2095, then you understand how a USN Rollback can negatively affect AD consistency.

What is a USN?

The USN (Update Sequence Number) is an Active Directory database instance counter that increments every time a single change is committed to the AD database on a Domain Controller. The USN is unique to each DC and has no correlation to a USN on another DC (and that doesn’t matter, as you will see why later on in this article).  Active Directory replication keeps track of every Domain Controller’s USN and uses this information to determine when replication is required. Active Directory has two basic types of writes to the AD database, a replicated write (where the change is performed on another DC) and an originating write (where the change is performed on the local DC). AD Replicates and leverages the information about what changes were performed on which DCs and then replicated out.

Every Domain Controller has a server object in the site container stored within the Configuration partition. This object has a child object called “NTDS Settings” which has a GUID (Globally Unique IDentifier) attribute which is replicated as part of replication metadata and used by the KCC to build the replication topology. Each DC has its own copy of the Active Directory database stored in the ntds.dit file and this unique database instance on a DC is identified with its own GUID-type identifier called the “Invocation ID”. The Invocation ID is created when the DC is promoted and only changes when the AD database is restored using a supported method or an application partition is added or removed.  The reason for this is so that when an AD database is restored to an earlier point in time, the USN is also restored to that point in time. This means that any change from the restored USN value until the original, pre-restored USN value would be ignored by other DCs pulling replication from the restored DC (since they track other DCs USNs that they replicate with and only pull updates when the destination DC’s USN increments above the last stored update value USN the DC has for it – more on this later). In order to avoid this situation, the DC’s AD database generates a new Invocation ID and stores the old Invocation ID is stored in an attribute on the server’s NTDS Settings object called retiredReplDSASignatures. In this manner, the DCs will treat a new Invocation ID as a new database and ensure it gets updates from it moving forward. You can see a DC’s Invocation ID and Server GUID by running repadmin /showrepl.
Continue reading

Nov 14 2014

Group Policy Settings Reference Guide for Windows 8.1 | 7 | Server

 

The Group Policy is an integral part of the Windows operating system, on which many a IT Pro, Beginners and Tweak enthusiasts count on to customize and enforce settings on their computers. The Group Policy Editor (Gpedit.msc) is one of the most useful tools for administering policy on Windows.

The Group Policy Editor, however is not included in every edition of Windows. For instance, in Windows 8, the Group Policy is included only with Windows 8 Pro and Enterprise Editions. While Windows 7 Ultimate, Professional and Enterprise editions have it, Windows 7 Home Premium, Home Basic and Starter Editions do not include the Group Policy Editor.

Group Policy Settings Reference Guide

Microsoft has updated and made available as a download, the complete Group Policy Settings Reference Guide for Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows Server 2003 SP2, Windows Server 2008 R2 and Windows Server 2012 R2. The download is available in the form of spreadsheets for different operating systems. So you can download the spreadsheet only for those operating system/s which you may be interested in.

Read the rest here

 

 

 

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