Network and System Security Risk Assessment

1. Network and System Security Risk Assessment --raw socket programming

2. Review • IP and ICMP • TearDrop • Fragmentation against firewall • ICMP Redirect • ICMP broadcast amplification • Ping of deaths

3. Review • ICMP Redirect • netwox 86 • This tool sends an ICMP error message when a packet matching filter is sniffed. • netwox 86 [-d device] [-f filter] -g ip [-s spoofip] [-c uint32] [-i ip]

4. Review • TCP SYN flooding • Three-way handshake • DoS/DDoS attack

5. Review: mysu • setuid • setuid() sets the effective user ID of the calling process. If the effective UID of the caller is root, the real UID and saved set-user-ID are also set • Dup2 • int dup2(int oldfd, int newfd) • dup2() makes newfd be the copy of oldfd

6. Review • Real user: • Real user IDs are used to track who a user really is, i.e. on what account he or she is logged in • Effective user: • are used to determine whether the process should be granted access or not. These IDs constitute the effective privilege of the process • Saved set-user-id

7. Review: • comment setuid(); • gcc mysu.c –o mysu_noset • run mysu_not with and without sudo • cp mysu_noset mysu_noset_root • chown & chmod 4775 • with sudo, both users are 0 • Without?

8. Review • Uncomment setuid(): • gcc mysu.c –o mysu_set • run mysu_set with and without mysu_set • result? • cp mysu_set mysu_set_root • chown &chmod • result?

9. Review • What about seteuid()? • seteuid() sets the effective user ID of the calling process. • gcc mysu.c –o mysu_sete_root

10. Review: Socket • socket : one endpoint of a two-way communication link between two programs running on the network. • it is an interface to the underlying transport protocols that are handled by the kernel. • Every socket is bound to a port, which designates the application who is to send/receive the data in the transport layer.

11. Review: Socket • sockfd = socket (AF_INET, SOCK_STREAM, 0) • bind(), listen(), accept(), connect(), close(), send(), receive()… • read(), write()….

12. Review: socket and backdoor • dup2 • nc –vv IPaddress port

13. Problems: Socket • "sockets“ like that does not fit all our needs. lack some functionality some of which is given below: • cannot read/write ICMP or IGMP protocols with normal sockets, ping(8) tool cannot be written using them. • For IPv4 protocols other than ICMP, IGMP, TCP or UDP, What if we have a proprietary protocol that we want to handle? How do we send/receive data using that protocol? • For hackers, how to construct special kind of packets for special purposes?

14. What is raw socket? • A different mechanism is needed: packets WITHOUT TCP/IP processing -- raw packet • allow user to bypass partly how computer handles TCP/IP. the packets were sent to the raw sockets user defines rather than the TCP/IP stack • User should write program to wrap the data, e.g. to fill the headers, instead of kernel • Raw sockets provide "privileged users" with the ability to directly access raw protocol

15. Why Use Raw Socket? • To conclude: • Using higher-layer socket programming (connect, bind, listen, read, write), user has no control over the packets • Raw sockets enables user to send spoofed IP packets, thus to build scanners etc.

16. 4 layer network ---------------------------------------------------------- | 4. Application | telnet, ftp, dns etc. | -------------------------------------------------------- | 3. Transport | TCP UDP | ---------------------------------------------------------- | 2. Network | IP ICMP IGMP | ---------------------------------------------------------- | 1. Link | device driver, network adapter | ----------------------------------------------------------

17. Link Layer • Very first of the TCP/IP layers. When the packet is received off the wire, the early processing is done in here. Duties include: • send/receive datagrams for the IP protocol • send/receive ARP requests and replies for the ARP protocol • send/receive RARP request and replies for the RARP protocol

18. IP header structip { u_int ip_hl:4, /* header length */ ip_v:4; /* ip version */ u_charip_tos; /* type of service */ u_shortip_len; /* total length */ u_shortip_id; /* identification */ u_shortip_off; /* fragment offset */ u_charip_ttl; /* time to live */ u_charip_p; /* protocol */ u_shortip_sum; /* checksum */ structin_addrip_src,ip_dst; /* source and dest address */ }; /usr/include/netinet/ip.h

19. IP header example Field Length Example ------------------------------ --------------- ------------------- Version 4 bits 4 Header length 4 bits 5 Type of Service 8 bits 0 Total length of the whole 16 bits 45 datagram Identification 16 bits 43211 Flags 3 bits 0 Fragment Offset 13 bits 0 Time to Live (a.k.a TTL) 8 bits 64 Layer III Protocol 8 bits 6 [TCP] Checksum 16 bits 0x3a43 Source IP address 32 bits 192.168.1.1 Destination IP address 32 bits 192.168.1.2

20. ICMP header • struct icmphdr • { • u_int8_t type; /* message type */ • u_int8_t code; /* type sub-code */ • u_int16_t checksum; • union • { • struct • { • u_int16_t id; • u_int16_t sequence; • } echo; /* echo datagram */ • u_int32_t gateway; /* gateway address */ • struct • { • u_int16_t __unused; • u_int16_t mtu; • } frag; /* path mtu discovery */ • } un; • }; • /usr/include/netinet/ip_icmp.h

