Hack for source games affecting tcadmin v1 and gamecp

[LFA]

There is mention in a hacking forum about hacking source games running under tcadmin v1 and gamecp. They specifically mention it is not possible in v2.

 

I don't know how this hack works. It could be a custom source mod or a remote exploit. I assume v2 is not affected because in v2 all game servers run as a guest by default. I recommend you configure your game servers to run as a guest using method 1 explained here: http://clients.tcadmin.com/knowledgebase.php?action=displayarticle&id=37 or this method: http://clientforums.tcadmin.com/showthread.php?t=6428

[anup_123]

I saw the post

This guy seems to be using the newly found windows rdp exploit as per his other threads

[Bubka3]

This post alerted me as well, however we are half-way on TCA v2, and our TCA v1 servers run using dimitri user per server method. I can say this post increased our migration to TCA v2 and I think we're almost done.

 

Oh yea, this works by customers not securing their server. Instead of uploading a spray, he can upload a virus, which will therefore exploit GameCP and TCA v1 by default because of the service running as Local System, at which point he gains control of the box.

 

The fix is easy:

sv_download 0

sv_upload 0

 

If you run SourceMod, installing this extension is a good idea as well.

http://forums.alliedmods.net/showthread.php?t=142249

 

And you should remind customers to never share the rcon password and rcon command.

Edited April 27, 2012 by Bubka3

[Ben-EdgeGameServers.com]

Yep! I alerted allot of people Just like I warned Bubka3. Watch out people I have been hacked while I was a GameCP User. Trust me Secure your things ASAP You don't want to be the next Victim.

[{-SMAKU-}_MotorMouth]

We had someone installing CS 1.6 on one of our boxes. It was only 1.6 no other game servers. After we deleted the CS 1.6 no other servers were installed.

[ECF]

This is due to uploading of a bad mod. Companies that allow uploading of mods should NOT do it.

 

Huge security risk!

[ViolentCrimes]

No offense or anything LFA but shouldn't this be an update you guys send out automatically? Why are we paying for updates if we have to do them manually ourselves? I know per say it is not an issue with tcadmin. But you can argue that tcadmin 1 should have used a different user from the start. What if we don't read the forums and have no clue about this, wouldn't this make you guys no better then cod4 devs for not fixing the exploit ddros attacks.

Edited April 30, 2012 by ViolentCrimes

[{-SMAKU-}_MotorMouth]

We test and only allow mods for certain games. If it requires an upload of .bat, .exe, .dll or any other file that can be used to get into out systems we make the installer.

[Trevor]

We test and only allow mods for certain games. If it requires an upload of .bat, .exe, .dll or any other file that can be used to get into out systems we make the installer.

 

This is a great start but i am pretty sure that this exploit is triggered by an uploaded .cfg file and then the server runs it during startup.

[LFA]

No offense or anything LFA but shouldn't this be an update you guys send out automatically? Why are we paying for updates if we have to do them manually ourselves? I know per say it is not an issue with tcadmin. But you can argue that tcadmin 1 should have used a different user from the start. What if we don't read the forums and have no clue about this, wouldn't this make you guys no better then cod4 devs for not fixing the exploit ddros attacks.

 

Instructions for running as a guest user has been in the product email for years. It takes less than 5 minutes to setup. TCAdmin blocks dll and exe by default. If the admin chooses to remove this restriction instead of taking the time to add them to the mod installer they should know what they are getting into. Running as a guest user is built in to v2.

[ViolentCrimes]

Yes but you are still selling v1 and charging for updates for it correct? Then why has it not been fixed for in your words years?

[ECF]

Is this argument going somewhere? Support is for the software and updates, not to deal with security issues that are caused by mismanagement of your servers, mods etc...

 

You purchased the software as is and agreed to the terms of service including the support terms when you signed up.

 

If you are looking for Luis to secure your servers it is not going to happen. If you are unhappy with the software then by all means please move to another software package.

[Bubka3]

Restricting DLL is a bad choice. We can't support all the mods and extensions for SourceMod in the world.

[ECF]

Well you have 2 choices.

 

1. Restrict dll, exe etc... and have a safe and happy server.

2. Allow dll, exe etc... and have your server hacked very quickly.

 

Version 1 was not designed nor coded to run as a user when it was created. Luis has given you the tools to secure your servers. Use them or don't.

[adamnp]

I have to agree with ECF --

 

This also helps weeding out some of the guys attempting to run a company that have no clue what they are doing. You should have a clue about security, and how to manage the operating systems you are utilizing. If you don't thats fine, hire someone who does to perform the routinely needed tasks.

 

I'd much rather Luis spend time developing and adding new features than spending that time 'idiot' proofing the software. If it was incredibly difficult for clients to replicate the fix on their own setup's I would then maybe agree that an internal patch might help thwart bad press, however keep in mind there are numerous security vulnerabilities out of box one can go after to infiltrate your systems. If you are inadequate at securing it, then Luis idiot proofing TCA will only give that particular person a little more time before the inevitable happens.

 

