Information Security News
Keil Hubert: There's Always Something Worth Stealing
The InfoSec crew was responsible for (and limited to!) maintaining network firewalls, content filters, and maybe some intrusion detection/prevention gear; they didn't have the critical cross-functional perspective that an effective security team needs ...
How is it possible that with no port forwarding enabled through the firewall that Internet originatedÂ NTP requests were getting past the firewallÂ to the misconfigured NTP server?
The reason why these packets are passing the firewallÂ is because the manufacturer of the gateway router, in this case Pace, implemented full-cone NAT as an alternative to UPnP.
The secret is in these settings in the gateway router:
If strict UDP Session Control were enabled the firewall would treat outbound UDP transactions as I described earlier.Â When a device on your network initiates an outbound connection to a server responses from that server are permitted back into your network.Â Since UDP is stateless most firewalls simulate state with a timeout.Â In other words if no traffic is seen between the device and the serverÂ for 600 seconds then donât permit any response from the server until there is new outbound traffic. But anytime related traffic is seen on the correct port the timer is reset to 600 seconds, thus making it possible for this communication to be able to continue virtually forever as long as one or both devices continue to communicate. Visually that looks like:
However if UDP Session Control is disabled, as it is in this device, then this device implements full-cone NAT (RFC 3489). Full-cone NAT allows any external host to use the inbound window opened by the outbound traffic until the timer expires.Â Â
Remember anytime traffic is seen on the correct port the timer is reset to 600 seconds, thus making it possible for this communication to be able to continue virtually forever as long as one or both devices continue to communicate.
The really quick among you will have realized that this is not normally a big problem since the only port exposed is the original ephemeral source port and it is waiting for a NTP reply.Â It is not likely to be used as an NTP reflector.Â But the design of theÂ NTP protocol can contribute to this problem.
There is a mode of NTP called symmetric NTP in which, instead of the originating device picking an ephemeral port for the outbound connection, Â both the source and the destination ports use 123. The traffic flow would look like:
Symmetric NTP opens up the misconfigured server to be anÂ NTP reflector.Â Assuming there is an NTP server running on the originating machine on UDP port 123, if an attacker can find this open NTP port before the timeout window closes they can send in NTP queries which will pass the firewall and will be answered by the NTP server.Â If the source IP address is spoofed the replies will not go back to the attacker, but will go to a victim instead.Â
Of course UDP is stateless so the source IP can be spoofed and there is no way for the receiver of the NTP request to validate the source IP orÂ source port permittingÂ the attacker to direct the attack against any IP and port on the Internet. Â It is exceedingly difficult to trace these attacks back to theÂ source so the misconfigured server behind the full-cone NAT will get the blame. As long as the attacker sends at least one packet every 600 seconds he can hold the session open virtually forever and use this device to wreak havoc on unsuspecting victims.Â We have seen indications of the attackers holding holding these communications openÂ for months. Â
What are the lessons to be learned here:
-- Rick Wanner - rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
by Robert Lemos
The amount of personal data traveling to and from the Internet has exploded, yet many applications and services continue to put user information at risk by not encrypting data sent over wireless networks. Software engineer Tony Webster has a classic solution—shame.
Webster decided to see if a little public humiliation could convince companies to better secure their customers' information. On Saturday, the consultant created a website, HTTP Shaming, and began posting cases of insecure communications, calling out businesses that send their customers' personal information to the Internet without encrypting it first.
One high-profile example includes well-liked travel-information firm TripIt. TripIt allows users to bring together information on their tickets, flight times, and itinerary and then sync it with other devices and share the information with friends and co-workers. Information shared with calendar applications, however, is not encrypted, Webster says, leaving it open to eavesdropping on public networks. Among the details that could be plucked from the air by anyone on the same wireless network: a user's full name, phone number, e-mail address, the last four digits of a credit card number, and emergency contact information. An attacker could even change or cancel the victim's flight, he says.
Amazon Fire Phone security features and pitfalls