Aggregator

Interest continues to build around pass-the-hash and related credential artifact attacks, like those made easy by Mimikatz. The main focus surrounding this subject has been hardening Windows against credential attacks, cleaning up artifacts left behind, or at least detecting PtH and related attacks when they occur.

All of this is important – especially because end-users must logon to end-user workstations, which are the most vulnerable systems on the network.

Privileged admin accounts are another story. Even if you eliminated pass-the-hash, golden ticket, and other credential artifact attacks, you would remain vulnerable whenever admin accounts logon to insecure endpoints.  Keystroke logging, or simply starting a process under the current user’s credentials, are viable methods for stealing or hijacking the credentials of a locally logged-on user.

So, the big lessons learned with Mimikatz and privileged accounts are to avoid using privileged credentials on lower security systems, such as any system in which web browsing or email occurs, or any type of file or content is downloaded from the internet. That’s really what ESAE (aka Red Forest) is all about. But privileged accounts aren’t limited to just the domain admin accounts contemplated by the Red Forest. There’s many other privileged accounts for member servers, applications, databases, devices, and so on.

Privileged accounts should only be used from dedicated administrative workstations maintained at the same level of security as the resources being administered.

How do you implement controls that really enforce this kind of written policy? And how do you detect attempts to circumvent?

When it comes to Windows, you have a few options:

• Logon rights defined at the local system
• Workstation restrictions defined on the domain account
• Authentication silos

I’ll briefly explain each one and show how you can monitor attempts to violate the policies.

Logon Rights

There’s five logon types and corresponding “allow and deny rights” for each, with “deny” overriding “allow”, of course. You define these in group policy and they are enforced by the local systems in which the group policy objects are applied. For instance, if you have an OU for end-user Workstations and you assign “deny logon locally” to an AD admin group, those members won’t be able to logon at the console of workstations regardless of their authority.

If someone tries to violate a “deny logon” right you can catch this by looking for event ID 4625 – an account failed to logon with status or sub-status code 0xc000015b. But be aware that these events are logged via the local workstation – not on the domain controller. This is another reason to use native Windows Event Collection to get events from your workstations.

Workstation Restrictions

This is something you’d have to specify on individual user accounts as shown below in Active Directory User and Computers. This control only applies to interactive logons.

In this example, I’ve allowed Tamas to logon only at SAW1 (secure admin workstation 1). Depending on how many SAWs and admins you have, this could be tedious. If Tamas tried to logon at a different workstation, that computer would log event ID 4625 – an account failed to logon with status or sub-status code 0xC0000070. The domain controller would log event ID 4769 with failure code 0xC.

Authentication Silos

This is a new feature of AD that allows you to carve out groups of computers and users, and limit those users to those computers – centrally from AD Authentication policy silos, which are containers you can assign user accounts, computer accounts, and service accounts to. You can then assign authentication policies for this container to limit where privileged accounts can be used in the domain. When accounts are in the Protected Users security group, additional controls are applied, such as the exclusive use of the Kerberos protocol. With these capabilities, you can limit high-value account usage to high-value hosts. Learn more about silos in Implementing Win 2012 R2 Authentication Silos and the Protected Users Group to Protect Privileged Accounts from Modern Attacks.

When a user tries to logon outside the silo of permitted computers, the domain controller will log event ID 4820: A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions.

Bad guys have more methods and shrink-wrapped tools than ever to steal credentials, so it’s especially important to lock down privileged accounts and prevent artifacts of their credentials from being littered throughout your network where the bad guys can find them. Windows gives you controls for enforcing such policies and provides an audit trail when someone attempts to violate them. Remember that besides just non-compliant or forgetful admins, these events may signal a bad guy who’s successfully stolen privileged credentials but is unaware of the controls you’ve put in place. So, take these events seriously.

“This article by Randy Smith was originally published by EventTracker” https://www.eventtracker.com/newsletters/experimenting-windows-security-controls-enforcing-policies/

Verisign just released its Q4 2017 DDoS Trends Report, which represents a unique view into the attack trends unfolding online, through observations and insights derived from distributed denial of service (DDoS) attack mitigations enacted on behalf of Verisign DDoS Protection Services and security research conducted by Verisign Security Services. Verisign saw that 46 percent of attacks in Q4 […]

The post Q4 2017 DDoS Trends Report: Financial Sector Experienced 40 Percent of Attacks appeared first on Verisign Blog.

We reported an overflow vulnerability in the base64 decode function of Exim on 5 February, 2018, identified as CVE-2018-6789. This bug exists since the first commit of exim, hence ALL versions are affected. According to our research, it can be leveraged to gain Pre-auth Remote Code Execution and at least 400k servers are at risk. Patched version 4.90.1 is already released and we suggest to upgrade exim immediately.

• All Exim versions below 4.90.1

This is a calculation mistake of decode buffer length in b64decode function: base64.c: 153 b64decode