Kills me when I see clients running webservers under root, etc.... Cut the shit!!! Get a grip!!! DO - SOME - RESEARCH *AND* LEARN!@#!@#!@#!

 

Not sure why so many are afraid of learning!! Once you know, you don't have to ask or be scared!

 

Just sayin ....but then again, even multi billion $ companies don't take the proper precautions....So -- who knows

Edited May 1, 2012 by adamnp

[Bubka3]

2. Allow dll, exe etc... and have your server hacked very quickly.

 

We allow dll. Has our servers been hacked? No.

 

It's called each server has separate account. If someone is still not utilizing this method in 2012, they are begging to end up on this guys list at hack forums.

 

As Luis said, its in the welcome email. And the dll is blocked by default. You unlock DLL, then you need to take some security measures.

 

EDIT: Thinking about it, TCAdmin dll restriction would be bypassed as srcds.exe can write the dll. With TCA2 he would just get access to the persons server, not the whole machine.

Edited May 2, 2012 by Bubka3

[adamnp]

We allow dll. Has our servers been hacked? No.

 

It's called each server has separate account. If someone is still not utilizing this method in 2012, they are begging to end up on this guys list at hack forums.

 

Just because the software is not running on an administrator account doesn't mean they cannot do damage. The first obstacle is getting in, once you get in - the number of ways you can go is up to your imagination. Maybe it might not get to the point where it has immediate impact to you, but it is extremely simple to impact your company, and your clients and anyone who connects to that hardware.

 

On Windows all applications talk with the kernel through the API which gives a malicious person the ability to sniff or monitor or modify a program's API calls (hooking)..... This gives full control over that particular process.

 

This can obviously be useful for all kinds of fun reasons including!!! :}

