Post reply

Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters):www.scforum.info:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Samker
« on: 18. February 2015., 20:25:15 »

D., thanks for time and effort. :thumbsup:
Posted by: devnullius
« on: 16. February 2015., 21:42:50 »

Took a few searches, but found it... They talk about changing a bit: I think it should read byte?

My Dutch source: http://tweakers.net/nieuws/101334/onderzoekers-omzeilen-beschermingsmechanismen-windows-via-gui-lek.html

Their source: http://breakingmalware.com/vulnerabilities/one-bit-rule-bypassing-windows-10-protections-using-single-bit/

Ugly text-only copy paste, without links... See below. For full, best experience, go to breakingmalware article!

One-Bit To Rule Them All: Bypassing Windows’ 10 Protections using a Single Bit
Introduction
Today, Microsoft released their latest Patch Tuesday. This Patch includes a fix for vulnerability CVE-2015-0057, an IMPORTANT-rated exploitable vulnerability which we responsibly disclosed to Microsoft a few months ago.
As part of our research, we revealed this privilege escalation vulnerability which, if exploited, enables a threat actor to complete control of a Windows machine. In other words, a threat actor that gains access to a Windows machine (say, through a phishing campaign) can exploit this vulnerability to bypass all Windows security measures, defeating mitigation measures such as sandboxing, kernel segregation and memory randomization.
Interestingly, the exploit requires modifying only a single bit of the Windows operating system.
We have verified this exploit against all supported Windows desktop versions, including Windows 10 Technical Preview.

This entry starts by detailing the vulnerability. At first, it seemed to us impossible to exploit. After some hard word, however, we managed to produce a fully working exploit which we’ll describe. As part of this analysis, we also present a video which demonstrates the exploit. Finally, we conclude this entry with a buggy dead-code anecdote which we thought interesting to share.
Responsible disclosure: although this blog entry is technical, we won’t reveal any code, or the complete details, to prevent any tech master from being able to reproduce an exploit.
 
Background
Over the last several years, privilege escalation vulnerabilities became all the more crucial for exploitation because they enable malicious code to run on the kernel. As such, a threat actor exploiting a privileged escalation vulnerability can bypass protective security mechanisms such as application sandboxes.
Step by step with the attackers’ progress, Microsoft made extensive efforts to protect the kernel. The reasoning is that even if a vulnerability exists, exploiting it would be difficult, if not impossible.
For example, here are just a few of the kernel protection mechanisms that are present in Windows 8.1:Kernel DEP – Ensures that most kernel data regions cannot be executed
• Kernel DEP – Ensures that most kernel data regions cannot be executed
• KASLR – Randomizes the kernel address-space to avoid figuring out where kernel modules exist
• Integrity Level – Limits the ability of an unprivileged application to leak kernel-related information
• Mitigation Of Common Attack Vectors – Hardens commonly abused structures (such as the Win32k wnd proc field)
• SMEP – Prevents execution control transfers between kernel mode to user-mode
• NULL Dereference Protection – Prohibits mapping of the first 64k of data in user-mode
Albeit these hardening mechanisms, in the past year we have seen some notable presentations that demonstrated techniques to bypass these protections.
The vulnerability which we describe in this entry, is a newly disclosed privilege escalation exploitable vulnerability that too bypasses these protections.
The Vulnerability: a hole in the Win32k.sys module
This particular vulnerability appears in the GUI component of Microsoft Windows Kernel, namely, the Win32k.sys module.
This entry assumes a strong technical understanding of the Win32k.sys module. For detailed information on this module, please refer to Tajei Mandt, Gilad Bakas and Gil Dabah.
Zooming into Window Scrollbars
The Win32k module manages also the actual windows’ scrollbars. These scrollbars – whether horizontal or vertical – are set for each window.
Let’s zoom into these scrollbars:
fig1
 
