Independent Digital

You’ve probably been using WordPress for a while now, you love it but every now and then something weird happens and your blog just does not perform as it should. So when a new update comes out, you’re overjoyed and eagerly update your blog, hoping all the problems will disappear. But they don’t. Maybe your blog was hacked at some stage but you found the gap and blocked it for good, or so you thought.

You keep getting hacked even though you have kept up with the latest WordPress updates so now you’re thinking of ditching Wordpress. Don’t! The solution is simple, it may take a bit of time but it will be worth it in the end.

I’ve been using Wordpress for about 2 years now and have been hacked a few times. Each time I thought I had it sorted only to be hacked again and again…Here are some of the symptoms I experienced:

• I edited posts and pages, pressed SAVE but they were deleted instead of being saved.
• I try to access my blog only to see this… database error: [User '???????' has exceeded the 'max_questions' resource (current value: 50000)]
• I started getting high volumes of spam mail (some using my address as the sender)
• I try to access my blog and all I see is a blank page
• My theme disappears
• My theme is swapped for the classic or default theme
• My database disappears
• I keep getting the installation page when trying to access my blog
• Posts and pages disappear

My final solution was to delete everything and start again. Naturally I had a backup. I first checked my server for any weird looking files and folders. I found a few and downloaded these to a safe folder. I then noted all the plugins that I had as well as the theme that I was using. I deleted all these. Then I deleted all the WordPress files and folders. I then checked the server once again for any weird folders or files (a bit difficult as I had quite a few other, non-WordPress related stuff installed, many of which I could not remember whether they were legitimate or not). So be careful, don’t delete unless you are absolutely sure that it is not supposed to be there. Try downloading to a safe folder before deleting so if it was a valuable folder or file, then you can always recover it.

Okay, once I had a “clean” server, I downloaded the latest version of WordPress, unzipped it and installed it on the server. I chose to create a new wp-config.php file rather than use the old one – I wanted a completely fresh start and didn’t want to risk carrying stuff over from that last install that may be “infected”. Once I had the basic installation working perfectly, I downloaded a new copy of my chosen theme from a legitimate site (see article on themes are a security risk) and installed this in the Themes folder.

If you can view your backup file, check out the wp_options table for any “active_plugins” and delete these, save the file and import it into your WordPress database. Try viewing your blog – it should function properly with the new theme.

I then downloaded all the latest plugins (as per the list of plugins that I had installed before the deletion) from legitimate sites. Unzipped and uploaded these to the plugins directory and activated them all. I then tried accessing the blog and found a few problems:

• The layout was not as it used to be. I then realised that I had done some editing of the theme files to suite the layout that I wanted. So back to editing the HTML to get the pages looking as before.
• Some plugins weren’t working. This was because some of them required some code to be installed within the WordPress “loop”. So a quick inspection of the installation instructions for the various plugins pointed me in the right direction. I was able to install the necessary code and get the blog working as before. I also chose to install “clean” plugins rather than use the old ones because of my fear of contamination. (see article on plugins are a security risk)

So what did I learn from all this?

1. Updates alone will not sort out a hacking problem. Previous versions of WordPress had security problems, which may have led to a security breach of my site. Similarly I may have been careless in other ways, allowing a hacker into my site. The point is that the hacker got through and was able to install code on my site. Updates from then on were useless as far as securing my site was concerned as the hacker was already on my site.
2. I expected Wordpress to take care of my security when I should have been taking care of it myself. I thought that if I updated regularly, my site would be secure. I was wrong as the hacker was already inside.
3. That I need to take security seriously. I did not believe that I would be hacked. I was, not once, not twice but many times. The time and effort that I spent trying to recover from the problems caused should rather have been spent taking preventative measures.
4. That I need to make sure that my site is free of suspicious files and code (within themes and plugins) – if hackers can get into your site, they can upload destructive files and edit your files by adding malicious code). It happened to me. One of the symptoms I noticed was the increasing amount of spam email that I was receiving. Since sorting out my site, the spam email has disappeared.
5. That I need to update my plugins and themes – from LEGITIMATE sources.
6. Increase my security by installing security plugins such as login lockDown,wp-security scan and askApache.

As of the time of writing, my site seems to be working smoothly and thankfully hacker free. If you would like to sort out your hacker problem once and for all but don’t have the time to do it, why not let us take care of the hassle and do it for you. Let us know.

Security Issues with LOAD DATA LOCAL

The LOAD DATA statement can load a file located on the server host, or a file located on the client host when the LOCAL keyword is specified.

