To all gogs users
We are currently suffering a DDOS attack which has effectively killed the server, this means performance will be degraded and all repositories are corrupted.
Protech IT solutions are currently working on a solution, please do not view the site or the source as we are in the process of a forced rewind.
Thank you
@random, CEO of ProTech IT solutions and lead admin.
@Techy, Lead Developer and community manager/ Trust and Safety Team Specialist
How did you get DDOSed?
Everytime I view the project the editor crashes too. So I’m trying to remix it right now.
People have made multiple accounts, running malicious code and crashed the database.
We are trying to fix it now
What is “gogs” or “gog”?
gogs is a GitHub clone written in Go.
https://support.glitch.com/t/built-a-github-clone-with-gogs-join-for-free-today/19163/2
Yep, we got it from a dev.to article
We remixed it and we provide it as a free service, but in order to keep things safe and prevent further attacks we have set some ground rules for both users and admins.
Also, your account will be deleted if:
Thank you
@random, CEO of ProTech IT solutions/head admin
@Techy, Lead Developer and community manager/ Trust and Safety Team Specialist
If people are able to run malicious code on the server side then you have some major security flaws which should be addressed immediately.
Also, if your database was accessed, are user’s passwords hashed? If so, what algorithms. Also, are they salted? If neither hashed or salted that wouldn’t look very good for you (as a business). (Also if your not salting hashed passwords I recommend you do so).
@charliea21 We are currently investigating the problem. But for some reason the site give’s all new users admin perms. We’re trying to fix that issue right now.
Hm, it could be a malicious code execution then. In that case, I’d take your project offline, backup the database to a secure location (perhaps on your local disk) and do a thorough investigation. Keep in mind though, it could all be down to a default or simple password. One of my personal servers was hit with a remote ransomware attack once - it was all down to using an extremely simple password (which I’ve now changed).
@charliea21 Thing is I’m puzzled how they were able to corrupt all of our Data with just creating new account. After I investigated I could not really find any evidence that users were “running malicious” code.
If the data was actually corrupted (file overwritten with binary nonsense) then someone’s managed to login remotely to your database (if it’s not a file based one, e.g MongoDB, MySQL, etc). On the other hand, if the database is file based (e.g SQLite) then it could be signs of code execution or there’s some random API endpoint letting anyone access project files.
In our case it’s a file based one. When users mass create a bunch of accounts our project just ends up crashing. We’re taking extra steps to ensure this doesn’t happen again.
Likely signs of remote code execution or the file just got corrupted due to a Glitch outage (has happened to me before).
I’ve noticed that a bunch of spam bot’s sign up for accounts shortly before every DDOS attack in the past 3 days.
Eh, likely unrelated. If you hit the disk limit Glitch won’t let you write to a file anymore. Thus, corrupting your data. Is your project scribing “nice” to the container limits?
Yeah, We’re well below the container limits.
@charliea21 Gogs is written in Go and uses no complicated technologies, this means that it stays below the container limits.
As for our databases, we are considering wether to move to a different and more secure database such as SQL. Please note that all databases and repositories are stored in private folders that are inaccessible through the editor.
As for the other issues you raised, the Site Security Team are working on ways to prevent future attacks. If you hold an account and feel that you are at risk then you reserve the right to delete it.
Please PM me or @Techy if you have any questions
We are about to implement features and wiping of the database. DO NOT ENTER THE SITE
Make the project private and change its name temporarily.
Doing that as soon as the Site Safety Team gives us the green light
We are on red alert and will be hashing passwords.
Everyone at ProTech Web Services (Runs Gogs) are working on improving security, but we can never always spot attacks due to possible time differences. We are relying on the community to spot glitches ( No joke intended) and report them.
Please go easy on us, we are working at breakneck speed to resolve problems.
Just wondering but was the passwords encrypted/hashed in the first place?
They were in an encrypted database which cannot be accessed by outsiders because the folder is secret
I get ddosed frequently and I use glitch for one of my premium websites, however i proxy all the discord requests to my hosts due to stupid 12 year olds not knowing how to make a bot ruining glitch and making it block my requests. I setup cloudflare and it works very nicely, i would recommend leaving the “under attack” mode on if your website is ddosed often
Glitch probably could withstand the attack but sadly due to the 429 after a project received too many requests i was forced to setup cloudflare
thank you very much for the advice @SpeedyCraftah, we appreciate your idea and will integrate as soon as we fix this
But do make sure to prioritise securing the database, make sure it has a very strong password (santa wumpus’s DB password is longer than 30 characters, includes special characters including both lower case and upper) and attempt to establish connections with the database with SSL if you haven’t already. We intentionally do not store explicit data in the database to avoid leaking of the database, all information leaked would pretty much be useless. With @charliea21 s advice, make sure your passwords are encrypted with salt. And ALWAYS MAKE SURE YOU TEST YOUR PERMISSION SYSTEM, i’ve never told this before but once i implemented a quick command to run any code on the server side, didnt test the permissions because i went “ah well i doubt i did anything fatally wrong” and then went to sleep, i woke up with many mentions. Luckily the other developers noticed the mistake quickly, immediately shut the bot down, changed root password, database password and changed the bot token. Due to this experience i have never made such a mistake again, could’ve gone so much worse
@SpeedyCraftah Yes, Thank you very much for your advise. We will be sure to implement this ASAP, because user security is our top priority.
As for this we have reset all of our users password as an additional security measure. We will be enforcing more secure passwords.
we have enabled SSL for our DB, we are working on salting and we will be thinking of disabling the first user admin feature
What xenforo does is it makes you make an account upon the setup page, which is outside of the main root page and blocked when the account was created, may be interesting setting something like this up
Or you can always automatically create an account for them with an auto generated strong password
maybe, we are thinking of a number of strategies.
we can enable a feature where only admins can create accounts for users
it’ll work out however
@charliea21 is actually gaining a lead, i am pretty sure gogs uses sqlite3 often, and something known as sqlite injection ( which a few of us can perform ) can override queries and what they are supposed to do, and just like that, the user can log in to an admin account with no password, it is extremely dangerous, and an admin account being hacked via sqlite injection is almost fatal to any website or service that is provided.
We never realised the threat, we will move to a new and secure database like mongoDB
SQL injection can be eliminated as a threat quickly, you just need sqlite to read all specific information queries as only values and keys, you can read more about it here https://www.calhoun.io/what-is-sql-injection-and-how-do-i-avoid-it-in-go/ just because a database is vulnerable by nature, doesnt mean it’s a bad and unsecure database. SW uses mysql which uses sql syntax, and we’ve never been attacked due to using the variable feature sql provides. Besides MongoDB has its own vulnerabilities, no database is ever perfect
By concatting a value into the query, sqlite doesn’t know at all what it is, you just can’t expect it to guess
I am noting down all your advice so we can integrate it into the code when the project is unsuspended
oh, one more little tip 
don’t let usernames on login contain = signs or semi-colins… doing a regex to check for these can often tell you if that person could be using sql injection
That’s one way to prevent SQL Injection, but the most efficient way is to take advantage of the placeholder feature SQL provides, that way users don’t need to do that. If the sql library you use doesn’t provide this, then you should do checks for special SQL query symbols (like quote marks)
i am going to check the database for anything we could protect and see if the passwords are hashed
we can modify usernames with cryptic usernames and disable/delete their accounts
Interestingly enough, when I visit the suspended site, I see the favicon still there even though I can no longer see the source.
i cannot access the project or remotely access the terminal, it has been suspended along with others like @J-Tech-Foundation’s coding language
yes, very sad, just as i was going to add language respective commands aswell
F
you could grab the language from our OS, i made a copy in there the other day
i did 
yay!
btw, i have put virtualenv and am trying to create a script that detects key presses
nodejs langauge respective is done 
private server… and it doesn’t work…
:\
great!
urm, where is it?
Browsers cache favicons for quicker loads
It’s back up! Lets go!!!
@RiversideRocks We’re currently making some security changes at the moment so users may have a hard time logging in! We expect this to be done in 1 hour.
YAY! XENT IS BACK UP!!!
thanks @glitch_support
Umm…I think this is the wrong thread?
Also every time a SQL command is executed you could record it to a file
LETS DO THIS!
i am happy to announce that everything in the database are already hashed and passwords cannot be extracted.