CyanogenMod 9, An Android ROM Without Root

April 12, 2012

By Jon Janego

As a follow up to my blog post in December about custom Android ROMs, i’d like to comment on the news released by the CyanogenMod team last month about their removal of default root access in their upcoming CM9 release.

In a post on their blog  a few weeks ago, the CyanogenMod team announced that they were changing the way that they handle root access on devices using their ROM.  Previous releases of their ROM  have root access enabled by default, as is common in most custom ROMs.  That had the result that any application that requested root access on the device would be granted it.  This is great for some of the power-user applications that are common among the Android modding scene – Titanium Backup is one that comes to mind – but it comes with a significant security risk, since a malicious application installed on the device could have full root access without the user being aware of what it was doing.  The CyanogenMod team acknowledged this in their post, saying, “Shipping root enabled by default to 1,000,000+ devices was a gaping hole“.

What the team is planning to do instead is to implement root access in a selective, user configurable manner.  A device using the ROM has root access disabled by default, but can be configured to only enable it for ADB console access, to enable it only for applications, or to have it enabled across the board.  This type of control leaves it in the hands of the users to choose the level of risk that they are willing to accept.  Obviously, many of the tech-savvy enthusiasts will immediately enable unfettered root access. However, for the large part of the Android community that is only interested in custom ROMs for the customizable interfaces offered by them, this will be a welcome and overdue security protection for them.  Already, it is clear in the comments to the CyanogenMod post that not everyone understands what the risk of root level access is – someone asks the community to “explain this for the liberal arts majors“.

Just so it’s clear, the removal of root level access is strictly at the operating system layer.  Installing a custom ROM onto an Android phone still requires unlocking the bootloader, which on most devices requires running a “jailbreaking” exploit of some sort.  There are a few exceptions to this; the Google Nexus line of phones lets you unlock the bootloader with only some console commands, and HTC and Motorola have also been providing bootloader unlocks to their devices.  Unless it’s coming from the manufacturer, there is always the possibility of some risk when executing unknown code on your device.  But once you’ve gotten to the point of installing the custom ROM, there was the further risk of having root-level access to the operating system easily available, which is the gap that CyanogenMod has closed here.

To me, this indicates that the CyanogenMod team is acknowledging their influence in the community and using it to educate users on good security measures.  Baking in a “secure by default” configuration to the most popular ROM will be good for everyone.  Kudos to them for acknowledging this, and let’s hope that it leads to a more secure Android ecosystem for everyone!

CyanogenMod Logo Used Under a Creative Commons Attribution License

Leave a Comment » | Information Security, Security Industry | Tagged: , | Permalink
Posted by Jon Janego

We’re All Consultants

June 15, 2011

Clients hire Neohapsis for many reasons: our expertise, our perspective as impartial outsiders, and our commitment to executing projects efficiently and expertly are just a few reasons.  But while working with clients, an important sub task that I try to accomplish is to help them change the way they interact with the rest of their business – to get security departments to think and act like consultants.  It’s easy for people working in IT, and those in Security in particular, to get caught up in their day to day activities.  There’s always a new fire to be contained or technical hurdle to overcome.  But while doing so, it’s important to understand how these activities are helping enable the business to continue to meet its overall goals.  The most effective consultants understand their role: to be the trusted advisor.  Internal security professionals can take on this same role within the company.  Their departments have the responsibility of ensuring that risks are appropriately mitigated and that the business can continue to function smoothly in the face of constant external and internal threats.  The core business can be viewed as a client of the security team, who is engaging security for assistance and reassurance that their day-to-day activities aren’t putting the business at a risk.

I’ve been working with one of our clients recently to help one of their business units engage more effectively with the internal security organization.  In the past, the business unit handled many IT activities themselves, acting as a de facto independent IT department.  While they are effective at running their own business, they did not have a security team focusing on their organization, so security concerns were often overlooked.  When I began working with the team, I found out that one of their main complaints with asking the security organization for assistance was lack of responsiveness.  I’ve helped set this organization up for future success by serving as a liaison between these two parts of the business, facilitating better communication on both sides.  The business unit has a central point of contact for security concerns, who can funnel them to the right people in the security organization; and the security organization has someone aware of most of the business unit’s projects and activities, which helps them cut through the confusion that can happen with disparate teams.

