Information Sharing - A Double-Edged Sword

This posting was sparked by a few new exploits on the rise, a Java exploit and a couple of Ruby-on-Rails vulnerabilities. I found out about both of them from Dark Reading.

I've been using computers for a very long time (31 years) by technology standards. One thing I've become accustomed to is regular updates and patches to systems, programs, and apps. Sometimes the systems that need to be patched aren't the systems that people themselves might have access to, but they may be a web server, a mail server, a programming interface, or even a server-side plugin.


The good
The reason these things need to be patched and fixed isn't because the companies who are making the patches are making money off of them. It's actually kind of counter that. It's a huge issue for a company's brand (yes, PR and Marketing) when their software is the main reason most of the Internet or Corporate America goes down. Think of the damage control a company like Microsoft has to do when there is a massive worm spreading around the Internet like CodeRed or the Melissa Virus. It's huge. People change platforms, they decide they can no longer trust a company with such glaring vulnerabilities. They "switch." I myself started using Macs simply because I trust Unix way more than I do Microsoft's ability to protect my system e-mails and webpages.

Here's the problem though, those vulnerabilities usually aren't because some crazy hacker on a mission has decided they're going to ruin one of these worldwide brands. It's usually because the company themselves have someone, either on their payroll or contracted who has provided the notification of the exploit initially (internally or through a provider channel), either when they were working on the code, they crashed their own systems, or they had a hunch and tested their theory. They notify the company who in-turn rolls out a patch... these people are paid to provide this service.

People read everything with their own filter on the world. If they are a good person, when they see a patch, they probably think to themselves... I need to apply this because I don't want any downtime... but what if the people are bad? Okay, let's not say "good" and "bad" because that's not necessarily the case at all (and part of a larger discussion). Let's say they are users and then those other people who have "too much time on their hands" at the moment. I say this because at one point or another in a white hat hacker's life they have more than likely infected something or spread something on accident. They're not bad people, but if it's uncontrolled it could do just as much damage. Always test on an offline machine if you're going to open Pandora's Box.

The bad
So back to my point about the people filtering what they see. When someone who 1.) wants to experiment, 2.) has downtime, and 3.) a need of an idea for something to hack, they have this great expanse of information (the Internet)... I know it's pretty obvious right? Although [most] people think that most hackers all go to secret websites and have a secret handshake, that's really just the people who go to Defcon or who have friends who are hackers because they do it for a living, or they want to pretend they're hackers. Most of the other hackers I've met happened by accident because someone else mentioned that I hacked, then we talked about the level of what we were into.

