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.

Why Kamikaze?

Disclaimer:  This is not about homage to self destruction; it is about a mindset of victory.

Sun Tzu said, “The good fighters of old first put themselves beyond the possibility of defeat, and then waited for an opportunity of defeating the enemy.”

First of all, it is about humility.  Sure I’m good at what I do, but there are many others out there that are far better than myself.  I have only made it to where I’m at today because others have helped me to get here.  I have a passion for learning, and I am constantly learning from others.  Sometimes, I think my comments are taken as offensive because I believe that in order to improve the way things are, then the way things are must be challenged.  Please don't take what I say as an attack, but rather a question from someone who might not understand the alternative point of view, (and yes, I am willing to listen).

Secondly, “k@m1kaZ3” makes for some fun 1337.  Really, try pecking it out on your keyboard a few times; you’ll see what I mean.

To me the kamikaze mindset is not about self destruction, it is about submitting one’s self to the service of a greater good.  (Again, I am NOT trying to say that Japanese fighter pilots were doing good by crashing their zeros into American ships.)  Often the “greater good” depends on one’s perspective, and that mindset can be effectively harnessed and evidenced in a fearlessness to tackle any challenge.  I absolutely despise failure, but I’m not afraid to learn from my past mistakes.  When learning a new technology or dissecting some new gadget, I actually prefer to learn by trial and error (and hopefully, eventually, trial and success).

 
The purpose of this blog is mainly just to document some projects that I’m working on, and probably a few book reviews or philosophical tangents along the way.  Enjoy!

Update: Originally I was going to name this blog kamikaze, but then ended up going with the Twitter name SudoSec. Even though the name changed, the content here is still relevant.  Guess now I'll have to make a new post called "Why SudoSec?"