“Security by obscurity is bad!“… Most infosec professionals will tell you this. The principle is to implement security by hiding stuff in the installation of tools or solutions. Often, people using security by obscurity believe that their stuff will be properly protected (not found by the attackers). But this technique will protect you only during the reconnaissance phase of the attacker. It will just make his task more difficult to gather interesting information.
After the Alexander Kornbrust’s talk during the last edition of  HashDays about self-defending databases, a question popped up in my mind: It could be interesting to know what are the most commonly used table and row names in databases. This could help to track suspicious queries sent to SQL engines. So, what are the preferred words used by developers?
A few days ago, I found an interesting piece of code via my tool pastemon.pl on pastebin. The code was very suspicious and was quickly deleted by the Pastebin team! But i’ve a local copy! Basically, it’s a IRC bot written in Perl which connects back to an IRC channel and performs queries on multiple search engines to grab SQL URLs returning errors. Its purpose is to search for websites vulnerable to SQL injections. But the most interesting part was the data searched by the bot. The source code contains interesting information, exactly the ones I was looking for: table and row names!
my @tabele = ('admin','tblUsers','tblAdmin','user','users', 'username','usernames','usuario','name','names', 'nombre','nombres','usuarios','member','members', 'admin_table','miembro','miembros','membername', 'admins','administrator','administrators', 'passwd','password','passwords','pass','Pass', 'tAdmin','tadmin','user_password','user_passwords', 'user_name','user_names','member_password','mods', 'mod','moderators','moderator','user_email', 'user_emails','user_mail','user_mails','mail', 'emails','email','address','e-mail','emailaddress', 'correo','correos','phpbb_users','log','logins', 'login','registers','register','usr','usrs','ps', 'pw','un','u_name','u_pass','tpassword','tPassword', 'u_password','nick','nicks','manager','managers', 'administrador','tUser','tUsers','administradores', 'clave','login_id','pwd','pas','sistema_id', 'sistema_usuario','sistema_password','contrasena', 'auth','key','senha','tb_admin','tb_administrator', 'tb_login','tb_logon','tb_members_tb_member', 'tb_users','tb_user','tb_sys','sys','fazerlogon', 'logon','fazer','authorization','membros', 'utilizadores','staff','nuke_authors','accounts', 'account','accnts','associated','accnt','customers', 'customer','membres','administrateur','utilisateur', 'tuser','tusers','utilisateurs','password', 'amministratore','god','God','authors','asociado', 'asociados','autores','membername','autor', 'autores','Users','Admin','Members','Miembros', 'Usuario','Usuarios','ADMIN','USERS','USER', 'MEMBER','MEMBERS','USUARIO','USUARIOS','MIEMBROS', 'MIEMBRO'); my @kolumny  = ('admin_name','cla_adm','usu_adm','fazer','logon', 'fazerlogon','authorization','membros', 'utilizadores','sysadmin','email','user_name', 'username','name','user','user_name', 'user_username','uname','user_uname','usern', 'user_usern','un','user_un','mail','usrnm', 'user_usrnm','usr','usernm','user_usernm','nm', 'user_nm','login','u_name','nombre','login_id', 'usr','sistema_id','author','sistema_usuario', 'auth','key','membername','nme','unme','psw', 'password','user_password','autores','pass_hash', 'hash','pass','correo','userpass','user_pass', 'upw','pword','user_pword','passwd','user_passwd', 'passw','user_passw','pwrd','user_pwrd','pwd', 'authors','user_pwd','u_pass','clave','usuario', 'contrasena','pas','sistema_password','autor', 'upassword','web_password','web_username');
The origin of the bot is clear: Poland (“kolumny” means columns in Polish). But the authors targeted also Spanish databases according to the table names (“usuario“, “miembros“). Based on the data above, if security by obscurity is bad, choosing right unique names for your databases schemas can slightly reduce the risk to be compromized. But let’s be clear, this will never prevent you to write secure code! 😉
IMO using obscurity as a layer improves security and is better than no extra layer.
RT @xme: [/dev/random] Database Tables and Rows: Security by Obscurity Is Sometimes Helpful! http://t.co/DK1wT11L
RT @xme: [/dev/random] Database Tables and Rows: Security by Obscurity Is Sometimes Helpful! http://t.co/DK1wT11L