mah_one

Observ ca mai este un loc in solvers list, trece-l si pe FAKE USERNAME!!! Sensi, ai dreptate, trebuie facut un poll pe aceasta tema.

Eu nu va inteleg de ce faceti challenge-uri pe site-uri care nu va apartin. Este ca si cum ai zice "Hai sa furam baza de date de la site-ul xxxxxxxxxxx". De ce nu faci tu un script in php si sa il urci pe un hosting gratuit? De ce trebuie sa exploatati un sqli intr-un site din Thailand? Poate tu nu esti rau intentionat, dar s-ar putea sa se gaseasca unii sa exploateze acelasi sqli in respectivul site, iar cei care s-au implicat in challenge-ul tau vor fi si ei in aceeasi oala. Eu cred ca trebuie o regula de genul: "FARA CHALL-URI PE SITE-URI CE NU VA APARTIN!". Poate sunt si minori care au havij, sqlmap si stiu doua taste in backtrack, dar nu stiu ca ceea ce fac este ilegal.

Nu ai nici un motiv sa fi frustrat. Te-au rugat ei sa le testezi site-ul? Ai contract cu ei si nu ti-au dat banii? Eu nu inteleg care e problema ta. Normal ca nu se merita sa cauti probleme in banci, de ce? 1. poti fi acuzat 2. nu ei te-au pus si nu sunt obligati sa te plateasca. Sincer, si eu cautam ca tine probleme prin website-uri si ma asteptam la bani, iar cand nu primeam ceva, taceam si gata.

Voi observati ca el si-a facut discursul, l-a pus pe calculator si il citeste cand s-a filmat? Sa va uitati la miscarea ochilor, clar citeste.... Ovidiu Anghelidi, nu am nimic personal cu tine si sper ca aceste critice pe care le-ai primit sa nu te descurajeze in ceea ce faci si nu numai. Eu nu stiu exact ce ai facut, asta si din cauza ca nu am stat sa citesc/ascult tot ce ai avut de zis in articole/filmulete. Vreau doar sa intelegi ca noi vedem altfel lucrurile. Nu le vedem altfel din cauza ca ne credem mai despteti ca tine, poate nici nu suntem, dar nu ai explicat cum trebuie. Tu vi pe un forum in care media de varsta este de 25 ani. Unde unii abia acum intra pe cercetare, iar tu vi cu niste filmulete in care vrei sa ne explici si sa intelegem ceva ce poate e peste puterea noastra de intelegere (neurochirurgie, fizica, etc). Eu cred ca ar trebuie sa iti cauti un sponsor, sa il convigi sa te ajute in cercetare si nu sa te lauzi pe un forum de securitate. P.S.: Daca ai fi venit cu o prezentarea mai elaborata in ceea ce priveste acel algoritm, ar fi fost ceva interesant.

Algoritimii DES, TripleDes, AES, algoritmi simetrici, pornesc de la un vector initial, despre care nu mentionezi. Daca schimbi vectorul initial ai output diferit pentru acelasi input si acelasi passphrase. SAU poate vroiai sa ne zici de PADING. Orice algoritm de codificare simetric prelucreaza blocuri de date de lungime fixa. Si se doreste ca inputul sa aibe o lungime multipla de dimensiunea unui bloc (16, 32 biti....). Ca sa nu mai oblige programatorul sa masoare textul si sa il ajusteze in vreun fel, niste baieti destepti au creat CBC-ul. Si ca sa nu iti vorbesc prostii o sa iau putin de pe google metodele de pading si descrierea lor si am sa pun intre ghilimele tot ce am luat de acolo si va fi traducere proprie. Exista doua moduri principale de operare la nivel de bloc pentru cifruri. CBC "cipher-block chaining" si "ECB - Electronic codebook". #1 "Problema ECB este ca pentru blocuri identice de input rezulta acelasi output, deci, nu efectueaza o dispersie buna pentru textul codificat si cifrul rezultat poate fi usor spart" Ma gandesc ca la asta te refereai. #2 Dar mai exista si CBC -> Astfel, la schimbarea unui singur bit din textul de criptat sau din vectorul intial afecteaza toate blocurile de text care urmeaza dupa acesta

