Where is the new Winmx ?

[GhostShip]

The main effort of our network spoiling attacker is directed at keeping Pri and Josh's site in business, fake channel list requests make up the majority of the false traffic, searches are intermittently made to selected search terms and when those are undertaken by real folks the results are spoofed to appear from anywhere but the server operating the attack, ordinary domestic ISP's block this raw socket level spoofing activity so we know a server is in usage at least.

Most of you know the methods of attack target either the initial chat or search requests or the resulting replies to individual clients, replacing the channel results has helpfully been done by Josh and Pri but for legal reasons its not possible to outsource the search results traffic in a similar way, this is why the effort has always been on a new client once it was found a super-patch wasn't going to be able to kill the crap traffic, the Winmx protocol system has fundamental problems and we cant build on sand, simply changing the packet number would only fix the traffic till our attacker had time to add that new packet number to his attack software, something more substantial is required, the sensible way ahead is in cryptographic signing of a more substantial level than the simple method that was broken by Josh Hollow, Piney some years ago.

Atm the attacker can legitimately sign his attack traffic using a network key gen from another chunk of software, its this and the failure of mx to check some of the data fields that has allowed the bulk of the attacks and thus the area of most attention really should be focused on replacing the weak flood broadcast  protocol elements. even adding a simple crc and time related field to each packet would substantially impact the attacker as then each packet would need to be decrypted read, messed with and a CRC recalculated for each packet before broadcasting it again , this would be required for each packet he intercepts and thus would require a lot more effort from him, by adding further processor intensive measures that waste processing time it might delay the traffic a bit for the home user but for a greedy attacker trying to slurp the whole network it would cause them a more substantial workload, that and some basic changes to the pri to pri interlinking could deliver enough of a hurdle to give us the advantage at long last, proper packet signing to replace the simplified and now broken method would in my opinion fix the root issue but implementing that would need for us to break the current system and so we need new software to achieve this once again, this is a circular issue and the way out of the loop is in factoring in new loops of effort and hurdles to outside attackers, cryptographically as well as using the distributed nature  of the network to place a higher level bar to outside attacks that rely secondly on the home users having more distributed processor cycles than the attackers server can muster, there are further ideas of this nature including packet size and packet number index offsets that can add a whole range of extra tasks to the attacker, turning the tables is the way ahead and we should be working on theoretical models now to reach a system of  checks and validation by the addition of new challenge packets that can be used per network hop to ensure crap traffic remains a less than viable attack method in the future.

 Now how about we devote some space to discussing that lot and look to the future instead of worrying about the current src that's simply part of the solution but wont offer all the answers to questions regarding our  future ?

We need a solid protocol base or we have achieved nothing.

[NISSE]

So is there a timeline even with minimal input, are we taliking months or indeed years
before we can have a functioning client that will download and upload?

[GhostShip]

Have you actually tried the beta client Nisse as it already uploads and downloads although there are some times when they fail due to non full implementation of the que system.

[wonderer]

right feature? ok i make a humble request that search and transfers work... dont care if chat works or not lol...

The right feature is, make no mistakes, the feature that captures coders interest, this might or might not be what you would like most

[NISSE]

Have you actually tried the beta client Nisse as it already uploads and downloads although there are some times when they fail due to non full implementation of the que system.

Yes I have tried it Ghost and it doesnt work.

So how far away is it?

[silicon_toad2000]

We've been through this a few times nisse, the answer is the same.
There is no timeline, there is no release date.
It will be released when the developers feel it is good enough for another release.
The same as it was last time you asked under any of the names you have used and it will be the same if you need another name to ask under.

If you say it will never be ready then walk away and that will be the truth for you.

[NISSE]

We've been through this a few times nisse, the answer is the same.
There is no timeline, there is no release date.
It will be released when the developers feel it is good enough for another release.
The same as it was last time you asked under any of the names you have used and it will be the same if you need another name to ask under.

If you say it will never be ready then walk away and that will be the truth for you.

I didnt ask you.

[GhostShip]

Perhaps you didnt ask Toad but hes the guy who runs the site here now and I advise you to desist from being rude.

Its no different for the staff here than it is yourself and even me we all want to have something to celebrate and tell our friends about in the future, how the network was attacked many times and yet through the power of our community was able to rise up and meet each challenge, now how about you get a bit more positive and stay patient, in answer to your question we are going to try for a release on our traditional date in sept and so we could do with some positivity and productive discussions on the way ahead to keep the folks happy that they have not been forgotten, each of us has a part to play in this network and its about time you took a part and self motivated yourself with a project of your own, how about it ?

