Showing posts with label Database Management. Show all posts
Showing posts with label Database Management. Show all posts

Friday, March 27, 2015

What types of things happen when a web server gets hacked.

These are just some of the things, and it really depends on the server, the type of data being stored, whether it’s in a server farm, or if it’s actually at a facility like an office. The outcome for each of these can be massively bad depending on a variety of factors, because after all, a server being hacked is never really a good thing, unless you’re the one doing the hacking, and that’s only if you’re a black hat.

On most web servers there is code, acres and acres of code. If the server is using a dynamic language for page creation, like PHP or ASP, then there are likely database connections at play. These databases likely contain the information someone would normally expect to find on such a server. There are the usual types of information, username, password, name, e-mail address, etc. If the server hosts a medical site, it might have personal information, all of which should be encrypted where it is stored. If the server were for controlling something else, then it would likely have access to that something, like a web-controlled automation system for instance.

Why would it be hacked?
Different information has different values on the black market. Most of the usernames and passwords, and e-mail addresses have value because they can be used on other servers in order to gain access to something else (example): Website A is compromised, Twitter account is hacked with the same credentials. Things like Social Security numbers can be used to not only try to impersonate someone’s identity, but they can also be used to defraud the Social Security system with new fake accounts. Medical information is probably only beneficial to someone who would care about it, depending on the target. So if it contained medical info about a person who was in politics it might have a value if they had certain medical conditions that weren't disclosed to the public, but if it’s about Grandma’s arthritis, probably not; unless they’re going to use it for spamming or phishing Grandma for pain meds which could theoretically happen.

If the server’s housed in a server farm, it’s likely on a restricted network. Likely it doesn’t talk to anything else on that restricted network. While it could be used to pivot if the attacker gained access to things outside of the web server, or the website, it’s likely not going to happen. Usually what happens with a web server in a place like a server farm is hacked, it’s immediately used for its bandwidth in that prominent place: new databases are created, new websites hosted, traffic diverted, data and server farms have something everyone wants, real estate. If the server is locked down to prevent those things, then only the website is hacked, and this could allow an attacker to use the website to collect information on the users for forwarding to the attacker's own servers, or they could serve malware or viruses from the compromised server to infect workstations. If the website has write access for the web server, then files can be injected and a back door created. Then the user can read the databases with the site's permitted database connections. If the account the website runs under on the computer has enough permissions, then the user can do other things to the server like make more servers, turn on services on the server that aren't currently running and install things like proxy servers, VPN systems, and host other things on the box like voice communications, video hosting, a lot of possible options. 

If the server is in an office there are a variety of other things that can become compromised. If the site itself is only compromised, then the system would have the same things that could happen as in a server farm. If the user gains access to the server itself, and that server is also a domain controller and the admins use the same username “admin” with the same password, then the users can try to login to that server to control the domain, the e-mail accounts, the domain routing, and the website. On a domain controller, now they can collect anything within the network as traffic that's not encrypted. If they setup a man-in-the-middle attack they can actually steal the encrypted data too. They can also leech information from the server as well as try to use it to pivot attack other systems on the same network if it's not a domain controller. With enough access they can install applications and still perform the data mining, then spoof packets and routes and still take traffic meant for elsewhere. It really depends on where the box is on the network infrastructure.

If the server is locked down so that the user is restricted to the website and database by itself, the user can still create new websites and databases. There is also the issue of the external IP for the network being blocked if the server is used to send spam or phishing e-mails; e-mails can be sent from web servers. Also there is the issue of bandwidth as more access to the server can bring down a network.

How to prevent a hack?
Management need to contact their IT people and ask them about the permissions, restrictions, and infrastructures in place on the network; make sure they're familiar with all of the risks at hand. Web designers need to contact the webmasters if they think there is an issue. If a different company hosts the website, then check their procedures, if they don't seem "secure" then move the site to a better host.

Friday, March 15, 2013

Web Form Security: Reasons behind online attacks

Why am I being hacked?

To really know what you're dealing with you have to get inside the head of a script kiddie or a hacker if you want to actually "secure" your systems. Since there are so many factors, many of which that are usually out of the control of most individuals, I'm using the phrase "secure" loosely. From a web or online security standpoint I've worked with several companies over the years, usually in a post-attack analysis, trying to determine what happened, how to recover (if possible) and how to harden against the attack again. Companies often do not spend money on security before an attack and say things like "It's never happened before." or "Why would they target us?" or "No we haven't been hacked." when in actuality they have.

There are several reasons why someone or a group might want to take over a webpage, a blog, a webserver, or a MySQL database server. Here are a few of the reasons I've experienced myself for why someone would exploit a site or page.

Web Real Estate

Mission critical systems that rely on a database need to be secured. Not only is there the risk of someone data mining a database of personal data, but there are also risks for the database server that contains the database and/or the website servers that host the site receiving or displaying the data. One of the ways people can cause havoc on a server is by using an SQL Injection Attack. In November of last year I wrote a post about SQL Injection Attack Precautions. It talks about who's ultimately responsible in terms of securing a system since usually in most cases the blame for an attack is spread across several people.

How could web real estate be at risk? If someone looks at a form for a search, they can assume that it is connected to some sort of database. Blindly hacking at the form, they will not be able to tell if the database is a PHP array, an SQL database, or an XML file until they receive an [un]intended response. Through passing unexpected characters into the form they can potentially break the form, cause a stack overflow on the server (effectively crashing it), or break the application that is handling the form. Something like putting a server into an endless loop can bring a server to its digital knees. This usually involves  passing escape characters to add extra slashes, closing quotes (single and double), programming language terminations, or by passing HTML code into the form. Passing empty form fields can break some forms, while others can be broken by simply disabling Javascript.

When a web form is broken it returns valuable information to an attacker about the structure of the system, the type of server services running, and the quality of the code on the system itself. In my experience most websites with easily hackable code are frequented more heavily by would-be attackers and script kiddies than sites that return no errors or information to an attacker. Since most modern web servers are hosted in server farms with high bandwidth connections, to outside attackers it will more than likely be the same payoff for hacking a sophisticated site versus a simple site. They both offer the similar  bandwidth and server resources and they are usually designed to be managed remotely so there is little chance the Administrator will spot the attack. If an attacker sees an increased level of security, they're less likely to attack a server simply because their efforts will be undone much more quickly or they'll be caught because they will have to try harder.

Web "Street Cred"

Just like the real world, online hackers need notoriety. That being said, there are individuals in the hacking community who love a challenge. Some websites such as tech blogs, newspapers, social media accounts, video streaming websites and social networks are going to be more at risk for someone trying to replace content or services simply to make a name for themselves. There are far more people looking to become famous from a hacking attempt than there are people looking to steal information and sell it on some black market. The skill sets required for guessing a password to take over a page vs. actually deriving unencrypted usable data that can be sold are night and day different. There are quite a few apps in the open that will crack or guess a password. There aren't very many individuals that can successfully write a root kit. Sometimes an attacker can simply guess the password to get in and look at the code. The guys who do it for a living will not be bragging about it unless they're making a sales pitch for paying work behind closed doors. You will see script kiddies doing it so they can make a name for themselves (think Anonymous).

Political Reasons

Some "groups" like Anonymous take pride in bringing down sites and exploiting pages and accounts with opposing views or showing companies and corporate conglomerates that they have glaringly open holes in their security. Search for "Anonymous Hacks Burger King Twitter" on Google. While there likely are real hackers that operate under the "Anonymous" moniker, most of the exploits I've seen are pretty amateurish. If Anonymous were really a serious group there would more than likely be now more online trading (or stock market for that matter).

Bad SEO

Some people just want more links for their own sites. These people can be spammers and sometimes they're legitimate businesses that have paid for a service that they themselves weren't quite sure on. In the past there was a practice of spamdexing where a website listed in major directories or topics pertaining to the contents of the site would be picked up and rewarded by the search engines. Fake sites and phishing sites soon caught onto this. The search engines changed their policies, but sometimes in countries throughout the world word doesn't travel so fast through translation. Many "SEO specialists" mention that they can get a site listed through link sharing. This is more than likely how if they are overseas.

