-
namespaces - overview of Linux namespaces http://man7.org/linux/man-pages/man7/namespaces.7.html
-
mount_namespaces - overview of Linux mount namespaces
. | |
.. | |
........ | |
@ | |
* | |
*.* | |
*.*.* | |
🎠|
<!DOCTYPE scan [ | |
<!ENTITY test SYSTEM "target.xml"> | |
]><scan>&test;</scan> |
GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.
You can just do your research on github.com, but I would suggest cloning all the target's repositories so that you can run your tests locally. I would highly recommend @mazen160's GitHubCloner. Just run the script and you should be good to go.
$ python githubcloner.py --org organization -o /tmp/output
Broken Link Hijacking (BLH) exists whenever a target links to an expired domain or page. Broken Link Hijacking comes in two forms, reflected and stored. This issue has been exploited in the wild numerous times, but surprisingly few researchers actively look for broken links in bug bounty programs.
This post aims to give you a basic overview of the different issues that could possibly arise if a target links to an expired endpoint.
#!/bin/bash | |
aquatone-discover -d $1 --threads 10 | |
aquatone-scan -d $1 --ports huge --threads 10 | |
DEBUG=nightmare xvfb-run -a aquatone-gather -d $1 --threads 10 | |
aquatone-takeover -d $1 --threads 10 |
require 'yaml' | |
require 'base64' | |
require 'erb' | |
class ActiveSupport | |
class Deprecation | |
def initialize() | |
@silenced = true | |
end | |
class DeprecatedInstanceVariableProxy |
XML processing modules may be not secure against maliciously constructed data. An attacker could abuse XML features to carry out denial of service attacks, access logical files, generate network connections to other machines, or circumvent firewalls.
The penetration tester running XML tests against application will have to determine which XML parser is in use, and then to what kinds of below listed attacks that parser will be vulnerable.
//////// | |
// The vm module lets you run a string containing javascript code 'in | |
// a sandbox', where you specify a context of global variables that | |
// exist for the duration of its execution. This works more or less | |
// well, and if you're in control of the code that's running, and you | |
// have a reasonable protocol in mind// for how it expects a certain | |
// context to exist and interacts with it --- like, maybe a plug-in | |
// API for a program, with some endpoints defined for it that do | |
// useful domain-specific things --- your life can go smoothly. |
--- squirrelmail.stable/squirrelmail/class/deliver/Deliver.class.php 2017-01-27 21:31:33.000000000 +0100 | |
+++ htdocs/class/deliver/Deliver.class.php 2018-03-14 17:21:10.320000000 +0100 | |
@@ -281,6 +281,7 @@ | |
global $username, $attachment_dir; | |
$hashed_attachment_dir = getHashedDir($username, $attachment_dir); | |
$filename = $message->att_local_name; | |
+ if(!ctype_alnum($filename)) die(); | |
// inspect attached file for lines longer than allowed by RFC, | |
// in which case we'll be using base64 encoding (so we can split |