Recently, a Mass injection attack has started that is targeted at SQL
Injection vulnerabilities within application code, with some of these attacks
specifically targeted at ASP and .NET applications in particular. Some of these
attacks are even fully automated and are being launched via botnets and other
infected systems. The source of these attacks and the attack code being used
changes so fast that it is impossible to block at the network level.
SQL Injection and Cross site scripting (XSS) attacks are nothing new. For
several years now Computer Security professionals have been warning of massive
attacks such as these disrupting normal business operations on the Public
Internet. It looks as though this new wave of attacks and new method of
infecting clients with malicious code has started.
The Security Team at MaximumASP has been watching this traffic very closely.
A vast majority of these attacks have been originating from Chinese IP space or
from compromised systems being controlled by Chinese attackers. Much of the data
that is being injected into the databases contains links back to malicious
Javascript code or links directly to Virus/Trojan code which is being hosted
from other infected systems and from systems that reside in the Chinese web
space.
The only way to protect your systems from attacks such as these is to correct
the insecure application code that is allowing these database changes to be
made. This means to validate all client side input to your applications for
type, length, format and range. Client side input is defined as any piece of
data that can be changed or modified by the client. This could be in the form of
HTTP GET, HTTP POST, Javascript, cookies, VIEWSTATE or any other code that
allows a client to input data to your web application.
Some of these recent attacks have even used Google search engines to find
HTTP GET parameters that maybe vulnerable to an injection attack. After these
GET parameters have been collected an automated system attempts to inject code
into these parameters to determine if the application is possibly vulnerable
attack. If the code is vulnerable links to malicious Javascript and virus code
are injected into the database so the application’s clients become infected.
This method of attack is extremely effective since your web server logs never
see the attacking client until the attack takes place. Since they are using
search engines such as Google to find your application’s parameters and code you
never see any type of information-gathering scan taking place before the attack
starts.
One way to protect yourself from the attacks described above is to use HTTP
POST parameters for input instead of GET parameters. POST parameters are just as
vulnerable to injection as GET parameters but the POST parameters will not be as
easily found by things such as search engines or automated scans.
Microsoft provides a free security tool called URLScan that restricts the
types of HTTP requests that Internet Information Services (IIS) will process. It
can be installed on servers running IIS 4.0 or later. URLScan can be configured
to block encoded URL’s, unwanted character sets, extremely long requests as well
as many other useful features that can help protect your system from known and
zero day (unknown) attack vectors. For more information or to download this
Microsoft product please go to the following link:
http://www.microsoft.com/technet/security/tools/urlscan.mspx
If you do not have access to your application’s source code, you can do some
research and ensure the 3rd party application you are using does not have any
known existing vulnerabilities. Many 3rd party applications such as phpBB have
recently been attacked and exploited. Attackers are again using search engines
such as Google to find servers with these vulnerable applications installed and
then launching attacks to deface or inject malicious code.
For more information on protecting yourself from Injection vulnerabilities
please see the following links:
June 4th, mid-afternoon
Post in
In this industry there is a growing and needed focus on security. There is
always the threat of viruses, spyware, worms and hacker attacks. Many people
feel that the larger companies are more vulnerable to attacks than small
businesses. In truth, however, it’s often the other way around.
As a hosting company we do what we can to mitigate network intrusions. We
feel it is our responsibility to offer these services as part of our base
products. I used to get a kick out of companies announcing that they were now
offering SPAM protection on their mail servers. Wouldn’t you do that by default?
That is why MaximumASP invests in its network security using intrusion
prevention systems, enterprise firewalls and virus protection. We literally
block hundreds of thousands of possible attacks every hour coming into our
network.
Many people think that if these tools are in place they are safe from the
possible threat of being hacked. These systems simply protect the network but
there is another side that many people do not think about or address. It is
application security. It is important that people understand that the way an
application is written must also be secure. There are many vulnerabilities on
the application level that we see.
It is impossible for MaximumASP as a hosting company to throw some hardware
network device up and protect from these types of attacks. The only way to
prevent someone from taking advantage of these vulnerabilities is to correct the
issues within the code itself.
Some developers are not aware of these risks. A SQL or Code injection,
according to Wikipedia, is “a technique to introduce (or "inject") code into a
computer program or system by taking advantage of the unenforced and unchecked
assumptions the system makes about its inputs. The purpose of the injected code
is typically to bypass or modify the originally intended functionality of the
program.” The functionality most often bypassed is system security. Cross-site
scripting attacks have been used most recently in phishing schemes.
Here are some tips to help you avoid the potentially disastrous effects of
some of these attacks:
- Never trust any type of client side input. This means forms such as HTTP
POST data, parameters set within a URI (HTTP GET) or cookie information.
- Always filter all un-needed characters from all client side input. This
is especially true for any type of special characters. The following are
characters that should never be allowed to pass in any client side input:
- | (pipe sign)
- & (ampersand sign)
- ; (semicolon sign)
- $ (dollar sign)
- % (percent sign)
- @ (at sign)
- ' (single apostrophe)
- " (quotation mark)
- \' (backslash-escaped apostrophe)
- \" (backslash-escaped quotation mark)
- < > (triangular parenthesis)
- () (parenthesis)
- + (plus sign)
- CR (Carriage return, ASCII 0x0d)
- LF (Line feed, ASCII 0x0a)
- , (comma sign)
- \ (backslash)
- Include the URL encoded value of all characters you are filtering. For
example the ‘ (single apostrophe) is equal to %27 when url encoded. The &
(ampersand sign) is equal to %26 when url encoded. The URL
http://example.com/example.asp?test=test’or%201=1%20-- is the same as
http%3A%2F%2Fexample.com%2Fexample.asp%3Ftest%3Dtest%E2%80%99or%25201%3D1%2520—
- If you are going to pass any authentication information from your client
to server SSL must be used to protect your data.
- Session cookies values should be very long and random. If your session
values are easily guessed it is possible for an attacker to guess the value
and steal or alter a session.
- Authentication information should not be passed within a cookie. Cookies
can be stolen from a client’s system and used to authenticate just like a
username and password.
- Application Session cookies should expire on logout or after a short
period of inactivity.
- Remove all developer notes from production code. Often developers leave
comments and notes within code that could be of use to an attacker. This is
fine during development of an application but before this code is viewable
to the public these notes and comments should be removed.
- Enable custom error messages at your webserver. Custom error pages allow
you to remove the default error pages that could help an attacker learn how
your system works.
- Always protect administrative or management URL’s with authentication
and SSL. Never rely on hard to guess or hidden files or directories to
protect these pages.
- If authentication is required for a web application always require
strong passwords and ensure these passwords are being stored on your system
in a secure method.
Web Application vulnerabilities like SQL injection, cross-site scripting and
brute force attacks are the number 1 way we see customer accounts compromised on
the MaximumASP network. If you follow the simple rules above when developing
your webapplication your chances of becoming compromised are greatly reduced.
October 7th, early evening
Post in
We spent the last few months redesigning our site to make our products and services easier to find and understand. Our new site provides two entry points for visitors, guiding them through the process of learning more, or taking them directly to a specific product of interest.
Please visit our new website at www.maximumasp.com today to learn how our services and new offerings can help you grow your business. Our website will continue to develop over time, incorporating your feedback and suggestions. It is our intention to provide our customers with the most valuable information and resource tools available. Please send feedback regarding the website to marketing@maximumasp.com
June 22nd, late-afternoon
Post in
So why would I be taking time to write a post about us having redundancy and
it actually working right? Well, it's pretty simple really. In the
hosting business, there have been several incidents over the years where all of
the promised redundancies did not work as they should and customers were left
offline for extended periods. Times where transformers blew up and there
was no backup power source, generators sat with their diesel engines locked up
due to no one test firing them on a regular schedule, or UPS systems that were
overloaded and failed as other back up systems attempted to come online.
Last week, it was very satisfying to watch all of the systems we tout here at
MaximumASP work exactly as designed, and you the customer experienced absolutely
no downtime.
On Thursday, June 14th, at approximately 12:15PM EST the utility supplier to
Louisville, Kentucky experienced a significant transformer failure in a
substation that is in the same grid as the MaximumASP data center. This
failure forced other parts of the grid to attempt to carry the load of failed
section. This was too much for the remaining sections to handle and they
began to cascade into a blackout condition. As this reached the MaximumASP
data center, the UPS systems carried the full data center load as the power
bucked 3 times in a 10 second span. As the UPS carried the load, the
Automatic Transfer Switch (ATS) sensed the supply change and fired up the 2
megawatt generator. As the generator synchronized cycles with the existing
electrical load, the ATS shifted power to the generator. We remained in
this state for almost 1 full hour, until power was restored from the utility.
Less than 1 hour after power was restored by the utility, the transformer
failed again. Like clockwork, the UPS's, ATS and generator engaged, and we
switched the generator to manual mode allowing us to run it continuously until
we were confident that the problem had been completely rectified. We
actually ran the unit until 6PM EST that evening making our own power, and
allowing the diesel refueling trucks to come in and replenish the fuel tanks as
the generator was running.
All is normalized now, but I thought that some of you might be interested in
all that went on behind the scenes on Thursday as your servers, switches, SANS,
and disk arrays hummed along without skipping a beat. It is certainly nice
to see these complex support systems work as they were designed to, and
hopefully this provides further reassurance that you made the right choice in
selecting MaximumASP as your hosting provider.
June 18th, late-afternoon
Pardon our dust as we roll out a new look for the weblog and our public site
June 10th, dinner time