Define bugbounty scopes for Burp Suite and OWASP ZAP in the simplest way possible. I mean really, it doesn't get much simpler than this.
It’s been roughly one month since rescope first got introduced and the feedback so far has been nothing but positive. Given that I was so new to twitter and everything, I didn’t know what to expect. Heck, with less than 20 followers at the time, I was surprised that anyone even saw the tweet, let alone click it. I dunno what happened, but somehow it gained some traction and before I knew, it was featured on pentester.
Four ways you can abuse CORS when origins are not validated properly.
In this post we will look at what happens when CORS Origin is not validated correctly and explore some ways this can be abused to exfiltrate data. My initial idea with this was to cover the MITM part (improper scheme validation) in greater detail, but I figured why not include the others as well. I won’t go into the cause of the problem, but rather focus on the symptoms and try to provide some clear examples of how this can be approached from an attackers’ POV.
Introducing rescope. A tool that parses your scope definitions to Burp/ZAP compatible formats for import. Useful for bug hunters and those working with large scopes.
rescope is a tool I wrote (in Go) that lets you quickly define scopes in Burp/ZAP- mainly intended for “bug hunters”, and pentesters who deal with larger scopes.
Update As for rescope v1.0 it is now possible to parse scopes straight from any major “bug-bounty-as-a-service” program. See Github and Blog post for details.
Simply give it a file (scope) containing target identifiers and rescope parses this to regex & spits out a file that can be imported to either Burp or ZAP directly.
For educational purposes only
There may be times when you want to exploit MS17-010 (EternalBlue) without having to rely on using Metasploit. Perhaps you want to run it from a ‘Command & Control’ system without msf installed, run a quick demo or execute on the go. Unlike “zzz_exploit”, this method does not require access to a named pipe, nor does it require any credentials. The downside, however, is an increased risk of crashing the target.
Escalating privileges when user is part of Docker group
I don’t think Docker needs an introduction at this point, but in case you are unfamiliar with it; it is a way of isolating software packages by virtualizing them on an OS-level which runs in “containers.” It works in a similar way to traditional virtual machines, but with much less overhead as the kernel is shared between multiple containers.
The problem arises when the docker group is assigned to the host user.
The pickle module is not secure against erroneous or maliciously constructed data.
Pickle is a serialization/deserialization module found within the standard Python library. For those unfamiliar with serialization and deserialization; it is a way of converting objects and data structures to files or databases so that they can be reconstructed later (possibly in a different environment). This process is called serialization and deserialization, but in Python, it is called pickling and unpickling. One big caveat to pickle however, is that it does not perform any “security checking” on the data that is being unpickled, meaning that an attacker having access to the endpoint can potentially gain remote code execution by serving malicious input.
Escalating privileges when pip is part of sudo group
If you happen to have a user shell on a system and you see that user has sudo rights to pip install, then escalation becomes super easy.
alice@jada:~$ sudo -l [sudo] password for alice: Matching Defaults entries for alice on jada: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User alice may run the following commands on jada: (root) /usr/bin/pip install * In that case, what you can do is create a malicious setup.py on target system: