Leaderboard

Remote Code Execution In Source Games Valve's Source SDK contained a buffer overflow vulnerability which allowed remote code execution on clients and servers. The vulnerability was exploited by fragging a player, which casued a specially crafted ragdoll model to be loaded. Multiple Source games were updated during the month of June 2017 to fix the vulnerability. Titles included CS:GO, TF2, Hl2:DM, Portal 2, and L4D2. We thank Valve for being very responsive and taking care of vulnerabilites swiftly. Valve patched and released updates for their more popular titles within a day. Missing Bounds Check The function nexttoken is used to tokenize a string. Note how the buffer str is copied into the buffer token, as long as a NULL character or the delimieter character sep is not found. No bounds checking is performed. View source on GitHub. const char *nexttoken(char *token, const char *str, char sep) { ... while ((*str != sep) && (*str != '\0')) { *token++ = *str++; } ... } The Vulnerability The method ParseKeyValue of class CRagdollCollisionRulesParse is called when processing ragdoll model data, such as when a player is fragged. This method calls nexttoken to tokenize the rule for further processing. By supplying a collisionpair rule longer then 256 characters, the buffer szToken can be overflowed. Since szToken is stored on the stack, the return address of the ParseKeyValue method can be overwritten. View source on GitHub. class CRagdollCollisionRulesParse : public IVPhysicsKeyHandler { virtual void ParseKeyValue( void *pData, const char *pKey, const char *pValue ) { ... else if ( !strcmpi( pKey, "collisionpair" ) ) ... char szToken[256]; const char *pStr = nexttoken(szToken, pValue, ','); ... } } Mitigation Bypass Address Space Layout Randomization (ASLR) is a powerful mitigation against exploiting memory corruption vulnerabilities. The mitigation randomizes the addresses where executables are loaded into memory. This feature is opt-in, and all executables loaded into memory of a process must have it enabled in order for it to be effective. The DLL steamclient.dll did not have ASLR enabled. This meant the address of executable pages of steamclient.dll loaded into memory at predictable addresses. This allowed existing instructions within the executable memory pages to be located and used trivially. Collecting ROP Gadgets Return Oriented Programming is a technique that allows shellcode to be created by re-using existing instructions in a program. Simply put, you find a chain of instructions that end with a RETN instruction. You insert the address of the first instruction of the chain to the stack, so when a function returns the address is popped into the Instruction Pointer register, and then the instructions execute. Since x86 and x64 instructions do not need to be memory aligned, any address can be interpreted as an instruction. By setting the instruction pointer to a middle of an instruction, a wider range of instructions become available. The Immunity Debugger plugin Mona provides a utility to discover gadgets. Be aware though, the plugin doesn't find all useful gadgets, such as REP MOVS. Launching cmd.exe Due to the way the payload is processed, NULL characters can not be used, and upper case characters are converted to lower case characters. This means our ROP gadget addresses becomes limited, as well as any other data used in our payload. To get around this, the shellcode is boostraped with with a gadget chain which locates the original un-modified buffer in memory. The un-modified payload is then copied back onto the stack via a REP MOVS gadget. The steamclient.dll executable imports LoadLibraryA and GetProcaddressA. This allows us to load other DLLs into memory, and obtain references to additional exported functions. We can import Shell32.dll to obtain a reference to the function ShellExecuteA, which can be used to launch other programs. Proof Of Concept In order to give third-party mod creators time to update their games, the proof of concept will be released in 30 days. Source mod developers should apply the patch below. Delivering The Payload The Source engine allows custom content to be packed into map files. Commonly this is used for adding extra content to maps, such as sounds or textures. By packing a ragdoll model file into a map file, with the same resource path as an original ragdoll model file, our version will be used instead. Recommended Fix To prevent buffer overflows from occurring, do not store more data in a buffer than it can hold. The nexttoken function should accept a token length argument which would be used to perform bounds checking. Developers who have created a Source modification game should apply the following patch. To mitigate exploitation of memory corruption vulnerabilities, enable ASLR for all executables. Perform automated checks during the build process to ensure all executables support ASLR. This can be achieved by using the checkbins.py utility developed by the chromium team. Additionally, Source games should be sandboxed to restrict access to resources and to prevent new processes from being started. As an example of how effective proper sandboxing can be, kernel exploits are often used when exploiting web browser memory corruption vulnerabilities, since the userland browser process is so restricted. For additional information, refer to Chromium's sandbox implementation. Download Patch Final Thoughts Video games are interesting targets for exploitation, not only technically but also logistically. As video games are common inside employee break rooms and homes of employees, exploitation of a vulnerability could be used in a targeted attack to jump the air gap to a private network. Additionally, discovering a remote code execution vulnerability in a popular video game can be used to quickly create a bot net or spread ransomware. As a mitigation, games should not be installed on work devices. Gaming machines should be moved to an untrusted network, and business devicess should not connect to the untrusted network. For those who play Soruce games, the attack surface can be shrunk by disabling third-party content from downloading. This can be achieved with the console commands cl_allowdownload 0 and cl_downloadfilter all. Additionally, since the vulnerability was discovered in the Source SDK, additional third-party mods are most likely vulnerable. However, by enabling ASLR for all executable modules, a memory disclosure vulnerability is required to develop a reliable exploit. About the author: Justin Taft is a software engineer who is adamant about secure coding practices. He has worked with many Fortune 500 companies to improve their security posture of their products. From reversing firmware of biometric fingerprint readers, to performing security reviews of cloud based Java application deployments, he is experienced in tackling a wide range of security assessments. Sursa: https://oneupsecurity.com/research/remote-code-execution-in-source-games?t=r

