Effective Airport Security

For the most part, airport security is more theatre than reality. There are a number of articles written elsewhere on this subject, Bruce Schneier being the most prominent, so this post is about an airport that I think has got it better than most.

I didn't pay much attention to Kolkata's airport security coming in, but the differences on the outbound was certainly notable. Most notable is that quite a number of the key decisions are performed by the army as opposed to contractors. This means that the mandate that they are working with is more aligned to the goals (anti terrorism, civilian safety) than the contracted security firms in other airports. It also probably means that the level of training for the security personnel is significantly higher, so they can make meaningful decisions instead of relying only on written instructions.

Only passengers are allowed into the airport terminal itself, which is somewhat strange in itself. This off course means that the airport is not a shopping mall, and all goodbyes have to be done kerbside. Entry into the terminal requires an air ticket and a passport. The process is slow, but each passenger is checked on the match (does the passport document match the traveller , and does the ticket match the traveller).

Like the US, each bag is then x-rayed, but this us before check in can take place.  Airlines cannot check in bags until it has gone through this process; and an appropriate tag has been attached. This was one of the places where there were civilians manning the apparatus, although I think it was still supervised by a soldier.

The passenger security clearance didn't require separate screening of liquids and gels; but the screening process itself was more thorough. Each passenger undergoes a pat down, bags seemed to be scanned with the passenger, and they do seem to pick up more details. They also tag each bag that has been screened. At boarding, there is a final round of checks to check whether the bag you are boarding with has been screened or not. 

It is a massive bureaucratic process, with checks and counter checks. It is certainly not fast, neither is it particularly welcoming. However, I think it is a lot less theatre - it feels more effective. It feels like every check had a reason and that it all ties up together. It is a small airport with a handful of flights, so I don't know whether the process can scale. But compared to other airport checks, it feels safer and better.

Initial Thoughts on Apple Pay

There is not much detail available on Apple Pay, announced at Apple's keynote yesterday - but my first thought, was that it resembles an update of Secure Electronic Transaction (SET). Like Apple Pay, SET theoretically allowed for a system where a payment transaction could be conducted without the merchant knowing the payment details and the bank knowing what was purchased. SET and other token based systems (such as a credential based payment system I developed in my PhD) haven't really taken off - although one can argue that Bitcoin is also an evolution of such a system.

