john

John Morgan Salomon, information security consultant, professional chainsaw juggler and south American tyrant in his spare time.

Your Gmail Account Has Been Hacked…

Exploits, Identity Theft, Incident Response No Responses »

Oct 142010

…cracked, compromised, stolen, whatever.

Die in a fire, you Nigerian shit.

The first symptom, as far as you can tell, is probably a bunch of your friends asking you casually, what the kind of crap is that you’ve been sending them. It’s only when you ask them to show you the messages they’re referring to that you realize that some Nigerian, Russian, Chinese, (or, for that matter, American, French, Japanese, what-have-you) son of a bitch controls your account and is blasting out garbage to all your friends.

Even more nefariously, a lot of these are plausible-sounding messages, like one I received recently from an email contact purporting to be stranded in Madrid after his wallet, passport, keys, phone, and plane ticket were stolen, begging his friends to call him on a local number for instructions on how to wire some emergency cash. Frequently, the only thing that gives such messages away at a cursory glance is the piss-poor spelling and grammar used by the scam artists responsible.

This post is sort-of directed at the non-technical people, who maybe don’t check their personal mails all that often. Yes, it’s confusing, and yes, it’s not fair, and yes it’s hard work. So are taxes. If you’re not lucky, not only do all your friends now think you’re an idiot, but all your email has been deleted.

First, see if the mail is still around. Check the trash and ‘all mail’ links. Maybe you’re lucky. Google does not restore deleted mail from backups.

To make sure nobody is able to hack your account again (i.e. with backdoors) go to

https://www.google.com/accounts/ManageAccount?service=mail&hl=en

Under “personal addresses” go to “email addresses” (top right). Make absolutely sure that any addresses for which password recovery is enabled are only ones you trust. Otherwise an attacker could just say “hey, I want a password reset sent to my address”. Smart attackers leave their own addresses there.

To understand how this could have happened, here are some more common ways in which someone can “hack” your gmail account:

trojan on your PC
sniffed password (you do use SSL by default, right? It’s a gmail option to always force SSL)
sniffer on a shared system (Internet cafe)
untrusted app
xss / cookie stealing

Trojans

That is short for “trojan horses”. These are often self-replicating viruses either downloaded from malicious web sites that were hacked (in some cases you won’t even know, you may be using an older browser like Internet Explorer 6) or via an unpatched Adobe Acrobat, or Flash. May also come from someone attacking your PC by network, say in an Internet cafe. You may not see these; you open up a website like you usually do, but it’s been compromised, and boom, that’s it. Invisible, annoying. Or, your laptop/workstation may be attacked remotely, using a security hole in the operating system.

How to deal with them? Regularly update your browser to the latest version and install operating system security patches. Make sure you have an up to date virus scanner. Do regular scans. Turn on your PC’s firewall (google for Windows firewall or Mac firewall. Both systems have a semi-decent one built in that will at least give you rudimentary protection.) Avoid using open wireless networks and visiting sites you don’t know whenever possible.

Sniffed password

You do have a strong password, right? Strong passwords have

8 characters or more
a mix of upper/lowercase letters
numbers thrown in
non-alphanumeric characters (e.g. !, ?)

Use mnemonics to more easily remember passwords (Ih8h@ck3rs!) or pass phrases (actual sentences) if a website / application supports them.

Your password can still be stolen by being “sniffed” — this means that you are logging into Gmail without the connection being encrypted. Have you bought stuff online and seen the little lock at the bottom of the page? That means your browser is using encryption to make sure anyone listening in cannot “sniff” your password. SSL, or “secure socket layer” is that little lock on the web browser. To enable it by default in gmail, go to settings->general->browser connection. Set it to ‘always use ssl’

Next, check your applications and make sure there’s only stuff there that you yourself enabled. Delete anything you didn’t.

Lastly, on your gmail main page, go to google labs (the green erlenmeyer flask icon at the top right next to the “settings” link) and make sure that only labs apps you yourself enabled are active. Deactivate all others.

Sniffing on a shared system / Internet cafe

Password sniffing is quite difficult when, say, you’re connecting from home. It is _very_ easy when you are at an Internet cafe. Wireless connections can be encrypted, via WEP or, better, WPA or WPA2, both supported by almost all wireless cards in laptops. If a wireless connection requires a password, it’s usually at least somewhat safe. WEP is not so much safe, but it’s better than nothing. If you are at an Internet cafe using a common PC, you risk that someone will have installed a piece of software that can “read” whatever password info you type (known as a “keylogger“). There are ways to ensure that this doesn’t happen (e.g. the system is reinstalled from scratch after each reboot — not so complex) but that is tough. Your best defense is to buy a small netbook or something and take it with you.

When using an Internet cafe, never click anything that offers to remember password. When you log out, always clear any stored information, e.g. cache, passwords and cookies. Here is a link that explains how on various browsers.

Furthermore, most modern browsers have a feature called “private browsing” or some variation thereof. This means that nothing is stored while you’re online. Use it.

Untrusted applications

See above with google apps. Also, when you download software or docs, obviously never run/open anything you do not explicitly trust. Have a good virus scanner, run it regularly.

Cross-site scripting (XSS) / cookie stealing

Cookies are bits of information that websites use to remember things about you — for example, when you log into amazon and return later, a cookie is what is placed on your PC to let you auto login again.

