Appsec Question

Bl8ckr0uter

greetings,
Our web developers and I are having a disagreement at work in regards to security. Our web servers pass information to out back end web services boxes in clear text. While the session is protected by ssl I still think we should hash the information inside and or encrypted before transferring it. They disagree and say that ssl is enough. My boss agrees with them. Any thoughts on this?

rogue2shadow

Who's arse does this fall on if the information is compromised? :P

Bl8ckr0uter

rogue2shadow wrote: »

Who's arse does this fall on if the information is compromised? :P

Not mine. But what I want is some sort of quantifiable measurement that shows how SSL doesn't provide enough protection. I mean a lot of security is "security theater" but this guy is not the type (neither is my boss). I may feel bad about it doing what it does but they will shrug it off until I pull out some numbers. I have a way of showing that but I'd still like to have a job later lol.

rogue2shadow

Bl8ckr0uter wrote: »

Not mine. But what I want is some sort of quantifiable measurement that shows how SSL doesn't provide enough protection. I mean a lot of security is "security theater" but this guy is not the type (neither is my boss). I may feel bad about it doing what it does but they will shrug it off until I pull out some numbers. I have a way of showing that but I'd still like to have a job later lol.

Got ya. I've seen stuff on securitytube regarding "SSLStrip" which I think is part of metasploit (correct me if I'm wrong). It does exactly what its title insinuates. If you have an internal auditor who'd be other to try it out maybe the "seeing is believing" effect make take hold on them (of course, he/she would need something legally written up to perform this).

Informative view:
Defeating SSL using SSLStrip (Marlinspike Blackhat) Tutorial

Straight to the point:
SSLstrip Tutorial Tutorial

it_consultant

Unless the attacker is in the LAN or in the customer's house then SSLStrip is useless, it relies on man in the middle techniques. If the cleartext information is being sent from two points within the LAN (ie from front end web servers in a DMZ into a back end database) then cleartext is OK and probably preferable from a performance standpoint. You could use IPSEC policies between the front and back servers which will put another layer of encryption on the traffic.

SSL is far from useless. If you dont have a man in the middle attacker who has successfully mirrored all the traffic on the root network switch then it will be very hard to crack the encryption. If you can monitor both sides of the conversation you could get the encrypt and decrypt keys that are generated at the beginning of the conversation. Thats even harder than SSLStrip.

it_consultant

Forgot one thing, I remember this from some pen testing I have done. If you are looking for a place to plug in to do a man in the middle, look to see where their websense is plugged into. It may be between the firewall and a stack of switches either plugged into a small smart switch or a dumb hub. There, the part where I said "mirror all the traffic to one port on the hub switch" has just been taken care of!

Bl8ckr0uter

Thanks for the responses guys:


@IT_Consultant:

I would still feel much better if it wasn't plain text across the browser. Im your experience do have you seen that most web developers do send information in this manner?

it_consultant

Bl8ckr0uter wrote: »

Thanks for the responses guys:


@IT_Consultant:

I would still feel much better if it wasn't plain text across the browser. Im your experience do have you seen that most web developers do send information in this manner?

Heck no, I thought we were just talking about plain text between the web servers and the back end servers. If, for example, you put a password in a website and you can see the PW in the URL string...that is not good. The risk being that someone can either see over your shoulder or can parse your internet history if your computer is stolen.

Bl8ckr0uter

it_consultant wrote: »

Heck no, I thought we were just talking about plain text between the web servers and the back end servers. If, for example, you put a password in a website and you can see the PW in the URL string...that is not good. The risk being that someone can either see over your shoulder or can parse your internet history if your computer is stolen.

I mean between web servers and back end servers. I still think that information needs to be hashed and/or encrypted. Regardless of the likelyhood of someone MITM our site. IPSec is a good idea.

it_consultant

I think IPSEC is probably what I would do since it encrypts all the traffic between the servers and is fairly easy to implement.

Bl8ckr0uter

it_consultant wrote: »

I think IPSEC is probably what I would do since it encrypts all the traffic between the servers and is fairly easy to implement.

It does make sense. I did watch the videos on SSL strip last night and it makes it even more obvious to me. Basic constraints is a pretty powerful field in a certificate. I think I really need to do some more studying/labbing with PKI and SSL to "see" this stuff in action.

RobertKaucher

What type of data is this that is being xfered?

Bl8ckr0uter

RobertKaucher wrote: »

What type of data is this that is being xfered?

Sensitive information. I don't know if I can legally say.

RobertKaucher

Bl8ckr0uter wrote: »