Eu cred ca ar fi mult mai util sa il gandesti altfel. E cam aiurea sa ai o lista de vectori si sa faci bruteforce (din punctul meu de vedere). Nu vezi comportamentul aplicatiei. Ai putea sa faci programul de asa natura incat sa vada ce caractere nu sunt filtrate, iar la urma sa iti vina cu un raport in care sa iti zica acele caractere. Dupa acest raport tu o sa stai si o sa te gandesti la cum sa scoti ceva de acolo. Spre exemplu primele incercari ar putea fi: vector = 't3st1234 vector = "t3st1234 vector = <t3st1234 sau vector = t3st1234< vector = >t3st1234 sau vector = t3st1234> Parsezi raspunsul de la server pana la t3st1234 si vezi ce s-a intamplat cu ' " > <. .......... Encode %22 %27 %3e %3c sau double encode %2522 %2527 %253e %253c sau html encode a.... .......... La sfarsit sa iti vina cu un raport in care iti precizeaza un grad de risc dupa o metodologie proprie. In functie de acest grad de risc te hotarasti daca se merita sa faci tu manual ceva sau nu. Felicitari pentru munca depusa in dezvoltarea respectivului tool. E bine sa lucrezi la astfel de proiecte. Fara suparare, dar eu vad altfel lucrurile si nu cred ca un astfel de tool m-ar putea ajuta.

Sunt ~ 100 de zile pana la data respectiva. Clar e de la IMWorld.

Am gasit, ieri, un DOM XSS in *.yahoo.com sper sa dea ceva bani... Felicitari pentru Stored XSS.

Si eu am primit odata 50$ - "Initial Payment", iar "Remaining bounty" a fost de 450$ pe un XSS in billsafe.de

Buna, Am gasit prin mai un bug intersant in facebook prin aprilie (este fixed) si puteam adauga orice numar de telefon in contul meu fara sa ii mai bag codul de verificare. Spre exemplu puteam sa pun un numar de genul 7777777777 sau 0722222222 (numerele adaugate fiind verificate), puteam sa adaug si un numar existent de pe alt cont, sa il fac duplicate la mine in cont. Ideea e ca nu prea cunosc eu facebook-ul si doresc sa stiu cam ce as fi putut sa fac cu un astfel de bug. Unul din scenarii la care ma gandesc este ca in USA se poate plati doar cu numarul de telefon pe Facebook. Vreau doar pareri in legatura cu ce as fi putut sa fac cu un astfel de bug. In momentul de fata nu vad nici un risc pentru ce am gasit, in abordarea pe care am avut-o cu cei de la facebook nu am aratat acest lucru (ii las pe ei sa se gandeasca la ce as fi putut face).

E bine ca ii platesc pe toti cei care au gasit dupa 1 Iulie

I reported myself, but the article was written by vulnerability-lab.

Video P.o.C.: http://www.youtube.com/edit?ns=1&video_id=Txj_uFYTVuo

Buna, Vreau sa arat cat de seriosi sunt cei de la paypal. Va rog sa dati mai departe Delete any account on paypal | full story EDITED: Nu am nici o legatura cu Domnul.Do, iar cine il cunoaste personal stie ca e un om de incredere. Domnul.Do poate sa confirme ca puteam sa sterg conturi de paypal si sa le creez la loc cu alta parola. Toate cele bune, Cernica Ionut

Lipsesc certificarile... Sa vad cum imi fac timp ca e cam greu cu master-ul.

Cernica Ionut-Cosmin - LinkedIn

Sa vedeti ce sistem de autentificare au cei de la ebay pe unul din site-urile lor. Am gasit in pagina sursa asta: <script> function do_pass_check() { if (document.signin.username.value == 'test' && document.signin.password.value == 'password'){ document.signin.submit(); } else { alert ("Wrong credentials!"); } } </script> Parola a mers:)). Am facut un brute force pe directoare pe unul din subdomenii si am ajuns la o pagina de autentificare. EDITED: Tin sa precizez ca e un project de-al lor foarte mic si nu are legatura cu ce inseamna ebay cu adevarat. Site-ul nu e cine stie ce, drept pentru care au cel mai bun sistem de autentificare din lume!

Sal, Am gasit in site-ul celor de la Marktplatts doua privilege escalation. #1 Puteam sa dau delete la orice reclama. #2 Am reusit sa postez reclame in numele altuia. Astia de la Marktplatts mi-au trimis un email foarte ridicol. Au considera ca cele doua probleme au fost cauzate de o singura problema. Dear Ionut, Both issues had the same root cause. Best Regard, Pieter Vlasblom Pe mine ma face sa rad mesajul lor. Ca sa intelegeti ce s-a intamplat am sa dau un exemplu: Cum ar fi sa gasiti doua SQLi si anume: google.com/test?id=SQLi si in google.com/anothertest?id=SQLi (o alta functionalitate) Iar cei de la google sa va zica ca sunt valide cele doua probleme, dar vor considera ca ai gasit o singura problema fiindca ambele au aceeasi cauza (adica cei din dev team au utiat sa foloseasca prepared statement). Mai am de mentionat ca ce am gasit afecteaza functionalitatea principala al acelui website. Site-ul era de advertising, iar eu puteam da delete la orice advertise si puteam sa postez in numele altor firme. Zic asta fiindca am primit minimum bounty pe ceva ce ar fi trebuit sa fie, ma rog, maxium bounty.