These can be “stolen” and used to impersonate you, i.e. when you use an Internet cafe system. To help protect against this, whenever you are done browsing, manually log out of everything, and go to your browser’s “clear history” link (e.g. on Firefox, under tools-> clear recent history).

They can also be stolen while you are online, although that is a bit more complex. XSS is “cross site scripting”, which basically means that if you have a browser open and visit a trusted site in one window and a malicious site in another window (again, the “malicious” site may just have been hacked and not be aware of it) the guy who has taken over the “bad” site can intercept and steal your session with the “good” site. This is probably where most google account hacks come from.

To guard against that, when you log into gmail or another service, make sure it’s the only browser window you have open; don’t multitask with several tabs unless it is to visit sites you know are legitimate.

This can all happen even if you take all due precautions, but it is rare.

Also, regarding passwords, make sure you have a STRONG one. I.e. at least 8 characters, alphanumeric, mixed case, some special symbols thrown in (!?*whatever) and nothing that could be tied to you (name, birthday, etc.) Use a mnemonic (i.e ilikechinese -> 1l1k3ch!n353!)

A precaution: back up your email account. Here are 3 million search results for “gmail backup”.

From my latest victim friend:

Thanks for helping me John – it’s been a fucking nightmare as a freelance writer – I’ve lost so much material!

The same thing can happen with Hotmail, Yahoo!, LinkedIn, Facebook, Plaxo, anywhere you store large amounts of contact info. Standard precautions apply. And as always, nothing is foolproof.

iPad Security — My Overview

Architecture & Design, Crypto, Gadgets 2 Responses »

Oct 072010

I had the chance to briefly look at an iPad today, with the idea of checking out, at least on a superficial level, its security functionality.

My overall impression? A really nice device, with a good touchscreen; although I’m tempted, I can’t imagine what my greasy fingers would do to it – and my iPod Touch 2G scratched pretty easily even with casual use, despite its nice case. It seemed fast enough, with tons of screen space. I’m not exactly sure what I’d do with it (I love typing and am a bit clumsy with things like finger/mouse gestures and with my iPod’s – admittedly miniscule – on-screen keyboard), although my friend Ant came up with the best use I can imagine — photographers showing off their portfolio to potential clients. The same would go for company presentations/electronic note-taking and doodling, and casual news/magazine/book reading, I guess.

In terms of usability, it’s been reviewed to death.

But I was not able to find much of any use regarding data protection and encryption, particularly in an enterprise environment. Privacy and confidentiality issues seem to be limited to personal use, and nobody appears to have done a comprehensive overview, not of its guts, but of security applications in the business world.

The September MISC Magazine (France) has an interesting section on iPhone security, with a lot of detailed technical analysis. By comparison, Apple’s overview of iPad security in the enterprise (pdf) is marketing fluff. Most of the other articles I was able to find were either breathless “the iPad will bring XYZ to your company!” garbage, or fluff pieces of the “in order to secure the iPad in the enterprise, ensure you have proper enterprise security” variety that bored security consultants like me write when they have nothing better to say.

The device I looked at was a 64GB model with GSM (no SIM card), iOS 3.2.2. This appears to fix certain vulnerabilities that allowed, among other things, remote privilege escalation, used in past versions of jailbreaks, but seems to still be vulnerable to a few issues. This is an attempt to collect the useful bits I found; the information may be superseded at time of reading, so do your own research.

The risks I can identify are the following:

danger of sensitive information compromise from a stolen (or less likely, network-accessed) iPad
danger to the company network from an iPad connected via wireless/VPN

Security features include:

Mandatory AES256 filesystem encryption. Although I couldn’t find specifics on this, I assumed it was similar to OSX’s FileVault. This is apparently not the case. The encrypted image can easily be accessed via jailbreak, e.g. RedSn0w, allowing access to files. It looks like the disk crypto allows no protection against this.
Numeric PIN code, that can auto-lock the device after 2/5/etc. minutes (or never), and manual lock with the top button. PIN protection can also be used to restrict apps (more on that in a moment.) The PIN protection is laughable (4 numbers, no more, no less). 4.1 looks like it fixes this, but it is not out for iPad at the moment.
Auto-wipe after 10 failed PIN attempts. This is disabled by default in 3.2.2
Application restrictions. Not much of a security measure; it allows prevention of access to applications based on the iTunes App Store’s age rating. You cannot choose which apps to restrict access to, nor is it possible to allow on-the-fly “unlocking” via PIN code of apps.
Password encryption of backups via iTunes. This is purely local (on the PC the iPad is being backed up to); Jonathan Zdiarski showed this summer that backup encryption is vulnerable. That said, iTunes device backup is a purely secondary protection mechanism; I would suggest to try and convince employees to never back up sensitive files to their personal PCs anyway.
Cisco VPN, including L2TP
Remote wipe using MobileMe — if there is a GSM or wifi connection. MobileMe costs $99 a year. This is also possible via the Exchange management console (over Exchange ActiveSync) or via Outlook Web Access if configured. Again, requires connectivity. Steve Jobs confirmed that there exists a remote kill switch for iPads in case of rogue applications; this would concern me enormously from a compliance perspective — not for the possibility of data loss, but as it implies remote third party access.
Centralized management is possible in the form of XML configuration files deployed via Apple Push Notification Service, allowing setting of such options; the Apple iPhone configuration tool is used to generate such configurations. Apple has some resources on enterprise management of iPads/iPhones.

Computerworld wisely suggests using something like 1Password, for more granular access control for files. Applications like Lockdown or Locktopus (both jailbreak required) provide password protection on a per-application basis; a quick google search didn’t turn up any Apple-sanctioned apps that do this.

Concerning danger to corporate networks from iPads, the only thing I can come up with is rogue jailbroken apps, and the very low probability that something bad is successfully smuggled into the Apple app store (as has happened in the past). The danger from these would be minimal if the iPad is only sync’ed with a company PC via USB, rather than being allowed to access the company network via wireless or VPN. If you are running an internal wireless network, that’s in front of a dedicated firewall anyway, right?

As always, a little user education goes a long way. Particularly users who buy their own iPads are less likely to lose them, turning Apple’s obscene pricing policy into a bit of a positive thing. If users can avoid connecting external USB devices, restrict themselves to only installing apps that they need, and practice a bit of discipline in terms of what they do with the device, they look like reasonable choices for low-security data. I wouldn’t put anything secret on one, though.

Getting Started in Security

Organization 1 Response »

Aug 052010

I’ve seen a few “how do I get started in security?” posts online recently. This is a running attempt to put together an answer. Note that a lot of these are from my subjective experience. They may not work for you. Other people may also tell you additional, or conflicting information. Do your own research, draw your own conclusions.

This is also not a laundry list of what you should learn, check off, and put on your resume — but a bunch of topics to consider gaining some degree of familiarity in. Many of these I’m by no means an expert in, but I’m at least familiar with the concepts and have the basic understanding needed to figure them out and how they apply to my job.

The Technical Basics

You can’t learn security unless you’re familiar with the technology it deals with. Learn the fundamentals. Here is a very incomplete list. You will never be able to do everything on it, at least not in depth.

It’s only fair to note that I come from an operations / architecture background, and that my primary experience is in network and systems security, plus authentication and cryptography. Draw your own conclusions.

Operating Systems

Installation and management (systems administration). My tip: Start with one of the *BSDs (OpenBSD, FreeBSD, NetBSD) and Linux (any distro — what’s important is figuring out how to use the command line, what files are where, etc.), then Windows. Set up a bunch of virtual machines (using VMWare or Virtual Box or equivalent). A lot of companies use Solaris (get a copy of OpenSolaris and play with it) and AIX, although you’re not likely to get access to many of the enterprise-level software they use. Learn systems administration, buy a good UNIX book. Learn about jails / chroot and virtual servers. Understand Windows Group Policy Objects (GPOs). What is a kernel? How does an operating system’s boot sequence work? Where are logfiles kept, what formats are they in, and how do you configure system and application logging?

Coding / Programming

Scripting and programming. UNIX shell scripting, Perl, C, C++, Java, Python, VB.Net, anything. I was never good at much of this beyond very basic scripting, and that sucks. If you go into any kind of either operations or investigation work, you’ll need this. PHP, ASP, HTML and other high-level “languages” also help. Understand the difference between compiled and interpreted, low-level vs. high-level languages.

Networking

Understand subnets and know how to calculate network masks. Learn what routers, switches, and hubs are. Know the basics of wired and wireless data networking. Understand how different operating systems and applications deal with networks. Learn the OSI model. What are router ACLs? VLANs? Know how MAC addresses work

Network Security

What is a firewall and how is it different from a proxy server? What is a packet filter? Download something like M0n0wall or pfSense and set it up. Buy a hub and learn to sniff packets with tcpdump and Wireshark. Play with Netcat and get two Netcat sessions talking to each other. Understand NMAP and how it works. Learn what load balancers, reverse proxies, IDS and IPS do and how they work. What is host-based vs. network-based IDS?

Applications

Set up Apache and IIS. Set up MySQL, Microsoft SQL Server, or another relational database, and install multiple databases in a single instance. How does ODBC work? Set up a DNS server and learn about DNSSEC. Set up an SMTP server and get it sending and receiving mails. Learn about POP, IMAP, SMTP, Exchange, and their secure variants.

Authentication and Encryption

How does LDAP work? What is Kerberos, NTLM, PAM, SASL? What are SSH/SFTP/FTPS, and can you get passwordless SSH working? What is ‘salt’? Learn how to use John the Ripper and other password crackers (e.g. cain, able). What are rainbow tables? Set up sudo. What is RBAC and how does it work? Why shadow passwords? What are file/directory permissions and how are they configured?

Understand the difference between symmetric-key and public-key encryption. What is SSL / TLS? Can you set up OpenSSL and issue your own certificate? What is x.509 and what are digital certificates? What is a PKI, a smart card, a root certificate, a CRL? What is a hash? What are checksums? Can you set up PGP/GPG? What is IPSEC, and what are its different implementations? Can you set up KAME between two hosts? What are cookies and how do they work / how can they be abused? What is the difference between encryption, signing, and non-repudiation?

Other Tools

Download and play with BackTrack and learn some of its tools — Wireshark, Kismet, Metasploit, etc. — it also includes some of the applications I mention above. Play with dsniff and at least familiarize yourself with what its various components do.

Security / Cracking Techniques

What is penetration testing? White box / grey box / black box testing? What is SQL injection? How does XSS work? What is a buffer overflow? How does fuzz testing work? ARP spoofing? Session hijacking? Privilege escalation? How would you sniff network traffic (hint — see above)? What are different kinds of keyloggers? What is a virus, a trojan, a man-in-the-middle attack?