The advantage Apple Pay does have, over all others before it, is the massive install base of iPhones and the Apple brand. As long as Apple itself does not fall prey to payment card breaches (and Apple Pay's design of keeping card data on the phone itself, mitigates this risk); Apple should have better success compared to previous attempts. Furthermore, if Apple Pay does work, extending the service to include non-credit card type transactions - such as integration with bank accounts - should not be a challenge either.

NSA's Operational Security Failures

In the May issue of the Communications of the ACM, Bob Toxen does a thorough examination of the operational security failures of the NSA in the Snowden leak. Snowden, as an administrator did have privileged access to many systems, but the scale of the leak, and the access control failures that allowed for the leak points to wide scale operational security failures. 

I do not agree with Bob Toxen on the ease of detecting smuggled USB sticks (in or out of the organisation) - modern USB drives are far easier to smuggle in, and it is even easier to smuggle in SD cards and the like. I do agree with his assessments on the scale of logical access control failures: administrators in any large organisation should certainly not have access to all systems; and users with higher classification accounts should require multi-factor authentication to access highly sensitive information. These are not new dangles processes or controls, and in fact the NSA helped write some of the key theory and practical guides in this area.

The learnings of the NSA's failures extends to most organisations. Unfortunately, unlike the NSA, most organisations do not have effectively unlimited funds at their disposal.

ITWeb Security Summit 2014

ITWeb Security Summit in 2009 was my first "industry" security conference, and after a long diet of academic security conferences, ITWeb was a huge let-down. There were some interesting talks - especially the key notes, but a lot of the others were a big waste of time. So much so, I did not bother going again until last year - and even then, it was for half a day.

This year was slightly different - I was presenting in the afternoon, and so took the opportunity to also attend the keynotes in the morning and some of the other topics in my own track. The organisation was a bit sloppy: for a conference in its ninth year, starting late due to traffic is inexcusable - rather start late given that traffic in Sandton at 8am is bad! Likewise, the opening remarks were a long ramble with no particular purpose - especially given that the conference was already behind schedule!

The first keynote  by Jacob Appelbaum's was definitely worth attending; covering a number of interesting topics related to surveillance. A bulk of it related to a primer of the NSA surveillance techniques, and especially on how these techniques are leveraged and integrated to provide a holistic end-to-end capability to intercept, inject and siphon data. His observations were scathing - not only of the US government but also of the general attitudes - and called the European/US/Canadian stance effectively "deep seated racism" - that they see themselves as superior, and thus it is ok to be doing mass surveillance on other people. I particularly enjoyed his argument, that it is not so much the NSA that is wrong - but the fact that this capability is provided for, and accepted. His view that even court authorised targeted surveillance without informing the target should outlawed is extreme - but was logically sound in the context provided. Sadly, he did not have much in the way of solution - and his approach of effectively open source (not necessarily commercially free) software and hardware will take a long time to really mature to be usable by the masses.

 Christopher Soghoian's keynote continued in a similar vein, focusing more on the, almost willing, corporate participation in the NSA programmes. Some of it, such as major service providers like Google and Yahoo not forcing SSL connections for email logins by default inadvertently helped programmes like those run by the NSA. Although he did comment on the business models employed - effectively targeted advertising - I think part of the issue, that these services are free to the user could lead to undue expectations - after all, you do get what you paid for.

Unfortunately, I can't make day 2 - but at least the keynotes were well worth attending. The track I was on was ok overall - a wide diversity in the level of content presented; and was generally well attended.

Online Trust and Jihadi Forums

Back at RSA 2012, Mikko Hypponen gave a very interesting talk on the IT platforms used by various terrorist groups - not only Islamists, but also white supremacists etc. I have seen sporadic articles since, but most are quite superficial without much detail.

A fairly lengthy academic research paper on trust in online forums, specifically Islamist Jihadi forums is therefore quite impressive - not only in the breadth of the article's coverage; but also in the author's conclusions.That trust will be difficult to achieve, especially in an online forum about terrorism, is not hard to fathom; but the fact that overall trust has declined and been supplanted by social media is harder to understand (although the period of research was before the NSA revelations).

The paper also doesn't discuss whether the issues of trust appear on other forums - both private and public on the Internet. The discussion points on why trust is difficult to achieve on the Internet would apply to all forms of Internet forums - not only Jihadists; and would these findings apply to forums for open source developers, car enthusiasts, media pirates and Hollywood gossip mongers?

That said, the paper is very interesting reading and covers a subject matter that is rarely discussed in any real level of detail. Even if it is ring fenced to a small Internet community - the methodology should be easy to transfer to other groups, and see if this is a general trend or not. If it is a general trend, there are interesting implications for telecommuting and perhaps even open source communities and other mostly digital communities.

Is it worth it?

In Bruce Shneier's TED talk from 2011, he comments that the critical question on security is "is the tradeoff worth it?". In the whole NSA debate, there has been much written and commented about the programmes, the programmes' impact on individuals' rights to privacy (both American and foreign citizens) and the ethics around such a programme.

However, the question on whether the NSA programme's trade-offs were actually worth it - as in a full cost benefit analysis, has only been tangentially discussed. In this regard, a paper by Mueller and Stewart, provides a good overview of the cost benefit analysis. Even, in the absense of numerical values, the benefits provided by the programme are actually quite low.

The paper is a vital discussion that has, so far been poorly addressed. More than anything else - surely a programme that costs billions, but has very little identifiable benefits, should be seen as fruitless expenditure. Given the US's current political stances on budget defecit - it almost seems like cutting the NSA programmes themselves will address the gap!

ZaCon 5

If ZACon 5 was a true representation of the security practitioners in South Africa, it would seem that there are next to no women - after all, only 1 lady in the audience of 100 plus gives a pretty skewed demographic. Perhaps this is a phenomenon more in the hacker community itself? Perhaps it is due to the fact that the event is on a Saturday? I have commented on diversity of ZACon before, and in other respects the audience was far more diversified, be it race, organisations or age - so, it seems like gender is the final frontier :) 

Organisationally, this was the best ZACon yet - better signage, better communication, up to date scheduling (even if it did run late, and the scheduling did changed a lot), AV and sound set-up etc. As Dominic commented, ZACon is growing up, and it seems to be sustainable footing - and this is a local security conference that deserves to continue. The content was also impressive, covering a variety of interests, although there was a strong "electronics" theme. 

Dimitry started off proceedings on the use of Markov chains to create more efficient password attacks. In principle, it is a great idea, but his actual demonstration and training data was did not make sense. Password complexity rules have almost ruled out the use of plain dictionary words as passwords, and thus the solution did not have the gravitas that it could have.

Jason presented the most interesting talk, on Mains Signalling. Basically, Mains Signalling is the use of signalling on the electrical grid, allowing for controlling of electrical systems. The technology is old, undocumented, and very topical with regards to the move to Demand Side Management, across the world. Through literally years of effort, and off the shelf components, Jason managed to decode some of the signal codes - including that of traffic lights, street lights and geysers. Given that there is absolutely no authentication or authorisation built into the system, anyone with the capability to send modulated signals on the electrical grid can cause havoc - and this is something that, to my knowledge, is not addressed as part of next generation grids. Yes, it is a far more local attack - but also far more economically damaging.

Jeremy ("Panda") presented an interesting investigation on the command and control servers for the Poison Ivy botnet (and two others). Through interception of communication, NMAP and tracking IP addresses and domain registration records; and managed to identify a number of additional domains and command and control servers. And amazingly, many command anc control servers are themselves vulnerable to many attacks, due to bad configuration and vulnerabilities within the Poison Ivy system. The approach will not work for all botnets, but this is certainly a good step forward in combating botnets.

Brazilian Marcos (studying at UJ) presented the most complex talk on detecting obfuscated obfuscation routines.  The use case is better detection of malware, but could also be used to attack software that uses obfuscation as a protection mechanism. Detecting and reversing good obfuscation is difficult and although the presentation is very much in initial stages; it does have good promise.

Rhodes MSc student Adam talked about his research on active honeypots. Traditional security technologies, like firewalls and anti-virus systems have high cost in detection, but low cost in carrying out enforcement. Conversely, honeypots have low cost in detection, but high cost in actually carrying out meaningful actions. The presentation was therefore on building a converged system - low cost of detection, and low cost of enforcement. In some respects it is a better IPS - and the approach is interesting; though probably not completely scalable. 

Dave from MWR's UK office gave the scariest talk of the day - on how it is easy to hijack ad networks to infiltrate ad-supported apps on mobile devices; most notably on Androids and jail broken iPhones. Ads are effectively webkit implementation within apps; but through bad design, vulnerable implementations, intentional wish to hijack data, bad sandboxing, and ads inhering permissions of the underlying apps, ad networks are effectively able to pull various types of data, or take actions such as sending messages or making calls. This means that the attacker can effectively hijack legitimate ads for their own purposes (since ad network traffic is often unencrypted) or in an easier (but potentially tractable) attack, launch an ad campaign that sets out to attack their targets. It was  truly fascinating insight into the problems with the current mobile advertising landscape and the lack of real incentives to address the problems.

Mark, also from MWR, but the SA office, gave an insightful overview of Control Area Networks (CAN), specifically in the cars. While there was some exploration on possible vulnerabilities, it was more of a discussion on reverse engineering. There are interesting avenues to pursue - especially remotely via avenues such as keyless entry or telemetry broadcasts for race cars. 