Security professionals must be both advisor and enforcer at the same time.  It’s tempting to get caught up in enforcing security for security’s sake – but it is important to remember that the ultimate goal of a security professional must be to help the core business be successful.

Leave a Comment » | Information Security, Neohapsis, Security Industry | Tagged: | Permalink
Posted by Jon Janego

Security Organization Redesign

November 23, 2010

Historically, security organizations have grown up organically, starting 15 – 20 years ago with a single security conscious person who ended up getting tagged with doing the job.  Over the years, that manager asked for new positions, filling a tactical need when issues were presented, creating departments/teams as it made sense. There was no particular plan in place or a long-term strategy. Eventually, you end up with more than a handful of employees and a dysfunctional team. Don’t get me wrong, the team is usually very good at putting out fires and “getting the work done” but, by no means is it robust or optimized.  They typically do not work on the issues that are most important to the company rather these large security groups are playing whack-a-mole with issues and deal with fires as they are presented.  There is no opportunity to get ahead of the game and when the fire is in your area you deal with it the best way you can.  Of course, this can cause inter-personal issues amongst the team members and duplication of efforts, driving even more dysfunction.

As a consultant, it’s easy to say that lack of planning created these problems, but I don’t know many info sec managers who could claim they have a growth plan that goes out 15 years and involves hiring 30-50 new employees.  Most security professionals, for the majority of their careers, are fighting fires

What lessons has Neohapsis learned working with our clients to reorganize their security departments?

Don’t under estimate the angst that will be voiced by the team leaders/managers within the department if they are not included in the decision making process, even if you already know the right decision.

When it comes down to it, there are only so many ways you can design a security organization.  Certain jobs and tasks make sense together.  Certain others require similar skill sets. Technically, you don’t really need to involve many people in the decision if you have someone who knows the culture of the company and has done this before. You could very easily take a CISO and a consultant and develop a new organizational structure and announce it to the CISO’s management team.  You try that, and you’ll be surprised at the uproar about not understanding the nuances of each department and the needs and issues of the individuals.  Though it will take longer, a CISO will find better acceptance with his own management team if they are allowed to go off and work together to propose an org design of their own. It will probably take 30 days and in the end, it will probably look almost identical to what the CISO and consultant would have wanted anyway.  But, the managers’ attitudes will be different and they will have buy-in.  It still doesn’t hurt to get a consultants opinion on the org design, just don’t let your management team think you outsourced their career path.  Even though you could have started your organization change 30 days ago, sometimes it is more about buy-in than being right. That’s a very hard lesson for many security professionals.

Titles are a big deal to security people

Probably the most contentious and politically painful experience, and frankly the biggest complaints from the security team leads and managers, will be coming up with proper titles for the new departments.  As is generally the case in large organizations, there are way too many Directors, VPs, Senior VPs than can honestly be justified by organizational design.  You look over the fence and wonder how everyone in the sales department can be a Senior VP.

What makes this particularly difficult within a security organization is that security professionals by nature view themselves as different or special than everyone else in the organization.  Inevitably, that means corporate HR policy is perceived to be inapplicable to them. The presumption of non-applicability is exactly what security complains about when co-workers ignore security policy. So when company policy dictates a Director title requires X number of direct reports, what do you do with your architecture group that has 5 people with 20 years security experience and no direct reports?  If you don’t title that team as Director’s or better, nobody from the outside will apply for the positions. But if you do, others in the organization will ask why there is a department of 5 people all with Director titles.

In the same vein, titles are routinely viewed by security professionals as a way of bullying co-workers into complying with a particular security policy or decision.  Any perceived lost opportunity to get a title promotion is met with severe angst, no check that…open revolt…even when no salary increase comes with it.

In the end most titles will end up being a mix of corporate policy and what levels in the organization that particular person would have to interact with (eg: need for presumed power). Yes, many feelings will be hurt.

Salaries are all over the map

In similar alignment with titles, salaries are a difficult thing to pin down in the security industry.  Sure you can go to any of a number of surveys and pull an average salary…but often they are for a generic title like “security architect” or “security analyst” or something very specific like “IDS specialist”.  Is your security analyst the same as my security analyst? I can’t tell.  Should a firewall guru get paid the same as a policy guru? Why? Why not?   Eventually you will have to look at existing salaries within the team (obviously), a third party perspective of the market conditions, and the caliber of talent you want applying.  At some level it becomes a throw a number out there and see if you a get nibble approach.

Sounds like too much work…

Are the basic issues outlined above insurmountable?  Of course not.  But they seem to be so minor that many security managers will ignore them and focus on the so called “big picture”.  Little do they know, the big picture was never really in doubt.  It was the little things that were going to give them the biggest head aches and threaten to derail the path to the big picture.

Has this happened in you organization? Did you have a re-org experience to tell? We would love comments.

Leave a Comment » | Risk Management, Security Industry | Permalink
Posted by tylerallison

ThotCon 0×01

March 31, 2010

For those who haven’t heard Greg Ose and I will be presenting at the first annual ThotCon on April 23 in Chicago. If you haven’t gotten your ticket yet you will need to hurry as they are almost gone. Our talk is called Forensic Fail: Malware Kombat and will cover some of the failings of digital forensics. We also have a surprise lined up for the end so if you are in the area you won’t want to miss it.

You can register for the conference at http://www.thotcon.org/registration.html. We hope to see you there.

Leave a Comment » | Exploitation, Information Security, Neohapsis, Security Industry | Permalink
Posted by Cris Neckar

Virtualization: When and where?

November 17, 2009

We often field questions from our clients regarding the risks associated with hypervisor / virtualization technology.  Ultimately the technology is still software, and still faces many of the same challenges any commercial software package faces, but there are definitely some areas worth noting.

The following thoughts are by no means a comprehensive overview of all issues, but they should provide the reader with a general foundation for thinking about virtualization-specific risks.

Generally speaking, virtual environments are not that different than physical environments.  They require much of the same care and feeding, but that’s the rub; most companies don’t do a good job of managing their physical environments, either.  Virtualization can simply make existing issues worse.

For example, if an organization doesn’t have a vulnerability management program that is effective at activities like asset identification, timely patching, maintaining the installed security technologies, change control, and system hardening, than the adoption of virtualization technology usually compounds the problem via increased “server sprawl.”  Systems become even easier to deploy which leads to more systems not being properly managed.

We often see these challenges creep up in a few scenarios:

Testing environments – Teams can get the system up and running very quickly using existing hardware.  Easy and fast…but also dirty. They often don’t take the time to harden the system or bring it up to current patch levels or install required security software.

Even in the scenarios where templates are used, with major OS vendors like Microsoft and RedHat coming out with security fixes on a monthly basis a template even 2 months old is out of date.

Rapid deployment of “utility” servers – Systems that run back-office services like mail servers, print servers, file servers, DNS servers, etc.  Often times nobody really does much custom work on them and because they can no longer be physically seen or “tripped over” in the data center they sometimes fly under the radar.

Development environments – We often see virtualization technology making inroads into companies with developers that need to spin-up and spin-down environments quickly to save time and money.  The same challenges apply; if the systems aren’t maintained (and they often aren’t – developers aren’t usually known for their attention to system administration tasks) they present great targets for the would-be attacker.  Even worse if the developers use sensitive data for testing purposes.  If properly isolated, there is less risk from what we’ve described above but that isolation has to be pretty well enforced and monitoring to really mitigate these risks.