Non-Technical Stuff

A lot of security is based around laws and best practices.

Laws

You should be aware of legal issues surrounding the following, across various jurisdictions:

Privacy
Data protection
Wire and communications fraud
Reporting obligations

Related laws also concern the following

Financial disclosure and due care (e.g. SOX 404)
Medical records (e.g. HIPAA)
Risk management (e.g. Basel II)
Safety and due care laws
Contract law

There are a lot of laws that cover things like financial risk, operational risk and liability, intellectual property / secrecy rights, and rules of evidence. They vary hugely between jurisdictions. Keep this in mind.

Standards and Best Practices

The past years have seen an increasing degree of standardization and development of frameworks that may at least be useful as references. A few examples with at least some security relevance:

COBIT
ITIL
ISO 27001
HL7 (medical)

There are also innumerable organizational requirements and contractual standards (e.g. stock exchange security rules) that a company or group may have to follow.

My personal advice: give yourself at least a basic idea what the big ones are (in your field and cross-disciplinary), and what they’re about, take what makes sense.

Concepts

What is risk? What is a vulnerability? What is a threat? What is CIA and why is it important? Figure out the differences between privacy and anonymity. How is availability calculated? What’s the difference between a policy, a procedure, and a process? Who is responsible for what, where, when?

Education and Networking

Courses and Certifications

Technical

I took a few basic Cisco and systems administration classes — these were helpful, but I’m not a big fan of coursework. Your mileage may vary. In addition, I’ve done several individual sessions (for example, an NMAP “dojo” with the guy who wrote it) that were pretty helpful. Most of my knowledge comes from experience and personal learning, though, so I can’t comment. My general opinion: great, if you can get someone to pay for it.

Degrees and Diplomas

Groups like Royal Holloway, ETH Zurich, and CERIAS offer diploma courses in information security. What do I know, I have an undergraduate degree in international relations from Cal, and an MBA. Not directly academically useful to my career, but very interesting in terms of environment and exposure to people smarter than myself. That should be your primary goal anyway.

The NSA has a list of accredited schools with information security programs.

Security-Specific

There exist tons of security courses, including SANS trainings, ISC², and others. I passed the CISSP exam, which was interesting-if-basic, and decided against throwing more money at certifications. As with the technical courses above, my personal opinion is that if you can get someone to pay for it and to give you the time for it, superb.

Subjective view: I would be suspicious of any employer that requires technical certification if you have any kind of professional experience.

Dan Guido (see under “Other Resources”) has a list of courses if that’s your thing.

Conferences and Networking

A lot of this field is about meeting people. Plus, conferences can be a lot of fun (often you end up going out and getting drunk with a bunch of geeks, which is usually rewarding in itself, in addition to actually letting you watch good presentations.)

I’ve attended http://cansecwest.com/ and CERIAS, which are about as completely different as it gets in terms of focus

The downside is that a lot of the security area is about personalities — don’t let that discourage you. Odds are you’ll never be a vulnerability research rock star with fawning hordes of nerd groupies, but that’s not the goal, right?

Meet people. Again, meet people. Get to know them. Don’t worry so much about making friends with the “big names”, but familiarize yourself with the people in your company, in similar companies, in your city, and in your field. I run a small security mailing list, originally designed to let IT security types in Switzerland get together for beers and pizza. Do the same. Stay in touch — these people are your network (and can be pretty cool to boot.)

Try to help others as much as you can — on forums, and on mailing lists. In addition to being good karma, it often will help you learn for yourself.

Books and Materials

RFCs are your friends. They’re written extremely densely, but the information is there.

Sign up for mailing lists, specifically in aspects that interest you (these are often flooded, so don’t try to take in everything at once.) Security Focus is a good start.

Check a few pages regularly for information on security vulnerabilities. Secunia and the F-Secure blog are decent.

Other Resources

Dan Guido has a good writeup of what to look for. Look for pages written by people like Bruce Schneier, there are too many to even start listing.

Career Decisions

What do you want to do?

This is a tough one, seriously.

I wanted to be a UNIX systems administrator, back when tech was still fun. Then, one day, someone dumped a firewall book on my desk, and said, “you’re the security expert, read up. Congratulations.” I bounced around in architecture, operations, compliance, policy, and training work, before ending up doing mainly incident response and risk management. In fact, most of the people I know who are good at “security stuff” gradually evolved into their roles, rather than deciding early on “I want to do this or that”.

Of course, to be fair, nowadays a lot of the field is more structured. Your mileage may vary.

This is a really arbitrary, artificial list. A lot of the following fields overlap heavily:

Operations

Mainly network security and authentication. Lots of systems administration. Usually lots of relationships with OS- and application administrators.

Architecture / Development

Designing and creating stuff. Can be “low-level” (i.e. network security architect, which firewall goes where), or “high-level” (designing policies and rules for putting various types of technologies to different kinds of use.) Could also involve writing software or configuration files.

Research

Either academic, commercial, or individual (whee, lookit me, I h4x0r3d a web site). You try to find new vulnerabilities, or work on new security technologies.

Policy and Compliance

The people who write the rules of what companies should do to ensure security. Relevant to audit. Generally high-level, deals with laws, best practices, and organizational-level risk management.