Debugging, reverse engineering (Gary's favorite!!), and of course hacking!@!

 

Just look at DLL redirection as a small example here...

 

1. It is relatively simple to implement.

2. It allows us to view and modify parameters passed to an API function, change return values of that function, and run any other code we desire.

3. While most other methods require code to be injected into the target process or run from an external application, DLL redirection requires only write access to the target application's working directory.

4. We can intercept any API call without modifying the target (either on disk or in memory) or any system files.

 

SO... Get a DLL on there, then say maybe start sniffing the account, gain the users login and password... Utilize that to work backwards, maybe get into the billing system and find a bug or do some SQL injection. Possibly end up getting fully into the billing system. etc etc..

 

In my opinion, more security is always better....I go by the philosophy that people are going to fuck up and be stupid..They utilize passwords such as 'password' or 'qwerty' or their wifes name and their birthdate...People are predictable, and once you get in 1 you can go further 90% of the time..The more secure I can be, the better protected my customers are and my business is.

[Bubka3]

Even if you do not allow .DLL in TCAdmin, a exploit in srcds can allow a attacker to upload any file they wish into the server.

So really blocking .dll is just an inconvenience, since a security it provides can be bypassed by this exploit.

 

With that said, if you lock the account it runs with to a folder, I believe they are unable to access anything outside of that.

Edited May 3, 2012 by Bubka3

[adamnp]

Even if you do not allow .DLL in TCAdmin, a exploit in srcds can allow a attacker to upload any file they wish into the server.

So really blocking .dll is just an inconvenience, since a security it provides can be bypassed by this exploit.

 

With that said, if you lock the account it runs with to a folder, I believe they are unable to access anything outside of that.

 

Correct me if I'm wrong but, what I feel you are saying is if the user can get in through an IMAP exploit (exploit #1) you shouldn't patch a BIND exploit (exploit #2) or make it harder for them to get in, based of assuming theres another way they can exploit your clients?

 

I have to say, in my opinion, and my method of operations that thinking is backwards. I secure everything I can, and every avenue I can--After that, I secure every way possible into the hardware, and any port that isn't needed. Lastly, all software packages are ALWAYS up to date, all passwords secure, and whitelists/blacklists are current!!!!!!!!

 

Secure as much as you can, not as little as you can. While it may be a slighty inconvenient (which can easily become avoidable with TCA's built in features) it surely is more convenient than client information exposure, system infiltration, and souring of your company image should something malicious in nature happen.

 

I often tell people it's not should an attack take place, its should an attacker take sight.

 

I agree there are tons of issues, but disagree that there is only a minimal solution.

[Bubka3]

This is what I am saying:

 

Since all the accounts are locked to their own folder, the .dll will only be able to access their own folder (This assumes you are using Dimitri security method or TCA v2, user per service method, which I both highly recommend). So yes, I can go block .dll, which will inconvenience everyone, but the security it provides is FALSE. With srcds, the exploit which allows .dll will bypass TCA restricts, as it gets written by srcds.exe, not TCA's FTP or File Manager.

 

What your saying is, what if the client uploads the bad .dll? Well then you just hacked yourself as you won't be able to access anything outside of the game server root.

 

What if the someone uses the exploit? Then they get to hack the client's server, and they would probably only end up with access to server files and the rcon password as no one keeps there billing and control panel details in a text file on their server. To prevent this problem, the clients can disabling uploading, and enjoy a safe server.

Edited May 3, 2012 by Bubka3

[ECF]

Billing systems should be run on its own server seperated from any other application IMHO.

 

Gaining access to a game server is one thing. But having someone get to your client's personal info is another.

[Bubka3]

Billing systems should be run on its own server separated from any other application IMHO.

 

Gaining access to a game server is one thing. But having someone get to your client's personal info is another.

 

Well, I kinda assumed that people already do this. I guess not.

[ECF]

Even if you do not allow .DLL in TCAdmin, a exploit in srcds can allow a attacker to upload any file they wish into the server.

So really blocking .dll is just an inconvenience, since a security it provides can be bypassed by this exploit.

 

With that said, if you lock the account it runs with to a folder, I believe they are unable to access anything outside of that.

 

If this is true then everyone should be contacting Valve to correct this exploit, not looking to us to create a way to secure their gameservers due to a fault in the server software.

[adamnp]

This is what I am saying:

 

Since all the accounts are locked to their own folder, the .dll will only be able to access their own folder (This assumes you are using Dimitri security method or TCA v2, user per service method, which I both highly recommend). So yes, I can go block .dll, which will inconvenience everyone, but the security it provides is FALSE. With srcds, the exploit which allows .dll will bypass TCA restricts, as it gets written by srcds.exe, not TCA's FTP or File Manager.

 

What your saying is, what if the client uploads the bad .dll? Well then you just hacked yourself as you won't be able to access anything outside of the game server root.

 

What if the someone uses the exploit? Then they get to hack the client's server, and they would probably only end up with access to server files and the rcon password as no one keeps there billing and control panel details in a text file on their server. To prevent this problem, the clients can disabling uploading, and enjoy a safe server.

 

You are correct, but my point is that I feel you are being naive thinking that only because they have 'user' access they can't do any harm. They can, and it can come back to affect you--The only difference is it's more difficult and requires a higher level of skill from the attacker--Typically these are targetted attacks.

 

Most people utilize the same logins and passwords, and most companies utilize the same login signatures. If you accidently upload a hacked dll, which sniffs the account and allows the attacker to gain this particular users login and password information. In more instances than not, they can then utilize that same information to gain access to the account panels, control panels, billing panels etc. Once inside the panels, they can attempt to infiltrate even further....and it just goes from there on.

 

Look back a few years ago to the WHT hack.. They got into a backup server on a non privledged account and ended up in their entire system.

 

We?ve since learned that this very deliberate, sophisticated and calculated hack against Web Hosting Talk was carried out by gaining access to our offsite backup servers,? says the post From our backup servers, the hacker gained access to the WHT db server. The malicious attacker deleted all backups from the backup servers within the infrastructure before deleting tables from our db server. We were alerted of the db exploitation and quickly shut down the site to prevent further damage.?

"the attacker is in possession of files containing user names, email addresses and hashed passwords"

 

There are thousands of other examples, and a few examples from companies that utilize TCA..I won't name them as there is no reason to defame them at this point in time....but my point is merely helpful. I really would utilize TCA's features and block the uploading of DLL/EXE's, and use the mod installation feature to install mods for your users.

 

and as for the SRCDS upload exploit, it was fixed a while back.

 

Updates to Counter-Strike: Source have been released. The updates will be applied automatically when your Steam client is restarted. The specific changes include:

 

Engine

 

Fixed an exploit that allowed files to be uploaded to the server at arbitrary locations in the file system

Fixed a server crash caused by a client packet claiming to be an HLTV client when HLTV is disabled on the server

Fixed a server crash caused by spoofing a client disconnect message

Fixed a server crash caused by sending malformed reliable subchannel data

Edited May 3, 2012 by adamnp

[Bubka3]

You are correct, but my point is that I feel you are being naive thinking that only because they have 'user' access they can't do any harm.

Sorry, I should of been more clear, no, the group we run under does not have permissions except to open an exe as a service. It is not RDP accessible, and it can't do anything but run 1 exe as a service.

 

Oh, and the exploit fix was a partial, I am pretty sure you can still upload and download random files.

 

Here is Allied Modder's take on this.

http://wiki.alliedmods.net/SRCDS_Hardening

File upload/download

 

It's possible to convince the server to let you upload or download random files from it. Valve has been attempting to fix this, but there still seem to be some workarounds to their fixes.

 

If you are running your own servers (not rented from a GSP), you can set file permissions on them to fix the upload issue.

 

https://forums.alliedmods.net/showthread.php?p=841590

https://forums.alliedmods.net/showthread.php?t=142249

http://www.sourceop.com/modules.php?name=Downloads&d_op=viewdownload&cid=9

 

If you really want to lock down and are not lazy,

https://forums.alliedmods.net/showthread.php?p=779851

These get rids of the more common nasty exploits.

 

If this is true then everyone should be contacting Valve to correct this exploit, not looking to us to create a way to secure their gameservers due to a fault in the server software.

The exploit is only used as a targeted attack, and it takes a lot of patience. Most people will never even see it. As stated above Valve did try to fix it.

And the people looking for putting the escape code on you are just lazy people, who want TCAdmin to just double click and make them a game host.

Edited May 4, 2012 by Bubka3