Detecting Evil: Network Security Monitoring

Trying to clear out the backlog of posts in my Drafts folder and this one is long over due...

News Headlines

These are just a couple of the new stories that caught my eye [in the hopefully not too distant past].

BofA Confirms Third-Party Breach

"Bank of America systems were not compromised. Our customer data is secure." Mark Pipitone, BofA Spokesman

Evernote Security Notice

"Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service."

LA Times Serving Up Malware

"To ensure safety, the Offers & Deals platform has been rebuilt and further secured. The sub-domain generates only advertising content and does not contain any customer information."

So What's Going On?

When ever I read headlines like this, they almost always come with some disclaimer that "There is no evidence that the intruders gained access to..." and rightly so.  A lot of companies don't have the ability to detect the breach in the first place, and then when they are notified about it by some third party (customers, law enforcement or the attackers themselves) they most certainly don't have any way to tell what information was stolen, so they claim that customers need not worry because there isn't any evidence of their information being stolen.

"Is it just me or am I the only one who thinks how can these attackers be so good as to break into the networks of companies yet those companies always seem to stop the attack just before the attackers gain access to sensitive information?" Brian Honan, SANS NewsBites Vol 15 Issue18.
 
Assessing the Damage

Because of all of the cover-up attempts by companies to minimize the negative publicity falls out from disclosing a data breach, it can be difficult to find relevant data to use to education the decision makers in your organization about the importance of good Network Security Monitoring.  Here are some resources that I have found useful in describing the impact of a security breach to executives and senior management:

• http://www.privacyrights.org/data-breach
• http://datalossdb.org/
• http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html
• http://www.darkreading.com/database/10-top-government-data-breaches-of-2012/240142846

 
And some other interesting statistics in regards to the accuracy of claims that companies caught the bad guys "just in the nick of time".

• Trustwave 2012 GSR states breach to detection was 173.5 days within the victim’s environment before detection occurred. 
• In the Trustwave 2013 GSR breach to detection window widened to 210 days. 
• The Mandiant 2012 Annual Threat Report on Advanced Targeted Attacks sites a much larger window, "The median number of days from the first evidence of compromise to when the attack was identified was 416 days." 
• The more recent Mandiant APT1 Report states "[attackers] were inside victim systems for avg of 356 days; longest observed: 1764 days"
• The Verizon DBIR 2012 states, "It saddens us to report that, yet again, breach victims could have circumnavigated the globe in a pirogue (not from the bayou? Look it up.) before discovering they were owned. In over half of the incidents investigated, it took months—sometimes even years—for this realization to dawn. That’s a long time for customer data, IP, and other sensitive information to be at the disposal of criminals without the owners being aware of it."
• The Verizon DBIR 2013 concludes that it still takes on average 221 from breach to discovery.

These numbers seem to echo a common sentiment that there are two kinds of companies out there; those who know they've been breached and those who have been breached and just don't know it yet.

Book Review: Lean Security 101

Lean Security 101: The Comic Book

by Josh More
Publisher: RJS Smart Security
Number of Pages: 24


Josh More over at RJS Smart Security obviously had some fun putting this together. Lean Security 101 is a neat little info-graphic that looks an awful lot like a comic book.  

Percy the Protection Pangolin

I'll admit it; I had to look up what a Pangolin actually was (+1 for originality).  The Pangolin is Josh's sidekick throughout the story.

The 80x5 Rule

The biggest insight I got out of this comic was the 80x5 Rule.  So you've probably heard of the "Pareto Principle", commonly referred to as the 80/20 rule.  Well the 80x5 rule builds on this idea using concepts from Lean.

The 80/20 rule is often quoted by business managers and executives as a rallying cry to take some action or get started with some new project by trying to justify quick returns with minimal effort.  But hidden within this management standard is an implicit acknowledgment that getting a project to 100% perfection (meeting all of the requirements on time and within budget) becomes increasingly difficult.  The law of diminishing returns takes over and additional effort is needed just to make incremental progress towards the goal.

When applied to Information Security, this concept is just as true.  There is no silver bullet for protecting your digital assets, so no single project or technology or defense mechanism is ever going to be 100% effective at keeping your data safe.

