Drupal Security Best Practices Document

This is just a quick post to point to a great guide on Drupal security best practices that we found recently. 

It was written for the Canadian government and is licensed under the Open Government License platform. 

The content is great and it is available free of charge. 

If your organization uses Drupal, you should definitely check it out and apply the guidance as a baseline! 

Pointers for Mobile App Certificate Pinning

We often get questions about Certificate Pinning in mobile applications. Many clients find the issue difficult to explain to other teams.

You can find really great write ups, and an excellent set of source code examples for fixing this issue – as well as explaining it – at this OWASP.org site.

At a super high level though, you basically want your mobile application to validate the SSL certificate of the specific server(s) that you want it to talk to, and REJECT any certificates that do not match the intended server certificate – REGARDLESS of whether or not the underlying OS trusts the alternative certificate.

This will go a long way to hardening the SSL communication streams between the app and the server, and will not permit easy interception or man-in-the-middle attacks via a network provider or hostile proxy server.

Updates to the app source code are needed to mitigate the issue, and you may need to update apps in the app stores, depending on the way your app is delivered.

As always, if you work with MSI on mobile app security reviews or application-specific penetration testing, we would be happy to demonstrate the attacks and suggested mitigations for any identified issue. Just let us know if you would like assistance.

As always, thanks for reading and I hope your team finds this useful.

Sometimes, It Happens…

Sometimes things fail in interesting ways. Sometimes they fail in dangerous ways. Occasionally, things fail in ways that you simply can’t predict and that are astounding.

In a recent assessment of a consumer device in our lab, we found the usual host of vulnerabilities that we have come to expect in Internet of Things (IoT) devices. But, while testing this particular device, which is also tied to a cloud offering for backup and centralization of data – I never would have predicted that a local device would have a full bi-directional trust with a virtual instance in the cloud.

Popping the local device was easy. It had an easy to compromise “hidden” TCP port for telnet. It took my brute force tool only moments to find a default login and password credential set. That’s pretty usual with IoT devices.

But, once I started poking around inside the device, it quickly became apparent that the device configuration was such that it tried to stay continually connected to a VM instance in the “cloud storage and synchronization” environment associated with the device and vendor. How strong was the trust? The local device had mount points on the remote machine and both systems had full trust to each other via a telnet connection. From the local machine, simply telnet to the remote machine on the right port, and without credential check, you have a shell inside the cloud. Not good…

But, as clear of a failure as the scenario above was, the rabbit hole went deeper. From the cloud VM, you could see thousands of other VMs in the hosted cloud environment. Connect from the VM to another, and you need the default credentials again, but, no sweat, they work and work and work…

So, from brute force compromise of a local piece of consumer hardware to a compromise of thousands of cloud instance VMs in less than 30 minutes. Ugh… 

Oh yeah, remember that storage centralization thing? Yep, default credentials will easily let you look through the centralized files on all those cloud VMs. Double ugh…

Remember, I said bi-directional? Yes, indeed, a connection from a VM to an end-point IoT device also works with assumed trust, and you get a shell on a device with local network visibility. Now is the time you kinda get sick to your stomach…

These kinds of scenarios are becoming more common as new IoT devices get introduced into our lives. Yes, the manufacturer has been advised, but, closing the holes will take a complete redesign of the product. The moral of this story is to pay careful attention to IoT devices. Ask questions. Audit. Assess. Test. There are a lot of bad security decisions being made out there in the IoT marketplace, especially around consumer products. Buyer beware!

Getting Smart with Mobile App GeoLocation to Fight Fraud

If your mobile application includes purchases with credit cards, and a pickup of the merchandise, then you should pay attention to this.

Recently, in our testing lab and during an intelligence engagement, we identified a fraud mechanism where stolen credit cards were being used via the mobile app in question, to fraudulently purchase goods. In fact, the attackers were selling the purchase of the goods as a service on auction and market sites on the dark web.

The scam works like this. The bad guys have stolen credit cards (track data, likely from dumps), which they use to make a purchase for their client remotely. The bad guys use their stolen track data as a card not present transaction, which is standard for mobile apps. The bad guys have access to huge numbers of stolen cards, so they can burn them at a substantial rate without impacting their inventory to a large extent. The bad guy’s customer spends $25 in bitcoins to get up to $100 in merchandise. The bad guy takes the order from the dark net, uses the mobile app to place the order, and then delivers the receipt and/or pickup information to the bad guys customer. The customer then walks into the retailer and shows the receipt for their mobile order, picking up the merchandise and leaving.

The bad guy gets paid via the bitcoins. For them, this is an extremely low risk way to convert stolen credit card info to cash. It is significantly less risky for them than doing physical card replication, ATM use or other conversion methods that have a requirement for physical interaction.

The bad guy’s customer gets paid by picking up the merchandise. They get up to $100 value for a cost of $25. They take on some risk, but if performed properly, the scam is low risk to them, or so they believe. In the odd event, they simply leave the store after making their demands for satisfaction. There is little risk of arrest or prosecution, it would seem, especially at the low rate of $100 – or at least that was how the bad guy was pitching it to their prospective customers…