As can be seen in Figure 1, each SBDATA structure defines the information regarding one of the scrollbars.
The WSBflags is a bitmask that determines the state of the scrollbars.
In order to enable and disable a window scrollbar, the function xxxEnableWndSBArrows is used. Through a single call, this function can alter the state of both scrollbars.
It is precisely within this function wherein the vulnerability lies.
Deep Diving into xxxEnableWndSBArrows
The prototype of xxxEnableWndSBArrows is:
fig2
 
• Wnd – A pointer to the relevant window
• wSBflags – The scrollbar type (e.g. horizontal or vertical)
• wArrows – Specifies whether the scrollbar’s arrows are enabled or disabled and indicates which arrows are enabled or disabled.
In order to describe the vulnerability, we’ll take a look at the first part of the xxxEnableWndSBArrows function which can be broken down into 3 logical parts:
Part 1 – Allocation of a new scrollbar (if needed)
The function starts by checking whether there is already scrollbar information for that window and allocates a new scrollbar information struct, if needed.
Technically speaking, the function reads the pSBInfo field (to recall, this field points to the tagSBINFO struct) and tests if the pointer is NULL. If the field is null and the wArrows parameter is not NULL, then a tagSBINFO struct is allocated for the window and the old flags of the scrollbars are set to 0. Otherwise the old flags are copied from the existing window’s scrollbars information. The code can be found in Figure 2.
fig22
Part 2 – Setting the state of the horizontal scrollbar
The flow continues by testing whether the state of horizontal scrollbar should be changed.
According to what was set in the wArrows argument, the function enables or disables the arrows (figure 3).
fig3
 
Part 3 – Testing the state of the scrollbar arrows
The flow continues by checking whether the state of the arrows have changed.
Technically speaking, this is done by checking the arrow’s flags (to note, there are a few more flag checks – but those are not interesting for our purpose). If the flags have changed and the window is visible then xxxDrawScrollbar is called.
This is precisely the place where things get interesting.
When digging into the code, it seems possible that the xxxDrawScrollBar will lead to a user–mode callback (Figure 4).
fig4
 
The pivotal function in this call chain is the ClientLoadLibrary. This function performs the callback to the user-mode function __ClientLoadLibrary.
Let’s return now to the code of xxxEnableWndSBArrows.
Our examination showed that the tagSBINFO pointer is used without any verification after the callback. Ultimately, this could lead to a Use-After-Free (UAF) vulnerability since the function may continue to work with the freed scrollbar information (Figure 5).
fig5
 
The Exploitation: manipulating windows properties
After the callback, the function xxxEnableWndSBArrows continues and changes the state of the vertical scrollbar.
At this stage, the function tries to enable or disable the flags. However, since the struct is already freed, we can use this to either Bitwise OR the first DWORD of the freed buffer with 0xC (if we disable the arrows) or to clear bit 3 and 4 (if we enable the arrows). See figure 6.
fig6
For simplicity sake, we show how to manipulate 2 bits in order to “rule them all”. However, manipulating only one of them would be enough.
The bit manipulation at first didn’t seem enough to result in anything significant, but we decided to keep trying. The most obvious things to try were to either increase the size of some buffer (using the bitwise OR) or decrease some reference counter (using the bitwise AND).
After a short search we found an object that met the first requirement. This object is the properties list of a window.
The Window Properties List
Each window has a properties list. Generally, these properties can be used by the GUI application to store arbitrary values, though also Win32K uses this properties list in order to store internal data.
fig7
 
The data structures used to hold the window’s properties can be seen in Figure 7. The first field, cEntries, is the number of entries in the properties array; iFirstFree is the index to the first free cell in the properties array; and props is the array itself.
An application can set the window’s properties using the SetProp API. The prototype of the function is as follows:
fig8
 
