Nope, it's available:)
$ whois didglennbeckrapeandmurderayounggirlin1991.com
[Querying whois.verisign-grs.com]
[whois.verisign-grs.com]
Whois Server Version 2.0
Domain names in the.com and.net domains can now be registered
with many different competing registrars. Go to http://www.internic.net/
for detailed information.
No match for domain "DIDGLENNBECKRAPEANDMURDERAYOUNGGIRLIN1991.COM".
>>> Last update of whois database: Tue, 10 Nov 2009 16:15:08 UTC
"The weakest trusted CA in the world compromises the entire public key infrastructure."
That's a slight overstatement. It compromises the entire public key infrastructure for which that CA is the root of trust.
If you removed all MD5-enabled CAs from your trusted roots list, you remove the potential of being fooled by a forged cert. Certs issued by other CAs, unaffected by the brute-force MD5 collisons, remain as trustworthy as they ever were.
Granted, for most people the chain of trust ties back to the default CAs that ship with their browser, and if any of those CAs is vulnerable, your faith in any cert validated as 'trusted' by your browser goes down, and most people don't bother looking at what CA issued the cert so long as their browser deems it trustworthy, but it's a little more nuanced that 'compromises the entire PKI infrastructure.'
I suspect browser patches will be out soon, removing trust for affected CAs entirely, not trusting them past a certain date, or at least giving warnings when MD5 signature verification is found along the chain of trust.
My point is that you don't need to sniff the transaction ID.. there's only 65536 possibilities, so by sending them all you can be sure you'll get it right.
And you could do it for a client-only nameserver as well, you just need to convince a client to make requests for you.
The problem is this;
How does lookupd really KNOW it's talking to it's upstream nameserver?
The answer is, because it's replies match the query info and the transaction ID, and come to the right port from the right IP.
Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.
That's really no different than how this attack works against servers.
DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).
Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.
DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.
Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated.
In case of Slashdotting, here's the full update;
Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.
So let me get this right... you're leaving your laptop on your desk powered on every night. Why do you have a laptop?
If you just use a regular tower you can user a large internal drive, or a few larger internal drives, removing the need for the extra drive. Then your problem becomes securing a tower. There are many desks and enclosers for securing towers.
As for a keyboard and mouse, if you're worried about your keyboard and mouse being stolen I'd recommend you find another job.
Re:The article is good, it just fails to mention
on
Origin of the iPhone
·
· Score: 1
I have one just like the last Samsung model. Mine also has WLan and, like the Samsung, it has a full sized keyboard.
A full-sized keyboard? Really? Doesn't that make it hard to put in your pocket?
Your character gains +1 Networking points for knowing that DNS uses UDP/53 by default, but sadly loses 100 points for not knowing what a stateful firewall is and an additional 50 for confusing source and destination ports. You should probably re-roll before you get eaten by an ICMP packet.
I know what a stateful firewall is.. but the fact is that for UDP, there's no such thing. Some stateful firewalls were do protocol inspection to fake state by figuring out when to expect a DNS packet, but UDP is by definition stateless. Without reading the protocol at a higher layer, there's no way to tell state from only the UDP headers.
As for source and destination ports, that's irrelevant. A request from my machine going to the DNS server will have source port > 1024 and destination port 53. The response will reverse those - source port 53, destination port > 1024. How exactly am I to tell by looking at that information if a packet destined for a high port on my machine from UDP 53 is truly a reply or not? The only reliable way is to read outbound packets for requests, and keep a faux-state -table of what I should expect in response. It works similar to state, but is not the same, and has a non-trivial amount more overhead.
Thanks for providing links to the RFCs. That helps me understand where you're coming from.
As for the relevence of TCP RFCs, they're very relevant. What we're talking about is how to respond to a TCP SYN, which by it's very nature is a TCP operation. A connection exists on the client's end the moment it sends a SYN. It's not in 'established' state, but is in 'SYN-SENT' state and entered in the connection table. The server doesn't need to acknowledge a connection attempt to tell the client to tear down it's connection. I totally agree with you for non-TCP protocols, but TCP is different.
See RFC 1122 which states in part;
" A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose."
The RFCs you've provided also support my explanation -- RFC 792 states; "If, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host." Note that it MAY send an unreachable. It's not required. In my experience, most stacks will send a type 3 code 3 in response to UDP attempts to closed ports, but never TCP.
RFC 1812 also states; " Routers MUST be able to generate the Redirect for Host
message (Code 1) and SHOULD be able to generate the Redirect for Type
of Service and Host message (Code 3) specified in [INTERNET:8]." Note 'SHOULD' which in RFC parlance means it's not required.
Under the section "5.3.9 Packet Filtering and Access Lists" which seems most related to our discussion; "The router SHOULD allow an appropriate ICMP unreachable message to be
sent when a packet is discarded. The ICMP message SHOULD specify
Communication Administratively Prohibited (code 13) as the reason for
the destination being unreachable." Again, it's not a requirement, but it's recommended.
What's the source for your statement that TCP RST is not the proper response to a closed port? I've literally never seen a Type 3 code 13 in response to a TCP SYN, and wonder if you're not confusing TCP and UDP somewhat.
NMAP's docs indicate that a TCP RST in response to a SYN is a determination that a port is 'CLOSED', and any ICMP response will flag it as 'filtered' including an ICMP type 3 code 1,2, 3, 9, 10, or 13. See the -sS (TCP SYN scan) section of http://insecure.org/nmap/man/man-port-scanning-techniques.html In practice, I've never seen any firewall which will report an ICMP error in response to a filtered TCP port, and only rarely have I seen one which gives any response at all, but if it does respond, that response would be a RST.
Now, for UDP packets, the proper response to a connection request destined for a port on which you're not listening is indeed an ICMP type 3, code 3. Obviously, there's no connection state here, and thus no way to RST a session so ICMP is used to notify the requestor.
I tried to find an RFC to reference, but honestly the TCP RFCs are pretty complicated, revised several times, etc.. so I couldn't find a definitive reference. If you have a source that backs your statement about ICMP responses to TCP connection attempts, I'd love to see it... in my experience, every protocol stack I've ever encountered operates by replying with a RST.
The UI is saying "I'm blocking all connections" even though it isn't.
Well technically, the only examples this article provides are of UDP services listening. So there's no evidence that the firewall is allowing 'connections'
I agree that to the end user connections probably means something different, but in the world of network protocols it has a very specific meaning, which doesn't include UDP services by definition. The only way for the firewall to deny inbound UDP sessions would be to fake connection state for these protocols. Many popular commercial enterprise class firewalls do just this, but I'm not surprised that a desktop firewall isn't doing it.
Slashdot Mirror
Fox-It is based in the Netherlands. This makes it likely that the author's native language is not English.
Would you be able to form a coherent thought in Dutch that a native speaker wouldn't find awkward?
Nope, it's available :)
$ whois didglennbeckrapeandmurderayounggirlin1991.com
[Querying whois.verisign-grs.com]
[whois.verisign-grs.com]
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net/
for detailed information.
No match for domain "DIDGLENNBECKRAPEANDMURDERAYOUNGGIRLIN1991.COM".
>>> Last update of whois database: Tue, 10 Nov 2009 16:15:08 UTC
Also, they have guns.
This seems to closely relate to the next story currently on the frontpage; Predicting Malicious Web Attacks
First of all, this story should probably link to the actual event site.
Secondly, the results have been available since 11/19/08. This is hardly news at this point.
"The weakest trusted CA in the world compromises the entire public key infrastructure."
That's a slight overstatement. It compromises the entire public key infrastructure for which that CA is the root of trust.
If you removed all MD5-enabled CAs from your trusted roots list, you remove the potential of being fooled by a forged cert. Certs issued by other CAs, unaffected by the brute-force MD5 collisons, remain as trustworthy as they ever were.
Granted, for most people the chain of trust ties back to the default CAs that ship with their browser, and if any of those CAs is vulnerable, your faith in any cert validated as 'trusted' by your browser goes down, and most people don't bother looking at what CA issued the cert so long as their browser deems it trustworthy, but it's a little more nuanced that 'compromises the entire PKI infrastructure.'
I suspect browser patches will be out soon, removing trust for affected CAs entirely, not trusting them past a certain date, or at least giving warnings when MD5 signature verification is found along the chain of trust.
Obligatory link to the Movies featuring Nmap page. Enjoy.
My point is that you don't need to sniff the transaction ID.. there's only 65536 possibilities, so by sending them all you can be sure you'll get it right.
And you could do it for a client-only nameserver as well, you just need to convince a client to make requests for you.
The problem is this;
How does lookupd really KNOW it's talking to it's upstream nameserver?
The answer is, because it's replies match the query info and the transaction ID, and come to the right port from the right IP.
Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.
That's really no different than how this attack works against servers.
DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).
Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.
DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.
Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated.
In case of Slashdotting, here's the full update;
Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.
But neither is 'A health care provider'
Is there a new edition of this book out or something? That ISBN dates to 2006 - an eternity in the world of security devices.
So let me get this right... you're leaving your laptop on your desk powered on every night. Why do you have a laptop?
If you just use a regular tower you can user a large internal drive, or a few larger internal drives, removing the need for the extra drive. Then your problem becomes securing a tower. There are many desks and enclosers for securing towers.
As for a keyboard and mouse, if you're worried about your keyboard and mouse being stolen I'd recommend you find another job.
I have one just like the last Samsung model. Mine also has WLan and, like the Samsung, it has a full sized keyboard.
A full-sized keyboard? Really? Doesn't that make it hard to put in your pocket?
I hate to be a pedantic jerk, but you misspelled pedantic.
Touche!
"...an authentic calculator simulator..."
What the hell is an authentic simulator?
Isn't David Hasselhoff also hug in Japan?
Don't hassle the Hoff!
Well, that's what the article is about.
The whole thing started because he said "The TCP spec says if a port isn't open the client should get an ICMP error," Which is flat out not true.
I think we're just talking about different things though.. he might've said TCP when he meant UDP
Whatever.. I quit.
"it would reply using the originating source port number."
Uhh, that's what I said.
"The response will reverse those - source port 53, destination port > 1024."
Your character gains +1 Networking points for knowing that DNS uses UDP/53 by default, but sadly loses 100 points for not knowing what a stateful firewall is and an additional 50 for confusing source and destination ports. You should probably re-roll before you get eaten by an ICMP packet.
I know what a stateful firewall is.. but the fact is that for UDP, there's no such thing. Some stateful firewalls were do protocol inspection to fake state by figuring out when to expect a DNS packet, but UDP is by definition stateless. Without reading the protocol at a higher layer, there's no way to tell state from only the UDP headers.
As for source and destination ports, that's irrelevant. A request from my machine going to the DNS server will have source port > 1024 and destination port 53. The response will reverse those - source port 53, destination port > 1024. How exactly am I to tell by looking at that information if a packet destined for a high port on my machine from UDP 53 is truly a reply or not? The only reliable way is to read outbound packets for requests, and keep a faux-state -table of what I should expect in response. It works similar to state, but is not the same, and has a non-trivial amount more overhead.
Thanks for providing links to the RFCs. That helps me understand where you're coming from.
As for the relevence of TCP RFCs, they're very relevant. What we're talking about is how to respond to a TCP SYN, which by it's very nature is a TCP operation. A connection exists on the client's end the moment it sends a SYN. It's not in 'established' state, but is in 'SYN-SENT' state and entered in the connection table. The server doesn't need to acknowledge a connection attempt to tell the client to tear down it's connection. I totally agree with you for non-TCP protocols, but TCP is different.
See RFC 1122 which states in part;
" A Destination Unreachable message that is received MUST be
reported to the transport layer. The transport layer SHOULD
use the information appropriately; for example, see Sections
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol
that has its own mechanism for notifying the sender that a
port is unreachable (e.g., TCP, which sends RST segments)
MUST nevertheless accept an ICMP Port Unreachable for the
same purpose."
The RFCs you've provided also support my explanation -- RFC 792 states;
"If, in the destination host, the IP module cannot deliver the
datagram because the indicated protocol module or process port is
not active, the destination host may send a destination
unreachable message to the source host."
Note that it MAY send an unreachable. It's not required. In my experience, most stacks will send a type 3 code 3 in response to UDP attempts to closed ports, but never TCP.
RFC 1812 also states;
" Routers MUST be able to generate the Redirect for Host
message (Code 1) and SHOULD be able to generate the Redirect for Type
of Service and Host message (Code 3) specified in [INTERNET:8]."
Note 'SHOULD' which in RFC parlance means it's not required.
Under the section "5.3.9 Packet Filtering and Access Lists" which seems most related to our discussion;
"The router SHOULD allow an appropriate ICMP unreachable message to be
sent when a packet is discarded. The ICMP message SHOULD specify
Communication Administratively Prohibited (code 13) as the reason for
the destination being unreachable."
Again, it's not a requirement, but it's recommended.
What's the source for your statement that TCP RST is not the proper response to a closed port? I've literally never seen a Type 3 code 13 in response to a TCP SYN, and wonder if you're not confusing TCP and UDP somewhat.
NMAP's docs indicate that a TCP RST in response to a SYN is a determination that a port is 'CLOSED', and any ICMP response will flag it as 'filtered' including an ICMP type 3 code 1,2, 3, 9, 10, or 13. See the -sS (TCP SYN scan) section of http://insecure.org/nmap/man/man-port-scanning-techniques.html In practice, I've never seen any firewall which will report an ICMP error in response to a filtered TCP port, and only rarely have I seen one which gives any response at all, but if it does respond, that response would be a RST.
Now, for UDP packets, the proper response to a connection request destined for a port on which you're not listening is indeed an ICMP type 3, code 3. Obviously, there's no connection state here, and thus no way to RST a session so ICMP is used to notify the requestor.
I tried to find an RFC to reference, but honestly the TCP RFCs are pretty complicated, revised several times, etc.. so I couldn't find a definitive reference. If you have a source that backs your statement about ICMP responses to TCP connection attempts, I'd love to see it... in my experience, every protocol stack I've ever encountered operates by replying with a RST.
Simply disallowing all incoming UDP traffick is trivially easy ... and doesn't break all that much.
Sure, if DNS isn't 'all that much'
Disallow all incoming UDP/53 traffic, and you'll lose the ability to resolve names. More secure? Maybe. Practical? Absolutely not.
The UI is saying "I'm blocking all connections" even though it isn't.
Well technically, the only examples this article provides are of UDP services listening. So there's no evidence that the firewall is allowing 'connections'
I agree that to the end user connections probably means something different, but in the world of network protocols it has a very specific meaning, which doesn't include UDP services by definition. The only way for the firewall to deny inbound UDP sessions would be to fake connection state for these protocols. Many popular commercial enterprise class firewalls do just this, but I'm not surprised that a desktop firewall isn't doing it.