There’s an interesting post on the Skype forums where a Linux user asks why Skype is reading his /etc/passwd file.

Since it was posted during the weekend, and there are Skype developers out there dealing with other issues, I’m guessing he won’t get a reasonable answer from a Skype developer until at least Monday.

It’s not my job to cover for Skype, but I’ll try to give a reassuring answer. More than likely, Skype is only reading /etc/passwd in order to get information about the userid it is running under. It may need to do this to determine its home directory, or to learn more information about the user.

If the programmers are doing it right, they’re using the getpwent() system call to grab the password entry through the name service switch. That’s because you may not be using a local password file at all. If you’re using a workstation in a large environment, your authentication information could be stored in LDAP, NIS, or another global password map. Ironically, when a program uses getpwent(), it doesn’t even know if you have a valid /etc/passwd file.

If you traced the call even further, you would see that the program is reading all of the entries in the /etc/passwd file. Since the file is sequential, there’s no way around that. Nor is there an easy way to tell what happens to the data once it’s read. Maybe it ignores the entries that it doesn’t care about, or maybe it emails them to an insidious hacker.

The /etc/passwd file can be read by any user, so it carries the bare minimum amount of security information. The actual passwords are encrypted and stored in the /etc/shadow file, which is then protected by the operating system by making it read-only from the root account. Reading /etc/passwd might give someone a slight insight into what accounts to possibly compromise, but it won’t offer any special insight on how to compromise them.

On a final note, although I encourage the testing and using of security tools, like AppArmor, I think its use in this case is unneeded. Chris Brown said it best in Protecting your applications with AppArmor:

AppArmor is not intended to provide protection against execution of ordinary tools run by ordinary users. You already have the classic Linux security model in place to constrain the activities of such programs.

Any regular user on a Unix host, should rely on the host operating system security model. I’ll admit, I feel more comfortable saying that about a Unix/Linux/Mac host than I would for a Windows host. If Skype–or any application–tries to perform an action that it isn’t allowed to do, the operating system should prevent it.

The recent change to German law to implement the EU Framework Decision on Attacks against Information Systems (enacted in Paragraph 202c of the German Penal Code) has caused many security researchers based in Germany to look to move elsewhere, or to remove previously available research findings.

The change in the law, which went into effect on August 10, criminalises the production, distribution, possession, and sale of tools that can be used to commit cybercrimes. Unfortunately, a strict interpretation of the changes would make possession of tools that could be used maliciously (such as nmap or Nessus for instance) illegal. While in reality, legal opinions are that the courts would differentiate between a cracker and a security researcher based on their intent, noone (unsurprisingly) seems to want to be the first test case.

The content for a number of projects have all but disappeared, such as the recent Month of PHP bugs, and the well known THC (The Hackers Choice) group, as well as smaller projects such as BtCrawler. Others are saying farewell to Germany and reestablishing themselves elsewhere such as the KisMac wifi scanner for OSX and the Phenoelit group.

All in all a hard strike against a country which has produced much valuable security research and expertise.

Every once in awhile I will have maintenance windows that need to start at Midnight. When announcements are made, there’s always going to be one person out there that gets the day wrong. If I say the system will be unavailable Wednesday at Midnight, I will be asked if I mean Tuesday night leading into Wednesday morning, or Wednesday night leading into Thursday morning.

Technically, Midnight is the beginning of a new day. If you’re used to military time, it’s easier to understand, since you’re starting over at 0000. But most people have always used Midnight in the context of a late evening, as in, I’m going to stay up until Midnight; so it’s pretty common to accidentally associate it with the previous day.

To overcome confusion, we announce all Midnight maintenance windows as having a start time of 12:01 AM. It’s close enough to Midnight, and for some reason, everybody seems to understand it. Sure, Midnight is ambiguous, but 12:01 on a Wednesday is clearly early understood as Wednesday morning. I’m not going to complain about a one minute compromise if it means avoiding ten minutes of writing emails to clarify the schedule.

Following the new “tradition” of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it “pay it forward” to the community.

So, Anton Security Tip of the Day #12: Proxy Log Fun - Proxy Logs vs Information Leakage

You probably know that web proxies (such as Squid, BlueCoat SG, BlueCoat Netcache and others) produce a lot of fun logs. Indeed, they are fun since they can be used for a whole range of things, from routine monitoring for AUP compliance to malware detection as well as possibly looking for the security scourge of 2007 - web client attacks.

Specifically, in this tip we will learn how proxy logs can be used for detection of file uploads and other outbound information transfers vie the web. First, think what is the legitimate use of file upload functionality for your web users. If web mail is allowed, then sending an attachment will include an upload. What else? The rest will be considered at least suspicious…

In addition to file uploads, some spyware application will also use similar methods to steal data. Looking for methods and content-type in combination with either known suspicious URL or user-agent (i.e. web client type) can often reveal spyware infections, actively collecting data. Admittedly, a well-written spyware can certainly fake the user-agent field so it is clearly not reliable, but still useful to add to our query above. Here are some of the criteria we will use to look for uploads in Squid and BlueCoat SG proxy logs:

• HTTP method (logged as “cs-method” by BlueCoat) = POST (as opposed to the usual GET, used to retrieve web content).
• For information uploads: content type (logged as “RS(content-type)” by BlueCoat) = anything but “html/text” (which is the type used for uploading web form contents) - especially try content types “application/octet-stream“, “application/msword“, “application/powerpoint“, “application/vnd.ms-excel“, “application/pdf” and a few others to look for common file uploads
• For spyware and application data transfers: user-agent set to anything but the common ones (i.e. not Mozilla, iTunes, LiveUpdate, etc) or even to “unknown.” One can also try user-agent containing your favorite messaging app (e.g. “MSN Messenger”, etc)

(if you feel adventurous, other interesting content-types to try are “application/x-javascript” and “text/javascript”)

Here are the examples of the above, including some “classics” (while spyware specimen are a bit dated, this method of detecting them via logs is relevant):

1. 1124376766.026 RELEASE -1 FFFFFFFF 4734C557F9315105CA6BE0FA56B94D55 200 1124276674 -1 -1 unknown -1/0 POST http://reports.hotbar.com/reports/hotbar/4.0/HbRpt.dll
2. 1124392388.975 RELEASE -1 FFFFFFFF 810FFBF233584C330353CF0A8C31F5D2 503 -1 -1 -1 unknown -1/813 POST http://log.cc.cometsystems.com/dss/cc.2_0_0.report_u
3. 2007-05-19 03:55:12 160 10.1.1.3 - - - OBSERVED “Spyware/Malware Sources;Spyware Effects;Web Advertisements” - 200 TCP_NC_MISS POST text/html;%20charset=utf-8 http bis.180solutions.com 80 /versionconfig.aspx ?did=5342&ver=1.0 aspx - 10.1.1.2 273 175 - - none - -
4. 2007-05-21 03:10:40 4 10.1.1.3 Joanna- authentication_redirect_to_virtual_host PROXIED “Search Engines/Portals” - 307 TCP_AUTH_REDIRECT POST - http storage.msn.com 80 /storageservice/schematizedstore.asmx - asmx “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MSN Messenger 7.5.0324)” 10.1.1.2 791 2566 - - none - -

Here are some other signs that will make the above log entry extra-suspicious is:

• A dead giveaway: upload happens to a “known bad” URL (e.g containing “gator” and others above)
• Upload happens to an unresolved IP address (do a “whois” on it!)
• Uploads happens to a port not equal to 80 (i.e. the URL contains a port such as http://10.1.10.10:31337)
• Upload has confidential file name in the log entry (e.g. somebody dumb emailing a sensitive file to himself - as discussed here)

Overall, this log analysis method is good for casting a broad net to catch not just spyware-infected systems, but also unauthorized applications (e.g. method=POST and user-agent=iTunes), instant messaging (e.g. method=POST and then by user-agent, content or URL), simple forms of data theft and document handling policy violations (emailing files to self via web mail: method=POST and sensitive file name present in the entry; also content type set to popular file types) as well as other abuses of web access. As a result, proxy logs provide an extremely rich AND readily available source of data about threats that users face!

To top it off, one promising direction of future research is using web proxy logs to detect client-side exploits by malicious web servers (more on this in the near future!)

Possibly related posts:

• Anton Security Tip of the Day #6: The Other Web Log
• All my past security and logging tips

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

I recently had reason to spend a while working with Nessus on Windows XP (Service Pack 2). Usually, I use a Nessus Server running on Linux, either running locally if I am onsite, or one installed on our company infrastructure for scanning from the Internet. In fact, you read the documentation don’t you?, Tenable specifically recommends in the Nessus Installation Guide that you _not_ run Nessus on XP, and instead use a Windows Server product, such as Windows Server 2003.

The reason for this is that in Windows XP Service Pack 2, Microsoft introduced a number of Network Protection Technologies for mitigating the spread of malware. One of these limits the number of simultaneous incomplete outbound TCP connection attempts to 10, with additional attempts being queued and potentially dropped. This impacts the reliability of at least port scanning, and possibly other security checks.

Unfortunately the scenario I was working with required me to be running Nessus through a VPN client (never ideal), in reality requiring me to be on XP. Tenable does, however, have some recommendations for running Nessus as reliably as possible on XP:

• Max number of hosts: 10
• Max number of security checks: 4
• Max number of packets per second for port scan: 50

The maximum hosts/security checks setting is standard in all of the Nessus clients I’ve used, however the packets per second setting seems to only be available within the client shipped with the Windows Nessus server. If you, like me, are using the new NessusClient 3.0 beta for Windows, you need to make the following change to the Nessus server’s configuration to ensure that 50 is the default value:

• Go to the “config” directory in your Nessus server installation. By default this is C:\Program Files\Tenable\Nessus\config
• Open config.default.xml for editing - just use Notepad if you don’t have an XML editor
• Find the SYN Scan:Max number of packets per second for port scan node, and edit the value (the CDATA bit) from 500 to 50

This value should now be the default for all new scans.

This worked well for me, however needless to say that running a Nessus scan in VMWare (slowdown factor one), over a VPN link (slowdown factor two), over a transatlantic Internet connection (slowdown factor three), the scan took quite a while to complete…