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…
1. Credis_Client::__destruct
Trick Magento into unserializing an instance of Credis_Client. __destruct is automatically called on the instance as a result of unserialization.
2. Magento\Sales\Model\Order\Payment\Transaction::close()
Credis_Client calls close on its protected redis property, for which an instance of Magento\Sales\Model\Order\Payment\Transaction is injected.
3. Magento\Framework\Simplexml\Config\Cache\File::save
Magento\Sales\Model\Order\Payment\Transaction calls save on its _resource property, for which an instance of Magento\Framework\Simplexml\Config\Cache\File is injected.
4. file_put_contents
Magento\Framework\Simplexml\Config\Cache\File::save will call file_put_contents using stat_file_name and 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 fact, there’s even a new project on GitHub called phpgcc which is building a list of generic POP chains (“gadgets”), similar to ysoserial in the Java 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:
site:paypal.com
After we have the initial domain in there we can use the -inurl directive.
site:paypal.com -inurl:www
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.