Jump to content

SirGod

Moderators
  • Posts

    784
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by SirGod

  1. Cel mai simplu ar fi sa folosesti MobSF: https://github.com/MobSF/Mobile-Security-Framework-MobSF Incarci APK si iti scoate un raport. Iti gaseste probleme de configurare si _potentiale_ vulnerabilitati. In principiu ar trebui verificate/validate. De exemplu, iti gaseste niste activitati neprotejate, dar poate sunt inutile. Sau iti gaseste folosirea unui API considerat insecure dar, la fel, poate nu este exploatabil in scenariul respectiv.
  2. Salut. Pune si link-ul daca e public si vedem care e problema.
  3. Milionari? Nu am idee. Posibil sa mai fie, dar poate mai "underground".
  4. Sunt care fac si 1.000k/an. Chiar si un roman. Asta din bug bounty. Din consultanta, iti trebuie un tarif orar de minim 50 EUR/USD pe ora (average), sa lucrezi echivalent cu un program obisnuit (40h/saptamana) si poti sa faci banii astia intr-un an. Din care mai platesti si taxele. Acum daca esti top, recunoscut, cu clienti stabili, recomandari, cred ca poti trece lejer de suma aia.
  5. Challengeul cu isadmin nu este chiar scos din burta. In cel putin 2 situatii se putea descoperi acel parametru: 1. content fuzzing - intr-un pentest/bug bounty nu faci content discovery doar pe fisiere si foldere cu dirbuster ca acum 15 ani. Faci content discovery si pe parametri GET, POST, cookies, headers si altele. Nu sunt rare situatiile in care gasesti ceva interesant, un parametru care se reflecta si scoti un XSS, un header care iti permite cache poisoning sau un cookie care iti ofera ceva permisiuni suplimentare. Da, poate nu mai gasesti "isadmin=true" ca acum 10 ani prin minunatele "Insecure Cookie Handling", dar poate ajungi intr-o interfata de development, endpoint-uri interne plus alte surprize. 2. mass assignment - desi nu e _exact_ cazul aici, challenge-ul simuleaza indeaproape vulnerabilitatile de tip mass assignment, unde "nimerirea" unui astfel de parametru te poate duce la privilege escalation (ca in cazul de fata), account takeover (manipulare user ID). Vezi aici mai multe detalii: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html Edit: Exercitiile astea, chiar daca nu sunt la ordinea zilei in rapoartele de pentest, sunt derivate din lucruri intalnite. "Chinuiala" sa le descoperi iti ofera rezilienta, sentimentul de "ce nu am verificat", mindsetul de "try harder", care sunt folositoare in viata de zi cu zi.
  6. Salut. Daca formatul este unul clasic de poza (png, jpg etc.), nu exista "sa inlaturi bulina" pentru ca nu exista nimic altceva sub. In situatia asta ai fi daca ai avea un fisier Photoshop cu layere de exemplu, sau PDF cu chenar deasupra. Pixelii de sub bulina nu exista, au fost inlocuiti. Posibil sa existe ceva software care (cum e si in Photoshop, context-aware) sa intuiasca pixelii bazandu-se pe cei alaturati, similar "AI".
  7. Da, arata mai bine, e mai usor de adaptat pe viitor. Dar face acelasi lucru, doar intr-un mod mai complicat. Daca ii trebuie pentru ceva punctual, nu recomand. Daca vrea sa integreze asta intr-o aplicatie deja scrisa intr-un anume stil si la un anumit standard, e varianta mai buna, probabil. Sunt curios de un test array vs SplFixedArray, pe datele lui reale: http://johnciacia.com/2011/02/01/array-vs-splfixedarray/
  8. <?php $data = file_get_contents("rst.json"); $parse = json_decode($data, true); echo $parse["fLeader"]; echo $parse["fRank"]; ?>
  9. Si aici este analiza celor de la grsecurity: https://grsecurity.net/huawei_hksp_introduces_trivially_exploitable_vulnerability
  10. Daca vrei sa inveti SMTP: https://tools.ietf.org/html/rfc5321 Daca vrei sa "aduni SMTP": https://www.shodan.io/ Daca vrei sa faci spam, mai gandeste-te: https://rstforums.com/forum/topic/100304-regulamentul-forumului/ https://www.legi-internet.ro/articole-drept-it/spamul-aspecte-legislative-si-jurisprudentiale.html https://www.dataprotection.ro/
  11. In anul 2019 si voi tot dupa nologine si root-uri.
  12. A făcut fix ce ți-a zis @Nytro mai sus. A pus console.log, document.write sau orice altceva în loc de eval. In felul asta, îți afișează codul în loc sa îl execute. Asta e doar primul pas. Ce poți faci mai departe e sa înlocuiești toate string-urile de forma '\x20\x22...' Sunt reprezentate în hex după cum notația cu \x le dă de gol. Poți face asta simplu cu un hex decoder sau automatizezi puțin cu un regex și faci replace în masă în tot fișierul. Apoi urmează partea grea. Urmărești codul și încerci sa înțelegi ce face. Când crezi ca ai înțeles ce face o variabila sau o funcție pune-i și un nume. Urmărește ce face codul dintr-un debugger (DevTools din Chrome e suficient), într-o sesiune curata de browser (e.g. incognito) și trece-l și prin Burp sau alt proxy local cum ți s-a zis mai sus. Pana ii dai de cap vezi dacă face ceva request-uri, dacă scrie ceva (fie elemente în DOM, fie valori în cookies, localstorage, sessionstorage etc.). E mult cod, mult de munca. Dacă timpul pe care îl petreci > valoarea pe care o aduce... Pierzi timpul. Dar măcar e educativ. Dacă ai nevoie de ajutor la chestii punctuale te ajut eu.
  13. Fa-ti forum de barbati adevarati si ragaie acolo.
  14. SirGod

    Facultate IT ID

    La Universitatea din București există informatica la ID. http://fmi.unibuc.ro/ro/idd/
  15. SirGod

    ..

    Când e vorba de prosteala, va adunați cu toții.
  16. Hai sa nu ne batem joc de comunitatea asta.
  17. Update: cautam si oameni cu experienta, nu doar junior.
  18. Deja doua bug-uri penibile, cam mare coincidenta ca să fie doar bug-uri. Poate asta e noua versiune de backdoor. Simplu, la vedere, "din greșeala". /teoriaconspiratiei
  19. Posturi insuficiente pentru Market. Categorie gresita. Gunoi.
  20. Posturi insuficiente pentru Market. Categorie gresita. Gunoi.
  21. Categorie gresita. Posturi insuficiente pentru market. Gunoi.
  22. Despre HTTPS si headere. Mai exact: HTTP Public Key Pinning HTTP Strict Transport Security Certificate Transparency Expect-CT OCSP Stapling Must-Staple Expect-Staple Certificate Authority Authorization Content Security Policy Secure Cookie Directive Link: https://depthsecurity.com/blog/pins-and-staples-enhanced-ssl-security
  23. Summary: In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of our Intel® Management Engine (ME), Intel® Server Platform Services (SPS), and Intel® Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience. As a result, Intel has identified security vulnerabilities that could potentially place impacted platforms at risk. Description: In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of its Intel® Management Engine (ME), Intel® Trusted Execution Engine (TXE), and Intel® Server Platform Services (SPS) with the objective of enhancing firmware resilience. As a result, Intel has identified several security vulnerabilities that could potentially place impacted platforms at risk. Systems using ME Firmware versions 11.0/11.5/11.6/11.7/11.10/11.20, SPS Firmware version 4.0, and TXE version 3.0 are impacted. Affected products: 6th, 7th & 8th Generation Intel® Core™ Processor Family Intel® Xeon® Processor E3-1200 v5 & v6 Product Family Intel® Xeon® Processor Scalable Family Intel® Xeon® Processor W Family Intel® Atom® C3000 Processor Family Apollo Lake Intel® Atom Processor E3900 series Apollo Lake Intel® Pentium™ Celeron™ N and J series Processors Based on the items identified through the comprehensive security review, an attacker could gain unauthorized access to platform, Intel® ME feature, and 3rd party secrets protected by the Intel® Management Engine (ME), Intel® Server Platform Service (SPS), or Intel® Trusted Execution Engine (TXE). This includes scenarios where a successful attacker could: Impersonate the ME/SPS/TXE, thereby impacting local security feature attestation validity. Load and execute arbitrary code outside the visibility of the user and operating system. Cause a system crash or system instability. For more information, please see this Intel Support article Link Advisory: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
  24. During a black-box penetration test we encountered a Java web application which presented us with a login screen. Even though we managed to bypass the authentication mechanism, there was not much we could do. The attack surface was still pretty small, there were only a few things we could tamper with. 1. Identifying the entry point In the login page I noticed a hidden POST parameter that was being sent for every login request: <input type="hidden" name="com.ibm.faces.PARAM" value="rO0..." /> The famous Base64 rO0 (ac ed in HEX) confirmed us that we were dealing with a Base64 encoded Java serialized object. The Java object was actually an unencrypted JSF ViewState. Since deserialization vulnerabilities are notorious for their trickiness, I started messing with it. Full Article: https://securitycafe.ro/2017/11/03/tricking-java-serialization-for-a-treat/
×
×
  • Create New...