• hWnd – The handle to the window.
• lpString – The of the property or an ATOM.
• hData – The data to store.
Adding properties to a window is performed through the CreateProp function, appearing in the win32k module.
As can be seen in figure 8 its allocation algorithm is quite simple. If there is no room for a new property in the list, the function allocates a new properties list with one more entry. The function then proceeds to copy the buffer of the old properties to the new one, frees the old buffer and increases the entries count.
fig88
There are several important things to note in this code:
First, the properties are allocated from the Desktop heap (Uses DesktopAlloc). Also, tagSBINFO is allocated from this heap. This is crucial if we want to use the UAF vulnerability to alter the properties structure.
Second, each new entry triggers the reallocation of the buffer. This means that we can easily trigger the reallocation of the buffer when it’s about to reach the size of the tagSBINFO structure. Doing this increases the chances that the buffer will be allocated over the freed tagSBINFO struct.
Third, and most importantly, the cEntries field is located in the first DWORD of the struct. This means that we can increase its size (using the bitwise Or). After increasing the size of the properties array we basically achieved a classical buffer-overflow.
Proof-of-Concept Video
The above research led to the privilege escalation exploitation. We stop here, however, to avoid releasing any sensitive code.
Our demo on a 64-bit Windows 10 Technical Preview provides the necessary proof-of-concept:
 

Summary
After some work we managed to create a reliable exploit for all versions of Windows – dating back as of Windows XP to Windows 10 preview (With SMEP and protections turned on). We have shown that even a minor bug can be used to gain complete control over any Windows Operating System.
Nevertheless, we think that Microsoft efforts to make the its operating system more secure raised the bar significantly and made writing reliable exploits far harder than before.
Unfortunately, these measures are not going to keep attackers at bay. We predict that attackers will continue incorporating exploits into their crime kits, making compromise inevitable.
Last side note: funny code
Examining the code of the xxxEnableWndSBArrows function showed that there are calls to the xxxWindowEvent function.
At first glance it seemed that these two functions would be far easier to use as an exploitation stepping stone than the xxxDrawScrollbar function, as detailed above.
However, after diving into the code it quickly became clear that the calls to xxxWindowEvent in the Horizontal scrollbar part of the code are actually dead-code (Figure 9).
fig9
 
Looking at the code, there are two conditional calls to the function, xxxWindowEvent. These calls are executed only if the old flags of the scrollbar information differ from those of the new flags. However, by the time these conditions appear, the values of the old flags and the new flags are always equal. Hence, the condition for calling xxxWindowEvent is never met. This practically means that this dead-code was there for about 15-years doing absolutely nothing.
Posted by: Samker
« on: 16. February 2015., 19:18:39 »

...

I don't know if you heard of the other bug patched this month? Change 1 byte with a guest account to gain complete control over XP - 2012 R2...
...

No, link please... ?
Posted by: devnullius
« on: 16. February 2015., 11:50:49 »

Damn! 1 year and an OS re-design?? That's a serious bug then!

I don't know if you heard of the other bug patched this month? Change 1 byte with a guest account to gain complete control over XP - 2012 R2... Flipping a bit in the code for scroll bars was the cause of this major bug. Sometimes it's in the details, sometimes the whole project is just ASCII'd ;-)

Devvie
Posted by: Samker
« on: 11. February 2015., 19:24:57 »



Another month, another Patch Tuesday: https://technet.microsoft.com/en-us/library/security/dn903782.aspx , but this release has a special sting in the tail: a flaw in the fundamental design of Windows that's taken a year to correct, and is unfixable on Server 2003.

The critical blunder allows miscreants to completely take over a domain-configured Windows system if it is connected to a malicious network – wirelessly or wired. Most home users shouldn't be hit by this, as they are not usually domain-configured, but it's a massive pain in the ASCII for IT pros because work computers are typically set up to join a corporate-controlled domain.

Plug a corporate laptop, say, into a dodgy network in a cafe, and it's game over: http://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx
According to Microsoft:

"An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights."

This remote-code execution flaw affects all supported versions of Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows RT, Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1.