What I currently do (security risk assessment) is related to this — I work with projects and try to make sure their technology is reasonably secure and they follow all the rules, then suggest ways they could do things better, pre-emptively.

Penetration and Code Testing

What it sounds like — you get paid to try and break other people’s toys and tell them what they should do better. Usually nowhere near as fun as it sounds like, as it mostly involves fairly strict limitations (e.g. you can’t take down banking systems, you have to follow strictly defined procedures) and lots of paperwork (letters of authorization, formatted reports, etc.)

Forensics, Investigation, and Incident Response

This is fun, but occasionally frightening and frustrating. Its main component is following up on abuses of policies and laws. This includes, but isn’t limited to: attacks from inside and outside, harassment, violation of technical policies, industrial espionage countermeasures, and electronic fraud investigation. Also deals with damage control from things like denial of service attacks or other things going wrong.

It tends to also involve cooperation with architecture and operations people, in terms of things like preventative or reactive patch management. Warning: may seriously impact your faith in human decency — from the management attitudes and legal techniques you deal with as much as the rancid child pornography you’re likely to be exposed to.

Where do you want to work?

Never forget that, in almost any security job, you’re a service provider whose job is to restrict what people do.

It’s important to figure out if you want to work for yourself (can be very difficult at first), as an employee, or as a contractor.

My experience is mainly in the following fields:

Financial Services

Banks pay well. They’re among the biggest security consumers. They tend to have access to lots of new technology and move pretty fast, but are also lots of management. Can often be very personality-driven, usually more formal than other work environments. Depends heavily on whether you work in private, retail, or investment banking, insurance, finance, or others.

Medical / Diagnostic

Much slower-moving than finance. Heavily focused on QA (e.g. data integrity). Usually lots of very smart people — security is comparatively new to these guys and heavily laws-driven.

Education

Stay away. Seriously. My only advice. Feel free to draw your own conclusions, but in my career, it’s been the most political, ill-paid, big-fish-small-pond nastiness I’ve ever encountered.

Services / IT Products / Consulting

Usually reasonably paid — the advantage is that you’re working with other tech people. The disadvantage is that, in most cases, your employer often takes a significant chunk of your paycheck.

I have no experience in the following:

Government / Military

Lots of money, salaries generally not that good, new technology but very strict rules.

Industrial

Commercial

Non-profit

….and others.

Most importantly, some pieces of advice that apply to all jobs:

Always try to talk directly to the manager who’ll be in charge of the group you’re applying to. Going through HR is often a dead end.
Never ever lie on resumes. Don’t be afraid to publicize yourself, though.
Avoid politics.
Never burn bridges.

I hope this helps.

Hiding from Bentham?

Privacy No Responses »

Aug 042010

A colleague recently brought up an interesting discussion — how to hide from Google?

Privacy and anonymity are good things. Bruce Schneier has some great points – they are essential for democracy, and absence of anonymity is ripe for other kinds of abuse.

All arguments against online privacy and/or anonymity come down to the question, “what do you have to hide?” to which the only useful response is, “nothing, let me film you the next time you use the toilet”.

My first instinct is, “why bother”? As others have pointed out, staying anonymous online is a myth. Even if you disconnect yourself from Facebook, webmail accounts, and any support forums you might otherwise use, and religiously heed the dictum that you should never post anything anywhere online that you might not want someone to see, a sufficiently motivated analyst would find what I would refer to as second- and third-tier records, such as credit card bills, bank accounts, social security numbers, driver’s license details, etc. — more than enough for most purposes.

Both privacy and anonymity are, at most, best-effort affairs. So what is the motivation for this sort of research? A few plausible scenarios:

Identify theft (e.g. constructive, for financial or other gain, or destructive, for defamation/slander)
Targeted investigation (e.g. for a job, political office, or crime-related research, etc.)
Statistics (e.g. targeted marketing)
Trawling (e.g. to find instances of wrongdoing)
Other (e.g. digging up dirt, fun)

I would guess that a vast majority of information collection falls into category 3, followed at a distance by category 4. Category 3 is worrisome mainly if you disagree with it out of principle. Fair enough. Growing technological capabilities of data cross-correlation systems allow for easy creation of entire profiles from otherwise disconnected bits of information. The potential for abuse of such a holistic, instantly accessible set of information about you as an individual is immense.

Even in the “right” hands, such as law enforcement (depending on your point of view) and responsible marketing types working under a strong privacy policy, the temptation to misuse data is inevitable. It is human nature to break rules, even in small ways — we are not automatons. I won’t go into scenarios about what even a government agency, scrupulously following all laws to the letter, could do with instantaneous, 24/7 knowledge of what you do, where you are, and what you’re thinking (category 4, followed by category 2), let alone a criminal element with stolen data about you (categories 1 and 2). Just in the hands of advertisers alone, the potential for irritation is limitless.

So let’s say that, out of principle, you object to the collection of information in the course of routing activities like online searches and use of free webmail service. I firmly believe that the best way for individuals to make the collection and correlation of information more difficult is to create as much entropy as is feasible. You can’t make it impossible, but you can at least make it not as easy.

In addition to at least making an effort to secure your Facebook profile as much as possible, some basic points:

Use GPG or PGP for mail and files. Most mail clients have easily available plugins. Make your key available.

When using free services like (highly recommended, by the way) Dropbox, use something like PGPdisk. You won’t be able to access it via the web interface, but it provides good security for files you share between computers.

