Leaderboard

Pentru ca multi stiu ca n-au posibilitatea, dar mai ales pentru ca multumita RST-ului am ajuns unde sunt acum, m-am gandit sa dau ceva inapoi. Din acest moment, orice membru RST, cu cel putin 50 de post-uri de calitate are din partea mea hosting GRATUIT si aici nu ma refer doar la webhosting, ci, in functie de nevoile fiecaruia, inclusiv VPS, VDS, dedicate sau cloud (in curand). Toti membrii care au acum hosting de la mine, din acest moment, sunt scutiti de plata cu conditia ca au un singur serviciu gratuit (spre exemplu, daca aveti 3 servere, unul va fi gartuit de acum inainte). Ideea este ca am fost si eu in papucii vostrii si stiu uneori, cat de greu, daca nu imposibil, va este sa obtineti un webhost sau un server gratuit. Doresc prin aceasta initiativa sa sustin pe cei care au idei, mai ales de business-uri online, sa se ridice. Ca orice cacat moka, trebuie sa avem si 2-3 reguli, de bun simt, evident: 1. NU primiti dedicate decat daca dovediti ca aveti nevoie de ele. 2. NU aveti voie sa gazduiti fisiere de tip audio/video (nici macar pentru streaming) daca nu va apartin. 3. Cine foloseste acest serviciu in scopuri ilegale (d-alea de imi bate diicot-ul la usa) va suferi consecintele. 4. Aveti dreptul la UN SINGUR serviciu moka! 5. IMI REZERV DREPTUL de a respinge pe cei care doresc sa gazduiasca servere de jocuri... La aceste reguli, bineinteles, se adauga si regulamentul de pe site-ul nostru: Serviciile disponibile le gasiti acum pe purehost.ro - Ulltimate hosting sollutions | best anti-DDoS protection | 100% uptime (site-ul este inca in constructie asa ca sa n-aud comentarii). Cei interesati sunt liberi sa ma contacteze pe urmatoarele cai: - PM (mesaj PRIVAT) pe forum - Yahoo!Messenger: th3acidripp3r@yahoo.com - Skype: softguard.datacenter Lista beneficiarilor: yo20063, Eric, em, cheater, sclipici, Cifre, p3tru, Reckon, mad93, robertutzu, Gecko, shaggi, icode, awnly3jhc2g, nSnoopy, hackedss, Wav3 L.E.: NU, NU ofer si domenii GRATIS, wtf guys!