The credit card issuer or the merchant gets stuck. They are out the merchandise and/or the money, depending on their location in the world, and the merchant agreement/charge back/PCI compliance issues they face.

Understanding the fraud and motivations of the bad guys is critical for securing the systems in play. Organizations could up their validation techniques and vigilance for mobile orders. They could add additional fraudulent transaction heuristics to their capability. They could also implement geo-location on the mobile apps as a control – i.e.. If the order is being physically placed on a device in Ukraine, and pick up is in New York, there is a higher level of risk associated with that transaction. Identifying ways  to leverage the sensors and data points from a mobile device, and rolling it into fraud detection heuristics and machine learning analytics is the next wave of security for some of these applications. We are pleased to be helping clients get there…

To hear more about modern fraud techniques, application security testing or targeted threat intelligence like what we discussed above, drop us a line (info at microsolved dot com) or via Twitter (@lbhuston). We look forward to discussing it with your team.

Hosting Providers Matter as Business Partners

Hosting providers seem to be an often overlooked exposure area for many small and mid-size organizations. In the last several weeks, as we have been growing the use of our passive assessment platform for supply chain assessments, we have identified several instances where the web site hosting company (or design/development company) is among the weakest links. Likely, this is due to the idea that these services are commodities and they are among the first areas where organizations look to lower costs.

The fall out of that issue, though, can be problematic. In some cases, organizations are finding themselves doing business with hosting providers who reduce their operational costs by failing to invest in information security.* Here are just a few of the most significant issues that we have seen in this space:
  • “PCI accredited” checkout pages hosted on the same server as other sites that are clearly under the control of an attacker
  • Exposed applications and services with default credentials on the same systems used to host web sites belonging to critical infrastructure organizations
  • Dangerous service exposures on hosted systems
  • Malware infested hosting provider ad pages, linked to hundreds or thousands of their client sites hosted with them
  • Poorly managed encryption that impacts hundreds or thousands of their hosted customer sites
  • An interesting correlation of blacklisted host density to geographic location and the targeted verticals that some hosting providers sell to
  • Pornography being distributed from the same physical and logical servers as traditional businesses and critical infrastructure organizations
  • A clear lack of DoS protection or monitoring
  • A clear lack of detection, investigation, incident response and recovery maturity on the part of many of the vendors 
It is very important that organizations realize that today, much of your risk extends well beyond the network and architectures under your direct control. Partners, and especially hosting companies and cloud providers, are part of your data footprint. They can represent significant portions of your risk, and yet, are areas where you may have very limited control. 
 
If you would like to learn more about using our passive assessment platform and our vendor supply chain security services to help you identify, manage and reduce your risk – please give us a call (614-351-1237) or drop us a line (info /at/ MicroSolved /dot/ com). We’d love to walk you through some of the findings we have identified and share some of the insights we have gleaned from our analysis.
 
Until next time, thanks for reading and stay safe out there!
 
*Caveat: This should not be taken that information security is correlated with cost. We have seen plenty of “high end”, high cost hosting companies with very poor security practices. The inverse is also true. Validation is the key…

Clients Finding New Ways to Leverage MSI Testing Labs

Just a reminder that MSI testing labs are seeing a LOT more usage lately. If you haven’t heard about some of the work we do in the labs, check it out here.

One of the ways that new clients are leveraging the labs is to have us mock up changes to their environments or new applications in HoneyPoint and publish them out to the web. We then monitor those fake implementations and measure the ways that attackers, malware and Internet background radiation interacts with them.

The clients use these insights to identify areas to focus on in their security testing, risk management and monitoring. A few clients have even done A/B testing using this approach, looking for the differences in risk and threat exposures via different options for deployment or development.

Let us know if you would like to discuss such an approach. The labs are a quickly growing and very powerful part of the many services and capabilities that we offer our clients around the world! 

Podcast Episode 7 Now Available

The newest version of the State of Security Podcast is now available. You can go the main page here, or listen by clicking on the embedded player below.

This episode features:

This episode is a great interview with Mark “Phork” Carey. We riff on the future of technology & infosec, how machine learning might impact security in the long term, what it was like to build the application-centric web with Sun, lessons learned from decades of hardware hacking and whole lot more! The short for this month is with @pophop, so check out what the self-proclaimed “elder geek” has to say as he spreads some wisdom. Let us know what you think and send in ideas for other folks you would like to hear on the podcast. 

 

Windows Server 2003 – End of Life

Windows Server 2003 has officially reached it’s end-of-life date. Does this mean that all of your Windows Server 2003 servers will be hacked on July 16th? Probably not. However, it is worthwhile to ensure that your organization has a plan in place to migrate all of your applications and services off of this legacy operating system. This is especially true if you have any Windows Server 2003 systems that are exposed to the internet. It is only a matter of time until a new vulnerability is discovered that affects this operating system.

