{"id":13539186,"url":"https://github.com/cryptolok/aslray","last_synced_at":"2025-04-02T06:30:27.945Z","repository":{"id":110323909,"uuid":"106934065","full_name":"cryptolok/ASLRay","owner":"cryptolok","description":"Linux ELF x32/x64 ASLR DEP/NX bypass exploit with stack-spraying","archived":false,"fork":false,"pushed_at":"2023-01-12T14:34:21.000Z","size":40,"stargazers_count":296,"open_issues_count":0,"forks_count":81,"subscribers_count":18,"default_branch":"master","last_synced_at":"2024-11-03T04:32:19.597Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cryptolok.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2017-10-14T14:22:47.000Z","updated_at":"2024-08-14T12:40:24.000Z","dependencies_parsed_at":"2023-04-15T04:14:38.058Z","dependency_job_id":null,"html_url":"https://github.com/cryptolok/ASLRay","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptolok%2FASLRay","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptolok%2FASLRay/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptolok%2FASLRay/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cryptolok%2FASLRay/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cryptolok","download_url":"https://codeload.github.com/cryptolok/ASLRay/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246767508,"owners_count":20830502,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T09:01:21.396Z","updated_at":"2025-04-02T06:30:27.612Z","avatar_url":"https://github.com/cryptolok.png","language":"Shell","funding_links":[],"categories":["\u003ca id=\"683b645c2162a1fce5f24ac2abfa1973\"\u003e\u003c/a\u003e漏洞\u0026\u0026漏洞管理\u0026\u0026漏洞发现/挖掘\u0026\u0026漏洞开发\u0026\u0026漏洞利用\u0026\u0026Fuzzing","\u003ca id=\"a63015576552ded272a242064f3fe8c9\"\u003e\u003c/a\u003eELF"],"sub_categories":["\u003ca id=\"41ae40ed61ab2b61f2971fea3ec26e7c\"\u003e\u003c/a\u003e漏洞利用","\u003ca id=\"929786b8490456eedfb975a41ca9da07\"\u003e\u003c/a\u003e工具"],"readme":"[![Rawsec's CyberSecurity Inventory](http://inventory.raw.pm/img/badges/Rawsec-inventoried-FF5050_flat-square.svg)](http://inventory.raw.pm/tools.html#ASLRay)\n\n# ASLRay\nLinux ELF x32/x64 ASLR DEP/NX bypass exploit with stack-spraying\n\n![](https://i.imgur.com/mBuqu8J.jpg)\n\nProperties:\n* ASLR bypass\n* DEP/NX bypass\n* Cross-platform\n* Minimalistic\n* Simplicity\n* Unpatchable\n\nDependencies:\n* **Linux 2.6.12+** - would work on any x86-64 Linux-based OS\n\t- BASH - the whole script\n\nLimitations:\n* Stack needs to be executable (-z execstack) for x64\n* Binary has to be exploited through arguments locally (not file, socket or input)\n* No support for other architectures and OSes (TODO)\n* Need to know the buffer limit/size\n\n## How it works\nYou might have heard of [Heap Spraying](https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/) attack? Well, [Stack Spraying](http://j00ru.vexillium.org/?p=769) is similar, however, it was considered unpractical for most cases, especially [ASLR](https://en.wikipedia.org/wiki/Address_space_layout_randomization) on x86-64.\n\nMy work will prove the opposite.\n\nFor 32-bit, there are 2^32 (4 294 967 296) theoretical addresses, nevertheless, the kernel will allow to control about only half of bits (2^(32/2) = 65 536) for an execution in a virtualized memory, which means that if we control more that 50 000 characters in stack, we are almost sure to point to our shellcode, regardless the address, thanks to kernel redirection and retranslation. According to my tests, even 100 or 10 characters are enough if the called function doesn't contain other variable creations, which will allow ROP-style attack.\n\nThis can be achieved using shell variables, which aren't really limited to a specific length, but practical limit is about one hundrer thousand, otherwise it will saturate the TTY.\n\nSo, in order to exploit successfully with any shellcode, we need to put a [NOP sled](https://en.wikipedia.org/wiki/NOP_slide) following the shellcode into a shell variable and just exploit the binary with a random address. Note that NOP sled isn't necessary, this is just to universalise the exploit.\n\n\nIn 64-bit system the situation is different, but not so much as of my discovery.\n\nOf course, you wouldn't have to cover all 2^64 possibilities, in fact, the kernel allows only 48 bits, plus a part of them are predictable and static, which left us with about 2^(4x8+5) (137 438 953 472) possibilities.\n\nI have mentioned the shell variables size limit, but there is also a count limit, which appears to be about 10, thus allowing us to stock a 1 000 000 character shellcode, living us with just some tenth of thousand possibilities that can be tested rapidly and automatically. This time however, you will need to bruteforce and use NOP-sleds in order to make things quicker.\n\nThat said, ASLR on both 32 and 64-bits can be easily bypassed in few minutes and with few lines of shell...\n\nThe DEP/NX on the other hand, can be bypassed on x32 using [return-to-libc](https://www.exploit-db.com/docs/28553.pdf) technique by coupling it with statistical studies of different OSes, more specifically, their ASLR limitations and implementations, which can lead to a successful exploitation for 2 reasons.\nThe rist one is being ASLR not so random in its choice and having some constants and poor entropy (easy to guess libC address and each OS has its own constants).\nThe second one is spraying the shell argument for libC into environment (easy to find and pass it to libC).\n\nTo conclude, DEP/NX on 32-bits is weakened because of ASLR.\n\nA more detailed description can be found in Hakin9-12-14 [issue](https://hakin9.org/download/hakin9-open-open-source-tools/).\n\n### HowTo\n\nIf you have exploited at least one buffer overflow in your life, you can skip, but just in case:\n```bash\napt install gcc libc6-dev-i386 || kill -9 $$\nchmod u+x ASLRay.sh\nsudo gcc -z execstack test.c -o test\nsudo gcc -m32 -z execstack test.c -o test32\nsudo chmod +s test test32\nsource ASLRay.sh test32 1024\nsource ASLRay.sh test 1024\nsource ASLRay.sh test 1024 \\x31\\x80...your_shellcode_here\nsudo gcc -m32 test.c -o test32x\nsudo chmod +s test test32\nsource ASLRay.sh test32x 1024\n```\nTo prove that NOP-sled isn't necessary for Debian x32:\n\n**!!! WARNING !!!** this will modify your /etc/passwd and change permissions of /etc/shadow, VM execution adviced\n```bash\nchmod u+x PoC.sh\nsource PoC.sh\ngrep ALI /etc/passwd\n```\nIn case it still doesn't work, just add some NOPs (\\x90) in the beginning.\n\nTo prove that even environmental variable isn't necessary for Debian x32:\n```bash\nchmod u+x PoC2.sh\nsource PoC2.sh\n```\n\nThus you can just put your shellcode into a variable and give random addresses to registers for a shell with ASLR, this is because the specific context where the function only has one variable which will be rewritten, so the stack will be popped to EIP just with our shellcode, which is more like a [ROP](https://www.rapid7.com/resources/rop-exploit-explained/) attack.\n\n\nFor Arch/Ubuntu you will also need to disable stack smashing protection and brute-force may take much longer (execution delay, probably due to brk(NULL/0) syscall or/and canary) :\n```bash\nsudo gcc -z execstack -fno-stack-protector test.c -o test\nsudo gcc -m32 -z execstack -fno-stack-protector test.c -o test32\nsudo gcc -m32 -fno-stack-protector test.c -o test32x\n```\n\nIn Debian 10, this issue was partially patched, notably due to AppArmor.\n\n#### Notes\n\nAlways rely on multiple protections and not on a single one.\n\nWe need new system security mechanisms.\n\n\u003e \"From where we stand the rain seems random. If we could stand somewhere else, we would see the order in it. \"\n\nTony Hillerman, *Coyote Waits*\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryptolok%2Faslray","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcryptolok%2Faslray","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcryptolok%2Faslray/lists"}