In the past year, Robert, started a conversation on building a data diode - or a one way transmitter of data. Considering the massive cost (some over 100's of thousands of Rands) of commercial systems, Robert's solution, costing less than R5000, is therefore an amazing hack; and one that works as advertised. 

The last talk was by Shcalk, on designing a low-gain directional Wi-Fi antenna; but was really mostly about 3D printing and house-4-hack. The 3D printer itself has got awards, and this is a good showcase of entrepreneurship. It was a good follow up to Roelof's (from Paterva) talk on the basic building blocks for building a successful business. It was a good way to close off a fascinating day.

Side Channel Attacks in the Cloud

I saw this paper (by Yinqian Zhang, Ari Juels, Michael K. Reiter and Thomas Ristenpart in ACM CCS 2012) earlier this year, but thought it was a very specific threat model. In a  one line summary - it is possible to recover private keys when they are being used within a virtual machine, through observations of the activity of the virtual machine from the host machine. It is a very complex attack, and requires at least host access for these observations, so my initial thoughts were that this attack could only be carried out by extremely skilled admins of a cloud hosting provider; but the complexity would probably mean that there was no realistic threat in that regard.

With the NSA revelations of the past few months, this is an interesting approach that could be taken by an agency (such as the NSA) to recover private keys from cloud providers, without getting actual access to the servers themselves. Given that PRISM does provide such access to hosts, it is not inconcievable that systems that are hosted on public cloud services such as Amazon's EC2 could be monitored. However, given the description of events relating to Lavabit, it is likely that this type of attack hasn't been operationalised yet - but remains interesting on what could be achieved.

NSA and Cryptography Attacks

There have been a few excellent articles on the NSA "breaking encryption", as reported in The Guardian and New York Times. In the talk 2 weeks ago Vint Cerf commented that we should use stronger keys - but as per the articles, key length may not be the issue at all. To summarise there are a few ways encryption can be broken:

1. Brute force the keys
2. Bugs in the software/hardware implementation
3. Bugs in the algorithm
4. Interception before encryption (in the case of network encryption specifically)
5. Steal the key

For point 1,  I think the maths of brute forcing the keys still hold out, we may be close - but I don't think we are there yet. But still, the advice of stronger keys always helps.

For point 2, there have been bugs in encryption libraries before and there are potentially still bugs in these libraries. Both Bruce Shneier and Matthew Green comment on the possibility that there are bugs in the Microsoft crypto library (which is closed source) and even Open SSL. Another possible attack vector, as noted by Ed Felten, is buggy components that make up crypto components, such as bad random number generators - which can then lead to weak keys etc. Faulty hardware (including deliberate backdoors) is also a possibility explored by Ed Felten.

For point 3, in most cases the maths in encryption algorithms seem to be right, and strong. But there have been cases were crypto algorithms have been broken (sometimes after years in operation) and cases where weak algorithms have been submitted for consideration in standards. I think most of the modern algorithms, such as AES are strong - but perhaps there are flaws that just haven't been published.

Point 4 raises an interesting attack vector, which I have seen being carried out by pentesters - basically a proxy service where a network call is intercepted at the initiation of a network session, and then network encryption is easily eavesdropped by the middle party. If the NSA is intercepting huge amount of traffic, it is possible to create such an attack - but automating this in a large scale is surely difficult?

The last point, of stealing keys - or rather forcing companies to hand over their keys under Prism is probably the easiest way for the NSA. There is some commentary on the possibility that the NSA had access to compromised keys at certificate authorities - which would assist this type.

Overall, I don't think there has been fundamental break in cryptography - but there has certainly been weak implementations followed by exploitation by the NSA.

 

The best form of defence is active defence

Over the past couple of years, Dave and I have had numerous discussions on various legal concepts around IT. As a noted privacy expert, and a IT professor at UNISA, the topics have been varied, and often straying to the esoteric.

Over the weekend, Dave and I recorded a podcast with Tony Olivier for the DiscussIT Pubcast on IT Security, covering the concept of active defence/hacking back. Dave and I previously presented the topic at a closed forum? And thought it would make it interesting to make it available to a wider audience. Tony is an excellent host, and managed to steer the discussion to additional points we had previously not covered. The podcast is a bit rough - it picks up a bit of the ambient noise, and is mostly unedited so all the umms and stutters are included for special effect :)

Odd Spam Mail

I usually go through my spam folder to check for incorrect identification; and once in a while I come across really weird emails. Weird in that, there is no obvious phishing attempt, attempt at selling me something or just plain malware. 

A few days ago, I came across this one - allegedly from the United Nations, looking for potential employees. At best it would be a CV harvest, which I suppose could be used for identity theft - but given the proliferation of job sites, this seems to be a strange way to harvest CVs. There are no attachments, and apart from being sent from a non UN email address (sent from a university in Bangladesh - possibly from a botnet); there isn't much going for this. Still rather strange ...

The Human Resources!

The United Nations Secretariat is looking for competent and motivated persons in all
fields of human studies and career, with a strong belief in its purpose and mandates,
who are willing to dedicate themselves to a rewarding international career in different
locations around the world.  The United Nations provides an opportunity to serve in a
dynamic, multicultural environment in a variety of jobs in the support of global
causes.

