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

21–30 of 114 posts

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

#21

Post by kibwen »

nathanappere wrote: post #4

Seems like a very civilized way to deface a website, you have to love how GitHub changed the game.

evilmalware 0.6 (beta)

Copyright 2000, 2001, 2003, 2005 E\/17 |-|4>This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY, COMPLETE DESTRUCTION OF IMPORTANT DATA or FITNESS FOR A PARTICULAR PURPOSE (eg. sending thousands of Viagra spams to people accross the world).

Basic Installation

Before attempting to compile this virus make sure you have the correct version of glibc installed, and that your firewall rules are set to ‘allow everything’.

1. Put the attachment into the appropriate directory eg. /usr/src.

2. Type ‘tar xvzf evilmalware.tar.gz’ to extract the source files for this virus.

3. ‘cd’ to the directory containing the virus' source code and type ‘./configure’ to configure the virus for your system. If you're using ‘csh’ on an old version of System V, you might need to type ‘sh ./configure’ instead to prevent ‘csh’ from trying to execute ‘configure’ itself.

4. Type ‘make’ to compile the package. You may need to be logged in as root to do this.

5. Optionally, type ‘make check_payable’ to run any self-tests that come with the virus, and send a large donation to an unnumbered Swiss bank account.

6. Type ‘make install’ to install the virus and any spyware, trojans pornography, penis enlargement adverts and DDoS attacks that come with it.

7. You may now configure your preferred malware behaviour in /etc/evilmalware.conf.

SEE ALSO evilmalware(1), evilmalware.conf(5), please_delete_all_my_files(1)

http://www.gnu.org/fun/jokes/evilmalware.html

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

#22

Post by TazeTSchnitzel »

kibwen wrote: post #21
nathanappere wrote: post #4

Seems like a very civilized way to deface a website, you have to love how GitHub changed the game.

evilmalware 0.6 (beta) Copyright 2000, 2001, 2003, 2005 E\/17 |-|4> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY, COMPLETE DESTRUCTION OF IMPORTANT DATA or FITNESS FOR A PARTICULAR PURPOSE (eg. sending thousands of Viagra spams to people accross the world). Basic Installation Before attempting to compile this virus make sure you have the correct vers…

Importantly, this software may not function properly unless it is run with root privileges. On systems that disable the root user, look for the sudo command, or similar.

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

#23

Post by noamsml »

laurencei wrote: post #7

Better title would have been: Protip: if your trying to hack/deface a website, dont submit a pull request WITH YOUR EMAIL AND PASSWORD! https://github.com/CoderDojo/CoderDojo-Kata/pull/2

Yep, password is common enough to unhash pretty easily. People need to learn to salt their hashes for fuck's sake.

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

#24

Post by geekgirlweb »

Trying to hack a non-profit site? An non-affiliated NFP? Someone did not love this person as a child.

Please report? https://github.com/ahmedalex

P.S. If you're not a jerk and would love to help with the new CoderDojo.com site, let me know rebecca (at) coderdojo.com

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

#26

Post by Xylakant »

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 changes may be actively malicious and not just buggy.

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

#27

Post by ngokevin »

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.

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

#28

Post by kordless »

Achshar wrote: post #15

What is happening here? I am not very accustomed to open source yet. Edit: un-checking "show inline notes" helps. Edit 2: So if I understand correctly, OP tried to hack into a website... by submitting code to github. I was confused at first because that would have been (very) wrong way to "hack", but as it turns out, that is indeed true. And rest is about the code he/she used. It seems to be auto generated in some wy…

And the devs of the project are having a field day pointing out all the coding errors. This comment is a gem:

> can you please add semicolons to the end of these lines + @douglascrockford

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

#30

Post by alexkus »

noamsml wrote: post #23
laurencei wrote: post #7

Better title would have been: Protip: if your trying to hack/deface a website, dont submit a pull request WITH YOUR EMAIL AND PASSWORD! https://github.com/CoderDojo/CoderDojo-Kata/pull/2

Yep, password is common enough to unhash pretty easily. People need to learn to salt their hashes for fuck's sake.

In this case, salting would give almost no benefit given the poor password choice.

The pull request included the code that does the hashing:-

    if( empty( $auth_pass ) || ( isset( $_POST['pass'] ) && ( md5($_POST['pass']) == $auth_pass ) ) )
      $_SESSION[md5($_SERVER['HTTP_HOST'])] = true;
    else
      printLogin();
So any salt [was hash] used would have to be present in the code too.

Given that such a simple password (8 digits) could be brute forced in seconds on an average PC, even with a salt, it doesn't really matter whether it was salted or not.

A password of "p*l12nJ9£l ~98as2389bvkqsopfq£3oef2[olpe]wog!wei^og(8ni" would take an unrealistic amount of time to brute force, even if unsalted, and it's beyond the scope of any precomputed rainbow tables for similar reasons.

Anyway, it's only a concern if he uses the same password elsewhere.

Post reply on HN