[Plum]

As you say it can be used as a ddos tool and so the answer is a considerable amount, the client is still heavily used in Japan and that region in fact makes up the majority of the current userbase.

That gives an idea. If you want to harden the protocol, make it able to detect the type of flooding that is happening and the region responsible and quarantine it. That is, if a portion of the network doesn't play by the rules, it should be snubbed. But I guess it would have to be an independent detection (per machine). I mean, it would be tempting to use a heads up flag to send to other machines to let them know what is happening. However, such an ability could be exploited. An attacker could claim to be under attack or finger innocent machines as needing snubbed - thus disabling all traffic as an attack.

I'm just thinking out loud.

[Bluehaze]

You are hinting in the right direction. What would genuinely be good for the network?

Thank you.

[White Stripes]

As you say it can be used as a ddos tool and so the answer is a considerable amount, the client is still heavily used in Japan and that region in fact makes up the majority of the current userbase.

That gives an idea. If you want to harden the protocol, make it able to detect the type of flooding that is happening and the region responsible and quarantine it. That is, if a portion of the network doesn't play by the rules, it should be snubbed. But I guess it would have to be an independent detection (per machine). I mean, it would be tempting to use a heads up flag to send to other machines to let them know what is happening. However, such an ability could be exploited. An attacker could claim to be under attack or finger innocent machines as needing snubbed - thus disabling all traffic as an attack.

I'm just thinking out loud.

torrent clients snub users that cause too many errors so you are thinking in the right direction

[Plum]

Even the negative human interactions here can serve as learning fodder for the network. It seems we are dealing with an age old problem, and it is about trust. I used to manage online groups, and infiltration was a problem. We had to make the groups open to be found, but the more open they were, the more spammers and infiltrators could join. Being able to trust moderators under me was a problem I had. They deleted files, changed the theme to be contrary to the mission, deleted users for no reason other than not having a profile when those members were members long before they joined, etc. One moderator changed in nature and was no longer fit as she no longer agreed with the mission and was trying to convert the rest of us. So that is the dilemma here, how do you be trusting and open enough to get coders (the community) or network peers (the protocol) and yet not be resistant to betrayal, back-stabbing, spam, infiltration, etc? The community problems and the network problems are really different manifestations of the same thing - the trust level dilemma.

So overcoming the trust level dilemma will require sophistication and emotional intelligence (and whatever the software parallel to that would be). The trust ability would have to be dynamic and not either extreme. You don't want things to be unfriendly or unusable, but don't want taken advantage of or attacked either. There has to be a way to detect changing situations and to make adjustments as necessary at the community level, the management level, the peer level, and the network level.

Now lets look at peer to peer communication. I was trying to research for a question asking about what not to do when rescuing hostages. Anyway, I found a text on what to do if you are kidnapped or a hostage. One point it brought up is what to do if there are other hostages. On one hand, it is good if you can take comfort from them and console one another. That helps you keep your mind. And maybe you all can help each other plot an escape. But that is the rub. What if the hostage takers play the hostages against each other or set up a system to reward snitches? Or even worse, what if one of the "hostages" is actually one of the hostage takers? So back to the network attacks, while we could make the super nodes or primaries talk to each other in terms of network conditions, suspected bad peers, etc., and that extra intelligence could be a help, what if we unknowingly give it to the attacker, or unknowingly let the attacker feed such an intelligence gather system a bunch of BS to act upon?

And my idea on snubbing, I guess it would have to be on a per-session basis, and incremental in nature. By incremental, I mean increasing the snubbing time after each triggering event. It could be that the first time or two, an address is getting framed, or they mirrored some garbage. But as they have time to adapt/filter the garbage, if it is a good node, they should be able to re-earn a trustworthy status. But the more garbage they relay, the longer the snub time, up to a maximum (not block entirely since it might be better than nothing).

I'm still just brainstorming aloud.

[GhostShip]

An interesting read Plum, as an aside I would like to toss in a nugget of information here that I think may be relevant, to ensure a node is at the address it is claiming to be a system of packets is in usage in MX to do something called the "double handshake", I'll outline it below.