As a former Windows Systems Administrator, I understand how difficult it can be to convince an application owner to invest the time and resources into migrating a system or service to a new operating system. Despite the fact that these systems have a heightened risk of being compromised, it’s very possible that your organization doesn’t have the financial resources to migrate your applications and services to a new operating system. You’re not alone. I found over 1.3 million servers running IIS 6.0 in Shodan. Over 688,000 of these servers are in the United States. However, there are still ways to reduce the risk of hosting these legacy operating systems until a migration plan is put into place.

A few ways to reduce the risk of hosting an application on a legacy operating system are:

  • Discover and document – You can’t protect a system if you don’t know it exists. Take some time to identify and document all of the legacy and unsupported operating systems in your network.
  • Learn about the application – Take some time to learn some details about the application. Is it still even being accessed? Who uses it? Why is it still hosted on an unsupported operating system? Are there other options available?
  • Educate the business users – If financial resources are an issue, take some time to explain the risks of hosting this application to the business users. Once they gain an understanding of the risk associated with hosting their application on a legacy OS, they can help secure funding to ensure that the application is upgraded.
  • Isolate – Segmenting the legacy system can reduce the risk that it is accessed by an attacker. It also can decrease the likelihood that a compromise of the legacy system will spread to other servers.
  • Update and secure – Install all available patches and updates. Not only for the operating system, but the hosted applications as well.
  • Perform thorough log analysis – Implement some sort of centralized logging platform to ensure you have the ability to detect any anomalies that occur within these systems.
  • Plan for the worst – Be prepared. Have a plan in place for responding to an incident involving these systems.

State Of Security Podcast Episode 6

The 6th episode of the State Of Security podcast is now available. 

This time around, we get one of the most personal episodes yet – a behind the curtain look of what it is like to manage the incident response team in a highly publicized breach, under strict regulation, for 6+ months. The insights here and examinations of the personal and professional impacts are profound. We also close this episode with our new “shorts” segment – this time with an insight from @sempf. Thanks for listening, and as always, let us know what you think on Twitter – @microsolved or @lbhuston. Stay safe out there! 

You can subscribe to the podcast in iTunes or via Podbean. You can also listen below.

Are you hacking!? There’s no hacking in baseball!

My Dad called me earlier this week to ask if I heard about the FBI’s investigation of the St. Louis Cardinals. My initial reaction was that the investigation must be related to some sort of steroid scandal or gambling allegations. I was wrong. The Cardinals are being investigated for allegedly hacking into the network of a rival team to steal confidential information. Could the same team that my Grandparents took me to see play as a kid really be responsible for this crime?

After I had time to read a few articles about the alleged hack, I called my Dad back. He immediately asked me if the Astros could have prevented it. From what I have read, this issue could have been prevented (or at least detected) by implementing a few basic information security controls around the Astros’ proprietary application. Unfortunately, it appears the attack was not discovered until confidential information was leaked onto a pastebin site.

The aforementioned controls include but are not limited to:

  1. Change passwords on a regular basis – It has been alleged that Astros system was accessed by using the same password that was used when a similar system was deployed within the St. Louis Cardinals’ network. Passwords should be changed on a regular basis.
  2. Do not share passwords between individuals – Despite the fact that creating separate usernames and passwords for each individual with access to a system can be inconvenient, it reduces a lot of risk associated with deploying an application. For example, if each member of the Astros front office was required to have a separate password to their proprietary application, the Cardinals staff would not have been able to successfully use the legacy password from when the application was deployed in St. Louis. The Astros would also have gained the ability to log and track each individual user’s actions within the application.
  3. Review logs for anomalies on a regular basis – Most likely, the Astros were not reviewing any kind of security logs surrounding this application. If they were, they might have noticed failed login attempts into the application prior to the Cardinals’ alleged successful attempt. They also might have noticed that the application was accessed by an unknown or suspicious IP address.
  4. Leverage the use of honeypot technology – By implementing HoneyPot technology, the Astros could have deployed a fake version of this application. This could have allowed them to detect suspicious activity from within their network prior to the attackers gaining access to their confidential information. This strategy could have included leveraging MSI’s HoneyPoint Security Server to stand up a fake version of their proprietary application along with deploying a variety of fake documents within the Astros’ network. If an attacker accessed the fake application or document, the Astros would have been provided with actionable intelligence which could have allowed them to prevent the breach of one of their critical systems.
  5. Do not expose unnecessary applications or services to the internet – At this point, I do not know whether or not the Astros deployed this system within their internal network or exposed it to the internet. Either way, it’s always important to consider whether or not it is necessary to expose a system or service to the internet. Something as simple as requiring a VPN to access an application can go a long way to securing the confidential data.
  6. Leverage the use of network segmentation or IP address filtering – If the application was deployed from within the Astros internal network, was it necessary that all internal systems had access to the application? It’s always worthwhile to limit network access to a particular system or network segment as much as possible.

Honestly, I hope these allegations aren’t true. I have fond memories of watching the Cardinals win the World Series in 2006 and 2011. I would really hate to see those victories tarnished by the actions of a few individuals. However, it’s important that we all learn a lesson from this..whether it’s your email or favorite team’s playbook…don’t overlook the basic steps when attempting to secure confidential information.