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.

New "Microsoft" Phising Scam

Today I received a phone call (Out of Area, Unlisted) from a guy with an Indian accent. He claimed to be from Microsoft and told me that they had received a message from my computer saying it was infected.

So I immediately replied:

"How did you get this phone number?"

His response:

"Because your ISP told us it was you and that it was your computer and when you register for Internet service they provide that information to us."

My retort (BSing of course):

"So Microsoft (someone who I haven't purchased anything from for 4 years) said my computer is infected, and you got my home phone number for my business account Internet provider?"

The guy hung up. I'm sure the rest of the phishing scam is that they are going to ask you to download something and install it to make sure your system is "clean." I myself am running an enterprise level anti-virus firewall (with subscriptions) and have AV installed on all of my Windows workstations and Virtual Machines.

According to Wikipedia:

Phishing is the act of attempting to acquire information such as usernames, passwords, and credit card details (and sometimes, indirectly, money) by masquerading as a trustworthy entity in an electronic communication.

The term "Phishing" first came about because a telephone or phone was used to fish for information. So the "PH" from "Phone" replaced the "F" in fish. Despite the Wikipedia entry, it is actually a part of "Phreaking" and not just possibly due to phreaking because a lot of phone privilege escalation involves a question and answer session with the phone network provider. There are all sorts of articles about Phishing and Phreaking in the older issues of the 2600 Hacker Quarterly now available at Amazon as an Kindle magazine subscription.

If you have a Mac / Linux based machine only, I probably don't have to say this but you can tell them you know they're full of it. If you have a "PC," Microsoft will NEVER contact you to tell you that you have a virus. They as a company, unless you're paying for some security service directly from them, would never take the huge effort to police the Internet and tell everyone that they're sending out a virus. That's not one of their core business motives.

There are all sorts of things that can be downloaded knowingly or unknowingly off of the Internet that contain back doors (where people can get into your machine), viruses (that give out information), slave systems (where people can make your computer work for them), and root kits (so your anti-virus applications that you are hopefully using can not detect of remove them).


Remember to NEVER provide any personally identifiable information about yourself over the phone to ANYONE who calls you unprompted (unless you are expecting the call).

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.