Security Now 317

From The Official TWiT Wiki
Jump to: navigation, search
Security Now
Episode 317

Security Now 317: TCP Part 1

News & Errata

Apple has not provided an update to remove trust from DigiNotar. PC World article on the subject. Steve recommends avoiding use of Safari on Mac platform until Apple responds to the issue.

It has been confirmed that the individual behind the Comodo hack is also responsible for the DigiNotar hack. Fox IT, the IT consulting firm that were brought in to examine the DigiNotar breach, found some fingerprint information left behind which was identical to the information found in the Comodo attack.

Microsoft released an out-of-cycle update to remove DigiNotar's trust from Windows. Mozilla also updated Firefox to version 6.0.2 to remove DigiNotar's trust as well

A DNS hijack occurred which saw the defacement of,,,, and They all belonged to the same domain registrar, NetNames. Turkish attackers hacked into the DNS management panel of these NetName accounts using SQL injection and modified the DNS pointers to point to another website (

@dochouse7 on Twitter mentioned a blog, which has a small detector for the top five banking trojans: Zeus, SpyEye, Carberp, Gozi and Patcher. It's 768K in size and performs an in-memory check of the currently running processes on your system to detect if any of these banking trojans are present.

Unspecified vulnerability in Medtronic Paradigm wireless insulin pumps

Fox IT's report on the DigiNotar breach.

ComodoHacker's pastebin posting on hacking DigiNotar

GlobalSign suspends issuance of any further certificates as they were mentioned in ComodoHacker's posting.

Walid Damouny on Twitter asks, "How trustworthy are other CAs. Like DigiNotar, CAs are not compromisable." Steve says it is worse than this because, for example, with the Patriot Act in the U.S., who is to say that other CAs haven't issued certificates on behalf of the government?

Steve has finished an ultra high-entropy pseudorandom number generator.

Spinrite Story

Terry J. LeBlanc - "Thanks, Steve. I haven't worked with SpinRite in quite a few years. Then I needed to run chkdsk on my Dell OptiPlex 755 over the weekend and chkdsk would hang at 36 percent during Phase 5, checking the available free space. No matter how long I let it run, chkdsk would not continue. It would not finish.

So I thought of SpinRite, accessed your website, bought it and downloaded it; created the ISO image; burned a bootable CD. I booted from the CD and got an opcode error. Researching the error on the Internet, I found references to others with the OptiPlex 755 boxes, trying to run SpinRite, getting that error that indicated that changing the BIOS from RAID-AHCI to RAID-ATA would eliminate the opcode error. So I changed the BIOS setting and restarted from the CD.

Sure enough, SpinRite came right up with the familiar DOS interface I had not seen in years. SpinRite ran successfully at Level 2. I restarted the workstation, ran chkdsk successfully and booted up normally. Problem solved. I'm using it right now. SpinRite and the other tools from GRC have helped me so many times over the years. I'm happy that you're still around and making these tools available. I'm happy to have SpinRite back in my toolbox. Great job, folks. Keep up the good work. Thanks, Terry LeBlanc."

Topic: TCP Part 1 - Getting Connected

TCP is a peer to other protocols (ICMP, UDP, etc.) that exist on top of the IP protocol, traditionally known as the TCP/IP stack.

Internet is composed of interconnected routers that connect users, services and servers to each other through links that individual packets move around.

Routers have the ability to discard packets that they don't have time to send for a variety of reasons (router crashes, goes down, links drop, etc.). Packets could also arrive out of sequence because routers can choose which links they send packets from or forward to. One link might be busy so the router will send the packet down another link, if the chosen link has a shorter path to its destination, then that packet will arrive before the previous one. This creates a problem with reliability.

TCP fixes this problem. TCP creates an abstraction called a "connection," not in the sense of wires but in the sense of packets. A TCP connection is between two endpoints. Every byte that is sent is numbered. The sender numbers the bytes and the recipient acknowledges the bytes that are received. Lost packets cannot be acknowledged this way.

The recipient acknowledges the highest numbered packet received in order. If packets came out of order, then the recipient holds that packet, assuming that it will soon receive the missing packets. The recipient acknowledges everything it has received up to that point, not any missing gaps. The sender will notice the missing acknowledgment and send those packets again. TCP re-sends data that is lost in transit. It buffers all outbound data until it has been acknowledged by the other end. The application running above TCP sends data down to TCP assuming that TCP will ensure that the data gets to its recipient.

This process happens first, by a connection initiator wanting to connect to a connection receiver. The typical example for this model is using a web browser to connect to a website. The website, or server we want to connect to is listening for incoming TCP connections. The connection initiator sends a synchronize, or SYN packet to the connection recipient, who is listening for incoming TCP connections. The SYN packet contains a declaration of the endpoint. This initiating endpoint is identified by its source IP and source port and the other endpoint is identified by the destination IP and destination port. IPs are 32 bits and ports are 16. That means 48 bits for each endpoint and together is 96. A connection is identified by a local port and IP and a remote port and IP. The purpose of ports is to enable multiple connections to the same location. For example, using a browsers to open multiple simultaneous connections to a single remote location, like Each connection connects to Google's IP at Google's port 80, for TCP. Each source port, however, would be different to disambiguate the traffic.

Each SYN packet contains the local port, local IP and the destination port and destination IP. The destination port could be 80 for HTTP, 110 for a remote POP server, 143 for a remote IMAP server and so on. These are part of the well-known port numbers. A remote IP can have different services listening on different ports for incoming TCP connections. Each port implies a different service. SMTP listening on port 80 means SMTP is operating over a TCP connection.

The SYN packet also has a sequence number. It starts to number the bytes that it will send to the recipient from a 32-bit count. The server receives the SYN and if the server is listening on a port, like 80, for example, it will reply with a SYN ACK (synchronize acknowledgment). The SYN portion is its own numbering scheme to send the other way, as a TCP connection is a full duplex connection, data can be sent in both directions. The ACK portion is the acknowledgment of the receipt of the initiator's SYN. Upon receiving the SYN ACK packet, the connection initiator sends its final packet, acknowledging the receipt of the SYN ACK packet. Essentially there's a SYN and an ACK, a declaration and an acknowledgment that passes between both endpoints in each direction. This is called the TCP three-way handshake, it is the establishment of the connection endpoints and the numbering of the bytes to pass through this connection. It also validates that each endpoint is able to receive traffic.

The reason that byte sequencing uses a 32-bit count is, since connections can vary in how long they last, to avoid data from a previous connection being overlapped with data from the current connection. The 32-bit count also gives plenty of margin. As data is sent to the other end, the counter advances by the number of bytes sent in each packet so that the sequence number continues to advance upward. If it hits the 32-bit limit, it wraps around back to zero and starts from there.

The recipient acknowledges the last in-order byte that it has received. It has no way of knowing about lost packets. As it receives the data it moves the numbering forward to the point indicated by the data in the packet and acknowledges this amount received to the sender. If it receives a packet out of order, it will wait to see if the other data is going to come in. If the sender does not receive an acknowledgment with a certain time frame, it will send that data again. This process works both ways, as TCP is a full duplex connection. This is how a TCP connection is established.

Notable Quotes

Significant Products

  • Link URL and optional brief description



  • Audible URL


Narrated by TBD

Other Sponsor

  • Link URL

Production Information

  • Edited by:
  • Notes:
Info.png This area is for use by TWiT staff only. Please do not add or edit any content within this section.