reginaldo

Google, Facebook, and now over 70 companies do grant tacit permission for anyone to test their systems, and will pay the researchers for a disclosure, as long as they follow the program rules, which are usually quite reasonable. I'm serious when I say that few people are more thankful than myself for the existence of security bug bounties.

However, one thing has always crossed my mind: since the legal definition of authorization is still very fuzzy, what stops a third party from going after a researcher, even though the company who owns the server which was technically hacked has no interest in filing any complaint against the researcher?

To clarify my question, the recent Brazilian law regarding computer hacking establishes that only the owner of the hacked computer can file a complaint against the attacker, and legal proceedings can commence only after such a complaint has been filed. Does it work the same way in the U.S.? My understanding of american law is very weak, but I know that, for some crimes, the victim does not have a say, i.e. the state will prosecute regardless of the victim's will.

In 2011 I wrote an emulator for the LatticeMico32 processor [1]. After it was written, I decided to play the chaos monkey game and change some instructions, like reversing "less than" and "greater than", just for kicks. So the code I was actually running would be the equivalent of taking a program and replacing all > with < (and vice-versa). Much to my surprise, some emulated code still worked. It mostly did the wrong thing, but the fact that the code worked, printing stuff in the screen and all, still baffles me.

[1] http://www.ubercomp.com/jslm32/src/