There are also risks associated with vulnerabilities in the technology itself.  The often feared “guest break out” scenario where a virtual machine or “guest” is able to “break out” of it’s jail and take over the host (and therefore, access data in any of the other guests) is a common one, although we haven’t heard of any real-world exploitations of these defects…yet.  (Although the vulnerabilities are starting to become better understood)

There are also concerns about the hopping between security “zones” when it comes to compliance or data segregation requirement.  For example, typically a physical environment has a firewall and other security controls between a webserver and a database server.  In a virtual environment, if they are sharing the same host hardware, you typically can not put a firewall or intrusion detection device or data leakage control between them.  This could violate control mandates found in standards such as PCI in a credit card environment.

Even assuming there are no vulnerabilities in the hypervisor technology that allow for evil network games between hosts, when you house two virtual machines/guests on the same hypervisor/host you often lose the visibility of the network traffic between them.  So if your security relies on restricting or monitoring at the network level, you no longer have that ability.  Some vendors are working on solutions to resolve intra-host communication security but it’s not mature by any means.

Finally, the “many eggs in one basket” concern is still a factor; when you have 10, 20, 40 or more guest machines on a single piece of hardware that’s a lot of potential systems going down should there be a problem.  While the virtualization software vendors will certainly offer high availability scenarios with technology such as VMware’s “VMotion”, redundant hardware, the use of SANs, etc., the cost and complexity adds up fairly fast.  (And as we have seen from some rather nasty SAN failures the past two months, SANs aren’t always as failsafe as we have been lead to believe. You still have backups right?)

While in some situations the benefits of virtualization technology far outweigh the risks, there are certainly situations where existing non-virtualized architectures are better. The trick is finding that line in the midst of the hell mell towards virtualization.

–Tyler

1 Comment | Compliance, Information Security, PCI, Risk Management, Security Industry, Security Tools | Permalink
Posted by tylerallison

Response to Visa’s Chief Enterprise Risk Officer comments on PCI DSS

March 27, 2009

Visa’s Chief Enterprise Risk Officer, Ellen Richey, recently presented at the Visa Security Summit on March 19th. One of the valuable points made in her presentation was defending the value of implementing PCI DSS to protect against data theft. In addition, Ellen Richey spoke about the challenge organizations face, not only becoming compliant, but proactively maintaining compliance, defending against attacks and protecting sensitive information.

Recent compromises of payment processors and merchants that were stated to be PCI compliant have brought criticism to the PCI program. Our views are strongly aligned with the views presented by Ellen Richey. While the current PCI program requires an annual audit, this audit is simply an annual health-check. If you were to view the PCI audit like a state vehicle inspection. Even though at the time of the inspection everything on your car checks out, this does not prevent the situation of days later your brake lights go out. You would still have a valid inspection sticker, but are no longer in compliance with safety requirements. It is the owner’s responsibility to ensure the car is maintained appropriately. Similarly in PCI, it is the company’s responsibility to ensure the effectiveness and maintenance of controls to protect their data in an ongoing manner.

Ellen Richey also mentioned increased collaboration with the payment card industry, merchants and consumers. Collaboration is a key step to implementing the technology and processes necessary to continue reducing fraud and data theft. From a merchant, service provider and payment processor perspective, new technologies and programs will continue to reduce transaction risk, but, today, there are areas where these organizations need to proactively improve. The PCI DSS standard provides guidance around the implementation of controls to protect data. Though in addition to protecting data, merchants, service providers and processors need to proactively address their ability to detect attack and be prepared to respond effectively in the event of a compromise. These are two areas that are not currently adequately addressed by the PCI DSS and are areas where we continue to see organizations lacking.

See the following link to the Remarks by Ellen Richey, Chief Enterprise Risk Officer, Visa Inc. at the Visa Security Summit, March 19, 2009:

http://www.corporate.visa.com/md/dl/documents/downloads/EllenRichey09SummitRemarks.pdf

