Wednesday, 14 March 2018

Information Leakage Through Child Tab - Mozilla

Hi Internet,

This bug was marked as RESOLVED and WONTFIX by Mozilla team but it was a good finding and learning for me hope you enjoy the read.
PS: The below issue also work when you are in "Incognito Mode/Private Browsing"
You just need to press SHIFT+CTRL+N to restore your session even if you have closed your child tab in Mozilla browser, I may not be able to explain well but here is what i got.

The application which have some services which opens in child tab (Using Auth) and once the user perform his/her activity, and logout from the session or close the child tab, still by pressing SHIFT+CTRL+N open's up the same child tab with information which was feed by the above user, without providing any user creds.

Example 1:
1. Login to
2. Navigate to Layout
3. Edit any gadgets from it (Its opens up a child tab)
4. Close the child tab, Logout from Gmail
5. Press SHIFT+CTRL+N you will be able to see the above child tab

Impact and Assumption:
Information leakage, lets suppose a scenario where user feed his/her credit card details or such in child tab. I am not sure, by pressing SHIFT+CTRL+N something like this should happen or not or its working as intended.

Mozilla says:
We allow you to undo close tab in private browsing, so undo'ing closing a window seems straightforward as something we will want to continue doing. Certainly I don't think this is a security issue that needs to stay hidden. The website could defend against this type of thing by checking login state when a page loads.

But, I browsed to many famous services offered over the Internet and this perfectly works over there and application directly allows you to restore back with your session from where you left, Obviously we can't perform any dynamic activity but can view data.

Example 2:
This is one of the well know bank in India which allows users to do netbanking but opens the login portal in child tab,
I logged in as genuine user performed my activity and closed my child tab, hence forth just press SHIFT+CTRL+N and your session will be restored back.

Now, this bank uses only POST method so when I clicked SHIFT+CTRL+N it gave me error of HTTP Method, well I just went to network tab and send the response again in POST method and guess what it gave me 200 OK and response was perfectly shown from where I left.

Here is an example javascript which open Facebook in child tab.


Monday, 5 March 2018

Thankyou McDonald for free cookies

Hi Internet,

Pwing McDonald's  in 3 step and getting access to 5000+ usernames and passwords of McDonald's users. Hope you like the read..
Img Src:


Well, finding this bug was not a pain it was simple, and if you are not aware is under bug bounty program.