United Nations staff uphold the principles and core values of the Organization,
including integrity, professionalism, efficiency and respect for diversity.  The United
Nations welcomes applications from nationals of all Member States and strongly
encourages women to apply. Applicants with disabilities are considered by the United
Nations for employment under all types of contracts in full compliance with the United
Nations Charter. The United Nations offers a variety of ways to join its workforce. It
also offers university students opportunities to serve as interns.

We want people with integrity from all works of life. People who are fair, impartial,
honest and truthful. We want dynamic and adaptable persons who are not afraid to think
creatively, to be proactive, flexible and responsive. If you think you embody these
values then this is the place for you and your career. The UN Jobs is open to all
varieties of your human careers, so anyone can apply, but not anyone will be selected!
Applicants with satisfactory requirement as outlined in their curriculum Vitae will be
contacted directly by the relevant divisions for deployment.

In Global Service!

Mr. Steiner Cobla
Executive Director: United Nations Employment Unit
Email: dfid@careceo.com
Phone/fax: +44-7010-051-797
+44-703-187-7882

Great Phishing Email (target - Standard Bank)

I love great phishing emails - the ones where the phishers have made the effort to make the email look legitimate. Earlier this week, I got this one from Standard Bank - an email that actually strikes the right notes in many ways. In fact, it is very difficult to state that it is illegitimate, and I doubt most normal users would be able to spot it as a phishing email.

Firstly, I am ex-customer - so asking details for further screening is not a "bad" message. The grammar, the notes on the opening times of the customer contact centre, the disclaimers are all perfect. I did open the HTML attachment, but not on a browser - and even the stylesheets are perfect (using a legitimate Standard Bank stylesheet). They even have the right anti-phishing messages

"Important security alert! Standard Bank will never ask you to access internet banking through a link in an email. Don't fall victim to fraud!"

And lastly, all the HTML code seems to point to Standard Bank website - unless a domain itself is compromised, I couldn't spot an incorrect domain. But perhaps, I didn't look hard enough.

So, why do I think it is a phishing email?

1. The attachment asks for your ATM pin and Internet Banking password (to be reset)
2. Asks for "Zip Code"
3. Asks for other personal data, such as ID numbers
4. Asks for email password
5. And lastly, the email headers give it away

Received: from exchange.szlonghao.com ([113.98.251.13])
        by mx.google.com with ESMTPS id q66si27264684yhl.395.2013.07.29.03. 

48.06
        for 
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Mon, 29 Jul 2013 03:48:47 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning 

ibsupport@standardbank.co.za does not designate 113.98.251.13 as permitted 

sender) client-ip=113.98.251.13;

Amazing Phishing Email

I got this email, this morning - perfectly formed and almost indistinguisable (click for a larger size). Pity, I am not a customer ...

The headers, and specifically Gmail's processing makes interesting reading (highlight my own). I wonder why it is a classified as a "Softfail" when the rule is clearly violated ...

Return-Path: 
Received: from dc1.DFMCASTROL.com ([58.48.109.18])
      by mx.google.com with ESMTP id iv6si3639532pac.241.2013.05.01.15.45.30
      for ;
      Wed, 01 May 2013 15:45:36 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning  

ibsupport@standardbank.co.za does not designate 58.48.109.18 as permitted 
sender) 
client-ip=58.48.109.18; Authentication-Results: mx.google.com; spf=softfail 

(google.com: domain of transitioning 

ibsupport@standardbank.co.za does not designate 58.48.109.18 as permitted 

sender) smtp.mail=ibsupport@standardbank.co.za
Received: from User ([74.93.82.193]) by dc1.DFMCASTROL.com with Microsoft 

SMTPSVC(6.0.3790.4675);
  Thu, 2 May 2013 06:28:03 +0800
From: "Standard Bank"

Another Interesting Phishing Email

Earlier this week, there was an interesting mass phishing/spam email sent to a group mailing list, presumably from the "webmaster" of the webmail service. What I particularly like about it, is how legitimate it sounds, and the use of the ruse of applying better security (in this case, implementation of Sender Address Verification, anti-virus and encryption).The original address seems to be a California server on Comcast (although the IP address is apparently in Nigeria?); but the reply back is to an ISP in Chile.