(A) sends (B) a message with (A)'s key to (B)'s broadcasted IP address

(B) sends (A) a message with (A)'s key and (B)'s own key  to (A)'s broadcasted IP Address

(A) now confirms it received the (B) key by sending to (B)'s Broadcasted IP address a message with both their own and the (B) key

(B) now actions the request of  (A) using both keys.


Both clients can now be certain that the other party can only have each others key if they are at the IP address they have claimed to be from, if (B) was lying he would not have received (A)s key, if (A) was lying he would not have received (B)'s key. 
The client key is randomised and generated per handshake so is thus different for each peer to peer connection so its no possible to pretend you got the key from a previous or earlier transaction.

Now this is a great system so why isn't it able to stop the attackers from pretending they are elsewhere ?

This system is not used per packet in the primary network and the network has to allow for message forwarding to distribute search queries etc , thus its impractical to validate every message packet as each message passes across a major quantity of other nodes, and whilst its used in some areas its most certainly not used in chat channel or search responses due to the overhead of transacting with potentially large numbers of request responders, its not unusual to see 5000 results for a popular search term, this then is how the attackers are able to play with us, how can we leverage a smaller quantity of validatory challenges without causing a massive traffic overhead ?

The answer in the genuine client was the usage of a "validatory" field in each packet, this ensured modified or changed packets where able to be detected and discarded , however the method used to validate is no longer solid and the attacker is believed to be able to fabricate this, thus in one fell swoop this allows unfettered ability to toss false traffic into the main network and thus the problem you all see today, I am not even sure this validatory field is checked properly by the genuine client as in some cases it seems to be paying no attention at all to it.

Trust between genuine peers is possible but methods to deprive those who seek to damage the network must be created and implemented and this is where the next phase of the effort needs to be, not on obscuring mechanisms, but real tools that mean an attacker has no chance to annoy us even if he knows the mechanisms in usage, if we can resolve this issue we can clear the network of phantom traffic purporting to be from random addresses in a short space of time and things will return to normal.

[White Stripes]

couldnt it do the full song and dance but only to verify an ip is good once (or every so often?) ? ... that is for the repeated packets...

[Plum]

That seems like a reasonable handshake. Here is how some people such as Steve Gibson of Gibson Research (guy who wrote Spinrite many years ago) have hardened TCP even with the 3-step handshake:

https://www.grc.com/r&d/nomoredos1.htm

The beauty of that approach is that memory doesn't need to be allocated as the ID fields are used in a way that they are biased by an encryption of the other side's ID. So subtract that hidden number from what is returned and see if that matches their IP. So this can prevent a resource leak type flood since the half-open connection doesn't need to be stored. The syn attack flood's goal is to crash servers, and the servers used to store the half-open connections, and if you eat up that stack with fake IPs the server cannot accept more until they time out. But what if you make it stateless to where the packets sent store what is needed to verify the connection? That bends the TCP rules just a little to where it is still compatible with systems that don't use that  verification (TCP calls for ever increasing ID numbers but does not say they have to be directly sequential).

Back to your questions, mainly do the verification in the most crucial spots, like initializing clients. I don't know the mechanics of the flooding in WinMX.

I had proposed a workaround from the UI side, but like I said, that should be relied on as a 2nd-line defense -- but the protocol upgrade should remain the focus. If WinMX had that, it might have been still somewhat usable, but eating up quite a bit of CPU cycles. But think about my search verification work around. It should help mitigate several types of attacks, though not prevent them. (If you search with one character less than requested and then only return those that match, that might help reduce fake file attacks too. Genuine files have the full name, while the dynamically made fake files will be missing letters.) The GUI part should verify that each hit returned fits the criteria of the initial search (unless you allow fuzzy searches or OR searches) before adding to the array in memory or displaying it. A big problem was that WinMX crashed once it ran out of memory because it naively stored everything that came in. After 5000+ fake hits, it could hang. Of course, they should have also put limits in the code to where it automatically canceled once a results queue reached its limit.

If my filtering algorithm is getting triggered, that could work as a flag that things are under attack. I am not sure what to do with that info. For instance, that could be used to dynamically harden the protocol. Some of the steps we suggest are costly in terms of CPU or bandwidth, so what if it was dynamic? It could operate in a mode only slightly more secure than now and use rather cheap checks for whether there is trouble. If there is, it can go to into attack reduction mode. So it can adjust for performance vs. safety as necessary.