Am incercat sa fac si eu asta, dar nu a iesit

Sa va dau un sfat cu astia de la paypal, aveti grija sa nu trimiteti 3,4 bug-uri intr-un singur report. Daca gasesc unul duplicate sau invalid, iar restul valide, vei primii invalid pe tot report-ul. Va zic din experienta. Pe lista care tot o trimit cu statusul la bug-uri, am 44 de iregistrari (ele sunt mult mai multe, fiindca am raportat mai multe odata). Vreau sa zic ca am exact 20 de inregistrari (Valid si Paid). Am ratat top 10 fiindca nu le-am trimis rapoarte separate. Spre exemplu am un bug la care si ei au acceptat "IMPORTANT CSRF vulnerabilities + XSS ". Intr-o pagina aveam CSRF(puteam sa adaug email, telefon si adresa) si un Stored XSS. In raport le-am mai trimis o problema(cum sa fur adrese(adresa unde sta user-ul, EX: strada Lalelelor, etc) random). So, erau 4 problem valide, ei au considerat ca sunt doar doua probleme -> XSS si CSRF, dar au platit numai 1000$, iar problema cu furatul de adrese, nu au mai zis nimic. Cum draq sa dai 1000$ pe un CSRF prin care adaugi o adresa de email, adresa unde sta user-ul si numar de telefon + un Stored XSS la adresa? (toate erau request-uri diferite).

Eu nu mai suport prostia astora de la paypal. Vineri le-am zis ca bugul e rezolvat, si i-am rugat a mia oara sa se mai uite prin ce aveau la data cand le-am trimis bugul si sa vina cu un feedback. Ei inca incearca sa reproduca bugul si imi vin cu prostii: Thanks for your message. On the bug in question, we had tested this multiple times without it executing. We cannot execute this without evidence that could lead us to its successful reproduction and will not investigate it further until we have some. Even with the POC included, it was not successful for us as we noted in our email exchanges with you as late as 7/2. Ma las pagubas.

Mesajul lor de pe 05/08/2013, nu avea uid, ei zic ca s-a creat o confuzie si ca au vorbit de bugul din billsafe.de Dar eu am explicat de ce nu avea cum sa vorbeasca de acel bug. Logic, raspunsul a fost pentru problema "delete any account", mai ales ca era un raspuns la ce i-am rugat sa imi raspunda. Probabil nu ai inteles ordinea evenimentelor: - Pe 02/07/2013 primesc un email in care isi cer scuze pentru ca au validat problema ca mai apoi sa ii atribuie status-ul "Submitted". - Eu ii rog sa se mai uite si sa vorbeasca cu dev team-ul lor, iar ei sunt de acord. - Pe 02/08/2013 le zic sa uite de billsafe.de, dar sa imi dea un feedback in legatura cu "delete any account" - pe 05/08/2013 imi dau un raspuns clar( pentru mine) in legatura cu "delete any account", si anume ca problema e valida si ca a fost fixata imediat. - dupa aceasta data imi mai da un report status la toate probleme de securitate, iar problema "delete any account" si celalalt doua din billsafe.de au fost tot "invalide" (am zis ca au uitat sa treaca, fiindca oricum una din ele era valida). - 21/08 a fost publicat in softpedia articolul - 23/08 paypal m-au luat la intrebari in legatura cu articolul. - 23/08 paypal mi-au zis nu au validat "delete any account", ci ultimul auth bypass din billsafe.de Dar nu are logica raspunsul lor, si nu il mai argumentez odata, cititi postul de mai sus. In ultimul rand raspunsul in care au validat o problema, raspuns ce a lasat loc la interpretari, a fost dat in urma unei intrebari foarte clare: "I would like to have an final answer about what happened with the problem with delete any account on paypal."