Dear Subscriber,

Please, we are currently performing a database maintenance and upgrade on our webmail log for a better performance of our services to all subscribers. We are very much and indeed concerned about stopping the proliferation of spam. We have implemented a Sender's Address Verification (SAV) to ensure that you do not receive unwanted email(s) and to give you the assurance that your messages to message center have no chance of being filtered into junk email folder.

Also a DGTFX virus has been detected in your email account folder. Your email account has to be upgraded to our new and Secured DGTFX anti-virus 2013 version to prevent damages to our webmail log and files. To help us confirm and protect your account and our webmail log, please, fill the columns below and send back to us to validate your webmail account or your email account will have to be deactivated from our webmail log to avoid the spread of this virus.

Email Address:
Account Username:
Account Password:

You will be sent a password reset message in the next seven (7) working days after undergoing this process. We guarantee and assure you of more quality services at the end of this maintenance exercise and we apologize for the inconvenience this process might caused. Note also that your password will be encrypted with 1024-bit RSA keys for your password safety.

We sincerely apologize once again for this inconvenience and appreciate your help in this emergency situation.

Regards
---
----
Webmail Technical Team

Software Fragmentation

Software version fragmentation refers to the disparate versions of software installed across the user/install base. Fragmentation occurs primarily because the end user does not update or patch their applicable software to the latest version. Fragmentation has been in the popular news lately - firstly with regards to mobile operating systems (where Apple's iOS is probably the least fragmented mass used software platform, and Android seems to be heading the opposite direction); and secondly on Java virtual machines (which is actually under reported, as most reports only cover the PC based JVMs, and not the other JVMs out there, such as mobile JVM or embedded JVM; not to mention the non SUN/Oracle JVMs).

Not being on the latest version is not necessarily a problem - the recent JVM vulnerability was most widely exploited on the latest versions. Likewise, there are now very few exploited vulnerabilities on deprecated Microsoft operating systems, such as Windows 2000 - and there are many of those out there. But for the majority of cases, not being on the latest version implies that there are potentially vulnerabilities that can be exploited in the software.

While operating system and JVM fragmentation is discussed quire frequently, fragmentation in common applications is, I think, a bigger problem. Consider Adobe Acrobat Reader - the latest version is 11.0.2, but how many users are actually on this version? How many are on version 9 or earlier? In an investigation I did for a client earlier this year, less than 0.5% of the install base for either Adobe Reader or Adobe Flash were on the latest versions - and over 50% of the install base was at least 2 versions behind. Not to mention, that some really old versions of the software existed across the user base.

The problem with keeping software up-to date is that it seems to be incredible difficult on a large scale. It is not that there are no auto-updates - but there are lingering problems with dependencies (updating the JVM requires all applications that run on the JVM to also work, or integration of applications like Adobe Reader and Flash in other applications); and some users just don't update. There are other mitigations, such as Host IPS, but there is not a lot of widespread usage of these technologies. 

It seems that the platforms that have managed to get the least fragmentation, are the tightly controlled and integrated platforms - that connect to the Internet, and offer updates easily. Is the Apple, X-Box, Playstation model the way of the future?

The Implausability of Secrecy

Law professor Mark Fenster has an interesting article on the nature of secrecy, where he argues that the concept of secrecy (in Government) is not binary - and in fact, in most cases, secrecy is almost impossible to maintain (regardless of the legal frameworks). Using a diverse set of American examples; the article shows how endeavors to maintain secrecy is often self defeating - either through the pure weight of the volume of people who know the information and through disjointed laws and regulations that allow for part of secret information to "leak" out.

Although based on American examples and law, there are interesting parallels to South African government's own attempts at maintaining secrecy - be it the arms deal, or Nkandla or many other examples. Based on the article, the real danger of the Information Bill, is not that ministers can seemingly make anything secret - but rather, by its very nature, that information will leak out, and the enforcement of this law is almost impossible.

Oracle JRE Vulnerability and Security Miscommunication

There is a very dangerous bug in Oracle's Java Run Time Environment which enables an attacker to access data outside the JRE's sandbox environmnent. This is something that should be communicated about, and the patch should be applied, ASAP. These facts are undisputable.

However, some tech writers and commentators clearly don't understand the difference between the Java Run Time Environment and Java itself. The most notable article was this one in Forbes, which paints the language as the vulnerability; and not specifically the run time environment. In fact, it makes specific reference to "Java the language", and also pulls in all sorts of systems that have run time environments - although these environments do not necessarily have the vulnerability (since they are likely to be running a different version of the run time environment).In fact there are lots of different types of JREs, and not all of them are made by Oracle (with the notable ones being IBM and the open source OpenJDK project).

To be fair, for most consumers, there is little to distinguish between a JRE and Java the language. I think that there is a red herring in referring to all the possible installations of Java instead of where the problem actually is. There are some great guides on how to see if you are affected and how to fix it; such as this one by Krebs (although he also refers sometimes to the language and not the JRE).

NIST CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0422

Oracle: http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html

Wireless-G Account Issue/Security

Nashua-Mobile recently launched an uncapped WiFi service with Wireless-G in South Africa. The registration process was a bit hazy - with Nashua Mobile not knowing the process itself; but once that was sorted, the rest of the registration process was pretty smooth; although still quite convoluted!

When it came to logging on though; it was a damn pain. For some reason my login just didn't work. After a few attempts over a few days, I have up and called the help desk. While friendly and enthusiastic, they recommended a few setting changes to my iPhone. Instead, I tried using M's laptop instead; and had the same issues.

Thus, I decided to just reset the password and behold; it worked. It wasn't that the password was wrong (I could log in to my account); but rather it seems it was too long (15 characters) or it couldn't handle special characters. In fact there are a few security weaknesses beyond not accepting long passwords; they store the passwords in plain text and email and SMS the passwords to you. The helpdesk person also asked for the password so that they can "try" to log on!

I will send through a note to them; let's see what comes out!

Good Phishing Email

I like coming across really good phishing emails; primarily because I try to think on how to actually identify the email correctly. This morning, I got the following, reputedly from ABSA bank:

Your registeration with us has been cancelled due to our new terms and conditions, please read below to view how to re-register or visit your branch

Read Here

 It had all the hallmarks. Let's start with the sender, sent from a legitimately sounding address "absamail.co.za", which was not detected by Google as a bad domain. The mail relay is "Vodamail", which is somewhat suspicious - but Vodacom's ISP does have a large set of corporate customers, so a Bank is not too surprising. And lastly, all the sending address (196.11.146.165) seems to be a South African IP range. I looked on some registration records, but couldn't get much beyond the hosting ISP.

Aside from the sender details, the text itself is short and sweet; and even has a friendly "visit your branch", to give it some credibility. And for the "Read Here" bit, I didn't get a URL overlay (although I can't find any direct bugs; other than a misplaced "HREF=3D", which is apparently a MIME encoding component (from a casual Google search).

The URL has off course nothing to do with ABSA, and is hosted in Romania. I assume it has a drive by download and other nice things - I didn't go and check.

Aladdin - Password on a USB Stick

When Alvin first showed me his prototype for Aladdin in London 2 months back; I was a bit sceptical - and asked the question everyone seems to be asking - what if you lose it? It is a good question - but that is not what Aladdin is trying to solve - it is trying to solve a bigger problem - trying to remember, ever increasing numbers, of complex set of random alpha-numeric characters we call passwords. It is a far cry from Ali Baba, when all that was needed is "Open Sesame" (which incidentally is quite a strong password). 

The genius in Aladdin is that it works on almost any device that recognises USB keyboards. It generates and stores a set of randomly generated alpha-numeric characters;  and combining the key with another key or some input of your own (effectively salting the password) makes it a very versatile device for managing passwords. 

I think it is a brilliant concept; and one worth supporting. In corporates I have had exposure to; password management is a significant cost in IT; and this is a very neat concept in managing passwords. The problem of losing the devices remain with two exploits that come to mind - using the key itself to access systems (which can be addressed through some salting techniques) or resetting the affected passwords themselves. But for the normal user, I think these threats are compensated by the benefits of having a simple way to have strong secure passwords.

I think it's a worthwhile project; and I hope it gets full funding. I have ordered mine :)

Project Link on indiegogo: http://www.indiegogo.com/aladdin-key