I am still trying to think out how a "gossip" or  network health mechanism might work. We know that reputation systems can and do get gamed (attackers are elevated, good citizens are snubbed). If clients knew the conditions of the network, they could prepare themselves or even get some idea where the attack is originating. But I see the problems this could cause. One of the worst things to do if you are bullied is to let other bullies know you are being bullied. If you change schools and then mention you moved because of bullying, you will likely find new bullies. So you might not want to let attackers know you are under attack. If you could warn one level upstream in the direction of the attack, it might help, but what if the one up from you is the attacker? So it gets tipped off.

[GhostShip]

With a half reasonable attacker we can expect any "reputation" signalling to be the focus of an attack, we have at some place on this forum discussed implementing this to replace the broken validation system, this would increase the computational expense to the attacker manyfold as well as leave a residual key to be used in further operations however ...

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

This alone cannot be used to  good effect since the parties in the flood broadcast system are unknown to each other, but if the key generated is sufficiently improved over the existing one we can make usage of it in other ways for instance

http://en.wikipedia.org/wiki/Password-authenticated_key_agreement

This then could act as the validatory component, to good effect the overall strategy is to ensure we have strong peer to peer keys and an ability to use encrypted materials from remote clients based on a self validating message packet, how we go about this and what tweaks and twists we add are really what I was looking to focus on as we have not seen any real effort to attack individual peers but instead attacks based on using peer multiplication as a bad message is distributed amongst the peers and leads to traffic amplification, if we can remove the ability to distribute bad or malicious packets of data we have won the day.

I have tossed in these two ideas above to show it is possible to create a key in a hostile environment and its also possible to use the key to sign and thus validate a series of messages, the real issue comes in the details of how exactly we model our delivery of either key or preferably key hash data (leaving the original key secure and unknown by the third party) to legitimate peers such a hash could be added to the end of each roomlist or search result and thus allow for the possibility of computing the validity of the received messages based on a common knowledge or a public key system, the issue is with a public key system as we are familiar with the term we face the problems of who acts as the central authority of keys, I don't know about the rest of you but I don't want to see that sort of power given to anyone so we need to dig deep and look further into the fine print of how to utilise what tools we can use and create a model that's resilient but can be used to impeded our attacker, its this theoretical model we need to work on and then we can go look for code to make it happen.

I just got up btw so forgive me if this is  bit long winded or not fully expanded upon but I hope you get the general gist of whats necessary to solve our problem, if it helps I am willing to create some overview models that demonstrate some of the key area we need to cover albeit in purely a theoretical way as I wouldn't want to show actual examples of the current primary system in any great detail, lets all get our brains on this, using our combined range of knowledge it might be simpler than we suspect to plug this hole.. 

[Bluey_412]

Keep the SRC closed...

Even on this forum, the people I see pushing for open source are the very ones I would be wary of allowing access to source...

[GhostShip]

I understand your feeling on this matter, its not going to be a leap into the dark however as I'm confident we can find enough tools from the world of cryptography to ensure even the best attackers cant break the routines, the old winmx used very weak crypto but implemented many of the same clever crypto tricks  and they lasted a fairly decent time, all we need to do is look at building a model for the primary network that allows for a non spoofable signed message packet that can be rapidly checked before the rest of the packet is even bothered with, if this hole is fixed we can restore the main operations of the network in a short space of time, as long as we can be sure folks are at the ip they clam the blocklist will be able to hold out the bad folks, its just a matter of working out a model of trust, other networks have had to undertake this same effort in their evolutions so whilst I share some reservations I have confidence that when called the users will deliver the answers we need to move ahead safely, we have some of the cleverest folks on any network here now's the time for them to show off a bit 

[Plum]

I have a possible reservation about verifying IPs. It seems that if the industry or the feds got a hold of such code, they would use it to help nail people. If we can verify someone is at the given IP, and then they upload something, our own verification could be used against our users. But yes, there needs to be a way to keep out bogus IPs. We don't need to be turned into a DDOS machine or even used to DDOS bystanders (hey, if we send to non-users, it would be DOSing them).

I have wondered if each client should have an unique (but per session) ID that is kept independent of IP but can be used to maybe reduce MITM attacks and some impersonation. But what would be weird would be if two machines on the same IP were indeed running the software. So seeing that the IP is not sharing the same ID as last time could be taken as a red flag. But I don't know if such an approach would be useful.

