--
Why are good security hackers called “White Hats”? Well, because we're the good guys. But why are good guys called “White Hats”? That'll be the legacy of cowboy films, especially silent films, where the audience needed to identify the hero quickly. The biggest and best White Hat film cowboy was Tom Mix. Of course, he did all his own stunts, too.
--
What makes an OS secure?
Certainly you can get your hands on OSs that are known to be insecure … by which I mean that the vendor is able to show you the list of known vulnerabililties for which no patch or reasonable remediation is available. And I'm sure you can guess the names of some of these.
And from the set of OSs that are not known to be insecure, you can figure that some of them are only “not known” because the vendor/distributor simply doesn't want to know.
OpenBSD knows itself to be secure – and even with the handful of problems that show up over time, I'd tend to believe it. The same goes for qmail. But both of them are hard work to learn how to set up properly, and don't tend to have many current “features”.
A build-by-hand system, with the administrator following every vulnerability and patch release, is theoretically excellent … but takes far too much time away from real work.
Debian & Ubuntu suspect themselves to be secure, and know that they have a decent mechanism to fix problems when they are found – their Security Teams may not be as responsive as the upstream package teams, but they promise not to break version compatibility when patching, which is one of the biggest problems that the hand-builder encounters.
Of those last three categories, I'd tend to recommend the OpenBSD style for an install-once and forget type of system, and the Debian/Ubuntu for a install-many-times and regularly update one.
Of course, with Debian/Ubuntu, you must never install packages that don't come from repository sections that are looked after by the Security Team itself. Under those circumstances, you're better advised to set up your own repository for build-by-hand packages, and maintain those exceptions carefully yourself.
]]>--
Two interesting cases in the blog list today that discuss the same aspect of security – the difficulty of collecting hard evidence.
Rember that security is not simply to protect against those script kiddies. It is to protect against real human attackers. As Bruce Schneier reminds us in http://www.schneier.com/blog/archives/2007⁄12/security_in_ten.html :-
But throughout history and into the future, the one constant is human nature. There hasn't been a new crime invented in millennia. Fraud, theft, impersonation and counterfeiting are perennial problems that have been around since the beginning of society. During the last 10 years, these crimes have migrated into cyberspace, and over the next 10, they will migrate into whatever computing, communications and commerce platforms we're using.
So, back to the theme. Info World has recently collected a top 10 list of bad corporate security behaviour. Number 7 states that “Handling breach details sloppily tips off the perp” and reminds us that a tipped-off perpetrator will be able to cover their tracks.
The FBI believes that Ukranian politician Dimitry Ivanovich Golubov is one such perp, who was able to wipe incriminating digital data when the police searched his apartment. Dimitry claims in a communication with the Washington Post Security Fix blog that although his data was indeed wiped by an EM pulse generator, it was accidentally triggered by the police themselves …
This officer has found Raskat system remote control. He decided that it is remote from my car alarm and started to push on it in order to find which one of parked nearby car it was. I have no car and it was remote from the system Raskat, and I have clearly said this to him, but he has not listened to me, and told me to be silent. And he pushed this button several time. It can be possible he has erased all information on purpose, in order to say that all evidences are all wiped off, or more likely due to stupidity.
This is all too good to make up …
]]>--
Once known as Ethereal (was that “ether eel” or “eth eer eal”?), the best network protocol analyser in the world has finally made it to version 1.0!
Wireshark is an essential diagnostic tool, that should be on any hacker's machine. It runs on everything – Windows, Linux, OS X, Solaris, *BSD. It disassembles over 900 different protocols and has a comprehensive SNMP MIB library. For heavy lifting it has a built-in Lua interpreter, which can be used for both taps and dissectors. If you own the private keys, Wireshark will decode your SSL transactions too … http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark explains some more.
Enjoy!
]]>--
And another great Open Source project gets upgraded just before April begins!
OpenSSH 4.9 will now chroot sshd when asked, and also provides a bunch of new useful options for the sftp server. This version has tightened up on the non-execution of ~/.ssh/rc when ForceCommand is in place, as well as a number of bug fixups.
]]>--
Looks like the Chaos Computer Club is having fun. The German interior minister, Wolfgang Schauble, is a strong proponent of storing biometric data (specifically fingerprints) in things like the RFID chip in passports …
''Each individual's fingerprints are unique … it is possible to conduct biometric checks, which will also prevent authentic passports from being misused by unauthorized persons who happen to look like the person in the passport photo.''
A very confident statement, and not wholly untrue. But now anyone can have their own copy of Wolfgang's fingerprint (probably the right index finger), as the Chaos Computer Club have published it in the latest issue of Die Datenschleuder. Not only is the fingerprint printed on the page, it is also provided on a plastic foil that has been shown to defeat many of the commercial fingerprint readers specifically in use by the German passport offices.
Read more about this on The Register's article
Biometrics are a good and useful identification mechanism, but there is a very real danger in overreliance on the specificity of a biometric item. How about those Mercedes cars that require the owner's fingerprint before they start?
Police in Malaysia are hunting for members of a violent gang who chopped off a car owner's finger to get round the vehicle's hi-tech security system. http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm]]>
Storing Fingerprints
--
Here's a story that is doing the rounds at the moment. An Australian High School (Ku-ring-gai High in NSW) had bought in to a fingerprint scanning system to handle attendance monitoring in classes. It seems that the “optional” and “opt-in” aspects of this scheme had been badly communicated to the students, parents and staff, and the system has been withdrawn.
There has been a fair bit of reporting; the best seem to be short article from http://www.theaustralian.news.com.au/story/0,25197,23481514−5006784,00.html'>The Australian and a radio transcript from ABC AM
However, the implementation details of this system are not terribly unique, so I won't waste much time on them. The bit I found interesting was that the system makes a big point of not actually storing the pupils' fingerprints.
Wow. A fingerprint reading system that doesn't store fingerprints?
I heard a statement read on my local radio station explaining this … I can't quite exactly from memory, but the general theme was that the scanner converts the fingerprint into a number, and the system stores that number. It doesn't store the fingerprint itself.
This is, of course, a basic description of what computers do with all the input data that they recieve. Everything is converted into a digital representation, it's all just 1s and 0s. So why tell us that? My first assumption was that the author of that statement was being breathtakingly arrogant, assuming that no-one would understand the explanation, but as it sounded computery and confident, it must be fine.
However, the ABC AM transcript provided a little more insight, from another school running the same system …
We've been trialling a system that generates, where students use their finger to sign on, on a scanner. And it is a version of a fingerprint. It generates a four-point shape, four-sided shape that generates a four-digit code that then recognises that student each time they put their finger on the scanner.
So the scanner input may well be the fingerprint, but it's output into the system is essentially a one-way 4-digit hash of the scan data. This is obviously going to be non-unique across any sizeable population of students, so there would have to be some other identification token in use, like “last name”.
But that's not the real privacy concern here. The concern is that anyone with access to the system (not simply the database) will be able to identify the owner of a fingerprint – or at least, get a small short-list of candidates. If the police have a fingerprint that they "suspect may have come from a pupil" (which means, they will just check anyway if the process is easy enough) all they need to do is generate the 4-digit hash of it, and then sweep the database for matches.
The concern for people with personal data in storage is to see how they can ensure it is only used in the disclosed situations it is intended for, and cannot be misused. The governments probably want to ensure that the data are available. A commercial vendor is more interested in making sure that the system just simply works for what it it sold for. Which influences do you think will most strongly affect the final systems?`
]]>Too much GPS on the Nissan GT-R
--
I don't think this is exactly fresh news, but it still has an interesting security angle.
The new Nissan GT-R Japanese model has a speed limiter that keeps the vehicle below 180 kph. It also has a GPS that tracks your location. If you drive your car to a racetrack that Nissan knows about, you are allowed to unlock the speed limiter so you can give the car a good thrashing … however, as soon as you have finished, you have to take your car to a Nissan “High Performance Centre” for an expensive safety check – otherwise your vehicle's warranty becomes void. See Damon Lavrinc's February 2008 post on autoblog.com for details.
As Bruce Schneier said recently :-
Security requires a particular mindset. Security professionals – at least the good ones – see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.
Steal the GT-R, take it to a racetrack and unlock the speed limiter. Then return the vehicle before it is missed, but cause damage that would be eligible for warranty return; then watch the owner suffer economic misery, because they didn't visit the “HPC” for the safety checkup after their "race meeting".
]]>Big numbers and DARPA …
--
This isn't strictly a Security topic, but the start of the chain of thought comes from DARPA, the Defense Advanced Research Projects Agency of the USA.
One of DARPA's current projects is creating insect cyborgs -- inserting interface electronics into early-stage insects, and keeping them stable throughout the metamorphosis stage.
The goal of the MEMS, inside the insects, will be to control the locomotion by obtaining motion trajectories either from GPS coordinates, or using RF, optical, ultrasonic signals based remote control.
My colleague Arthur said “Ah! That's why there are so many addresses in IPv6!”
It's not trivially easy to determine how many insects there are in the world – wikipedia didn't have a number on the Insects page, for example! However, from 42explore.com (googled for “number of insects”) comes the unsourced quote
Entomologists (scientists who study insects) estimate that the average number of insects for each square mile (2.6 square kilometers) of land equals the total number of people on the earth.
So, rough calculations – there are 6.7×10^9^ people, a land area of 1.5×10^8^ km^2^. 2.6×10^18^ insects. There are 3.4×10^38^ addresses in IPv6 … plenty for all the cyber-roaches!
]]>Airport Security is arbitrary and funny …
--
Here's a shockwave game picked up in a referral from Bruce Schneier's blog …
Due to enhanced security measures, passengers will not be permitted to wear SHIRTS through the security checkpoint
Your job is to process passengers, not allowing contraband through onto the aircraft, and not allowing the queue to get too long …
After careful security review, PUDDING is now allowed in carry-on baggage
Go ahead – keep us all safe!
]]>Automated exploit generation
--
Some interesting research from CMU – automatic exploit generation, based on observing the differences between an original and a patched executable.
The two inputs to the generator are the original program, and it's patched descendant. We don't know what the vulnerability was that caused the patch to be created; but the output is exploit code that can trigger the original vulnerability. Reasonably obviously, if we don't know what the vulnerability was, we can't automatically provide an attack payload, but you could do worse than just assume a stack smash, or just generate a variant for all current attack methods and see which ones work …
The overview page specfically discusses the way that Windows Update rolls out patches slowly around the world, giving plenty of time for an attacker to auto-generate exploits and point them at the later targets. The technique is general, however, and applies equally to anyone who issues updates, including the Linux world.
Of course, in the Linux world security patches are published with source code, so in theory all exploits are openly documented; but it still takes manual intervention to turn that code into an exploit, and that takes time. This automatic generation method is just as dangerous to Linux as it is to Microsoft …
]]>Hostile control of your computing environment
--
There is a sort of “standard paranoia” that a government is theoretically asking itself :- given that Microsoft is an American corporation, how can we trust our computing infrastructure if the American government and Microsoft conspire to “switch us off”?
Well, how could this be achieved? Let's have a look at some of the possible methods …
These three all rely on some form of covert channel to be in place. Whereas the data flow for this would have to be inbound to the organisation, the command flow could be the opposite. There is no way that the channel could be detected while in use; therefore your only detection opportunity is a complete code analysis, or very strict execution profiling. Both of these are pretty much impossible in a closed-source vendor situation.
If there is already a covert channel in place, you cannot prevent it from being triggered. Detecting the establishment of a covert channel within an update or patch is much more tractable, especially when looking at technologies such as the automated exploit generation research recently announced. However, detecting establishment within the install of an elective addition, such as “Office 2007”, would tend much further towards the impossible.
So, the basic answer to the question is “yes, you could be 'switched off'”. You may choose to doubt that the facility exists (I think that is the correct position to take, as even in security you should remember that malice isn't necessarily the prime mover), but you can't doubt that it is plausibly possible even with pre-existing resources.
Would you be any better off switching to an open-source solution, where you are capable of deep inspection of the source code that your infrastructure is built from? Well, yes – if you are capable of such a large software assurance task in the first place. If you aren't capable of such assurance, you could hope that “many eyes make bugs shallow” … but that is a very weak point at the best of times for this sort of work.
]]>Which Internet are you using?
--
Are you using the Internet that ICANN thinks you are?
Or are you using an Internet that is … slightly different?
Back in September 2003, VeriSign started up their Site Finder service, which redirected any unregistered queries in .com= and .net= to their advertising portal search website. Not only did this push VeriSign's website traffic up (from ~ 2500th place to the top 10, according to Alexa ), but it also broke the expected DNS behaviour as per RFCs, and damaged connectivity for anything using the Internet for non-website traffic (i.e. email, FTP, etc)
After strong industry pressure and formal communication from ICANN, the service was discontinued in October 2003. During that time, the Internet you were seeing was not the same as the Internet that ICANN expected you to see.
On February 24th 2008, Pakistan Telecom decided to block access to YouTube.com for its customers, by announcing a change to the network routing tables that should have affected only its own customers. However, the BGP announcement message was not blocked by their upstream ISP, and leaked out. It reconfigured pretty much all of the Internet within a minute, and took YouTube metwork administrators almost one and a half hours to regain control. The upstream ISP for Pakistan Telecom stopped their faulty announcements about 30 minutes after that.
During this time, people trying to access YouTube.com's website would have instead seen a Pakistan Telecom website. See http://www.ripe.net/news/study-youtube-hijacking.html for a nice description of the event.
The “L” Root DNS server (there are 13 root DNS servers on the Internet) was originally set up in a network owned by Bill Manning and later on control was passed to ICANN. When they took control they didn't change the IP address of the server (this isn't an easy task); but decided to do so in November 2007 (See a fuller description at The Register)
In order for this change to succeed, nearly every machine on the Internet needs to be updated, and there is no way that can happen quickly (or indeed, at all). So we know that some machines will continue to send requests to the old non-existant server; this is not a problem, as they will be able to retry the other servers almost immediately.
However, things are not completely clear-cut. Bill Manning (who owns the old address block) had set up some monitoring services, trying to see who was still accessing the old service (see http://www.caida.org/workshops/wide/0611/slides/manning-wide0611.pdf for some of his older research) and this was eventually noticed by other Internet technicians; but they didn't know why this had been done. An entry on the Renesys blog paints the picture of a hostile takeover of the old L server, and speculates about the type of damage that be caused by it.
So, in this case, there was no attack on the Internet – but the techniques used for legitimate research could easily be abused …
Do you know what your own ISP is doing to your Internet traffic? For home user services, it is increasingly unlikely that you are actually connected to “the Internet” at all, as they deploy transparent HTTP proxies (to cut down on upstream traffic), traffic shaping (to reduce the load from P2P software, or to damage competing VoIP services), and prevent outgoing SMTP (to reduce the impact of botnet infected user PCs).
This sort of segregation is often carried out without announcement, and can cause both actual service problems, and frustration on the part of technicians trying to fix them. But I suspect that it is the future of home connectivity – if you want real “raw” Internet, you will probably have to purchase it as a premium service.
]]>Examining the internal state of Windows
--
Very few people know how to get Microsoft Windows systems to tell you about their internal state in the same way that we are commonly used to in the Unix and Linux worlds. Here, via Bruce Schneier's blog is a nice set of articles from Ed Skoudis.
These discuss things such as the Windows Management Instrumentation Command-line (WMIC), which provides a great level of detail about running processes; tasklist, which fills in some of the information missing from WMIC like open DLLs; and the openfiles command, which is almost as useful as lsof, but not quite.
Of course, this is still windows. There's a large performance hit to using some of these, so don't get carried away …
]]>Lockdown OS X
--
Apple are now publishing a set of OS X Security Configuration Guides to help system administrators know how to get the most secure installations of OS X set up.
The Leopard (OS X 10.5) guide walks through things like :-
Verizon security breach report
--
An interesting report from Verizon's Business Risk Team, covering 4 years of forensic research on actual security breaches
“a post-mortem examination of over 500 security breach and data compromise engagements between 2004 and 2007”
“78% of the breaches we handled would have still occurred if systems had been 100% patched the instance a patch was available.”
“An example of omission would be policies being established and thought to be in place, but in fact were not. 49% of all cases involved some form of omission. 66% of all cases involved data the victim did not know existed, or, did not know was being stored where it was.”
http://www.verizonbusiness.com/resources/security/databreachreport.pdf
]]>Entry #1216349010
--
Problem: you want to pass data between systems, but want to guard against metadata or content exploits.
Example: users upload images, which you need to process.
Threat: Standard JPG library buffer overruns.
Solution: Air Gap
Example: Upload machine displays the uploaded image onto the screen. Application machine uses a webcam to scan/record the image. No metadata can be preserved.
]]>Implementing IP securely
--
I'm not quite sure how I found this report, but it's a good one.
“Security Assessment of the Internet Protocol” steps carefully and throughly through the Internet Protocol, pointing out real-world examples of problems that have arisen by not thinking through all the implications with a security hat on.
http://www.cpni.gov.uk/WhatsNew/3680.aspx is an Advisory from CSIRTUK summarising the report, and provising a link to the full document.
]]>Data recovery from ext3 filesystems
--
A nice article from SecurityFocus, discussing a good approach to using data carving tools to recover deleted files from a Linux ext3 filesystem, using e2fsprogs, sleuthkit and foremost.
http://www.securityfocus.com/infocus/1902
The ext3 FAQ tells us there there is no guaranteed method to recover deleted files from the filesystem; but Abe Getchell's article describes some useful techniques that will help you to search for the remains of your data.
A couple of points aren't made very clearly, however – if your ext3 filesystem is busy, your data will probably be overwritten before you have time to go looking for it. Abe's example is of a file lost from the sole partition of a machine (i.e. the default schema on Ubuntu, and probably other distributions), and if there is a log of logging going on you will have to act quickly. Shutting down to single-user mode would help; physically mounting the drive on another system (or booting from a LiveCD to do the recovery) would help even more. Given that you might not have the tools you need pre-installed, don't install them before looking for the deleted data!
The other point is that you'll be scanning through a very wide chunk of disk to look for the deleted file, and you will probably be finding lots of other files that had previously been deleted. Not too had if this is your own personal machine you're recovering from, but if this is a client machine, be very careful that you understand what type of access is appropriate, even to deleted files. Abe's suggestion of using a good library of checksums (such as those provided by Tripwire) is an excellent way of checking for a matched file without explicitly reading its contents.
]]>Don't trust wireless encryption …
--
I've been saying this for a long time now, so the recent announcement by Elcomsoft shouldn't actually catch anyone by surprise.
You should not trust wireless encryption!
Elcomsoft have managed a 100 times speedup in cracking WPA and WPA2, simply by leveraging the GPUs of Nvidia graphics cards, which are very powerful computation machines and found in a lot of PCs :-)
Now, at one level, this is only a small speedup. But it's one more nail in the coffin. When a WPA2 crack becomes fast enough to ice its way through your network in “trivial” time, how do you respond? Unless you're running a real OS on your wireless network devices (like OpenWRT or similar) where a software upgrade will probably suffice, most consumer devices are basically unsupported, and unfixable. You have to wait until a new unit comes out with a fixed firmware, and hand over $$$ … again. Or just run your network with known weakness, which is asking for trouble.
My basic advice is to run your wireless network unencrypted; but run a software VPN over the top, for all machines. Something like OpenVPN does an excellent job of being straightforward to install and configure, and has great client-end tools. However, if you have to support more limited devices like iPhones, try IPSec (generally found in the classier “firewalls”, such as pfSense).
If you want to provide service for non-VPN users, run them in through a captive portal so you can present an AUP to them (so you can limit your liability against illicit use of your network) and rate limit them to something that won't break your usage caps, if you have them.
The basic premise of all this, is that when a vulnerability is discovered in a software-based VPN, there will be an upgrade available for your existing infrastructure within a short period of time. If there's a vulnerability in your hardware-based wireless router … you're stuck.
]]>Hunting for simple shellcode
--
Didier Stevens posted a reasonably simple challenge on his blog recently; find the message hidden in a simple all-black BMP file.
A simple disassembly using ndisasm (from the Ubuntu package nasm) finds a series of single-byte moves that often indicate text strings.
$ ndisadm -u picture-puzzle.bmp
...
000001D4 C645E455 mov byte [ebp-0x1c],0x55
000001D8 C645E572 mov byte [ebp-0x1b],0x72
000001DC C645E679 mov byte [ebp-0x1a],0x79
000001E0 C645E779 mov byte [ebp-0x19],0x79
000001E4 C645E862 mov byte [ebp-0x18],0x62
000001E8 C645E920 mov byte [ebp-0x17],0x20
...
In order to look at these bytes, we use a few of the standard unix/posix text processing commands. grep will select the target lines, cut will isolate the part of the line we want, sed will re-write the output into the format we want for printf, tr will be used to change the output from line-based to a single line. Yes, we could do all this in sed or perl, but it would be less readable; yes, it would be quicker, but this is hardly a big job.
So, grep and cut to get just the bytes …
$ ndisasm -u picture-puzzle.bmp | grep 'mov byte' | cut -d, -f2
...
0x55
0x72
0x79
0x79
0x62
0x20
...
Transform those bytes from the ‘0x..’ format to ‘\x..’ that printf wants …
$ ndisasm -u picture-puzzle.bmp | grep 'mov byte' | cut -d, -f2 | sed -e 's/^0x/\\x/'
...
\x55
\x72
\x79
\x79
\x62
\x20
...
Some of the bytes are nulls, generally indicating end-of-string. Add a second clause to the sed command, to replace them with LFs, making the output nicer.
$ ndisasm -u picture-puzzle.bmp | grep 'mov byte' | cut -d, -f2 | sed -e 's/^0x/\\x/; s/x0$/x0a/'
...
\x55
\x72
\x79
\x79
\x62
\x20
...
Now use tr to squeeze everything into one line, and pass the whole lot to printf. Now, printf doesn't like to be used as a filter, so I'll use the shell $(…) construct to pop the ndisadm output into printf.
$ printf $(ndisasm -u picture-puzzle.bmp | grep 'mov byte' | cut -d, -f2 | sed -e 's/^0x/\\x/; s/x0$/x0a/' | tr -d '\n')
Uryyb sebz OZC furyypbqr!
user32
MessageBoxA
OK, the first line is the only interesting one. The letter distribution makes it look like a simple alphabet substitution, and the most common is rot13 … but let's go one better, the caesar program (In Ubuntu bsdgames) will do a frequency analysis for us …
$ printf $(ndisasm -u picture-puzzle.bmp | grep 'mov byte' | cut -d, -f2 | sed -e 's/^0x/\\x/; s/x0$/x0a/' | tr -d '\n') | caesar
Hello from BMP shellcode!
hfre32
ZrffntrObkN
Now, real shellcode isn't going to be as easy to spot visually like this, but sometimes the obvious is a good place to look!
]]>Policy and Agreement updates, done right by LinkedIn
--
LinkedIn have updated their Privacy Policy and User Agreement. When you log in to their site, there is a banner telling you about the update, and providing a click-through to the new documents.
Given that many sites don't make much of an effort to tell you when a change has been made, this is good.
But when you're faced with a long legalese document that has purportedly been updated, how can you tell what's been changed? You don't happen to have a copy of the old documented stored somewhere, do you?
LinkedIn extend the arm of professionalism with a specific page called “summary of the changes” for each document. This presents in human-readable form a very good summary of what has actually changed … here's a snippet :-
In Section 2, we added a paragraph under the heading _"Forums/Chat/Blogs"_, in which we remind
you that if you post personally indentifiable information on a forum, chat or blog on LinkedIn,
other users can read and collect that information and may send you unsolicited messages.
In Section 3, we added a paragraph under the heading _"Closing Your Account"_, where we describe
the effects of closing your LinkedIn account and the uses of any information retained after such
a closure. We provide contact information for a request to remove your information entirely.
A new Section 4, entitled _"Your Obligations"_, was added. In this Section, we describe the
obligations of LinkedIn community members to each other and advise you of the effect of
violations.
This is a great example of how to communicate changes to dense documents; it's chatty, friendly, and informative. If we see more of this kind of thing, we'll be more able to assess complex agreements and policies, which is good for everyone.
]]>Responding to a successful attack
--
A nice article from Security Focus describing the aftermath and clean-up from a successful attack on a linux box.
Responding to a Brute Force SSH Attack; Jamie Riden 2008−12-03
]]>