http://rentajew.org/

DEBUGGING WITH GDB This is a very brief introduction into compiling ARM binaries and basic debugging with GDB. As you follow the tutorials, you might want to follow along and experiment with ARM assembly on your own. In that case, you would either need a spare ARM device, or you just set up your own Lab environment in a VM by following the steps in this short How-To. You can use the following code from Part 7 – Stack and Functions, to get familiar with basic debugging with GDB. .section .text .global _start _start: push {r11, lr} /* Start of the prologue. Saving Frame Pointer and LR onto the stack */ add r11, sp, #0 /* Setting up the bottom of the stack frame */ sub sp, sp, #16 /* End of the prologue. Allocating some buffer on the stack */ mov r0, #1 /* setting up local variables (a=1). This also serves as setting up the first parameter for the max function */ mov r1, #2 /* setting up local variables (b=2). This also serves as setting up the second parameter for the max function */ bl max /* Calling/branching to function max */ sub sp, r11, #0 /* Start of the epilogue. Readjusting the Stack Pointer */ pop {r11, pc} /* End of the epilogue. Restoring Frame pointer from the stack, jumping to previously saved LR via direct load into PC */ max: push {r11} /* Start of the prologue. Saving Frame Pointer onto the stack */ add r11, sp, #0 /* Setting up the bottom of the stack frame */ sub sp, sp, #12 /* End of the prologue. Allocating some buffer on the stack */ cmp r0, r1 /* Implementation of if(a<b) */ movlt r0, r1 /* if r0 was lower than r1, store r1 into r0 */ add sp, r11, #0 /* Start of the epilogue. Readjusting the Stack Pointer */ pop {r11} /* restoring frame pointer */ bx lr /* End of the epilogue. Jumping back to main via LR register */ Using GDB Enhanced Features with GDB is highly recommended. root@labs:~# wget -q -O- https://github.com/hugsy/gef/raw/master/gef.sh | sh Save the code above in a file called max.s and compile it with the following commands: $ as max.s -o max.o $ ld max.o -o max The debugger is a powerful tool that can: Load a memory dump after a crash (post-mortem debugging) Attach to a running process (used for server processes) Launch a program and debug it Launch GDB against either a binary, a core file, or a Process ID: Attach to a process: $ gdb -pid $(pidof <process>) Debug a binary: $ gdb ./file Inspect a core (crash) file: $ gdb -c ./core.3243 $ gdb max If you installed GEF, it drops you the gef> prompt. This is how you get help: (gdb) h (gdb) apropos <search-term> gef> apropos registers collect -- Specify one or more data items to be collected at a tracepoint core-file -- Use FILE as core dump for examining memory and registers info all-registers -- List of all registers and their contents info r -- List of integer registers and their contents info registers -- List of integer registers and their contents maintenance print cooked-registers -- Print the internal register configuration including cooked values maintenance print raw-registers -- Print the internal register configuration including raw values maintenance print registers -- Print the internal register configuration maintenance print remote-registers -- Print the internal register configuration including each register's p -- Print value of expression EXP print -- Print value of expression EXP registers -- Display full details on one set may-write-registers -- Set permission to write into registers set observer -- Set whether gdb controls the inferior in observer mode show may-write-registers -- Show permission to write into registers show observer -- Show whether gdb controls the inferior in observer mode tui reg float -- Display only floating point registers tui reg general -- Display only general registers tui reg system -- Display only system registers Breakpoint commands: break (or just <function-name> break <line-number> break filename:function break filename:line-number break *<address> break +<offset> break –<offset> tbreak (set a temporary breakpoint) del <number> (delete breakpoint number x) delete (delete all breakpoints) delete <range> (delete breakpoint ranges) disable/enable <breakpoint-number-or-range> (does not delete breakpoints, just enables/disables them) continue (or just c) – (continue executing until next breakpoint) continue <number> (continue but ignore current breakpoint number times. Useful for breakpoints within a loop.) finish (continue to end of function) gef> break _start gef> info break Num Type Disp Enb Address What 1 breakpoint keep y 0x00008054 <_start> breakpoint already hit 1 time gef> del 1 gef> break *0x0000805c Breakpoint 2 at 0x805c gef> break _start This deletes the first breakpoint and sets a breakpoint at the specified memory address. When you run the program, it will break at this exact location. If you would not delete the first breakpoint and just set a new one and run, it would break at the first breakpoint. Start and Stop: Start program execution from beginning of the program run r run <command-line-argument> Stop program execution kill Exit GDB debugger quit q gef> run Now that our program broke exactly where we wanted, it’s time to examine the memory. The command “x” displays memory contents in various formats. Syntax: x/<count><format><unit> FORMAT UNIT x – Hexadecimal b – bytes d – decimal h – half words (2 bytes) i – instructions w – words (4 bytes) t – binary (two) g – giant words (8 bytes) o – octal u – unsigned s – string c – character gef> x/10i $pc => 0x8054 <_start>: push {r11, lr} 0x8058 <_start+4>: add r11, sp, #0 0x805c <_start+8>: sub sp, sp, #16 0x8060 <_start+12>: mov r0, #1 0x8064 <_start+16>: mov r1, #2 0x8068 <_start+20>: bl 0x8074 <max> 0x806c <_start+24>: sub sp, r11, #0 0x8070 <_start+28>: pop {r11, pc} 0x8074 <max>: push {r11} 0x8078 <max+4>: add r11, sp, #0 gef> x/16xw $pc 0x8068 <_start+20>: 0xeb000001 0xe24bd000 0xe8bd8800 0xe92d0800 0x8078 <max+4>: 0xe28db000 0xe24dd00c 0xe1500001 0xb1a00001 0x8088 <max+20>: 0xe28bd000 0xe8bd0800 0xe12fff1e 0x00001741 0x8098: 0x61656100 0x01006962 0x0000000d 0x01080206 Commands for stepping through the code: Step to next line of code. Will step into a function stepi s step <number-of-steps-to-perform> Execute next line of code. Will not enter functions nexti n next <number> Continue processing until you reach a specified line number, function name, address, filename:function, or filename:line-number until until <line-number> Show current line number and which function you are in where gef> nexti 5 ... 0x8068 <_start+20> bl 0x8074 <max> <- $pc 0x806c <_start+24> sub sp, r11, #0 0x8070 <_start+28> pop {r11, pc} 0x8074 <max> push {r11} 0x8078 <max+4> add r11, sp, #0 0x807c <max+8> sub sp, sp, #12 0x8080 <max+12> cmp r0, r1 0x8084 <max+16> movlt r0, r1 0x8088 <max+20> add sp, r11, #0 Examine the registers with info registers or i r gef> info registers r0 0x1 1 r1 0x2 2 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0xbefff7e8 3204446184 r12 0x0 0 sp 0xbefff7d8 0xbefff7d8 lr 0x0 0 pc 0x8068 0x8068 <_start+20> cpsr 0x10 16 The command “info registers” gives you the current register state. We can see the general purpose registers r0-r12, and the special purpose registers SP, LR, and PC, including the status register CPSR. The first four arguments to a function are generally stored in r0-r3. In this case, we manually moved values to r0 and r1. Show process memory map: gef> info proc map process 10225 Mapped address spaces: Start Addr End Addr Size Offset objfile 0x8000 0x9000 0x1000 0 /home/pi/lab/max 0xb6fff000 0xb7000000 0x1000 0 [sigpage] 0xbefdf000 0xbf000000 0x21000 0 [stack] 0xffff0000 0xffff1000 0x1000 0 [vectors] With the command “disassemble” we look through the disassembly output of the function max. gef> disassemble max Dump of assembler code for function max: 0x00008074 <+0>: push {r11} 0x00008078 <+4>: add r11, sp, #0 0x0000807c <+8>: sub sp, sp, #12 0x00008080 <+12>: cmp r0, r1 0x00008084 <+16>: movlt r0, r1 0x00008088 <+20>: add sp, r11, #0 0x0000808c <+24>: pop {r11} 0x00008090 <+28>: bx lr End of assembler dump. GEF specific commands (more commands can be viewed using the command “gef”): Dump all sections of all loaded ELF images in process memory xfiles Enhanced version of proc map, includes RWX attributes in mapped pages vmmap Memory attributes at a given address xinfo Inspect compiler level protection built into the running binary checksec gef> xfiles Start End Name File 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max 0x00008054 0x00008094 .text /home/pi/lab/max gef> vmmap Start End Offset Perm Path 0x00008000 0x00009000 0x00000000 r-x /home/pi/lab/max 0xb6fff000 0xb7000000 0x00000000 r-x [sigpage] 0xbefdf000 0xbf000000 0x00000000 rwx [stack] 0xffff0000 0xffff1000 0x00000000 r-x [vectors] gef> xinfo 0xbefff7e8 ----------------------------------------[ xinfo: 0xbefff7e8 ]---------------------------------------- Found 0xbefff7e8 Page: 0xbefdf000 -> 0xbf000000 (size=0x21000) Permissions: rwx Pathname: [stack] Offset (from page): +0x207e8 Inode: 0 gef> checksec [+] checksec for '/home/pi/lab/max' Canary: No NX Support: Yes PIE Support: No RPATH: No RUNPATH: No Partial RelRO: No Full RelRO: No TROUBLESHOOTING To make debugging with GDB more efficient it is useful to know where certain branches/jumps will take us. Certain (newer) versions of GDB resolve the addresses of a branch instruction and show us the name of the target function. For example, the following output of GDB lacks this feature: ... 0x000104f8 <+72>: bl 0x10334 0x000104fc <+76>: mov r0, #8 0x00010500 <+80>: bl 0x1034c 0x00010504 <+84>: mov r3, r0 ... And this is the output of GDB (negatively, without gef) which has the feature I’m talking about: 0x000104f8 <+72>: bl 0x10334 <free@plt> 0x000104fc <+76>: mov r0, #8 0x00010500 <+80>: bl 0x1034c <malloc@plt> 0x00010504 <+84>: mov r3, r0 If you don’t have this feature in your GDB, you can either update the Linux sources (and hope that they already have a newer GDB in their repositories) or compile a newer GDB by yourself. If you choose to compile the GDB by yourself, you can use the following commands: cd /tmp wget https://ftp.gnu.org/gnu/gdb/gdb-7.12.tar.gz tar vxzf gdb-7.12.tar.gz sudo apt-get update sudo apt-get install libreadline-dev python-dev texinfo -y cd gdb-7.12 ./configure --prefix=/usr --with-system-readline --with-python && make -j4 sudo make -j4 -C gdb/ install gdb --version I used the commands provided above to download, compile and run GDB on Raspbian (jessie) without problems. these commands will also replace the previous version of your GDB. If you don’t want that, then skip the command which ends with the word install. Moreover, I did this while emulating Raspbian in QEMU, so it took me a long time (hours), because of the limited resources (CPU) on the emulated environment. I used GDB version 7.12, but you would most likely succeed even with a newer version (click HERE for other versions). © 2017 Azeria-Labs Sursa: https://azeria-labs.com/debugging-with-gdb-introduction/

