Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Google?
Assuming I had access to them all I would delete them all.
Orherwise it would depend on which system it is and how I got access to it. -
voidpy5156yMake a copy of the database and save it on my hard drive, then fire up SQLite and execute "DROP TABLE foo" or "UPDATE foo SET * = 'gay'" on the original one.
-
Start adding garbage data slowly over the time.
Deleted data can be restored in few hours.
Till the time they figure out garbage data will be in backups -
p100sch15006yJust drop it, it is not worth more consideration. After all a few hours of downtime scares almost all customers away from a service. But I'm not an asshole who endangers the data of innocent customers of him. That would be heartless. You may love to see Microsoft going out of business, but wrecking a Dev team's TFS too would be cruel.
-
Root system shell:
Modify the config to accept remote connections, create a script that: deletes itself from disk, creates a system user with root priv that accepts remote access via ssh key, accepts connections from a specific private key you own during 10 minutes (randomize the time for bonus points), deletes the user after time expires, fires a background process to restart the script in 24 hours. Download data intelligently, analyze for maximum impact (release of data publicly, exploitation of username:passwords, etc.) Analyze network traffic and subnet for additional likely targets. Maintain a low profile. See how deep the rabbit hole goes.
Root database connection only:
Attempt privilege escalation to system shell, if unsuccessful analyze backup pattern and replicate similar dump time for a script to collect database dumps over time. Look for SQL injection opportunities with application / service using collected data. Analyze data to determine other api endpoints or services to attempt to exploit. Profit from data via release or exploitation of username:passwords. Delete everything when maximally exploited.
Holy shit I should have been a hacker. -
I would normalize the tables, add indexes where necessary, add more integrity validation in the backend, introduce audit logs...
YEAH I HEARD YOU, YOU SAID ENEMY.
I'm a DBA, I can't help it. -
altering random records in a slight but relevant way. This would probably go unnoticed for many backup cycles, and if it finally gets discovered it will be hard to impossible to tell when it all started, dooming the entire collection. The emotional impact is also bigger..i think.
-
Instead of just wrecking stuff, like truncating all tables, it would be more fun to shuffle the foreign keys in every table.
No one will suspect a thing, apart from the fact that end users suddenly have each other's avatars and preferences, and for example in case of a webshop all orders are sent with randomized items to randomized addresses, paid from random credit cards... it's like a super fun secret santa event :D -
I'd look for normalization mistakes and flood the db with realistic but corrupt data. Have fun figuring out what causes the errors.
If you had root access to your enemy's database. What would you do? 😈
question