FA admin account compromised (yet again)

[Pi]

Code: [Select]

//// Used to verify that the value is what it is supposed to be...
 //   IE: if i need the numeric ID of a board, it needs to verify that the value is an integer, not a string.
 //   This way, we can make sure that SQL isn't injected.
 //
 function check($value, $constant)
 {
    if($constant == 1)
        if(is_numeric($value) == TRUE)
            return $value;
        else
            return FALSE;

    if($constant == 3)
        if(is_float($value) == TRUE)
            return $value;
        else
            return FALSE;

    if($constant == 4)
        if(is_array($value) == TRUE)
            return $value;
        else
            return FALSE;

    //  These, strip out anything that MUST be stripped
    //
    if($constant == 2)
        return addslashes(stripslashes(stripslashes($value)));

    if($constant == 5)
        return makeproper($keyword);
 }
In which Yak can count! 1, 3, 4, 2, 5! What in the FUCK?

Code: [Select]

        return addslashes(stripslashes(stripslashes($value)));

I, uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

[Conan]

furaffinity.net/system now returns a 404.

They just hid it better now.

[UncreativeUsername]

furaffinity.net/system now returns a 404.

They just hid it better now.

So, FA wasn't aware their code was publically viewable, and someone told them within the last 24 hours? Could someone still use the password and name thing Pi mentioned and wreak havoc with FA no matter what, or could they have already changed it and averted another disaster?

[Pi]

So, FA wasn't aware their code was publically viewable, and someone told them within the last 24 hours? Could someone still use the password and name thing Pi mentioned and wreak havoc with FA no matter what, or could they have already changed it and averted another disaster?

Putting that kind of thing in the webserver's view is staggeringly wrong in so many ways that I'm not really sure how to explain it. Amazingly, though, there's no obvious way to dump the database — that's on the one server whose MySQL port wasn't exposed to the public. I'm sure some digging around would have found some kind of PHPMyAdmin installation, from where the DB could be dumped.

If they were smart, they will have changed it.

If they were smart, they would have put up more extensive firewalling (they haven't. i can still. reach. the. sunrpc. portmapper. on. their. big. box. it has been at least a week.)

If they're smart, they would have done so many things differently.

Long story short: They have no idea what the fuck they're doing, but they keep trying to spin it like the problem is on our end for complaining about it.

[Jim Demintia]

So (again, not really having a whole lot of knowledge here), what is the correct way to do this, then? Not defending their stupidity, but I notice a lot of the PHP apps I have used have a subdirectory in their distribution usually called conf/ from which a file is included that includes stuff like the db password. Thing is though, those files are usually prefaced with a call to exit() or if a variable isn't defined, die("access denied") or something. That said, the file is still technically in the web server's view, and I see no way to fix that without modifying the app itself.

Really then, it seems to me their idiocy is not having some kind of guard like that on critiical configuration files, just allowing them to be dumped like that.

And re: phpMyAdmin, I get bots on my DSL-line webserver looking for that (it isn't there, I don't use it). I would think that if there was a phpMyAdmin install on a hosted domain like FA, hackers would have found it by now, and not necessarily furries either.

[Eevee]

So (again, not really having a whole lot of knowledge here), what is the correct way to do this, then?

Run your application as an application, not as a hodgepodge of files that paste themselves into each other and need hacks to pretend they're not supposed to be directly callable.

Not defending their stupidity, but I notice a lot of the PHP apps I have used have a subdirectory in their distribution usually called conf/ from which a file is included that includes stuff like the db password. Thing is though, those files are usually prefaced with a call to exit() or if a variable isn't defined, die("access denied") or something. That said, the file is still technically in the web server's view, and I see no way to fix that without modifying the app itself.

Yes see this is all pretty retarded.

But it's extra-retarded in FA's case because these files had a different extension that made them non-executable, so nginx cheerfully served them raw.

[Pi]

So (again, not really having a whole lot of knowledge here), what is the correct way to do this, then? Not defending their stupidity, but I notice a lot of the PHP apps I have used have a subdirectory in their distribution usually called conf/ from which a file is included that includes stuff like the db password. Thing is though, those files are usually prefaced with a call to exit() or if a variable isn't defined, die("access denied") or something. That said, the file is still technically in the web server's view, and I see no way to fix that without modifying the app itself.

A well-written app will have a configuration file outside of the web root. The reason PHP apps do that is because PHP developers are generally stupidPHP apps are frequently deployed on shared hosting where your only directory may be the web root. In this case, their configuration files have a .php extension so the server will parse them, instead of returning them as text, or a .htaccess denying access to everything under that directory. FA apparently cargo-culted this kind of structure without considering the implications or checking to ensure that their kludge properly locked down their includes. Typical FA, really. And of course Dragoneer has to flat-out lie about things:

Sean, your site just leaked the production database credentials. You need to stop the PR spin and focus on the very real issues you are having, right now. I mean seriously look at them, not sit there and say "good points, I'll think about 'em" like you usually do.

And it helps absolutely nobody that the first thing you do is download it, re-upload it them wave around and go "LOOK WHAT I'VE GOT! Everybody download it and attack the site."

Really then, it seems to me their idiocy is not having some kind of guard like that on critiical configuration files, just allowing them to be dumped like that.

They have enough control over their application that this just shouldn't be a problem, since they're not on shared hosting and can require() files that don't live in the web root. They also have enough control over their network that I shouldn't be able to reach somewhat-sensitive UNIX services. C'ést la Vie, I guess.

[loki]

Jouva pointed this out to me:

Code: [Select]

$first = crypt($string, '$2a$07$'.sha1('d67c5cbf5b01c9f91932e3b8def5e5f8').'$');
Note this MD5 sum above: d67c5cbf5b01c9f91932e3b8def5e5f8

From http://www.adamsinfo.com/creating-an-md5-on-linux-with-md5sum/

echo -n “teststring”|md5sum

Results in:
d67c5cbf5b01c9f91932e3b8def5e5f8

He literally copy-pasted an example into the code and never bothered to change it.