https://www.humblebundle.com/books/cybersecurity-wiley Social Engineering: The Art of Human Hacking The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation Threat Modeling: Designing for Security Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd Edition The Shellcoder's Handbook: Discovering and Exploiting Security Holes, 2nd Edition Cryptography Engineering: Design Principles and Practical Applications The Art of Deception: Controlling the Human Element of Security The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code Unauthorised Access: Physical Penetration Testing For IT Security Teams Secrets and Lies: Digital Security in a Networked World, 15th Anniversary Edition CEH v9: Certified Ethical Hacker Version 9 Study Guide Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition // Removed - Am scos link-ul celalalt Ce scrie acolo: "Support charity". Preturile sunt foarte mici, oricine isi poate permite. // Nytro

O mica jucarie pentru cei ce se ocupa cu Reverse Engineering. Momentan doar pentru Windows, arhitecturi x86 si x86_64. Articol: http://blog.talosintelligence.com/2017/07/pyrebox.html Repo: https://github.com/Cisco-Talos/pyrebox

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 !

We are a group comprised of certified intelligent hackers, crackers and developers. we guarntee succcess in the job done as fast as possible and we provide of the job done ...we have an office and a return policy..all information will be giving to u ...Contact us // Cocalari

Salut! Pentru cine nu stie de unde sa inceapa sau ii e lene sa citeasca de unul singur, mai in jos aveti linkurile de la videoconferintele Telacad pentru cursurile de programatori web I&II I http://www.telacad.ro/videoconferinte/php1curs1.mp4 http://www.telacad.ro/videoconferinte/php1curs2.mp4 http://www.telacad.ro/videoconferinte/php1curs3.mp4 http://www.telacad.ro/videoconferinte/php1curs4.mp4 http://www.telacad.ro/videoconferinte/php1curs5.mp4 http://www.telacad.ro/videoconferinte/php1curs6.mp4 http://www.telacad.ro/videoconferinte/php1curs7.mp4 http://www.telacad.ro/videoconferinte/php1curs8.mp4 http://www.telacad.ro/videoconferinte/php1curs9.mp4 http://www.telacad.ro/videoconferinte/php1curs10.mp4 II http://www.telacad.ro/videoconferinte/php2curs1.mp4 http://www.telacad.ro/videoconferinte/php2curs2.mp4 http://www.telacad.ro/videoconferinte/php2curs3-1.mp4 http://www.telacad.ro/videoconferinte/php2curs3-2.mp4 http://www.telacad.ro/videoconferinte/php2curs4-1.mp4 http://www.telacad.ro/videoconferinte/php2curs4-2.mp4 http://www.telacad.ro/videoconferinte/php2curs5.mp4 Spor la invatat!