Welcome to day 31 of Cybersecurity Awareness Month!. I hope that you have enjoyed reading and responding to it as much as we have enjoyed writing it!
We finish the month with a voyage into the history of the Internet. The Ident Protocol is defined in RFC 1413 and was intended to help identify the user of a TCP connection. Essentially, it acts as a server on port 113 TCP and historically was used by protocols such as FTP, SMTP, NNTP, and was an integral part of IRC by providing a mechanism to identify the user.
ident has fallen out of favor as security on the Internet has become a growing issue, mostly because it permits a way to enumerate userids on a system, but also because it uses an inbound query which is blocked by stateful inspection firewalls (unless explicitly permitted) because it has not been initiated from the inside.
Unfortunately, even though ident is largely deprecated and generally is not considered a safe protocol, you will often find it running on default operating system installs and on so called black boxes which will often come configured with ident running thus allowing a possible attack vector.
It is my personal belief that there is no good reason to allow ident into your network. or to run ident on your servers and workstations. So I leave you with these questions...
Are there any legitimate uses of ident that warrant allowing ident into your network?
If you do allow ident into your network...how do you secure it?
As usual I look forward to your feedback. either via the comments or through our contact page.
Have an enjoyable All Hollow's Eve!
Reader J.T. Moore points out that there are still rare occasions where ident is required. In that case oidentd is an excellent ident server. "This provides a valid ident response which solves the problem with the IRC server, but it doesn't allow anyone to use ident to probe for user names or active connections."
-- Rick Wanner - rwanner at isc dot sans dot org
A new version of "NIST Special Publication 800-41, Revision 1, Guidelines on Firewalls and Firewall Policy" is available, it can be found here ==> http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf
This is an update to the original document, published in 2002. If you are required to be compliant with the NIST 800's, either by regulatory compliance or internal policy, this updated document is worth a read.
ICANN is currently formulating their 2010 - 2013 Strategic Plan. In order to define priorities, they have a presentation framing what's on the table ==> http://sel.icann.org/meetings/seoul2009/presentation-strategic-plan-consultation-28oct09-en.pdf along with a webcast and a survey for interested stakeholders to voice their opinions ==> http://sel.icann.org/node/7103
This may not seem like your standard security "recon and exploit" blog entry - in fact, it sounds like something your boss might want you to read, but what ICANN decides to do has the potential to impact how we use the internet in fundamental ways. It sounds like the survey is for this next week only, to be used for the first draft of the plan in November. So if you are interested, read the presentation and get your opinions in.
Cyber Security Awareness Month - Day 30 - The "Common" IPSEC VPN Protocols - IKE / ISAKMP (500/udp), ESP (IP Protocol 50), NAT-T-IKE (500/udp, 4500/udp), PPTP (tcp/1723), GRE (IP Protocol 47)
IPsec is a group of protocols that together encapsulate, authentication and encrypt traffic. IPsec is a common solution for corporate VPN gateways. The 2 endpoints of an encrypted tunnel are usually referred to as "peers", but in some cases can also be called a client and a gateway (but even then they are still peers).
This is not meant to be a complete discussion of VPNs or IPsec - there are entire books dedicated to just this topic (some of them are on my bookshelf I'm sad to say). If you spot any errors, find something that should be added, or have a personal experience you'd like to share on this topic, please add your comments !
The most common protocols used in today's VPNs are:
IKE (Internet Key Exchange) (formerly known as ISAKMP - Internet Security Association and Key Management Protocol) is the most common protocol used to authenticate the VPN session. IKE is transported on 500/udp.
Setting up an IKE Security Association is generally split into 2 phases:
Phase 1 sets up an initial secure tunnel between the peers. This phase always uses a Diffie-Hellman (DH) key agreement. IKE Phase 1 can use either "Main Mode" or "Aggressive Mode" to get this job done. Main Mode uses three 2-way exchanges in its process, Aggressive Mode squeezes this down to a "one and a half exchange" (see below)
Main Mode negotiation has 6 messages.
Client -> Server
Server -> Client
Client -> Server
Server -> Client
Client -> Server
Server -> Client
Aggressive Mode has 3 messages.
Client -> Server
Server -> Client
Client -> Server
The weakness of Aggressive mode is that some data is exchanged before a secure tunnel is in place, so sniffing an aggressive mode connection can result in compromise of the final association. However, Aggressive mode is a quicker process than Main Mode.
Phase 2 negotiates the IPSEC Security Association, which among other things includes what encryption algorithms to use (AES or ESP are common protocols that might be negotiated). The IPsec security association is what actually transports and encrypts the data.
IKE can use Pre-shared keys, RSA Signatures or RSA encrypted nonces to authenticate peers.
ESP (Encapsulating Security Payload) is the most common protocol for encapsulation of the actual data in the VPN session. ESP is IP Protocol 50, so is not based TCP or UDP protocols. Because of this, NAT devices often have a problem with ESP (read on for more on this). The actual encryption algorithm within the tunnel is negotiated when the ESP session starts up. The vpn gateway generally has a list of supported protocols (3DES and AES are the most common these days), which it will match up to a similar list that the client will offer up as it attempts to connect.
A common configuration decision is to decide if a VPN tunnel will use "tunnel mode" or "transport mode". Transport mode encrypts the data payload, but maintains the original IP header fields. Tunnel mode encapsulates the whole packet, so encrypts both the header and payload, and adds its own header fields, treating the entire original packet as payload. In other words, Transport Mode has less overhead (both in encryption cycles and added bytes), but Tunnel Mode encrypts the entire packet.
NAT-T-IKE (4500/udp) allows the ESP session to be encapsulated within a more NAT-friendly UDP packet. Most VPN clients and gateways natively support NAT-T. NAT-T is sometimes also seen on 500/udp, especially in older implementations, or on any configured tcp or udp port (10000 is the default tcp port on cisco gear). Some vendors also allow "NAT-T style" encapsulation within TCP packets
Common IPSEC NAT problems solved by NAT-T:
1/ If an intermediate device passes only TCP and UDP traffic, the ESP encapsulation will fail, since ESP is IP Protocol 50 (ie - it's not TCP or UDP). The symptom that the end-user sees in this case is that their VPN session connects, but then no traffic is passed. Helpdesk calls for this are typically "I can connect, but can't get my email / files / etc"
2/ When a person in a remote location (conference hotel, branch office, wherever) VPN's into head office, their session works. When a second person at that same location VPN's into the same head office, both sessions immediately fail. This is a problem with NAT. Since ESP is not based on TCP or UDP, it does not use ports, so the second ESP session from A to B looks exactly like the first ESP session from A to B. The fix for this is NAT-T, though if the two ESP sessions NAT out on different public IP's, that will work as well.
Both of these issues are more completely described in the RFC for NAT-T (see below).
PPTP is actually a "meld" of a PPP session (tcp/1723) and a GRE (Generic Route Encapsulation) tunnel (IP protocol 47). PPTP is generally authenticated using MSCHAP-v2 or EAP-TLS, and in later versions is encrypted using Microsoft's MPPE (Microsoft Point-to-Point Encryption, RFC 3078).
AH (Authentication Header) is always covered in discussions of IPSEC and VPN's, but I've never personally used it for a production VPN solution - since AH does not encrypt the payload, it's not particularly appealing in situations that require confidentiality (as most internet based VPNs do). AH is all about verifying the integrity of the data, rather than actually encrypting it for confidentiality. AH uses IP Protocol 51.
For security assessments, ike-scan is a handy command line tool that uses IKE to discover and fingerprint IPSEC VPN gateways. This tool also comes with a brute-forcer for IPSEC preshared keys (psk-crack). Linux, OSX and Windows versions are available here ==> http://www.nta-monitor.com/tools/ike-scan
SSL based VPNs seem to be an industry trend recently. While these capitalize on the encryption and certificate support built into today's operating systems and browsers, they also migrate us into a world of a more well-understood protocol, with a much larger stable of exploit tools. If implemented correctly, SSL VPNs can be a great thing. However, if implemented without a solid understanding of the potential pitfalls, SSL VPNs are susceptible to attack using many of the same tools you might use against an SSL session to a protected website. For more information, see our Cyber Security Awareness Month day 25 Discussion of ports 80 and 443 ( http://isc.sans.org/diary.html?storyid=7450 ) and this recent entry on Sniffing SSL ( http://isc.sans.org/diary.html?storyid=7477 )
Typical IKE-SCAN sessions are shown below (ip addresses represented as "a.b.c.d"). Note that some hosts return a full handshake, some simply return a notify
Scanning a single host:
c:> ike-scan.exe vpn.somecompany.com
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
a.b.c.d Main Mode Handshake returned HDR=(CKY-R=4feb587b34903be0) SA=(En
c=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
Ending ike-scan 1.9: 1 hosts scanned in 0.152 seconds (6.58 hosts/sec). 1 returned handshake; 0 returned notify
Scanning a subnet with several VPN gateways:
c:> ike-scan a.b.c.0/24
Starting ike-scan 1.9 with 64 hosts (http://www.nta-monitor.com/tools/ike-scan/)
a.b.c.10 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=353da7769f710767)
a.b.c.33 Notify message 7 (INVALID-EXCHANGE-TYPE) HDR=(CKY-R=c03397649b1d76fe)
a.b.c.58 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=41665b363ae98c7c, msgid=71d55f0e)
a.b.c.75 Main Mode Handshake returned HDR=(CKY-R=68f5d1b1b716f49e) SA=(En
c=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
a.b.c.77 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=36431b961d8d5237)
a.b.c.105 Main Mode Handshake returned HDR=(CKY-R=1ecbf70c195d4aaf) SA=(En
c=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
a.b.c.130 Main Mode Handshake returned HDR=(CKY-R=59e03fd934356da6) SA=(Au
th=PSK Hash=SHA1 Enc=3DES Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00
007080) VID=8404adf9cda05760b2ca292e4bff537b (Maybe Sidewinder G2) VID=baf4ee8d4
Ending ike-scan 1.9: 256 hosts scanned in 40.409 seconds (6.34 hosts/sec). 3 returned handshake; 4 returned notify
Now, let's try forcing these same hosts to an aggressive mode IKE exchange. Note the new information for hosts .10 and .105 (including the VPN vendor), and that host .130 returns less information this time. Hosts .33 .58 and .75 didn't answer at all this time. Differences like this not only give you new information directly, but the information that is left out can be valuable as well during recon, allowing you to sometimes identify targets right down to OS versions, which can in turn identify potential bugs that might be used during a penetration test.
c:> ike-scan --aggressive a.b.c.0/24
Starting ike-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/ike-scan/)
a.b.c.10 Aggressive Mode Handshake returned HDR=(CKY-R=353da776bbb4b996)
SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28
800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b86
96fc77570100 (Dead Peer Detection v1.0) VID=c0fa006bbbb5b99678f8a0fa93809964 VID
=09002689dfd6b712 (XAUTH) KeyExchange(128 bytes) ID(Type=ID_IPV4_ADDR, Value=a
.b.c.10) Nonce(20 bytes) Hash(16 bytes)
a.b.c.77 Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=36431b96ca6a9cf4)
a.b.c.105 Aggressive Mode Handshake returned HDR=(CKY-R=1ecbf70ceb9f629b)
SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28
800) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Pee
r Detection v1.0) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=eb0c501
1eb9e629b323f3948e404dff2 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pix01.
somecompany.com) Nonce(20 bytes) Hash(16 bytes)
a.b.c.130 Unexpected IKE payload returned: Delete Notification=(Type=INVALID-EXCHANGE-TYPE, SPI=, Data=)
Ending ike-scan 1.9: 256 hosts scanned in 42.905 seconds (5.97 hosts/sec). 2 re
turned handshake; 1 returned notify
As you can see, reading RFC's is a great way to get way to get the real "nuts and bolts" source material for all of these protocols. They aren't always the easiest to get through, but any understanding of internet basics should include the RFC's upon which they're based. RFC's build on each other, you will see that many of these RFC references are updated versions of now obsolete original documents.
RFC2409 - RFC4306 Internet Key Exchange (IKEv2) Protocol - http://tools.ietf.org/html/rfc4306
(Obsoletes RFC2407, RFC2408, RFC2409, Updated by RFC5282)
IP Encapsulating Security Payload (ESP) - http://tools.ietf.org/html/rfc4303
Negotiation of NAT-Traversal in the IKE - http://tools.ietf.org/html/rfc3947
UDP Encpasulation of IPsec ESP Packets - http://tools.ietf.org/html/rfc3948
Microsoft Point-To-Point Encryption (MPPE) Protocol - RFC 3078 - http://tools.ietf.org/html/rfc3078
RFC4302 IP Authentication Header - http://tools.ietf.org/html/rfc4302
The ESP Triple DES Transform - http://www.ietf.org/rfc/rfc1851.txt
The Transport Layer Security (TLS) Protocol Version 1.2. - http://tools.ietf.org/html/rfc5246
(Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492)
>> (AES was originally RFC3268)
DNS is a network client/server protocol that allows clients to resolve hostnames into IP addresses (and vice-versa). The DNS protocol and most DNS implementations, both client-side and server-side, have had a very troubled past. This diary entry will provide a quick description of the DNS protocol and some of the different threats/attacks against it. There is probably over 100 RFCs dealing with different aspects of DNS, so this diary is only going to hit a couple of the high level points.
The most common form of DNS is a client requesting resolution of a hostname to IP address. For this, the client sends UDP port 53 packet in the appropriate format to it's configured DNS name server. That server then looks in it's local cache and if not found, attempts to resolve the query against other DNS servers on the Internet. There is a complicated hierarchy of DNS servers on the Internet that is seeded by 13 root DNS servers, which point to other nameservers for top-level domains like .com, .net, .uk, .de, etc. There are only 13 named servers because of the maximum 512 byte UDP limitation in the DNS protocol; in practice many of the servers are load-balanced and/or use anycast so that they are geographically dispersed.
DNS servers have "zone files" that contain the hostname to IP address tables and reverse files that do the opposite. It is also common/recommended for DNS servers to be setup in a master/slave relationship where the slave servers will download the zone files from the master at configured intervals. The zone transfer occurs over TCP port 53, for reliability.
DNS uses UDP for speed, but there is a 512-byte size limit on the original DNS protocol. If a query response exceeds 512-bytes, the server flips on the TC bit in the reply header. A client receiving this will then retry the query using TCP to receive the full response. I have often seen firewall administrators get this wrong and filter all TCP 53 to their DNS server (except for external slave DNS servers) and everything works fine until they have long DNS replies and their server is telling clients to retry with TCP, only to be blocked by the organization's firewall.
From a threat perspective, there have been a number of different attacks against the DNS protocol. The most damaging protocol attack is called cache poisoning and when performed successfully allows an attacker to modify IP/hostname information in a DNS server's cache. The cache poisoning can happen in different ways and there have been preventions implemented in DNS servers when these weaknesses were discovered, but most experts agree that the only way to effectively prevent against these attacks at a protocol level is with DNSSEC. Cache poisoning has been seen in the wild over the years and the results were quite spectacular, but the attackers were overzealous and easily identified. A successful cache poison attack that is surgically executed would be hard to detect.
The second threat against DNS is standard programming errors in client or server daemon code. BIND is the most common DNS server implementation and there has been remote exploits against it in the past. Also, there have been problems in numerous client resolver libraries that could be exploited with malicious DNS servers.
It should be noted that an attacker who can see your DNS queries can also forge responses so that he controls the IP address returned. Until DNSSEC is fully implemented, this is just an architectural weakness (and an unfortunate result of the performance/security tradeoff). That is why SSL is so important for anything critical.
Public DNS servers are also used for reflective DoS attacks. Attackers can send spoofed IP packets with a small query that results in a larger DNS reply packet. The unwitting DNS server responds with a large packet to the victim. Network/system administrators should check their public DNS servers and ensure that they do not allow public recursion.
There is a push now to implement DNSSEC, which is basically an extension to DNS providing signatures of the DNS zone files. This would prevent many of the attacks against the DNS protocol. However, progress to implement DNSSEC has been purposefully slow and deliberate, so that the DNS operators don't "break the Internet".
Here are some URLs that provide some background information:
D.J. Bernstein's intro to DNS: http://cr.yp.to/djbdns/intro-dns.html
The DNS network protocol: http://www.networksorcery.com/enp/protocol/dns.htm
DNS research papers: http://dns.measurement-factory.com/writings/
DNS cache poisoning attacks in 2005: http://isc.sans.org/presentations/dnspoisoning.html
With projects like DShield, I have spend a lot of times around logs. One of the challenges in collecting logs from multiple sources is correlation and with that, correlating time. In addition to logs, some authentication systems like Kerberos will not work unless participating systems are synchronized to the same clock.
Luckily, ntp provides for a rather simple and quite accurate way to keep time on networked systems. NTP Version 3, which is the version you will find currently implemented, is defined in RFC 1305 . Even though ntp isn't terribly complicated, there is a simpler version called SNTP (simple NTP). SNTP is defined in RFC 2030 .
Synchronizing time starts out with a primary reference source. This is a "standard clock" we use as a reference. If all you need is internal synchronization, you may just define some clock as your standard clock. But more likely then not, you are interested in synchronizing your clocks with the outside world. Various government standard organizations operate such standard clocks, and synchronize them with each other. The time to which all these national clocks are synchronized is referred to as UTC ("Universal Coordinated Time"). Occasionally, UTC is adjusted by adding leap seconds in order to match the rotation of the earth which is not exactly regular.
Now back from time to ntp. We established that we start with a master clock. All of our clocks are synchronized with this "master clock" using ntp. In order to do so, we need an ntp server connected to the master clock, and a ntp client on our system to connect to the master clock's ntp server. Usually, you end with an internal ntp server (or a couple of them for redundancy) that is synchronized to an external source. All your internal hosts will then synchronize to your own internal standard.
Now what about the NTP protocol? How does it work? NTP deviates a bit from the standard port use. Most clients will pick an ephemeral port (>1023) and connect to the server's fixed port. For NTP however, the connection will usually be from UDP port 123 to UDP port 123 (but can be from high port to udp/123 ).
The client will connect to one or more servers, receive the time from each server. Next, the client will calculate a "drift" indicating what adjustment needs to be made to the internal clock to keep it in sync. One of the nice features of ntp is that adjustments are applied gradually, and large "jumps in time" are avoided. The ntp protocol definition explains in a lot of details various algorithms that should be used to pick the "best time" from a set of time servers.
NTP expresses time as 64bit numbers. The first 32 bits are the number of seconds from January 1st 1900. The remaining 32 bits express the fraction of seconds. 32 bits = 4 billion seconds or about 136 years. On Februrary 7th 2036, at 6:28:16 (if my math is right), ntp will "overflow". Lets hope we will have a 128 bit version of ntp implemented by then.
How is NTP secured? By default not at all. Some of its security comes from its distributed nature and by using multiple time servers. Encryption and authentication is optional with NTP. Most of the time, access to ntp servers is just controlled by IP address. But a shared secret may be used as a password and to help authenticating the response. The most recent version of ntp does allow for PKI support. For more about ntp security, see the GIAC Gold paper by Matt Willman 
Couple words on finding an appropriate time server: For a reasonably large network, it may be appropriate to get your own dedicated time server. There are some reasonably inexpensive products that will synchronize with non-network external clocks like GPS (usually requires an external antenna), cell phone networks (works well if you have cell phone reception in your datacenter. Does not require a monthly subscription to a cell phone service) or the governments time radio signal.
If you are concerned with too many clients connecting to your ntp server: ntp has an option to broadcast or multicast ntp data. That way, you can easily serve an entire network with time information without having to support individual connections. Multicast ntp uses the IP address 18.104.22.168.
Other time servers: Many ISP's routers have pretty good time servers build in. Check the router your network is connected to. Windows systems usually have "time.microsoft.com" pre-set, OS X systems use "time.apple.com" by default. Linux addapted pool.ntp.org over the last few years. pool.ntp.org is a set free reachable time servers . Or you may refer to a list of public time server .
About once a week, we have a reader complain about a bad certificate for "incidents.org". Many years ago, this site was known as "incidents.org", not "isc.sans.org" or "dshield.org". As a result, you may still come across a reference to "https://www.incidents.org". The domain still points to the same IP address as isc.sans.org, but our SSL certificate is issued for "sans.org", not "incidents.org", which causes the bad certificate warnings.
This is a common issue: It is trivial to use "Name Based Virtual Hosting" for regular web sites. The browser will send a "Host" header indicating which host it would like to connect to. This host header is mandatory ever since HTTP/1.1. But for https, this doesn't work. The host header is now encrypted, and in order to decrypt it, the server needs the correct key... if the key is different for each host, then you got a catch 22. As a result, each https host needs a dedicated IP (or port, but that's ugly).
In order to solve this problem, the Internet gods brought us RFC 4366 and "TLS Extensions" . Or as the RFC will tell us right in the beginning:
Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable in order to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. 
More and more browsers and web servers start to support RFC 4366. With this, we solve another problem (at least partially): Monitoring https traffic. It was always possible to log the IP address. But with RFC 4366, the host name is now transmitted in the clear, as the following fragment of a packet capture shows:
19:28:02.363758 IP browser.60299 > dshield.org.https: Flags [P.], ack 1, win 32850, length 167 0x0000: 4500 00cf cb8c 4000 4006 0000 0000 0000 E.....@.@....... 0x0010: 41ad da4b eb8b 01bb 8537 8bc0 6340 3c7a A..K.....7..c@<z 0x0020: 5018 8052 26dd 0000 1603 0100 a201 0000 P..R&........... 0x0030: 9e03 014a e782 0201 a72f 0250 7a55 ec2d ...J...../.PzU.- 0x0040: 9878 d405 65b2 402d e00e 0054 70a1 9c7e .x..e.@-...Tp..~ 0x0050: 72e0 8e00 0044 c00a c014 0088 0087 0039 r....D.........9 0x0060: 0038 c00f c005 0084 0035 c007 c009 c011 .8.......5...... 0x0070: c013 0045 0044 0033 0032 c00c c00e c002 ...E.D.3.2...... 0x0080: c004 0041 0004 0005 002f c008 c012 0016 ...A...../...... 0x0090: 0013 c00d c003 feff 000a 0100 0031 0000 .............1.. 0x00a0: 0017 0015 0000 1273 6563 7572 652e 6473 .......secure.ds 0x00b0: 6869 656c 642e 6f72 6700 0a00 0800 0600 hield.org....... 0x00c0: 1700 1800 1900 0b00 0201 0000 2300 00 ............#..
In this case, I connected to "secure.dshield.org". Wireshark will recognize the extension (so does tshark). The following display filter will select all packets with the "sever_name" ssl extension: ssl.handshake.extension.type == 0x0000 .
Now you may ask: Is this a problem? Well, if you want to keep the host name secret, then it is. But without it, there is a one-to-one relationship between hostname and IP address, so not much is lost, and the host name is revealed in clear text in the server's certificate. Is there the possibility of a known plain text attack? Maybe... (e.g. we know there has to be a "Host: ..." header with known content). But I am not enough of a crypto geek to know. From my perspective, there is plenty of known plain text in https traffic.
But there is also an opportunity here. Maybe a tool to log the hostname. Or a tool that compares the certificate coming back to the host name requests and alerts of a mismatch.
Of course, once I get around to it, incidents.org may get its own, valid, SSL certificate.
VMware released security advisory VMSA-2009-0015 today, announcing patches that resolve two security issues with some versions of VMware Workstation, Player, ACE, Server, Fusion, ESXi and ESX products. For details, see:
VMware Fusion 3.0 went from Release Candidate to General Availability last night, as did VMware Workstation 7.0 and VMware ACE 2.6
Lots of new stuff - the feature I welcome the most is nested VMs. This allows you to run ESX with guests inside of workstation (if you have enough memory that is). This is a great feature if you are doing ESX work on your laptop. This is common in both lab and testing, but we also use this a lot in training. This feature has been in the workstation and fusion products (unsupported) for quite some time, but VMware is finally rolling it into the fold of supported features.
AES encryption of disk images is a feature that's been on ACE, but is now available on the other desktop products. This is a great help to anyone doing PCI or HIPAA work in a VM. You can now for instance transport a VM and use encryption native to the product, as opposed to adding a step and another product to get the encryption job done. The encryption on disk also (maybe) fills the "data encryption at rest" requirement in many compliance frameworks. Keep in mind though that achieving actual compliance with any compliance framework depends on a lot more than just encryption - it's best to involve your auditor before running sensitive VM's on a laptop. This one new feature is very welcome and is certainly required in many compliance situations, but might not get you all the way to compliant just on it's own.
Other new features:
- support for Windows7 (and it's associated new graphics APIs) and Windows Server 2008.
- support for VMs with up to 4 processors and 32GB of memory (with a new 16GB laptop coming, I'm looking forward to this !)
- ALSA sound support for Linux ( this has been a long time coming ! )
- a nifty new "pause" feature, allowing you to pause a VM if you need some temporary processor power for your host or another VM
- a new Virtual Network Editor, which is long overdue (especially on Fusion !)
Interestingly, ACE now has the capability to create VMs, and Workstation now has P2V features. It's really seeming like VMware is pushing all the products up one notch in the totem pole with this release - ACE seems to be turning into workstation, and workstation seems to be morphing into the old server product
Lots of posts on the release candidate features, it looks like the GA code has the same feature list (as you'd expect):
Rob VandenBrink is a Security and Network Consultant at Metafore (www.metafore.ca)
In the series of posts this month we've been looking at network ports relevant to security administrators. This note explores the ports used for Active Directory (AD) communications, which is a topic particularly relevant for allowing AD traffic across a firewall. For instance, you may be wondering which ports to open to allow AD replication across internal subnets, or to allow an AD member server on a screened subnet to authenticate to a domain controller on another subnet.
Active Directory communications involve a number of ports, some of which are more familiar to network and security administrators than others. These were outlined in the Active Directory Replication over Firewalls article by Steve Riley:
- RPC endpoint mapper: port 135 TCP, UDP
- NetBIOS name service: port 137 TCP, UDP
- NetBIOS datagram service: port 138 UDP
- NetBIOS session service: port 139 TCP
- SMB over IP (Microsoft-DS): port 445 TCP, UDP
- LDAP: port 389 TCP, UDP
- LDAP over SSL: port 636 TCP
- Global catalog LDAP: port 3268 TCP
- Global catalog LDAP over SSL: port 3269 TCP
- Kerberos: port 88 TCP, UDP
- DNS: port 53 TCP, UDP
- WINS resolution: port 1512 TCP, UDP
- WINS replication: 42 TCP, UDP
- RPC: Dynamically-assigned ports TCP, unless restricted
For a full listing of AD-related services, see Microsoft's support article 832017 Service Overview and Network Port Requirements for the Windows Server System.
Which of these ports actually need to be allowed through the firewall depends on the scenario you're implementing and on your environment. For instance, support for NetBIOS services may unnecessary in situations where you have newer Windows systems supporting the SMB over IP protocol. Similarly, newer Windows environments make use DNS, instead of Windows for name resolution.
The ports that need to be open to facilitate cross-firewall AD replication differ, depending on the versions of Microsoft Windows in your environment. Microsoft provides OS-specific guidelines in its Active Directory and Active Directory Domain Services Port Requirements article. For instance, replication between servers that use Windows 2000 or 2003 require the following ports open bidirectionally on the firewall that's between the servers:
- RPC endpoint mapper: port 135 TCP
- LDAP: port 389 TCP, UDP
- LDAP over SSL: port 636 TCP
- Global catalog LDAP: port 3268 TCP
- Global catalog LDAP over SSL: port 3269 TCP
- DNS: port 53 TCP, UDP
- Kerberos: port 88 TCP, UDP
- SMB over IP (Microsoft-DS): port 445 TCP
- RPC: Dynamically-assigned ports TCP, unless restricted
To restrict the use of RPC ports, follow instructions in Microsoft's support article 224196 Restricting Active Directory Replication Traffic and Client RPC Traffic to a Specific Port and a TechNet blog entry Dynamic Client Ports in Windows Server 2008 and Windows Vista.
Authentication to AD
AD uses the following ports to support user and computer authentication, according to the Active Directory and Active Directory Domain Services Port Requirements article:
- SMB over IP (Microsoft-DS): port 445 TCP, UDP
- Kerberos: port 88 TCP, UDP
- LDAP: port 389 UDP
- DNS: port 53 TCP, UDP
- RPC: Dynamically-assigned ports TCP, unless restricted
Tunneling AD Traffic Using IPSec
If you don't like having to open this many ports, you could use IPSec to tunnel the traffic across the firewall. You could use ESP with encryption disabled, so the packets would still be cryptographically signed and tunneled, but your intrusion detection systems (IDS) would still have visibility into the traffic.
Jason Fossen, who teaches the Securing Windows class at SANS, shared with us additional insights regarding the use of IPSec:
Because IPSec connections can be limited to those users and computers in specified global groups, is tightly integrated into the host-based Windows Firewall (which would be configured on all DMZ servers and participating controllers), and can optionally be tied into a Network Access Protection (NAP) infrastructure, the use of IPSec can provide benefits the perhaps outweigh the IDS/IPS hassles.
The Use of AD in the DMZ or a Screened Subnet
Jason Fossen also shared his thoughts on architecting AD in environments where some Windows servers reside close to the network's perimeter, such as in the DMZ or a screened subnet. He recommending implementing a separate forest for DMZ servers that need to be domain members (perhaps with a one-way cross-forest trust to the internal forest), rather than joining DMZ servers to the internal forest directly. Jason continued:
The DMZ controller(s) will be located in a new perimeter network attached to a firewalling device. When implementing a cross-forest trust, after configuring groups and permissions on the DMZ servers (which requires LDAP traffic), the only traffic that must be allowed through the firewall is Kerberos. If the DMZ servers must be joined to the internal forest, then it’s better to place Read-Only Domain Controllers (RODC) in another perimeter network of the firewall for the sake of the DMZ servers.
Also, with the use of PKI, RADIUS, reverse proxy servers, etc., it has become less necessary to either join DMZ servers to the internal forest or to establish a one-way cross-forest trust from the DMZ forest to the internal one, even when users must authenticate with the internal forest credentials.
Jason's SANS course explores this topic in detail.
This note outlined the key points for AD traffic considerations. For additional guidelines, read through the articles referenced in the text above.
Liked this? Post it to Twitter!
Why bother breaking down the door if you can simply ask to be let in? Social engineering works, both during penetration testing and as part of real-world attacks. This note explores how attackers are using social engineering to compromise computer defenses.
Starting in the Physical World
We have spent most of our lives in the physical world, whose norms we know well. As a result, we tend to trust messages that come to us in the physical world more than those in the "virtual" world of the Internet:
- One example of this was the case of malware that began spreading via parking violation notices, which were placed on windshields of parked cars. The notices attempted to lure victims into visiting a malicious website.
- Other physical world attacks involve phones, whereby attackers use compromised VoIP accounts to leave voice messages that invite victims to call the "bank" to handle a supposed problem with their banking account. Sometimes such "vishing" correspondence arrives via text/SMS messages.
- In another physical world example, the Conficker worm manipulated the autorun.inf file on the infected USB key to trick the next victim into launching its malicious software.
Other social engineering attacks in the physical world have been effective as part of penetration testing or research:
- Pen testers left USB keys in public areas, waiting for the employees to pick them up and insert them into their PCs at the office.
- Pen testers sent CDs to the targeted organization, waiting for employees to insert them into their PCs at the office.
- Researchers asked people to reveal their passwords in exchange for a pen and chocolates. (I hope many of these passwords were fake.)
Malware Installation Tricks
Attackers increasingly rely on social engineering tactics to trick victims into installing malicious software. There are numerous variations of the approaches seen in the wild, including the following:
- After initially infecting a PC with a fake anti-virus tool, attackers may redirect the victim's searches for technology review sites. The idea is that if the victim wants to determine the legitimacy of the downloaded anti-virus tool like AntiVirus2010, he'll be presented a fabricated review that extols the virtues of the fake product.
- Attackers use search engine optimization (SEO) techniques to direct victims to malicious clones of legitimate sites. One such SEO technique involved entirely mirroring the legitimate sites and DDoS'ing the legitimate sites.
- Malware authors may upload malicious versions of popular software to shareware sites and use botnets to download their files to inflate the download counter, as was performed by the Nugache worm. This tricks the victims into downloading malicious files, because the shareware site shows them as being most popular.
- Social networking sites have been a hotbed for distribution of malware, often by sharing links via compromised accounts. For instance, this technique was employed by the Koobface worm to spread via Facebook, MySpace, and other such sites.
- Spammers often send email messages that look like software upgrade advisories to trick victims into installing malicious programs. One of the recent examples involved a warning to download an upgrade to the Outlook Web Access client. Similar techniques involve the use of fake and real news bulletins, as was the case with malware-infused Michael Jackson spam.
Targeted Attack Tricks
Attackers may profile victims to include the person or company-specific social engineering elements in the intrusion campaign:
- The attacker's email, instant, or social networking messages may be automatically customized based on the user's locale to make them seem more relevant, as was the case with the Waledac worm.
- The attacker's messages may be spoofed to come from a trusted or expected sender, or may include content the victim expects to receive.
- Attackers may use social networking and resume sites to profile the victim, so their communications are more likely to be read and acted upon.
How else are Internet attackers using social engineering? If you have real-world stories to share, please send us a note.
Liked this? Post it to Twitter!
Port 1433 together with port 1434 are the ports most associated with MSSQL or to security people as the Slammer ports.
Port 1433 is typically used for database connections, but like all TCP/IP services it does not have to be and people do move the server to a different port. When alternate ports are used, then the SQL Server Browser, listening on port 1434, lets users connect to the database and identify which port is being used by the database. The port is also called the MSQL monitoring port by some people.
MSSQL has a number of security risks associated with it, most notably is the Slammer worm which appeared in January of 2003. More than six years later it is still going around the internet and is still one of the highest hit ports in our database. Mainly because it still works.
Now most people do not intentionally open up database ports to the internet, but a few of the Microsoft products included the desktop edition of MSSQL (MSDE) so many people inadvertently had these ports open and were infected.
A number of worms/bots have also exploited MSSQL through the default SA password which for a long time was blank. This was later fixed with a patch and has subsequently been addressed in the later versions of MSSQL. However we still see a lot of scans for the port and in penetration tests entry is often gained through misconfigured MSSQL servers.
In short, databases are accessed by applications there is no good reason for them to be directly accessible from the internet.
We just released a significant update to our web honeypot. If you are running it, please update (and make sure automatic updates are enabled).
If you are not running the honeypot yet, here is how to get started:
- you will need Apache and PHP (should work on Windows, but we do most of our testing on Linux)
- you DOÂ NOT need to dedicate an IPÂ address to the honeypot. It will work fine as a virtual host.
- log in to "My ISC"/"My DShield" https://isc.sans.org/myisc.html
- click on "My Information" https://isc.sans.org/myinfo.html
- find the web logs signup form on the page (see image below). Fill in your information.
- The "Latest honeypot version" link will link to the honeypot. Download it
- create an empty directory (e.g. /srv/www/vhosts/webhoneypot )
- uncompress the webhoneypot into this EMPTYÂ directory. (tar xzvf webhoneypot.tgz)
- configure the honeypot using our configure script: lib/config.php
The 'docs' directory includes a sample apache configuration (honeypot.dshield.org.conf). You will need to adjust the directory.
Please let me know if you are running into any issues, and THANKS a lot for your help. The data will be publicly available to anybody interested in helping us analyze the data.
Port 80 and 443 are ports generally associated with "the Internet". Port 443/HTTPS is the HTTP protocol over TLS/SSL. Port 80/HTTP is the World Wide Web. Let's face it, port 80/443 are generally a given for being open on any type of filtering device allowing traffic outbound on your network. If web servers are being hosted, connections will be allowed inbound to those web servers. They are also two ports that pose a significant threat(s) to your network.
One reason for such a threat, is the very fact that we just mentioned: everyone generally associates it with the Internet and web traffic and its usually open. Sadly, it doesn't get watched that closely. I have heard the statement many times "its just people surfing the web and we ignore it cause there is too much traffic." The sad reality is that more often than not, the threat will come from people on your network surfing the web. The rise in browser based attacks is staggering to say the least.
For those that do want to watch it close, that poses a challenge as well. How do you filter? What do you filter? How do you do analysis on the traffic? Let me pose a example to you. I looked at a piece of malware about three years ago that used base64 encoded html comments, on a very benign web page, to pass commands. How do you detect that? Some software automatically defaults to port 80 if the primary port is available.
The above two threats applies to port 80 and 443 traffic. Now, let's just focus on 443 for a minute. It's encrypted traffic which means you can't read it. So what do you do? Unless you have a proxy on your network where you can inspect the traffic at that point or run a host based IDS etc., your other network tools are blind to what is there.
I have become a big fan and proponent of visual analysis for network traffic. With the amount of traffic we have on our networks today, visual analysis is in my opinion, one of the few viable options for trying to discern trends in traffic. Port 80 and 443 are prime candidates for that analysis. Things such as establishing what is normal for traffic loads, time of day, websites visited etc. can all be great baselines to know when something different starts to happen.
If you have any comments or suggestions for port 80 and 443, then please let us know. Also, there are other services that you know of that run on port 80, please post those as well!
The ports below 20 and also 37 are frequently called the "small services" and can be safely blocked. For a quick review, here is what is going on down at the bottom of the port list:
tcpmux 1/tcp #TCP Port Service Multiplexer [rfc-1078]
tcpmux 1/udp #TCP Port Service Multiplexer
compressnet 2/tcp #Management Utility
compressnet 2/udp #Management Utility
compressnet 3/tcp #Compression Process
compressnet 3/udp #Compression Process
rje 5/tcp #Remote Job Entry
rje 5/udp #Remote Job Entry
echo 7/tcp #
echo 7/udp #
discard 9/tcp #Discard
discard 9/udp #Discard
systat 11/tcp #Active Users
systat 11/udp #Active Users
daytime 13/tcp #
daytime 13/udp #
netstat 15/tcp #
qotd 17/tcp #Quote of the Day
qotd 17/udp #Quote of the Day
msp 18/tcp #Message Send Protocol
msp 18/udp #Message Send Protocol
chargen 19/tcp #Character Generator
chargen 19/udp #Character Generator
ftp-data 20/tcp #File Transfer [Default Data]
ftp-data 20/udp #File Transfer [Default Data]
time 37/tcp #Time
time 37/udp #Time
An interesting attack was developed many years ago using the echo and chargen ports. echo will send back whatever characters are sent to it, while chargen will generate random characters. By spoofing source and destination addresses/ports, it was easy to inject fake packets into a network that would generate characters from Alice's chargen port and send them to Bob's echo port, which would then echo them back to Alice's chargen which would generate more characters to send to Bob, and....I think you get the picture. Instant denial of service attack.
Cisco's routers can enable/disable the "small servers" on those devices (echo, discard, and chargen) by using these commands:
Router(config)# service udp-small-servers
Router(config)# no service udp-small-servers
Router(config)# service tcp-small-servers
Router(config)# no service tcp-small-servers
In Unix systems, edit the inetd.conf (or equivalent) file to comment out these services if you don't use them. Odds are pretty good that you don't.
If you have any additional thoughts or comments on the Small Services please let us know via our contact form, or simply add your public comments via the comment link below.
Marcus H. Sachs
Director, SANS Internet Storm Center
In case you did not notice, the DShield system is going nuts with reports on tcp/0. Stephen Hall wrote a nice Cyber Security Awareness Month diary on the subject of tcp/0 earlier this month. Did the bad guys read it and start launching probes? Is it Akamai or some other caching service? If you can do some full packet captures of any tcp/0 traffic hitting your firewalls let us know what you find out. Send us your analysis via our contact page.
Marcus H. Sachs
Director, SANS Internet Storm Center
Microsoft's Windows 7 operating system was officially released on Thursday October 22nd. I'm sure that many of our readers were lined up outside their local candy stores to buy an early copy. For those who have successfully installed it, tell us about your experience. Was it good, bad, or ugly? Any pearls of wisdom you'd like to pass along to others? You can comment directly by using the comment link below or you can send us a private message by using our contact form. Either way, we'd like to hear about some early experiences. We'll update this diary from time to time with reader comments.
Marcus H. Sachs
Director, SANS Internet Storm Center
What is BGP? It is the default Exterior Gateway Protocol for the INTERNET.
It is also often the Interior Gateway Protocol for ISPs.
It is used to exchange routing information with other ISPs and BGP speaking customer routers.
There are two major concerns about the security of BGP.
One is router table corruption either deliberate or accidental.
At DEFCON last year there was a "kewl" bgp hijack method demo'ed.
The concepts weren't really new and methods to mitigate this were well known just not implemented in many cases.
Another concern is blindly resetting BGP sessions causing the routers involved to lose route information. This diary has a fairly complete set of references for the "blind TCP RST of persistent TCP connections within the window size" vulnerability first released in 2004
This vulnerability was exasperated somewhat by route servers and looking glass implementations that provided the five tuple needed thus in some cases you only had to "guess" the correct sequence number within the windows size.
The "Blind connection reset attacks against TCP" published by F Gont here:
are harder to mitigate against since icmp packets wouldn't be expected to have MD5 authentication.
There are several recommended mitigations for BGP attacks.
Pros: Its simple to implement given that most BGP peers are one or 2 hops away from each other.
So a valid peer should be able to get a BGP packet to their peer with a TTL of 255 or 254 in most cases.
It's easy for the router to check as it is a simple Inbound_TTL >= TTL_Allowed type comparison.
It is nearly impossible to spoof an attack on a BGP session that is protected by GTSM as you have to be either directly connected or at least as close hop count wise as the expected peer.
Not all BGP speakers support GSTM.
Not all BGP speakers have an initial TTL of 255.
Not all BGP speakers use an initial TTL of 255 for resets when they have lost Session State of a BGP session. So the TCP reset may come from the OS stack which may not be GSTM aware.
There are some tunneling methods that MAY allow packets into an ISP with an unmodified TTL but those are corner cases that can be dealt with depending on implementation.
MD5 authentication of BGP sessions:
Most BGP implementations support this.
Without the "shared secret" used between peers it is nearly impossible to successfully launch a spoofing attack.
Because of the way the rfc was written it allowed the vendors to ignore MD5 authentication for connectionless resets. This can impact BGP if one of the peers lose state or has a stale connection (see section 4.1 of the rfc above).
MD5 authentication itself can be attacked, as it can be a compute intensive operation depending on the vendor's implementation.
It doesn't protect against NON-TCP based attacks.
Additional security measures recommended for BGP speakers.
Implementing prefix filtering to block advertisements of rfc1918 space and bogons.
Implementing prefix filtering to block customers from advertising cidr blocks they weren't issued.
Implementing prefix filtering based on cidr block advertisement size.
A good set of templates to secure BGP is available for several routers here.
"Modbus Protocol is a messaging structure developed by Modicon in 1979. It is used to establish master-slave/client-server communication between intelligent devices. It is a de facto standard, truly open and the most widely used network protocol in the industrial manufacturing environment. It has been implemented by hundreds of vendors on thousands of different devices to transfer discrete/analog I/O and register data between control devices. It's a lingua franca or common denominator between different manufacturers. One report called it the "de facto standard in multi-vendor integration". Industry analysts have reported over 7 million Modbus nodes in North America and Europe alone." From: http://www.modbus.org/faq.php
Modbus was oroginally developed as a proprietary communication/command protocol for SCADA/Process Control systems. It has been migrated to TCP/IP since 1999. There really isn't much to the protocol specification at all.
One of the first main issues with Modbus is that it is not designed to be run on open networks, it was intended to be used on dedicated lines, such as a serial connection, or a closed network. Ideally this is achieved through an airgap between the PCS network and the corporate IT network. It is however quite convenient to be able to monitor or even control these systems from a corporate desktop. The devices that communicate using Modbus are also typically not designed to be on open networks, and often fail from a port or vulnerability assessment scan. There really isn't much to 'hacking' these devices, if you can talk to them they do whatever you tell them to.
The Modbus protocol itself contains no security whatsoever. If you can communicate directly with a Modbus server or client you can issue commands. This can be quite important depending on the function that the slave devices are performing. The only real choices are as mentioned previously to completely airgap Modbus from any other network, or severely limit access to authorized masters.
This brief article is just the tip of the iceberg for the Modbus protocol, and any discussion of Process Control, SCADA systems and security.
Adrien de Beaupré
from their version history notes:
- Full support for Windows 7.
- Full support for Mac OS X 10.6 Snow Leopard.
- The ability to configure selected volumes as 'system favorite volumes'.
TrueCrypt is a software system for establishing and maintaining an on-the-fly-encrypted volume (data storage device).
More information here: http://www.truecrypt.org/docs/?s=version-history
Adrien de Beaupré
Welcome to day 21. Today we will talk about port 135.
In a simple way, we have these basic information:
Service Name: epmap/loc-srv
Popular Name: Microsoft DCE locator
Udp or Tcp: Both
Port 135 hosts an important service on Windows hosts. When a host wants to connect to a RPC service on a remote machine,
it firsts checks with the destination machine on port 135, to know which port is being used by the service it wants to connect into. (Yes, quite close to *nix Portmap)
The Microsoft DCE locator, which runs on port 135 will then return the port on which the desired service is running.
The original requester host will then connect to this port.
May be used by:
* DHCP server
* DNS server
* WINS server
What makes this a port of interest is that in the past, it used have lots of vulnerabilities, which were exploited by malicious users and for worms,
as the old Blaster or for bots that had the exploit on its database, like the old phatbot/sdbot.
A good move form Microsoft was to include on Windows XP ServicePack 2 a firewall default rule to block external access to this port.
However, there are still some situations where you may need to add some exceptions to remote connection on this port, such as:
- some MS SQL Server scenarios.
- some WMI (Windows Management Instrumentation), which is quite useful for CLI administration.
Whatever is the reason you need it to be open, make sure you will restrict it at the maximum possible way.
Example of a port 135 traffic (from pcapr):
01:48:35.511258 IP 22.214.171.124.3949 > 126.96.36.199.135: S 2182823608:2182823608(0) win 8760 <mss 1460,nop,nop,sackOK>
01:48:35.536500 IP 188.8.131.52.135 > 184.108.40.206.3949: S 3596070259:3596070259(0) ack 2182823609 win 17424 <mss 1452,nop,nop,sackOK>
01:48:35.974438 IP 220.127.116.11.3949 > 18.104.22.168.135: . ack 1 win 10164
01:48:35.999130 IP 22.214.171.124.3949 > 126.96.36.199.135: P 1:73(72) ack 1 win 10164
01:48:36.035866 IP 188.8.131.52.135 > 184.108.40.206.3949: P 1:61(60) ack 73 win 17352
01:48:36.561338 IP 220.127.116.11.3949 > 18.104.22.168.135: . 73:1525(1452) ack 61 win 10104
01:48:36.575457 IP 22.214.171.124.3949 > 126.96.36.199.135: P 1525:1681(156) ack 61 win 10104
01:48:36.580581 IP 188.8.131.52.3949 > 184.108.40.206.135: F 1681:1681(0) ack 61 win 10104
01:48:36.601318 IP 220.127.116.11.135 > 18.104.22.168.3949: . ack 1681 win 17424
01:48:36.605455 IP 22.214.171.124.135 > 126.96.36.199.3949: P 61:101(40) ack 1681 win 17424
01:48:36.614687 IP 188.8.131.52.135 > 184.108.40.206.3949: F 101:101(0) ack 1682 win 17424
01:48:39.871749 IP 220.127.116.11.135 > 18.104.22.168.3949: FP 61:101(40) ack 1682 win 17424
01:48:46.433952 IP 22.214.171.124.135 > 126.96.36.199.3949: FP 61:101(40) ack 1682 win 17424
01:48:59.558881 IP 188.8.131.52.135 > 184.108.40.206.3949: FP 61:101(40) ack 1682 win 17424
Pedro Bueno (pbueno /%%/ isc. sans. org)
Woke up this morning to find the news in my inbox, that Vulnerability Management company Rapid7 purchased Metasploit. Personally, I think this is a good thing. Anytime there can be commercial funding and backing put behind an Open Source program in order to further it's development, I consider it a good thing. I know this model works, as I work for Sourcefire. We have a few open source programs ourselves.
Better funding = better (more) exploits = better pen-test tool. Not that Metasploit isn't already awesome, because it is, but this will make Metasploit turn another corner in its (already successful) evolution.
I applaud HD's (and of course everyone else on the Metasploit team's) work, and may this acquisition further the success of the platform.
Read more about the purchase here.
Today one of our readers sent an interesting post from the developers of WordPress. It is about a just released version 2.8.5.
This version is called as the "Hardening Release", which I thought was quite great! According the post, these were new security features from the new 2.9 series that they decided to backport to the 2.8.x tree.
Among the new features/fix you can see:
- "A fix for the Trackback Denial-of-Service attack that is currently being seen.
- Removal of areas within the code where php code in variables was evaluated.
- Switched the file upload functionality to be whitelisted for all users including Admins.
- Retiring of the two importers of Tag data from old plugins."
Why does this news deserve a diary? For two reasons:
1) Wordpress is one of the most popular "publishing plataform" (blogs,etc...) and free...
2) In 2008 there were 23 vulnerabilities for it and in 2009 there are 12 vulnerabilities found so far...
So, this effort from the developers really deserves our attention and kudos...
Pedro Bueno (pbueno /%%/ isc. sans. org)
The Web Application Security Consortium (WASC) released last Friday the 2008 statistics, compiling website vulnerability data from more than 12K sites and detecting near 100K vulnerabilities. As in previous years, Cross-Site Scripting (XSS), information leakage, and SQL injection are at the top of the list, but with a few significant variations:
Compared to 2007, the number of sites with wide spread SQL Injection and Cross-site Scripting vulnerabilities fell by 13% and 20%, respectively, however, the number of sites with different types of Information Leakage rose by 24%. On the other hand, the probability to compromise a host automatically rose from 7 to 13 %.
The statistics are mainly collected through (black & white box) automated testing. Therefore, once again and IMHO, one of the most frequent vulnerabilities, Cross-Site Request Forgery (CSRF or XSRF), is not properly reflected in the report. All the details are available on the WASC Statistics Project website (WASS) both in HTML and PDF format.
Definitely, if you plan to take actions to improve the security of your web-apps (and you should!), start focusing on these four vulnerabilities: XSS, information leakage, SQLi and CSRF!
Today, October 20, Oracle releases its quarterly CPU. There are lots of vulnerabilities DBAs must act upon ASAP. I specially want to point out that, although it "only" addresses
More (advance) information in the pre-release announcement, and in a few hours...:
Ports 5060 and 5061, both on TCP and UDP, are associated to the Session Initiation Protocol (SIP) by IANA. In particular, port 5060 is assigned to clear text SIP, and port 5061 is assigned to encrypted SIP, also known as SIP-TLS (SIP over a TLS, Transport Layer Security, encrypted channel). Unfortunately, the standard TLS (successor of SSL) can only be established over TCP. Does this mean SIP UDP-based communications have to travel unencrypted? Fortunately not. An IETF draft covering SIP-DTLS is on the queue (DTLS is Datagram TLS, that is, UDP)... but... what is SIP?
The Session Initiation Protocol (SIP) is a signaling protocol for Internet multimedia conferencing and communications, such as Voice over IP (VoIP). It is extensively used on VoIP architectures, and is becoming the IETF alternative and "natural" replacement to the complex H.323 signaling protocol. As a signaling protocol, SIP is mainly focused on managing and negotiating all the features of VoIP sessions (or other multimedia-based protocols), such as setting up and tearing down VoIP calls.
SIP is probably one of the most complex protocols based on the length of its RFC, RFC 3261, and its flexibility and extensibility, what has caused the publication of multiple standards that update and add new functionality to it. Today, a search by SIP on RFC Editor returns 157 references.
However, it is a text-based request and response protocol, very similar to HTTP (web): SIP messages are made of headers and body, it allows multiple request methods (REGISTER, INVITE, ACK, BYE, etc), it defines entities as URI's (Uniform Resource Indicators), and the set of responses is categorized in different groups (success (2xx), redirection (3xx), etc); all them common features available in HTTP. SIP messages are ASCII encoded and can make use of the standard Multipurpose Internet Mail Extensions (MIME) capabilities. This protocol is tightly integrated with the most commonly used media protocol, RTP (Real-time Transport Protocol), used to carry the streaming and real-time multimedia sessions. The ports used for RTP communications are dynamically negotiated by SIP when a new VoIP or multimedia session is established. This behavior is very similar to FTP, where the control channel manage the communication (TCP/21), and negotiates the ports for the data channel, the one that transports the information (TCP/20 or dynamically negotiated). For those readers interested on inspecting a SIP packet capture, check this sample from the Wireshark repository, where SIP Digest authentication is used.
Why SIP is (or can be) an important protocol? As VoIP and other multimedia capabilities, such as video on demand (VoD) and triple play communications, are being widely deployed by service providers and companies, SIP is silently entering in our networks. However, some providers do not use SIP over the standard ports, and select their own set of ports; this obviously breaks communication capabilites between providers as it is like setting up your web server on a port different than TCP/80 (you need to know in what port it is listening on). Additionally, if SIP P2P (peer to peer) communications get adoption, where intermediate proxies and servers are not required for two (or more) users to establish direct multimedia communications, we might end up opening these ports (TCP & UDP / 5060 & 5061) in most firewalls, and specially, on SOHO environments.
You can start today looking for SIP traffic on your networks. Capture some traffic and analyze it. Using Wireshark you can apply different display filters to confirm if SIP is there:
udp.port == 5060 or udp.port == 5061
tcp.port == 5060 or tcp.port == 5061
sip or sdp
frame contains "SIP"
ssl or dtls
Let's get ready for the upcoming SIP and VoIP wave!
New week, new scams. Two emails showed up on our ISC scam radar this morning.
One seems directed at universities, and is informing students that their email quota is exhausted and asks them to connect to a web site (studentresume. c.la) to re-enable their account. The site includes an iframe from planetchiltern. com and doesn't even TRY to look like the web site of an university. It still asks for your userid and password, though...
Another one pretends to come from Microsoft and warns users on a rapidly spreading Conficker.B infection (sic!). Conveniently enough, the email includes the "patch and removal tool".
If you fell for either of these, now would be a good time to confess to your sysadmin :).
[Thanks to ISC readers Matt and Joe for the samples]
At first, when a pal of mine called to rant about the new tendency of his OS to go "hasta la Vista", I laughed. He is an IT professional, and a little swine flu in his computer is no big deal. Or so I thought. What started as an occasional hiccup on Thursday apparently turned into an unspectacular but complete Exitus on Friday: The computer simply didn't boot no more.
Of course we all know, often from individual experience, that a disk drive with a "mean time between failure" (MTBF) of indicated 500'000 hours is NEVER the one drive that we bought. Rather, we usually seem to get the "mean failure" version, whereas other people must be getting the "time between".
Nevertheless, this apparently hasn't taught us to be diligent with our backups. As far as backups of data on personal PCs go, most people are either in the "ignorant and negligent" or "knowing and diligent" camps. The special corner of data loss hell, the "knowing but negligent" section, seems to be solely populated by IT and technology people.
It doesn't have to be you. Go buy that USB or eSATA drive, and get that copy made TODAY.
ICMP, the Internet Control Message Protocol, was originally designed (RFC 792, 1981) to convey error conditions back to the sender of an IP packet. In today's Internet, ICMP is somewhat of an anachronism, since pretty much all programs and protocols contain their own error detection and recovery logic.
ICMP packets don't use port numbers like UDP and TCP do, but have a message type and message code field in the header instead.
ICMP/8 and ICMP/0
The ICMP packets that you probably are most familiar with are "ICMP Type 8 code 0" and "ICMP Type 0 Code 0", commonly known as "ping" and "ping reply". A "ping" is still the most commonly used command by system administrators to determine if a box is "up" and to check "round trip times" between two systems. While there are more reliable methods to accomplish either of these tasks, good old "ping" still prevails.
Ping packets can also have a data portion (payload). This triggered a big hunt for "covert channels" more than a decade ago, when an article on "Project LOKI: Arbitrary information tunneling" appeared in Phrack Magazine. Today, most firms and institutions keep "ping" blocked across their perimeter firewall, but primarily since the impact of blocking it is marginal, and not because of "covert channel" concerns. It has been a long time since mal-code authors last effectively used ping for communication. And why should they - http and https are working just fine across most corporate firewalls.
Another attack, the "smurf", relied on ICMP's ability to respond to a broadcast packet. Basically, a single "ping" sent to the broadcast address of a subnet was answered by all the active hosts on that subnet. Very neat to quickly map what's out there, but also a really good "amplifier" in a denial of service attack. This non-feature of ICMP has therefore long since been fixed: All current Operating Systems have broadcast ICMP either off by default, or support a configuration parameter to turn it off.
ICMP Type 3, "Destination Unreachable", is next to "ping" the most common of the ICMPs on today's Internet, primarily thanks to the increasing use of UDP in peer to peer networks. Unlike TCP, where the recipient of a packet can respond with a "Reset" (RST) if communication is undesired or not permitted, UDP contains no such mechanism and relies on ICMP to convey its displeasure. ICMP Type 3 Code 3, "port unreachable" is the usual answer returned on an UDP packet sent to a port that is not active (listening).
One of the cool features of ICMP Type 3 is that the error messages actually contain the first few bytes of the original packet that triggered the error. Firewalls unfortunately tend to ignore this information, and only display a useless information like "Denied ICMP type=3, code=3 from 220.127.116.11 on interface outside". A good old tcpdump or decent IDS will tell you more:
18:12:34.068212 IP 18.104.22.168 > 22.214.171.124: ICMP 126.96.36.199 udp port 53 unreachable, length 65
0x0000: 45c0 0055 95f5 0000 4001 4d0c 5801 0203 E..U....@.M.X.,.
0x0010: ad02 0304 0303 941a 0000 0000 4500 0039 ..dx........E..9
0x0020: 6749 0000 7211 4a84 ad02 0304 5801 0203 gI..r.J...dxX.,.
0x0030: c0df 0035 0025 3608 000a 0100 0001 0000 ...5.%6.........
0x0040: 0000 0000 0377 7777 0369 626d 0363 6f6d .....www.ibm.com
0x0050: 0000 1c00 01
At offset 0x001C (marked in blue), you can see the start of the original datagram. In this case, the system at 188.8.131.52 responded with an ICMP/3:3 "Port unreachable" because 184.108.40.206 apparently sent a DNS request for "www.ibm.com" to 220.127.116.11, and the latter does not seem to be running a DNS service. If you ever find your firewall under a deluge of ICMP/3 packets, sniffing them to determine the embedded original packets could help to tell you more.
ICMP/3 Type 4, "Fragmentation Needed but Don't Fragment Bit Set" is used to determine the maximum size per IP packet that a path between source and destination can support. This so-called "PMTU Discovery" helps to ensure that packets are sent at the maximum size that can squeeze through, which avoids fragmentation and reduces the bandwidth used for packet headers as compared to actual payload. In the frenzy to ban all ICMP through firewalls a decade ago, the rather useful ICMP 3/4 messages got blocked along with everything else. PMTU discovery is largely defunct today.
An ICMP/11 packet is triggered when a packet dies off because its internal "time to live" (TTL) counter expired. IP packets start their journey with a TTL of usually 255, and this counter is decremented at every network hop the packet traverses. When the counter reaches zero, the packet is discarded, and an ICMP/11 error generated. ICMP/11 are also used by the "traceroute" program, which sends packets with deliberately low TTLs and keeps track of the origins of any ICMP/11 error message it receives. By slowly counting up from the low initial TTL, a hop-by-hop mapping of the network nodes between source and destination can be performed.
The IETF started work on a paper that lists both the "threat" of ICMP and "impact" caused when an ICMP message is blocked at the perimeter. Today, a lot of firms block everything ICMP, and accept that doing so can lead to delays and time-outs in some UDP based applications. A less paranoid and equally well accepted practice is to permit ICMP/11:0 and ICMP/3:4 error replies from the outside, but to rate-limit these packets to prevent flooding.
But this is the Cyber Security Awareness Month. So ... time to improve your awareness: If you currently have all ICMP blocked on your perimeter, sniff the ICMP traffic on the outside of the firewall for a day to see what you are missing. If you currently permit ICMP through your perimeter, sniff the ICMP traffic for a day to see what it is that you are letting through.
There's no telling what you might find, in either case :)
I mentioned to my collegue that I would be writing a Handler diary today about telnet, his ears perked up and he said, "That's my favorite protocol, you know!". I'll bet there are a lot of you out there with the same enthusiasm about this age old favorite.
Telnet is a grandpa(ma) of protocols. It was the first application protocol on ARPAnet in 1969. The RFC number is two digits for goodness sake! RFC97, First Cut at a Proposed Telnet protocol, February 1971. Peeps, the song of the year was "Joy to the World" by Three Dog Night! Dev continued during the 70's and the final version was released in May of 1983. (Every Breath You Take, by The Police, if you were wondering).
It took a while to deal with the difficulty in communicating with different manufacturers. NVT (Network Virtal Terminal) standardized and fictionalized the terminal to enable a communication standard. Telnet is a symetric communication on port 23 between a Telnet Client and Telnet Server. Quality of service is reliable, rate controlled and fully-duplexed protocol. IDS Behavior consists of burst activity during the session initiation, and only occasionally thereafter.
One of the first "user friendly" telnet application programs was a weather warning site. Things we take for granted now. Log into the application and your choices were wind, temperature, etc. Telnet is also usable through SMTP and HTTP. You can mail, you can "GET"... what else could you want in a tool?
Telnet is priceless to engineers troubleshooting routers and switches. It is also a hackers first choice in the pen-test of your network. Easy catch!
The old cyber doomsday scenario serves to entertain but remind us, even as we laugh, that there is no such thing as a 100% secure computer. What are your telnet settings?
Tell us an oldy but goody about your experience with this wonderful protocol. We'll will post the most entertaining with the group as they come in.
Come on ......Jeramiah was a bullfrog!.... WoooooHooooo!
Handler on Duty
Lode sent in some unusual traffic he is seeing from one of his servers. The traffic is Protocol 0 (IPv6 Hop by Hop), originates from a Loopback address and is destined to 18.104.22.168, which used to be IANA reserved but recently was allocated to ARIN, but is currently not in use.
13:02:52.012656 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.181 > 22.214.171.124: ip 0
13:02:52.012699 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.25 > 126.96.36.199: ip 0
13:02:52.012743 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.96 > 188.8.131.52: ip 0
13:02:52.012788 IP (tos 0x7,CE, ttl 255, id 29423, offset 0, flags [none], proto: Options (0), length: 20) 127.0.0.187 > 184.108.40.206: ip 0
Some searching shows references to this traffic from Solaris (this server is Debian Linux) systems dating back to at least 2002, but I couldn't find any concrete solutions. One reference suggests this traffic might be related to a misconfigured rootkit.
Anybody who knows anything about this traffic and can provide insight please contact me via our contact page.
-- Rick Wanner - rwanner at isc dot sans dot org
A couple of readers have indicated that this evening when they started Firefox it disabled the Microsoft plug-ins Windows Presentation Foundation and Microsoft .NET Framework Assistant 1.1. These plug-ins have been the source of some controversy since it was revealed earlier this week that Microsoft had patched them as part of patch Tuesday.
While the people over at Mozilla have recommended disabling these plug-ins, their is no indication over at the Mozilla Blogs of why this action was taken.
Anybody have any details of what is going on?
-- Rick Wanner - rwanner at isc dot sans dot org
Welcome to CSAM Day 17! Today is brought to you by Secure Shell (SSH) commonly deployed on port 22/TCP.
SSH has become ubiquitous as a mechanism for command line access to *nix systems, and is sometimes deployed on Windows systems as well. As the Dshield graph for port 22 shows, it is a popular target for attackers. These attacks usually take the form of attempts to brute force root accounts and other accounts with weak passwords.
My primary method of protecting SSH servers is threefold:
- Deploy the SSH server on a port other than 22/TCP. It appears that the SSH probes on the Internet at this time are focusing their interest on the standard SSH port. My personal server is deployed on a non-standard port and I have not had any attempts to login in over two years.
- Deploy one of the SSH brute force prevention tools like DenyHosts, fail2ban, blockhosts, etc. On one of the servers I run where I have to deploy on the standard SSH port DenyHosts has blocked 65 IPs which have attempted brute force attacks in the last month.
- Disallow remote root logins. Most SSH servers provide a mechanism to disallow the ability to login to a root account using SSH. In OpenSSH this is done by setting PermitRootLogin to "no" in the /etc/ssh/sshd_config file. This forces users to login using a user account and escalate privilege using su or sudo to become root.
What strategies do you use to secure SSH?
Do you have any strategies for protecting SSH servers deployed on Windows?
Please submit your suggestions through our contact form or via the diary comment system. I will summarize throughout the day.
Faisal pointed out that I was remiss in not mentioning SSH keys. If you use keys for authentication and disable password authentication via SSH then SSH brute force attacks cannot succeed. In OpenSSH password authentication can be turned off by setting PasswordAuthentication to "no".
Joanne points out that there are alternatives to using brute force prevention tools. In her case she uses the iptables firewall to only permit one SSH connection, successful or not, every three minutes. Joanne also points out that if you must use passwords at least make sure the users use good ones.
Ned maintains a securing SSH page over at the CentOS wiki. It describes in detail how to implement some of the ideas presented here and more.
Sven sent a number of strategies. First he suggested using AllowGroups to limit access to a group of people. He also recommended that if users only require file transfer capability alternative shells like scponly can be utilized. He also points to ChrootDirectory which can be used as a chroot jail for SSH.
Gerard is a fan of sshdfilter. It is another of the anti-brute forcing tools, but it is an ssh wrapper and doesn't use tcpwrappers for blocking but rather creates iptables or ipfw rules to facilitate the blocking.
-- Rick Wanner - rwanner at isc dot sans dot org
The .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox. That in of itself may be cause for concern. But wait, there is more. MS09-054 was issued to address an IE vulnerability (CVE-2009-2529). As it turns out the vulnerability could also be exploited via Firefox. If you could launch XBAP using a browser the vulnerability could be exploited. For users of either browser it is recommended to disable XBAP. So essentially a security fix introduced additional issues? The irony is, well...
More information from Microsoft is available here.
So, if you use Windows, install patches, and also have Firefox, oddly enough you will want to read the following Microsoft KB article entitled "How to remove the .NET Framework Assistant for Firefox"
The title pretty much says it all. Please check out the Cisco advisory here.
Adrien de Beaupré
By default when you install Oracle the TNS Listener is on tcp port 1521. It handles network requests to be passed to a database instance. If it not appropriately secured commands can be sent to the listener, the listener can be shut down, or the databases can be queried. There have been a number of vulnerabilities over the years that have been actively exploited specific to the TNS Listener.
If you check the Dshield database for the last while port 1521 has appeared in the 'top 10' a number of times. It would appear as though if you install Oracle it is highly recommended not to expose it to the Internet (or any untrusted network). Obviously a number of people are actively looking for Oracle instances. http://www.dshield.org/port.html?port=1521
Some best practices for the TNS listener:
- Restrict access to this port
- Assign a password to the listener
- Install patches
Some examples of CVE entries that involve the TNS Listener:
CVE-2008-2625, CVE-2007-5507, CVE-2007-2120, CVE-2006-0265, CVE-2005-3206, CVE-2005-3207, CVE-2004-1369, CVE-2003-1116, CVE-2002-1118, CVE-2002-0965, CVE-2002-0509, CVE-2002-0567, CVE-2001-0498, CVE-2001-0499, CVE-1999-0784, CVE-2000-0986
Some recommended reading: the Oracle Database Listener Security Guide http://www.scribd.com/doc/22455/Oracle-Database-Listener-Security-Guide
Please contact us if you have any comments or would like to add to this diary entry.
A duo announcements by VMWare highlight a new patch, and an updated one fixing their enterprise offering, ESX which addressed 51 CVE's worth of issues.
The majority of those however are within the Java Runtime (JRE) bundled with the product.
You can find more out on their list server where the following updates are released:
Steve Hall | ISC Handler
Email has become a mainstay for both businesses and individuals. It seems a day does not go by that we are online checking for that ever important message from someone important to us. In the business world email is now our most important and timely form of communications. Information is passed from boss to employee – employee to boss –
owner/manager to employee groups and employee to employee. Email is a way we can make sure that our message is heard and acted upon. I for one could not function even a day without my email.
Email security is the process of using encryption to send messages that can only be opened and read by the intended recipient. Sending an email without encryption is much like sending a postcard through the Postal Service, it can be read by everyone who handles it on his way through the system from the sender to the receiver.
Most of the email sent today is sent using standard SMTP without using encryption or authentication. This email is sent on port 25 in clear text format and is exposed to view. This means that there is a danger that the email can be intercepted and read by anyone, anywhere. Now for most of the email that I send and receive this is not really a problem. I really don’t care if anyone has my super Chocolate Chip Cookie recipe or my Super Hot Chili recipe. I am however involved in some organizations that provide FOUO (For Official Use Only) information. For this information I need to protect the data from prying eyes. So how do I do that?
There are some really great client side utilities such as Secure MIME (S/MIME) or Pretty Good Privacy (PGP). These programs however require user involvement. The user has to know when and how to use the program and the recipient has to have the “Key” to unlock the encryption. This could be a problem for some of the users that can barely use their email.
A perhaps better place to focus your security efforts is securing your SMTP traffic. There are a lot of good articles about securing SMTP traffic and the basics are the same whether you are using Linux mail programs or Microsoft Exchange or Novell Groupwise. However, each of them has their own little caveats.
With the sending of secure email comes the receiving of secure email as well. One method used to accomplish this is Secure POP3 (POP3S) and Secure SMTP (SMTPS). Again there are probably as many ways to accomplish this as there are people using it. I am going to look at one way and some of our readers may have some suggestions for others.
POP3S over SSL is one method utilized. Let me preface this discussion with the fact that there are some known vulnerabilities with OPEN SSL so please make sure that you apply patches or fixes as recommended by your OS manufacturer http://openssl.org/news/vulnerabilities.html. With that said, one of the methods that we have utilized is using POP3 over SSL. This a free, open source implementation of Secure Socket Layers (SSL) the same encryption layer that is used for standard, secure Internet based secure e-commerce transactions. This method uses port 995 for POP3-over-SSL and port 465 for SMTP-over-SSL and for those using IMAP it uses port 993 for IMAP-over-SSL communication.
One of the key things that we did is use stunnel to create a secure channel for all of the POP3 data to be exchanged. This stunnel requires a piece of data called a Certificate be generated. This certificate is then used to validate and exchange information from device to device. These certificates can be purchased from providers such as GoDaddy or Thawte
or they can be self generated. Once the certificates are in place the email passed through the ports are encrypted and validated end to end using the key.
This is a very brief explanation of what Ports 995, 465 and 993 are used for. These three ports can take you from a postcard environment to a secured envelope environment with just a bit of effort.
Deb Hale Long Lines, LLC
Reports are coming in today regarding another round of spam attempting to spread malicious programs on machines all over the world.
I just checked my Postini and I too am seeing these emails. Here is the content of the new round:
- Please re-configure your Microsoft Outlook Again.
- Download attached setup file and install.
These emails contain an attachment. The ones in my Postini filter contain an attachment with the name install.zip. (This doesn't mean that is the only
name that is being used. )
According to the headers these emails are coming from IP addresses all over the world and are using various mailservers including servers from well
known services like Yahoo and GMail as well as private mail servers at private companies.
In addition to the Outlook spam we are seeing a new influx of IRS spam with an attachment tax-statement.exe, and of course the DHL Service spam.
Yesterday my company got hit with a round of the emails with OWA links. We don't use Exchange for our external email so the link was "broken". We
received a number of phone calls and emails from customers telling us they clicked on the link and it didn't work and asking what they should do now.
Luckily the link was "broke" or we would have had a pretty nasty mess on our hands today. The interesting thing about this was the email was sent to
one email account with "Dear another email account" and the users still clicked on the link. May wonders never cease.
I find this unusual increase in virus spam emails rather ironic beings this is Security Awareness month. Might be a good time to remind your
users about the dangers of clicking on links or attachments that they get in emails. Make sure that they understand what the procedure is for reporting
these emails to your company or your security department.
Deb Hale Long Lines, LLC
Aaron let us know about a discussion thread on the NANOG mailing list about issues with the blackholes.us DNS block list (DNSBL):
The issue is the maintainer of the blackholes.us DNSBL shut the list down some time back and the IP address space that the DNS servers for it were on was given back to ARIN. That address space has since been re-allocated to a new company and they are getting tired of the continual inbound DNS queries to the IP address of the old server. Apparently they have now stood up a DNS server to answer those queries with a wildcard record that effectively returns "yes, the IP you are inquiring about is a spammer". As a result, lots of mail relays that are still configured to do lookups against this DNSBL are now being told that everyone on the Internet is a spam source.
According to this post in the news.admin.net-abuse.email Usenet newsgroup, the DNSBL was shutdown 2 years ago.
If you are an email administrator, please check your RBLs to see if you are still submitting queries to blackholes.us and remove it from your configurations if you are. You should also review any other RBLs you are using to ensure that they are still in operation as well.
We've received numerous emails about this already today. This is an update to a diary we did earlier this week.
The body of the spam today is:
Dear user of the <some company> mailing service! We are informing you that because of the security upgrade of the mailing service your mailbox (<user>@<some company>) settings were changed. In order to apply the new set of settings click on the following link: The email contains a link with a file to download. Some of the files we have seen are: settings-file.exe MD5: 0244586f873a83d89caa54db00853205 settings-file2.exe MD5: e6436811c99289846b0532812ac49986 The files are being detected by some anti-virus software programs at this time as Zbot variants. Thanks Jon, Frank, iTinker, Nick and others for your reports on this.
This diary is a bit unusual in that the problem here is very close to home, the ISC/DShield website. But I figure among all of our readers, there may be one who can help. I have seen others describing the same issue, but so far I haven't found a solution.
Users who download our log submission client using Internet Explorer frequently receive truncated files. Firefox appears to download them fine. In either case, the server logs a "200" status and the file size in our Apache access log is correct (about 2.2 MBytes). However, the users only receives 200-300kBytes. A packet capture confirms that only 200-300kBytes got transfered. As MSIE starts the download, it does display the correct file size (and the content-length header is correct)
Some of the issues we excluded:
mod_security, firewall, IPS
Also note that the downloads work fine with Firefox, so the server is perfectly capable of sending the file. Any help is appreciated.
Link to the file: http://isc.sans.org/clients/cvtwin-setup.exe
Here is a packet dump of the end of the connection:
IP client.54436 > server.80: Flags [.], ack 193105, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460 IP client.54436 > server.80: Flags [.], ack 196025, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460 IP server.80 > client.54436: Flags [FP.], seq 215005:216465, ack 646, win 1783, length 1460 IP client.54436 > server.80: Flags [.], ack 198945, win 32120, length 0 IP client.54436 > server.80: Flags [.], ack 200405, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 203325, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 207705, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 210625, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 212085, win 32120, length 0 IP client.54436 > server.80: Flags [.], ack 213545, win 32850, length 0 IP client.54436 > server.80: Flags [.], ack 216466, win 32120, length 0 IP client.54436 > server.80: Flags [F.], seq 646, ack 216466, win 32850, length 0 IP server.80 > client.54436: Flags [.], ack 647, win 1783, length 0
Often times, if hackers or worms break into your computer, they will try to delete the logs on the local computer to help hide their tracks. Having all your computers submit their local logs to a central log server will help you maintain copies of those logs. Even if a bad guy isn't trying to delete your logs, its also a good way to aggregate log data and to review it centrally using tools such as Swatch, Logsurfer or SEC to see if there are unusual events occurring on your systems. These three tools all allow you to build a set of rules to help filter the log traffic. Messages that are 'normal' noise can be ignored and messages that are indicative of unusual activity can generate an alert to notify your admins to review the activities.
There are 3 main syslog packages at this time:
1) syslog - the original syslog program. This only supports sending messages to the central log server over UDP. As such, you have no guarantees that the messages will get to the central server. Because it is UDP based, it is important that you use a firewall to block inbound UDP syslog traffic from the Internet. This is so malicious users can not send in a flood of syslog entries that result in filling up the filesystem on your central syslog server.
2) syslog-ng - in the spirit of Star Trek, this is 'syslog - the next generation'. syslog-ng includes support to submit logs to a central server using TCP, so it can compensate for packets that got lost due to network issues or slow down sending if there is network congestion. syslog-ng also can use supplemental tools, such as stunnel to encrypt the log traffic between the source and the central log server using SSL.
3) rsyslog - this is the latest syslog replacement. It can use TCP as well for more reliable communication. It now has native encryption support built-in, eliminating the need to use a second tool like stunnel to secure the network communication. It can also use MySQL as a storage backend rather than flat text files. This is useful for tools such as phplogcon which can be used to visualize the log data.
For environments with Windows systems, there are add-ons you can install to allow you to submit your various Windows event logs to a syslog server as well. Some examples of these products are winlogd, SNARE, and a Perl module Win32::Syslog.
It ain't just Microsoft ... while MS issued a deluge of patches today, Adobe pushes just one, but theirs addresses no less than 29!! gaping holes in one single update. As we reported earlier, at least one of these 29 vulnerabilities is already being actively exploited. So if you are using Acrobat or Adobe Reader, no matter whether on Unix Windows or Mac, you definitely should take a close look at http://www.adobe.com/support/security/bulletins/apsb09-15.html and start rolling the update. If we were in the habit of rating Adobe patches like Microsoft's, this one would be a "Critical"
Overview of the October 2009 Microsoft patches and their status.
|#||Affected||Contra Indications||Known Exploits||Microsoft rating||ISC rating(*)|
|MS09-050||Vulnerabilities in SMBv2 Could Allow Remote Code Execution (Vista and Windows Server 2008 SP2 only)|
first mentioned in
| CVE-2009-3103 is
see our diary here.
|MS09-051||Vulnerabilities in Windows Media Runtime Could Allow Remote Code Execution|
|Windows Media Runtime
|KB 975682||CVE-2009-0555 known
|MS09-052||Vulnerability in Windows Media Player Could Allow Remote Code Execution
|Windows Media Format
|KB 974112||No known exploits.||Severity:Critical
|MS09-053||Vulnerabilities in FTP Service for Internet Information Services Could Allow Remote Code Execution|
|IIS FTP Service
|KB 975254||Exploits Known for both
|MS09-054||Cumulative Security Update for Internet Explorer
|KB 974455||Exploits known for
|MS09-055||Cumulative Secuirty Update of ActiveX Kill Bits
|KB 973525||No known exploits.||Severity:Critical
|MS09-056||Vulnerabiliites in Windows CryptoAPI Could Allow Spoofing
|KB 974571||publically known
|MS09-057||Vulnerability in Indexing Service could allow remote code execution if user browses to a malicious page.
|KB 969059||No known exploits.||Severity:Important
|MS09-058||Vulnerability in Windows Kernel could allow privilege escalation.
Replaces MS06-022 and MS08-064
|KB 971486||No known exploits.||Severity:Important
|MS09-059||Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service|
|KB 975467||No known exploits.||Severity:Important
Vulnerabilities in Microsoft Active Template Library (ATL) ActiveX Controls for Office Remote Code Execution
|KB 973965||No known exploits.||Severity:Critical
Vulnerabiliites in the Microsoft .NET Common Language Runtime Could Allow Remote Code Execution
|MS09-062||Multiple vulnerabilities allow arbitrary code execution. This affect windows, Office (including the viewer), SQLserver and various developer tools. Also affects Forefront Client Security on Windows 2000 SP 4.
|KB 957488||No publicly known exploits.||Severity:Critical
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them
Proxy servers are used to manage access to the Internet in companies. It is a tool to check, control, report and otherwise manage staff access to the Internet and is an important tool to enforce policies. There are numerous products on the market, the more well known ones are of course Squid and Microsoft's ISA. They are typically deployed either in the Internal network or in the DMZ or in both zones. The ports used are typically 3128, 8080 and 80, however like any TCP application any port can be used.
Proxies do have their evil twins, Open Proxies. Have you ever had that sinking feeling when looking at firewall rules or web usage and you have noticed that your firewall rule allows the Internet to access your proxy server. Your monthly usage has increased hundred fold, or of the 500 people in your organisation 9,876 of them are currently using your proxy server?
Open proxies, unless deliberately deployed are typically mis-configured firewalls, proxy servers or web servers, but can also be the result of a compromise or malware. It is a convenient avenue to browse anonymously and can be used to propagate things such as undesirable content. Ports 3128 and 8080 are one of the most scanned ports. As many of you will know there are sites that will happily publish the IP address and ports of open proxies.
In many countries the use of an open proxy may be considered illegal as you are using someone else's computer, often without their knowledge. The company/person whose computer is being used as an open proxy may in some jurisdictions also be in breach of some laws, especially if it is being used to propagate child porn or is being used in other criminal activity (Am not a lawyer, so get legal advice if you use open proxies or find one in your network and need to know for sure).
If not patching today, maybe make today your "check for open proxies in my network day".
A few people have mentioned (Thanks Luke, Anon, et all) that they have started receiving SPAM messages along the following lines:
On October 16, 2009 server upgrade will take place. Due to this the system may be offline for approximately half an hour.
The changes will concern security, reliability and performance of mail service and the system as a whole.
For compatibility of your browsers and mail clients with upgraded server software you should run SSl certificates update procedure.
This procedure is quite simple. All you have to do is just to click the link provided, to save the patch file and then to run it from your computer location. That's all.
Thank you in advance for your attention to this matter and sorry for possible inconveniences.
Not sure what the evil is, as the links I received have been dead, so if you do receive one of these messages please let us know. If you follow the link, be prepared for surprises and do it on a system that you do not care about (and that does not mean the computer belonging to the annoying fellow/gal sitting two desk away.)
One of the reasons I like this is that the reason to many people it would seem quite plausible, especially if they are running an internal CA at the site. They may have received messages like this from their own support desk. So in a targeted attack this could work quite nicely. The English isn't bad either.
the sample file we received was named patch.exe MD5=9abc553703f4e4fedb3ed975502a2c7a
ZBOT characteristics, so trojan, keylogger, disables AV.
If you have a sample with a different hash please upload it through the contact form.
In the samples received the URL used in the message typically has a component relating to the organisation itself. e.g. http://something.<yourcompanydomain>.thehostingdomain/somefile.aspx Embedding the company domain will make it look a little bit more legit to the user.
In many enterprises, spam prevention and abuse handling is a function of IT Security and less of a business duty for the email system administrators. With that in mind, I wanted to point out something on the operational security front.
Earlier today, McAfee released their October 2009 Spam Report. This report discusses a number of things including the continued increase in pharmaceutical spam, brand abuses, and just the overall sophistication of the spam messages we are receiving today. Throw in all of the phishing scam messages which have been on the increase for the past 3 years, and we can see why the younger generation has all but abandoned email as a communication resource in lieu of more closed systems such as Facebook or twitter. Those of us in higher education has been attempting to cope with this change in communication to varying degrees and expect the corporate world to have to adjust within a few years as well.
So..... thought I would point out something that may be useful for situational awareness purposes, or to at least explain to the C-level people why the spam filters missed a number of spam messages recently.
Scott Fendley ISC Handler
SNMP has to be one of my favourite protocols when doing internal pentesting. Mainly because I know that there will be a bunch of devices that are configured to use it, in fact almost everything connected to the network that isn't a workstation is likely to have SNMP open. Secondly because the "password" or more correctly the community string is likely to be "public". If it isn't then it is often trivial to find. Once you have the community string, then it is a just a matter of asking the devices nicely to give up their configuration details and you quickly have a good picture of what the network looks like. If you are lucky you can reconfigure the devices as well.
SNMP is used to monitor network connected devices. It consists of a manager and a number of agents. The manager at regular intervals polls the agents on port UDP/161 and queries the Management Information Bases (MIB) for the device. The MIB is effectively a hierarchical database structure for information on the device, e.g. serial numbers are in a specific location, nic statistics, etc.
SNMP-TRAP allows the agent to send information about itself to the manager on port UDP/162. TCP can be used for both 161/162, but UDP tends to be more common.
Typically the agents are configured in read-only or read-write mode. The difference between the two is determined by the community string used.
There are several versions of SNMP V1, V2c and V3. V3 introduces encryption, message integrity and better authentication than can be provided by the community string.
There are a few challenges when using SNMP.
- With the exception of V3, information is exchanged in clear and can be sniffed.
- All versions are susceptible to password guessing attacks.
- Whilst V3 is the right version to use, many devices are only capable of using V2c or even V1 so you have to live with the insecurity
- When UDP is used, packets can be spoofed (what will the effect be on your SNMP-TRAP server when it receives thousands of TRAPs per second?)
There have been a few security advisories relating to SNMP over the years, it tends to be an internal issue. However if you accept SNMP queries from the internet you may be leaking more information than you thought. In fact in a previous life we used "public" IP addresses on an internal network segment. When mapping the internal network using SNMP, using one of the monitoring tools and due to a configuration challenge (yes we let SNMP out of the network), the SNMP requests didn't end up on the internal network, but on the Internet. The following Monday morning we had a great network map of a network somewhere in Europe. I'd like to think people have learnt since then, but ....
For more information have a look at the wikipedia entry which is quite good or you can always read the many RFC associated with SNMP (1155, 1156, 1157, 1441, 1213, 3410-18, 3584 & 3826).
Mark - Shearwater
As most of our regular readers are aware, this is Cyber Security Awareness Month and the ISC handlers are writing diary entries about securing various ports and services. For the die hard security professionals, this month is nothing more than a review of things you have learned over the past 10-20 years. For those new to information security, it is our hope that you learn more about the various ports and services which are commonly used on networks. As the old adage states, those who do not learn from the past are doomed to repeat it. It is my hope that you as our reader will learn from the mistakes of our collective past so that as an industry we don't have to repeat things (as often at least).
To that end, let me share a bit of a story (and personal history).
In my life prior to becoming an InfoSec professional, I was a student worker who functioned as Unix systems administrator over a small lab of Solaris workstations. As the case with many of student workers, our work space was usually some closet, or cubical where they could stash us which had 3 things, a 10bT ethernet jack, a phone line run to it, and power. My supervisor was located in a building halfway across campus (a good 10 minute walk) and my nearest student co-worker was at least 2 or 3 buildings away. One of the most frustrating mysteries of my job was that my supervisor seemed to be psychic. No sooner than I sat down at my little workstation, he would call me with a list of things I needed to do. If I was running late from class, or left my office early, he seemed to have an uncanny awareness of that fact and I would hear about it rather quickly.
As a part of this desktop Unix support team, one of the first tasks was to install our very own workstation from the ground up (with some documented guidance others had developed). I got to have the full administrator experience of setting up accounts, and monitoring the activity of those accounts, compiling and installing new software, updating the computer, and just about everything else you could imagine. The only thing I had to do is provide the root password to my supervisor usually in a sealed envelope that he would stash in one of many books sitting on his bookshelves.
Even in these early days of my career, I had already begun that paranoid security mindset that I believe our field really requires. At the time I could tell you every application I had installed, what services I had running from the /etc/inetd.conf, and which of my users had logged in recently and what they had done. I turned on all of the logging features of which I was aware, and reviewed these audit logs routinely. So the peculiar thing is that my supervisor never needed to telnet (these were the old days before SSH was prevalent) into my workstation to check up on me. The question that haunted me for so long was how he could detect that I was in my office without any of the modern avenues available today (such as a central authentication system, door logs, hallway cameras and similar).
At some point, he revealed to me how he seemed so psychic to all of us student workers: PerfMeter. Perfmeter is a tool which uses the Unix RPC (remote procedure call) services that ran on Solaris machines which would provide a number of statistics about the system including CPU usage. At the time, the default screen savers under Solaris X windows would either be very heavy on CPU cycles, or didn't use much of anything in comparison to when you were on the workstation. And as Perfmeter could communicate with a remote system without the need of authenticating (!!!) and left no audit log entries (!!!) of this activity occurring, my supervisor just had to configure a graph for each of the student workers computers and know if we were at work or not. And as a consequence of the lack of any true security perimeter, any attacker in the world could potentially use this or other RPC based applications to gather intelligence on system administrators and the systems they maintained with little to know hurdles to speak of.
PerfMeter is only one of many thousands of applications/services which communicate via RPC calls which initially use TCP or UDP port 111. RPC is/was a very powerful technique for constructing distributed, client-server applications and is based on the notion that a called procedure need not exist in the same resource space as the calling procedure or application. By using RPC, the programmer of these distributed applications could avoid the details of the interface with the network (and consequently avoid making as many programming mistakes in the networking code which was so prevalent at the time).
In many cases when a client makes an RPC call for a given program, it will first connect to the rpcbind or portmapper service (tcp/udp 111) on the destination system to determine the ultimate port where the request should be sent. The active port 111 will have a list of all active services, and tell the requesting client were to connect. However, infosec professionals should know that under some versions of Unix rpcbind not only listens on the TCP/UDP port 111, but it also listens on UDP ports greater than 32770. The exact port number is dependent on the OS release and architecture. Thus, packet filtering devices, router ACL blocks, and firewalls that are configured to block access to rpcbind/portmapper at only port 111, may be subverted by sending UDP requests to rpcbind listening above port 32770. This vulnerability may allow an unauthorized user to obtain remote RPC information from a remote system even if port 111 is being blocked.
To finish a part of the story, I eventually found that Wietse Venema (author of SATAN, TCP wrappers, and other security tools) had developed a replacement to the native rpcbind/portmapper program that would correct two of the main issues I had with it at the time: access controls and logging. With this tool, I was able to at least attempt to thwart the attacker (my supervisor) until told otherwise, and limit the amount of data my workstation was allowing out.
While Unix based RPC doesn't seem to be as prevalent today, I do expect that this construct can and will be used in the future in new and different ways. We all have seen or heard of stories where there is an intrusion which involves some legacy application which was not properly secured. Chances are some of you may have one of those applications running on the interior of your network.
Here are some recommendations I have for securing these applications. If you have other suggestions, please share via our contact form.
1) Inventory your servers to see if any of them are listening for TCP or UDP port 111 using a tool like nmap. Also, check for high UDP ports such greater than 32770. Alternatively, get the server admins provide the output from lsof for UDP and TCP ports which are listening.
2) For each of these servers, enable the host based logging which may be available.
3) Verify that this log data should be flowing to your centralized log server or Security Event Management system.
4) Configure the host based access control to limit what computers or networks can do RPC calls (and don't forget that localhost may need to be allowed for some intra system communications). Most modern Unix/Linux based systems have incorporated Venema's tcp wrapper access control framework which makes this reasonably easy today.
5) As a defense in depth measure, make sure that your router ACLs or Firewall rules limit your exposure from outside of your organization to the portmapper service port.
6) If a server has no need for the service such as NFS, NIS/NIS+ or legacy applications which uses RPCbind, then shut off the service.
7) Solaris 10 systems can enable the host based TCP Wrapper support by running the following command:
# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
# svcadm refresh rpc/bind
So readers, what other recommendations do you have in securing the RPC protocol?
Scott Fendley, ISC Handler on Duty
The Internet Storm Center is focusing on IP ports for the month of October. I am going to continue the theme, but with a bit of a twist. I am going to talk about a few of the ports that are usually not desirable to appear in a traffic analysis. There are many more than I could list, the majority associated with malware. But not all of them. Here we go:
1214 - Limewire/Kazaa (A Peer-to-Peer application. Not by definition malware, but not something desirable in an enterprise)
2773 - SubSeven (Trojan)
5631 - pcAnywhere (A commercial remote control application)
1863 - Numerous Microsoft applications
I want to emphasize that these listed are not necessarily bad. The point here is awareness. Knowledge, and management, of the ports required and permitted in the enterprise, and at home, will lead to an overall improvement of the security posture of a network. This is where syslogs, traffic analysis, and documentation will tie everything together.
I welcome any and all thoughts, comments, questions, queries, concerns, etc. I will post updates to this story as comments come in to the ISC.
tony d0t carothers @ isc d0t sans d0t org
One of our readers, Roy, came across this article from Yahoo! this morning reporting that Comcast is planning to enlist it's customers help in the fight against botnets by using pop-up alerts. Comcast's general idea is that, if Comcast notes traffic associated with known botnet activity, a pop-up will appear on the user's computer. The article gives the full details as reported by the Assosciated Press.
The last paragraph, from an overall security perspective, is the most concerning to me, and that is the use of hoax popups and sites. I quote "Phil Lin, marketing director at network security firm FireEye Inc., said hackers could mimic Comcast's pop-up banner or the confirmation ads. And unsuspecting customers wouldn't know they should expect to see a confirmation from Comcast in the first place." We know it is only a matter of time, and my guess is it will be a very short time, before the botnet farmers start making use of hoax notification pop-ups and sites.
The bottom line: Good security practices up front, solid software and applications, and user awareness would almost eliminate the need for any effort of this type.
Alan tells us that several AT&T cell subscribers have just received a text message, which instructs them to call a toll-free number XXX-XXX-7649 to resolve a problem with their account. When called, a voice menu harvests their credit card information.
An interesting delivery mechanism for an old-hat phish, which we're all used to seeing in our email inboxes - now bright-shiny-new as a text message - nice find Allan!
Johannes tested this with the 4111 1111 1111 test card number, which the phish menu verified correctly. Subsequent tests indicate that a random 16 digit number is initially accepted by the voice menu, but fails verification at the end of the input process. This indicates that the menu is actually verifying and processing the CC numbers correctly, and is most likely processing (evil) transactions in close to real-time.
Always interesting to keep tabs on what evil lurks out there !
Arno writes in to tell us that Thawte will be discontinuing their free E-mail Certificates and email cert "web of trust" service, as of Nov 16, 2009. They are offering a free one-time migration to a 1 year Versign certificate services subscription (which is is a chargeable thing after your first year runs out).
Information on the discontinuation and the migration can be found here ==> https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=AD196&actp=LIST&viewlocale=en_US
and here ==> https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO12704
Feel free to comment on this diary entry - we’re interested in issues or resolutions you may have had involving the RDP protocol, Terminal Services client and server applications, as well as any questions you may have regarding this diary entry. You can use the comment button at the bottom of this article.
Microsoft's RDP (Remote Desktop Protocol) and it's associated "terminal service" client and server apps have been widely used since Windows 2000 days for Windows server administration. RDP gives delivers the server's complete remote desktop to a client. RDP has been improved over time, and is now pretty much the de facto standard for remote administration in most datacenters.
In more recent times, VDI (Virtual Desktop Interface) implementations often use RDP to deliver the desktop from a VM to thin clients or PC's, in an effort to centralize control and minimize administration requirements for client desktops. This has resulted in more widespread use, as well as improvements to the protocol especially around the delivery of graphics and performance in high-latency situations.
The perception has always been that RDP offers a secure delivery of information, as Microsoft publishes detailed information of it’s encryption settings. The default setting is now “high”, which means 128bit encryption (using RC4)
However, there’s a problem with RDP – by default the certificate used for encryption is signed by an RSA private key, which is then stored statically in the file mstlsapi.dll, which every Windows client and server has in it’s base install! This was originally discovered by Erik Forsberg in 2003 (http://www.securityfocus.com/archive/1/317244 ), and documented further at http://www.oxid.it/downloads/rdp-gbu.pdf (amongst other places).
This means that in a default installation, a Man-in-the-Middle (MITM) attack can intercept the exchange of RDP encryption information, substitute it’s own (correctly signed) SSL information to both the client and the server, and decrypt the entire session, all without the “encryption alert” message showing up at the client!
Even if that were not the case, the default installation for Terminal Services client on XP does not notify you if the server certificate does not "match". Check for yourself - open the terminal services client, choose the "Advanced" tab, then check the "verification policy" value - youi'll see that it's set to "Connect and don't warn me"
What does this mean to me?
What this means is that if the default Windows installation is taken, and no further protections around encryption are implemented, that RDP is easily compromised. This is normally done by capturing an RDP login exchange, usually using a Man-in-the-Middle attack, then decrypting the captured packets to arrive at the password. CAIN (www.oxid.it) does a great job at this task. Describing an attack in theory is great, but I find that people don’t often take it seriously until the SEE it work in their environment. For this reason, we’ve attached a short video of such an attack, with a brief description of how MITM attacks. This attack works even if you change the “Server Authentication Verification” discussed above.
When I discuss this with people, they often don’t realize just how large a security risk this is – until they see it for real that is. This video shows just how easy it is==> http://isc.sans.org/diaryimages/rdp-mitm-mpg.html .
There's a brief explanation of how Man in the Middle via ARP cache poisoning works, but the emphasis is on the RDP stuff, and on how to use CAIN to get the goods – in an internal security assessment for instance. Just be sure that if you try this at home, that your laptop has enough horsepower to “keep up”. If your laptop chokes during the attack, remember that you’ve poisoned the ARP cache of 2 or more hosts (your DC is one of them maybe), and the default ARP cache timer is 4 hours!
In a larger sense, what this should mean to us is that the default installation of most things (including Windows) is almost never the right choice for security. Products ship so that people can install them with limited training and be still successful. This is true of Windows, most Linux distributions, OSX, pretty much everything. After installing an operating system for business (or personal) use, it’s always a good thing to reference that vendor’s security best practices. Googling the vendor name plus “hardening guide” is often a good start. Other references that may be helpful are sites like the “SANS Top 20” ( http://www.sans.org/top20/ ) or the benchmarks at the Center for Internet Security ( http://www.cisecurity.org/ ).
How can I fix RDP in my Datacenter? Do i need to stop using RDP?
The good news is that the RDP protocol, as well as Microsoft’s Terminal Services client and server applications are very well constructed, and can be secured using industry-standard methods, methods that you are probably already using for your corporate website or wireless infrastructures. Microsoft has really good documentation on using a PKI (Public Key Infrastructure) to use trusted authorities to secure RDP using TLS (Transport Layer Security). You can find one such document (which references other docs) here ==> http://technet.microsoft.com/en-us/library/cc782610%28WS.10%29.aspx
Can I prevent Man in the Middle Attacks?
You can certainly make them more difficult by configuring you switches correctly – look for an isc diary on Layer 2 protections coming soon.
Adobe's PSIRT (Product Security Incident Response Team) published a new blog post today . The post reveals that a critical vulnerability, CVE-2009-3459, is now being exploited in the wild in targeted attacks. The vulnerability affects Adobe 9.1.3 on Windows, Unix and OS X. However, the exploits have been limited to Windows so far.
An update scheduled to be released on Oct 13th should fix the problem. Until then, Windows users are advised to enable DEP. Anti malware vendors have been informed by Adobe.
My personal favorite port is port 53, but well, it was already taken. So I am going to cover port 25, my least favorite port :)
Port 25 is used by mail servers to receive e-mail. E-mail in itself is of course a mixed blessing. Spam levels in the 90% range make it a less and less useful business tools. There is a lot of history involved here, and SMTP wasn't the first "E-Mail" protocol. Before SMTP became popular, protocols like UUCP (Unix-to-Unix-CoPy) were used to exchange email. SMTP in some ways extends these older protocols and inherited some of the properties.
For a full description of SMTP, start with RFC821 (http://www.faqs.org/rfcs/rfc821.html). But RFC821 is just the start. Later RFCs expand on it substantially and you will need to understand them to fully appreciate how today's e-mail servers work. Let me try to assemble a quick SMTP primer here.
First of all, the mail client will connect to the mail server, the mail server will identify itself with a line like:
220 mailserver.example.com ESMTP Postfix
The number in the beginning is the important part, the rest is mostly ignored. "220" means the service is ready to receive your spam. Next the client has to identify itself. There are two ways this may happen. The old way (RFC821) is to send a "HELO" message like:
However, modern clients will typically use "EHLO" instead of "HELO". EHLO is defined in RFC 1869. Sending an "EHLO" will signal to the server that your client understands the extensions defined in RFC 1869.
The servers response to a HELO or EHLO will be a "250" code (if there wasn't an error).
For an EHLO, additional '250' lines will be returned listing the capabilities of the server. At this point, we do have an established connection and are able to send our first e-mail. The e-mail itself consists of 3 parts:
- an envelope. This is typically not part of the e-mail, but indicated the From and To address to the mail server. The From and To address in the envelope can be different from the From and To address used in the header of the message
- a header. The header includes typically a Subject/From/To and other fields.
- a body. Delimited from the header by an empty line you will find the body of the message.
But well, you probably knew all of that. Lets talk about a few more interesting features:
STARTTLS: This scheme, if both sites support it, can be used to negotiate an SSL connection on the fly. RFC 2487 will tell you more about it. But here the details: The connection starts as outlined above. But after the initial EHLO/250 exchange, the client will send a STARTTLS command. This will lead to an SSL connection being established. The SSL certificate may be used for authentication purposes as well as encryption in this case.
Message Submission: RFC 2476 outlines a new method to submit messages which is widely implemented. The basic idea is to distinguish between message forwarding, and injection new messages ("message submission"). RFC 2476 suggests the use of TCP Port 587 to submit messages.
Non Delivery Receipts: This is a sore point in many mail server configurations. There are two ways to indicate that a message is not deliverable. As the server receives the envelope, it will check the "To" address, and reply with an error message before accepting the e-mail. This is preferred as it cuts down on network traffic and non-delivery receipts beind sent to the wrong people later. However, it requires that the mail server knows all the users that are deliverable. For a simple relay server, this can be hard to figure out at times.
lots more to tell you about SMTP, port 25 and why I don't like e-mail. But maybe that will be a later diary.
Our reader Mark send us a link to his firefox "Security Suite" https://addons.mozilla.org/en-US/firefox/collection/securitysuite .
Mozilla started offering the ability to setup these collections to make it easier to share sets of plugins like that. Our handler Swa got inspired by Mark's submission, and setup his own https://addons.mozilla.org/en-US/firefox/collection/isc
I think this is a great idea. And I am wondering what plugins our readers would recommend for a suite like this. I can see three different suites:
- Home user security suite
- Security professional suite
- Pentesting suite.
Let me know which tools you would add to either one of them, and I will publish the top 5 plugins in each category (and maybe even setup the corresponding suites)
IRC. Internet Relay Chat, commonly found on ports 6667,6668,6669, and 7000, but really, found on most any port.
My question is, is it evil? Now, I've worked at some places in the past where IRC was generally forbidden, viewing that it was pretty much an evil thing, only "hackers" used it, and was a bad place to download "warez". (Yes, these words are put in quotes because they were actual words spoken to me, when I asked the question "Uh, Why?")
IRC is a very well documented (RFC here) "chat" protocol allowing for any of hundreds upon hundreds of pieces of client software to interact with IRC servers (or networks of servers such as freenode, efnet, or dalnet) in order to enter "rooms" or "channels" in order to talk with other members of the channel or room. Most of you know this.
However, there became another use for them several years ago, one of a Command and Control or "C&C" type of technology, where malware that was placed (or downloaded and ran) on a machine on your local network connecting outbound, "beaconing" back to the C&C server (generally just an IRC channel with a password) so that the Master of the malware could control the other computers.
This became known as a botnet. You may have heard of them.
(Now, I am sure the term "botnet" was used long before IRC was being used as a C&C, but you get my point, in fact, I know it was, but you get my point.)
Of course over the years, botnets have become more sophisticated, by using things like SSL and http instead of IRC, but there are still a lot of botnets out there that use IRC for C&C.
Where I used to work, and also in my present job (Sourcefire, makers of Snort) we used to find these botnets by using the IRC rules that are found in the chat.rules file. The rules that are in the chat.rules files are bound to the standard IRC ports, however, and as I previously stated, IRC, especially C&C "covert" channels of IRC traffic, goes out over any port.
I've seen C&C on port 80, port 53, you name it, 23, 21.. you get the point. So the easiest way I found to track these IRC network connections is by removing the port restrictions on the IRC rules in the chat.rules file, and replacing the ports with an "any" statement. (Of course, I am referring to Snort syntax here.) Allowing the rules to trigger on IRC on any port.
Things to keep in mind about this very simple method of finding IRC on the network, if you allow IRC on your network, you are going to get tons and tons of alerts...
... however, if you do NOT allow IRC on your network, and you find it, you are either finding someone who is violating policy (generally something you'd want to do), or, something worse. Hopefully not one of these simplistic C&C "covert" channels, if you find these examples (usually easily identifiable by reviewing the Snort logs and NOT seeing a conversation, but seeing commands and passwords being issued), start noting the IPs that are in the alerts on your network, and start cleaning!
I generally don't feel that IRC is a bad thing, if used responsibly. If IRC is allowed on the network, then finding those botnets can be tricky (I would start by suppressing freenode, dalnet, etc servers in your threshold.conf file), and it might take more work, but the benefits of it will show themselves in the end.
Thanks to a reader (Thanks Bob), who wrote in this morning asking if we have seen an increase in spam lately, I can personally confirm that yes, I have seen more spam in my inbox lately.
Bob sent us a couple interesting graphics, the first being a graph of how much of a spam increase there has been recently:
Secondly another graph he sent in was an interesting correlation. It was how many viruses have been blocked by ClamD.
As I said, I've noticed a big increase in spam lately in my own personal email as well.
What about the rest of the readers? Have you guys experienced similiar?
DHCP is a very commonly used protocol for the automatic assignment of TCP/IP configuration options. DHCP is defined in RFC 2131. "The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) , adding the capability of automatic allocation of reusable network addresses and additional configuration options . DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants ." DHCP extensions for IPv6 is defined in RFC 3315.
Common values include:
- IP address
- Subnet mask
- Default gateway (router)
- DNS servers
- DNS domain name
- Lease time
- 802.1Q VLAN ID
- 802.1P L2 Priority
- TFTP Server IP address
DHCP is not without its issues, here are some of them:
- DHCP is a UDP based protocol and is easily spoofed
- DHCP lease exhaustion/starvation Denial of Service attacks
- Rogue DHCP server responding to clients, the sky is the limit with this attack
- Spoofed RELEASE packets Denial of Service attacks
- DISCOVER and REQUEST are broadcast, everyone hears them and anyone can respond
- No concept of authentication
- Unless Layer2 security is enforced rogue clients get a lease too
- Assigning rogue DNS server IPs to clients, allowing pharming attacks among others
- Vulnerabilities in the DHCP client, some allowing remote arbitrary code execution
- Vulnerabilities in the DHCP service, some allowing remote arbitrary code execution
Please contact us if you have any comments or would like to add to this diary entry.
A reader wrote in "PiXiE uses Wake-On-LAN to turn on machines after they power down, then feeds them a rootkit over BOOTP when they try to network boot (many systems automatically try network boot when woken-on-LAN." A presentation can be found here: PiXiE: A Self-Propagating Network Boot Virus for Windows
Adrien de Beaupré
Microsoft has confirmed that thousands of Windows Live accounts have been compromised with their passwords posted online. Mainstream media such as the BBC are also carrying the story. Some information is posted here.
UPDATE: Gmail and Yahoo are also affected by the compromise. Change all passwords on any of these popular webmail sites.
Some does and don'ts:
- Do change your passwords on a regular basis (every six months or so)
- Do use long complex pass-phrases rather than passwords where you can
- Do change all of your passwords if you notice something suspicious
- Do take identity theft seriously
- Do use up-to-date anti-virus and a firewall
- Do NOT click on links in emails, ever
- Do NOT use the same password at multiple sites
Backdoors and malware and trojans oh my!
Post 31337 (tcp or udp) is not an officially assigned port according to IANA. Most /etc/services files do not reference it. So why pick what seems to be an obscure port that does not have a protocol associated with it to discuss as part of Cyber Security Awareness Month? If you use a popular search engine 31337 tends to return references to 31337 being an alternate spelling for Eleet (or Elite), and possible infections of a backdoor trojan which listened by default on this port. Back Orifice is not exactly new, originally released in 1998, it's successors such as BO2K have been updated somewhat. Most anti-virus engines will classify Back Orifice as malware and attempt removal. Some IDS engines will still alarm on traffic going to or from once popular typical trojan ports.
One part of the discussion of port 31337 could be the futility of alarming on any particular tcp or udp port at all. In 1998 BO had the ability to change its default listening port to anything at all. Any service in fact can be made to listen on pretty much any port. Without looking at the payload of the traffic you have no idea what is happening, whether it is a firewall or an IDS triggering on a 'suspicious' packet.
Trojans have not gone away to be a footnote in the history of InfoSec, they have evolved.
Please contact us if you have any comments or would like to add to this diary entry.
Update1: Dan wrote in to remind me that port 31337 is also the default listen port for Ncat, the netcat replacement from the Nmap team. Thanks Dan!
Adrien de Beaupré
Samba released several updates to fix some security vulnerabilities. Anyone running Samba should take a look at each of the bulletin below and seriously consider upgrading which can be downloaded here.
Information disclosure by setuid mount.cifs - affecting all versions
Remote DoS against smbd on authenticated connections - affecting all versions
Misconfigured /etc/passwd file may share folders unexpectedly - affecting version > 3.0.11
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org
We are going to introduce a new feature this weekend: One liner "event notes". These notes are intended for cases in which we try to point out something briefly, which doesn't deserve or need a full diary. For example an outage, or a patch for some software.
Right now, the notifcations are not sent for these "one liners". In the future, I may add an option to send them.
Please use our comment form to report problems with these one liners. I am also interested in anybody who has issues using the OpenID login. Right now, I am aware with some providers having problems, but I need a few more samples. If you attempted to use an OpenID, but it failed, please let me know the Open ID you used and how it failed.
First proposed in April 1971, the File Transfer Protocol is one of the oldest protocols of the Internet. According to RFC 959, "The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently." The FTP protocol is somewhat complex and uses three methods to transfer files. The one thing to remember is the choice of connection method is initiated by the client and the server has the option to refuse to use it at which point the connection will fail.
Active FTP Method
In this method, the FTP client opens a dynamic port and the FTP server connects to the client (the server is the “active” participant) on a random port chosen by the client who waits for a connection from the FTP server. Since the client decides the method, it will send a “PORT” command containing the IP address and port where the server needs to connect.
When you examine a packet trace, you will notice the client sending the information to the server with the IP and Port like this (h1,h2,h3,h4,p1,p2) – where the client sends the server the IP address and the port. For example, the client sends IP and Port (192,168,1,102,4,2) indicating the client is listening on IP 192.168.1.102 using TCP port 1026 ((4 * 256) + 2)) after which the transfer will start using the new port.
Passive FTP Method
In this method, the FTP client connects to the server on a dynamic port chosen by the server. Again, since the client decides the method, it will send a “PASV” command to initiate the Passive transfer and the server respond with something like "227 Entering Passive Mode (192,168,60,11,192,52)"by sending a message containing the IP address and port (using the same syntax used in Active FTP).
Extended Passive Mode - IPv6 and NAT
With the release of RFC 2428 in September 1998, the Extended Passive Mode was added to IPv6 and NAT as another method for FTP transfer. In this mode, the FTP server operates exactly the same as passive mode. The only difference is that it only transmits the port number (not broken into high and low bytes) and the client is to assume it connects to the same IP address it was originally connected to.
The basic concepts of FTP transfer is where the client opens a control connection to the server on TCP port 21, and specifies a source port as the source to which the FTP server should respond (IP and Port information). The FTP server sends its response using port 21. At this point, the server and client negotiate the data transfer parameters. The FTP server opens a second connection for data on port 20 to the client. The client will then responds on the data port to complete the connection and data transfer begins.
This protocol is insecure for transferring files because everything is sent in the clear where user names, passwords, FTP commands and transferred files can be captured using a packet sniffer. An alternative is to use the Secure File Transfer Protocol (SFTP) to protect the information in transit.
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org
tcp/5900 is used by VNC, a platform independent desktop sharing and remote control application. VNC is hugely popular and also used for helpdesk/remote support in many large organizations.
Well, it is a *remote control* tool. There's probably a bad guy or two out there who likes to remote control your PC while you are in the middle of an e-banking session. And there's even more bad guys out there who are too incompetent to work with a command line, and prefer to have their hacked victims accessible over the GUI. Yes, VNC is being used by Trojans, Backdoors and Hackers alike. If you ever find VNC on your PC and it wasn't you who put it there: Worry. Worry more. Then, re-install your PC from scratch.
As the DShield graph for port 5900 shows, there is a lot of scanning going on for tcp/5900, which is the VNC standard port.
The scanning seems to have two main purposes:
(1) To find VNC servers that can be breached by a brute force password guessing attack
(2) To find VNC servers that are still vulnerable to one of the more serious holes (like CVE-2006-2369)
As a reader commented in one of our more recent diaries on the subject, the best defense is not to open VNC up to the world in general. Tunneling through SSH or IPSEC improves VNC security quite a bit. If you need to keep it exposed to the outside, use the latest version and pick a loooong password. It also doesn't hurt to move it to a port other than 5900. While this is mere security-by-obscurity, and won't help against a targeted attack, it DOES keep all the scanners away who are just trolling for a target of opportunity.
Note that VNC is also using 5901..5903, depending on how many screens there are, and also uses tcp/5800 to allow a clientless (Java in browser) connection to a VNC server. Last but not least, tcp/5500 is used to "shovel" a connection from a server to a viewer running in "listening mode". The latter mechanism is hugely popular among the bad guys, because there are still way too many firms who have a firewall with a "permit anything from the inside going out" rule. Once a bad guy manages to subvert (virus, hacking) a server on the inside, he still can't get to it with an inbound connection on tcp/5900, but he often can "shovel" a tcp/5500 inside-out back to his listening VNC viewer. Metasploit also has a couple of lovely payloads to chose from that facilitate this sort of thing.
All the ports mentioned above are the standard ports used by VNC out of the box. A VNC server is just as happy on Port 80 as it is on 5900 though, so while scans for tcp/5900 are usually indeed looking for VNC, you should have your IDS on the look-out for VNC traffic on ANY port. Emergingthreats has a couple of nice Snort rules for VNC traffic.
A number of readers in the last 20 minutes have been indicating that there has been an outage with Verizon in the New York area. Service appears to be recovering, and some internet health monitoring sites are showing latency entering and exiting the Verizon hub in Boston.
Nanog are reporting a few people experiencing connectivity issues in the NY US area.
If you have any information on what happened, let us know and we'll update this diary with the news.
Update: Verizon have indicated via Twitter that:
"a router responsible for peering in the Northeast failed. It was reset and traffic should be coming back."
VMWare have informed us that an update is available for their Apple Mac version of their VMWare environment, VMWare Fusion.
The update fixes a vulnerability found in all versions of VMWare Fusion, so if you use this product, it is time to update. A vulnerability for one of the issues has been published.
The published vulnerability apparently produces a remote shell with root privileges but I have not tested it at this time.
The exploit writer comments:
"The vmx86 kext ioctl handler permits an unprivileged userland program to initialize several function pointers via the 0x802E564A ioctl code. These function pointers are later used from several reachable locations within the driver, one of which is called immediately after initialization."
A whole raft of new SysInternal goodness has been released just before the weekend so we have new versions of our toys to play with over the weekend.
Mark also blogs about a couple of interesting issues.
Thanks to Roseman for the heads up, and the follow-up e-mail.
The guys and gals over at OpenSSH have announced that a new version has been released. This is version 5.3, and its also the 10th Birthday version of the stalwart of secure communication over TCP port 22.
Details of the release can be found in the release note and should be on the mirror servers soon.
The release note shows a couple of general bugs, and a few platform specific ones.
Enjoy, and remember to test your deployment!
The second day of Cybersecurity Awareness Month is dedicated to the strange, and anomalous port number, 0.
It is possible to specify a socket only partially by setting the PORT
identifier to zero or setting both the TCP and PORT identifiers to
zero. A socket of all zero is called UNSPECIFIED. The purpose behind
unspecified sockets is to provide a sort of "general delivery"
facility [useful for logger type processes with well known sockets].
"alert tcp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC tcp port 0 traffic"; flow:stateless; classtype:misc-activity; sid:524; rev:8;)"
We've received a few notes today about a recent increase in attempts to log in as root via ssh.
The activity graph confirms this activity as well as another spike toward the end of last month.
If you allow remote root logins (bad!), you'll want to check your systems.
I'm sure we'll here more on this topic when port 22 is discussed for Cyber Security Awareness Month
Christopher Carboni - Handler On Duty