Security concerns

From The Okopipi Wiki

Jump to: navigation, search

Note to reporters: The information contained on this wiki page is not official documentation.


Contents

Introduction

This page is where the likely threats are enumerated with the current model. Please contribute to the threat model, and use the discussion pages regarding STRIDE / DREAD ratings.

STRIDE / DREAD

The Microsoft Threat Modelling system (http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx Microsoft Threat Modelling Center) is the best way of discovering weaknesses, and documenting their relative strength

NB: The Discoverability aspect in DREAD is automatically 10. This is a very public protocol.

Asset classification

People

Irreplaceable: therefore high risk

  • Handlers
  • "Hidden" server system administrators

Physical assets

Easily comes and goes, therefore low risk

  • Nodes in the peer to peer network
  • "Hidden" servers
  • Internet

Data assets

Need some thoughts here. Suggest high risk as it doesn't work without these

  • Categorization list (URL to ping, etc) used by nodes to ping uncooperative spammers
  • Handler map data
  • Spammer do not intrude list

Processes

  • Categorizers -> Categorization
  • Nodes -> Pinging the spammers
  • Nodes -> Distribution of the categorization list
  • Spammer -> clean their lists

Others...

Threats

Please contribute to this - use a third level heading. In time, we might need to break it into handler / p2p / etc to make it easier to find the threats.

Open vs. Closed

STRIDE: Information disclosure, Denial of service

The system being proposed is one of two layers. It is currently thought that only some of the handlers will know the IPs of the core NBF servers. This being the case, however, it is evident that the handlers that know the location of the core servers are higher in the hierarchy ("superhandlers") than those that do not.

The knowledge of whether a handler is merely just that or a "superhandler" should be very well-guarded. If it gets out, the spammers could attack the superhandlers directly, which would have much the same effect on the network as if the core servers were attacked. Messages will have to be bounced around a lot before they reach the superhandlers--which means the network will be secure, but not very bandwidth-efficient.

We also need a wide net of standard handlers--I'm guessing numbers in the hundreds. Their number makes them too wide a target for the spammers to attack, and they'll have to attack them all, as they still don't know which of the hundred are the handful of supers. And now we arrive at the issue--the system needs to be open enough so that we can get a large number of handlers, but closed enough so that the spammers can't run handlers and cause messages to disappear or otherwise disrupt the communication.