As shown above, exim allocates a buffer of 3*(len/4)+1 bytes to store decoded base64 data. However, when the input is not a valid base64 string and the length is 4n+3, exim allocates 3n+1 but consumes 3n+2 bytes while decoding. This causes one byte heap overflow (aka off-by-one). Generally, this bug is harmless because the memory overwritten is usually unused. However, this byte overwrites some critical data when the string fits some specific length. In addition, this byte is controllable, which makes exploitation more feasible. Base64 decoding is such a fundamental function and therefore this bug can be triggered easily, causing remote code execution.

To estimate the severity of this bug, we developed an exploit targeting SMTP daemon of exim. The exploitation mechanism used to achieve pre-auth remote code execution is described in the following paragraphs. In order to leverage this one byte overflow, it is necessary to trick memory management mechanism. It is highly recommended to have basic knowledge of heap exploitation [ref] before reading this section.

We developed the exploit with:

• Debian(stretch) and Ubuntu(zesty)
• SMTP daemon of Exim4 package installed with apt-get (4.89/4.88)
• Config enabled (uncommented in default config) CRAM-MD5 authenticator (any other authenticator using base64 also works)
• Basic SMTP commands (EHLO, MAIL FROM/RCPT TO) and AUTH

First, we review the source code and search for useful memory allocation. As we mentioned in the previous article, exim uses self-defined functions for dynamic allocation:

Function store_free() and store_malloc() calls malloc() and free() of glibc directly. Glibc takes a slightly bigger (0x10 bytes) chunk and stores its metadata in the first 0x10 bytes (x86-64) on every allocation, and then returns the location of data. The following illustration describes structure of chunk:

Metadata includes size of previous chunk (the one exactly above in memory), size of current block and some flags. The first three bits of size are used to store flags. In this example, size of 0x81 implies current chunk is 0x80 bytes and the previous chunk is in use. Most of released chunks used in exim are put into a doubly linked list called unsorted bin. Glibc maintains it according to the flags, and merges adjacent released chunks into a bigger chunk to avoid fragmentation. For every allocation request, glibc checks these chunks in an FIFO (first in, first-out) order and reuses the chunks.

For some performance issues, exim maintains its own linked list structure with store_get(), store_release(), store_extend() and store_reset(). The main feature of storeblocks is that every block is at least 0x2000 bytes, which becomes a restriction to our exploitation. Note that a storeblock is also the data of a chunk. Therefore, if we look into the memory, it is like:

Here we list functions used to arrange heap data:

• EHLO hostname For each EHLO(or HELO) command, exim stores the pointer of hostname in sender_host_name.
  • store_free() old name
  • store_malloc() for new name

  smtp_in.c: 1833 check_helo

  1839 /* Discard any previous helo name */ 1840 1841 if (sender_helo_name != NULL) 1842 { 1843 store_free(sender_helo_name); 1844 sender_helo_name = NULL; 1845 } ... 1884 if (yield) sender_helo_name = string_copy_malloc(start); 1885 return yield;
• Unrecognized command For every unrecognized command with unprintable characters, exim allocates a buffer to convert it to printable
  • store_get() to store error message

  smtp_in.c: 5725 smtp_setup_msg

  5725 done = synprot_error(L_smtp_syntax_error, 500, NULL, 5726 US"unrecognized command");
• AUTH In most authentication procedure, exim uses base64 encoding to communicate with client. The encode and decode string are stored in a buffer allocated by store_get().
  • store_get() for strings
  • can contain unprintable characters, NULL bytes
  • not necessarily null terminated
