January 8, 2011: FA Technical Exposé

[Jim Demintia]

mass gallery deletion

You know, it'd be horrible if those SunRPC ports were exposed because the gallery data is mounted over NFS, and they were running some insecure version of Linux-NFS or whatever, that didn't entirely authenticate IP addresses....

or worse yet, they've got something suitably dumb, suitably them, in /etc/exports.

[Pi]

or worse yet, they've got something suitably dumb, suitably them, in /etc/exports.

Near as I can tell (showmount -e, showmount -a), their /etc/exports had this in it:

Code: [Select]

That's right, their NFS was running, lights on with nobody home.

Then they stopped NFS but left portmap open, and now portmap is no longer exposed (but probably still running).

si;gh

[Eaglebird]

Also, when did "Commission Information" ( http://www.furaffinity.net/user/info/eaglebird/ ) go to a 404 instead of "Multiple XSS vulnerabilities were detected and confirmed! (we're so awesome for investigating things!)"?

[Conan]

Also, when did "Commission Information" ( http://www.furaffinity.net/user/info/eaglebird/ ) go to a 404 instead of "Multiple XSS vulnerabilities were detected and confirmed! (we're so awesome for investigating things!)"?

Since that page isn't mentioned at all in the new UI, I'm under the belief they've given up on it.

[Jim Demintia]

How amazingly fucked up does that thing have to be that after all this time it's still inoperable? I don't ever remember it being there.

Or maybe Dragoneer is just an undisciplined lazy ass, and has never bothered to care about it.

[Conan]

How amazingly fucked up does that thing have to be that after all this time it's still inoperable? I don't ever remember it being there.

Or maybe Dragoneer is just an undisciplined lazy ass, and has never bothered to care about it.

The page was never a top priority of theirs, it's been offline for nearly two years. They pretty much said "it'll be fixed eventually, we're working on it".

[Eaglebird]

The page was never a top priority of theirs, it's been offline for nearly two years. They pretty much said "it'll be fixed eventually, we're working on it".

They probably kept trying to fix it but other XSS vulnerabilities kept destroying their work. 

[Pi]

I didn't look into 70.33.186.216/askcow until recently, but it turns out it has its own domain, askcow.org. It used to run DNS but doesn't seem to be responding to it right now, but what's still running is pretty amusing.

Code: [Select]

PORT     STATE SERVICE VERSION
80/tcp   open  http    nginx 0.8.52
3306/tcp open  mysql   MySQL 5.1.52-rel12.3-log
8080/tcp open  http    Apache httpd 2.2.3 ((CentOS))

They're listening on MySQL, even though I've told them, repeatedly, that this is a stupid thing to do. Summercat supposedly relayed this information to Yak, but considering that the former has absolutely no idea what he's talking about, I can't imagine my meaning crossed both the idiot barrier and yak's language barrier intact.

There's an Nginx web server on port 80 and an Apache on port 8080, the latter exposed to the world for no reason I can see. Seeing as both the Apache and the Nginx servers seem to be returning the same content, I'm going to venture (here i go, making almost baseless assumptions) that this configuration is cargo-cult administration - there are few reasons to be doing it this way, and I can't think of any of them that would be relevant for a static site, as this appears to be.

Askcow itself appears to be a "project management" piece of vaporware. The domain's whois record states:
Tech Name:Nicolae Odobescu
Tech Street1:Kiev str. 8
Tech Street2:ap. 8
Tech City:Chisinau
Tech State/Province:Chisinau
Tech Postal Code:MD-2068
Tech Country:MD
Tech Phone:+373.79480290
Tech Email:nick.boo@gmail.com

And there's that Moldova stuff again. This is totally inconclusive though; I host semi-abandoned sites for my buddies all the time. (granted, I don't give them whole IP addresses or leave their database port and backend webserver hanging out in public)

And welp.

[Freehaven]

At this point, I could almost stand to think that I could do a better job of running this shit, and I don't know jack about web servers and stuff like that.

[loki]

Code: [Select]

PORT     STATE SERVICE VERSION
80/tcp   open  http    nginx 0.8.52
3306/tcp open  mysql   MySQL 5.1.52-rel12.3-log
8080/tcp open  http    Apache httpd 2.2.3 ((CentOS))


Brilliant! Let's expose the MySQL version to the world as well so we all know what exploits it's vunerable to. Also, I don't think that site is that old since it's running a fairly recent release of Percona Server: Percona Server 5.1.52-12.3 (of course this is guessing) - even then, that version of MySQL came out in October so it's been a fairly recent addition.

I think it's entirely plausible that Yak saw us notice another his sketchy Moldovan websites and prevented the site from returning.

[Pi]

Code: [Select]

<Pi> yak, why was the backup server redirecting to new.maximum.md
<Pi> i am still wondering this
<yak[work]> easy. the server was idle, i was demoing a website there that you didn't quite figure out how to get working
<Pi> also why was that so hard to answer
<Pi> "i was using furaffinity's idle boxes for personal shit"
<yak[work]> i didn't feel the need to. no offence but it's none of your business.
<Pi> well, you see, from an infosec standpoint, when unused boxes are redirecting to eastern european domains, that usually indicates something has been compromised
<Pi> in this case, your sense of professional ethics :P
<yak[work]> I agree. And you've brought that up to attention. But you never asked me directly, which I could have easily replied ages ago if you did.

I'm pretty sure I've asked him, repeatedly and directly, about why in fuck this was happening, but I certainly could be wrong.