Archive

Archive for the ‘Database’ Category

Verizon releases corporate security breach report

June 11th, 2008 chad No comments

Verizon Business has released a report that touches on what they found after looking through 500 forensic investigations involving 230 million records, and analyzes hundreds of corporate breaches. These breaches include three of the five largest breaches ever reported. Here is a few items they discovered:

  • 87% of corporate data breaches could have been prevented if they had reasonable security measures been in place (duh!).
  • Less than 25 percent of attacks took advantage of a known or unknown vulnerability.
  • Asian attacks (mainly China and Vietnam) are usually application exploits that are used for data compromise.
  • Most defacements originate out of the Middle East.

There’s also some very good information in the article regarding how to protect your network and data. I would strongly encourage any network/system administrator to, at the very least, browse this part of the report.

Google hacking – is your network vulnerable?

April 9th, 2008 chad No comments

Google hacking has been talked about on several other web sites before, but most people just don’t think about the implications of not securing their services. Often the attitude of “it could never happen to me” takes precedence over an admin taking proper security precautions. After performing some simple Google searches, you too can gain access to everything from database information, personal emails, and even some free mp3s.

First, let’s start off with a simple database search and password search. These simple two searches can reveal configuration information about databases including login and password combinations. For example, nv-happydays.com showed three files that are downloadable including a two password.inc files and a WS_FTP log that revealed other sites. Luckily, all of the sites related to nv-happydays.com did not allow direct database connections.

If a database is connected to the internet and not properly protected, anyone can run a database query on (for example) port 3306 for a MySQL database server and find even more, and potentially sensitive, information. You should NEVER be able to publicly read a database configuration file – you should only see something similar to this. Otherwise, you have set yourself up to have many many files viewable by the world for potentially nefarious purposes.

blackworldnews.com was not so lucky about other files. These included their mysql.sql file, their inbox file (mostly spam just like everyone else), and their shadow file which was loaded into and proved to be crackable by John the Ripper in a fairly short amount of time. 8 hours, 47 minutes, and 31 seconds to be exact.

Another unlucky Googled site was wealdendun.com. Their mysql.sql file as well as their shadow file were found, and again, could be cracked by John in a very short amount of time just like blackworldnews.com.

Another search that turned up some interesting information was searching for backups. I found an educational institution that used BlackBoard (just like Davenport) had their backup files publicly readable. Also readable were usage statistics and more detailed usage statistics. No, not the most exciting stuff in the world, but I would think that these items should probably be limited to system administrators and not the whole world.

Solution: Fairly simple. At the very least, add the extension .php for any files that have .inc as an extension. Examples include, but are not limited to “password.inc”, “database.inc”, “configuration.inc”, or any other *.inc file. They would then be changed to “password.inc.php”, “database.inc.php”, “configuration.inc.php”, or *.inc.php instead respectively. Every *.inc file I have ran across has coding that starts with <? and ends with ?>. This is typically how php coding starts, but most browsers don’t go simply off of the code they see, they go off of the extension when processing files. If the extensions were *.php, anything in between the <? and ?> would get hidden even if one tried to view the source of the file. Another solution would be to add a black index.html file to directories that don’t already have an index file of some sort. Apache can also be configured to not to allow directory listings so these files are not viewable by search engines in the first place. To do this add the text “Options -Indexes” (without quotes) in a .htaccess file. Google it if you’re not familiar with htaccess files. However, if the files have already been exposed to search engines, they’ve most likely been crawled. In this case, you NEED to take the previous measures to remove access to your files and then IMMEDIATELY change your passwords.

Materials: A web browser and some free time.

Categories: Database, DoS, E-mail, Internet, Linux, Network, Windows Tags: