NanoSec Conference 2020 - REvisiting Software Security - State the Art

A presentation in NanoSec Conference 2020 held virtually with topic Revisiting Software Security.

Transcript

1. REvisiting Software Security - State the Art Nafiez (@zeifan) Yeh (@iamyeh)
2. About Us Special interest group located in Malaysia with passion in bug hunting, software security, fuzzing, reverse engineering and exploits. We called ourselves TomatoDuck Fuzzing Group. Some of our notable work can be found here: - http://zeifan.my/ - https://fakhrizulkifli.github.io/
3. Agenda ➔ Overview of Software Security ➔ Our Approach on Hunting Vulnerability ➔ Modern Exploitation ➔ Vulnerability Disclosure - Best Defense is Offense
4. Overview of Software Security
6. What Makes It Failed? 3rd party software developer do not follow mitigations built by Microsoft, e.g. compiler options. Lack of Secure Development Lifecycle. Ignorance from vendor by trying to avoid fixes. Security is expensive.
7. What’s Happening Here? Microsoft has improved so many things including killing bug classes. Finding vulnerability is SUPER hard. Exploit mitigations on different aspects, vulnerability become useless. Exploit development costly.
8. Our Approach on Hunting Vulnerability
9. General Discussion Usually we’ll go from low hanging fruit to the complex part. Our previous work on hunting vulnerability in Antivirus covering various security issue and methods. The methods are almost similar, it’s just depends on your target. Sometimes we studied other researchers’ bugs, we analyzed from scratch to understand how it works. We used the case studies for different test case.
10. General Discussion Easiest way to hunt for vulnerability is the access to source code. However it is impossible to have access to source code when it comes to closed source program. Heavily involved in reverse engineering. One way to approach is to fuzz. Fuzzing is hard!
11. Fuzzing (⅓) We still rely on traditional method such as file format fuzzing - Byte and Bit mutation FTW! We perform variant hunting - APIs, Functions, etc. Dumb & Smart Fuzzing - Custom & Public
12. Fuzzing (⅔) Our resources, 128GB of memory - Split into multiple VMs, can up to 8 VMs running parallel - Tweak Windows VM to get a better performance - Pipe out results to external disk for easy access Corpus - Depends on target, e.g. PDF, DOC - Hundreds to thousands files, from 1KB up to 30MB+
13. Fuzzing (3/3) We got number of CVEs For custom fuzzer, we built a fuzzer that specific to work on the target ONLY! - Limited to the target itself Public fuzzer, we used any available fuzzers such as WinAFL and CERT BFF - WinAFL supports coverage guided, APIs - CERT BFF only file format, support custom Python plugin
14. Overall Stats / Results
15. Our Custom Fuzzer (½) File format fuzzing still effective these days, although it slow but we do found numbers of vulnerabilities. - Mutation on input file - e.g. file.exe input.test - Covering bit flip - Random, Range values - 0x0 to 0xFFFFFFFFFFFFFFFF - Strings, special characters - Detecting crashes via debugger, slow but it works :) - cdb, PyKD or WinAppDBG - Page Heap enabled
16. Our Custom Fuzzer (2/2) Detecting crashes could trigger false alarm - Split out the result by performing a better filtering - Check last exceptions e.g. address NULL or has something on memory / register - Important info - Access violation - Last crash disassembly code, Register value, Stack trace (sometimes inaccurate) - At some cases, this required manual verification.
17. Results from Custom Fuzzer Remote Code Execution: CVE-2020-0980 - Microsoft Word CVE-2020-16957 - Microsoft Access CVE-2020-25291 - WPS Office Some don’t assign with CVE, e.g. Foxit PDF Software We still have pending from vendors. Stay tuned!
18. WinAFL Fuzzing Effective but hard to use - Originally from AFL, now implemented on Windows - It supports instrumentation, this giving advantage for coverage guided fuzzing - Doesn’t work on all environment, our test case only works on Windows 10 1511 - You can port a custom mutator - We found numbers of vulnerabilities using WinAFL
19. WinAFL Fuzzing - At some cases it required reverse engineering and code writing - Writing harness - Ideally you fuzz on assembly level, you have to extract that disassembly path and turn it into code - e.g. If the API available on MSDN, easy to write the harness - Much more faster however input file only max to 1MB - Minimum resources available on Internet, but you can get the idea how it works :)
20. Example Results of WinAFL Info Leak: MSRC Case 58680 - Windows GDI MSRC Case 58593 - Windows GDI MSRC Case 58745 - Windows GDI MSRC Case 58843 - Windows GDI
21. CERT BFF (½) CERT BFF - Perform mutational fuzzing on software that consumes file input - Easy to use, just configure the YAML plugin - Our member found out that you can plugin your own fuzzer engine scripts (Python) - e.g. Using another public fuzzer such as Radamsa to call the specific parameter to perform mutational. Radamsa will responsible perform this mutation and the results still pipe to the BFF for triage
22. CERT BFF (2/2) - We found numbers of vulnerabilities using this fuzzer - We tested out the custom scripts that we ported and the default fuzzer scripts. - We found out if it is running more than 48 hours, the performance will turn slow - The option is to reboot VM for every 2-3 days and restart the process based on the last execution - No limit on the file size but can turn the program to load slow. - At some cases, it will crash due to several factors such as fail fast, out of memory, etc.
23. Example Results of CERT BFF Remote Code Execution: CVE-2020-10222 - Nitro PDF Software CVE-2020-10223 - Nitro PDF Software CVE-2020-25290 - Nitro PDF Software CVE-2019-19817 - Nitro PDF Software CVE-2019-19818 - Nitro PDF Software CVE-2019-19819 - Nitro PDF Software Some don’t have CVE - Multiple software
24. Modern Exploitation
25. State the Art Memory corruption exploitation used to be easy Historically been exploited for decades Past mitigations not powerful enough to prevent exploitation
26. Vulnerability Mitigations Control Integrity Guard Arbitrary Code Guard Memory Garbage Collector Control Flow Guard GS (Buffer Security Check) Address Space Layout Randomization Data Execution Prevention NULL Dereference Protection
27. https://ctf-wiki.github.io/ctf-wiki/pwn/windows/stackoverflow/figure/demo2-1.png
28. https://jnet.i.lithium.com/t5/image/serverpage/image-id/18394i1F93FD8C873152B4/image-size/large?v=1.0&px=999
29. https://www.blackhat.com/docs/asia-17/materials/asia-17-Li-Cross-The-Wall-Bypass-All-Modern-Mitigations-Of-Microsoft-Edge.pdf
30. https://twitter.com/zeifan/status/1298074650098819072/photo/1
31. Case Study - Windows GDI CreateDIBitmap Out-of-Bounds Out-of-Bounds Read vulnerability found in Windows GDI CreateDIBitmap. Reported to MSRC (58593) with the potential exploitation that leads to info leak. No fix due to by design. We couldn’t demonstrate full behavior of the exploitation due to limitation of vulnerability that we had, which requires multi-chain.
32. Continue Vulnerability was found via fuzzing with WinAFL. An invalid pointer read error inside GDI32!CreateDIBitmap API function was found when it tries to copy specially crafted bitmap data. Further analysis found the vulnerability could be exploited to achieve information leakage.
33. An access violation occurred when harness triggered crash on memcpy() Backtrace shows the memcpy() was called in GDI32!CreateDIBitmap Crash Triage
34. Bug Analysis (½) The 4th argument was passed as a pointer to an array of uninitialized data which later passed as source for memcpy to an allocated heap of fixed size. 6fd67ae is 4th argument Before reaching to the part where the input is copied, there is a check to test if the 3th bit of the pointer address is set or not.
35. Bug Analysis (2/2) Once the check is satisfied, the CreateDIBitmap copies the uninitialized data to the allocated heap of size 0x200 and then triggers the Invalid Pointer Read error. With this information, we could achieve info leak.
36. Exploitation (1/2) To achieve info-leak, CBM_INIT must be set so that the system would use the data pointed by the 4th argument because we are going to spray it with the index of the color table data and the color table must not be initialized. The heap allocation must be large enough to make sure the masked pointer still points to our sprayed data.
37. Exploitation (2/2) Example of Proof-of-Concept
38. Modern exploitation is hard. To achieve powerful exploitation, one has to chain to multiple vulnerabilities. Costs of exploit development will continue grow. What Now?
39. Vulnerability Disclosure
40. Vuln Disclosure - General (½) Vulnerability disclosure debate has been there for many years. Some people like it, some against. Painful process for both party, researchers and vendors. Most vendors these days came with vulnerability disclosure process.
41. Vuln Disclosure - General (2/2) Vendors give feedback, appreciate the work, give bounty. Some vendors don’t really have proper channel to disclose vulnerability, e.g. no PGP Delay in response and sometimes silent fixes has been shipped to customer.
42. Do’s? When disclosing vulnerability, try to provide as much info. Use all the medium for contact e.g. social media, general email. Reach to people / researchers out there if you need help. You can go as Anonymous if you want, Full Disclosure might work. Get CERTs involved.
43. Don’ts? Just never disclose anything not until things are settle. Most vendors co-operate these days, they might slow or you need to push a bit. Before you post anything, make sure to inform vendor and get their opinion. If it doesn’t work, get your peers to help you. Seek for advice :)
44. Vuln Disclosure - Malaysia (½) Disclosing vulnerability to vendor in Malaysia is pain. Vendors / Companies trying to avoid those, just don’t care about security. Past years we saw case(s) vendor tend to sue. Vendor keeps ignore / deny. Poor vulnerability management, remediation and security response processes.
45. Vuln Disclosure - Malaysia (2/2) No one knows you, probably you go as anonymous so no one bother. Vendors think they do better than you. Ignorance is bliss. Its 2020, security should be prioritize. Real World example - https://blog.rz.my/2020/08/reality-on-responsible-vulnerabil ity.html
46. Case Study: Kyrol Labs We started to look into Kyrol Internet Security product somewhere end of 2018. Tooks us total 5 days to find 12 vulnerabilities, with severity Informational to Critical. Our first email to them on January 2, 2019 and they responding 2 days after. The conversation via email until May 2, 2019. Nothing works. We were looking for alternative before we about to do full disclosure. Let’s take a look into the timeline of disclosure :)
47. Jan - Apr May Jun Aug Oct Nov 2 Jan - Sending first email to Kyrol Labs 4 Jan - Follow up and vendor respond 8 Jan - They informed us the product is obsolete, we asked for further update like fixes, etc. 10 Jan - We told them we’ll go full disclosure and they try to deny. We gave 90 days standard disclosure. 15 Jan - Vendor told us they will fix and expect on April. 16 Apr - Follow up with vendor as the 90 days has reach. They told us they can’t fix the issue. 18 Apr - We told them we couldn’t wait. We seek for advice from local community before full disclosure. 18 Apr - Friend from local community help to liaise with NACSA. We sent vulnerability report to them. NACSA responding the same day saying that they’ll look into it. 29 Apr - NACSA invite us for discussion over video conference on May 3. 2 May - Seek update from vendor. No reply at all. 3 May - Video conference with NACSA. Presented 12 vulnerabilities to them. NACSA coordinated the case to vendor. 13 Jun - Seek update from NACSA. They have followed up via call and email. 28 Jun - NACSA invite for video conference with vendor. We made a choice by giving them surprise with 12 vulnerabilities we found. They said will look into it and will try to fix the highest severity. 16 Aug - Seek update from vendor. They told us they manage to identified the vulnerability reported. 22 Aug - Our paper in POC Seoul got accepted and presenting Kyrol security issue to public in Nov. 23 Aug - We informed vendor and NACSA we’ll be discussing the vulnerability to public. 26 Aug - We were told by vendor they will be releasing new product in Nov. 29 Oct - NACSA invite us for final discussion with vendor, face-to-face meeting on Nov 1. 1 Nov - Face-to-face meeting. Vendor told us they can’t deliver the fix nor ship new product in Nov. During discussion, we told NACSA that we’ll be disclosing the issue public due to disclosure timeline has exceeded (almost a year). We discuss the matter of impact. NACSA agree with our decision and they required vendor to fix the issue no matter any constraint.
48. Vuln Disclosure in Malaysia We seen that agencies like NACSA and MyCERT slowly getting better at it. If you found vulnerability, report to NACSA or MyCERT. CNII prioritized by them. - NACSA usually drive the process and can help you to hide your profile. - Don’t publish to public, not until you get things settle with the agencies. - We can help you if you need help to work closely with them You can contact them via cert@nc4.gov.my or cyber999@cybers ecurity.my
49. Conclusion ➔ Best defense is offense ➔ We help the community to eliminate vulnerabilities ➔ Engage with vendors for bugs fix ➔ Future works in planned, fuzzing hypervisor and custom fuzzer with Qiling ➔ Feel free to ping us at twitter ➔ We are open for new blood to join us on these journey
50. Thank You & Stay Safe!