Showing posts with label hacker. Show all posts
Showing posts with label hacker. 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, January 11, 2013

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.

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.