The 80x5 rule is designed to help you get the most value from the least amount of effort, and while maximizing your defensive posture.

The 80x5 rule says that instead of spending all of your effort trying to implement a single defensive measure (that will never reach 100% effectiveness), it would be much more productive to add complementary layers of security.  After you have spent the first 20% of your effort on that defensive measure (and reached 80% of the results), any further effort on that task could be considered waste (based on Lean).  In terms of opportunity cost, if you took the remaining unspent effort (you still have 80% left at this point) and divide that into four more blocks, you could potentially get 80% results from each of another four projects.  This is obviously a much better ROI than spending that remaining 80% and only obtaining at most 20% benefit from your current task.

Assuming each layer is 80% effective (based on the Pareto Principle), eight layers could give you up to 99.999% effective security.  Yes, there can and will be various exceptions to this line of reasoning.  But why spend all your effort on fixing things that should be considered "good enough" when there are other more productive security measures you could be working on (like building up your incident response team and testing your IR plan)?  I see this as an important tool for helping to prioritize competing projects and assessing those final inches toward the goal line.

The book goes into more detail, but hopefully you get the idea.  Go download a free copy for yourself, http://www.rjssmartsecurity.com/Lean-Security-101-Comic/, and give them a call about a free Lean Security Assessment.

#ChecklistIsDead

I keep seeing tweets and blog posts and hearing talks at various cons that keep repeating statements such as: 

"[insert unpopular framework/checklist here] has done nothing to improve cyber security, and in fact it has probably made security worse"

And I don't believe it!

I recently wrote about how the InfoSec echo chamber keeps dogging on "outdated best practices", and today I started wondering if these echo repeaters all work for Gartner?  So I'm proposing that all framework/checklist bashing should use the hashtag #ChecklistIsDead from now on.

My point is that one of the biggest reasons InfoSec is failing is not because we are using a bad checklist.  We are failing because we aren't actually following through with implementing *any* checklist consistently, whether it is the PCI DSS, FFIEC, FISMA, NIST, or the SANS Critical Security Controls.  I don't really care which checklist you are being graded on (most of them can be cross-referenced with each other anyway, just different wording for the same basic goals), but if you can't make a list of your key business process, a list of your critical information assets, and updated diagrams for your network and data flow... then what makes you think that you are going to do any better with the newest #RiskManagement flavor of the week?

For example, I hear a lot of people complaining about the PCI DSS in one breath and then calling for the need to replace checklists with a risk based approach to security.  That's all fine and good, but if companies can't comply with the intent of PCI DSS v2.0 Requirement 12.1.2 to perform a risk assessment [only] once per year, then how well are they going on their own without such a requirement?

Establish, publish, maintain, and disseminate a security policy that "12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)"

I have read some articles lately (here and here) that talk about how security policies and frameworks are too silo'd and need to span across functional boundaries.  I'm sorry, but show me what framework or checklist specifically calls for its implementation to be contained within silos?  These failed implementations are the direct result of bad decisions made at the highest levels of most companies who don't understand the threats and vulnerabilities facing their organizations.  Yet these same decision makers are supposed to magically understand the risk derived from these same threats and vulnerabilities in order to invent a better #RiskManagement program that fixes their security failures?

