Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Allegory of the cave(1)
Ähnlich wie Allegory of the cave(1) (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Allegory of the cave(1)
- 1. The Allegory of the Cave Has Application Whitelisting Coagulated As Expect?
- 3. Curt Shaffer Curt Shaffer has been in the IT field for 15 years. His experience is diverse across the IT field from ISP network design and installation, to server engineering for small and medium business as well as a number of local and US federal international agencies as well as intrusion analysis, incident response and malware reverse engineering. His change over the past 5 years has been his security focus. A majority of his security work most recently has been building internal threat intelligence for federal agencies and in his current position as the Owner of and Sr. Threat Researcher, for Symbiotic Network Technologies, LLC he analyzes current and new trends in that attack landscape in order to provide organizations with a realistic view of how they are being attacked and what can be done about it. He holds a number of industry standard certifications including CISSP, SANS:GREM, GCIA, GCIH, GPEN, GSEC and a number of CompTIA and Microsoft certifications.
- 4. Judah Plummer Works at Foreground Security - SOC Analyst Extraordinaire Math and Comp. Sci. Degree from University of Pittsburgh He has worked on validating these findings (found a 0 day once), and has assisted with the deployment and management of these applications in large deployments. Also, found a DLC License bypass for Xbox (possible upcoming NovaHackers talk?).
- 5. Put to the Test
- 6. Put to the Test McAfee – Popular choice for government and others Bit9 – Popular due to ease of deployment App Locker – Built in/No extra cost
- 7. Previously …with some updates Windows File Protection Didn’t work Java Exploits All day long Payloads Iexpress Didn’t Work
- 8. Previously …with some updates Adobe Worked Javascript Worked VBA Worked Shellcode Worked
- 9. Previously …with some updates Other findings: Intercepting the Bit9 Client traffic (Fiddler FTW!) Rubber Ducky Powershell injections Disabling the Service
- 10. Why Is This Still a Problem? “While we believe Bit9 is the most effective protection you can have on your endpoints. “ https://blog.bit9.com/2013/02/25/bit9-security-incident-update/
- 11. 30 days to life? The 90's called, they want their trial bypass back
- 12. Let Me In?
- 13. Just Ask Nicely
- 15. New Bypasses? DLL Hijacking Watering Hole Attacks Modifying Executable File Types Dynamic Annotation techniques and similar dynamic building techniques Microsoft Winhttp Security ID Modifications
- 16. DLL Hijacking DLL Hijacking has been used in the past as a persistence method. We tested to see if we could trick the whitelisting solution into executing the hijacked DLL with our own malicious code. Worked like a champ!
- 17. Watering Hole Attack Have become more popular in advanced attacks There is a huge range of techniques that can be taken advantage of and growing with new technologies such as HTML5. Files can be called/executed by trusted applications and their plugins.
- 18. Modifying Executable File Types Change file types, such as .txt files to be executable Changing the “Magic Number” of files, to be repaired later, after it has been overlooked due to being non-standard filetype and thus being ignored by Bit9.
- 19. Dynamic Annotation New technique for some interesting malware applications. Build MOF executable from samples scripts pulled from trusted sites, such as Microsoft’s Technet, and build them on the fly with VB is one example we have seen used in the wild We are working on a talk for later this year on the topic with a POC botnet.
- 20. Winhttp Our guess: not a lot of work has been put into protecting the new WinHTTP remote administration components of Windows. Execute malicious code through this trusted process. Any other system/admin tools that need to be trusted?
- 21. Security ID Modifications Is whitelisting on a per user basis? Have all types of users, including null user SIDs, been taken into account? We didn’t have a lot of time to test modifying the SIDS of services and files, but it’s our guess this would work rather well.
- 22. Chris John Riley’s PySC Shellcode from DNS TXT records Or via Internet Explorer (using SSPI) Works on the latest version we tested! Thanks Chris! Code link in the notes.
- 23. Future Considerations Macintosh Bypasses More HTML5 Features Trusted Directory or Trusted User Abuse Hash Collision Fun Metasploit Module
- 24. Metasploit Module Codename: “The Alan P@rs0ns Project: Sharks with friggin lasers” Menu Options/Functionality: Operating System Version Vendor Choice Exploit/Bypass Style, Choice Payload Choice Post Exploitation
- 25. Questions?
- 26. Contact Info curt@symbioticnt.net @inetopenurla (My blog…hope for a revival soon ) @bit0day (to follow releases of details of our findings) jplummer@foregroundsecurity.com
Hinweis der Redaktion
- To answer the question on the first slide, it is our belief that these solutions are still easily bypassed, and in some cases using the exact same methods discussed previously in the Raising the White Flag talk 2 years ago. The number of findings we uncovered would show, while they fixed some of the egregious problems pointed out before, they have not gotten much better overall and still have a lot of work to do.
- We wanted to bring up first that most of this talk is on the findings on Bit9 Parity 7.1.3, not because we have an agenda against them, but because frankly they kept us busy enough to fill up info for a talk in itself. We hope to add how the others have done in the next version when we release the details of the Bit9 bypasses we found.
- When we say something “worked” or “didn’t work” in the slides here, we are speaking from the context of the attacker. So worked means we were able to bypass, and did not work means that the application whitelisting stopped the attempt. We also thought it was necessary for us to cover the previous findings at least at a high level for those who may not have caught the first talk on this 2 year ago at Shmoocon. Windows File Protection Attacks did not appear to work for our testing. Even if we were able to modify the WFP protected files, the hash would change, thus requiring other techniques to utilize this method. We aren’t saying it wouldn’t be successful in those cases, just by default it didn’t work for this reason. We tried to utilize an old malware technique that was successfully used by malware in Windows XP in the past. The idea was that in Windows XP, if you started a process (i.e lets say calc.exe) with a name of one of the files in WFP (i.e. lets say winlogon.exe), you would not be able to kill the process because it was “protected” by Windows. We saw some inconsistent results in testing this in the previous research. We did not spend much time on this for this talk as we tested on Windows 7 and Window 8 only which utilize hashes for these protections now rather than just the name as Windows XP did. Java again worked in both exploits that lead to further payloads to be run such as Java Meterpreter (can we request railgun access via this method please?? Maybe call it jailgun :P) Java payloads also worked. It should be noted that this works and will continue to work based on organizations requiring obsolete Java code in their environment. We actually have been told by at least one customer that the flaw in the version they required in their code was a function they relied on and thus would allow for legacy applications! This is more of an organization issue rather than a Bit9 or other white listing flaw. Iexpress is a packaging utility that actually digitally signs the outer most component with a certificate by Microsoft! We found this to work in earlier versions of App Locker due to the lack of subsequent checks on the files inside the singed exterior pacakge. From our analysis this is no longer possible on any of the tested applications.
- Adobe Flash and PDFs worked in both exploits and the payloads used once again. The main problem here, as you will hear us say over and over, is that it is now and will continue to be, an exploitation of required trust in an application that will be the way in by attackers. More granularity would be needed to fix this problem in our opinion. (thinking of like per function analysis or something) Javascript worked to execute payloads due to the inherent trust of the browser. We were able to bypass these solutions by executing local Javascript via Browser plugins or in conjunction with other methods (such as HTML5 local storage, Shellcode, and Powershell). VBA worked in a few different ways. The one that was most notable was by executing direct shellcode from the VBA (as discussed by Dider Stevens and others http://blog.didierstevens.com/programs/shellcode/) Shellcode worked for us to bypass Bit9 using the VBA loading method as well as using Power Syringe (as can be found http://www.exploit-monday.com/2011/11/powersyringe-powershell-based-codedll.html among other places. )
- Bit9 still does not appear to be insisting the SSL certificate to be more than trusted from our analysis. We were still able to intercept the traffic by using an overall trusted certificate. This was possible due to Bit9 checking the certificate be valid, but that is all. We were also able to use Fiddler (http://www.telerik.com/fiddler) to do the same actions utilizing the ever so awesome feature that Fiddler uses to do the interception at the API level! Once we had access to the unencrypted sessions, we were able to just execute the commands on the client to shut the protection off, or permit new files for x amount of time or even trust our hash. Essentially anything that is capable from the server interface, we could do by faking or intercepting traffic to the client from the server. Again, not sure what the best fix is for Bit9 in this case other than looking for some more specific in the cert or some sort of further validation of the communication streams. The last two items here require physical access. I think we can all agree that physical access to a system is generally game over for any protection in most cases. There is nothing new to report here on the techniques discussed in the previous talk other than they continue to work as before.
- We mentioned the above statement as an example of the marketing of some of these companies were leading people to believe they were a silver bullet to stop all badness. After the talk we gave this year at the Shmoocon Epilogue the CSO of Bit9 said they changed the wording of their marketing in order to make this apparent. We found the following document http://www.torusinc.com/partners/bit9/ that states, to quote the article, "That stops all forms of malware”. This had a data from this year according to our Google searches on the topic. We have stated many times that we are not saying whitelisting is not a step in the right direction. In fact the speakers on this version of the talk were part of one of the largest full lock down deployments of Bit9, at the time of the initial research, that spanned 135 sites internationally. Even though we were able to see bypasses working in the logs of Bit9 Parity, the fact that we were able to see these things assisted in completely identifying one of the largest incidents either of the speakers of seen in their IR experience to date. This included finding one of the 5 persistence methods being used by the attacker which showed the attacker had modified the sethc.exe (sticky keys exe) on all of the domain controllers to be cmd.exe which provided System level access to the DCs by pulling up an RDP session, hit shift 5 times and bingo! System shell on the DC. The visibility was enough to make the product worth it in this case, so we don’t want to seem like bashers of the product.
- So due to Juddah (sorry for calling you out dude ;) ) forgetting to take a snapshot before installing the Bit9 software, we found an interesting trail bypass. He suggested, we should just try to uninstall and reinstall and see if that works. I said something to the effect of that hasn’t worked since the 90s but we have nothing to loose. Turns out, just uninstall and reinstall the software and your trial is restarted. No modifications to existing policies, rules, approvals etc were done. Picked right back up where we left off only with 29 more days of trail open to us. Didn’t even need to reboot! We realize this isn’t a vulnerability per say, but couldn’t help but saying the 90s called and wants their trial bypass back!
- The sysinfo output is included on the right here and in the next slide to show it was the same system.
- They did fix the vulnerability we talked about in Raising The White Flag it appears. This vulnerability was found based on previous research a few years before the talk was given where the attacker was able to inject into the parity.exe process and obtain full execution. Curt found that this was fixed in the 6.0 version tested, but the child process of parity.exe, named notifier.exe was not protected and provided full execution to the attacker yet again! This included the ability to run any file whitelisted or not, and even specifically blacklisted files, due to exploiting the chain of trust of the processes. The screenshot above was to show that it appears they have fixed this problem in the lastest version tested. We will admit, we didn’t track down and test all of the other possible children processes to ensure it was a full fix this time so it may still be possible on another child process!
- We did not release a lot of information on these findings yet as we have not had time to fully disclose them to the vendor via our standard method and timeframe. We do plan on doing a follow up on this talk later in the year which we will release the full details and the proposed Metasploit module. We Would like to add that we did test Chris John Riley’s PySC (https://github.com/ChrisJohnRiley/PySC) and that was successful as well. We forgot to mention that in the talk but wanted to ensure that we brought it out. We do want to ensure it is understood by the community and the vendor that these techniques were successful and repeatable. The astute in the audience can probably put 2 and 2 together and figure out the details based on what we mentioned here.
- This was tested and documented fully by Judah and myself. This technique works very well. https://www.mandiant.com/blog/dll-search-order-hijacking-revisited/ Thanks to Mandiant for the initial research!
- This attack is becoming very common, especially among advanced attackers. Simulating such an attack allowed the one test of modifying the executable file PE Header (Discussed in the next slide) to work in bypassing the protections. We have not explored HTML5 fully yet, but our thought is that is where watering hole techniques will move to in the future and will only add to the success of these attacks on organizations running whitelisting solutions.
- The first option here we did’t fully test mainly because of the requirement to have access to the system at an advanced level before launching an attack. We suppose that if an attacker used one of the other techniques used to gain the initial access, this would be a very efficient persistence method to maintain access on the compromised system. The second technique mentioned here worked in our testing in conjunction with watering hole scenarios where we dropped the file with a modified PE header (just a Z rather than MZ as would be expected) Then modifying the seemingly ignored file (ignored by the whitelisting solution), via future code from the watering hole site. It is expected that this “on the fly” modification would work with the drop happening on any of the stated bypasses and also include other methods discussed from the last talk such as using Firefox Plugins and local storage options via HTML5 and Javascript as well.
- We won’t go into a lot of details on what Dynamic Annotation is or the depths in which we tested this. The main reason is because we plan on releasing a talk later in the year on this topic with a POC botnet utilizing this technique for not only bypassing whitelisting but bypassing a lot of protections on the endpoint. The main thing we will say is that this is basically the direct API access utilized by the Windows “Accessibility Options”. As you can imagine, that is pretty low level access and a big win from the attackers standpoint.
- WinHTTP provides a HTTP interface to API access on systems. http://msdn.microsoft.com/en-us/library/windows/desktop/aa382925%28v=vs.85%29.aspx. To more fully clarify a member of the audience asked if we were referring to WinRM which provides HTTP via SOAP access to systems for remote management. http://msdn.microsoft.com/en-us/library/aa384426%28v=vs.85%29.aspx. We wanted to point out that WinRM utilizes the WinHTTP access to provide the remote management capability. So while based on the same idea, the two are not the same exact feature. As with many of the bypasses, we expect administrators to see this as a valuable tool to script or automate administration of systems. While it needs to be turned on or configured as a “listener” before it is able to be used, we do not see that being a problem. The first flag we would bring out is please at least use HTTPS obviously but think twice before allowing this to be run on your systems as it will bypass whitelisting due to the inherent trust to the process.
- This technique is most successful when an attacker is attempting to execute a file or service that is only permitted based on system or per user/group basis. Again previous access to the system must be gained in order to execute this bypass from our limited research. We suppose that if the SID is known before the file is dropped, there may be a possibility to drop the file with the necessary SID predefined and thus allowing execution.
- We forgot to mention this on the day of the talk, but we did test Chris John Riley’s script PySC. This script downloads shellcode from a remote DNS server (using TXT records) or through Internet Explorer (using SSPI to utilize system-wide proxy settings and authorization tokens) and injects it into a specified process. Our testing on this was successful with the latest version. Again because of the exploitation of trust of the calling process. Thanks goes out to Chris on this script and the permission to use it in our research and findings! https://github.com/ChrisJohnRiley/PySC
- We wanted to test the Mac client that Bit9 Parity added, but we did not have the version required (it is our belief that 7.1.4 is required and we only had access to 7.1.3). We may add findings on this side in the next version if we can get the proper version to test with. We really want to explore how bad HTML5 makes it for these types of protections. I believe Kevin Johnson from Secure Ideas released a talk on the possibility of using HTML5 to play a recorded command at an audio level unable to be heard or understood by the human ear, but at a level the mic on the system could pick up and then execute the command on the system via the commands received by the mic. The built in ability of HTML5 to both play and listen via the mic for such things is an example of the badness we fear is waiting for us in the HTML5 arena. We already know that many people that have chosen Bit9 is due to the ability to trust directories for automatic approval for things such as SCCM, Bigfix etc. We also know from experience our admins of such services do not often protect these directories as much as they should! Therefore we are certain there are fun things to play with to attempt getting our code approved for running on endpoints. They also, along with other vendors, provide the capability to trust executables running by a trusted “publisher”. We haven’t seen that backfire have we? :P https://blog.bit9.com/2013/02/08/bit9-and-our-customers-security/
- We plan on developing and releasing a Metasploit module do provide a menu driven capability for people to use these and future findings on internal pentests or testing their environments to see if they are vulnerable or not. This is much like what the guys are doing with the Veil Framework https://www.veil-framework.com. Only their focus is and will be Anti Virus and our focus is mainly whitelisting. We do see a crossing of the streams as far as the end goal, but for now I call them out only to provide an idea of what we look to accomplish with our tool.
- I am trying to add as many of the questions that came out during the Q/A section of the talk here. If I miss someone thing that was asked, please feel free to email me. I’m happy to provide information other than full details until we feel the disclosure is proper. You can probably look forward to the next version later in the year at something like Derbycon or SecTor or something similar.