Correction: You're assuming that the spammers would only attack handlers if doing so can shut down the network directly. No -- they would attack handlers to discourage individuals/companies from volunteering. Would you volunteer as a handler if you stand a 1:20 chance of totally losing your company's online revenue stream (and possibly your customer's credit card data, etc.) because of it? 1:100?

Further Correction: This would not take much bandwidth. It's not like we are doing large file trading here; it's encrypted text. This type of network would likely run well over something such as dialup--even with all those queries. (JDShewey aka morphius)

DREAD: Automatically 10, due to concerns for the handlers' safety

Threat: Attacking the Internet

STRIDE: Denial of service

The spammers need the Internet to make their illicit money, and are simply too stupid and greedy to do this for long (or they would have done it already). Taking it out is akin to mutually assured destruction, and would be seen as terrorism by even relatively weak cyberlaw countries, thus provoking a black helicopter response once a digit or three is extracted from a dark place. Therefore, I do not think this would be a likely scenario ... for long.

DREAD: 10 + 10 + 10 + 10 + 10 = 50 / 5 = 10/10 = Extreme risk but unlikely.

ChrisRLG : Superhandlers to ALWAYS be on dynamic IP's - not fixed. Superhandles to also bounce a % (say 65%) of the received messages on to other handlers too - otherwise they would always be receiving and never transmitting to the other handlers. Yes thet will add to the traffic - but for good reasons.

Threat: Attacking the "hidden" servers

STRIDE: Denial of service

THe security of the project currently relies upon hidden servers. There is no such thing. Given that the adversary has already shown the ability to take out parts of the Internet at will, the adversary will use a binomial attack against tier 1 network providers to find out if that network is hosting one or more of the hidden servers. By necessity, we need to distribute this function throughout the peer to peer network to avoid this attack.

  • There is such a thing. Please see my post reguarding the mechanics of this. (JDShewey)

DREAD: 10 + 10 + 10 + 10 + 10 = 50 / 5 = 10/10 = Extreme risk.

Threat: Attacking the handlers

STRIDE: Denial of service (in fact, life threatening)

This is definitely a problem, but one which if there are enough handlers (say 100 or 150 volunteers) makes it that much less likely that attacking one or two of them will make any difference to the spam meisters. The moderators must be anonymous participants.

Attack methods: I imagine if I were attacking this system, these 1st-level handlers would be my target. I'd set up a series of Okopipi clients, so each would get a different list of handlers. I could collaborate with others to build a list with good coverage of the complete list of handlers, though finding even 20-30 would be sufficient. Then we would attack them directly. The goal wouldn't be to shut down the network, but to expose volunteers to an unacceptable level of risk. IPs can be DDoS'ed, or used to lookup sites (personal? business?) hosted on that server, contact information, etc.. Even a fairly scattershot attack including DDoS's, threatening email (or snail mail/phone calls), cracking attempts, etc. could be quite successful in stopping volunteering, making ISPs wary of hosting volunteers, etc..

  • Agreed. This is why changing the IPs of the super nodes and/or using Tor won't make any difference. Remember: this is a gunfight. You're building a gun that will annoy the spammers. The spammers already have guns that will take down Tier 1 providers. The bigger the network gets, the more spammers are annoyed and the more actively they'll fight to take it down. DDoS attacks from spammers are going to hurt innocent bystanders. They're going to cost real businesses real money (probably a great deal of real money). Everyone here must be ready to explain why you're picking this fight in the first place. If a pissed-off CEO is asking the question, the answer had better be more convincing than just "we're fighting spam" or you're going to end up more hated than the spammers. (samc 11:50 EDT 2006-05-26)

DREAD: automatically 10/10. Extreme risk

Threat: Attacking the peer network

STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of privilege

  • Spoofing: injecting bad URLs to attack competitors. Injecting "good" but false entries to make the pings slow down.
  • Tampering: if there's no method of protecting message integrity, the attacker might be able to insert themselves in the middle and play with the messages
  • Repudiation: if there's a cancel message, a rogue client might be able to kill all "ping this spammer" messages
  • Information disclosure: We cannot have rogue clients working out which nodes are super nodes, or any information about who's who in the network
  • The network infascructure is masked as described here, resolving this issue
  • Denial of Service: basic flooding, other attacks against the p2p network layer
  • "Valid" mass poisoning: A spammer might install altered Okopipi clients to 100K bots; these would simply submit randomized, false (or joe-job) spam reports at normal activity rates.
  • Elevation of privilege: if there's a super node concept, the spammer might be able to become a super node and control flows etc. Suggest no super nodes for any length of time, or use voting to eliminate rogue super node results.

DREAD: 10+10+10+10+10 = 50 = 10/10. Extreme risk.

Threat: Attacking development

STRIDE: Spoofing, Tampering, Information Discovery, Denial of service (primary attack)

A single place (like this) makes this the weak point for the replacement for Blue Security. Propose a distributed method of developing the protocol, ensure the protocol is open and easy to implement (absolutely NO WS-Security or SAML mistakes here!), and let developers go away and make as many implementations as possible.

DREAD: 10 + 3 + 3 + 1 + 10 = 27/50 = 5.4 = Medium risk.

(threats taken from my (Andrew van der Stock's blog entry (http://www.greebo.net/?p=339) and contributed here with my full blessings.)

Threat: Attacking DNS servers

STRIDE: Denial of Service

This is the attack that took Blue Security down for about 5 days. What a DNS does is convert a website name e.g. "www.google.com" and convert it into an IP address e.g. "66.249.89.99".

To prevent an attack like this happening it is best to limit use of web addresses. That way a DNS server will not be needed for most of Okopipi's processes.

DREAD: I don't know how to calculate this, could someone please do it or at least show me how? --Thematrixeatsyou 00:42, 27 May 2006 (PDT)

Retrieved from "http://wiki.okopipi.org/wiki/Security_concerns"
Personal tools