$30 off During Our Annual Pro Sale. View Details »

NanoSec Conference 2020 - REvisiting Software Security - State the Art

Nafiez
December 23, 2020

NanoSec Conference 2020 - REvisiting Software Security - State the Art

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

Nafiez

December 23, 2020
Tweet

More Decks by Nafiez

Other Decks in Research

Transcript

  1. REvisiting Software
    Security - State the
    Art
    Nafiez (@zeifan)
    Yeh (@iamyeh)

    View Slide

  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/

    View Slide

  3. Agenda
    ➔ Overview of Software Security
    ➔ Our Approach on Hunting
    Vulnerability
    ➔ Modern Exploitation
    ➔ Vulnerability Disclosure - Best
    Defense is Offense

    View Slide

  4. Overview of
    Software
    Security

    View Slide

  5. View Slide

  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.

    View Slide

  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.

    View Slide

  8. Our Approach on
    Hunting
    Vulnerability

    View Slide

  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.

    View Slide

  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!

    View Slide

  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

    View Slide

  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+

    View Slide

  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

    View Slide

  14. Overall Stats / Results

    View Slide

  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

    View Slide

  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.

    View Slide

  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!

    View Slide

  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

    View Slide

  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 :)

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  24. Modern Exploitation

    View Slide

  25. State the Art
    Memory corruption exploitation used to be easy
    Historically been exploited for decades
    Past mitigations not powerful enough to prevent exploitation

    View Slide

  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

    View Slide

  27. https://ctf-wiki.github.io/ctf-wiki/pwn/windows/stackoverflow/figure/demo2-1.png

    View Slide

  28. https://jnet.i.lithium.com/t5/image/serverpage/image-id/18394i1F93FD8C873152B4/image-size/large?v=1.0&px=999

    View Slide

  29. https://www.blackhat.com/docs/asia-17/materials/asia-17-Li-Cross-The-Wall-Bypass-All-Modern-Mitigations-Of-Microsoft-Edge.pdf

    View Slide

  30. https://twitter.com/zeifan/status/1298074650098819072/photo/1

    View Slide

  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.

    View Slide

  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.

    View Slide

  33. An access violation
    occurred when harness
    triggered crash on
    memcpy()
    Backtrace shows the
    memcpy() was called in
    GDI32!CreateDIBitmap
    Crash Triage

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  37. Exploitation (2/2)
    Example of
    Proof-of-Concept

    View Slide

  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?

    View Slide

  39. Vulnerability
    Disclosure

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  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 :)

    View Slide

  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.

    View Slide

  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

    View Slide

  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 :)

    View Slide

  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.

    View Slide

  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
    [email protected]
    or
    cyber999@cybers
    ecurity.my

    View Slide

  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

    View Slide

  50. Thank You & Stay Safe!

    View Slide