Your comment did it. I've been avoiding it, since I know I won't stop until I either finish all the levels or give up after spending too many hours, but I finally decided to give it a try. And it is amazing. As an emulator author myself ( http://www.ubercomp.com/jslm32/src/ ), I'm in awe of the care that was put into the CTF environment. Very nice.

To the people who are wondering if they'll be able to finish the CTF, here are my two cents: go ahead and try for a few hours. I'm sure you won't regret it. I haven't done assembly since the beginning of 2012, and I was able to do a couple of levels in less than an hour, and before I started I new absolutely nothing about MSP430 assembly. The tutorial/manual are so good that I believe even someone who doesn't know assembly at all might be able to finish at least some levels.

The 10 years before those 2 days helped a lot too...

You're actually pretty close.

Fixing XXEs in Java is not a trivial thing to do. The best reference I know comes from Apache shindig [1], and you do have to make all those BUILDER_FACTORY.setAttribute calls, otherwise you block general external entities but allow parameter entities, which still leaves you vulnerable.

[1] http://svn.apache.org/repos/asf/shindig/trunk/java/common/sr...

I quoted that as a joke. I'm too familiar with bug bounties to ever expect one million dollars as reward for a bug. Let's hope people don't take it seriously. Lesson learned: since I'm not a native speaker, I shouldn't joke unless the joke is obvious.

Well, I originally found the OpenID bug in 2012, but hadn't noticed Facebook was vulnerable until very recently. After I found their OpenID endpoint, the hardest part was getting them to make me a Yadis discover request. Then I had to squash a little bug in the exploit. Most of the time was spent re-reading the OpenID spec. I'd say total amount of work (including the time it took me to write the post) was about 2 days.

As I said in the post, I already had a strong suspicion that, once I could read files, escalating to RCE would be easy. But I decided not to do it without permission and they fixed the bug very quickly. As much as I'd loved to actually see the output of an ls or something like that, I think I made the right call.

I don't know if you read it, but I sent you an email about this same bug (when I originally found it in Drupal) in 2012. Didn't know FB was vulnerable back then. By the way, I learned a lot from you here on HN. So let me take this opportunity and say thank you very much.

Well, it's already disclosed, but I really wanted to know how much people would think this kind of bug is worth.

Hi HN, I'm the one who found the bug. My writeup is at http://www.ubercomp.com/posts/2014-01-16_facebook_remote_cod.... I'd be glad to answer any questions. I won't disclose the amount for now because I want to know what people think this would be worth, but eventually it will be disclosed. If you run an OpenID-enabled server now it's a great time to make sure your implementation is patched.

Hi. I'm the one who found the bug. Facebook's side of this story is at https://www.facebook.com/BugBounty

The last stripe CTF literally changed my life. I've always been interested in security but didn't have the confidence and honestly thought I didn't have it takes to be successful in the field. I decided to try the CTF anyway just for fun and was able to finish everything much to my surprise. I had read about SHA-1 padding when it affected Flickr so I knew just what to do on the level that involved SHA-1 padding, which I thought was the hardest.

When I came to HN and saw a lot of people I admire talking about how hard it was, especially daeken [1], I remember thinking something along the lines of "well, I thought it was hard but not that hard", and decided to try to find a few security bugs in open source software... Best thing I ever did... In just a few weeks I found some nice bugs on both Drupal and Wordpress, got the first CVE credited to myself, and then I started to have fun (and some profit) with the various bug bounty programs around the web, most notably those run by Google (I'm currently 0x05 overall) [2] and Facebook (7th) [3].

After a year doing security work on the side I was able to quit my day job last august and now I make my living basically as a security consultant and also as a "bounty hunter". I also got multiple job offers from US companies (I currently live in Brazil).

And all of this happened only because the stripe CTF gave me the confidence to actually follow my dreams. Oh, and I still don't know if I have what it takes to be really successful in the field, but frankly security bugs are everywhere so I go ahead and keep on finding them. I'm learning a lot every single day and the mean time between bugs is getting lower and lower, which is great. So thank you Stripe. Thank you very much.

Shameless plug: BTW, I'm in the committee for the W2SP conference, so if anyone has some interesting discovery to share, please submit a paper.

[1] https://news.ycombinator.com/item?id=4424299 [2] https://www.google.com/about/appsecurity/hall-of-fame [3] https://www.facebook.com/whitehat/thanks [4] http://www.w2spconf.com/2014/

Most Google services accept and honor a "hl" URL parameter. So it would be http://www.google.com/about/company/history/?hl=en for English, and hl=nl for Dutch (not that you want it). No cookie cleaning is needed :)

Not just Xerox, btw... My HP printer/scanner does the same. After reading that post I started paying attention and eventually saw the effect a few times. I just wonder how many copies with the wrong numbers I've produced so far...

Here are some references to get you started:

http://www.volokh.com/2012/01/02/the-original-and-traditiona...

http://en.wikipedia.org/wiki/Citizens_United_v._Federal_Elec... (Relevant part: The majority opinion viewed "freedom of the press" as an activity, applicable to all citizens or groups of citizens seeking to publish views).

However, before you even delve into the references, note that the First Amendment reads:

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.

IMHO, the expression freedom of speech, or of the press conveys the idea of freedom of the spoken word and freedom of the written word. Of course, I am not a lawyer, not an american, and also not a native english speaker, so my impressions on language have to be taken with a grain of salt.

Wow... My father is a civil lawyer and deals with inventories regularly, but I don't think he's ever gotten a case so contrived. And I fully agree that having to prove the debt exceeds the assets is a major annoyance. Anything that puts the brazilian justice system in your back (especially in this case where the burden of proof is inverted), is a nightmare.

This analysis is wrong. One inherits the debts, but only up to the value of the assets inherited. See Art. 1.792

Art. 1.792. O herdeiro não responde por encargos superiores às forças da herança; incumbe-lhe, porém, a prova do excesso, salvo se houver inventário que a escuse, demostrando o valor dos bens herdados.

Free translation:

Section 1792. The heir is not liable for charges greater than the forces of inheritance: it must, however, provide evidence of excess, unless there is inventory to excuse himself, demonstrating the value of inherited assets.

>He basically did what Weeve did, except Weeve is in confinement now.

Hopefully not for long... https://news.ycombinator.com/item?id=6093468

Don't get me wrong, I don't agree with what he did, but the whole case is baffling to me.

What about when someone uses their old email address as the password recovery email for the new email address? I agree with Silhouette in that I hope they follow through with this... It will surely be fun to watch, and also people will become a little bit more security conscious.

I thought it was quite good, comparing tho most company statements I see. They even used the word apologize. Most companies do not use such wording as it might imply admission of guilt. That's why you see regret instead of apologize in a lot of company issued statements...

I believe the issue was related to the fact that the user running Jenkins was a full passwordless sudo user.

Maybe the attacker used the groovy console too...

I don't know if you're doing this, but I think it's a bad idea to leave Jenkins publicly accessible. Indeed, IMHO, it's a bad idea to leave stuff that should not be accessible by the general public publicly accessible. Especially things that have access to your code.

Do ask your team to review passwords and user rights, but also put this service and others like it behind a VPN. Then both the VPN server and Jenkins will have to have holes simultaneously before you get hacked.

It would be nice if they did so, but I don't think companies should be obligated to pay for bug reports from researchers that have no association whatsoever with them. Those that pay seem to get more reports, both in numbers and in quality, at least that's what Google says. Also, I think that a consumer should have the right to speak up when personal data is at risk, but that's a whole other story.

In this case, I'm more worried about the "lots to lose" part than about the "nothing to win" one. For some reason I'm even fine with doing charity work for the benefit of billion-dollar corporations from time to time [1]. But not if there's the risk of them coming after me in the future...

[1] http://technet.microsoft.com/en-us/security/cc308589.aspx

I'm not an american, but I'm a spare-time security researcher, hoping to make a career out of this in the future. The last few cases reported here on HN give me the impression that if you stumble upon a vulnerability (which, by the looks of it, seems similar to the one involved in the AT&T case), it's best to keep it to yourself. You have nothing to win by reporting it, and possibly a lot to lose if you do.

Oh no. I'm not saying it would be easier without exceptions. I'm just saying that the current status of our programming tools makes writing safe code very hard, and exceptions are one more thing you have to think about. I use them a lot...

The authors of the paper propose their "worlds" API as a way to make writing safe code easier. They're still using exceptions, but they would require no cleanup...

The code becomes:

  try {
      in thisWorld.sprout() {
          for (var idx = 0; idx < xs.length; idx++)
            xs[idx].update();
          
          thisWorld.commit();
      }
  } catch (e) {
      // no clean-up required!
  }

So it's commit for data structures for data structures. If an exception is thrown and the commit line is not executed, no changes will be visible.

Writing exception safe code is hard

No it’s not. Be sure to clean up anything that could need cleaning up in a finally block.

This is like saying... be sure to never copy more bytes than the buffer capacity. Easier said than done.

Writing exception safe code is very hard. Do not take my world for it. Read Alessandro Warth's paper (with Alan Kay as a co-author) [1]. Do not skip section 3...

Let me quote section 3.1:

In languages that support exception-handling mechanisms (e.g., the try/catch statement), a piece of code is said to be exception-safe if it guarantees not to leave the program in an inconsistent state when an exception is thrown. Writing exception-safe code is a tall order, as we illustrate with the following example:

  try {
  for (var idx = 0; idx < xs.length; idx++)
      xs[idx].update();
  } catch (e) {
      // ...
  }

Our intent is to update every element of xs, an array. The problem is that if one of the calls to update throws an exception, some (but not all) of xs’ elements will have been updated. So in the catch block, the program should restore xs to its previous consistent state, in which none of its elements was updated. One way to do this might be to make a copy of every element of the array before entering the loop, and in the catch block, restore the successfully-updated elements to their previous state. In general, however, this is not sufficient since update may also have modified global variables and other objects on the heap. Writing truly exceptionsafe code is difficult and error-prone.

Now, I have seen a lot of code, and very very very few times I've seen someone restoring the state of a collection after an exception blows.

[1] http://www.vpri.org/pdf/tr2011001_final_worlds.pdf

Last June, when this first came up, I commented:

I was thinking about the implications of using this technique to analyze e.g. political speeches and try to catch people lying on the act. Your application (winning on card games) seems very interesting too

Now, with the Google glass getting closer to being a real thing in the market, the possibilities are endless (for the good and for the bad). Unfortunately, my mind is kind of twisted and I think about the bad first. Must be a side effect of all the security issues I'm researching.

For instance:

# Google glass + Eulerian magnification + facial expression recognition = Instant "Lie to Me"-like[1] microexpressions expert.

# Google glass + Eulerian magnification + TSA agent: "picking" suspects by the way their pulse react as they get closer to the agent using the "apparatus". Of course, the real criminals would just take some kind of drug to avoid being detected...

http://en.wikipedia.org/wiki/Lie_to_Me

Some blogs I like (most are not updated very frequently, though):

Billy Rios (discovered GIFAR) http://xs-sniper.com/blog/

Michal Zalewski (one of the top security researchers in the world, wrote "The Tangled Web", a must-read) http://lcamtuf.blogspot.com

Neal Poole: https://nealpoole.com/blog/

Nir Goldshlager: http://www.nirgoldshlager.com/

Michael Brooks: https://sitewatch.me/en/Blog

Nils Jünemann: http://www.nilsjuenemann.de/

Stefano di Paola (Minded Security): http://blog.mindedsecurity.com/

Root Labs: http://rdist.root.org/

The impact varies with the platform and parser being used, and with the extensions installed. I don't know the specifics of ExpatParser (the one used by Django), but in general, the "careless" parsing of unsanitized user-supplied XML might lead to:

- DoS

- Disclosing of sensitive files (in general, the XML has to "validate". In PHP, it's always possible to read any file accessible by the process parsing the XML).

- Making arbitrary network connections (with this an attacker can portscan a network, attack vulnerable services that would be protected by firewall, and/or use the vulnerable server as a restricted kind of proxy).

- Probing LDAP directories.

- Remote code execution.

See, for instance:

http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_...

http://defcon.org.ua/data/2/2_Vorontsov_XXE.pdf

http://www.insinuator.net/2013/01/rails-yaml/

Edit: As a clarification, I'm not implying that any of the above (apart from the DoS issue) is applicable to Django. I'm just saying what can possibly happen (and often happens for PHP apps).