Link to home
Start Free TrialLog in
Avatar of apakian
apakianFlag for Australia

asked on

man in the middle attacks / udp protocol.


I am in the process of designing a udp based instant messaging platform, and am
at the point of writing the parts which will handle user registration...

the protocol idealy will be as stateless as possible, using simple request/reply
transactions.

assuming the request packet went something like this..

request:
---------------------------------
dword packet_identifier
char user_name_wanted[65]

reply
---------------------------------
dword packet_identifier
char password[16]

my main concern, is man-in-the-middle attacks,, someone
being able to see the password coming from the server to the client.

Even if the server encrypts the password,, at some point
along the way, a man-in-the-middle attack is possible....

A public key crypto scheme is not possible, as I am trying to keep
this as simple as possible...

My question is: is there any well known methods to prevent or
detect m-i-t-m attacks ?  I know of kerebos, but would like to
know if there is a way without using it..

ps.

Icq for example, allows you to register a new user using it's protocol,,
so how do they get around this problem.

Avatar of ahoffmann
ahoffmann
Flag of Germany image

>  is there any well known methods to prevent or detect m-i-t-m attacks ?
encryption. Dot.
either shared or public keys
Avatar of Beluga
Beluga

You really need some kind of encryption. It doesn't have to be public key encryption though, and there are other people's modules you can use (e.g. Windows crypto API, GnuPG, etc.).


write your own crypto key algorithm, make it a randomly typed GIGANTIC number and then run it through a simple math algorithm. then the computers compare the result. if it matches then success!

I.E. both recipients have a default crypto key of "9384793848974390374983749472082790863975618518", authentication is done by the sending computer challenging the recieving computer with a random number set.... that number set is then run against that crypto key via math algorith (+*%-). then the recieving computer responds with the answer, it either matches or it doesnt... that should hold someone off for a while!

crypto key = C
random number set = R
result = Z

Z= C * (R + 113 / 20) / 345
-------------------------------
 that should result a low number keeping the traffic to minumum, the crypto key will never be revealed and shouldnt take more than a few minutes to code :)
if you really wanna get complex... make the key 200 numbers long and the math algorithm even longer. will take more time to code but the computers will do it near instantly.

better yet, split the random number set into multiple variables, then run that through a algorithm.... i think that would take forever to figure out if you were sniffing for mitm attacks.

I.E. random number set to be processed is 12345678901.

A=123
B=456
C=7890
D=1
X=CRYPTO KEY
Z=RESULT

Z= ((C*A) + (C+B-A) - D) / 133 + 2

hehe you could get crazy adding to this one.


to your icq question. icq is very vulnerable to MITM attacks... the hardest part of performing an MITM attack is getting the data to run by your NIC. a person cant just connect to the internet and sniff any data he wants, he would have to be on the same physical connections (or use ARP poisoning if he knows the specific targets IP).

so unless there is someone DIRECTLY in-between or on your network, i wouldnt worry about MITM.
i would be more worried about remote attacks that would compromise a system involved. then the whole system is exposed and an undetectable source of attack.

either way, writing your own crypto key means:
a) someone cant use pre-written cracking software to defeat encryption (kiddie scripts)
b) MITM will not do their work(hack) automatically, requires user(hacker) intervention/logic to adapt
c) custom written encryption challenge means user(hacker) is gonna have to go through ALOT to figure it out.

this is the same thing as kerberos except, instead of a 3rd party handing you a dynamic key, it is a static key hardcoded into the software. either way the key is NEVER transmitted.
> .. write your own crypto key algorithm, ..
hmm, this is not recommended, usually, except you're an crypto/algorithm expert ;-)

> a) ..
most crypto is cracked using brute-force methods, so the algorithm itself doesn't matter (it just may help to shorten, somehoe, sometimes)

> b) ..
  MITM is not a reason to use a somehow unknown algorithm, see a) above

> c) ..
  see a) again

The risk to code an algorithm which is breakable is very high.
I'd use well known crypto algorithms 'cause they are known to be unbreakable, somehow, currently, ... (keeping brute-force beside, which always works)
Avatar of apakian

ASKER


Is there any statistics on how frequently or how difficult mim attacks occur on the internet ?

apak: MITM attacks are the lesser used methods of attack and gaining information. since you would have to be on the same physical network inbetween 2 hosts, its extremely difficult to gain such access. it is much more likely for a hacker to penetrate a network using remote vulnerabilities(such as DCOM or LSASS) and install software that would then sniff passwords, capture data, infect more computers or gather enough information to launch an effective attack to steal a database or any other proprietary info.

MITM attacks would be toward the lesser of security concerns, but a serious concern none the less.


hoffman: a brute force attack will not work as theres no static interface to pound out password attempts. as i said before, this is a very effecient way and secure to prevent MITM attacks as MITM is a person sniffing the data. since my above algorithm uses a challenge/response type authentication, brute force would be impossible.

duh, hoffman you didnt do much readin here and obviously you are not a security expert as all you did is criticize with no citing or logical steps forward... as i said above, the problem with a well known crypto algorithm is, theres well known exploits. i could crack WEP encryption and even RC5 using sequence prediction methods that have been discovered from collective efforts of hackers in no time....  because everyone else has already done the hard work for me.

the advantage to writing your own hardcoded key is that it would take a serious expert with some serious time on his hands to break it. im guessing it would take approx a few gigabytes of capturing challenge/respose authentications to predict the hardcoded key. that would take YEARS to capture that many authentications. and one could easly extend that to decades by making the hardcoded key twice as long.

im not a crypto/algorithm EXPERT, but i would put money says i can give em a good run for their money :)
atleast i scored pretty high on http://highiqsociety.org/

> .. you didnt do much readin here .. advantage to writing your own hardcoded key is that it would take a serious expert with some serious time ..
LOL, I read elsewhere .. and the majority there tells you that homegrown algorithms are most likely more worse than standard ones. Well, you can believe yourself or an opinion of a majority. It's up to you ;-)
Avatar of apakian

ASKER


Let me ask it another way,..

Computer 'A' located in sydney is sending a 32bit random number using udp, once every 100ms to Computer'B' located
in rome.

The random number never changes....

Computer 'A' does this 24/7 over and over again, 10 times a sec.

What mechanisms exist for Computer 'C' to see the packets being send from 'A' to 'B'

And is it relevant where 'C' is , if any methods require for this to be known ....




'C' must be somewhere in the routing chain from 'A' to 'B'.
If your packets are not unicast, then 'C' can be anywhere in the same subnet as 'B'

IF an attacker knows that the random never changes (a random constant then ;-), then (s)he needs just one packet with the random and then can use brute-force methods to compute it.
Calculating all possible values within 32bit is less than a second on modern hardware.

Just sending a random/constant sounds useless, somehow ...
Avatar of apakian

ASKER


I was just illustrating a point..

Ok fine, lets say the number is 64bits wide, so brute force would be useless ( it would also be useless in 32bits,, considering how long 4 billion packets
would take to send )

I dont understand your answer regarding being in the routing chain...
> ..  routing chain ..
when you have a connection from A to B, there are most likely some routers inbetween.
Lets say from A to B the traffic has to pass through routers R and Q , like
  A -- R -- Q -- B
then R and Q can "see" the traffic. C needs to be any of A, R, Q, B
Avatar of apakian

ASKER


What is the typical routing chain for an ISP..

assuming a user is connected to the ISP via adsl,cable,dialup or wireless..

have routers on the net been hacked in the past ? is their a common flaw in routing protocols
that can allow a person to intercept packets..



ASKER CERTIFIED SOLUTION
Avatar of ViRoy
ViRoy

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial