question about RDS exploits
- From: "geek-y-guy" <noone@xxxxxxxxxxx>
- Date: Fri, 18 Apr 2008 21:33:58 -0400
Hi All: I may have to don my flame suit for this, but bear with me.
I have a client for whom I'm colo'ing a webserver that connects to separate
shared SQL2005 server. The colo'd server is running 2003 web edition with
all current updates and service packs installed.
The client had a legacy app that used RDS ... when I set up the server, I
had to explicitly break security to enable RDS to run. I explained at the
time that this was a serious security issue, but they signed off on the
risks.
A year later, their database get compromised and someone (script kiddie,
disgruntled employee, other?) inserts some JS malware code into all the
fields in the database. By the time the problem is discovered, their malware
installation script has overwritten itself several times, breaking the JS
code they inserted (luckily). I'm fairly certain the RDS vulnerability was
exploited on the webserver, giving the attackers dbo access to the dB.
I restore the dB from a backup, but it gets compromised again, and again.
Finally I convince them to remove the pages running RDS and change the dB
password and the attack is stopped...for now. Fortunately, security
protocols were sufficient enough on thedB server to protect the other dBs.
Problem is, the dB server was exposed to the internet, albeit on a
non-standard port. That's been addressed as well at this point, but I assume
that once they cracked the connection string they were attacking the dB
server directly.
My question is, would the attackers have been able to retrieve the dbo
uname/pwd/connection params from the webserver using the usual RDS exploit
scripts, and were they then attacking the dB server directly? If so, will
removing internet access from the dB server protect against the exploit, or
can they use RDS to attack the dB via the webserver, even with all the pages
disabled?
Any thoughts or recommendations appreciated!
.
- Prev by Date: minimum permissions to grant / delete logins
- Next by Date: MSSQL audit and compliance tool
- Previous by thread: minimum permissions to grant / delete logins
- Next by thread: MSSQL audit and compliance tool
- Index(es):
Relevant Pages
|
|
