Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/10/20 in all areas

  1. O metoda super veche pe care am folosit-o si functioneaza ok pentru a "elimina competitia" sau "derank" din motorul de cautare google, functioneaza pe site-urile care folosesc platforma wordpress. 1. Luam site-ul, printr-un miracol facem rost de multe link-uri de pe acel site. 2. Ai link-urile pregatite, la fiecare final de link adaugi termeni de cautare random. 2.1. Practic http://exemplu.tld/categorie/subcategorie/ http://exemplu.tld/categorie/subcategorie-2/ http://exemplu.tld/categorie/subcategorie-3/ http://exemplu.tld/hello-world/ http://exemplu.tld/hello-world-2/ http://exemplu.tld/hello-world-3/ devine http://exemplu.tld/categorie/subcategorie/?s=filme+gratis+2012+online http://exemplu.tld/categorie/subcategorie/?s=filme+gratis+2012+online+subtitrate http://exemplu.tld/categorie/subcategorie-2/?s=scapa+de+calorii+gratis http://exemplu.tld/categorie/subcategorie-3/?s=un+dermatolog+a+gasit+o+noua+crema+pentru+marirea http://exemplu.tld/categorie/subcategorie-3/?s=un+dermatolog+a+gasit+o+noua+crema+pentru+marirea+unghiului http://exemplu.tld/hello-world/?s=cumpara+crema+pentru+marirea+creierului+online http://exemplu.tld/hello-world-2/?s=cum+sa+faci+bani+2019 http://exemplu.tld/hello-world-2/?s=cum+sa+faci+bani+2016 http://exemplu.tld/hello-world-2/?s=cum+sa+faci+bani+2014 http://exemplu.tld/hello-world-2/?s=cum+sa+faci+bani+2020 http://exemplu.tld/hello-world-2/?s=cum+sa+faci+bani+online http://exemplu.tld/hello-world-3/?s=slabire+in+7+zile http://exemplu.tld/hello-world-3/?s=slabire+in+7+zile+2020 3. Teoretic vrem sa generam cat mai multe 404-uri. Mai departe va descurcati voi ca google sa afle de link-urile pe care le-am generat. Ce ar trebui sa se intample? Domnul search engine vede ca sunt foarte multe 404-uri si scoate rezultatele din cautari.
    2 points
  2. When hunting for security issues, the pursuit for uncharted assets and obscure endpoints often ends up taking the focus away from obvious, but still critical, functionality. If you approach a target like you are the first person to ever perform a security assessment on it, and check everything thoroughly, I believe you are bound to find something new — especially if the code you are testing has been in continuous development for a while. This is the story of a high-severity bug affecting what is probably one of PayPal’s most visited pages: the login form. Initial discovery While exploring PayPal’s main authentication flow, I noticed a javascript file containing what appeared to be a CSRF token and a session ID: This immediately drew my attention, because providing any kind of session data inside a valid javascript file usually allows it to be retrieved by attackers. In what is known as a cross-site script inclusion (XSSI) attack, a malicious web page can use an HTML <script> tag to import a script cross-origin, enabling it to gain access to any data contained within the file. Sure enough, a quick test confirmed the XSSI vulnerability and, although a javascript obfuscator was used to randomize variable names on each request, the interesting tokens were still placed in fairly predictable locations, making it possible to retrieve them with just a bit of extra work. However, a secret is only as good as the damage you can do with it. I immediately set out to find out what exactly _csrf and _sessionID were and if they could actually be used in a real attack. Digging further After countless attempts to replace regular CSRF tokens inside authenticated requests on PayPal’s platform with the value of _csrf, I came to the conclusion that a classic cross-site request forgery attack was not possible using this specific token. Similarly, a victim’s _sessionID was unfortunately not enough to impersonate them on PayPal’s site. Next, I went back to the vulnerable script and followed the tokens to find what they were actually used for. This led to a deep dive into one of PayPal’s main protection mechanisms used to prevent brute force attacks, the security challenge. While this functionality is used in many places, I will be focusing on the main login form. The idea is pretty simple: After a few failed login attempts, you are required to solve a reCAPTCHA challenge before you can try again. The implementation, however, may raise some eyebrows. Upon detecting a possible brute-force attempt, the response to the next authentication attempt is a page containing nothing but a Google captcha. If the captcha is solved by the user, an HTTP POST request to /auth/validatecaptcha is initiated. The familiar _csrf and _sessionID are present in the request body, as well as two other values, which we will get to a bit later. The response to the captcha validation request is meant to re-introduce the user into the authentication flow. To this end, it contains a self-submitting form with all the data provided in the user’s latest login request, including their email and plain text password. I realized that, with the correct timing and some user interaction, knowing all the tokens used in this request was enough to get the victim’s PayPal credentials. In a real-life attack scenario, the only user interaction needed would have been a single visit to an attacker-controlled web page. So I went back and tried to figure out what the missing parameters were. This was easier than expected: The value of jse was not validated at all. recaptcha was the token provided by Google upon solving a reCAPTCHA challenge. It was not tied to a specific session, so any valid token— for example, from an automated solving service — would be accepted. Exploitation Putting all this together, I created a proof of concept that demonstrated the whole process, except for integrating a captcha solving service. First, the proof of concept would exploit the initial XSSI vulnerability to get a set of tokens which were valid in the victim’s session. It would then launch a few authentication requests with random credentials from the victim’s browser, simulating a brute force attempt, which would trigger the security challenge flow. Once the victim logged in to PayPal using the same browser, the cached random credentials would be replaced by the user’s own email and password. The last step was obtaining a fresh reCAPTCHA token, after which the plain text credentials would be retrieved from the /auth/validatecaptcha endpoint and displayed on the page. The final page shown by my proof of concept code contained your email and password I later found that the same vulnerable process was also used on some unauthenticated checkout pages, allowing plain text credit card data to be leaked using the same technique. Disclosure The proof of concept, along with all relevant information, was submitted to PayPal’s bug bounty program on the 18th of November 2019, and was validated by HackerOne 18 days later. Following a quick acknowledgement by the PayPal team and a few additional questions, I was awarded a $15,300 bounty on the 10th of December. The reward amount corresponds with the bug’s 8.0 (High) CVSS score, which is the same score that I had initially suggested when submitting the report. A patch was applied around 24 hours later, meaning that the bug was fixed only five days after PayPal became aware of it — quite an impressive turnaround time. Fix and prevention advice The /auth/validatecaptcha endpoint now requires an additional CSRF token, which cannot be leaked using cross-site script inclusion. While this properly fixes the vulnerability, I believe that the whole thing could have been prevented when designing the system by following one of the oldest and most important pieces of infosec advice: Never store passwords in plain text. By the way, I am looking to do security assessments and bug bounty program management work. I have experience in security testing, vulnerability triage, as well as a background in software development. Does this sound of interest to you? You can get in touch via alex@ethicalhack.ro. Source https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9
    1 point
  3. Am vorbit azi cu el prin mesaje , si mi-a spus ca nu mai are de vanzare nicio carte asa ca o sa raman cu domentatia lui pe pagina lui sau cred ca o sa cumpar ce mi-a recomandat Nytro , momentan pana imi ajunge Serious Cryptography mai am de terminat vreo 3 cursuri despre criptografie ale lui Christof Paar care sunt pe youtube . Multumesc pentru tot !
    1 point
  4. Daca vrei sa citesti cartea domnului Nicolae Constantinescu, probabil ai luat cel putin odata contact cu el, in caz ca erai atent la ce vorbea, ai fi auzit ca pe pagina sa personala de la facultate, a pus toata documentatia de care ai nevoie sa inveti ceea ce doresti. Diferenta este ca e scrisa in engleza. Daca vrei neaparat cartea respectiva, poti vorbi cu cineva din camine de an mai mare sa o cumperi, mai erau cateva persoane care o aveau, in caz canici asa nu reusesti, cea mai usoara metoda este sa te duci personal la dansul, si sa il rogi daca se poate sa iti dea si tie cartea sa ii faci un xerox in incinta facultatii.
    1 point
  5. Si eu am avut cu domnul Constantinescu cursuri. Om mai dubios ca el nu exista pe planeta asta. Nu inteleg de ce ai citi ceva scris de el cand sunt atatea carti de specialitate mult mai bune, up to date.
    1 point
  6. https://www.google.com/search?source=hp&ei=4tgXXq23MIvYwALix4OwCA&q=inurl%3Ascribd.com+Criptografie+de+Nicolae+Constantinescu&oq=inurl%3Ascribd.com+Criptografie+de+Nicolae+Constantinescu&gs_l=mobile-gws-wiz-hp.12...2509.56540..58107...3.0..0.143.2362.6j15......0....1j2.......5..41j0j46j0i10.RRJ_rQWZqJY Vezi pe primele doo, 3 pagini, cauta si pe bing Vorba lui Zata, o cumperi Edit: o poti cumpara si de pe aici, un borcan de zaciscă si 10 tigări https://okazii.ro/recomandate/10a-363-nicolae-constantinescu-criptografie-a122818013 Edit,: e mai bine sa o citeşti în format copac, ramane imprimata in bostan, ebook e doar rapid la fel cum e diferenta dintre o carte si un film
    1 point
×
×
  • Create New...