• Reset in EHLO/HELO, MAIL, RCPT When a command is done correctly, smtp_reset() is called. This function calls store_reset() to reset block chain to a reset point, which means all storeblocks allocated by store_get() after last command are released.
  • store_reset() to reset point (set at the beginning of function)
  • release blocks added at a time

  smtp_in.c: 3771 smtp_setup_msg

  3771 int 3772 smtp_setup_msg(void) 3773 { 3774 int done = 0; 3775 BOOL toomany = FALSE; 3776 BOOL discarded = FALSE; 3777 BOOL last_was_rej_mail = FALSE; 3778 BOOL last_was_rcpt = FALSE; 3779 void *reset_point = store_get(0); 3780 3781 DEBUG(D_receive) debug_printf("smtp_setup_msg entered\n"); 3782 3783 /* Reset for start of new message. We allow one RSET not to be counted as a 3784 nonmail command, for those MTAs that insist on sending it between every 3785 message. Ditto for EHLO/HELO and for STARTTLS, to allow for going in and out of 3786 TLS between messages (an Exim client may do this if it has messages queued up 3787 for the host). Note: we do NOT reset AUTH at this point. */ 3788 3789 smtp_reset(reset_point);

To leverage this off-by-one, the chunk beneath decoded base64 data should be freed easily and controllable. After several attempts, we found that sender_host_name is a better choice. We arrange the heap layout to leave a freed chunk above sender_host_name for the base64 data.

1. Put a huge chunk into unsorted bin First of all, we send a EHLO message with huge hostname to make it allocate and deallocate, leaving a 0x6060 length (3 storeblocks long) chunk in unsorted bin.

2. Cut the first storeblock Then we send an unrecognized string to trigger store_get() and allocate a storeblock inside the freed chunk.

3. Cut the second storeblock and release the first one We send a EHLO message again to get the second storeblock. The first block is freed sequentially because of the smtp_reset called after EHLO is done.

   After the heap layout is prepared, we can use the off-by-one to overwrite the original chunk size. We modify 0x2021 to 0x20f1, which slightly extends the chunk.

4. Send base64 data and trigger off-by-one To trigger off-by-one, we start an AUTH command to send base64 data. The overflow byte precisely overwrites the first byte of next chunk and extends the next chunk.

5. Forge a reasonable chunk size Because the chunk is extended, the start of next chunk of is changed to somewhere inside of the original one. Therefore, we need to make it seems like a normal chunk to pass sanity checks in glibc. We send another base64 string here, because it requires NULL byte and unprintable character to forge chunk size.

6. Release the extended chunk To control the content of extended chunk, we need to release the chunk first because we cannot edit it directly. That is, we should send a new EHLO message to release the old host name. However, normal EHLO message calls smtp_reset after it succeeds, which possibly makes program abort or crash. To avoid this, we send an invalid host name such as a+.

7. Overwrite the next pointer of overlapped storeblock

   After the chunk is released, we can retrieve it with AUTH and overwrite part of overlapped storeblock. Here we use a trick called partial write. With this, we can modify the pointer without breaking ASLR (Address space layout randomization). We partially changed the next pointer to a storeblock containing ACL (Access Control List) strings. The ACL strings are pointed by a set of global pointers such as:

   uschar *acl_smtp_auth; uschar *acl_smtp_data; uschar *acl_smtp_etrn; uschar *acl_smtp_expn; uschar *acl_smtp_helo; uschar *acl_smtp_mail; uschar *acl_smtp_quit; uschar *acl_smtp_rcpt;

   These pointers are initialized at the beginning of exim process, set according to the configure. For example, if there is a line acl_smtp_mail = acl_check_mail in the configure, the pointer acl_smtp_mail points to the string acl_check_mail. Whenever MAIL FROM is used, exim performs an ACL check, which expands acl_check_mail first. While expanding, exim tries to execute commands if it encounters ${run{cmd}}, so we achieve code execution as long as we control the ACL strings. In addition, we do not need to hijack program control flow directly and therefore we can bypass mitigations such as PIE (Position Independent Executables), NX easily.

8. Reset storeblocks and retrieve the ACL storeblock Now the ACL storeblock is in the linked list chain. It will be released once smtp_reset() is triggered, and then we can retrieve it again by allocating multiple blocks.

9. Overwrite ACL strings and trigger ACL check Finally, we overwrite the whole block containing ACL strings. Now we send commands such as EHLO, MAIL, RCPT to trigger ACL checks. Once we touch an acl defined in the configure, we achieve remote code execution.

Upgrade to 4.90.1 or above

• 5 February, 2018 09:10 Reported to Exim
• 6 February, 2018 23:23 CVE received
• 10 February, 2018 18:00 Patch released

Vulnerabilities found by Meh, DEVCORE research team. meh [at] devco [dot] re

https://exim.org/static/doc/security/CVE-2018-6789.txt https://git.exim.org/exim.git/commit/cf3cd306062a08969c41a1cdd32c6855f1abecf1 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6789 http://www.openwall.com/lists/oss-security/2018/02/07/2

• Heap Exploitation: A tutorial of heap exploitation by Dhaval Kapil
• how2heap: A repo for learning heap exploitation by Shellphish
• Heap exploitation: (Chinese) A slide introducing basic glibc heap exploitation by Angelboy
• Advanced heap exploitation: (Chinese) A slide of advanced heap exploitation techniques by Angelboy
• The poisoned NUL byte: An article of Null byte off-by-one exploitation by Project Zero

今年我們向 Exim 回報了一個位於 base64 解碼函式的溢出漏洞，編號為 CVE-2018-6789。此漏洞從 Exim 專案開始時即存在，因此影響 Exim 的所有版本。

根據我們的研究，攻擊者可利用此漏洞達成遠端任意代碼執行，並且不需任何認證，至少有 40 萬台 Exim 伺服器受此漏洞影響並存在被攻擊的風險。我們建議立即將 Exim 升級至 4.90.1 版以免遭受攻擊。

詳細的技術細節請參閱我們的 Advisory： https://devco.re/blog/2018/03/06/exim-off-by-one-RCE-exploiting-CVE-2018-6789-en/

Speech by Andrew Hampton, Director-General of the GCSB, to the New Zealand Institute of International Affairs in Wellington, Feb 27 2018.