Mahmoud Gamal - Security Blogs

Hello hackers, A couple of weeks ago I tweeted about exploiting an out of band XXE vulnerability with a firewall blocking all outgoing requests including DNS lookups, so here is the full story: This is a private bug bounty program so I won't be mentioning who the vendor is. As usual during a hacking night while navigating the target application I came across an endpoint that took a parameter called xml but its value was encrypted. Later I found out that XML data sent to the backend is encrypted in the client side before sent in HTTP requests which means that XML data might not be properly validated in the backend, so I wanted to modify it to be able to inject my own XXE payload. So what I first tried was to find the JavaScript function used to encrypt the XML and do the same for my custom XML payload, however, the application's JavaScript was minimized with WebPack which made it very hard to read and trace functions. To avoid the hassle of finding the JavaScript encrypting...

TL;DR We found a zero-day within a JavaScript template library called handlebars and used it to get Remote Code Execution in the Shopify Return Magic app. The Story: In October 2018, Shopify organized the HackerOne event "H1-514" to which some specific researchers were invited and I was one of them. Some of the Shopify apps that were in scope included an application called "Return Magic" that would automate the whole return process when a customer wants to return a product that they already purchased through a Shopify store. Looking at the application, I found that it has a feature called Email WorkFlow where shop owners can customize the email message sent to users once they return a product. Users could use variables in their template such as {{order.number}} , {{email}} ..etc. I decided to test this feature for Server Side Template injection and entered {{this}} {{self}} then sent a test email to myself and the email had [object Object] within ...

Hi Folks, Today I'll be writing about some interesting SQL injection vulnerabilities I recently found. This is a private program so I won't be mentioning who the vendor is. #1: WAF? ok! At a lovely hacking night I started testing for a private bug bounty program, after about 30 minutes of throwing random single and double quotes inside all the parameters, one of the endpoints returned an error saying: {"error":"An unexpected error has occured"} So I looked at the request and set the value of the parameter to `23' and '1'='1` and as expected the endpoint returned valid results which means it's vulnerable to SQL injection! That's it, a lovely basic Boolean-Based SQL injection let's write the report and get a nice bounty! But... THE WAF! While further exploiting this vulnerability to extract data from the database as a proof of concept, the endpoint was returning {"error":" undergoing correct...

This article was originally posted on Seekurity Blog: https://www.seekurity.com/blog/general/lets-steal-some-tokens/  Hey There, How you doing? Good? Cool! In this blog post I will be talking about my experience with minor bugs chained together to steal sensitive tokens. #1. Stealing CSRF tokens through Google Analytics. While randomly testing things on apps.shopify.com, I landed at some random app page and hit the  Write a review  button, I wasn’t logged in so I was redirected to the login page and after logging in I was redirected to the application page again. Ok, that’s normal. However, what wasn’t normal is that the URL I got redirected to contained this GET parameter  authenticity_token=[CSRF_TOKEN] . Yummy!!! I know Shopify allow you to add rich text to your application’s description,so I just thought I will load an image from my server and get the token from the referer header, or add a link to it and trick the victim to click it. Yup...

What's up whoever reading this! been a long time since I last posted something here. Today, I will be writing about a SQL injection vulnerability I recently found. As usual, at a hacking night after drinking my favorite cookie frappe I picked up a bug bounty program and started testing. Like any other researcher, I was throwing XSS payloads randomly everywhere. (I usually use '"><img src=x onerror=alert(2) x= with a single quote at the beginning) and while doing so one of the endpoints returned a 500 error saying A SQL error was encountered which definitely attracted my attention. The field returned that error was my `full name` so I went back there and immediately tried test'test which returned the same error which means that the single quote is what is causing the problem here. Realizing that, it seemed to me that single quotes weren't escaped at the SQL query, so I tried to escape it for them(by doubling it) and see what happens...