All the while, taking time to actually implement the items on the existing checklists keeps slipping through the cracks or falling down the priority list (and just getting a QSA to submit your RoC to the cardbrands doesn't mean your company has actually implemented all of the requirements on the checklist).

There were several interesting items listed in a recent paper by James Lewis of the Center for Strategic & International Studies, Raising the Bar for Cybersecurity.

"In the last few years, in 2009 and 2010, Australia’s Defense Signals Directorate (DSD) and the U.S. National Security Agency (NSA) independently surveyed the techniques hackers used to successfully penetrate networks. NSA (in partnership with private experts) and DSD each came up with a list of measures that stop almost all attacks.

"DSD found that four risk reduction measures block most attacks. Agencies and companies implementing these measures saw risk fall by 85 percent and, in some cases, to zero."

<sarcasm>Too bad checklists are dead.</sarcasm>

Best Practices

Great comment in this week's SANS NewsBites (Vol. 15 Num. 029) from Alan Paller, director of research at the SANS Institute.

[Editor's Note (Paller): As organizations discover there is economic liability for lax cybersecurity, and lawyers smell blood in the water, the recognition will dawn on policymakers that their reliance on high level "guidance" was a really bad idea and made government cybersecurity a terrible model for protecting the critical infrastructure and businesses.  This week the Australian Attorney General established a legal requirement that all agencies implement a small number of critical security controls. No company can pretend they don't know the basic controls they must implement. The U.S. government will do that, too, but, as Winston Churchill said so long ago, "Americans will always do the right thing - after exhausting all the alternatives." You can get a head start on doing the right thing if you can get to London on May 1-2 (http://www.sans.org/event/critical-security-controls-international-summit) or listen in on the briefing on April 18.  (http://www.sans.org/info/128297]


I found this comment somewhat ironic, given the recent twitter conversation with @joshcorman:

@cindyv for 1); stop dogmatically clinging to outdated "Best Practices", Dogma, and static compliance checklists.[cont]
— Joshua Corman (@joshcorman) April 2, 2013

Maybe "Best Practices" really aren't the absolute "Best" that we can do in every individual situation.  And can they really be called "Practices", if they aren't actually practiced? (i.e. repeated performance or systematic exercise for the purpose of acquiring skill or proficiency). Having cursory familiarity with an established checklist of known good security measures such as the SANS Critical Security Controls, does not qualify as practicing or best.  ;)

@sudosec @cindyv hasn't SANS migrated away from "the 20" ? Also, all controls need to subordinate to context of Risk Program
— Joshua Corman (@joshcorman) April 11, 2013

@cindyv @sudosec I need to look at their newest list; but my main point was the context/program is king
— Joshua Corman (@joshcorman) April 11, 2013

Also, check out Cindy's article about being Consumers of Security Intelligence here.

SANS 2013 Orlando

SANS 2013 was great, but I'm certainly glad to be back home.  It was a long week of sitting in conference rooms from sun up to sun down listening to some of the brightest instructors in InfoSec.  I really enjoy the quality of the conferences that SANS provides.

GIAC Intrusion Analyst (GCIA) Job Task Analysis (JTA)

It was an honor to be selected to participate in the JTA session.  The JTA is a way for GIAC to double check the correlation of their certification exam scores to the actual job skills that SANS is trying to teach.  I flew in a day early to take part in the exercise. I enjoyed the opportunity and hopefully get to help out again in the future.  And, I got to meet Judy Novak.

SEC504: Hacker Techniques, Exploits and Incident Handling

This is the fourth class I've taken from SANS, so I pretty well knew what to expect.  SEC504 covered a lot of material, but much of the material felt familiar to me already, just more depth and insight into the attack techniques that are readily available.  For a lot of the attacks out there today, there really aren't very many good defenses.  So I guess numero uno on the list for things I learned at SANS 2013 isn't really something new, but something old and very foundational to InfoSec.  
 - Use common sense to limit who has access to systems and data in your environment.
 - Baseline your environment so that you know what is "normal" in terms of ports being used and processes running on your systems.
 - Don't reuse the same password for local administrator accounts across your organization.
 - Use host-based firewalls to prevent compromised systems from being able to easily pivot to other systems on the same subnet.
 - I also picked up a Teensy to play around with for physical testing.

Now I just have to get busy studying for the GCIH exam... 

APT: It is Not Time to Pray, It is Time to Act - Dr. Eric Cole

Dr. Cole is an excellent speaker and easy for me to pay attention to.  His tone and cadence in his presentations are very academic, but at the same time very candid and realistic.  He doesn't come across as somebody that is trying to wow you with his vast knowledge of InfoSec.  He seems to genuinely care about the material he is presenting and willing to do whatever it takes to make that material interesting and tangible to his audience.  The content of the keynote for SANS 2013 wasn't so much about all of the APT hype as it was a very focused warning of the need to master the basics of InfoSec before we will really be able to win against the attackers.  

Dr. Cole outlined 5 steps to improving security posture and being able to react to indicators of compromise more efficiently.

1. Identify Critical Data - Align critical assets with threats and vulnerabilities to focus on risk.  Using Risk Based Thinking - What is the risk? Is it the highest priority risk? Is it the most cost effective way of reducing the risk?
2. Align the Defense with the Offense - The areas that defense currently focuses on are not the same as what the offense is focusing on.
3. Know thy Organization - You Cannot Protect What You Do Not Know About.  Organizations need accurate up-to-date network diagrams and network visibility maps, focus on configuration management and change control.
4. Defense in Depth
    a) Inbound Prevention
    b) Outbound Detection
    c) Log Correlation
    d) Anomaly Detection