There are two security issues when using the LOCAL version of LOAD DATA:

• The MySQL server initiates the transfer of the file from the client host to the server host. It is therefore possible for the server to access any file on the client host to which the client user has read access.

• In a Web environment, a user could use LOAD DATA LOCAL to read any files that the Web server process has read access to.

These problems have been address in the later versions of MySQL (versions 3.23.49 and 4.0.2):

• All MySQL clients and libraries in binary distributions are compiled, by default, with the –enable-local-infile option, to be compatible with MySQL 3.23.48 and before.

• If you build MySQL from source, you must invoke configure with the –enable-local-infile option, or else LOAD DATA LOCAL cannot be used by any client unless it is written explicitly to invoke mysql options(?MYSQL OPT LOCAL INFILE, 0),

• Disable all LOAD DATA LOCAL commands from the server side by starting mysqld with the –local-infile=0 option.

• With the mysql command-line client, LOAD DATA LOCAL can be enabled by specifying the –local-infile[=1] option and disabled with the –local-infile=0 option. For mysqlimport, the –local or -L option enables local data file loading.

• If you use LOAD DATA LOCAL in programs that read the [client] group from option files, you can add the local-infile=1 option to that group. But use the loose- prefix to keep this from causing problems for programs that do not understand local-infile. If LOAD DATA LOCAL INFILE is disabled then a client that issues such a statement receives an error message.

Want to be notified when new posts are published?

Your email:  
Subscribe Unsubscribe  

Protecting your File System

You should try and ensure that access to your local file system is protected from unauthorized creation, modification, or deletion. The file system is quite vulnerable to attack.

Defacement

A common attack is defacement. Usually the attacker ends up defacing your site, much to your embarrassment. Most defacement occurs because of poor patching of vulnerable web servers. The second most common form of defacement is due to web application vulnerabilities.

To secure your file system, you should try to:
? Use ?chroot? jails on Unix platforms
? Use minimal file system permissions on all platforms
? Consider the use of read-only file systems (such as CD-ROM or locked USB key) if
practical.

