In my last few posts I reviewed some of the SSL type vulnerabilities. These vulnerabilities were the result of SSL misconfigurations. Today I will address a client side SSL/TLS exploit.
How many people do you know who access secure websites by typing HTTPS://www.securesite.com in the address field of their browser? The vast majority of people just place the website name (www.securesite.com) in the address field of their browser and let the chips fall where they may. So I guess my question would be “How does the browser know whether to send me to a secure site (HTTPS) or send me to an insecure site (HTTP)”? Does the browser see www.securesite.com in the browser and flip a virtual coin to decide whether or not to direct me to an insecure (HTTP) or secure (HTTPS) connection? Does the browser read www.securesite.com and think to itself “I bet that site should be established over a secure connection today,” or does the computer just use magic to decide whether to establish a secure connection or not?
I will now attempt to explain the great mystery and technical awe and wonder of how the browser determines whether to establish a secure or insecure connection... Ready... Here goes: If the type of connection is not specified in the address field of the browser (HTTP or HTTPS), then the connection defaults to being established over HTTP. In other words, if I type www.securesite.com into my browser, the browser will default to HTTP://www.securesite.com. *Whew, That was tough to explain.* So the question is how do I end up using a secure connection (HTTPS) if the browser defaults to a non-secure connection (HTTP)?
In all reality most people only encounter HTTPS through HTTP. In other words, people are directed to secure connections through insecure connections. Secure connections (HTTPS) are generally established through redirects or links.
Let’s discuss how HTTPS is encountered through redirects. Suppose I am the owner of a company which sells bobsleds to people who live in the Sahara desert (I just fired the head of marketing). I set up a website named www.hotsledsforhotclimates.com. In order to purchase a sled we require people to provide SSN, Checking Account Number, and three different credit cards using our website. I have a doctorate degree in quantum cryptography so I know that sending all this sensitive information over an insecure connection like HTTP is not a good idea. I decide that if someone tries to access my webpage through HTTP that they should probably be redirected to a secure connection (HTTPS). “Franz” (A desert dwelling hermit from the Sahara desert) decides he wants to purchase a bobsled in case it snows. Franz has heard that the site www.hotsledsforhotclimates.com has the type of bobsleds he is looking to purchase. Bob opens his browser and types www.hotsledsforhotclimates.com into the address field of his browser. The browser sends the request to HTTP://www.hotsledsforhotclimates.com. The request is sent to my website which promptly tells Franz’s browser that it must use HTTPS to connect to www.hotsledsforhotclimates.com. The web browser is redirected to HTTPS://www.hotsledsforhotclimates.com. Franz purchases his bobsled and the world is right again.
The second way that people generally encounter HTTPS is through links. Suppose that a site is dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert. Nothing on the website is confidential so the site does not require a secure connection (Everything is sent through HTTP). The site has links which redirects people who wish to purchase one of these bobsleds to hot sleds for hot climates. The link which points to hot sleds for hot climates is HTTPS:// www.hotsledsforhotclimates.com. Franz (Our beloved hermit) is reviewing the site dedicated to the hottest companies who sell bobsleds to people who live in the Sahara desert and decides that he must purchase a bobsled from one of these companies. In a moment of weakness Franz decides to use his children’s college fund to purchase a bobsled (The sleds are very expensive). He selects the link for HTTPS:// www.hotsledsforhotclimates.com and is quickly sent to a secure site where he can purchase the bobsled of his dreams. Franz purchases his bobsled and everyone is happy (except for his poor kids who will now be forced to attend a small community college).
So to reiterate, people encounter HTTPS through HTTP (More specifically, redirects and links). So what is stopping attackers from intercepting all links and redirects which tell the browser to use HTTPS and replace them with links which point to HTTP? Why can’t attackers place themselves between the customer (Franz) and the web site www.hotsledsforhotclimates.com and modify all redirects and links destined for HTTPS and replace them with links to HTTP? What would stop an attacker from setting up an insecure connection with the customer and a secure connection with the website and act as a middleman between them? The answer to these questions is: essentially nothing! In fact, a tool named SSLStrip performs this type of attack with minimal effort.
SSLStrip works as follows. An attacker performs a man in the middle attack to place themselves between the client and the server. Whenever SSLStrip sees links or redirects which try to send the customer to a secure connection (HTTPS), it replaces the links with insecure versions of these links (HTTP). SSLStrip sets up a secure connection with the site HTTPS:// www.hotsledsforhotclimates.com and an insecure connection with the customer HTTP:// www.hotsledsforhotclimates.com.SSLStrip even places a padlock favicon in the corner of the customer’s browser to make them think they are connected over a secure connection. The attacker takes the information sent from the customer (Username, Password, SSN, Credit Cards) and logs them to a file for future review. The attacker then uses their secure connection with the server to forward this information to the web server.
So what should you do in order to prevent falling prey to this attack? First, if you type www.securewebsite.com into your web browser or access a link which redirects to a site requesting sensitive information (Username, Password, SSN, Credit Card, etc), manually verify you are redirected to a secure connection HTTPS://www.securewebsite.com. This can be accomplished by looking at the web address listed in the browser and verifying the address starts with HTTPS. Although this safeguard may make it more difficult for an attacker to exploit this vulnerability, a dedicated attacker using an advanced Homograph attack may still be able to successfully exploit this vulnerability. Second, you can manually type HTTPS:// before the website you are trying to access. This will verify the connection is immediately connected through HTTPS and is never sent through HTTP redirects. Once you access the site through manually placing HTTPS// before the site name, the site can be saved as a bookmark for quick access over SSL in the future.
-Gary McCully
Read more!
Thursday, August 26, 2010
Information Security Policies and Procedures, Part 4
This is part of an ongoing series on documentation development. Please be sure to read the previous posts in this series.
Part 1 , Part 2 , Part 3 , Part 5 , Part 6
The formatting and structure of documentation may not seem like the most enthralling topic, and in many (most) ways it is not. It is however one of the most important elements of effective documentation. Delivering information in a clear and consistent way is essential to ensure documents are easy to use and effective. From your organization’s logo to the approval of the board, documentation should look, feel, and be official. Even fonts can make a difference. If you work for an organization large enough to have a style guide and/or documentation standards, much of the structure, format, look, fonts, etc. will be laid out for you. For those who are blazing the path, however, you must be prepared to make several decisions prior to developing documentation.
It is almost always easiest to design a template and determine style and formatting before putting the figurative pen to paper (hands to keyboard). (Truth be told, I cannot think of a single example where it would be better to develop documentation before developing a template, but I am doing my best not to speak in absolutes. If you have any examples to prove me wrong, please by all means share them in the comments or email me directly.)
Unfortunately, due to time and other constraints, I will not be going into great detail of the intricacies of creating and formatting templates and using styles. If you plan to have any lengthy involvement in document development, I highly recommend spending some time becoming comfortable with the advanced features of your word processing program of choice. While I think it is safe to say that many feel they are expert users of the Microsoft Office suite, there are many powerful features that many who consider themselves “power users” are unaware of. Get to know the styles, template features, and table structure. Time spent up front creating a bullet proof and consistent template and related style rules will pay immense dividends in saved time and effort down the road.
As our focus in this series is policies and procedures, we will start there. In the header, at minimum include the title, revision number, effective date, and your organization’s logo. The reason for the title should be fairly clear. Including your logo will make the document immediately identifiable as belonging to your organization. The effective date and revision data allow users to identify that they are using the correct version of the document.
In the footers, include copyright information as well as page numbers. Page numbers are important, especially with longer policies and procedures, to ensure that users know that they are looking at a complete policy and not just a page or two.
The footer is also a good place to include the document classification. As we discussed in earlier posts, some policies and procedures will be more sensitive than others. It is important to label documents so that users understand their proper handling. If you do not have an asset classification program, we strongly suggest you implement one as asset classification is one of the main building blocks of an effective information security program. Please feel free to contact SecureState’s Risk Management team for details.
Take care to have consistent header and footer designs across your organization’s documentation. I cannot reiterate enough the importance of consistency.
In our next installment, we will continue on formatting and structure and get into the details of what sections and basic information should be included in every policy and procedure.
Read more!
Part 1 , Part 2 , Part 3 , Part 5 , Part 6
The formatting and structure of documentation may not seem like the most enthralling topic, and in many (most) ways it is not. It is however one of the most important elements of effective documentation. Delivering information in a clear and consistent way is essential to ensure documents are easy to use and effective. From your organization’s logo to the approval of the board, documentation should look, feel, and be official. Even fonts can make a difference. If you work for an organization large enough to have a style guide and/or documentation standards, much of the structure, format, look, fonts, etc. will be laid out for you. For those who are blazing the path, however, you must be prepared to make several decisions prior to developing documentation.
It is almost always easiest to design a template and determine style and formatting before putting the figurative pen to paper (hands to keyboard). (Truth be told, I cannot think of a single example where it would be better to develop documentation before developing a template, but I am doing my best not to speak in absolutes. If you have any examples to prove me wrong, please by all means share them in the comments or email me directly.)
Unfortunately, due to time and other constraints, I will not be going into great detail of the intricacies of creating and formatting templates and using styles. If you plan to have any lengthy involvement in document development, I highly recommend spending some time becoming comfortable with the advanced features of your word processing program of choice. While I think it is safe to say that many feel they are expert users of the Microsoft Office suite, there are many powerful features that many who consider themselves “power users” are unaware of. Get to know the styles, template features, and table structure. Time spent up front creating a bullet proof and consistent template and related style rules will pay immense dividends in saved time and effort down the road.
As our focus in this series is policies and procedures, we will start there. In the header, at minimum include the title, revision number, effective date, and your organization’s logo. The reason for the title should be fairly clear. Including your logo will make the document immediately identifiable as belonging to your organization. The effective date and revision data allow users to identify that they are using the correct version of the document.
In the footers, include copyright information as well as page numbers. Page numbers are important, especially with longer policies and procedures, to ensure that users know that they are looking at a complete policy and not just a page or two.
The footer is also a good place to include the document classification. As we discussed in earlier posts, some policies and procedures will be more sensitive than others. It is important to label documents so that users understand their proper handling. If you do not have an asset classification program, we strongly suggest you implement one as asset classification is one of the main building blocks of an effective information security program. Please feel free to contact SecureState’s Risk Management team for details.
Take care to have consistent header and footer designs across your organization’s documentation. I cannot reiterate enough the importance of consistency.
In our next installment, we will continue on formatting and structure and get into the details of what sections and basic information should be included in every policy and procedure.
Read more!
Subscribe to:
Posts (Atom)
Posts
