About flags 0x41414141 times
No matter how much we talk about the need to use flags of the linker and compiler aimed at identifying memory damage and complicating their use - our developers of DBs, ABS and various certified products, as a rule, do not listen to this. And when writing a pre-auth RCE server side exploit, once again the idea appeared to write about it on the basis of our latest works.
So, in the course of one of our recent work on analyzing the security of an application without source code (a client-server application for Windows OS), we found a vulnerability using the fuzzing method. We were immediately pleased by the fact that for its operation there is no need to know the login and password, since the data leading to the application crash were contained in the first package responsible for authentication (2013 in the yard).
')
In 2011, our researcher found a similar vulnerability in Oracle PeopleSoft (this vulnerability was closed in CPU January 2011 ). There, the vulnerability manifested itself when entering a password of a certain length. But we couldn’t squeeze anything out of the DoS, because the / GS (stack cookie) compilation flag was used, and our overflowed buffer did not reach SEH, and we couldn’t overwrite it to transfer control to our code.
But our new target did not have this. The only thing she used was DEP. So writing a remote exploit for Windows 7 was just a formality. The task was quite simple and boring: rewrite the return address to the chain of ROP gadgets to disable DEP and transfer control to our shellcode, which lay in the same stack.
We decided to write an exploit for Windows 8 as well, which introduced a number of additional security mechanisms , of which we were interested in the mechanism responsible for randomizing the load of libraries compiled without the / DYNAMICBASE (ASLR) flag. This feature is called ForceASLR. It was introduced, as mentioned, in Windows 8, but is also available for Windows 7 after installing the KB2639308 update and a small registry setting for the application of interest (see Image File Execution Option).
Adding to
and for WOW on x64 - in
the MitigationOptions key and the value 0x100, you can force ASLR on for the program.
So even the last Dropbox file itself can be quickly (or system administrator) fixed for Firefox, Chrome for Windows 7/8 users (IE10 is okay in this regard) by turning on ASLR for the necessary programs - however, only in Windows7 / 8, Windows Server 2008 R2, and that is not always ... But more on that later.
Let's go back to our story. We wanted to almost artificially introduce the presence of ASLR for this program, which would break our plan at the stage of preparation of the ROP chain (since now we do not know the address of our ROP gadgets). But even here disappointment awaited us, since the application was compiled without a relocation table (fixed base address), namely, compulsory randomization of loading the executable file is based on it. So even the newfangled feature of Windows 8 did not help this software.
In order to somehow have fun and surprise the customer, we wrote shellcode, which itself restored the operation of the server being operated, so it wasn’t even noticeable that it fell, and the clients worked uninterruptedly with it (there could be problems except for clients who only connected to the server) =) To do this, I had to restart the stream and correctly reinitialize all the service structures.
Reference. ASLR bypass techniques:
Besides the fact that such software is easy to exploit, it is also an opportunity to easily exploit vulnerabilities in other more protected programs, for example, in browsers. I will explain. One of the ASLR bypass techniques is a special attack initiated by the attacking library without ASLR into the address space of the attacked application (The last widely known case of using this technique is a targeted attack using the CVE-2013-3893 operation in Internet Explorer). And the attacker decided to attack clients / employees of the bank (it’s not a secret, of course, what kind of RBS system is used) or a government institution (and, naturally, the secret is not a list of certified software allowed to work in such companies for encryption, demarcation). access, memory cleanup, etc.). An attacker, examining this software, will try to load them (if they do not load themselves), since they are mostly without ASLR. And at the same time a good targeted attack is obtained. After all, if the browser does not load, for example, an ActiveX-element of a certain RBS system, then the victim, most likely, is not a client of this bank, and therefore the target of the attacker.
This example wanted to show how heterogeneous systems are now and how sophisticated attacks are. Do not forget that a huge amount of software lives on the user's computer at the same time. Weak software can be used to compromise your software, or your software to compromise someone else's.
History reference:
The appearance of the mechanism does not mean that it has become enabled by default in VisualStudio. See what your projects use from this, and correlate to which year of release they are from a security point of view.
Remember that with the transition to a new studio, you get not only a new graphical user interface and programmer news, but also all the new features of the compiler and linker, of which very many are related to security. For some, it may be news, but even the / GS flag has evolved and by 2010 is version 4, not to mention a number of improvements , such as pointer protection, heap metadata protection, and the order of variables on the stack, which even sometimes do not have special names .
For the sake of completeness, we say that ASLR and DEP can be configured not only through flags, but also using the registry and a special API: MitigationOptions in IFEO (Image File Execution Option), UpdateProcThreadAttribute, SetProcessMitigationPolicy API, but with flags much easier.
To increase user security, of course, there is such a thing as EMET ( Enhanced Mitigation Experience Toolkit ), but we, unfortunately, agree with the comment to the article at the link: " And yet this thing is for very advanced users ." I do not mean the complexity of working with the program, but the weak computer literacy of most users.
Spend a few minutes of time, set the flags of the compiler and linker, and you will complicate many times, and in some cases make it impossible to write a stable working exploit. As a result, the attacker will be content with only DoS.
Yes, there are similar (and specific) flags for mobile platforms:
iOS : –fPIE, –fstack-protector-all, -fobjc-arc
Android (for native libraries): -fstack-protector, -Wformat-security, NX, ASLR, PIE
BlackBerry 10 (for native libraries): - fstack-protector-all, -D_FORTIFY_SOURCE = 2, -fPIE, -Wl, -z, relro, -Wl, -z, now, -pie
WindowsPhone 8 (for native libraries): similar to Windows 8
Not everyone can immediately write a safe code (unrealistic), not everyone can afford software for analyzing code security (the budget does not allow), not everyone can quickly and painlessly implement SDL into a company (this, of course, we must strive for), but everyone can set the flags. So with minimal effort, you can significantly increase security.
PS: Naturally, compilation flags do not affect architectural, logical and configuration vulnerabilities;)
PPS: There are also sandboxes and virtualization, but this is not a panacea either. About them - already at ZeroNights 2013 !
So, in the course of one of our recent work on analyzing the security of an application without source code (a client-server application for Windows OS), we found a vulnerability using the fuzzing method. We were immediately pleased by the fact that for its operation there is no need to know the login and password, since the data leading to the application crash were contained in the first package responsible for authentication (2013 in the yard).
')
In 2011, our researcher found a similar vulnerability in Oracle PeopleSoft (this vulnerability was closed in CPU January 2011 ). There, the vulnerability manifested itself when entering a password of a certain length. But we couldn’t squeeze anything out of the DoS, because the / GS (stack cookie) compilation flag was used, and our overflowed buffer did not reach SEH, and we couldn’t overwrite it to transfer control to our code.
But our new target did not have this. The only thing she used was DEP. So writing a remote exploit for Windows 7 was just a formality. The task was quite simple and boring: rewrite the return address to the chain of ROP gadgets to disable DEP and transfer control to our shellcode, which lay in the same stack.
We decided to write an exploit for Windows 8 as well, which introduced a number of additional security mechanisms , of which we were interested in the mechanism responsible for randomizing the load of libraries compiled without the / DYNAMICBASE (ASLR) flag. This feature is called ForceASLR. It was introduced, as mentioned, in Windows 8, but is also available for Windows 7 after installing the KB2639308 update and a small registry setting for the application of interest (see Image File Execution Option).
Adding to
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable> and for WOW on x64 - in
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable> the MitigationOptions key and the value 0x100, you can force ASLR on for the program.
So even the last Dropbox file itself can be quickly (or system administrator) fixed for Firefox, Chrome for Windows 7/8 users (IE10 is okay in this regard) by turning on ASLR for the necessary programs - however, only in Windows7 / 8, Windows Server 2008 R2, and that is not always ... But more on that later.
Let's go back to our story. We wanted to almost artificially introduce the presence of ASLR for this program, which would break our plan at the stage of preparation of the ROP chain (since now we do not know the address of our ROP gadgets). But even here disappointment awaited us, since the application was compiled without a relocation table (fixed base address), namely, compulsory randomization of loading the executable file is based on it. So even the newfangled feature of Windows 8 did not help this software.
In order to somehow have fun and surprise the customer, we wrote shellcode, which itself restored the operation of the server being operated, so it wasn’t even noticeable that it fell, and the clients worked uninterruptedly with it (there could be problems except for clients who only connected to the server) =) To do this, I had to restart the stream and correctly reinitialize all the service structures.
Reference. ASLR bypass techniques:
- Bust
- Partial rewriting of EIP
- Address leak
- Through vulnerability
- Through timing attack
- Through games with lines / objects
- ...
- Using pre-known addresses
- Libraries without ASLR
- System structures ( technique with _ KUSER_SHARED_DATA )
- Intentional location
- JIT / Heap spray
- ...
Besides the fact that such software is easy to exploit, it is also an opportunity to easily exploit vulnerabilities in other more protected programs, for example, in browsers. I will explain. One of the ASLR bypass techniques is a special attack initiated by the attacking library without ASLR into the address space of the attacked application (The last widely known case of using this technique is a targeted attack using the CVE-2013-3893 operation in Internet Explorer). And the attacker decided to attack clients / employees of the bank (it’s not a secret, of course, what kind of RBS system is used) or a government institution (and, naturally, the secret is not a list of certified software allowed to work in such companies for encryption, demarcation). access, memory cleanup, etc.). An attacker, examining this software, will try to load them (if they do not load themselves), since they are mostly without ASLR. And at the same time a good targeted attack is obtained. After all, if the browser does not load, for example, an ActiveX-element of a certain RBS system, then the victim, most likely, is not a client of this bank, and therefore the target of the attacker.
This example wanted to show how heterogeneous systems are now and how sophisticated attacks are. Do not forget that a huge amount of software lives on the user's computer at the same time. Weak software can be used to compromise your software, or your software to compromise someone else's.
History reference:
- GS appeared in 2002
- SafeSEH appeared in 2003
- DEP appeared in 2004
- ASLR appeared in 2006
- ForceASLR appeared in 2012
The appearance of the mechanism does not mean that it has become enabled by default in VisualStudio. See what your projects use from this, and correlate to which year of release they are from a security point of view.
Remember that with the transition to a new studio, you get not only a new graphical user interface and programmer news, but also all the new features of the compiler and linker, of which very many are related to security. For some, it may be news, but even the / GS flag has evolved and by 2010 is version 4, not to mention a number of improvements , such as pointer protection, heap metadata protection, and the order of variables on the stack, which even sometimes do not have special names .
For the sake of completeness, we say that ASLR and DEP can be configured not only through flags, but also using the registry and a special API: MitigationOptions in IFEO (Image File Execution Option), UpdateProcThreadAttribute, SetProcessMitigationPolicy API, but with flags much easier.
To increase user security, of course, there is such a thing as EMET ( Enhanced Mitigation Experience Toolkit ), but we, unfortunately, agree with the comment to the article at the link: " And yet this thing is for very advanced users ." I do not mean the complexity of working with the program, but the weak computer literacy of most users.
Spend a few minutes of time, set the flags of the compiler and linker, and you will complicate many times, and in some cases make it impossible to write a stable working exploit. As a result, the attacker will be content with only DoS.
Yes, there are similar (and specific) flags for mobile platforms:
iOS : –fPIE, –fstack-protector-all, -fobjc-arc
Android (for native libraries): -fstack-protector, -Wformat-security, NX, ASLR, PIE
BlackBerry 10 (for native libraries): - fstack-protector-all, -D_FORTIFY_SOURCE = 2, -fPIE, -Wl, -z, relro, -Wl, -z, now, -pie
WindowsPhone 8 (for native libraries): similar to Windows 8
Not everyone can immediately write a safe code (unrealistic), not everyone can afford software for analyzing code security (the budget does not allow), not everyone can quickly and painlessly implement SDL into a company (this, of course, we must strive for), but everyone can set the flags. So with minimal effort, you can significantly increase security.
PS: Naturally, compilation flags do not affect architectural, logical and configuration vulnerabilities;)
PPS: There are also sandboxes and virtualization, but this is not a panacea either. About them - already at ZeroNights 2013 !
Source: https://habr.com/ru/post/196900/
All Articles