An example of spam-dexing from the Search Engine Journal (3/12/2013)
"There are many sites with spam on their sites that can’t see the links that they are showing where you couldn’t see unless you went into the code.  Google bot shows that a Top 50 University has “cheap viagra pills” on their main page."
To find out which one you can search for University Viagra on Google.

Data Capturing including Credit Cards and Social Security Numbers

Some people are a little more secretive about their exploits and they will hide code on a system to take advantage of web visitors and traffic. This may take the form of database copying or replication (if the site is storing e-mail addresses, credit card numbers, or sensitive data). The attackers may send copies of the real submissions to their own server. They may monitor statistics from the site (for a competitor). Some attackers inject malware into the code so they can infect user computers. In a previous post I talk about the hacking of clothing manufacturer Calvin Klein and how I started receiving SPAM from the newly created e-mail address I used for them the day I signed up. Calvin Klein of course denied any knowledge of this or interest in rectifying the issue.

Additionally when someone is actually capturing all information to a system on the system itself, any information passed is vulnerable. This includes Social Security Numbers, Credit Card numbers, and anything else that may be submitted (student ID numbers). Depending on the type of site, this is a huge risk to clients, customers, and worse... the brand in terms of PR backlash.

Bot Net  

Web servers can be powerful, plentiful machines just ripe for harvesting. Located on massive connections there is very little that can be done to track multiple machines requesting orders from the controlling system (the requests can look like normal web traffic in a packet filter). In numbers, compromised machines can become a powerful collective. Why not run an application in the background on someone else's web server to make it control countless drones while it goes on serving a webpage? This does actually happen. Usually the attacker will install something called a "root kit" which is an app or framework that is undetectable that runs in the background. This allows them to control the server and exploit the bandwidth and resources available to the server. The web page may be up and running and unchanged, so the owner usually won't find out until there is a knock at the door because the machine was used to exploit someone else's, it was controlling countless other machines or worse the website goes down because the ISP pulled the plug at the request of a government or after their own inspection and determination of high traffic. Once a root kit is installed it is easier to use a new machine than it is to clean off the root kit. Without examination the exploit the attacker used may still be in place. It would only be a matter of time before the attack exploited the machine again.

So what are the real risks?

Most of the time the attacks come down to bad password management policies, or use of an unsafe network by someone to log into a website control panel or administration panel (think Starbucks). Every once in a while someone is hit with an XSS attack or a/an [My]SQL injection attack, but this requires someone actually trying to hack the server. Passwords can be captured in open places like airports, coffee shops, hotels, vacation resorts, cruise ships, and on any other unsecured WiFi networks with free applications on the web. Be smart and use strong passwords longer than 10 characters in safe / secure locations and more than likely there will be no issues.

Friday, November 9, 2012

Dark Reading Mailing List Compromised?

So I try to stay on top of the tech news in regard to exploits and security. One of the sites that I subscribe to is Dark Reading. It's more of a main stream sort of whitepaper delivery system for vendors but every once in a while I find something useful. They usually provide links to the real content and I go in search of something more informative on the topic, but they're a good starting point (unlike the 2600 Hacker Quarterly who publishes exploits directly on their pages).

As a hacker I'm paranoid about a lot of things. I see the system and I see all of the nuts, bolts, cables, users, and the complete infrastructure all at once. It's sort of a mind-numbingly overwhelming gift for information overload.

While I was Web Manager working at CertMag.com one of my responsibilities was configuring, securing, and learning the ins and outs of our StrongMail MTA and maintaining our mailing lists locally (amongst a bazillion other things). We had an offsite service that "maintained" our list, but there were a few ways that the list(s) could be captured by savvy listeners when we were submitting it or receiving it over non-secure or non-encrypted channels (think Wireshark). At the time we employed the services of Hallmark Data Systems, and they had several procedures and securities in place to make sure our list was "safe." Basically from what I gathered it was an offline database on an AS 400, although I think they were considering integrating some aspects online (for a fee of course).

