Better than being identified as a phone or giraffe.
Better than being identified as a phone or giraffe.
IPv6 please. It is easy. A tech site for geeks should have had IPv6 a decade ago.
readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.
But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.
If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.
This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.
"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.
You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.
So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.
Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!
Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.
The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the data to deserialize to something completely different.
Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.
The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).
Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.
It may not be worse but it will have programmed sense, so it will refuse to attempt it.
Port numbers is only useful and needed if you are dealing with carrier NAT. That is NAT performed by the ISP, such that multiple customers share the same ISP. This happens to be somewhat common with apartment networks.
If RIAA/MPAA records the address 2001:db8:a55:beef::2af6 only the "2001:db8:a55:beef" part is actually useful. The remaining part of the address will typically be a randomized privacy extension address. They are therefore still unable to prove which machine was used to download the content.
If you are one of the persons that want to use easy to remember addresses, you can still use privacy extensions. With IPv6 it is normal to have many address on each computer. You can have your easy to remember address (2001:db8:a55::2) that you use for ingoing connections. And the machine will prefer the random privacy extension address for outgoing connections (2001:db8:a55::9b43:82dd:2239:10bc - right now but in an hour it will be completely different).
There is also some big sites that are available:
baldur@ballerup1:~$ for i in google.com facebook.com www.netflix.com akamai.com cloudflare.com rackspace.com wikipedia.org; do ping6 -c1 -n $i | grep bytes; done
PING google.com(2a00:1450:4005:801::1000) 56 data bytes
64 bytes from 2a00:1450:4005:801::1000: icmp_seq=1 ttl=50 time=28.8 ms
PING facebook.com(2a03:2880:20:4f06:face:b00c:0:1) 56 data bytes
64 bytes from 2a03:2880:20:4f06:face:b00c:0:1: icmp_seq=1 ttl=43 time=191 ms
PING www.netflix.com(2a01:578:3::36e4:ea94) 56 data bytes
64 bytes from 2a01:578:3::36e4:ea94: icmp_seq=1 ttl=46 time=38.0 ms
PING akamai.com(2a02:26f0:103:186::22df) 56 data bytes
64 bytes from 2a02:26f0:103:186::22df: icmp_seq=1 ttl=54 time=22.3 ms
PING cloudflare.com(2400:cb00:2048:1::c629:d59d) 56 data bytes
64 bytes from 2400:cb00:2048:1::c629:d59d: icmp_seq=1 ttl=57 time=10.6 ms
PING rackspace.com(2001:4801:1221:101:1c10:0:f5:116) 56 data bytes
64 bytes from 2001:4801:1221:101:1c10:0:f5:116: icmp_seq=1 ttl=43 time=127 ms
PING wikipedia.org(2620:0:862:ed1a::1) 56 data bytes
64 bytes from 2620:0:862:ed1a::1: icmp_seq=1 ttl=52 time=20.7 ms
The CDNs in there means that you will get some content over IPv6 even from sites that are not IPv6 enabled as such.
IPv6 Neighbour Discovery protocol (ND) https://tools.ietf.org/html/rf... is the protocol used by IPv6 hosts to find each other. It is the IPv6 equivalent of ARP. And ND is based on multicast. Without multicast, nothing would work with IPv6.
An IPv4 host needs to use broadcast ARP packets to every host on the same network. This was fixed in IPv6, so each host uses the last 32 bits of its address as a multicast group. When you need to contact someone, you will take the last 32 bits of his address and then multicast your ND packets to that multicast group. That way only hosts that share the same last 32 bits will receive the ND packet. This dramatically reduces the amount of broadcast/multicast chatter received by each host.
The downside is that it only works on networks with MLD enabled switches. That is very rare. Without MLD the system will fall back to broadcast.
But just to point out that you are wrong to believe that multicast is experimental when in fact it was baked in from the very start.
You need to read up on IPv6 privacy extensions: https://tools.ietf.org/html/rf...
Your computer will generate a random IPv6 address and change that random address at regular intervals (typically a few hours before it changes). Therefore they will be unable to track the exact computer, because there is no way to know which computer had that random address at the time.
They will get you anyway due to cookies and device fingerprinting, but that is no different than the situation with IPv4 and NAT.
Also with carrier NAT ISPs in most countries are by law required to record the port numbers assigned to each user. Your IP might be shared with multiple other users, but as long they also recorded the port number, they will be able to find the user. RIAA and MPAA knows this - I get a ton of email from them every day complaining about users that download their stuff with Bittorrent and every complaint includes port numbers.
Try "Network Prefix Translation" instead: https://tools.ietf.org/html/rf...
"This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Prefix Translation (NPTv6) function that provides the
address-independence benefit associated with IPv4-to-IPv4 NAT
(NAPT44) and provides a 1:1 relationship between addresses in the
"inside" and "outside" prefixes, preserving end-to-end reachability
at the network layer."
Although personally I believe it is seldom needed. In practice a IPv6 home network can renumber every device within 30 seconds of the ISP changing the prefix on you. That is less time than it takes for your CPE router to reboot.
Nope, all three protocols will work fine with any prefix size. Only SLAAC need a
If you did a
The majority of internet service providers will give you a
2001:db8:123:: (that would be your router)
2001:db8:123::2 (that would be your web server or whatever).
2001:db8:123::3 (that would be your mail server or whatever).
198.51.100.250 (that would be your router - and also your web/mail server because it is all you got).
Blocks less than a
One can hope that ARIN will recognize the need to be able to route this on the internet as sufficient reason to get a
There is one other difference to the RIPE policy and that is the IPv6 requirement. There is no such requirement by RIPE. You will get your
You are wrong. My router does have DHCPv6 and so does every OS (Linux, Mac and Windows) on my network.
You will find that basically 100% of the new generation routers (those with 802.11ac radios) come with full fledged IPv6 support these days. Including DHCPv6 support.
As to the ISP that seems to depend entirely on what country you live in. Some countries have very high penetration now. The rest of the world will follow.
They wont because my ISP makes static allocations to every customer. But if you have another ISP with a poor policy, then you can use a private range such as fd00::/64 for your internal network.
fd00::2 is shorter than 192.168.1.2 if we are still at that...
Yes you are supposed to put in something random in the fd00 style address. But nothing stops you from ignoring that. It is just so that your VPN to your employer does not collide unnecessary with your home network, but if both of you choose to use the same range, you are no worse off than if the same thing happened on IPv4.
For the average customer this is no issue however. They are in don't care about IP-addresses boat. If the ISP changes your prefix, your internal network will just renumber too and nobody notices.
The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it. -- E. Hubbard