Usually self-proclaimed "hackers" in my experience are in actuality script kiddies (people who use a program or a tool in a way they've read about to purposely cause chaos), so often when I'm confronted with the questions of what I do, I kind of go the other way and don't share what I'm into unless they let me know that they're "cool," A.K.A. not a script kiddie. Just like the branding issues companies have with being exploited, "hackers" white, black, and gray.... all hats, also have a branding issue because somewhere some [insert expletive here] is writing a virus that will cause harm and it says the same thing on my nametag to society that his says... I'm a creative professional with the means and ability. Society doesn't care whether I would do it or not or about my moral compass, but you have to think like a "bad guy" to outsmart a bad guy... it doesn't make me "bad." But it makes the unknowing populous marvel and wonder (in a bad way).

On with the Internet reference... when I say they have the Internet at their fingertips, they don't need to go to one of the heavily monitored websites for script kiddies or the IRC channels, all they have to do is browse through a company's patches. In the patches that most people install there is usually some bit of information that says what exploit or vulnerability is being patched. Apple doesn't share a lot of detail about this, but Microsoft usually tells you what they're patching if you follow enough links from Windows Update. Java, Ruby, PHP, and most other opensource languages will release it in a bugfix that you can read about. When it happened to Microsoft's brand before, Microsoft had already provided patches for the exploits for CodeRed and Melissa long before they were in the wild and running rampant. Most people however do not like applying patches because, just like going to the doctor, "If it ain't broke don't fix it."

I've heard all sorts of reasons why someone shouldn't patch something... "because if they don't know I'm running an older version I'm safe" or "it might bring down my machine so I wait a couple of months to test it." Zero-day patches just like zero-day exploits can also bring your machine to its knees. I wait about a week to make sure that a patch has been thoroughly tested by the masses. It takes most companies a couple of days to clean up after a failed patch, so that should be enough time to cover myself. (I can't afford to have downtime.)

The incurable
When an idle mind sees a patch and decides to take it upon themselves to figure out how to exploit it, then that's where the problems arise. The problems where there is a vulnerability that a company doesn't know about the day it's unleashed are called a zero-day exploits or holes and they're usually compromised in a zero-day attack... because the company has had zero days to prepare for the aftermath from a technical and marketing standpoint. These can be people purposely writing a virus or altering code and spreading it. Because a company has little or no warning then it can be catastrophic for the brand.

How is information sharing bad?
The problem is with the channels where information is shared. Most of the highly technical details about a vulnerability do not need to be out in the wild so a passing bot or web crawling search-engine can find them. They need to be behind at least one level of authentication. This makes is more like a deterrent because only the people who would really need to know about something would take the time and effort to go in and look at all of the specifics. Potentially harmful individuals might go in and still compromise a machine or series of systems, but a casual passer-by wouldn't see the info to get any ideas.

Really observant individuals might actually take the time to find a pattern in [poor] programming. For instance Microsoft has been pretty bad about securing Internet Explorer and the way it is interconnected with their operating systems. In the past, when someone logged in with the default Administrator account they could open an e-mail or a webpage and take down their machine with full privileges. Luckily it's a little more difficult for most users now.

On another note Whitepapers can be something of a major problem as well. I downloaded yet another Whitepaper on SQL Injection attacks again today. Nothing new or earth shattering, but it always pays to look to see what I might be up against. I'm always interested in new perspectives.

A thief who can see a whole building and examine it in full detail, might realize it's much easier for them to drive through the wall and bypass the door and window sensors on the alarm system altogether. The same thing applies to Whitepapers and Patch Descriptions on the web. Although much of the media clambers for information about the technical specifics of what happened, it's probably safer if all of that detail isn't on the record completely and in the open. PR and Marketing departments should be the main filter in brand protection. After all, too much self-provided information might actually help in destroying your brand. (Same goes for real hackers.)

Soap Box
If you have a person (or group of people) in your organization or company who really want to support some of the open-source platforms like Java, PHP, Ruby-on-Rails, and so forth they also need to understand the responsibilities that come with maintaining an effectively secure system. Everything needs to be patched and it needs to stay somewhat up-to-date. When companies invest in new ideas and those ideas fail the people who are working on the front lines and in the trenches are the ones that are hit. Most companies can reboot from a failed experiment, but most people can't.

That's all for now.

SQL Injection Attack Precautions

I try to remain perceptive and learn from my own mistakes as well as the mistakes of others. I was reading an article on Dark Reading called "The SQL Injection Disconnection," a fluff article just for clicks that briefly mentions SQL Injection attacks and how hackers are talking about them to the same degree as DDoS attacks.

I was the Web Manager at CertMag.com for a couple of years and noticed a lot of different ways someone could harm a website with poorly written code. We had a forum written in Argentina, another forum product called vBulletin, and had even written our own custom forum at one time. When I took over the technical operations to my surprise there were five extra user accounts in the Microsoft SQL server and one database called "test" in Japanese that contained all sorts of content related to the adult video industry. Needless to say we had been "pwnd." Our server was serving who knew what and we were a sitting duck. Shortly before we switched to our upgraded vBulletin forum we were being injected every 3-4 hours with someone claiming prize.

When I went out to the server farm to my surprise there were no filters on the firewall at all to even try and prevent some of the attacks taking place; an IT oversight. Also the web server was on the DMZ rather than being filtered by our Enterprise Level anti-virus firewall. When I left this was all "fixed."

The problem with the disconnect in regard to SQL Injection isn't that people aren't aware of them or that people aren't taking notes. There is usually a disconnect in human communication. There is no one person who in most situations would ever cover each of the steps to make certain an SQL injection attack was preventable. More often than not the issue falls across several people who all have to do their part in order to make a nice "safe" system to prevent or mitigate SQL Injection attacks. I obtained a special insight into the issue by being lead developer, web manager, network administrator, and IT manager all over the course of about 6 months. It was an eye-opening mind-altering adventure that really made me come up with some very dark options someone could do to take down a server.

What is SQL?
Basically SQL stands for Server Query Language and is used more specifically in communications with database servers. When someone needs to insert into or pull information from a database they more than likely use some form of SQL.

So what is an SQL injection attack?
There are several varieties of SQL injection but they all usually involve someone finding an exploit in a system and loading something into the database. This might be a snippet of code that runs when the page is redrawn (quite common) or an SQL script that either rewrites all of the content in the database with something else or wipes out all of the content altogether. It may also add something to all of the content (eg. pharmaceutical links).

How does this happen?
The more frequent occurrences happen because some off-the-shelf (or open source) application being used was not patched. For example someone downloads and installs a copy of WordPress. A patch is released to fix a known issue with the software, but the person who is responsible for applying the patch does not. Someone then goes on the web and searches for WordPress websites and through trial and error discovers the unpatched site. They apply their code (more than likely downloaded off of the web somewhere) and then the page, site, or database is compromised. I use WordPress as an example, but this happens with almost all open source (public) content management systems at one point or another.

Who is involved or more importantly responsible for the failure?
It depends on the environment of the site being taken over. If the site is corporate, there are several roles that could be responsible for the downfall of the server.

1. Webmaster or IT person: If incorrect server permissions are set (meaning someone has read and write access through something like a search box) then the attacker could take over the website by installing a backdoor. Then they download the passwords for the database from the code they've exploited, now they can create their own.
2. Webmaster or IT person: If separate accounts for the web server application or if the server is executed under a Root account then this could compromise the physical box itself (IT would need to provide a new box or wipe and reinstall in the event of a root kit).
3. DBA, Webmaster, or Web Developer: If the web browsing user account being used to communicate with the database by regular web users has full or elevated database privileges then new tables could be created, existing tables deleted, all data destroyed, or rewritten.
4. Web Developer: If website forms do not filter or clean the inbound content before being inserted into the database the content can be compromised.
5. Web Designer or Web Developer: If the site uses a prebuilt script from someone else's site (open source or shared code) and the code is not inspected, it may contain backdoors which could allow code injection. An example for this might be someone using an AJAX filter to check incoming content before a client submits, but blindly trusting the content. AJAX would insert the content on the check and the site would then be infected.
6. Web Designer or Web Developer: Assuming people will always input proper expected information into a form is bad practice. If someone can inject Javascript into a site they can inject AJAX, backdoors, or worse.
7. CEO, Owner, or Board of Directors: If budget for building a website or maintaining an IT department is cut, low, or non-existent this can lead to poor programming and administrative performance when trying to complete the project on deadline. This can lead to poor planning which can also lead to bad code being written, faulty code being reused, or anyone cutting corners from IT all the way through the web designers.

So this is more of a systemic issue overall since there are several avenues that could lead to a server being exploited. The main issues start at the top in regard to deadlines and fall onto the people who set up the server, the user accounts, the database accounts, and the permissions on the server, the database, and the files for the website. Once this is passed over to the development team, planning and security strategies need to be implemented in order to create a site that functions and does not trust outside users ever.

Things to keep in mind.

1. If a person is able to inject code, but the account doesn't have the proper privileges then the code will not work.
2. If the code is written but restricted to a non-web-accessible directory, the end user cannot execute the code and the site will be a little "safer."
3. Not everyone who attacks your website will use your frontend code. They may not even use a browser. If you're a programmer and checking the validity of an insert, turn of JavaScript and see if you can exploit the site. (eg. If a phone number field for insertion into the database allows something other than a phone number it may throw an error showing your directory structure or bringing down your server or code briefly.)
4. People attack websites for various reasons to name a few: Web real estate (for serving content), prestige ("script kiddies"), competition (corporate or political), religious or idealist reasons (eg. Anti-American), and just because they're bored (hobbyists).
5. If a site is attacked, restoring the database doesn't remove the exploit, only the temporary blemish. If the site is not patched quickly the attackers are given time to experiment and take over more control of the server.

The best way to stop some of these attacks are for everyone involved to do their part completely. The following goes into more technical detail.

Steps to take to secure a server:

1. When the server is being installed or set up, the Web Server needs to have proper directory permissions assigned. There are several articles about this on the web.
2. When the database server is installed it should have its own user account.
   (This is usually the default for MySQL)
3. The administrative account(*NIX) for the web server should not be accessible from the web at all. (No Root SSH) I know it sounds like a no-brainer, but it happens.
4. In regard to MySQL, the administrative account for the database server should not be accessible from the web at all. (No web queries from Root or the main Admin account)
5. Ideally if the site has a backend (CMS) and a frontend then on the backend (which should be secured and NOT in a folder called "Admin" or "controlpanel") the site's interface should use an account that has the ability to select and insert... maybe even delete (not drop). No other permissions should be allowed. On the front-end of the site if there is some reason to insert (like statistical tracking) then THAT user needs to have Insert-Only access to that one specific table or special database. It should not be able to access any other accounts or databases.
6. If the site has no reason to insert from the frontend, then the frontend user needs select-only access.
7. When allowing the site to upload files into the database ALL content must be screened, filtered, and checked. For example just because someone uses a feature like mysql_real_escape_string in PHP, it doesn't mean that all content entered into the database is safe for display on the site. That function simply prevents someone from escaping SQL statements and concatenating their own statement to alter the database itself. They can still write a backdoor when the code is visible on the site again (redisplayed using PHP). Something like strip_tags or a language like Regular Expressions would need to be used to filter code on insertion AS WELL AS on execute.
8. The backend of the website should be as hardened or more-so than the frontend of the site. Many times developers will figure someone who is on the backend has been authenticated, but if someone compromises the system by leaving themselves logged in or by logging in from an unsecure location then the whole site could be destroyed.
9. Ideally no changes to the live website would happen in real time from an interface on the backend. There should be a staging site for maintaining back-ups, a higher level of security, also for code testing to make sure someone outside doesn't see underlying issues with the site while it is under development.
10. Everyone who touches the website and web server needs to be on the same page in regard to safety. Downtime costs money all the way to the top.

That's all for now.