Use SSL whenever you can. Even if you don’t use a commercial ($$) certificate for your own web page, you’re just trying to encrypt traffic. I recently made the mistake of accessing one of my (non-SSL) website accounts from a public wireless network, and only realized my mistake two seconds after logging in. Whoops. Password change time…

Use tor, and the excellent Vidalia package (on the tor site). Tools like the Firefox torbutton add-on make this a snap.

Tunnel things via SSH, and only use SSH for access to UNIX boxes. Of course, you’re already doing this.

Search on googlesharing (assuming you trust Moxie Marlinspike more than you trust Google) and use any of the other anonymizing services out there. If you run your own system, I can also recommend tools like nph-proxy.

And, of course, never post anything online you wouldn’t want someone else to see.

But again, full anonymity and privacy are illusory. Someone who cares enough can always find out about you, given sufficient tools and determination. Enter a colleague’s attitude, which I find pretty interesting.

His point is that it’s best to establish patterns of regular usage, that most of what you do is utterly and completely uninteresting to anyone out there beyond statistical correlation with hundreds of millions of other users, and that you can’t realistically expect to hide 90% of your Internet activity anyway. For those times when you really need to duck under cover, though, you should be technically astute enough to abandon those patterns you’ve established.

His logic, which I can’t refute, states that it’s better to have a public persona, which will provide plausible deniability of the few, specific instances when you really need privacy and anonymity, than to constantly attempt to hide everything you do.

Evaluating Bespoke Trading Applications

Forensics, Management, Politics, Privacy & Security Law No Responses »

Jul 282010

A planned Black Hat talk on High-Frequency Trading (HFT) vulnerabilities was recently pulled from the 2010 Black Hat conference, ostensibly at the request of one of the authors’ clients who probably felt that the planned disclosures hit a little close to home.

HFT is a hot topic in circles ranging from regulatory and compliance discussion forums, over smaller traders, to conspiracy wingnuts. Despite the fact that it’s just one technological tool among many to give exchange participants an edge over competitors, I tend to side with the conspiracy theorists, especially insofar as it’s an approach to transactions that by its very definition gives an edge to larger market actors — thus skewing the idea of a “fair market”. Various individuals have claimed that this goes so far as to allow participants to manipulate prices using fake orders, but I don’t know enough about trading technology to comment on this.

Due to the very technologically intricate and detailed nature of HFT platforms, very few people understand how they work — and overtaxed regulators and security & compliance organizations thus are left in the dust when it comes to ensuring that such solutions do not present a security and operational risk, not just to the companies who run them, but to overall market stability. Remember, complexity is almost always bad if you can’t reliably understand it with a reasonable grasp of the subject matter.

The article has one particular paragraph that rings very true:

While applications are combed for typical application vulnerabilities like SQL injection or cross-site scripting, they’re not examined for operational vulnerabilities: A rogue trader could, for instance, change a single variable to allow far more risky trades than a bank or its clients intend–the sort of trick that Société Générale trader Jerome Kerviel may have used to make unauthorized trades in 2008 that cost the firm $7 billion.

Yeah, basically. Many of the people who use these toys are very bright autodidacts, creating customer tools for exotic, structured products. Even off-the-shelf software is frequently written using what I like to call “functional programming” — i.e. a very smart person with a Visual Basic book coding a solution to an operational requirement without paying attention to best practices that may, in any case, be outside of the scope they care about. Investment firm management is likely to turn a blind eye to even obvious flaws in such software, due to the fact that traders (a) bring in massive amounts of revenue and (b) are increasingly the only people who understand certain market types.

The rise in black pools and other off-exchange trading will only increase the latter phenomenon; I’ve seen trading floors where it was pretty common for one person to be responsible for a particular exotic product; frequently, this person might even have been the one who helped create the actual market. Remember, you can trade pretty much anything, as long as you have a willing counterparty…

How do you deal with such issues as a security professional? To many who are not trained in the black arts of financial transactions, much technological innovation in modern markets is the driving force behind an increased complexity that regulators cannot hope to oversee effectively. Analyzing security issues in such tools also becomes difficult, even from the inside, even when a company is willing to implement controls — the line between legitimate exploitation of a weaker player’s market position and an actual security intrusion blurs to the point where traditional technical vulnerability analysis is no longer an option.

I don’t have a solution, beyond an innate distrust of anything I don’t understand in detail, but I believe that companies’ willingness to reduce their exposure to security issues stemming from overly complex trading software is more a philosophical than a policy or technical question — how far are we willing to go to exploit loopholes in the spirit of market regulation? Are we willing to sacrifice potential high risk + high profit combinations in order to remain in more staid trading areas?

And most importantly, if management won’t listen, as a security guy, can you sufficiently CYA to avoid being caught up in a potential technical or regulatory failure of one of your employer’s systems that’s just too intricate to reliably review for risk?

A Practical Guide For Defeating NMAP OS Fingerprinting

Forensics, Network Security, Pen Testing No Responses »

Jun 222010

This was on my old site before I moved. Maybe someone will find it interesting.

-John

David Barroso Berrueta

http://voodoo.somoslopeor.com

<tomac@somoslopeor.com>

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