A big concern I have is how do you encrypt searches and headers to where the other client can still get what it needs to perform whatever task and it cannot be intercepted? Oh, if you rotate things that would keep basic packet sniffers from seeing it, but everyone would know to rotate back, and thus anyone could decode it. Or many words could be compressed by use of a dictionary file to keep literal strings out of the traffic. However, everyone would have to have the dictionary, and thus attackers would have it. But that would hide the terms from the traffic, and maybe colleges wouldn't be flagging or blocking the traffic as file-sharing related.

Oh, and fake files are always an issue. I gave one possible solution for dynamically created files (search with a shorter string and then only list ones that contain the original longer string - thus not listing files created to match the string *after* the search was started). I never saw that type of fake file on WinMX, and that could be because of obscurity, not any inherent protection or immunity. (Security that relies on obscurity is never good, and only marginally better than nothing - once someone finds out, it is then worse than nothing since it would only be false security.) But that is not the only "fake file" attack type. Another is valid files with the wrong names, like someone tricking others into mirroring a movie by giving it the name of an operating system. So you think you are getting Windows 7, but you are getting some foreign movie or hardcore porn of an illegal genre. That is where URN type searches should be done. WinMX has that, but you have to use it manually. So unless you do that, you might not know that the file you are downloading has a vastly different name and extension than many identical copies. Just a simple verification here is to check the extensions against their signatures. You often know by the first couple hundred bytes what the file type is. If it starts with MZ, it is usually an .EXE (or a .DLL, .OVR, .OVL, or other x86 machine code), while "Rar!" at the beginning means it is a .rar file. If you see "RIFF" in the header, that is one of several multimedia files.

Another way to help stem the attacks would be if there were a way to verify that acceptable clients were being used. On Gnutella, I am sure they are using modified clients. They have the source... Too bad there isn't a way to only operate with clients which share the same or close version or even CRC, and only accept their results. But if the headers require a CRC, they could lie about that, so no benefit.

[GhostShip]

Security by obscurity may not be the panacea of  the p2p world but you have to admit that we had approximately 10 good years of operation before a developer decided unilaterally as some do to to give the kiddies enough information to attack the network with, most attackers are unable to deal with well designed encryption and will give up, nearly all of the problems you look at can be minimised using routines and checksums throughout the model to mitigate anti -p2p2 activity.

An important thing to remember regarding a protocol of any sort is that the attackers have to abide by the rules just the same as the normal user and this means with a sensible and well thought out network model to base the protocol on many attacks and cheats can be dealt a crippling blow,  it stands to reason clients that share false files will end up on the blocklist, some folks might think they can get away with acting in an anti p2p way but they will always find that their activities will annoy someone enough to raise a red flag, if folks don't want to share that's fine but fake libraries and modified clients that leech from the legitimate users are not what anyone wants, trust is important and thus a few hurdles to ensure a minimum level of honesty can be added to reassure the rest of the network that an individual user is acting in an honest way, forced sharing is not something anyone can demand but honest sharing with correct reporting of shares and availability should be a minimum requirement for network entry.

Winmx as a network is not an anonymous network, we all deliver our IP to each other each time we transact in some way, this is nothing new and there are few p2p networks that can deliver files without knowing something about where the files have to end up,yes there are some networks that cache data on remote machines and use other users as data dumps etc but most of these are filled with illegal pornography and heavily monitored, Joe soap using winmx or another p2p app is not a focus of most countries law enforcement as p2p is not illegal in concept or operation, sharing copyrighted materials may be an actionable civil matter in some lands but in others its unheard of for folks to be chased after, but attacks that  subvert a network to send traffic to random iP addresses and other such attacks are in fact criminal efforts and those practicing such attacks should bear in mind that they can be held responsible at any time as theres no limitation on the prosecution of crime in the majority of nations.

There are many pitfall's to look at when designing a protocol but in the main much of the key work has already been undertaken and the relevant models exist, our efforts need to focus on scouring both our minds and the web for new tricks and methods that we can incorporate into our existing model to upgrade it whilst making usage of older tricks and proven methods to rebuild upon, the model is the first step and the protocol the second, an actual end client out to work against the network should encounter both resistance locally and remotely to anti p2p activity, either play nicely or don't play at all putting it simply.