You can check if you system is vulnerable by confirming the following:
? Is your system up to date? If not, then update it.
? Does the file system allow writing via the web user to the web content (including
directories?) To secure your system, ensure that the application files and resources are read-only.
? Does the application write files with user supplied file names? To secure your system, ensure that the application does not take user supplied file names when saving or working on local files
? Does the application use file system calls or executes system commands (such as exec()
or xp_cmdshell()? To secure your system, ensure that the application checks all user supplied input to prevent any commands from being run.
? Would any execution or file system calls allow the execution of additional, unauthorized commands? See how to prevent injection attacks.

Path traversal

Most web applications include local resources, such as images, themes, other scripts, etc. Each time a resource or file is included by the application, it is possible that an attacker may be able to include a file or remote resource you didn?t authorize.

Your file system is vulnerable if:
? files have unauthorized code containing file open, include, file create, file delete, and so on
? files contain unsanitized user input.

To protect your file system, do the following:
? Try not to have user input when using file system calls
? Use indexes rather than actual portions of file names when templating or using language
files (eg the value 1 for America rather than allowing the user to return ?America?)
? Don’t allow the user to supply the whole path ? surround it with your path code
? Validate the user?s input by only accepting known good ? do not sanitize the data
? Use chrooted jails and code access policies to restrict where the files can be obtained or
saved to

File permissions

Your file system is vulnerable to local and remote attack if users can read, modify or delete files used by the web application.

Protect yourself:
? By using the tightest possible permissions when developing and deploying web applications
? By trying to deployed your application on read-only media, such as CD-ROMs
? By considering using chroot jails and code access security policies to restrict and control the
location and type of file operations even if the system is misconfigured
? By removing all ?Everyone:Full Control? ACLs on Windows, and all mode 777 (world
writeable directories) or mode 666 files (world writeable files) on Unix systems
? By strongly considering removing ?Guest?, ?everyone? and world readable permissions
wherever possible

Insecure Indexing

Search tools such as Google are very useful but can also be used by attackers to find vulnerable information on your system. Your system is vulnerable if Google or other search tools can find things such as hidden files or meta tags.

Protect yourself by:
? Using robots.txt ? this will prevent most search engines looking any further than what you
have in mind
? Tightly controlling the activities of any search engine you run for your site, such as the IIS
Search Engine, Sharepoint, Google appliance, and so on.
? Disabling any search functionality on your website if you don?t need it

Unmapped files

Web applications only interpret their own files to the user. All other content is rendered as HTML or plain text. This may disclose secrets and configurations which an attacker may be able to use to successfully attack the application.

To check if your system is vulnerable, use your browser to request a file that is not normally visible. If the file?s contents are rendered or exposed, then the application is at risk.

To protect yourself:
? Remove or move all files that do not belong in the web root
? Rename include files to be normal extension (such as foo.inc to foo.jsp or foo.aspx)
? Map all files that need to remain, such as .xml or .cfg to an error handler or a renderer
that will not disclose the file contents. This may need to be done in both the web
application framework?s configuration area or the web server?s configuration.

Temporary files

Applications occasionally need to write data to a temporary file. These files, if exposed
to unauthorized users, may expose private and confidential information.

If your application uses temporary files, check the following:
? Are the files in the web root? If they are, can they be retrieved using just a browser? If so,
can it be done without being logged on?
? Are old files exposed? Is there a garbage collector or other mechanism deleting old files?
? Does retrieval of the files expose the application?s workings, or expose private data?

To protect yourself, consider the following controls:
? Generate the content on the fly rather than storing the data in a temporary file
? Users must be authenticated before they can retrieve any resource. Also, ensure that they only have access to their own files
? Use a ?garbage collector? to delete old temporary files
? If deployed under Unix like operating systems, use chroot jails to isolate the application
from the primary operating system. On Windows, use the inbuilt ACL support to prevent
the IIS users from retrieving or overwriting the files directly
? Move the files to outside the web root to prevent browser-only attacks
? Use random file names to decrease the likelihood of a brute force pharming attack

Old, unreferenced files

Old temporary files may contain sensitive source or configuration data which attackers may be able to access.

Check the file system for:
? Temporary files created by editors or crashed programs
? Folders called ?backup? ?old? or ?Copy of ??
? Files with additional extensions, such as foo.php.old
? Temporary folders with intermediate results or cache templates

To protect yourself:
? Prevent the need to keep old copies of files around
? Periodically ensure that all files in the web root are required
? Ensure that the application?s temporary files are not accessible from the web root

Second Order Injection

If the web application creates a file that is operated on by another process, typically a batch
or scheduled process, the second process may be vulnerable to attack.

To check if you are vulnerable:
? Does the application use background / batch / scheduled processes to work on user
supplied data?
? Does this program validate the user input prior to operating on it?
? Does this program communicate with other business significant processes or otherwise
approve transactions?

To protect yourself:
? Ensure that all behind the scenes programs check user input prior to operating on it
? Run the application with the least privileges ? in particular, the batch application should
not require write privileges to any front end files
? Restrict the resources and features which the background application may use
? Use host based intrusion detection systems and anti-virus systems to detect unauthorized file creation.

For more on how to secure your site, get our FREE E Book

This E Book covers all aspects of web applications and web services security. It is compiled by professionals in the field and is used by thousands in the internet industry to ensure their web security. The E Book covers:

• SQL injection
• Phishing
• Credit card handling
• Session fixation
• Cross-site request forgeries
• Compliance and privacy issues
• Denial of service attacks

It is a must have for anyone serious about web security. Get it right now. It’s FREE!

Security-Related mysqld Options

The following mysqld options affect security:

–allow-suspicious-udfs

This controls whether user-defined functions that have only an symbol for the main function can be loaded. By default, the option is off and only UDFs that have at least one auxiliary symbol can be loaded

If you start the server with –local-infile=0, clients cannot use LOCAL in LOAD DATA statements

Force the server to generate short (pre-4.1) password hashes for new passwords. This is useful for compatibility when the server must support older client programs.

–safe-show-database

–safe-user-create

If this option is enabled, a user cannot create new MySQL users by using the GRANT statement unless the user has the INSERT privilege for the mysql user table or any column in the table.

–secure-auth

Disallow authentication for accounts that have old (pre-4.1) passwords.

–secure-file-priv=

This option limits the effect of the LOAD_FILE() function and the LOAD DATA and SELECT … INTO OUTFILE statements to work only with files in the specified directory.

–skip-grant-tables

This option causes the server not to use the privilege system at all. This gives anyone with access to the server unrestricted access to all databases.

–skip-name-resolve

Hostnames are not resolved. All Host column values in the grant tables must be IP numbers or localhost.

–skip-networking

Do not allow TCP/IP connections over the network. All connections to mysqld must be made via Unix socket files.

–skip-show-database

With this option, the SHOW DATABASES statement is allowed only to users who have the SHOW DATABASES privilege, and the statement displays all database names.

Want to be notified when new posts are published?

Your email:  
Subscribe Unsubscribe  

Securing MySQL Against Attackers

The password is encrypted when you connect to the MySQL server and as of MySQL 4.1.1 is very secure. However, it is advisable to upgrade if you are still using an earlier version of MySQL as hackers could quite easily crack your password. For those using MySQL Enterprise, the Enterprise Monitor enforces best practices for the maximum security of the MySQL server.

Besides the password, all other information is not encrypted and is transferred as text and can be read by hackers. Use the compressed protocol if you are concerned about this as it makes it more difficult to hack. You can also use MySQL’s internal SSL support to make the connection even more secure or use SSH to get an encrypted TCP/IP connection between a MySQL server and a MySQL client. (See http://www.openssh.org/ for an Open Source SSH client).

Consider the following in order to improve your MySQL security:

• Require all MySQL accounts to have a password.

• Never run the MySQL server as the Unix root user - mysqld should be run as an ordinary, unprivileged user.

• Do not allow the use of symlinks to tables

• Make sure that the only Unix user with read or write privileges in the database directories is the user that mysqld runs as.

• Do not grant the PROCESS or SUPER privilege to non-administrative users.

• Do not grant the FILE privilege to non-administrative users.

• Use IP numbers rather than hostnames in the grant tables.

• Restrict the number of connections allowed to a single account - by setting the max_user_connections variable in mysqld…

Want to be notified when a new post is published?

Your email:  
Subscribe Unsubscribe  

If you have a MySQL database that is open to the internet then you need to read the following security guidelines so that you will be in a better position to protect your data.All security measures should apply to the entire server and not just the MySQL server in order to protect it from any and all types of attacks, including:

? Eavesdropping

? Altering

? Playback

? Denial of service.

MySQL uses security based on Access Control Lists (ACLs) for all connections, queries, and other operations. MySQL also supports SSL-encrypted connections between MySQL clients and servers.

When using MySQL:

? Don?t give anyone (except MySQL root accounts) access to the user table in the mysql database!

? Familiarize yourself with the MySQL access privilege system (GRANT and REVOKE)

o Don?t grant more privileges than necessary.

o Don?t grant privileges to all hosts.

Check the following:

? Try mysql -u root. If you are able to connect to the server without being asked for a password, then anyone can connect to your MySQL database!

? Use SHOW GRANTS to check which accounts have access to what. Use the REVOKE statement to remove those privileges that are not necessary.

? Don?t store any plain-text passwords in your database. Instead, use a hashing function such as, MD5()or SHA1() and store the hash value.

? Don?t choose passwords from dictionaries. Read up on how to choose a secure password.

? Do use a firewall. Firewalls are able to keep out about 50% of all types of exploits. Put MySQL behind the firewall.

o Check:

Try to scan your ports from the Internet using a tool such as nmap. MySQL?s default port should not be accessible from untrusted hosts. Also try the following command from some remote machine, where server_host is the hostname or IP number of the host on which your MySQL server runs:

shell> telnet server_host 3306

If you get a connection and some garbage characters, the port is open, and should be closed on your firewall or router. If telnet hangs or the connection is refused then the port is, correctly, blocked.

? Do not trust any data entered by users of your applications. They can enter special or escaped character sequences in Web forms, URLs, etc, which can then access your database.

Protect both string data values as well numeric data. Use single quotes around the numeric constants:

SELECT * FROM table WHERE ID=’234′

If the user enters extra information, it all becomes part of the string, In a numeric context, MySQL converts this string into a number and strips any trailing non-numeric characters from it.

? Also protect publicly available information against denial of service attacks. Otherwise, your server becomes unresponsive to legitimate users.

Check:

o Use single and double quote marks (?‘? and ?“?) in all of your Web forms.

o Modify dynamic URLs by adding %22 (?“?), %23 (?#?), and %27 (?‘?) to them.

o Modify data types in dynamic URLs from numeric to character types using the above characters.

o Do not pass unchecked values to MySQL. Test enter characters, spaces, and special symbols rather than numbers in numeric fields. Your application should remove them before passing them to MySQL or else generate an error.

o Check the size of data before passing it to MySQL.

o Use a different username (and not your administrative username) for your application to connect to the database.

o Do not give your applications any access privileges they do not need.

o Use application programmes such as Php, Pearl, etc to escape special characters in data values. This prevents users from entering values that cause the application to generate statements that have a different effect than you intend.

? Do not transmit plain (unencrypted) data over the Internet. Rather use an encrypted protocol such as SSL or SSH..

? Use the tcpdump and strings utilities to check whether MySQL data streams are unencrypted by issuing a command like the following (works under Linux and probably with some modification under other systems):

shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings

Be aware though that the lack of plain text does not always mean that the information is encrypted. Consult a security expert if you need high security.

Want to be notified when new posts are published?

Your email:  
Subscribe Unsubscribe  

?The Cult of the Dead Cow? announced last week, the release of Goolag Scanner, a free open source web-auditing tool. Goolag Scanner enables anyone to examine their website via Google for any security holes. The scanner technology is based on “Google hacking” developed by Johnny I Hack Stuff. Goolag Scanner can be used by web site owners to detect and correct any security flaws in their web site.

Johnny previously published a collection of these “Google Hacks” or “Google Dorks” on his web site, which are used by ?professional? hackers. Goolag scanner has now packaged these into a GUI automated tool that allows an unskilled hacker to use these very same techniques.

Goolag Scanner is a standalone windows GUI based application using about 1,500 pre-configured Google search queries or dorks. It searches for links to vulnerable web applications, back doors, or documents containing sensitive information. You can select individual searches or sets of them. You restrict the search to your own server, or extend it right up to an entire top-level domain. The results are displayed as a list of URLs that can be opened in the browser. However, if you use the tool too much, Google may block your IP address and there may also be legal implications so be cautious when using it.

Want to be notified when new posts are published?

Your email:  
Subscribe Unsubscribe  

Be careful when installing plugins. It is a dangerous world out there with many strange people doing strange things. Now not all plugins are dangerous and neither are their authors. Some plugins, however, have simply not been tested enough with the result that malicious hackers manage to find flaws, which they can exploit to do their dirty deeds. They then search the net for WordPress sites running that plugin. When they find it, they?re in and before you know it, your WordPress blog is performing erratically or your database has been deleted.

One example of this plugin security issue is the wp-forum 1.74 plugin. According to the securityfocus website, ?it is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query. (This would allow an)? attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.?

Another example is the wp-db-backup plugin, which had a serious vulnerability issue. Now I am not saying that it is the intention of the plugin author to create plugins containing devious code which allows a security breach. It is more likely that the authors themselves are unaware of the security flaw. As far as I know, there is no standardized validation of plugins to ensure that they are not a security problem. So we need to be very careful before we install any plugin. Do research, check on the web and within forums to see whether others have experienced security issues when using that plugin. If there are no known issues, make sure that you have backed up your website and database before installing the plugin. The WordPress team are continually upgrading WordPress to ensure that it is as secure as possible so remember that the most important step that you can take to secure your site, is to ensure that you are running the latest version of WordPress.

Have a look at this excellent article on plugins and security issues.

Some plugins with known issues

• WordPress BackUpWordPress plugin Php File inclusion vulnerabilities 2007-11-06

• WordPress WP Photo Album Plugin “photo” SQL Injection 2008-02-20

• WordPress Search Unleashed Plugin “s” Script Insertion Vulnerability 2008-02-5

• WordPress DMSGuestbook Plugin Multiple Vulnerabilities 2008-02-05

• Wordspew Plugin for Wordpress “id” SQL Injection Vulnerability 2008-02-04

• WordPress WP-Footnotes Plugin “admin_panel.php” Cross-Site Scripting 2008-2-04

• WordPress WassUp Plugin “to_date” SQL Injection Vulnerability 2008-01-31

• WordPress AdServe Plugin “id” SQL Injection 2008-01-30

• WordPress WP-Cal Plugin “id” SQL Injection 2008-01-29

• WordPress Permalinks Migration Plugin Cross-Site Request Forgery 008-01-24

• WordPress WP-Forum Plugin “user” SQL Injection 2008-01-21

• WordPress PictPress Plugin “path” Disclosure of Sensitive Information 2007-12-07

• WP-FeedStats Plugin for WordPress Script Insertion Vulnerabilities 2007-07-27

• WordPress AdSense-Deluxe Plugin Cross-Site Request Forgery 2007-05-22

• WordPress wp-Table Plugin “wpPATH” File Inclusion 2007-05-02

• WordPress wordTube Plugin “wpPATH” File Inclusion 2007-05-02

• WordPress myGallery Plugin “myPath” File Inclusion 2007-04-30

• WordPress WP-DB Backup Plugin Directory Traversal Vulnerability 2006-08-15

• FeedBurner FeedSmith Cross-Site Request Forgery Vulnerability 2007-10-04

Here?s a list of plugins that you can install to make your WordPress blog more secure.

Want to be notified when there is a new post?

Your email:  
Subscribe Unsubscribe