5. Common Metrics - Use the 20 Critical Controls!

Vendor Expo

Eh, not much to say here other than some vendors had some boths set up with some trinkets and trash on display.  And now my inbox and voicemail are full of messages that I don't really need.

Social Zombies: Rise of the Mobile Dead - Kevin Johnson

Yeah, I know social media is out to get me.  Really, duck face?

Introduction to Windows Kernel Exploitation - Stephen Sims

This is one area that I have no experience with.  Stephen did a great job of taking a difficult subject and explaining it so that I could follow along.

How to Become a SANS Instructor - Eric Conrad - Lunch-n-Learn 

Eric has an interesting story about how getting involved with SANS boosted his career and opened up the door of opportunity.  I've thought about signing up for the Mentor program, maybe this was persuasive enough to get me to send in the application?

ADHD and Samurai - John Strand and Kevin Johnson

The Active Defense Harbinger Distribution (ADHD) is pretty cool.  It is a Linux distro built around the idea of making life difficult for the bad guys.  It focuses on Annoyance, Attribution and Attack.  Some of the fun features include infinitely recursive directories, seeding honeytokens with call-home commands so that you can locate where your data has be exfiltrated, and setting up the signed Java applet attack in Metasploit to actually exploit the attacker.  There is a great write up of Paul Asadoorian and John Strand's RSA presentation here.

The Samurai Web Testing Framework (WTF) is also a nifty Linux distro with a series of tools to assist in web app pen testing.

Hacking You Friends and Neighbors For Fun - Joshua Wright 

Very entertaining.  If you haven't seen this talk yet, check out the slides here.

InfoSec in the Financial World: War Stories and Lessons Learned - Bryan Simon

Bryan make the case for improving the information sharing of financial institutions with regards to adversaries, attacks and defense strategies.  Ironically, on his way to the conference, half his slides were yanked by his legal department so that he wasn't able to share some of the stories he wanted to.  The best part about this session were all of the conversations that started up afterwards.

NetWars Tournament

Wow, this was my first time at Netwars.  I wasn't really sure what to expect here.  All I can say is, there are some wicked smart people at SANS and I need some more practice.

Surprising Results Improving Weak Passwords

Last year I saw a presentation by John Strand of Black Hills Information Security titled "Everything They Told Me About Security Was Wrong" during which he talked about how ridiculously easy it is to crack most people's passwords.  John gave several examples about how the typical alpha-numeric-special-character complexity requirements mandated by most security frameworks or regulations are actually making it easier to break into and harder on users to remember their passwords. 

Then along came correct horse battery staple.  Just for reference, here are a few examples from the Brute Force Calculator (these examples are based on a system running an Intel i7-2600K CPU @ 3.40GHz).

Password Length	Password Type	Character Set	Total Key Space (password combinations)	Time Required to Brute Force
7	NT MD4	Mixed Alpha Numeric All	6.5545E+13	15 days
8	NTLMv2	Mixed Alpha Space	6.3456E+13	15 days
8	NT MD4	Mixed Alpha Numeric All	6.16123E+15	4 years
15	NT MD4	Mixed Alpha Space	7.45436E+25	50 billion years
15	NTLMv2	Mixed Alpha Space	7.45436E+25	2 trillion years
18	NTLMv2	Mixed Alpha Space	1.10978E+31	357 quadrillion years
19	NTLMv2	Mixed Alpha Space	5.88185E+32	19 quintillion years
20	NTLMv2	Mixed Alpha Space	3.11738E+34	1 sextillion years

