Dailies
- Caoine
- Echoica
- Jina Bolton
- Lifehacker
- Overclockers Australia
- RiskAnalys.is
- Rory.Blog
- Schneier on Security
- Security Catalyst Community
- Security Ripcord
- Securosis.com
- Slashdot
- Whirlpool
Photos
Categories
- Books
- Computers
- Family
- Forensics
- General
- GTD
- Movies
- Music
- Profession
- Security
- University and Studies
- Web Development
Monthly archives
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- December 2006
- June 2006
- May 2006
- April 2006
- March 2006
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- February 2005
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
- January 2004
- December 2003
- November 2003
- October 2003
- September 2003
- August 2003
- July 2003
- June 2003
- May 2003
- April 2003
- March 2003
- February 2003
- January 2003
- December 2002
- November 2002
- October 2002
Search
Surf Jacking
Just finished reading about Surf Jacking from Ronald van den Heetkamp (and Sandro Gauci and Mike Perry), the demonstration movie that Sandro published really set in stone how interesting this vulnerability is. Sandro’s whitepaper describes the attack in detail, the primary attack scenario being the following:
- Victim logs into the secure web service at https://somesecurebank.com/.
- The secure site issues a session cookie as the client logs in.
- While logged in, the victim opens a new browser window and goes to http://www.example.org/
- An attacker sitting on the same network is able to see the clear text traffic to www.example.org.
- The attacker sends back a “301 Moved Permanently” in response to the clear text traffic to www.example.org. The response contains the header “Location: http://somesecurebank.com/”, which makes it appear that www.example.org is sending the web browser to somesecurebank.com. Notice that the URL scheme is HTTP not HTTPS.
- The victim’s browser starts a new clear text connection to http://somesecurebank.com and sends an HTTP request containing cookie in the HTTP header in clear text
- The attacker sees this traffic and logs the cookie for later (ab)use.
The first thing I did after reading this paper was to check my online banking, and I was relieved to see that the session cookies sent by the server were set to “Encrypted Only”.
Posted by Christian
Posted in: Computers, Security, Web Development
No Comments »
11 August 2008
Two-Factor For All
…almost.
So, in the spirit of bringing ubiquitous two-factor authentication closer to the masses (because excuses are disappearing) I spent a few hours hacking together a Wordpress hack (plugin) that integrates Twitter’s direct message capabilities to provide a one time PIN when you log in to your Wordpress administration screen. The intent being that direct messages get sent to your mobile via SMS, hence SMS one time PIN generation, mimicking SMS PIN authentication as used by financial institutes.
Of course, by using this hack you introduce a number of dependencies, primarily that being Twitter’s service itself which doesn’t have a great track record, but also your mobile phone’s network. In addition, the fact that it is a hack, not a plugin, is also potentially a pitfall. The last issue is because I don’t actually know how to write a Wordpress plugin properly. Not for lack of trying, I can’t help it that one of the “pluggable” functions in Wordpress didn’t want to be overloaded. In fact, I’m not entirely sure that functions in version 2.6 can be overloaded(?).
I also have to admit that whilst the motivation is to introduce a second factor of authentication, such as a thing you know (your password) and a thing you have (your mobile phone), by using Twitter’s services you don’t actually need a mobile phone to get your PIN. So if you check your direct messages via the web interface, it’s actually a one-by-one factor authentication, not really two-factor, and we all know what 1 x 1 equals don’t we? But you get the point.
In regards to the good work done on the Phonefactor plugin I just want to comment that I was half way through this hack when I read about Phonefactor and it didn’t support calling Australia, so that meant I was out. The quality of their work is great though.
I’ll release the details soon..
Posted by Christian
Posted in: Computers, Profession, Security, Web Development
6 Comments »
4 August 2008
When Security Tools Go Bad
Noticed on milworm today PoC buffer overflows for both OllyDBG and ImpREC. This reminded me of a post I wrote last year about some vulnerabilities that were discovered in EnCase and the Sleuth Kit. These sorts of issues do get me thinking about how much, and how effectively, we verify the validity of the security tools we use.
At a forensic acquisition training course I attended recently, one of the items discussed was assuring and validating that the tools you use do not compromise the information you are acquiring. This is particularly important for chain of custody and tamper-proofing. You don’t want to use a particular piece of software, which claims to access a storage media without making any changes to it, only to discover that it has made minute changes. Or that a hardware device designed to prevent data being written to a hard-drive actually makes small changes to the drive itself.
This same principle applies to tools used for malware reverse engineering or software validation. You don’t want to find that the tools you’re using to try and determine if software is malicious, are exploitable by DLLs able to run foreign executables. If you aren’t careful with your testing environments, you may un-expectantly expose it to malware (in the bad way, not in the way that is controlled). This isn’t much of a problem if you run your reverse engineering tools in a virtualised environment, but if you don’t then you might find that you’ll have to spend some time rolling back or re-installing everything.
Being pragmatic of course, I don’t think anyone would expect you to be able to find the sorts of vulnerabilities as was found in this PoC. But sure, you’ll have to show some degree of rigour in validating your tools. Most of the time it will be sufficient to check for any current or previous vulnerabilities on security sites such as securityfocus, sans, securitytracker or milworm. Perhaps rigour around also means that you maintain an up-to-date tools list, including your licensing and version information. Perhaps you utilise Secunia’s software to ensure that all software is current.
I’m unsure how other people perform this process, or even if it’s necessary. Perhaps it’s only necessary in the forensic space. I’m not entirely sure. I’ve posted the question on the Security Catalyst Community so hopefully I’ll find out what other people think.
Posted by Christian
Posted in: Computers, Forensics, Security
No Comments »
9 July 2008
Mobile Phishing Gets Easier
So Telstra has been promoting and advertising the imminent release of software updates for a large number of Australian mobile phone users that will allow their phones to read Quick Response Codes (QR Codes). The idea being that these barcodes can be put in magazines, on posters, on your bills, anywhere and it’s trivial for you to read the barcode with your mobile phone and be redirected to a website. In fact not just browse to a site, but save a contact, start an SMS or even call a number.
A colleague of mine at work has an N95 and he quickly discovered that his phone already had the software installed. Within minutes he was firing up the scanner at barcodes and to our surprise the technology appeared to work great. In fact, due to QR Codes being open (i.e. the specification is in the open) he was quickly creating his own barcodes. Think a physical, digital business card that can be instantly understood by your mobile phone.
The Problem
I’ve already started to hear some people commenting that perhaps this will be a great avenue for potential scammers to make mobile phone users visit sites that perhaps they don’t want to. Consider the scenario where you’re sitting at your bus stop and on the billboard next to you is a poster for the next upcoming movie release, and in the corner of the poster is a QR Code. Imagine you fire up your phone, point it at the code and click “Go”. The next thing you know your mobile phone is at a malicious website downloading a specially crafted piece of mobile malware.
I can see a couple of similarities between these QR Codes and URL shortening services such as tinyurl.com. Both offer a method to abstract and simplify a method to access more complicated information. Both don’t easily appear to disclose what they are hiding until perhaps it is too late. There has already been a number of people discussing the potential risks of these URL shortening services (one quick example is over from RISKS). I believe that these risks map almost one to one to QR Codes and automatic software on your mobile phone.
What next?
As these QR Codes become more ubiquitous maybe we’ll start seeing more people plastering phishing QR Code stickers over publicly exposed QR codes (Quishing? *erk* Someone shoot me). Maybe by making it easier for people to access mobile content we’ll see a spike in malicious mobile code. Maybe we’ll start to see an increase in bills which can be paid via your mobile phone, which in itself includes a whole host of risks.
Or maybe it will all just fizzle?
Posted by Christian
Posted in: Computers, General, Profession, Security
1 Comment »
8 July 2008
Reverse Engineering Web Applications
Was having a discussion at work the other day with a colleague drawing parallels between current web application security/penetration testing and reverse engineering. I believe the comment was initially driven from the fact that a lot of the web app pen testing that we had been doing recently involved a large amount of client-side code (thanks a lot web two dot oh!), and that we had spent quite some time dissecting javascript trying to understand logic flows, and underlying service calls.
At first I was apprehensive about agreeing with him, immediately in my mind I was seeing a one-to-one relationship between reverse engineering and binary executable disassembly. I was thinking of reverse engineering as the process of running up a compiled, binary executable in something like IDA Pro, to map out how the executable functioned, or even the concept of network sniffing to understand a network protocol.
Of course, the more we discussed it, the more it started to make sense that perhaps web app sec testing was like reverse engineering. In the instance of the web application, we were actively trying to get a higher level understanding of what the application was doing, and how all its inter-related pieces functioned, trying to understand the relationship between the multiple frames, javascript files and functions, and of course the remote service calls. But there was still something that was making me differentiate between the two, and it came to me a few days later. (well one possible answer).
The difference being the goal of reverse engineering compared to web app sec testing. I was seeing web application security assessments as trying to uncover vulnerabilities, then using exploitation of the vulnerabilities to try and gain access to information or resources they shouldn’t be able to. (Tangent: Great couple of articles from Gnucitizen and Spylogic on the differences between Tiger Team Operations and Penetration Testing.) Whilst, in my limited understanding of reverse engineering, reverse engineering was more about ensuring that an executable wasn’t doing anything suspicious. More like malware reverse engineering, as opposed to traditional reverse engineering.
After reading the wiki about reverse engineering it become a lot clearer why they seemed to be related and yet different, even the term reverse engineering itself carries a degree of ambiguity. One of the quotes that wiki had that stuck out was “going backwards through the development cycle“, this term made a lot of sense with regards to the goal of reverse engineering, and even playing a small part in the goal of a pen test. And this is where I draw my twisted tale to its conclusion (or my conclusion from this twisted tale?).
Whilst the goals between reverse engineering and web application security penetration testing are quite different, most web app pen tests will include a component of reverse engineering to try and document and abstract what the application is doing. This is particularly the case due to the paradigm shift occurring at the moment with a lot of web apps pushing logic out to the client. So whilst a web app security test isn’t strictly reverse engineering, I think a lot of the same skills are used at different times.
Posted by Christian
Posted in: Computers, Profession, Security, Web Development
1 Comment »
7 July 2008
No Excuses
If Blizzard is able to offer One Time Password Tokens for a MMORPG platform, then there is no longer a reason why your financial institute doesn’t offer the same. Be it fat tokens or SMS one-time text.
I’ve had a couple of conversations about what happens when the baseline for user authentication is reset. I believe in the next year or so that milestone will be crossed, where the majority of online systems which provide access to PII or finance data will have either authentication-level, or even transaction-level, second factor authentication/authorisation.
For the baddies, this means that their modus operandi will have to evolve as well, and perhaps we’ll see an increase in sophisticated, real-time phishing sites, or smarter and targeted malware or man-in-the-middle-ware. There’s just too much money and information out there for the stealing, so I can’t see them simply packing up their bags and calling it quits. It’ll be interesting to see what happens next.
Posted by Christian
Posted in: Computers, Profession, Security, Web Development
2 Comments »
29 June 2008
Telstra Malware at AusCERT and the Security Equals ‘No’ Dilemma
The past couple of weeks have been an absolute rollercoaster. Last week we had a fairly hectic one with a number of our guys attending AusCERT, and then this week was a combination of busy work and getting ill. I find making the decision to call in sick to be one of the more difficult decisions I have to make. Am I actually sick enough not to go to work? Will I make myself much sicker if I just muscle through it? Will I make other people sick? I’m always of two minds with this issue. This instance was probably a bit easier, as the Tuesday night I was waking up every hour or so with head and body aches and so making the call on the Wednesday was really simple.
One of the interesting items that came out of AusCERT that had us all talking, and scratching our heads wondering why popular press weren’t getting into it, was the news that Telstra accidentally distributed malware on USB thumb drives (and here) they were handing out. I guess popular media has more important things to talk about. I know it certainly makes you question whether or not you’d want to use them for security services. Of course, I understand that chances are this was a sales/marketing mistake and so doesn’t necessarily highlight the professionalism of the Telstra security folk.
Another interesting entry I read this week (or was it last week?.. my memories still a little shattered from the cold/flu) was Kees Leune’s post on Never say ‘no’. Kees talks about the all too common situation where security people are seen as the ‘no’ people (thought police, policy nazis, project killers, whatever). More often than not this is actually a perception problem. If the security person is doing their job right they should not be saying no, they should be identifying and highlighting risk. It’s the owners of the risk who are the people who are saying no, not the people identifying the risk. Usually risk assessors are positioned in such a way that they can’t even own a risk, so for them to be saying no would imply some break in the risk management framework.
I can definitely relate to this problem, and further so believe that once your department has developed that reputation it is a very difficult thing to change it. It’s not just a name change that will fix it, it’s almost an entire culture change that has to occur. I’m not completely sure I understand the answer to the problem, it falls into the bucket of ‘you just have to keep on working hard at it.’
Posted by Christian
Posted in: Computers, Profession, Security
No Comments »
30 May 2008
The Power of Design to Fight Crime
Just read this article over on core77 summarising an event held by the UK Design Council which collected forty leading technology designers and manufacturers plus a group of young people to discuss “new ways of harnessing the power of design to protect young people from crime - particularly theft of ‘hot products’ like mobile phones and MP3 players.” This event was conceived after the Design Council released some stats that show that the majority of 11-16 year olds in England carry a gadget with them at some point and that one in eight have been the victim of ‘hot product’ theft in the past three years. I believe ‘hot product’ theft is where the product is stolen from them whilst they’re still using it, such as on the mobile (cell) phone, or listening to an iPod.
Core77’s excerpt provides the most concise overview:
The focus is on generating innovative design briefs which offer a clear business opportunity for manufacturers who will be encouraged to develop them into the next generation of crime-safe gadgets. [...] Home Secretary Jacqui Smith said:
“I am delighted that so many of our best designers have contributed their time and expertise to today’s event and I look forward to seeing genuinely new and commercially viable products flow from it. The role that good design can play in cutting crime is well established but success depends on effective partnerships between Government, the police and the design industry.”
At first I didn’t quite understand what they meant by utilising “design” to prevent crime, believing that it was more centered on architecture, such as developing city spaces which demote crime. But after skimming this article it started to make sense. Richard Farson explains this concept by discussing the power of design:
Design achieves its power because it can create situations, and a situation is more determining of what people will actually do than is personality, character, habit, genetics, unconscious motives or any other aspect of our individual makeup. Nobody smokes in church, no matter how addicted.
…
Recently, the design disciplines have received research attention indicating that the physical environments designers create may have positive effects never before realized, potentially reducing all of the measures of despair. For example, studies show that if children grow up in a home designed to permit a view of greenery, they are less likely to turn to addiction and crime and more likely to achieve in school. Such thoughtfully designed environments can reduce the frequency of divorce and other signs of family dysfunction. It is no longer far-fetched to predict that intelligent design will help prevent mental and physical illness, child abuse and suicide.
Richard also explains that this design power also has a ‘dark side’:
Because it is so powerful, design also has a dark underside. If mindlessly conceived or corrupted, design can produce depressing consequences. The design of cities that plan giant shopping centers can erode traditional communities by forcing neighborhood businesses to close. Massive highway construction can divide and rupture a neighborhood. Kafkaesque office designs of row after row of monitored employees, or maze-like cubicles, can dehumanize. Graphic designs in advertising can be dangerously misleading, promoting unhealthy products or unworthy candidates. Some designers think these bad designs greatly outnumber the good ones.
I believe that a lot of these principles can map to web application security principles as well. At a high level it’s easy to relate the concept that mindlessly conceived or corrupted design of a web application will have an impact upon how many vulnerabilities it may have. In addition, the design of a web application, either be through its presentation layer, or more subtly through the way that business logic is represented in HTML (for example) can also create a false pretense that the system is secure. A good example is a traditional design firm promoting the security of their applications because they utilise SSL/TLS to encrypt the site, when employing SSL may be good for protecting data in transit, but doesn’t help prevent vulnerabilities exposed through XSS or CSRF.
On a deeper level, such as taking into account what the Internet provides for crime, I think the principles still align as well. If it wasn’t trivial to perpetrate crime remotely, anonymously and on such a large scale would it be so prevalent? Probably not. The Internet was not initially designed with a security hat on so of course it’s insecure at a low level.
Posted by Christian
Posted in: Computers, Security, Web Development
No Comments »
18 May 2008
Forensic Acquisition Training
I was fortunate enough to attend a two-day crash course on forensic image acquisition last week. The trainer was Phillip Russo from CIA Solutions, whilst a local Perth boy he spends a huge amount of his time running training elsewhere around the world. The course covered the basics of forensic acquisition, traditional investigation skills and computer crime, integrity tools (hashing), checklists, chain of custody, to shutdown or not shutdown, dead versus live forensics, media types, write blockers (software versus hardware), imaging and image types, and a summary of tools.
One of the highlights for me personally was having an opportunity to discuss more of the court room and legal aspects of presenting evidence, as Phillip had a history of presenting in court in a number of different contexts. I think it was through his experience that he had methods of dissecting fairly difficult concepts, so much so that I imagine even the mums and dads out there could understand. A good example is the concept of file slack. Whilst I may have a fairly good understanding of what file slack is, trying to explain this to people who don’t have any history or experience with computer forensics, even savvy IT people, can be a fairly daunting task. Combine this with trying to explain how hard drives, partitions and file systems work and you certainly have a fairly large task in front of you.
Another highlight was the opportunity, not only to get hands on with hardware write blockers and AccessData’s FTK Imager, but also to combine this with real life scenarios and the process of documentation. Due to studying computer forensics at University I was fairly comfortable with the technical process of data acquisition, but combining this with the realistic process of documenting the acquisition, including chain of custody forms, was quite interesting and surprisingly difficult to do effectively.
The question was raised, whether or not if all the forms were transitioned into digital form, whether that would still be admissible in court. Whilst the concept could not be completely discounted, the fact that such records are not ‘tangible’ seemed to be quite an important factor for court room presentation. Judges and juries seem to have a better grasp of concepts when they can see the evidence in front of them. This certainly made sense to me, and obviously relates quite closely with the KISS principle. I think this also makes sense for this type of environment, probably more so than applying it to web application development for example, as you are already bombarding people with foreign and complex concepts, let alone trying to explain to them the principles of digital signatures of your ‘running sheet’, as opposed to your hand written notes.
Overall a worthwhile 2 days, and whilst it whetted my appetite for further training in forensic analysis, I’ll just have to leave that for another day.
Posted by Christian
Posted in: Computers, Forensics, Profession, Security
1 Comment »
6 May 2008
Don’s Windows Incident Response Script
Just had a quick play with Don’s Windows Incident Response Script and am very happy that someone else has put in the time and effort for something as useful as this, and then provided it for all. Some of the useful information it captures includes:
- User Account Information - Account name, Full name, SID, LocalAccount
- System Information - Hostname, manufacturer, OS Type, version, SP etc
- PreFetch File Information (this is AWESOME) - the metadata of about the last 128 programs that were executed
- Installed Software
- Windows Setup Log
- USBSTOR Registry Key
- Windows Firewall Exception List
- Log On and Off Events (if auditing is turned on of course)
- Event Logs
- Temp Internet Information
- Running Processes
- Active Network Connections (ahh netstat)
- Anti-malware logs (dependant on your AV vendor)
So yeah, go check it out.
Posted by Christian
Posted in: Computers, Forensics, Security
No Comments »
19 April 2008