Remote OS Fingerprinting is becoming more and more important, not only for security pen-testers,but for the black-hat. Just because Nmap is getting popularity as the tool for guessing which OS is running in a remote system, some security tools have been developed to fake Nmap in its OS Fingerprinting purpose. This paper describes different solutions to defeat Nmap and behave like another chosen operating system, as well as a demonstration on how can be accomplished.

Table of Contents

1. Introduction

2. Reasons to hide your OS to the entire world

3. Nmap

4. Linux solutions

4.1. IP Personality

4.2. Stealth patch

4.3. Fingerprint Fucker

4.4. IPlog

5. *BSD solutions

5.1. Blackhole

5.2. Fingerprint Fucker

5.3. OpenBSD packet filter

5.4. FreeBSD TCP_DROP_SYNFIN

6. General solutions

7. More things to play with

8. Conclusion

References

A. GNU Free Documentation License

A.1. PREAMBLE

A.2. APPLICABILITY AND DEFINITIONS

A.3. VERBATIM COPYING

A.4. COPYING IN QUANTITY

A.5. MODIFICATIONS

A.6. COMBINING DOCUMENTS

A.7. COLLECTIONS OF DOCUMENTS

A.8. AGGREGATION WITH INDEPENDENT WORKS

A.9. TRANSLATION

A.10. TERMINATION

A.11. FUTURE REVISIONS OF THIS LICENSE

A.12. ADDENDUM: How to use this License for your documents

1. Introduction

The purpose of this paper is to try to enumerate and briefly describe all applications and technics deployed for defeating Nmap OS Fingerprint, but in any case, security by obscurity is not good approach; it can be a good security measure but please take into account that is more important to have a tight security environment (patches, firewalls, ids, …) than hiding your OS.

Learning which Operating System is running in a remote system can be very valuable for both the pen-tester and the black-hat. Suppose that they find an open port in their (approved or not) penetration; knowing the OS makes easier to find and execute an exploit against that service, because often an exploit is OS version specific, and an exploit for Sendmail running on HP-UX won’t work for Sendmail running on AIX, or being more accurate, an AIX 4.3.3 exploit could not work in a system running 4.3.3 with the latest maintenance code applied. Fyodor (Nmap’s author) has written a detailed article about remote OS Fingerprint, describing some different methods to successfully detect the remote OS, from the basic ones, to the more powerful ones.

In the beginning, guessing the remote OS was done grabbing the banner that a specific service was serving. For example, a typical telnet or FTP banner was always shown to the entire world, telling which OS was running, or if the banner has been changed or removed, some service commands could be executed to know the OS (remember the SYST in the FTP). Other basic ways to know the OS could be searching for HINFO entries in the DNS server, or trying to get information using snmp (lot of devices have enabled by default snmp access using the ‘public’ community string). Even searching for the target company jobs posting in the Internet, dumpster diving looking for OS manuals, or social engineering are valid methods for trying to know the remote OS.

Then, some more advanced network solutions were deployed, taking advantage of each OS vendor TCP/IP stack implementation. The idea is to send some crafted packets to the remote OS and wait for its answer. Those packets are “nasty” packets, crafted with uncommon TCP options or with ‘impossible’ options. Each OS has its own TCP/IP stack implementation, there isn’t a common stack implementation for every OS and this issue allows to create a classification of different OS and versions according to their answers. Playing around with those tricky packets is how remote OS Fingerprinting tools work; some of them using the TCP/IP protocol, and others using the ICMP protocol.

There is a paper about ‘Defeating TCP/IP Stack Fingerprinting‘ that describes in high level the design and implementation of a TCP/IP Stack fingerprint scrubber. That paper outlines why and how you can defeat TCP/IP OS Fingerprinting, so I am not going to talk too much about that; therefore I will focus on the solutions available out there.

2. Reasons to hide your OS to the entire world

Perhaps you are wondering why do you want to spend your precious time changing your Linux kernel to hide your real OS version against Nmap ‘bad purposes’ users. Maybe the following reasons can convince you:

Revealing your OS makes things easier to find and successfully run an exploit against any of your devices.
Having and unpatched or antique OS version is not very convenient for your company prestige. Imagine that your company is a bank and some users notice that you are running an unpatched box. They won’t trust you any longer! In addition, these kind of ‘bad’ news are always sent to the public opinion.
Knowing your OS can also become more dangerous, because people can guess which applications are you running in that OS (data inference). For example if your system is a MS Windows, and you are running a database, it’s highly likely that you are running MS-SQL.
It could be convenient for other software companies, to offer you a new OS environment (because they know which you are running).
And finally, privacy; nobody needs to know the systems you’ve got running.

3. Nmap

Nmap is one of such tools. It sends seven TCP/IP crafted packets (called tests) and waits for the answer. Results are checked against a database of known results (OS signatures database). This database is a text file that contains the result answered (signature) by each OS known. Thus, if the answer matches any of the entries in the database, we can guess that the remote OS is the same that the one in the database. Some Nmap packets are sent to an open port and the others to a closed port; depending on that results, the remote OS is guessed. A sample entry could be:

/* OS Comment. Yes, we want to be a Sega Dreamcast console */

Fingerprint Sega Dreamcast

/* ISN predictibilty; TD: time dependant */

TSeq(Class=TD%gcd=<780%SI=<14)

/* Test 1 result: SYN packet with some options to an open port. We got

a SYN+ACK, acknowledgment seq +1, window size 0x1d4c, don’t fragment

bit not activated, and only the MSS returned */