Implementing the Changes

So, I decided to see if I could get my organization to go along with the idea of much longer but less complex passwords.  There were two parts to implementation, the first was the social/political side of things, getting the right approvals internally to change the policy, explaining to users why the change was good for them and the company, and convincing the auditors that this change actually improves security.

The second part was configuring Windows Group Policy to enforce the new policy.  This turned out to be not as straight forward as I expected.  Using the Windows GPO Editor to set passwords minimum length stops at 14.

Some Google-fu netted me this result that provides a couple of examples for fixing Microsoft's shortsightedness for improving password security.

Joeware's ADMod tool makes it easy to modify the Default Domain Policy, here's the command to set the minimum length to 15 characters

    admod -default minpwdlength::15

Then to see if it worked...

Dealing With Auditors

You know you are going to have a fun time when an IT auditor asks a question like, "Can you explain how to read this network diagram?" Another point John made during his prezi, was that no organization is ever 100% compliant with every applicable regulation or security requirement.  No one.  So what happens when your organization doesn't meet the specific letter of the law for a particular requirement?  You implement a compensating control.  After walking through a few examples of password cracking tools, such as John the Ripper and Cain/Abel, it wasn't as tough a sell as I was expecting.

Results

The auditors signed off for the changes to the password policy without too much trouble. The auditors weren't the only concern I had about changing the policy.  My guess was that these changes were going to create a problem for users as well as IT having to do account unlocks all the time.  After having this policy in place for several months now, one of the biggest surprises I found from going through this exercise is that account lockouts are currently at an all time low across the entire company.  That is what you call a Win-Win!

Wake Up Call to Software Vendors

While working on deploying an update to a software application by one of the vendors I deal with on a regular basis, I was given a document titled "Pre-Install Handout".  (Well, I'm not really that crazy about handouts.  Most of the time I believe in earning my keep. Anyway...)  At the top of page three, there is a big yellow triangle with a bold black exclamation mark next to the following text:

"Domains: If the [server] machine is to be placed on the [customer] domain, [vendor] must have complete administrative rights to that machine.
 
There should be absolutely no security restrictions on making changes to that machine. If the domain security interferes with the [server] machines operations; it will have to be removed from the domain."

Dear vendor, if you can't get your software to work with the security settings of our environment, then it is probably time for me to start looking for a new vendor.

This is the same vendor that a couple of months earlier, I sent a request asking for a copy of their SSAE-16 reports and financial statements so that I could include the documentation in my vendor management program file.  The response I got back:

"Though [Vendor] does have products that fall under the requirements of a SAS70 audit, because both [Product A] and [Product B] are considered in-house products for our customers (no data is stored on our servers here), it does not apply in this instance.

I have attached an FAQ that further addresses your request. As a point of mention, both the [Product A] and [Product B] divisions of [Vendor] share a facility with the [Product C] division and though we are separate products, we are bound by the same facility and information security management as addressed in that product’s SAS70. Let me know if I can provide any additional assistance.

The SAS70 report appears to now be in the new SSAE-16 reports, but again, the [Product A] and [Product B] departments, this doesn’t apply." 

A couple of weeks after getting this response, I had a support ticket open with this vendor.  The same support technician that sent me the response above, proceeded to download a copy of the application database from my server to their workstation to "test some things out".  The vendor did not request permission before making a copy of the data that I am responsible for, and didn't admit to doing so until after I questioned them about it.  I then asked for a copy of their SSAE-16 reports (which they obviously don't have).  Finally, the vendor sent me an updated privacy statement that included coverage of customer data within the vendor's environment.  While not a perfect solution, it should hold up in court if they have a data breach.  But at that point all of the data I'm responsible for is probably already on pastebin.

