Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you’re trying to hack/deface a website, don’t submit a pull request

github.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#41

Post by piranha »

bratsche wrote: post #16
raimondious wrote: post #12

Earlier quoted context omitted.

Allow? They just released a feature that lets you drag and drop images into comments — it automatically uploads to s3 and inserts the URL in your comment. For some reason, they encourage it.

I assumed that was because of changes in Skitch. Everyone I know used to take screenshots with Skitch, upload them and Skitch would copy the URL into your clipboard and you could post into Github. But since Evernote bought them they closed things down and they're basically useless now, so I figured that was why Github was motivated to add this feature.

Re: Skitch, there is a nice app I switched to lately: http://monosnap.com/

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#42

Post by angersock »

ngokevin wrote: post #27
tucson wrote: post #25

can someone explain? (I am not familiar with github and the whole thing is cryptic to me)

It's equivalent to knocking on someone's door and asking them if you can graffiti their house wall, egg their car, and toilet paper their front yard tree. All while having the graffiti, egg, and toilet paper in your hands in front of their face.

The comments are even better, and so to extend this analogy:

After you ask them, they then criticize your choice of spraypaint ("Krylon? Really? Not using Rustoleum, even though this is clearly for outside application?"), testing that your egg is actually of proper dimension and size, and then sighing in annoyance upon finding out that your toilet paper isn't quilted.

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#43

Post by user24 »

Xylakant wrote: post #26

This attempt is blatant and obvious, but what about a more serious attempt where you first establish some credibility with a couple of "good" PR that fix major problems and then add a tiny little backdoor that loads code from somewhere else. Distribute the relevant code over a couple of commits and you might just slip it in. With Githubs ease of merging and automatted testing by Travis, it's easy to forget that chang…

Something similar to this was attempted with the Linux kernel once: https://freedom-to-tinker.com/blog/felten/linux-backdoor-att...

I say similar because it was not a trusted contributor going rogue but someone actually hacking the public CVS repo.

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#46

Post by RyanZAG »

For anybody too lazy to read through them all, here are some gems:

+

Are you sure, like, really really sure, you want JavaScript 1.2?

+var speed=1

please run jslint on your code before submitting a pull request

There are so many errors that JSLint gives up on this code at 39%.

+temp=document.body.scrollTop

You really shouldn't declare a variable without using var - can lead to all sorts of scoping problems.

Oh, good catch! You should submit a pull request to fix this

+

There's a couple of redundant span elements here, when you get time, you could optimise this

+  

It's great that you've made sure that non-breaking space is read right to left, your readers would have been screwed otherwise.

+ $bind_port_p="IyEvdXN...";

    It's going to be hard to comment on these Base64 encoded C and Perl programs in their current form.
    That daemon() function call is going to cause problems on a whole bunch of non-Linux architectures. Solaris doesn't have it for example.
    You should definitely consider supporting IPv6, you can't just assume IPv4 connectivity...
    You're also missing a return at the end of main().
+$auth_pass = "fe3f6d96a1ee06bc5415a5c05540c7a8";

1911990 is not a good password. Your birthday?

Let's hope you didn't use that for your email account, lovestory8976@yahoo.com

can you use a sha512 hash, instead? it's more secure.

+

Hmm the HTML isnt compliant. Please rebase from master, squash the previous commit and resubmit.

Thanks for your invaluable future contributions

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#48

Post by bdcravens »

mastofact wrote: post #11
judofyr wrote: post #6

God, I'm so tired of animated GIFs in GitHub comment threads. The code critique is far more amusing to me.

I'm more shocked that they even allow images to be embedded in comments.

Presumably folks would use it to post screenshots relevant to the code being discussed.

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#49

Post by EthanHeilman »

Xylakant wrote: post #39
EthanHeilman wrote: post #33

Earlier quoted context omitted.

Why not just find an exploit in the code. Spending months building trust while creating a giant trail of information that can be used to find you and then really pissing off the open-source community seems like a bad plan for someone that is attempting to quietly gain root. Might work if one project is attempting to discredit another project (think closed source vendor trying to steal clients who use opensourced gith…

Because it works even if you can't find a proper codepath to exploit. It might gain you anything you want: A quiet path to leak admin account info to a server of your choice. An attack vector into a system trusted by more than one person. You don't need to provide much information to get a github account, so the risk is not very much elevated.

>You don't need to provide much information to get a github account, so the risk is not very much elevated.

1. Unless you are extremely lucky, you have to gain someones trust by posting fixes that do not contain backdoors. This leaves a trail in terms of: coding style, word usage, editor settings (tabs vs spaces), and ip records/timestamps in github. It's not much but it is additional unnecessary exposure.

2. Since the code is publicly available on github it stands a much better chance of discovered later. If you own a server, do you business and change the logs, you have a very very low chance of someone discovering the intrusion after the fact.

3. If someone discovers the backdoor they can setup a honey pot. They might even allow the change to be merged and then wait for you to connect, although this is unlikely. An attacker is potentially forfeiting the element of surprise.

4. Gaining access to a remote server is trivially easy (just use a publicly available exploit before it is patched on your target server), especially if it is a webapp, especially if you have access to the code.

I'm not saying there isn't someone out there that thinks this is great attack method. I'm just saying that an attacker that uses this method is either doing it because they think it is funny or a stupid attacker (there is not shortage of stupid attackers).

Re: If you’re trying to hack/deface a website, don’t submit a pull request

#50

Post by mseebach »

zheng wrote: post #18
mumrah wrote: post #14

Pull request might not be a terrible attack vector. I'm sure there are plenty of people out there who don't look carefully and just merge them in.

In fact, I might go so far as to say that this was never intended to be merged. I'll assume whoever did this wants their message heard, and while it will never show up on CoderDojo, the hodgepodge of coding styles ensures that the "pull request" will go viral, thus possibly reaching a far greater number of people than it would have otherwise. /tinfoil

What message? I read through the thing and didn't see any message. There's some encoded arabic, but even if I could read arabic, I couldn't read it encoded.
Post reply on HN