My doubt is this: UDP has no sequence numbers, so what indeed is the concept behind UDP session hijacking?
You are correct in that UDP does not have a state like TCP has, so in a literal sense there is no session to hijack. However, because of this it is impossible to verify the identity of the sender of an UDP packet. All you have to go on is the sender IP in the UDP header, and that could trivially be spoofed. In that sense, it is easier to session hijack UDP than TCP or HTTP, since you do not have to worry about sequence numbers or session cookies.
So an attacker sniffing your network traffic could read the UDP packets you send to a server, and then send a response spoofed to look like it is from the server. Your computer will naively assume that the spoofed response is the real response if it arrives first, since there is no way to verify the identity of the sender.
Do note that you do not have to be able to modify the traffic, only sniff it, to do this. You could send your spoofed response from anywhere. But this could sometimes even be done without any sniffing - just send out UDP packets and hope it match something, or that a client will accept the response even though it has not sent a request.
So what could this be used for? For instance you can mess with two of the more common UDP protocols:
- DNS: Send a false response to a DNS lookup, and you can fool the victim into resolving
www.mybank.cominto an IP you control, where you serve a phishing site. (This will not work if the site is then requested over HTTPS, since you will not be able to serve a valid certificate.)
- NTP: Send false times to a client, thereby controlling its clock. This could for instance be used to "expire" a HSTS post (if time is moved forwards), or make and expired certificate valid (if time is moved backwards).