XXE in OpenID: one bug to rule them all, or how I found a Remote Code Execution flaw affecting Facebook's servers Hi, since I don't write much, let me first introduce myself. My name is Reginaldo Silva and I'm a brazilian computer engineer. These days I work mostly with information security, with a special interest in Web Application Security. I.E. if you let me, I'll find ways to hack into your site or application, hopefully before the bad guys do. You'll find a little more information about me going to my home page. Today I want to share a tale about how I found a Remote Code Execution bug affecting Facebook. Like all good tales, the beginning was a long time ago (actually, just over a year, but I count using Internet Time, so bear with me). If you find this interesting and want to hire me to do a security focused review or penetration testing in your own (or your company's) code, don't hesitate to send me an email at reginaldo@ubercomp.com. September 22nd, 2012 was a very special day for me, because it was the day I found a XML External Entity Expansion bug affecting the part of Drupal that handled OpenID. XXEs are very nice. They allow you to read any files on the filesystem, make arbitrary network connections, and just for the kicks you can also DoS the server with the billion laughs attack. I was so naive at the time that I didn't even bother to check if anyone else was vulnerable. I reported it immediately. I wanted to start putting CVEs on my resume as soon as possible, and this would be the first (it eventually got CVE-2012-4554 assigned to it). Only five days later it occurred to me that OpenID was pretty heavily used and so maybe other places were vulnerable as well. I decided to check the StackOverflow login form. Indeed, it was vulnerable to the whole thing (file reading and all). Then I decided to try to find OpenID handling code running inside Google's servers. I wasn't able to read files or open network connections, but both App Engine and Blogger were vulnerable to DoS. This is how I got my first bounty from Google, by the way. It was a US$ 500 bounty. After reporting the bug to Google, I ran some more tests and eventually noticed that the bug I had in my hands was affecting a lot of implementations. I won't enumerate the libraries here, but let me just say that this single bug affected, in one way or another, libraries implemented in Java, C#, PHP, Ruby, Python, Perl, and then more... The only reason I'm not publishing the PoC here is that there are a lot of servers who are still vulnerable out there. Of course, the people who know about security will just read OpenID and XXE and then write an exploit in about 5 minutes, but I digress. So after contacting (or trying to contact) every OpenID library author out there, I decided to write to the member-only security list hosted at the OpenID foundation an email titled "One bug to rule them all: many implementations of OpenID are vulnerable to XXE" to share my findings. I figured most library authors would be members of that list and so patches would be released for everyone very soon. I was right, but only partially. The persistent readers who are still with me by now are thinking: what does a Facebook Remote Code Execution bug has to do with all this? Well, I knew Facebook allowed OpenID login in the past. However, when I first found the OpenID bug in 2012 I couldn't find any endpoint that would allow me to enter an arbitrary OpenID URL. From a Google search I knew that in the past you could do something like https://www.facebook.com/openid/consumer_helper.php?openid.mode=checkid_setup&user_claimed_id=YOUR_CLAIMED_ID_HERE&context=link&request_id=0&no_extensions=false&third_party_login=false, but now the consumer_helper.php endpoint is gone. So for more than a year I thought Facebook was not vulnerable at all, until one day I was testing Facebook's Forgot your password? functionality and saw a request to https://www.facebook.com/openid/receiver.php. That's when I began to suspect that Facebook was indeed vulnerable to that same XXE I had found out more than a year ago. I had to work a lot to confirm this suspicion, though. Long story short, when you forget your password, one of the ways you can prove to Facebook that you own an @gmail.com account is to log into your Gmail and authorize Facebook to get your basic information (such as email and name). The way this works is you're actually logging into Facebook using your Gmail account, and this login happens over OpenID. So far, so good, but this is where I got stuck. I knew that, for my bug to work, the OpenID Relying Party (RP - Facebook) has to make a Yadis discovery request to an OpenID Provider (OP) under the attacker's control. Let's say Ubercomp. Then my malicious OP will send a response with the rogue XML that will then be parsed by the RP, and the XXE attack will work. Since the initial OpenID request (a redirect from Facebook to Google) happens without my intervention, there was no place for me to actually enter an URL under my control that was my OpenID identifier and have Facebook send a Yadis Discover request to that URL. So I thought the bug would not be triggered at all, unless I could somehow get Google to send Facebook a malicious XML, which was very unlikely. Fortunately, I was wrong. After a more careful reading of the OpenID 2.0 Specification, I found this nice gem in session 11.2 - Verifying Discovered Information: I checked and, indeed, the openid.identity in the request was Final: OpenID Authentication 2.0 - Final. This is a very common practice, actually. So indeed after a few minutes I was able to make a request to https://www.facebook.com/openid/receiver.php that caused Facebook to perform a Yadis discovery on a URL under my control, and the response to that request would contain malicious XML. I knew I had a XXE because when I told Facebook's server to open /dev/random, the response would never come and eventually a request killer would kick in after a few minutes. But I still couldn't read any file contents. I tried everything on the XXE back of tricks (including weird combinations involving parameter entities, but nothing. I then realized I had a subtle bug on my exploit that, fixed that, and then... That's right, the response contained Facebook's /etc/passwd. Now we were going somewhere. By then I knew I had found the keys to the kingdom. After all, having the ability to read (almost) any file and open arbitrary network connections through the point of view of the Facebook server, and which doesn't go through any kind of proxy was surely something Facebook wanted to avoid at any cost. But I wanted more. I wanted to escalate this to a full Remote Execution. A lot of bug bounty programs around the web have a rule that I think is very sensible: whenever you find a bug, don't linger on messing around. Report the bug right away and the security team will consider the worst case scenario and pay accordingly. However, I didn't have much experience with the security team at Facebook and didn't know if they would consider my bug as a Remote Code Execution or not. I Since I didn't want to cause the wrong impressions, I decided I would report the bug right away, ask for permission to try to escalate it to a RCE and then work on it while it was being fixed. I figured that would be ok because most bugs take a long time to be processed, and so I had plenty of time to try to escalate to an RCE while still keeping the nice imaginary white hat I have on my head. So after writing the bug report I decided to go out and have lunch, and the plan was to continue working when I came back. However, I was wrong again. Since this was a very critical bug, when I got back home from lunch, a quick fix was already in place. Less than two hours after the initial report was sent. Needless to say, I was very impressed and disappointed at the same time, but since I knew just how I would escalate that attack to a Remote Code Execution bug, I decided to tell the security team what I'd do to escalate my access and trust them to be honest when they tested to see if the attack I had in my mind worked or not. I'm glad I did that. After a few back and forth emails, the security team confirmed that my attack was sound and that I had indeed found a RCE affecting their servers. So this is how the first high impact bug I ever found was the entry point for an attack that probably got one of the highest payouts of any web security bug bounty program. Plus, and more importantly, I get to brag I broke into Facebook... Nice, huh? Oh, by the way, the Facebook security team wrote a post to tell their side of the story. Join the discussion on Hacker News. Timeline All timestamps are in GMT. I omitted a few unimportant interactions about the acknowledgements page and such. 2013-11-19 3:51 pm: Initial report 2013-11-19 5:37 pm: Bug acknowledged by security team member Godot 2013-11-19 5:46 pm: I replied by sending a PoC to read arbitrary files 2013-11-19 7:31 pm: Security team member Emrakul informed me that a short term fix was already in place and would be live in approximately 30 minutes 2013-11-19 8:27 pm: I replied confirming that the bug was patched. 2013-11-21 8:03 pm: Payout set. The security team informed me it was their biggest bounty payout to date. 2013-11-22 2:13 am: I sent an email asking whether the security team had already considered the bug as RCE or just as a file disclosure. 2013-11-23 1:17 am: Security team replied that they did not considered the attack could be escalated to RCE. 2013-11-23 7:54 pm: I sent an email explaining exactly how the attack could be escalated to an RCE (with file paths, example requests and all). 2013-11-24 9:23 pm: Facebook replied that my attack worked and they'd have to work around it. 2013-12-03 4:45 am: Facebook informed me that the longer term fix was in place and that they'd soon have a meeting to discuss a new bounty amount 2013-12-03 7:14 pm: I thanked them and said I'd cross my fingers 2013-12-13 1:04 pm: I found a Bloomberg article quoting Ryan McGeehan, who managed Facebook's incident response unit, saying that "If there's a million dollar bug, we will pay it out" and asked if there was any news. 2013-12-30 4:45 am: Facebook informed me that, since the bug was now considered to be RCE, the payout would be higher. I won't disclose the amount, but if you have any comments about how much you think this should be worth, please share them. Unfortunately, I didn't get even close to the one-million dollar payout cited above. In case you're wondering, I quoted Mr. McGeehan mostly as a joke. http://www.ubercomp.com/posts/2014-01-16_facebook_remote_code_execution

Sa spunem ca ai o partitie de linux pe care o folosesti din an in paste si nu iti mai stii parola la user. Recuperatu parolei este extrem de simpla daca folosesti grub. Cand iti apare grub-ul la boot te pozitionezi pe intrarea cu linux si apesi 'e'. Iti va aparea un editor de text minimal in care poti modifica toti parametrii de boot. Tot ce trebuie sa faceti este sa editati linia selectata. De exemplu linia de mai sus kernel /boot/vmlinuz-2-6-15-1-686 root=/dev/sda1 ro trebuie modificata in kernel /boot/vmlinuz-2-6-15-1-686 root=/dev/sda1 rw init=/bin/bash Sau daca linia ar arata asa linux /boot/vmlinuz-3.6.0-2-486 root=UUID ro ar trebui modificata asa linux /boot/vmlinuz-3.6.0-2-486 root=UUID rw quiet init=/bin/bash Ce fac modificarile? Montezi disk-ul readwrite (era montat ro - readonly). Si fortezi ca primul proces deschis de sistem sa fie bash (nu init) - evident acesta va fi deschis ca root. Apasa F10 sa bootezi dupa ce ai modificat. em-hax # ps -e |head -3 PID TTY TIME CMD 1 ? 00:00:03 bash 2 ? 00:00:00 kthreadd 3 ? 00:00:01 ksoftirqd/0 Acum tot ce mai e de facut e de schimbat parola la root. em-hax # passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Cum va puteti proteja de acest atac? Parola pe grub. $ cat /etc/grub.conf default=0 timeout=15 password paxeratat