[thelist] Are there any security leaks of HTC's
VOLKAN ÖZÇELİK
volkan.ozcelik at gmail.com
Sat Jun 4 16:00:32 CDT 2005
Hi,
After all the hack crisis; below is a simplified translation of the
report that the emergency team has prepared.
Thank you very much for your inputs. They were really helpful.
I thought it is a good idea to share the results & findings with you.
Excuse me if it's a bit long.
Before beginning the report let us have some nostalgia: Here is my
comment about the project in another thread titled (What is the ideal
session timeout)
>note that I just consider "memory" optimization. security is another issue,
>the computers will not be publicly accessible, they will be used by the
>staff and thus they can be considered "secure enough"
Shame on me!
And here comes the report:
------------------------------------------------------------------------------------------------------------
<the introduction and the formal "blah blah blah" part
has been cropped>
Basically we need to properly understand the following two concepts:
1. After having logged in to the system, whatever security precautions
you take will be useless. Since the hacker will have a valid session
identifier, he will do whatever he likes with it.
Thus,
i. We need to strengthen to login part,
ii. We need to find & fix the security holes throughout the rest of
the system.
We should also note that, the problem is not directly related to
HTC-spoofing. Web is, by it's nature a disconnected and insecure medium.
insecure : A %100 secure server, is a server that is not connected to
the internet
disconnected: You cannot know, the person who has opened a connection
to the server, is really an authorized individual, or a hacker who
"impersonates" the legitimate user.
This may seem a rather skeptical approach, but this is the truth in fact.
Let us strenghten our theis with some discussions and quotes from the net:
1. First of all, as we have mentioned on the preceeding report,
Microsoft IE 5 and former versions have a "frame spoofing"
vulnerability.
This security leak has been discussed all around, but it was hard to
find a concise description. Although we haven't found any bug report
on the MS technical documentation, we know that some versions of IE
does not implement cross-frame security model for its HTC components.
Here is a quote about frame spoofing:
" This vulnerability exists because Internet Explorer's cross
domain protection does not extend to navigation of frames.
This makes it possible for a malicious web site to insert
content into a frame within another web site's window.
If done properly, the user might not be able to tell that
the frame contents were not from the legitimate site,
and could be tricked into providing personal data to the
malicious site. Non-secure (HTTP) and secure (HTTPS)
sites are equally at risk from this vulnerability.
The patch makes frames 'write-protected,' or 'read-only,' "
This means that there are some leaks in some versions of IE
which makes IFRAMEs reachable, controllable and writable.
(if you can read the contents of the frame, it is quite possible
that you can reach it's DOM structure, you can javascript methods
that reside in the frame document etc.)
Having not found the fact above satisfactory enough, we conducted
further research on the subject:
http://insight.zdnet.co.uk/software/applications/0,39020466,2124604,00.htm
http://www.securiteam.com/windowsntfocus/6L00C1P5PG.html
say that:
" Iframe and frame elements in the WebBrowser control often
contain URLs for other Web sites, and most times, strict
security controls manage these potential cross-scripting
threats. The problem GreyMagic discovered lies in just
one property, Document, which isn't properly protected in
several versions of IE (as specified below under
Applicability).
What this means is that, for example, oElement.document
provides a link to the current element, but
oIFrameElement.Document will return the frame element with
no security check to see whether it is coming from a
different domain.
THIS PROVIDES FREE AND FULL ACCESS TO THE FRAME'S
DOCUMENT OBJECT MODEL"
Applicability:
IE 5.5 with Service Pack 2 installed and
IE 6 without SP1 installed are both vulnerable
Risk level --
critical
Fix --
Upgrade to IE 6 and install SP1. "
This means that even internet explorer 6 without having applied
its patches is insecure.
After having seen this we have absolutely concluded that:
Our HTC files are not secure, any call can be executed through them once
the hacker manages to log in to the system.
We want to underline this again: If the user cannot login to the
system, he has no security threat at all.
Other related links:
http://support.microsoft.com/default.aspx?scid=kb;en-us;168485
http://www.pcworld.com/downloads/file_description/0,fid,5485,00.asp
http://support.microsoft.com/default.aspx?scid=kb;en-us;167614
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/xframe_scripting_security.asp
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/sec_dhtml.asp
http://support.microsoft.com/kb/q167614/
http://support.microsoft.com/kb/q168485/
http://www.microsoft.com/windows/ie/security/default.mspx
http://news.com.com/2100-1001-215275.html?legacy=cnet
http://www.nwnetworks.com/96-02iesecurity.htm
Let us continue our discussion with a case study:
Scenario:
The hacker successfully logs into the system, by somehow stealing the
username/password. The hacker by using the HTC vulnerability executes
any method on our servlets.
It's not hard to guess which methods are executed on the servlets:
The data is sent to servlets through HTTP POST, and not HTTP GET.
Thus if the hacker observes his browse history, he can easily find which
servlet is executed with which parameter.
This is a security problem:
The data has to be sent to the servlet via HTTP POST, through and intermediate
form, not from the querystring.
Now let us ask why 5 times:
Why do we have a leak in the HTCs?
Because some versions of IE enable frame spoofing,
and some IE versions do not fully conform to the
cross-domain security principles.
Why does frame spoofing affects us this much?
Because, our HTC components use IFRAMEs to
send and get data, to avoid full page postbacks.
This makes the application asynchronous and user-friendly.
We have caught it in the second why!
The main problem is not using HTC, it is the IFRAME that
resides in the HTC.
So can we use another solution instead of IFRAMEs for async data
transfer?
Yes XMLHttp ActiveX control will allow it.
We have to ensure that the entire application is not within a frame
(and thus susceptible to spoofing) as well. It can be done with a
script like:
if (top != self) {
top.location=self.location;
}
So how secure is this XMLHttp transfer?
Since this method requires higher versions of internet explorer, the
hacker will not be able to benefit from the vulnerabilities of former
versions of IE.
Other security leaks?
As stated above, sending data over HTTP GET is a leak. We have to use
HTTP POST instead.
It's risk?
Not that much as the "frame spoof" issue. But we have to avoid it none the less.
* Trusting the client is a mistake. Let us demonstrate with a simple example:
telnet www.xxx.yyy.com.tr 80 (enter)
GET /index.html HTTP/1.0 (enter)
Referer: http://www.hahaha.com (enter)
User-Agent: Mozilla/4.0 (compatible;
MSIE 9.0; Windows NT 6.0; .NET CLR 1.1.4322; .
NET CLR 2.0.50215) (enter)
We have spoofed the server that we use internet explorer version 9.0,
and come from the site "www.hahaha.com".
Thus:
- You cannot trust the javascript that reside on the client.
- You cannot trust that the client declares the correct browser version.
Another quote:
"
With sessions you have the compromise of having to to trust
the client to give you the right session id. Every time you|
get that ID, re-verify.
One other thing is active sessions can be hijacked
(by anyone with the correct session id) - so you could have
two clients with the same id. It's a good idea to check IP
address (and perhaps make a hash (e.g. md5) of
IP address + user agent ($_SERVER['HTTP_USER_AGENT'])
to verify the session hasn't been hijacked.
"
Okay, the server can be spoofed. So let us do the version checking on
the client.
<script>
function btnLogin_click() {
/*if don't have proper object, deny access*/
if(document.all&&
document.getElementById&&d
ocument.getElementsByTagName&&
event&event.wheelDelta) {
postLoginForm();
}
else {
alert("browser not supported !);
}
}
</script>
The script above is based on object detection, and will not post the login form
unless the client uses MSIE v6 or above.
Now let us write another story:
"
'code execution via javascript'
A second flaw in Firefox 1.0.3 and the Mozilla Suite 1.7.7
allows an attacker to inject script into any site by
loading it in a frame and navigating back to a previous
javascript: URL containing an eval() call. This can be used
to steal cookies or other confidential data from the
target site.
This attack can be combined with the first to
execute arbitrary code.
"
references:
https://bugzilla.mozilla.org/show_bug.cgi?id=292691
https://bugzilla.mozilla.org/show_bug.cgi?id=292499
https://bugzilla.mozilla.org/show_bug.cgi?id=291745
Which means if we install mozilla 1.0.3, with a few hacks, I can
run any javascript I like on the browser, So I can theoretically
bypass the login check by loading the page within a frame and calling:
myframe.btnLogin.onclick=null;/*kill the old event handler*/
myframe.btnLogin.onclick=function(){postLoginForm();}
Our colleague, has even said that there are some browser versions,
which allow alter javascript code before execution. Having heard this
we got shocked. We should never trust the client.
- Neither client-side browser detection
- Nor any client-side validation scripts are trustable.
Solution:
Everyhing should be checked, both on the client and server.
Just another entry for your interest:
"Don't trust client-side scripts. Some programmers write
JavaScript programs to check the validity of input fields
on forms before the form is actually posted to the server.
Although there is nothing wrong with this - you can use
it to immediately notify users if something was wrong,
lowering the load on the server - you should still recheck
all data on the server.
JavaScripts can be circumvented, so don't trust them. "
Actually we cannot trust CSS as well.
As you know there is a concep of "user defined css"
Here is a scrap of our master css
<file hidden for confidentiality purposes>
Let us override it by the following user-defined CSS:
<style>
input {behavior: none !important;}
button {behavior: none !important;}
...
form.WAForm {behavior: none !important;}
...
GM\:LOOKUP {display: block;}
GM\:ROWEDIT {display: block;}
TABLE.xmlTable {behavior: none !important;}
...
.invisible {display: block;}
.hide {display: block;}
.hidden {display: block;}
.movable {behavior: none !important;}
</style>
As you see, we have changed all the hidden areas on the page, to visible.
We have removed all CSS-based validation and CSS-based behaviors.
Now the user can enter his fiance's name to, say a datetime field,
and no client-side error will be generated. Since this field is not
validated on the server, it will cause either server-side exceptions
or data corruptions. The two of which are equally bad.
Our humble opinion as the commitee:
- CSS has to be used for only presentation.
- There should be no functionality difference between a system with CSS
and a system without css.
Let us turn to our good old hacker:
Say that his only goal in life is to hack our site:
He may write a browser wrapper, get a open-source browser and modify
its engine to suit his needs.
Say that in his browser there will be no type=hidden and type=password
so <input type="hidden" /> and <input type="password" /> will default
to <input type="text" />
- there will be no attribute "disabled" or "readonly" (NS4, does not
have such for instance)
- there will be no CSS support (so our behavioral controls, display:none's and
visibility:hiddens will not work any more)
Or without having need all these, he can easily write a low-level
app, that communicates with the server via HTTP gets and posts.
(This can be easily achieved by using System.Web namespace in c#
or using java.net package in java)
you may
(google: xmlHttp)
(google: browser wrapper)
(google: handle cookies using java.net api)
(google: session hijacking)
(google: frame spoofing)
(google: cross-frame security)
(google: don't trust client side)
(google: best practices for login page protection)
(google: How to Spoof HTTP_Referer)
(google: security best practices)
This entry below is about session hijacking:
"
All in all, sessions with cookies are very nice,
but there's still a problem: the session identifier
(in the cookie)
is passed along with every request in plaintext, so
package sniffers can easily intercept this data.
Once someone hijacks a session
identifier (the cookie), he can easily make a
cookie of his own with that same identifier,
thereby stealing the session.
"
By the way, we don't need to connect to system via ADSL.
If the hacker is to hack in the system, he will preferably
use a analogous dialup network, so that he cannot be
detected easily.
Here, we are not considering the standard user. We are
discussing the possible abilities of a pseudo-attacker.
- We should definitely use SSL.
Our application, in terms of security needs, has no difference
than the e-mail providers, or online-banking applications, that
use SSL during the entire transaction.
To make session hijacking difficult, here follows a suggestion:
"
To make session hijacking impossible, you need to be sure
of where your data comes from, and you can't.
But you can make it harder:
Store the user's IP address and any other information
passed along with every request in the session
on the server-side.
On every user request, check if the owner of the session
identifier is still the same. This isn't perfect, because
all data the server uses to identify the user is passed
in a plaintext format, so any hacker can steal it.
But then he must know what to steal, and he must
certainly spoof IP addresses, which is pretty hard.
So it's something.
"
Another notice:
"
One final thing - don't pass session ids in the URL (which
is possible) unless you really have to. This shows up in
every web traffic log between the client and server, making
hijacking much easier.
"
We have been using this to prevent cahcing, we should use
pseudo-random alphanumeric data instead of the session id.
- Another suggestion.
We should keep the login count on the database
After 6 consequitive unsuccessful login attempts
we should block the user account, give the user a new password, and a
new username if necessary.
- We have to enhance the logging functionality of both the router and
the web server.
- We suggest to change our password policy. We should generate random
alphanumeric passwords every 15 days and SMS the passes to the users.
- All the clients(agents in our case) should be told not to share
their passwords, they have to be periodically observed, if an agent is
detected not adhering to this password policy,
1. S/he should be warned.
2. If s/he still continues, s/he should be financially punished (a
decrease in salary)
3. If s/he still continues, thier right to access web should be suspended.
<summary and other references>
Regards, etc.s,
Me and other team members
-------------------------------------------------------------
It was a long post,
hope it is worth reading.
Cheers,
Volkan.
On 6/1/05, Mark Groen <markgroen at gmail.com> wrote:
> ----- Original Message -----
> From: "VOLKAN ÖZÇELIK" <>
> To: <thelist at lists.evolt.org>
> Sent: Wednesday, June 01, 2005 9:04 AM
> Subject: [thelist] Are there any security leaks of HTC's
>
>
> Hi everyone,
>
> Do you have any web site / reference on the security leaks of
> Microsoft's (sigh) "HTC components" ?
>
> I've googled around but couldn't find any satisfactory answer.
>
> Are there / have you experienced any security leaks (I've heard that
> there are, but cannot find anything) or are they innoncent ?
>
> You may be googling for the wrong term as htc is used for a lot of acronyms.
> Try DHTML security instead.
>
> (February 15, 2005)
> http://www.microsoft.com/technet/security/Bulletin/MS05-013.mspx
>
> For myself, I keep up with the patches from M$, (still using Win98,
> happily), so javascript holes aren't a concern. Some clients want their
> png's and hovers to work, and htc gives you access through javascript to css
> behaviors and image filtering that you can't get otherwise for IE.
>
> I'm thinking the answer is: yes, if you aren't patched and using IE then you
> could be abused.
>
> hth!
>
> cheers,
>
> Mark
>
> --
>
> * * Please support the community that supports you. * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>
More information about the thelist
mailing list