# AWAE (OSWE) preparation ***__DISCLAIMER I HAVE NOT YET STARTED THE OSWE COURSE, THESE ARE MY PREDICTIONS / STEPS TAKEN TO PREPARE FOR THE COURSE AND EXAMINATION__*** I recently registered for the OSWE (Offensive Security Web Expert) course that is offered by Offensive Security. It is the next step to furthering your web hacking skills and goes into detail about both dynamic and static code analysis. I'm going to start the OSWE preparation by reading through the course subjects and grouping them into what they are similar to, then, pick out the ones I am not familiar with and research them briefly to gather a basic understanding of what they consist of. * Persistent Cross-Site Scripting * Session Hijacking * .NET Deserialization * Data Exfiltration * Bypassing File Extension Filters * Magic Hashes * PostgreSQL Extension and User Defined Functions * Bypassing REGEX restrictions * Cross-Site Request Forgery * Type Juggling * Blind SQL Injection * Bypassing File Upload Restrictions * Loose Comparisons * Bypassing Character Restrictions * PostgreSQL Large Objects * Debugging .NET Assemblies From first looking at the course material, I can already group multiple subjects together, one group being Session Hijacking and Persistent Cross-Site Scripting (Since PXSS can lead to Session Hijacking), another being Magic Hashes, Loose Comparisons and Type Juggling (Since loose comparisons can lead to type juggling which in some cases can be exploited with magic hashes), another being "Bypassing File Extension Filters" with "Bypassing File Upload Restrictions" (since a common bypass for file upload restrictions is the modification of file extensions to trick the server into allowing the upload), another group being "Bypassing REGEX restrictions" and "Bypassing Character Restrictions" since REGEX is generally used to ensure only certain characters or patterns are used in a servers input, which falls in line with the "Bypassing Character Restrictions", and finally Data Exfiltration along with Blind SQL Injection (Since a common use of Blind SQL Injection is to exfiltrate data), I have done some past research on Blind SQL Injection in the ORDER BY clause for MySQL *shameless plug* https://0x00sec.org/t/taking-sql-injections-further-blind-second-order-sql-injection-tmhc-ctf-shitter-writeup/18122. So already we have simplified the list, and made it much easier / less intimidating to handle: * Persistent Cross-Site Scripting & Session Hijacking * .NET Deserialization * Bypassing File Extension Filters & Bypassing File Upload Restrictions * PostgreSQL Extension and User Defined Functions * Bypassing REGEX restrictions & Bypassing Character Restrictions * Cross-Site Request Forgery * Blind SQL Injection & Data Exfiltration * Loose Comparisons, Type Juggling & Magic Hashes * PostgreSQL Large Objects * Debugging .NET Assemblies Now I personally have already dealt with some of these vulnerabilities before, so less time will be required for me to look over them (I did the same thing in OSCP, order by what I thought would take me the longest to master, and start from there), so here is my ordered list of what I think will take me the most time, to the least time (I have also included a personally expected difficulty level out of 10): 1. .NET Deserialization (7/10) 2. Debugging .NET Assemblies (6/10) 3. PostgreSQL Extension and User Defined Functions (6/10) 4. PostgreSQL Large Objects (6/10) 5. Blind SQL Injection & Data Exfiltration (5/10) 6. Bypassing REGEX restrictions & Bypassing Character Restrictions (4/10) 7. Loose Comparisons, Type Juggling & Magic Hashes (4/10) 8. Cross-Site Request Forgery (3/10) 9. Bypassing File Extension Filters & Bypassing File Upload Restrictions (3/10) 10. Persistent Cross-Site Scripting & Session Hijacking (3/10) This is completely subjective of course, and for me the reason behind this is the vast amount of CTF challenges that are based around XSS, PHP Loose Comparisons, type juggling, magic hashes, SQL Injections and file uploads. Some CTF resources that I personally really enjoy are: * https://247ctf.com/ * https://root-me.org/ (Especially the web challenges) * https://hackthebox.eu/ (This is the platform that I started hacking on, top quality) * https://0x0539.net/ * https://ctftime.org/ (For the live jeopardy and boot2root competitions) The reason I am nervous about the .NET and PostgreSQL vulnerabilities is the fact that I have little to no experience with the technologies. __Predictions__ Here I will be including my predictions for how each topic in the course material will be presented in the exam (I am completely speculating, I have not seen, or done the exam before). So we know the exam consists of 48 hours to find vulnerabilities in unique applications using code analysis, so, we can sort the topics into groups of what you can do with them. | Auth Bypass | RCE | File Read | N/A | | - | - | - | - | | Blind SQL Injection | .NET Deserialization | Blind SQL Injection (Depending on DBMS) | Bypassing Character Restrictions | | Persistent Cross-Site Scripting | Bypassing File Extension Filters | Bypassing File Upload Restrictions | Bypassing REGEX restrictions | | Data Exfiltration | PostgreSQL Extension and User Defined Functions |Data Exfiltration| Debugging .NET Assemblies | | Magic Hashes | PostgreSQL Large Objects | (All of the RCE methods) | | | Loose Comparisons | Blind SQL Injection (Depends on the DBMS) | | | | Cross-Site Request Forgery | Bypassing File Upload Restrictions | | | | Type Juggling | CSRF (if only certain IPs can execute commands)| | | So we can kind of guess how the boxes will be structured (again, this is a prediction, I have not yet done the course). The N/A column are just skills that may come in handy, not necessarily vulnerabilities. It is quite clear that we will need to use some sort of bypass to access the machine(s), and then either read a file or get command execution somehow, using the vulnerabilities/techniques taught in the course. __Topics__ I have done some brief research regarding all topics to get a grasp of what each topic consists of: __.NET Deserialization__ > Serialization is the process of converting the state of an object into a form that can be persisted or transported. The complement of serialization is deserialization, which converts a stream into an object. Together, these processes allow data to be stored and transferred. -Microsoft Docs So, if we control data that is deserialized on the server side it can lead to Remote Command Execution. This vulnerability is based on the idea that the .NET framework has many types built into it that will run just because they were instanced, for example: * Constructors * Setters * Destructors * OnDeserialize Handlers A really good (although lengthy) slide to read through is: https://www.slideshare.net/MSbluehat/dangerous-contents-securing-net-deserialization References: * https://owasp.org/www-project-cheat-sheets/cheatsheets/Deserialization_Cheat_Sheet.html * https://blog.detectify.com/2018/03/21/owasp-top-10-insecure-deserialization/ * https://www.immuniweb.com/blog/OWASP-insecure-deserialization.html __Debugging .NET Assemblies__ I guess this part isn't really a vulnerability, more of a technique used for dynamic code analysis, and with all things, the more practice the better. This is something I have next to no experience with this, so I will need to read up on multiple resources. Visual Studio seems to have an extension that can be used to facilitate the debugging of .NET applications called `.NET Reflector Visual Studio Extension`. Resources and References: * https://marketplace.visualstudio.com/items?itemName=vs-publisher-306627.NETReflectorVisualStudioExtension * https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-debug-dotnet-framework-source?view=vs-2019 * https://www.domstamand.com/debugging-your-dotnet-applications-and-packages-howto/ * https://github.com/0xd4d/dnSpy __PostgreSQL Extension and User Defined Functions__ I don't think I have any experience with this vulnerability, and I am not entirely sure what is meant by this part of the course, I am guessing it refers to what is possible if we control the definition of functions and extensions inside the PostgreSQL database. Maybe we can add a malicious extension / plugin to the PostgreSQL database that allows for the achievement of Remote Command Execution or other further exploitation methods. Possibly relevant reference: https://www.postgresql.org/docs/8.2/xfunc-c.html __PostgreSQL Large Objects__ From what I have been able to find online, this seems to be part of PostgreSQL's restore department, which may allow for remote file write, or execution of binary files stored in the large objects table (I am not entirely sure about the latter). Possibly relevant reference: https://jon-stewart.github.io/exploiting-postgresql-restore/ __Blind SQL Injection & Data Exfiltration__ This vulnerability is like a normal SQL injection vulnerability, although what makes it special is the lack of visible output from the database, even when the query was successfully executed. A workaround to exploit this vulnerability would be to make use of binary queries (queries that either return 0 or 1) to tell whether you got something right or not (maybe bruteforce a password letter by letter, or check for the existence of a table). Since the response will either be True or False you can then trigger certain backend responses that are then visible to us without actually needing to see direct database output. For example, we can inject a certain binary query payload that if true, it makes the database run the SLEEP() function that exists in most DBMS', so depending on the response time from the server, we can tell if the query returned true or false. A similar outcome can be achieved by using errors and purposefully causing 500 Internal Server Error response codes (now is when I would recommend reading my blog post based around the Shitter challenge). __Bypassing REGEX restrictions & Bypassing Character Restrictions__ Simply put, this consits of using certain tricks and techniques to bypass the restrictions that a REGEX filter may present, for example, using a different encoding to bypass a filter that only checks for ascii characters. For the bypassing character restrictions, this can also be done with a similar method, for example, using Unicode on an ascii based application, so the application doesn't detect the inputted character as one of the blocked ones. __Loose Comparisons, Type Juggling & Magic Hashes__ I put these three vulnerabilities / techniques into one group simply because they overcross in certain places, but for the benefit of this section, I am going to try and "separate" them and give an individual explanation. Loose comparisons, in PHP for example, are seen when a comparison between two parameters are done with two equals signs ("==") instead of three. When only two equals signs are used, only the value is compared, so if I compare "1" and 1 in PHP with a weak comparison, it will return true, even though one is string and the other is an integer (no output means false): ```php php > echo "2" == 2; 1 php > echo "2" === 2; php > ``` This is exploitable since it allows us to use type juggling (which can usually be done to exploit a bypass if anything). Type juggling is basically when you use things like weak comparisons to make PHP act in a way it shouldn't, by feeding it different data types (maybe arrays instead of strings for example). Finally, magic hashes are hashes that can be used in these situations since the hash itself follows a certain format / pattern, some good resources are: * https://medium.com/swlh/php-type-juggling-vulnerabilities-3e28c4ed5c09 * https://www.owasp.org/images/6/6b/PHPMagicTricks-TypeJuggling.pdf * https://www.whitehatsec.com/blog/magic-hashes/ * https://github.com/spaze/hashes * https://www.netsparker.com/blog/web-security/type-juggling-authentication-bypass-cms-made-simple/ * Some of the web challenges from 247 CTF __Cross-Site Request Forgery__ Essentially, cross site request forgery or CSRF, is when you can make another user send a request to the server, simply by sending them a link. I personally think it is one of the most underated vulnerabilities in Web App hacking. An example would be if a server took 2 get parameters to send money, one for the amount, and one for the receiver (vulnerable.com/?amount=1000&to=attacker@attacks.com). The second someone clicks that link, their cookies will log them in, and the amount will be deducted from their account, and sent to the attacker. It is such a simple attack, but still so dangerous (the same thing can be achieved in a post request by using your own website and javascript). Some good resources are: * https://en.wikipedia.org/wiki/Cross-site_request_forgery * https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/ * https://portswigger.net/web-security/csrf __Bypassing File Extension Filters & Bypassing File Upload Restrictions__ When a server allows a file to be uploaded to a server, most of the time they only want a certain type of file to be uploaded (for example an image). This section of the course material will basically teach some techniques about how to bypass these filters, and make the server accept and store file types that it shouldn't. An example would be for a profile picture upload, with some of these methods, an attacker could upload a .php file, which they can then access somehow on the site, and since the PHP file is executed on the server side, they can achieve RCE. * https://www.exploit-db.com/docs/english/45074-file-upload-restrictions-bypass.pdf * https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload * https://vulp3cula.gitbook.io/hackers-grimoire/exploitation/web-application/file-upload-bypass __Persistent Cross-Site Scripting & Session Hijacking__ This vulnerability consists of the lack of sanitization / validation on the server side, so it returns user controlled input directly back to the user. This can be exploited to make a victims local browser run malicious JavaScript code, which can lead to the stealing and hijacking of session cookies. The session hijacking part is simply the idea of taking someone's cookies, placing them in your own browser, and then accessing the vulnerable site as them (you can only steal cookies for the domain that is vulnerable to the XSS, since one domains JS will not be able to access another domains information).