T1(DF=N%W=1D4C%ACK=S++%Flags=AS%Ops=M)

/* Test 2 result: Null packet with options to an open port. We got a

ACK+RST, acknowledgment seq, window size 0×0, don’t fragment bit not

activated */

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

/* Test 3 result: SYN, FIN, URG, PSH with options to an open

port. We got a SYN+ACK, acknowledgment seq +1, window size 0x1d4c,

don’t fragment bit not activated, and only the MSS returned */

T3(Resp=Y%DF=N%W=1D4C%ACK=S++%Flags=AS%Ops=M)

/* Test 4 result: ACK packet to an open port. We got a RST,

acknowledgment seq, window size 0×0, don’t fragment bit not activated */

T4(DF=N%W=0%ACK=S%Flags=R%Ops=)

/* Test 5 result: SYN with options to a closed port. We got a

ACK+RST, acknowledgment seq, window size 0×0, don’t fragment bit not

activated */

T5(DF=N%W=0%ACK=S%Flags=AR%Ops=)

/* Test 6 result: ACK with options to a closed port. We got a RST,

acknowledgment seq, window size 0×0, don’t fragment bit not activated */

T6(DF=N%W=0%ACK=S%Flags=R%Ops=)

/* Test 7 result: FIN, PSH, URG with options to a closed port. We

got a ACK+RST, acknowledgment seq+1, window size 0×0, don’t fragment

bit not activated */

T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

/* Port unreachable message result. No response */

PU(Resp=N)

Then, if we want to defeat Nmap and tell the attacker that we are running a different operating system, we only need to fake the responses to the Nmap tests. The solution that is going to describe is only valid for defeating Nmap and not other remote OS Fingerprinting tools. In the Conclusion section, other tools will be mentioned, as well as some recommendations for the pen-tester and/or the attacker.

4. Linux solutions

Methods to defeat Nmap OS Fingerprinting in Linux are written as kernel modules, or at least, as patches to the Linux kernel. The reason is that if the aim is to change Linux TCP/IP stack behavior, and if we want to achieve it, we need to do it in the kernel layer.

Three kernel module solutions are going to be described, all of them independent from the Linux kernel tree; you have to download them and patch your kernel to add the feature. The first one requires netfilter enabled in your kernel (what I think it’s a must if you want to start to have a secure system), but the other two don’t.

4.1. IP Personality

The first and probably, best option is IP Personality. It’s netfilter module (then, only available for 2.4 Linux kernels) that allows us to change the IP stack behavior and ‘personality’, having multiple network personalities depending on parameters that you can specify as an iptables rule. Actually, we can change the following options:

TCP Initial Sequence Number (ISN)
TCP initial window size
TCP options (their types, values and order in the packet)
IP ID numbers
answers to some pathological TCP packets
answers to some UDP packets

An IP Personality overall summary is that we can change the way we answer to some packets, and we can specify which packets we want to answer in such way (it could be depending on the source ip address, the destination port, or, and that’s we are going to use, those crafted packets coming from Nmap)

Installation is fairly straight forward and well explained in the INSTALL file provided by the package; for our test purposes, our test box is a stable Debian box running a 2.4.19 kernel. By default, IP Personality netfilter module is not available in latest kernel, so we need to patch our kernel sources. Patch for adding IP Personality feature to our netfilter core is available in the IP Personality site. We also need to patch the iptables command so that it can recognize our new feature available. Once the kernel is patched and compiled, we need to reboot our box just because the patch also modifies other netfilter files (the connection tracking).

Next step is include our iptables rules related to IP Personality in our working kernel. Before doing it, we run Nmap to check our current OS:

# nmap (V. 3.10ALPHA4) scan initiated Wed Feb 19 20:26:52 2003 as: nmap -sS -O -oN nmap1.log 192.168.0.19

Interesting ports on 192.168.0.19:

(The 1597 ports scanned but not shown below are in state: closed)

Port State Service

22/tcp open ssh

25/tcp open smtp

80/tcp open http

143/tcp open imap2

Remote operating system guess: Linux Kernel 2.4.0 – 2.5.20

Uptime 106.832 days (since Tue Nov 5 00:29:33 2002)

# Nmap run completed at Wed Feb 19 20:26:58 2003 — 1 IP address (1 host up) scanned in 7.957 seconds

Now, we can reboot to run our new patched kernel and add the iptables rules needed to fake Nmap OS guess:

voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sbin/iptables -t mangle -A PREROUTING -s 192.168.0.50 -d192.168.0.19 -j PERS –tweak dst –local –conf dreamcast.confi

voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sbin/iptables -t mangle -A OUTPUT -s 192.168.0.19 -d192.168.0.50 -j PERS –tweak src –local –conf dreamcast.conf

What we are doing with those filter rules is:

The first one means that all packets coming from 192.168.0.50 (me) against 192.168.0.19 (server) have to be mangled and rewritten simulating a Dreamcast behavior. The PREROUTING chain is the one that can do that.
The second one means that all packets coming from 192.168.0.19 (server) against 192.168.0.50 (me) have to be mangled and rewritten simulating a Dreamcast behavior. As is a packet going out the server, the OUTPUT chain is the responsible for that.

Checking our set-up:

voodoo:~/ippersonality-20020819-2.4.19/samples#/usr/local/sbin/iptables -L -t mangle

Chain PREROUTING (policy ACCEPT)