Leave a Comment » | Compliance, Information Security, PCI, Risk Management, Security Industry | Tagged: , , , | Permalink
Posted by Matthew Miller

Easiest Way into a Company

May 22, 2008

One web page and one email is all you need to gain access to a major corporation’s internal network. Catchy I know, but this is not an exaggeration of what an attacker can do to gain access on their internal network. In culmination with exploiting a few systems on the internal network, they can have free reign. Securing your network infrastructure begins with your employees. I don’t think you will be able to extract any new techniques or any new concepts from this post; however, this should shed some light and acknowledge the importance of safe end user practices as well as securing internal networks and resources.

Much of the governance and regulatory focus is securing your external networks, but what if they get in? We have seen a rise in external vulnerability scans and a decrease in internal/external penetration tests. Did we forget security awareness, defense in depth, network architecture or even the most basic administrative practices? Not surprisingly, it seems corporations are searching for that check mark on their audit and not concerned with actual security.

So what, right?

Even the most security-aware corporations’ are still falling victim to social engineering exercises. Valuable resources which an attacker can use are found in the most trivial places such as social networking sites. Anyone can acquire an adequate employee list in minutes with all the social networking sites such as Linkedin, Facebook, Myspace, etc. From the vast amount of information that can be collected from social networking sites, message boards, and online-groups you can realistically create an organization chart (which helps addressing employees and providing focus for your phishing attack).

Scenario:

Currently, much of the workforce has logged into a VPN or OWA once in their lifetimes. Corporations are offering many services remotely to keep their workers adequately connected. These basic infrastructure items seem the most prone and widespread systems for an attacker to prey on. The first step an attacker makes is basic recon and choosing their targets. Often employees in administrative or sales roles are selected because they tend to login to resources remotely. Next, an attacker will search for an external facing login prompt to clone it to a dummy system with a basic logging to record IP and user credentials. After that, well crafted emails directing unsuspecting users to the dummy login…Done. Simple as that, login credentials obtained within minutes.

How do we protect from here:

There are three fronts that could dramatically improve the outcome of these scenarios. First off, end user training and policies geared towards making employees more aware of possible attacks and best practices. I am not talking about handing a policy to the employee and having them read it either. Second, internal penetrations tests still are viable and will cover a number of areas that will protect from employee attacks as well as minimizing potential sophisticated attacks. This may include additional tasks of hardening of hosts, segregation of networks/assets, and adjusting the appropriate policies. Third, static passwords on critical systems externally facing should be changed to a more secure method such as token authentication. The truth is there is no magic bullet to prevent phishing or social attacks, we will always be combating the human tendency to trust.

Leave a Comment » | Information Security, Neohapsis, Security Industry | Tagged: , | Permalink
Posted by Tony Blakemore

Willful Blindness

April 8, 2008

RSA is always a time of endless meetings and endless discoveries of new products. Walking around the floor this year is incredibly frustrating and enlightening (which I’ll expound on in another post). But with a role entirely dedicated to evaluating products, I keep having conversations that start something like this:

“My new {software/hardware/application/appliance/token} is so cool and revolutionary. It does something you’ve never seen any other product do!”

That person then goes on to describe a feature that is in every product that already exists in the space, most of which are doing whatever the person has described ten times better and more effectively.

Unfortunately, I don’t have the heart to break it to them that their product is, well… lacking. But it always makes me wonder: did this person Google whether the feature existed when they had the blinding flash of inspiration that lead them to develop this (not at all) novel breakthrough?

What interests me most is the idea that they did – if they didn’t bother to do their research, it’s just ignorance. But if they did, and still believe it’s novel, that suggests a willful (though potentially unconscious) blindness to the lack of novelty in their ideas. It’s as though (to use an over-used and somewhat disturbing colloquialism) they have drank the Kool-Aid of their own invention to the point that they’re absolutely unable to see that their product is particularly interesting.

Leave a Comment » | Security Industry | Permalink
Posted by Mike Murray

Follow

Get every new post delivered to your Inbox.