We weren't controlling any sensitive information, unless you count names, addresses, titles, and email addresses as sensitive (I guess altogether it could be something because it was a loosely targeted list if you're into marketing). For the most part once that information was sent to the database house it was out of our hands and pretty much would never be seen again in its complete state unless we pulled an audit query. They managed providing the list to the printer that distributed the print versions of our publications and they would also email back to us a queried list of names and email addresses only matching certain criteria per publication (I think this was eventually accessible online after a while come to think of it). They would then update the lists for people who had opted out or unsubscribed for legal and advertising audit purposes. In short it's a big technical inefficient process.

Jump ahead 5 Years later, one of the major issues with web subscriptions today or services where you expect to get something for providing a little personal information is getting tons of stuff that you don't want. So how can you tell whether the unsolicited email you're receiving is random spam, from a sold list, from a compromised web form or from a hacked database? One of the ways I combat this myself is I create a custom email address for every site that I'm registered on. I think right now I'm up to 400 or something ridiculous like that. It's usually nothing anyone would guess... acronyms but not random gibberish. When I register for a new site, I give them a new address. If an email looks like a legitimate pass with something in the footer like "You're receiving this message because you subscribed for Dark Reading," then I know they sold it or it's a sister publication. By law any legitimate sending service is required to provide an opt-out.  Also when someone opts out there is a certain amount of time to stop sending that person messages or the fines could be steep (severely).

So today I'm going through my emails and I see a message to my Dark Reading account titled "Re:Re: sending servers /.../." Out of curiosity I open the message on a *NIX machine and it's an ad for "Highly Stable and Secure Bulk Email Servers for Email Marketing." Sort of ironic. The company that I subscribed with was exploited by a company that provides "Highly Stable and Secure Bulk Email" services that are apparently more secure than my subscriptions own service?

So out comes the magnifying glass. A reverse look-up of the sending server's IP address with ARIN.net goes back to 173.192.141.86 at SoftLayer in Texas. No domain information was provided on the handshake with my email server, so it's no doubt a compromised machine running a root kit or a slave app. The return-path goes to an email address at fillmore.com which is owned by Fillmore Real Estate in Brooklyn. It was more than likely either hacked or they could just be a bounce back victim of a spam reply at which point they're not even involved.

So I dig a little deeper.

There's an email address in the links only(no websites) that goes to 21cn.com. If you're familiar with ccTLDs or country-code Top Level Domains then you'll recognize "cn" as China. This is a .com TLD, so on a hunch I look up the domain in APNIC.net... returned no results, Network Solutions... no results, Ripe.net... no results, but Internic.net came back with very little information and a different whois server for the domain at whois.35.com. So I plug that in and found the registrant to be:

     21cn corporation limited domainmanage@21cn.com +86.2085264358 +86.2085265827
     21CN Corporation Limited
     2F,NO.52 Liuyunwu street,Tiyu Rd,East,Tianhe,Guangzhou,China
     Guangzhou,Guangdong,CN 510620

So apparently the Dark Reading website's database, or their database management service, or some machine at Dark Reading's HQ was "hacked" and their list stolen, because I've not received any bulk emails on that list where I saw any other "subscribers," like an accidental broadcast with everyone in the CC field or some rookie mistake like that. There is the chance someone might have run a cycler to guess my own email address, but it's unlikely since I have a lot more email addresses that begin with letters other than "D" prior. Since it's only been provided to Dark Reading and it's a receive-only alias account I know it is not an issue on my end because that address isn't stored anywhere. If someone gleaned it from my mail server on the off chance they were listening to the data center in California then I'm sure I would receive a lot more of these to all of my email addresses (aliases) on record.  If they're using a service like we were it also might have been compromised in the transfer between Dark Reading and their database managing service.

From a PR standpoint, it always looks bad when a website that publishes info about online security experts might not have an IT staff that implements what they read in their own material. Okay that might be a little harsh considering there are more important things to do like replace faulty mice or tell people their company provided laptop no longer works because they've dropped it one too many times, but I can almost guarantee I probably won't read about it in Dark Reading.

That's all for now.