System-wide Mandatory ASLR Failure to Properly Randomize (Win8+)

Discussion in 'other security issues & news' started by WildByDesign, Nov 17, 2017.

  1. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    In Win 10 1709, the mitigations registry value didn't exist prior to the .reg key fix.

    Did you try to create an exception for IntelliJ IDEA in WD Exploit Protection -> Apps -> Programs and disabling "Force randomization for images(Manadatory ASLR)"?
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    There is also a question in the third hex value mitigations registry value. The .reg fix sets that value to "01". However if one refers to @WildByDesign matrix for the registry key mitigation values, the first nibble of that hex value controls system-wide high entropy ASLR. So should that third hex value actually be "11"? It appears that setting on system-wide mandatory and bottom up ASLR automatically enables system-wide high entropy ASLR by default. So the question is if the real problem all along was that system-wide high entropy ASLR has to be enabled instead?

    What doesn't help the issue is the WD Exploit Protection after 1709 installation displays the wrong values; it is actually that system-wide mandatory ASLR that is enabled and system-wide mandatory bottom up ASLR that is disabled.
     
    Last edited: Nov 23, 2017
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    There is also another revelation in regards to Windows Defender Exploit Protection. I downloaded the latest Hitman Pro Alert Test Tool which appears only to be 32 bit. I ran through half the tests so far. WDEG did crash the test tool in the tests I did. However and unlike EMET, you will get no alerts in regards to the exploit activity. So unless you are monitoring your event logs religiously, you will not know the exploit activity is occurring.
     
  4. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    :thumb:


    https://www.wilderssecurity.com/thr...-windows-10-needs.383448/page-52#post-2715892
     
  5. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Personally, I like to create Custom Views in Event Viewer specifically for Kernel Mode Mitigations and User Mode Mitigations.

    Applications and Services Logs > Microsoft > Windows > Security Mitigations

    From within there, a user can create custom views to make it easier to monitor user mode and kernel mode process mitigation events. This is new within RS3 1709.

    Please note: Be extremely careful with regard to enabling System-wide Process Mitigations. Enabling certain mitigations can easily cause a system to not boot. While the RS3 ProcessMitigations spreadsheet that I provided does work with System-wide kernel settings, it is mostly intended for the IFEO registry settings which would be per-application process mitigations. My apologies, I should have clarified that initially. System-wide can be dangerous for some of those advanced mitigations.
     
  6. Azure Phoenix

    Azure Phoenix Registered Member

    Joined:
    Nov 22, 2014
    Posts:
    1,556
  7. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,002
    Location:
    Member state of European Union
    IntelliJ IDEA works well with both variants. Checked after restart. Windows 8.1 64-bit. Thanks.
     
  8. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    :thumb:
     
  9. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    ;):)
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I retested with Hitman Pro Alert Test Tool; this time the correct way. You are supposed to add the test tool .exe to your existing exploit protection. So I added the .exe to WDEG as an app and configured it the same as existing IE settings. I then repeated all the individual tests.

    At this point, I don't know what to make of WDEG protection. The only test that actually aborted the test tool was DEP. For all the other tests, it appeared they bypassed WDEG protection. The test tool did not abort and calc.exe, the test payload, appeared every time. However when I reviewed my event log for errors, numerous events were recorded for the test tool; memory violations, etc.. It appears to me that although WDEG can detect the exploit activity and possibly block it, it lacks any capability of terminating the attack process. One explanation would be it defers to Windows Defender to perform those activities. So if you are using a third party AV solution, WDEG is only a 50% mitigation. This also is in stark contrast to EMET protection which did indeed work independent of a third party AV solution.
     
  11. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    Hi itman.
    The number of mitigations of I.E. is insufficient.
    With Chrome I set up 12 mitigations:


    Immagine.jpg



    You should repeat the test with the same mitigations.
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Ok. Will set those up tomorrow for the test tool and retest. Note that Microsoft states that their default configs. are supposed to be secure. :rolleyes:

    I don't have to worry about IE exploit-wise. I sometime ago created an Eset HIPS process modification rule for it. And the HIPS triggered an alert for every one of the test tool tests. And it did so immediately upon detection of any of the test tool's simulated attacks.
     
  13. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    Exploit-test-Tool (HPA3).
    The maximum allowable mitigations value is 18:



    11.jpg

    Set the instrument with the calculator before performing the test.
    Some mitigations prevent the calculator from being displayed.
    Go !!
    :)


    http://sendvid.com/17rid33p
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Retested. Set IE11 to all WDEP mitigations except; ACG, block low integrity and remote images, block untrusted fonts, code integrity, disable win32K calls*, do not allow child processes, and EAF*. CFG was disabled for Heap Spray tests per test tool instructions.

    * - these mitigations will crash IE11.

    WDEG failed the following 32 bit HMP-A test tool tests;

    Stack Exec
    Unipivot Stack
    ROP - WOW64 bypass
    ROP - WOW64 exploit
    ROP - Win Exec (0) via Anti-Detours
    Heap Spray 1
    Heap Spray 2
    Heap Spray 3
    URLmon
    Appears WDEG has a problem with heap spraying in 32 bit processes.

    I also tested WDEG using an older 64 bit ver. of the HMP-A test tool. Tool dates to fall of 2015. So definitely not made for Win 10. In any case, WDEG did better on this test only failing:

    Stack Exec
    ROP 3
    ROP 4
    Also below are entries from Windows Mitigations User event log. Appears all ROP events are logged by default:

    Process 'C:\Users\\Downloads\iexplore.exe' (PID 6580) was blocked from calling the API 'VirtualProtect' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 3344) was blocked from calling the API 'WinExec' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 7696) was blocked from calling the API 'VirtualProtect' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 6348 ) was blocked from calling the API 'VirtualProtect' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 6388 ) was blocked from calling the API 'NtProtectVirtualMemory' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 6140) was blocked from calling the API 'VirtualProtect' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 2480) was blocked from calling the API 'WinExec' due to return-oriented programming (ROP) exploit indications.
    Process 'C:\Users\\Downloads\iexplore.exe' (PID 2168 ) was blocked from calling the API 'LoadLibraryA' due to return-oriented programming (ROP) exploit indications.​
     
    Last edited: Nov 26, 2017
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    One additional thing I did was test with the older 32 bit ver. of the test tool that I referred to previously. That ver. had 4 heap spray tests. WDEG detected the first two and failed on the last two. So it appears, Surfright modified the heap spray tests in the latest test tool ver.; most likely to factor in Win 10 operating features.
     
  16. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    If anyone is interested, anti-exploit test with MBAE ver 24 in my XP:

    http://sendvid.com/iq904y0w
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Based on testing w/HMP-A Test Tool, WDEG has heap spray mitigation issues with 32 bit processes. One would think that applying the recommended .reg fix to correct system-wide mandatory and bottom-up ASLR would have corrected this but it didn't.
     
  18. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    Hi itman.
    New test.

    MitigationOptions*

    01 10 01

    *(WildbyDesign table)

    All Heap failed

    P.S.

    https://www.wilderssecurity.com/thr...xperience-toolkit.344631/page-51#post-2582995
     
    Last edited: Nov 27, 2017
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I don't know what you retested with; MB anti-exploit or WDEG?

    I did previously remove the mitigations reg key value set to recommended CERT values and retested. The results were the same; all heap spray tests failed. I also like you did previously, set on the system-wide heap setting in the mitigations reg key value. Again, all heap spray tests failed.

    It very much appears all Microsoft did was port existing EMET code into Win 10 WDEG and didn't do anything to correct its existing deficiencies.
     
  20. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    WDEG.

    :thumbd::confused:

    You've permanently remove the values recommended by CERT?
     
    Last edited: Nov 27, 2017
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes. As posted previously, I removed the mitigations reg value entirely since it did not exist prior to applying the recommended .reg fix. I then rebooted and retested using the heap spray tests. Made no difference.

    My latest test was to disable Eset's realtime protection so that WD would be fully active. Again, all heap spray tests failed.

    Bottom line - as in EMET 5.5, WDEG 32 bit heap spray protection is totally ineffective.
     
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I believe the following sums up what the heap spray issue is. WDEG like EMET 5.5 is preallocating memory areas to validate. Unlike EMET 5.5, WDEG appears to have no way of overriding or expanding what memory areas are checked. Perhaps @WildByDesign can research if memory areas checked have a setting in the registry:
    https://www.theseus.fi/bitstream/handle/10024/110291/Ruotsila_Jukka_2.pdf?sequence=1
     
  23. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,343
    Location:
    Italy
    OK.;)
    We are waiting for the Microsoft patch..........
     
  24. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    That is a great point and the PDF document is a good reference for that. As far as I know, there is no way at the moment to configure the memory allocations which are protected nor do I know how to determine this within Fall Creators Update 1709 in WDEG or registry modifications. I quite liked the granular control that we once had with EMET.

    If you have Twitter, I think that you should voice this concern directly to Matt Miller (@ epakskape) since he is at the root of almost all of those process mitigation developments. Or alternatively, you could bring this up with Will Dormann (@ wdormann) of CERT if this requires an advisory as he has a special interest in process mitigations in general.
     
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I just noticed something that might be the reason why WDEG is failing the heap spray test. If you read the HMP-A Test Tool documentation, it makes specific ref. to disabling its own CGI protection for calc.exe for the first two heap spray tests. Well when the test tool runs on Win 10 1709, it is not starting calc.exe in either the System32 or SysWOW64 directories. It is in fact starting calculator.exe which is a 64 bit Win Store app. Calculator.exe runs in AppContainer. So the question is if WDEG heap protection is N/A for AppContainer processes?

    -EDIT- On the other hand, I used 32 bit IE11 as the test target app versus the default calculator.exe and WDEG heap spray protection failed the tests. As mentioned previously, WDEG does detect the first two heap spray tests if using the 64 bit. vers. of the test tool.

    So it appears that there is a vulnerability in WDEG heap spray detection originating from a 32 bit process.
     
    Last edited: Nov 28, 2017
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.