/operate/ - Endchan Operations

Let us know what's up

Posting mode: Reply

Name
Email
Subject
Comment
Password
Drawing x size canvas
File(s)

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Manage Board | Moderate Thread

Return | Catalog | Bottom

Expand All Images


odilitime Board owner 09/08/2016 (Thu) 05:12:04 [Preview] No. 4983
I had a development server breached that I had an old development copy of the Endchan database (without media).

All users are advised to change their passwords ASAP.

Development server was breached used an redis/ssh exploit. Redis was installed and usually ran as a user but recently doing some development work, I accidentally started it up as root to look something up and left it running. Redis then can write to your ssh keys and insert unwanted keys and allow root access. All files in /root and /home were removed and a note was left:

>Hi, please view here: http://pastebin.com/raw/vadfLyDS for information on how to obtain your files!

Luckily I have bandwidth logs on that box and I can see there was nothing transferred out of the box. So my guess is they just deleted the files. The nature in which they left the machine leads me to believe this was an automated attack (plenty of other meaningful data directories were left alone).

The copy of Endchan's data is left untouched on this development server. However the dump that was used to transfer the copy was still likely in the /root directory that was deleted. I will get the date of the data copy as soon as I can do some data recovery on that machine, I estimated the copy to be an early 2016 Q2 dump. This server is now offline.

At Endchan, we want to be as transparent as we possibly can and even though we do not believe anything was leaked, we cannot rule out nothing happen with 100%. And even if we could be certain that nothing was at risk, we still want to report anything of this nature to our users.

I fucked up, I'm sorry for any troubles this may and has caused any of you.

Please let us know any questions you may have.


odilitime Board owner 09/08/2016 (Thu) 08:07:48 [Preview] No. 4984 del
I got access to the database files. If you created your account before 2016-04-09 10am UTC please change your password.

If you signed up or have changed your password since april 9th 2016 then you can disregard this.


Anonymous 09/10/2016 (Sat) 02:35:16 [Preview] No. 4986 del
smh OdiliTime


odilitime ==Board owner== 09/10/2016 (Sat) 05:14:26 [Preview] No. 4987 del
btw im gay


Anonymous 09/11/2016 (Sun) 10:39:43 [Preview] No. 4989 del
ODILDOTIME SUCKS NIGGER COCKS


Anonymous 09/11/2016 (Sun) 14:02:31 [Preview] No. 4991 del
(221.42 KB 540x513 1473463625223.jpg)
>>4983
thanks for the excellent transparency! it really inspires confidence!


Anonymous 09/11/2016 (Sun) 14:07:20 [Preview] No. 4992 del
(246.46 KB 500x375 1470949056008.png)
>>4983
you made the mistake of not using ssl


Anonymous 09/11/2016 (Sun) 14:08:10 [Preview] No. 4993 del
>>4992
or at least hsts


Anonymous 09/11/2016 (Sun) 14:32:07 [Preview] No. 4997 del
(10.45 MB 1280x720 hacking_endchan.webm)
rare video footage of the endchan hack


Balrog Board volunteer 09/11/2016 (Sun) 14:59:35 [Preview] No. 4998 del
(3.60 MB 320x180 Dude Sex hacking.gif)
>>4992
>>4993
This wasn't our web server. This was OdiliTime's personal server that OdiliTime happened to have transferred a backup to while we were doing maintenance on the endchan server just in case something went wrong. SSL or a lack thereof wasn't involved.

In any case, we got lucky and I've made sure to rip OdiliTime a new asshole over this shit. I'm guessing that the attack was either a scam by a script kiddie or a greyhat trying to spook people into securing their shit. Like OdiliTime said, nothing was uploaded, so the odds strongly favor no DB leak occurring. The notification to change your passwords is more out of paranoia (e.g. some crazy NSA shit transmitting the data offsite without the transmission being logged by the external monitoring equipment; not likely) than anything else.

In other words, shit got fucked up, but odds are it'll be fine.
Edited last time by Balrogwashere on 09/11/2016 (Sun) 15:01:24.


Anonymous 09/18/2016 (Sun) 02:00:08 [Preview] No. 5011 del
>>4983
>since april 9th 2016

I'm a bit curious about how it took you 5 months to notice.


odilitime Board owner 09/18/2016 (Sun) 23:38:42 [Preview] No. 5016 del
>>5011
I made the back up in April. The server didn't get hacked in April.


Anonymous 09/23/2016 (Fri) 17:46:15 [Preview] No. 5020 del
namefags btfo


Anonymous 11/29/2016 (Tue) 09:52:50 [Preview] No. 5343 del
Why is/was your development/test server accessible online? Can't keep >>4986 over this mishap. Could you check the logs if a mod volunteer like >>>/pol/23993 was in the logs of potential account takeovers?
>>4998
>crazy NSA shit transmitting the data offsite without the transmission being logged by the external monitoring equipment; not likely) than anything else.
Highly possible with state actor attacks we've seen as of late.

Leaking PizzaGate really did a number, worldwide.
>>5016
You do still have a copy of that old DB, right?


odilitime Board owner 11/29/2016 (Tue) 11:16:02 [Preview] No. 5344 del
>>5343
>Why is/was your development/test server accessible online?
because we needed public testers.

>Could you check the logs if a mod volunteer like >>>/pol/23993 was in the logs of potential account takeovers
Not sure how to figure that out, let me talk with Lynx.

>You do still have a copy of that old DB, right?
No I don't.


Anonymous 11/29/2016 (Tue) 23:46:32 [Preview] No. 5380 del
>>5344
Then make a mock test site, not a duplicate, yesh.
>No I don't.
This is bad. M8, when you can, study up on Sysadmin. Rule 37 of "After an attack" is to keep an archive of the exploit. You want to retrospect on how malicious attacks are growing, so you proactively scope those vulnerabilities.


odilitime Board owner 12/06/2016 (Tue) 01:38:31 [Preview] No. 5428 del
>>5380
>make a mock test site
That's what this was. What's the point of the test if you aren't testing real data. Very few have a budget to generate similar but different data.
But you're right in the sense that we did need every users' account on the dev server. That could have and should been cleaned out more.

>keep an archive of the exploit
generally a good rule. I have a large archive of them, however the size of this development server was too large. I did a thorough analysis and deleted it. The vulnerability was easy to figure out and very popular, so there was plenty of documentation on it. In this specific case the storage costs outweighed the value.


Anonymous 12/07/2016 (Wed) 18:30:32 [Preview] No. 5430 del
>>5428
As long as you archive and properly mock the test server from hither on, you will form a basis to document changes dependent on the master branch. Usually it is cheaper to VPN the server in a locked virtual environment, so you see a full scope of the system. Vulnerabilities are getting scarier and efficient, thanks in part to manufacturers leaving vulnerabilities in the hardware/UEFI/BIOS/firmware. Right now, the biggest threat are GPUs with DMA and their undocumentation: enormous processing power that when clustered, can replicate innumerable vulnerabilities in one machine before the next cycle hits the CPU to address the bus.



Top | Return | Catalog | Post a reply