Lets Get Started :
As usual i started with sub-domain enumeration where I got a  subdomain ( which was not hosting any services for customers. Moving further I ran dirsearch on same, and  got 200 OK @ ( (Looks like some kind of backup for McDelivery).

Okay so, extracting the tar file made me concluded it's actual a backup of McDelivery which consists of many things such as their DB, Website Backup's and many other juicy information. (Still I feel there must me something more...)

Lets Do Some Old School Tricks :
Why not simply do keyword search in entire dump file using grep
Then come's the results, their were multiple files having match of keyword "password" but then there was an excel sheet as well which I couldn't find during my manual search (GUI based).
The excel file had ~ (tilde) symbol after extension, obviously askubuntu have an answer for this. Anyways, guess what the excel sheet had username, email ID and password's !!!
and the count goes on .....

Big deal huhh !

Quick Flash :
25th February 2018: Informed McDonald's
26th February 2018: McDonald's Acknowledged 
28th February 2018: Reminder sent to McDonald's
28th February 2018: McDonald's Escalated Internally
28th February 2018: Issue Resolved


Wednesday, 7 February 2018

SOP Bypass using rel="noreferrer"

Hi Internet,

A bug that affects "Million people" this bug was marked as DUPLICATE and RESOLVED by Mozilla team but it was a good finding and learning for us (Robin Divino and Me) hope you enjoy the read.


By default, any websites is passing the whole URL to any external domain (un-trusted third party domains) when the request was crossing between 2 domains, means if the user clicks an external link to a specific website, the whole URL will pass to the request header as part of a what we called Referer header.

But many of the websites URL parameters value contains sensitive user information/data such as Password reset token, OAuth token, Email address and many more, therefor website owners use a what we called rel attribute on the html code with the value of noreferrer to avoid leaking sensitive data to external domains.

However, we have found that the Firefox quantum seems ignoring the rel="noreferrer" attribute of an <a> tag which will put quantum users in risk.

For example:

HackerOne application ( is strict when it comes to information sharing , because they do not allow anyone from third party domains to have access to hackerone users informations, because of that hackerone footer twitter external link contains the following code:

<a class="footer-nav-item-link icon-share-twitter" href="" target="_blank" rel="noreferrer noopener"></a>

When we click on the external twitter link and capture the request, the request header still contains referrer header that contains the full URL.

Steps To Reproduce:

1. Find any website page that contains external link (e.g twitter, facebook, etc.) most of the external link will be found on the footer as part  of their social link ads.

2. Make sure that the external link you found have a rel="noreferrer" attribute on its <a> tag or similar to what i have mentioned above in case of hackerone footer.

3. Click the external link and capture the request using burpsuite.

4. Observed the request header still have referer header despite the website owner put a rel="noreferrer" on their <a> tag that contains hyper-link to external domains.


Massive information leakage of FF users without their knowledge :(


Monday, 5 February 2018

Integer Underflow to RCE in Firefox

Hi Internet,

A 750$ bug :P Lets get started.

If the integer value used is less than the minimum signed or unsigned int. This is called an underflow and will also trigger a segmentation fault.

Summary of this issue:
Before this change, if the metadata for a dbm-format certificate (or presumably key) database were corrupted, ugly_split could do an unchecked subtraction resulting in unsigned integer underflow, and would attempt to operate on something it thought was very big, resulting in (at least) an out-of-bounds.

How I started :
I was using nginx server with HTTPS which host's nothing, however adding a certificate exception every time crashes my FF in Linux, but does not crashes in windows. Then i taught of running FF in debug mode to see where the crash happens

GDB Log :
(gdb) bt
#0  0x00007fffcf4a4c56 in ?? () from /usr/lib/firefox/
#1  0x00007fffcf4a7a60 in ?? () from /usr/lib/firefox/
#2  0x00007fffcf4a63fe in ?? () from /usr/lib/firefox/
#3  0x00007fffcf4a7d1f in ?? () from /usr/lib/firefox/
#4  0x00007fffcf4a7e32 in ?? () from /usr/lib/firefox/
#5  0x00007fffcf4a9046 in ?? () from /usr/lib/firefox/
#6  0x00007fffcf4b599a in ?? () from /usr/lib/firefox/
#7  0x00007fffcf4b602a in ?? () from /usr/lib/firefox/
#8  0x00007fffcf4b87c6 in ?? () from /usr/lib/firefox/
#9  0x00007fffcf4b8d94 in ?? () from /usr/lib/firefox/
#10 0x00007fffcf4b8e40 in ?? () from /usr/lib/firefox/
#11 0x00007fffcf4b08ee in ?? () from /usr/lib/firefox/
#12 0x00007fffcf6eb12f in ?? () from /usr/lib/firefox/
#13 0x00007fffcf6eb6f5 in ?? () from /usr/lib/firefox/
#14 0x00007fffcf6d4321 in ?? () from /usr/lib/firefox/
#15 0x00007fffcf6d746f in ?? () from /usr/lib/firefox/
#16 0x00007ffff597120d in ?? () from /usr/lib/firefox/
#17 0x00007ffff5972261 in ?? () from /usr/lib/firefox/
#18 0x00007ffff598206e in PK11_ImportCert () from /usr/lib/firefox/
#19 0x00007fffe949d431 in ?? () from /usr/lib/firefox/
#20 0x00007fffe67bc232 in ?? () from /usr/lib/firefox/
#21 0x00007fffe6f1eeac in ?? () from /usr/lib/firefox/
#22 0x00007fffe6f23c76 in ?? () from /usr/lib/firefox/
#23 0x00007fffe9835da8 in ?? () from /usr/lib/firefox/
#24 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/
#25 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/
#26 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/
#27 0x00007fffe98365f2 in ?? () from /usr/lib/firefox/
#28 0x00007fffe9b1a311 in ?? () from /usr/lib/firefox/
#29 0x00007fffe7b12cf5 in ?? () from /usr/lib/firefox/
#30 0x00007fffe7dba6b6 in ?? () from /usr/lib/firefox/
#31 0x00007fffe7dc0498 in ?? () from /usr/lib/firefox/
#32 0x00007fffe7dc0cda in ?? () from /usr/lib/firefox/
#33 0x00007fffe7d9ff82 in ?? () from /usr/lib/firefox/
#34 0x00007fffe7da3bae in ?? () from /usr/lib/firefox/
#35 0x00007fffe7da3eae in ?? () from /usr/lib/firefox/
#36 0x00007fffe8799edc in ?? () from /usr/lib/firefox/
#37 0x00007fffe73c0177 in ?? () from /usr/lib/firefox/
#38 0x00007fffe899c084 in ?? () from /usr/lib/firefox/
#39 0x00007fffe899c3cb in ?? () from /usr/lib/firefox/
#40 0x00007fffe7da0330 in ?? () from /usr/lib/firefox/
---Type <return> to continue, or q <return> to quit---
#41 0x00007fffe7da3bae in ?? () from /usr/lib/firefox/
#42 0x00007fffe878f8f2 in ?? () from /usr/lib/firefox/
#43 0x00007fffe87b3545 in ?? () from /usr/lib/firefox/
#44 0x00007fffe87b6554 in ?? () from /usr/lib/firefox/
#45 0x00007fffe7d85a3f in ?? () from /usr/lib/firefox/
#46 0x00007fffe7d85c94 in ?? () from /usr/lib/firefox/
#47 0x00007fffe7d8a1c8 in ?? () from /usr/lib/firefox/
#48 0x00007fffe87b3591 in ?? () from /usr/lib/firefox/
#49 0x00007fffe87b3f70 in ?? () from /usr/lib/firefox/
#50 0x00007fffe87b6291 in ?? () from /usr/lib/firefox/
#51 0x00007fffe853096f in ?? () from /usr/lib/firefox/
#52 0x00007fffe853259a in ?? () from /usr/lib/firefox/
#53 0x00007fffe856e496 in ?? () from /usr/lib/firefox/
#54 0x00007fffe85392dd in ?? () from /usr/lib/firefox/
#55 0x00007fffe8575a72 in ?? () from /usr/lib/firefox/
#56 0x00007fffe8575b47 in ?? () from /usr/lib/firefox/
#57 0x00007ffff48d8fac in ?? () from /usr/lib/x86_64-linux-gnu/
#58 0x00007ffff1d91fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/
#59 0x00007ffff1da3fc1 in ?? () from /usr/lib/x86_64-linux-gnu/
#60 0x00007ffff1dac7f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/
#61 0x00007ffff1dad08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/
#62 0x00007ffff4a16c3c in ?? () from /usr/lib/x86_64-linux-gnu/
#63 0x00007ffff4a36dd3 in ?? () from /usr/lib/x86_64-linux-gnu/
#64 0x00007ffff48d81e8 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/
#65 0x00007ffff4445d92 in ?? () from /usr/lib/x86_64-linux-gnu/
#66 0x00007ffff1abb197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/
#67 0x00007ffff1abb3f0 in ?? () from /lib/x86_64-linux-gnu/
#68 0x00007ffff1abb49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/
#69 0x00007fffe8590d6f in ?? () from /usr/lib/firefox/
#70 0x00007fffe855a852 in ?? () from /usr/lib/firefox/
#71 0x00007fffe855aa12 in ?? () from /usr/lib/firefox/
#72 0x00007fffe67b54e5 in ?? () from /usr/lib/firefox/
#73 0x00007fffe67b0498 in ?? () from /usr/lib/firefox/
#74 0x00007fffe9385cd5 in ?? () from /usr/lib/firefox/
#75 0x00007fffe965e09e in ?? () from /usr/lib/firefox/
#76 0x00007fffe965eb20 in ?? () from /usr/lib/firefox/
#77 0x00007fffe73ff615 in ?? () from /usr/lib/firefox/
#78 0x00007fffe73ffc2f in ?? () from /usr/lib/firefox/
#79 0x00007fffe73ffd9f in ?? () from /usr/lib/firefox/
#80 0x00007fffe7a3f343 in ?? () from /usr/lib/firefox/
#81 0x00007fffe7997068 in ?? () from /usr/lib/firefox/
---Type <return> to continue, or q <return> to quit---
#82 0x00007fffe9835da8 in ?? () from /usr/lib/firefox/
#83 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/
#84 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/
#85 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/
#86 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/
#87 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/
#88 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/
#89 0x00007fffe98365f2 in ?? () from /usr/lib/firefox/
#90 0x00007fffe9b1a613 in ?? () from /usr/lib/firefox/
#91 0x00007fffe73e7902 in ?? () from /usr/lib/firefox/
#92 0x00007fffe73e6b33 in ?? () from /usr/lib/firefox/
#93 0x00007fffe73e6b33 in ?? () from /usr/lib/firefox/
#94 0x00007fffe73e7eb4 in ?? () from /usr/lib/firefox/
#95 0x00007fffe8337b24 in ?? () from /usr/lib/firefox/
#96 0x00007fffe83382d1 in ?? () from /usr/lib/firefox/
#97 0x00007fffe6dc2004 in ?? () from /usr/lib/firefox/
#98 0x00007fffe6e43ca6 in ?? () from /usr/lib/firefox/
#99 0x00007fffe6bb9d7f in ?? () from /usr/lib/firefox/
#100 0x00007fffe6bc1b6b in ?? () from /usr/lib/firefox/
#101 0x00007fffe6bc345d in ?? () from /usr/lib/firefox/
#102 0x00007fffe67b5625 in ?? () from /usr/lib/firefox/
#103 0x00007fffe67b0498 in ?? () from /usr/lib/firefox/
#104 0x00007fffe6bb2b91 in ?? () from /usr/lib/firefox/
#105 0x00007fffe6b88c7d in ?? () from /usr/lib/firefox/
#106 0x00007fffe8555de8 in ?? () from /usr/lib/firefox/
#107 0x00007fffe95f84de in ?? () from /usr/lib/firefox/
#108 0x00007fffe968a13f in ?? () from /usr/lib/firefox/
#109 0x00007fffe968b17a in ?? () from /usr/lib/firefox/
#110 0x00007fffe968b5f6 in ?? () from /usr/lib/firefox/
#111 0x000055555555a745 in ?? ()
#112 0x0000555555559d5c in ?? ()
#113 0x00007ffff6d64830 in __libc_start_main (main=0x555555559cf0, argc=2, argv=0x7fffffffddf8,init=<optimized out>,
fini=<optimized out>,rtld_fini=<optimized out>, stack_end=0x7fffffffdde8) at ../csu/libc-start.c:291
#114 0x000055555555a079 in _start ()

Okay, it was causing a crash while adding certificate which gave me an hint that this bug will come under  crypto-core-security in Firefox. Moving forward i report this to Mozilla. However i noticed that if i create a new profile in FirefoxESR (i.e. go to "about:profiles", "create new profile"/"launch profile in new browser") and add the same certificate it didn't cause a crash.

So it seems like there's something specific to my profile that's causing this underflow, Moving further David Keeler and me analyze cert8.db file to check for the root cause of this bug.

Where cert8.db file consists of security certificates stored separately from the Operating System. sometimes the certificate store can become corrupted.
After taking a look on cert8.db looks like something caused my certificate database to be corrupted :(

Because the legacy certificate database implementation was written before the dawn of time, there are places where it's not very careful about its inputs. In particular, it looks like if some database metadata gets corrupted, ugly_split will do an unchecked subtraction and try to operate on data it thinks is very large:


        off = hashp->BSIZE;
        for (n = 1; (n < ino[0]) && (ino[n + 1] >= REAL_KEY); n += 2) {
            cino = (char *)ino;
   = (uint8 *)cino + ino[n];
A           key.size = off - ino[n];
   = (uint8 *)cino + ino[n + 1];
            val.size = ino[n] - ino[n + 1];
            off = ino[n + 1];

B           if (__call_hash(hashp, (char *), key.size) == obucket) {

At A, we have no guarantee that off >= ino[n], so at B we pass in a very large value for the size of the key.

Mozilla Security Team change risk from None to Moderate (sec-moderate) based on that this would require modifying the user's profile on-disk to exploit.

PS: I tried exploiting this using ncat with SSL but the session is not stable and it dies.

Issue Reported: 19-11-2017
Fixed Released: 05- 12-2017
Awarded with 750$ 

For everyone who might need a better understanding of how this bug works and how it can be exploited, read further.

My Assumption:
As stated in the blog, a corruption in cert8.db causes this crash, and every beginner in BOF knows crash is how we fuzz to create an exploit.
Since there is no check in the value of the variable 'off' any overwrite can make the value of 'off' to be set lower than ino[n] resulting in the crash.
Assuming 'hashp' is a pointer to a buffer size or memory address, a lower or negative value of 'off' may be result of getting higher memory address value from the stack thus setting key.size to much greater and when you have crashes and deals with memory there is high chances that this can be taken advantage to inject shell code into memory to execute.
For now what I tired was adding a shell code in h_page.c with a handler but established connection was not stable, I am sure a more experienced exploit writer can get a reverse shell by overwriting the cert8.db