21. ICMP header Example • icmp->icmp_type = ICMP_ECHO; • icmp->icmp_code = 0; • icmp->icmp_cksum = 1; • icmp->icmp_id = 2; • icmp->icmp_seq = 3;

22. RAW SOCKET API • Just like normal sockets, we create raw sockets with the socket(2) system call: • int socket(int domain, int type, int protocol) • type and protocol parameters are set to SOCK_RAW and protocol name accordingly: • if ((sd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) { .. }

23. Write a simple ping • Demo with myping0.c • Demo with myping1.c • Compared with myping3.c • They work with two different types of header structures

24. Problem: no reply • ICMP checksum error • Checksum computation • Calculating IP and TCP checksum is no big deal as RFC 791 puts in: • 'The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header'. • RFC 1071: • ?How about IP Checksum?

25. Checksum algorithm unsigned short in_cksum(unsigned short *addr, int len) {         int sum=0;         unsigned short res=0;         while( len > 1)  {                 sum += *addr++;                 len -=2;         }         if( len == 1) {                 *((unsigned char *)(&res))=*((unsigned char *)addr);                 sum += res;         }         sum = (sum >>16) + (sum & 0xffff);         sum += (sum >>16) ;         res = ~sum;         return res; }

26. Demo • With checksum, ping receives reply • Observe the result of myping4. c and myping5.c

27. Problem: myping shows no reply • How would raw_socket receive data? • Normally using recvfrom() • Conditions for a packet to match raw socket • If protocol parameter was specified, only packets with that protocol value are delivered. • If bind() was called on raw socket, only packets destined to bound IP address are delivered. • If connect() was called, only packets from connected address are delivered

28. demo • myping6.c • which can both send and receive packets • recvfrom() • socket with IPPROTO_RAW will not receive • so create another socket with IPPROTO_ICMP

29. How Packets Flow • If you're not using raw sockets on a "send-and-forget" basis, you will be interested in reading the reply packet(s) for your raw packet(s). • The decision logic for whether a packet will be delivered to a raw socket can be enumerated as such: • TCP and UDP packets are never delivered to raw sockets, they are always handled by the kernel protocol stack.

30. How Packets Flow • The decision logic for whether a packet will be delivered to a raw socket can be enumerated as such: • Copies of ICMP packets are delivered to a matching raw socket. For some of the ICMP types (ICMP echo request, ICMP timestamp request, mask request) the kernel, at the same time, may wish to do some processing and generate replies. • All IGMP packets are delivered to raw sockets: e.g. OSPF packets. • All other packets destined for protocols that are not processed by a kernel subsystem are delivered to raw sockets.

31. Receive the reply • To receive a reply, you may also need to consider: • setting the protocol accordingly while creating your socket via socket(2)system call. For instance, if you're sending an ICMP echo-request packet, and want to receive ICMP echo-reply, you can set the protocol argument (3rd argument) to IPPROTO_ICMP). • setting the protocol argument in socket(2) to 0, so any protocol number in the received packet header will match. • defining a local address for your socket (via e.g. bind(2)), so if the destination address matches the socket's local address, it'll be delivered to your application also. • So, what about TCP and UDP? For reading the reply packets for your TCP/UDP raw socket, the only viable option is to utilize a packet filter.

32. Set IP header • We can start crafting ICMP packets now. But, this way, Layer II data will be constructed by the kernel IP code. • we want to tell kernel that our packet includes the Layer II data already. To do this, we set the IP_HDRINCL option for our socket via setsockopt(2) system call: • const int on = 1; • if (setsockopt(sd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on) < 0) { .. }

33. ICMP Smurf • Demo myping8.c • Wireshark and promiscuous mode

34. TCP Header struct tcphdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_int th_x2:4, /* (unused) */ th_off:4; /* data offset */ u_char th_flags; u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ };

35. TCP Header Example Field Length Example ------------------------------ --------------- ------------------- Source Port 16 bits 12783 Destination Port 16 bits 80 Sequence Number 32 bits 0xbfcdab00 Ack Number 32 bits 0xaeb10908 x2 4 bits Data Offset 4 bits 20 Flags 8 bits TH_ACK, TH_PUSH Window size 16 bits 8192 TCP Checksum 16 bits 0xebcd Urgent Pointer 16 bits 0x0

36. TCP pseudo header • From the TCP or UDP point of view, the packet does not contains IP addresses. (IP being the layer beneath them.) • Thus, to do a proper checksum, a "pseudo header", that is, one that's not there, but that is taken into account in the important parts of the IP header, that is, source and destination address, protocol number, and data length. It it to ensure that the checksum takes into account those fields.

37. References • http://www.enderunix.org/docs/en/rawipspoof/ • http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html • http://www.moon-soft.com/program/bbs/readelite514835.htm • http://linuxraw.jiaogen.com/2010/04/28/linux-sock_raw%E5%8E%9F%E5%A7%8B%E5%A5%97%E6%8E%A5%E5%AD%97%E7%BC%96%E7%A8%8B/ • http://blog.chinaunix.net/space.php?uid=11278770&do=blog&cuid=226419