Sensitive information. I don't know if I can legally say.

Is there a legal requirement to go beyond something other than SSL? Is there a legal requirement regarding the data for your industry at all?

Bl8ckr0uter

RobertKaucher wrote: »

Is there a legal requirement to go beyond something other than SSL? Is there a legal requirement regarding the data for your industry at all?

Yes. HIPAA requires PHI data in transit to be "protected". I read that as encrypted since if the session suffers a MITM attack, the data wouldn't be protected.

it_consultant

HIPAA would not apply in this case since the information being transmitted in clear text is not publicly available. I assume everyone working there has had a HIPAA compliant background check. Physical security is also important, can people just walk into the server room? Do you use cipher locks or keys? Often, in practical terms, a locked door will stop most man in the middle attacks. Your coworkers are right in a lot of ways in assuming that SSL is secure enough for this task. Securing it inside the LAN is a little overboard. You should be more concerned with the possibility of a data leak from one of the employees. Those are far more common. Those cannot be stopped by IPSEC or SSL.

Bl8ckr0uter

Now that I think about it, the ipsec might be enough. IPsec would be basically make an authenticated and/or encrypted session. I would then use like AES to actually encrypt the "data". Well maybe I'm confused because would AES actually encrypt the "data" or the session that the data is flowing through? My thought is that it would be the later and if so, if the session is hijacked then the data would not be secured. I need to do some review of my ISCW book tonight lol.


Any thoughts?

Bl8ckr0uter

it_consultant wrote: »

HIPAA would not apply in this case since the information being transmitted in clear text is not publicly available.

What do you mean by this (not publicly available)? Are you saying that since it is going from our DMZ to our backend servers and is not on the public internet it doesn't "need" to be secure(encrypted)?

it_consultant wrote: »

I assume everyone working there has had a HIPAA compliant background check. Physical security is also important, can people just walk into the server room? Do you use cipher locks or keys? Often, in practical terms, a locked door will stop most man in the middle attacks. Your coworkers are right in a lot of ways in assuming that SSL is secure enough for this task. Securing it inside the LAN is a little overboard. You should be more concerned with the possibility of a data leak from one of the employees. Those are far more common. Those cannot be stopped by IPSEC or SSL.

Yes to the first. We do not use keys. I agree with you on the data leek piece...

Maybe I'm being a noob or something but I just think that regardless of SSL or not, the data itself should be encrypted (and hashed). Maybe SSL is enough and all of this is a moot point.

RobertKaucher

Bl8ckr0uter wrote: »

Yes. HIPAA requires PHI data in transit to be "protected". I read that as encrypted since if the session suffers a MITM attack, the data wouldn't be protected.

My wife is the corporate compliance associate for her company (mental health, spans two counties) and we regularly discuss this type of stuff. Your current SSL would be in compliance. That brings it to a question of practicallity. Would using IP Sec actually add any value? As far as I see it, no. Because the SSL exploites you are looking at require MITM and if I understand it the data is running on a subnet for servers, correct? If a person can place a MITM on your internal, server subnet you are screwed to begin with.

What is the reality of someone being able to compromize the subnet in this way? They need to compromize the subnet either physically or a machine and install virtualization software and launch their own server. They would also need to compromize your DNS and not be noticed. Is this scenario likely enough to warrant the additional overhead/administrative cost of adding IP Sec? In my opinion, no. Because it is such an unlikely scenario and goes beyond what HIPAA would consider "reasonable steps" in this situation. Energy would be better spent in securing other areas of the infrastructure to ensure that such a scenario is even less likely to occur.

Consider it this way. Your backend cannot be held to a higher standard then your front end. If HIPAA says SSL is ok when the patient is viewing data via the web (where a MITM attack is far more likely to occur), how can it be argued that the back end data (already much more secure) needs to be held to an even higher standard?

Bl8ckr0uter

I see your point. Maybe I'm just freaking out because February is just a few months away and come then, I could get sued, personally.

it_consultant

Its harder to execute a MITM attack than you might think. Its very easy for sensitive data to be left in public on an unencrypted drive. 90% of security is behavior.

rogue2shadow

it_consultant wrote: »

90% of security is behavior.

Great quote.

Bl8ckr0uter

it_consultant wrote: »

Its harder to execute a MITM attack than you might think. Its very easy for sensitive data to be left in public on an unencrypted drive. 90% of security is behavior.

Very true. I agree 100%

RobertKaucher

These are the kinds of conversations that make you grow as a professions, I think. Help keep a person balanced.