What are the specific security risks of this web services architecture?

Question

I need ammunition to try to promote WS-Security for a set of externally-available web services that interact directly with our production customer service application. My vision is to implement IPassword provider and authenticate with our AD store. The architecture recommendation that came down from on high is SSL, with an IP filter on the router to only allow certain IP addresses to call the web services. Access will be granted with a GUID key. No login or password required.

A key will be granted to each partner authorized to access our web services. It will be generated by us and probably emailed to them. There is no expiration policy that I'm aware of.

This feels wrong to me, but they're not buying my argument that there is no actual authentication in play here. What specific security risks are there with this architecture? Exactly what attack scenarios are possible and how easy would it be to compromise our systems? I need to be able to detail the risks, possibly even demonstrate them to our architecture team.

Answer 1

Depending on how you're checking IP Addresses, it is possible these could be spoofed quite easily:

http://en.wikipedia.org/wiki/IP%5Faddress%5Fspoofing

Answer 2

That's pretty secure. Spoofing an IP address at the router level is pretty hard and is a common security approach for banks. By locking it down by ip adress at the router, you are pretty certain you know which organizations will be accessing your web service.

It sounds like a two factor authentication scheme, but to say that it is "air tight", I'd have to hear more about the guid key and how that is going to be implemented. Is everyone going to use the same key, or will it be different for each person/application accessing the web service?

Their approach actually seems pretty sound. The IP Address acts as a "user name" and the guid represents the "password" in a traditional user name / password model. IP Address at that level of the stack are very hard to spoof, because the IP address is essentially verified by the ISP. Spoofing an IP address on the upstream to cause a DOS might be possible for someone less experienced, but actually spoofing the IP to open between your service and a "rogue" client is extremely hard.

The most secure approach would be to combine the two by using IP filtering at the router, and force the use of a user name and password all through SSL.

Answer 3

You may be fighting a losing battle.

No security is foolproof - if you build it someone can break it. The level of security is dependent on what you are securing and the resources at hand. The proposed solution is very reasonable for many applications. Some one who has the resources to hack it has the resources to hack your solution. It probably is harder to hack the former.

The other issue is resources. Maybe the ops team can better handle security. In short even with the best arguments you may not prevail.

Answer 4

Your GUID/SSL method has holes. The ability to spoof IP adresses is available and if an email is intercepted with the GUID key - You're compromised.

WS-Security is an established protocol and that means it's been studied and hammered at by security researchers and Doctorates. These are the people to trust when implementing security measures. Whereas home baked security almost always has critical flaws in it.

Answer 5

Well... there is so much that can go wrong here...

For one, the SSL server certificate only protects you against normal eavesdropping and if done correctly the identity of the server. It doesnt ensures who the client is. (Im assuming you are doing the proper security checks on the servers certificate on your client).

But that tells the server nothing about the client. To do that you need to also assign a client certificate and validate it on the server and even then this solution is still vulnerable to man in the middle attacks if not done correctly.

Going back to your configuration. If your server certificate validation is not done correctly someone could not only eavesdrop but also inject/modify the information on your communication channel (since you are not performing any signature on the message itself to verify it wasnt modified).

The IP filter is pretty weak, since most institutions have some NAT or Proxy configurations for outside access. So pcs with outside access through the same node would show the same IP. So no "spoofing" is required... you just need to compromise any of the internal machines... like a secretary's machine (giggles).... and make the requests from there.

The IP Spoofing im not sure would be a valid attack, in this case an attacker would cause a denial of service on the client machine and then try to connect to the server forging the packets and taking advantage that the spoofed client cant respond and rst the packets to terminate the connection.

It would imply guessing the package sequence number, which is hard now days, but not impossible. from there an attacker can inject blindly whatever message he needs but in this case since the connection is not plain html but an ssl stream which involves exchange of info like keys etc, and given that the attacker cant see, since the injection is done blindly (at least unless its in the same subnet and can sniff the packets)... i doubt its possible.

Anyways... recommended configurations.

1 - Server SSL certificate with validation on the client. - Client SSL certificate with validation on the server. - Some sort of checksum of the message, besides the GUID token.. which i would advice to be generated each time for each session-client. (Dont forget to distribute this certificates securely on encrypted stores pkcs12 etc otherwise this approach is susceptible to man in the middle attacks)

2 - Extend the web service soap message with the WS-Security and use client and server signature/encription with Client and Server certificates, and use timestamping services.

You can still ip bind the connections... but there would be no need... and its still weak.

On a side note, IP spoofing was used by Kevin Mitnick against Shimomura back in 1994... so it is possible and not extremely hard. I bet that depending on your servers OS version there are tools that automate most of the process already.

Id love to hear what others think. Hope this helps.