PayPal Fixes Vulnerability That Allowed Hackers to Delete Any Account – Video (Updated) Paypal said: "Update. PayPal has reached out to Softpedia with the following statement: “Despite recent reports of a PayPal vulnerability that allows users to delete any account and replace it with one of their own, we want to confirm that we have never received any valid bugs related to that issue on PayPal.com and did not issue a reward for it. If a researcher identifies a valid bug on our site, we encourage them to responsibly report it to our Bug Bounty program so we can reward and recognize those researchers that help keep PayPal a safer place for our customers.” E a doua oara cand paypal valideaza problema ca apoi sa nu o recunoasca (au venit cu niste interpretari idioate care o sa le prezint intr-un articol zilele astea). Articolul ce il voi scrie va avea doua subiecte: - idiotii de la vulnerability lab - paypal Doar ce este intre ghilimele este scris de mine, restul sunt minciuni de la vulnerability lab (inca nu imi este clar de ce au scris chestia aia, iar Kunz Mejir nu vrea sa imi raspunda la intrebare). Paypal au validat problema pe 05.08.2013, iar in mesajul de validare nu au specificat bugul, dar era logic la ce bug s-au referit. Problema a existat, Domnul.Do si toshiba poate sa confirme problema descoperita( le-am facut o demonstratie). https://rstforums.com/forum/68534-p-y-p-l.rst#post442967 Am sa dau mai multe detalii intr-un articol ce il voi posta zilele astea. Mesajul meu 02/08/2013: Hi Art, Anything about the research you made? Forgot the problem with billsafe.de, just review the last report on that website, because the issue still exists. I would like to have an final answer about what happened with the problem with delete any account on paypal. I know that I'm not able to take any bounty for that problem, because you don't know what happened, but I would like to make it public and I want your feedback regarding the existence of this issue. All the best, Cernica Ionut Raspunsul lor 05/08/2013 Cernica, Thank you for your patience. We have received an update that this item has been found valid and immediately fixed. Our development team wanted me to pass on to you that this was a good find. I apologize for the delay, but we needed a few more developers to look at this in depth. Kind regards, Art Vineri seara (23/08/2013), m-au luat la intrebari in legatura cu minciunile din regsiter.co.uk. Le-am explicat ca ce am zis eu este scris intre ghilimele, restul sunt minciuni de la vuln-lab. Le-am mai zis ca ce era intre ghilimele am scris fiindca ei au validat problema "delete any account". Ei mi-au zis ca nu au validat problema cu "delete any account" ci ultima problema din billsafe. De ce cred ca paypal minte? Strong arguments: #1 intrebarea era despre "delete any accont" #2 Au zis ca a fost gasit valid si imediat rezolvat - "has been found valid and immediately fixed". Ultima problema din billsafe.de a fost gasita tot in aprilie si rezolvata recent (am email cu ultimul hash vulnerabili la data de 02/08/2013). Problema "delete any account" a fost validata si rezolvata imediat. #3 "but we needed a few more developers to look at this in depth". De ce draq trebuie sa se uite o armata de developeri pe un amarat de bug, care in 2 minute putea fi confirmat. Va zic eu de ce au avut nevoie de "few more dev", fiindca trebuia sa se uite pe cod sau sa ii intrebe pe toti developerii, cine a fixat problema cu "delete any account" si ce inginer de securitate a raportat aceasta problema. In plus chiar ei au zis ca vor ajunge sa intrebe dev team cu acest bug. Not so strong arguments: #3 Cuvantul "update", de ce update si nu notification? Eu doar le-am raportat o problema, ca oricare alta, nu au fost probleme de genul sa imi invalideze problema ca el sa primesca un "update". #4 "Our development team" - Cand vorbeau de dev team-ul din billsafe.de precizau clar, citez: "I'm touching base with the Billsafe team now". Raspunsul de la paypal: The bug you are referencing from 8/5 was for BillSafe, UID Ah113ftM. Your email was entitled - "Art" billsafe.de" and we were referencing that BillSafe issue you inquired about. The same email thread contains a status update that notes the bug in question from the article, oebaLK, as invalid. I am not sure where your confusion arises from which bug was fixed, but I don't see any indication given from the email you note that oebaLK was anything but invalid. Da primisem un bug report in care "delete any account" era invalida, dar si celalalte doua din billsafe.de erau invalide, iar eu am crezut ca au uitat sa modifice. Imediat dupa ce am trimis problema au validat bugul, iar un scuze au zis abia pe 02/07/2013 7:04 AM: I apologize for the inconvenience. We notified you in May that the incorrect response was sent regarding UID oebaLK and advised you it was in submitted status rather than valid status. O sa fac un articol amanuntit cu ce s-a intamplat.

Nu are rost sa spun cum se face "apa calda", detalii gasiti aici: Security Tools Benchmarking: Session Puzzling and Session Race Conditions

in 3 ore i s-a facut un patch a doua zi am primit badge-ul