If you’re running Jekyll on GitHub pages and looking to set up redirects, there’s a good chance you stumbled upon jekyll-redirect-from. It’s a nice little tool for creating redirects, simply by declaring them in a page’s front matter. However, if you create a redirect using jekyll-redirect-from, there’s an issue that you might be concerned about…it does not preserve the query string or hash from the original request URL when redirecting the user.
There’s an issue in the repo about this which, at the time of writing this, has been open for nearly a year. There’s also a PR to fix it. However, in the interest of keeping jekyll-redirect-from simple and lightweight it seems unlikely that this will be fixed.
Fortunately, I’ve found a workaround that allows redirects on GitHub pages and preserves the query string and hash.
I’m currently working on a tool that, among other things, attempts to detect if a string represents a serialized Java object.
I spent a while trying to find the best means for doing this and ultimately found the answer to my question in the slides for a talk titled “Deserialize My Shorts Or How I learned to Start Worrying and Hate Java Object Deserialization” by Christopher Frohoff.
CVE-2016-4010 is an object injection vulnerability whereby an attacker can trick Magento into unserializing user controlled input.
Additionally, its author identified a POP chain that allows arbitrary file write. The chain, which was discovered in the Magento 2 code base, works like this…
Trick Magento into unserializing an instance of
__destruct is automatically called on the instance as a result of unserialization.
close on its protected
redis property, for which an instance of
Magento\Sales\Model\Order\Payment\Transaction is injected.
save on its
_resource property, for which an instance of
Magento\Framework\Simplexml\Config\Cache\File is injected.
Magento\Framework\Simplexml\Config\Cache\File::save will call
components. Those properties can also be injected allowing complete control over both the contents and the location of the file (including filename).
A pretty nasty sequence of events…
I decided to do a little investigation into the feasibility of using this POP chain against Magento 1. Here I’ll share my findings…
Recently I’ve been spending a lot of time experimenting with PHP unserialize object injection vulnerabilities. Frequently, exploits against these types of vulnerabilities involve chaining together multiple objects to call unexpected methods on unexpected properties. This technique is known as creating a POP (property oriented programming) chain. Here are a few examples of how that plays out in PHP world…
In a blog post from Bugcrowd titled “Discovering Subdomains”, Google dorking is the first strategy covered…
The site directive will filter results only to your target:
After we have the initial domain in there we can use the -inurl directive.
Each subdomain we find can then be filtered out with more -inurl directives to make place for others:
site:paypal.com -inurl:www -inurl:shopping
This strategy for identifying subdomains is very convenient, but what about if the target is using their naked domain instead of www?
SSRF (server side request forgery) is a type of vulnerability where an attacker is able trick a remote server into sending unauthorized requests. SSRF opens the door to many types of undesirable things such as information disclosure, DoS and RCE. In this post, we’ll take a look at the types of exploits that are achievable when we have access to curl Redis via SSRF.