So back to the software upgrade deployment I mentioned earlier.  When I sent the paperwork in to the vendor for the service request to have them install the upgrade (and no, they don't allow anyone else to do the installation), I explicitly stated that they are not to make any changes to the OS, firewall settings, install third party tools, etc. unless they first got permission to do so.  I also restated this to the technician (different than the one above) working on the install and got an affirmative response that they agreed to these rules of engagement.  So guess what?  I remote into the system they are installing the upgrade to and see the vendor making changes to the host firewall (as in completely turning it off).  #FAIL!  I then terminated the vendor's connection, turned the firewall back on, and called to see whether this technician suffers from short term memory loss.

Dear vendor, when are you going to wake up and treat your customers with a little bit of decency.  It is not my goal in life to catch you doing stupid things.  I really don't need the extra stress of worrying about what you might do to compromise the security of my data.  I have enough bad guys out there trying to break into my systems without you handing them the keys to your backdoor.

A word of advice to sysadmins and business folks that deal with vendors:

I doubt I'm alone in this experience.  I suspect things like this happen everyday to systems in your environment the same as they do in mine.  Do you have policies in place to handle these situations?  Are the people on your team trained to watch out for this type of negligence on the part of the vendor?

One of the basic concepts of data security is the principle of least privilege.  This should be applied to vendors as much as anyone.  Vendors don't usually have malicious intent, but in general they also have much less skin in the game when it comes to protecting your data.  Monitor their activity.  Watch what they are doing when they are in your system.  Revoke their access unless you have a real need for them to be in your systems. 

GCIA Exam Prep

So, I attended the SANS Rocky Mountain Conference in Denver last June.  It was an odd venue at The Curtis.  My room was on the 13th floor, and every time the elevator doors opened up I was greeted by Jack Nicholson’s voice saying “Here’s Johnny!”  Accommodations aside, I took the SEC503, Intrusion Detection course with the master Mike Poor guiding the class through a week of deep dive into the world of decoding Binary to Hex to Decimal to Binary to Decimal to Portuguese to Hex to Russian to, well you get the idea.

Things I learned

Packet Analysis isn’t that difficult if you understand a few basics.  (Note: I didn’t say good analysis.)

There are plenty of tools out there to make your job easier, but there are times when the tools aren’t going to work as expected.  In those cases (often the most critical if dealing with a new 0-Day exploit or crafted packets that bypass known signatures), it is imperative to understand how to manually decode packets to find where the evil is hiding.

A determined attacker can always find a way in.  The really good attacker does so with very minimal noise.  For example, on day 6 during the PCAP analysis challenge, one of the things that really stood out to me was that there were several various attempts to compromise the honeypot we were asked to analyze, but the successful attacker was able to gain root access and do so by generating less than 1% of all the alerts that were triggered by the snort signatures we were using.  Talk about finding the smallest needle in the needle-stack!

Review your logs!  This is one of those things that every admin knows he ought to do, but never seems to find the time to do it right.  The key to managing your time for reviewing logs and alerts for Intrusion Analysts is minimizing the number of false positives.  This involves knowing how to build an IDS in such a way as to detect the attacks that are most likely to succeed in the environment you are trying to protect.  Is there really a point in alerting on the fact that someone just tried to port scan your network?  Maybe, but it depends on how much time you are really going to spend researching that event.  Are you really getting any value out of that snort alert letting you know that SQL Slammer is still probing port 1434, even though your firewall doesn’t allow any traffic from the outside in to port 1434?

Regrets

I wish I would have spent a little more time before class studying up on some of the material to have a better foundation to build on.  For example, my *nix-fu is less than stellar.  I’ll admit, I’m still in grasshopper mode when it comes to chaining command line tools together like cut, uniq, sort, awk, and sed.


I wish the class would have spent at least a half day or so walking though the Security Onion (SO) disto.  The Packetrix VM has enough tools to complete the PCAP analysis challenge for day six, but it would have been fun to use tcpreplay to feed the pcap into SO and use Squil to drill into the details of the attack.  I really wish that we could have spent just little bit of time on a quick into to Bro-IDS.  Mike mentioned OSSEC a few times in class, but I wish we could have spent some time looking at how it works.

I wish I would have read Network Intrusion Detection (NID) by Stephen Northcutt and Judy Novak before taking the class.  The course materials were written by Judy, and NID covers a lot of the same material and has somewhat the same approach to the material that the class had.  I highly recommend for anyone getting ready to take SEC503, read NID.

Studying for the GCIA Exam

Came home.  Went back to work.  Played catch up on all the requests piling up while I was gone.  Finally got around to taking the first practice exam a few weeks later.  I found out I was actually pretty interested in learning more about blue team operations so I order a few books and spun up a few VMs and started playing around. 

Below is a list of materials I used to study for the exam and polish up my intrusion analysis skills. 

SANS SEC503 Course Material

Network Intrusion Detection by Stephen Northcutt and Judy Novak

TCP/IP Illustrated, Vol. 1 by W. Richard Stevens
 

Practical Packet Analysis by Chris Sanders
 

Snort IDS and IPS Toolkit by Jay Beale, Brian Caswell and Andrew Baker
 

OSSEC Host-Based Intrusion Detection Guide by Andrew Hay, Daniel Cid and Rory Bray













So how did I do on the exam?

This was a tough exam.  I poured a lot of hours into studying for this.  It was getting close to the deadline to take the exam, so I signed up at the closest PearsonVUE testing center, only to have them call be back after 5 PM on the Friday night before I was scheduled to take the exam on Monday morning to tell me that my scheduled exam was canceled due to technical difficulties.  Contacted GIAC right away and they work everything out, which gave me a couple of extra weeks to cram.  In the end, all of the extra study paid off.  I aced the exam.

Don't Surrender to Your Smartphone

Me: Hello Smartphone App

Smartphone App: Hello User, may I have your contact list, IMEI #, Camera, Email account username and password, Bank Account #, Routing # and Geolocation?

Me:  Sure, why not?  I just need to check the status of a “friend” on “Twit-face-square-link-book.com” right now!

I recently attended the Innotech conference in OKC and sat in on the Android (in)Security presentation given by Georgia Weidman (very entertaining).  During the presentation she demonstrated how malware could be installed on an android device as a shim to the driver for sending and receiving text messages so that the phone could be manipulated into receiving botnet C&C messages via SMS and the user would never see these messages on their phone.

Most smartphone vendors these days require developers to disclose what permissions are used by their app before you download it.  This permission model allows users to make informed decisions about which apps they allow on their phone and gives the user control over how their phone is being used.  At least that's the idea behind it.  So, do you know what permissions your phone is using?


This application can access the following on your phone:

Your personal information 

• Allows an application to add or change the events on your calendar, which may send email to guests. Malicious applications can use this to erase or modify your calendar events or to send email to guests, 
• Allows an application to read all of the calendar events stored on your phone.  Malicious applications can use this to send your calendar events to other people, 
• Allows an application to read all of the contact (address) data stored on your phone.  Malicious applications can use this to send your data to other people, 
• Allows an application to modify the contact (address) data stored on your phone.  Malicious applications can use this to erase or modify your contact data. 

Your messages 

• Allows an application to write to SMS messages stored on your phone or SIM card.  Malicious applications may delete your messages, 
• Allows an application to read SMS messages stored on your phone or SIM card.  Malicious applications may read your confidential messages. 

Your location 

• Access course location sources such as the cellular network database to determine an approximate phone location, where available.  Malicious applications can use this to determine approximately where you are, 
• Access fine location sources such as the Global Positioning System on the phone, where available.  Malicious applications can use this to determine where you are, and may consume additional battery power. 
• Create mock location sources for testing. Malicious applications can use this to override the location and/or status returned by real location sources such as GPS or Network providers. 

Network communications 

• Allows an application to create network sockets. 

Your accounts 

• Allows an application to use the account authenticator capabilities of the AccountManager, including creating accounts and getting and setting their passwords, 
• Allows applications to sign in to Google Calendar using the account(s) stored on this phone, 
• Allows applications to sign in to the Google mail services using the account(s) stored on this phone, 
• Allows an application to perform operations like adding, and removing accounts and deleting their password, 
• Allows an application to request authentication tokens.  

Absolutely no mention of malicious activity for Your Accounts and passwords?  (That must mean that all my accounts and passwords are uber safe, right.)
 
Phone calls 

• Allows the application to access the phone features of the device.  An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like. 

Hardware controls 

• Allows application to take pictures with the camera.  This allows the application at any time to collect images the camera is seeing. 

System tools 

• Allows an application to change the state of network connectivity, 
• Allows an application to change the current configuration, such as the locale or overall font size, 
• Allows an application to modify the system's settings data.  Malicious applications can corrupt you system's configuration, 
• Allows the application to mount and unmount filesystems for removable storage, 
• Allows an application to prevent the phone from going to sleep, 
• Allows application to retrieve information about currently and recently running tasks.  May allow malicious applications to discover private information about other applications, 
• Allows an application to change the phone's time zone, 
• Allows an application to modify the APN settings, such as Proxy and Port of an APN, 
• Allows an application to modify your currently synced feeds, 
• Allows an application to modify the sync settings, such as whether sync is enabled for Contacts.  

But wait there's more...
 
Your location  

• Access extra location provider commands.  Malicious applications could use this to interface with the operation of the GPS or other location sources.  

Network Communications  

• Allows an application to view the state of all networks, 
• Allows an application to view the information about the state of Wi-Fi. 

Your accounts  

• Allows an application to get the list of accounts known by the phone, 
• Allows applications to see the usernames (email addresses) of the Google accounts you have configured.  

Hardware controls  

• Allows the application to control the vibrator.  

System tools

• Allows an application to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the application to slow down the overall phone by always running,
• Allows an application to disable the and any associated password security.  A legitimate example of this is the phone disabling the keylock when receiving an incoming phone call, then re-enabling the keylock when the call is finished,
• Allows and application to expand or collapse the status bar,
• Allows an application to get details about the currently synced feeds,
• Allows an application to read the sync settings, such as whether sync is enabled for Contacts.
• Allows an application to read the synced stats; e.g., the history of syncs that have occurred.

And a few extras just for fun (really, is there anything more fun than hacking, well, I meant penetration testing for research purposes, when you have permission?)

Manipulation of your physical life

• Allows an application to interact with other people on your behalf.  Malicious applications will use this to send text messages to premium phone numbers to run up unauthorized charges to your phone bill.
• Allows an application to join a botnet and send and receive command and control messages.  Malicious applications will use this to allow hackers and cyber criminals to take over your device.
• Allows an application to reset the password to your online banking accounts.  Malicious applications will use this to prevent you from checking the balance of your accounts when suspicious activity alerts start showing up in your inbox.
• Allows an application to delete email and SMS text messages from your phone. Malicious applications will use this to prevent you from reading the alerts about suspicious balance transfers from your online banking accounts.
• Allows an application to upload pictures from your phone to botnet operators and hackers.  Malicious applications use this to find compromising photos that will be used for blackmail or general embarrassment.
• Allows an application to record phone calls and from your phone to botnet operators and hackers.  Malicious applications will use this to gather information about you that can be used to still your identity.

There have been hacks and mods available for some time now to pry your personal information out of the hands of shoddy developers, greedy marketers and dubious botnet operators and give control over your smartphones and mobile devices back to you, the user.  Take for instance the Cyanogen rom for Android.  So why are users so complacent about giving out every permission that their favorite app asks for?

I am bothered by the fact that apps like Facebook come preloaded on my device, automatically start during the boot cycle and then do not allow me an option to uninstall this ridiculously invasive app unless I root my phone and manually delete it myself.  I'm appalled by developers and vendors that think this is acceptable behavior.  It is high time that users stand up for their privacy and tell vendors why these types of marketing gimmicks are unacceptable and unethical!

On a brighter note, I actually found an app the other day that claims to require ZERO permissions!  ABC Touch Lite on the Android is a cool little app that my kiddos can use to learn to draw the alphabet.  Wow, how is that possible?  Can an app actually function without needing to see the password to my email account?

If you are interested in having some fun testing out the security on your smartphone, check out Georgia's Smartphone Pentest Framework.