I wrote a very simple burp extension that can pull a token a CSRF token out of a response and update the next request with that token. It’s designed to be a simple as possible so it works for my lesson on writing burp extensions and if you’re lucky then all you need to do is update the script with the name of the token your target application uses and you’re good to go but it’s designed to be as easy to tweak to your needs as possible. I also wrote about how to install custom extensions here if you’ve …
Effectively filtering user input is one of the best ways to prevent an awful lot of web application vulnerabilities. There are several ways to approach this, each with their own pros and cons so I’ll run through them here an then you can think of the best way to combine them for your context. It’s important to remember though, that filters are context specific, there is not one filter that will work for a whole application and that’s what can make writing an effective filter tricky.
During a recent penetration test I came up against a security feature that would invalidate my session whilst I was fuzzing if it saw simple attack strings, so if I used <script> anywhere then it’d kill my session. Most frustrating! Especially as it essentially prevented the use of tools such as Burp’s Active Scanner and it made using Repeater inconvenient too. So I quickly threw together a Burp Macro to handle automatic re-authentication for me and went back to fuzzing! So here’s how to do that!
Structured Query Language (SQL) is used all over the web and is potentially vulnerable to an injection attack any time that user input is insecurely concatenated into a query. An injection attack allows an attacker to alter the logic of the query and the attack can lead to confidential data theft, website defacement, malware propagation and host/network compromise.
If an attacker is able to get SYSTEM level access to a workstation, for example by compromising a local administrator account, and a Domain Administrator account is logged in to that machine then it may be possible for the attacker to simply read the administrator’s access token in memory and steal it to allow them to impersonate that account. There’s a tool available to do this, it’s called Incognito.
Why not copy and paste the following into your /etc/john.conf and try them out! Got a suggestion for a rule? Leave a comment! They can then be called with ‐‐rules=Try, ‐‐rules=TryHarder and ‐‐rules=BeBrutal! You can find an explanation of how these rules are built here.
Whilst Hashcat is often provable faster than John the Ripper, John is still my favourite. I find it simple to use, fast and the jumbo community patch (which I recommend highly) comes packed with hash types making it a versatile tool. One of the features of these tools, which is often unknown or at least under appreciated is the ability to create custom “rules” for teaching the tool how to dynamically generate potential passwords. Since Microsoft implemented “Password Complexity” and this was enforced around the globe, user have made the jump from a password of: password, to the [sarcasm] much …
A common and critical vulnerability exploited during penetration tests is that of reused Local Administrator passwords. This issue is a common one it allows an attacker to find a vulnerable machine on a network, pull the administrative hash out of that machine and then log-in to a more interesting machine or ultimately privilege escalate.
In my experience Insecure Direct Object Reference is one of the least well known vulnerabilities out there, but it’s a very simply issue to explain. It’s a vulnerability that generally leads to loss of confidential data but can result in the less of modification of data too.