"The circumstances around this vulnerability are unusual — if not unprecedented — necessitating the very long remediation cycle," explained JAS Global Advisors, the security firm that found the MS15-009 flaw: https://www.jasadvisors.com/about-jas/jasbug-security-vulnerability-fact-sheet/

"Unlike recent high-profile vulnerabilities like Heartbleed, Shellshock, Gotofail, and POODLE, this is a design problem not an implementation problem. The fix required Microsoft to re-engineer core components of the operating system and to add several new features. Careful attention to backwards compatibility and supported configurations was required, and Microsoft performed extensive regression testing to minimize the potential for unanticipated side effects."

The bug (CVE-2015-0008) was discovered over a year ago when global DNS overlord ICANN hired JAS to check out the security of its systems for creating new generic top-level domains: https://technet.microsoft.com/library/security/MS15-011
Once it was found, a JAS employee spent a year working with Redmond to build a fix that wouldn't bork everyone's systems.

Microsoft said the flaw is so fundamental, it's "infeasible" to patch Server 2003 to fix it (cough, cough, Server 2003 is reaching its end of life: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ ).

“The architecture to properly support the fix provided in the update does not exist on Windows Server 2003 systems," a spokesman for Microsoft told The Register.

"For customers running Windows Server 2003, we recommend using properly configured VPN solutions when connecting to untrusted networks.”

The issue lies in how Windows handles group policy interaction with domain-configured systems.

For example, a user with a work laptop configured to use a domain could be sitting in a cafe, trying to access files on a corporate network. A man-in-the-middle attacker could modify the ARP tables in the wireless router to point the Windows system at a malicious domain that serves, say, a login.bat file with evil commands in it.

It sounds too easy, right? That's because cryptographic mechanisms and other protections to thwart this kind of attack could be disabled or broken.

How the attack is allowed to work

"A remote-code execution vulnerability existed in how Group Policy received and applied policy data when connecting to a domain," explained Microsoft's security team.

"Concurrently, a vulnerability existed whereby Group Policy could fail to retrieve valid security policy and instead apply a default, potentially less secure, group policy. This could, in turn, be used to disable the domain enforced SMB Signing policy."

The team continued:

"More importantly, SMB Client doesn’t require SMB Signing by default so it is possible to direct the domain related traffic, especially the unencrypted traffic, to attacker controlled machines and serve malicious content to the victims in response. To block this kind of attacks we added the ability to harden the UNC path access within domain network: https://msdn.microsoft.com/en-us/library/gg465305.aspx "

The Redmond giant said it's not aware of anyone exploiting this design flaw in the wild.

More patches to apply

There are two other critical patches released. MS15-009 covers 41 reported flaws in Internet Explorer hitting all versions of the browser from version six and above on all operating systems: https://technet.microsoft.com/library/security/MS15-009
Visit the wrong website without this patch set installed and you could be pwned.

One of the IE bugs – CVE-2015-0071 – is a privilege-escalation hole, and was exploited in the wild. Allegedly, Chinese hackers combined it with a remote-code execution vulnerability in Adobe Flash to infect visitors to the Forbes website with malware: http://www.isightpartners.com/2015/02/codoso/
The "thought for the day" page was booby-trapped with code that exploited the programming flaws to hijack visitors' PCs during Thanksgiving in 2014, it's claimed.

Adobe patched its bug soon after, thwarting this particular attack.

Microsoft's second critical fix today covers Windows 7 and above, and server software after Server 2008 R2: https://technet.microsoft.com/library/security/MS15-010
The flaw covers how the Windows kernel-mode driver deals with certain objects, particularly embedded TrueType fonts.

The remaining six patches are all rated important by Redmond and cover a smaller subset of Microsoft's wares. There's two security fixes for Office, tweaks for Group policy that are presumably related to the design fix, a patch for Flash, and fixes for Virtual Machine and the graphics system.

(ElReg)
Enter your email address to receive daily email with 'SCforum.info - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising