Make IT Easy launch another web site developed for Springvale Sewing Sales and Service. They are a family owned business that was established in 1983 by the late Peter Stavrou. Originally located behind the Springvale Post Office, they have since moved to 184 Springvale Road, Springvale a couple of doors up from the Free Burma Cafe located on the corner of Springvale Road and Newcomen Road in Springvale. They buy, sell, service and repair all available makes of sewing machines including Singer, Pfaff, Juki, Toyota, Brother, Mitsubishi, Yamato, and many more brand names. Read more about their story here.
Make IT Easy helps non-profit organisation against toxic waste dumping in the south eastern suburbs of Melbourne launch their web site. Residents Against Toxic Waste In the South East (or RATWISE as they are otherwise known) was incorporated in 1999 and consists of residents from the cities of Greater Dandenong and Casey concerned about the management of hazardous waste and, specifically, the location of industries that produce and treat this waste. They are of the opinion that these industries should be located at least 2km from where people live in order to protect them from incidents which could see the release of toxic material into the air.
Although the web site is still under construction, it now features full web blogging capabilities which feeds through to their Facebook page via RSS. Please help us by supporting them on Facebook.
To visit their web site, click here.
Most of you have probably heard by now about the Heartbleed Bug that has breached the heart of network security across the internet. The vulnerability, discovered by a team of security engineers from Codenomicon Defensics, affects encryption technology that protects online accounts for emails, instant messaging, and a wide range of electronic commerce such as internet banking.
The flaw is in the open source implementation of SLL, the encryption standard used by a majority of sites on the internet to provide a secure way of transmitting sensitive data via email or instant messaging. Essentially, the encryption standard works by allowing two parties to authenticate and establish a session key that is used to cryptographically protect the remainder of the session. It does so by using a reliable stream service provided by TCP (that is, the network transport layer), which it partitions into records with headers and cryptographic content.
SSL (Secure Sockets Layer) version 2 was originally deployed in Netscape Navigator by Netscape in 1995 (version 1 was never deployed). Microsoft improved version 2 of SSL (or SSLv2 for short) by fixing some security problems, and introduced a similar protocol known as Private Communications Technology (PCT). Netscape then substantially overhauled the protocol as SSLv3 in 1996.
The Internet Engineering Task Force (IETF), realizing it was bad for the industry to have three similar, but incompatible, protocols, introduced a fourth similar but incompatible protocol called Transport Layer Security (TLS). The differences between this protocol and SSLv3 were not dramatic, but significant enough to preclude interoperability between the two.
TLS tweaked the encryption algorithms for key expansion and authentication which, consequently, made it incompatible with SSLv3. TLS also mandated the unencumbered Diffie-Hellman key exchange (DH) or Digital Signature Algorithm (DSA) developed by the National Institute of Standards and Technology (NIST) as part of their Digital Signature Standard (or DSS as it was commonly known), rather than the RSA encryption algorithm (used by SSL) which was developed by Ron Rivest, Adi Shamir and Leonard Adleman at MIT.
Nevertheless, for historical reasons, and in order to avoid an extravagant or wasteful consumption of resources, TLSv1.0 was made backward compatible with SSLv3 and SSLv2, since all frequently shared the same connection ports. For example, the https protocol (that is, the HTTP protocol secured by either SSL or TLS) uses port 443 regardless of which security protocol is chosen. Furthermore, since TLSv1.0 and SSLv3 are very similar, supporting both was easy. All TLS versions were refined in March 2011, which phased out support for SSLv2 of the protocol. This, however, was not a sufficient enough reason to migrate many implementations away from the widely deployed SSLv3.
SSL/TLS Basic Protocol
In the basic protocol, if a client computer wishes to establish a connection with a server, for example to download email messages, it must first initiate contact with the server. The server responds by sending its certificate, which the client verifies and extracts from it the server’s public key. The client computer then selects a random number S from which the session keys will be computed, and sends it to the server encrypted using the server’s public key. The remainder of the session is then encrypted and integrity protected with those session keys.
Note that, as the session keys are derived from S, the client is able to authenticate the server since the server requires its private key in order to extract S. The server, however, is not able to authenticate the client unless, of course, it requests a username and password that is encrypted using the session keys. In theory, SSLv3 could be used for mutual authentication, and the protocol does allow for optional authentication by the client if it has a certificate and, is appropriate for the encryption scheme agreed to by both client and server. To this date, however, authentication is seldom mutual – that is, the client authenticates the server, but the server does not authenticate the client.
This, however, is not the vulnerability that was discovered. On the contrary, SLLv3 assumes that a session is relatively long-lived, and from it many short lived “connections” can be cheaply derived. This is also true for all versions of the TLS protocol. This is because they were designed to work with HTTP 1.0, which has a tendancy to open a lot of TCP connections between the same client and server.
The Heartbleed Bug
The vulnerability was introduced in the software implementation of SSLv3 in December 2011, and released in March 2012. Dubbed the Heartbleed bug, it exposes 64 kilobytes of memory from the server to the client or from the client to the server (whichever is trying to ascertain whether or not a connection or an active session still exists). For example, if the client attempts to ascertain whether or not an active session still exists with the server, the bug has the potential of exposing up to 64 kilobyes of server memory with every heartbeat request. Conversely so, if the server attempts to ascertain an active session with the client. This can happen if the session has been idle for a prescribed amount of time, and is a feature that has been added as an extension to the TLS protocol to keep connections alive without continuous data transfer.
This is achieved by sending a heartbeat request that can only be initiated (by the client or server) during an active session. The client or server (whichever receives the request) has the option of responding to the request with a heartbeat response message which, if sent, should contain an exact copy of the (arbitrary) data that was sent in the heartbeat request, and must not exceed 16 kilobytes.
To complicate matters, heartbeat requests are also used to establish connections between two peers (i.e. client and server) that minimises fragmentation of IP datagram records. Referred to as Path MTU Discovery (PMTUD), the process attempts to maximise the size of the transmission units (i.e. datagrams) by transmitting datagram records containing heartbeat requests of various lengths not to exceed 16 kilobytes. Note that, since this process does not require authentication, it is done prior to the SSL/TLS handshake (i.e. prior to encryption).
Either way, when a heartbeat request is received, and sending a heartbeat response is not prohibited, the receiver must send a corresponding heartbeat response message containing an exact copy of the payload (or message) in the heartbeat request. Unfortunately, a missing bounds check in the handling of the heartbeat, if exploited, can be used to return more than the 16 kilobyte limit specified by the protocol. Hence, the name of the bug, “heartbleed”.
According to Codemodicon, there is no 64 kilobyte limit to the attack – that limit only applies to a single heartbeat request. The attacker can keep requesting an arbitrary number of 64 kilobyte chunks of memory until enough secrets are exposed. For an active SSL session, this happens once per cycle of a prescribed time limit. When used to establish a session, however, the heartbeat request can be sent a number of times till an appropriate path that minimises fragmentation of datagram records is discovered.
What is being revealed?
Exploitation can allow an attacker to retrieve portions of sensitive data that is stored in the memory of the client or server at the time of the heartbeat request. This can include, but is not limited to, personal or financial details, private communications such as emails or instant messages, or any other documents worth protecting by encryption. It could also include details like the private or primary keys used in establishing a secure session!
In order to coordinate recovery from this bug, Codemonicon have classified the compromised secrets into four categories:
- primary key material
- secondary key material
- protected content
The following sections discuss the (security) impacts of each category, including methods/strategies on how to recover from them. It elaborates on those discussed on the heartbleed.com web site.
Compromised Primary Key Material
These are the private or primary keys used to establish a secure session. With them, attackers are able to decrypt any past and future traffic to and from the protected service, provided they (at least) capture the handshake messages that initiate those sessions. This is because the handshake signals, as noted earlier, contain the shared secret, S, between the client and server needed to encrypt/decrypt the remainder of the session. Trying to determine the shared secret is difficult since no efficient (classical) algorithm for computing general discrete logarithms (the complexity category that this problem is classified under) is known.
This, however, does not prevent the attacker from impersonating the protected service. That is, with the private or primary keys revealed, the attacker would be able to establish a shared secret between itself and the victim (typically a client), thereby tricking the peer (client or server) into revealing more personal/sensitive information.
Recovery from this sort of leak requires patching the vulnerability either by disabling the heartbeat extension, or updating the version of OpenSSL. Note that not all versions of OpenSSL contain this vulnerability. It also involves revoking the compromised keys and, reissuing and redistributing new keys. This is done by requesting a new X.509 certificate for each affected service from a Certificate Authority, examples of which include DigiCert, SSL.com and Thawte, just to name a few. All of this needs to be done by the owners of the affected service(s).
Compromised Secondary Key Material
This, for example, includes user credentials such as the user ID and passwords that access the service. While this may not seem like a real concern, especially if there are no credentials, personal details, files or documents worth protecting, it should be of real concern to (at least) those who choose the same user ID and password across many internet services. This is because of security breaches similar to those experienced by Facebook users when sophisticated attacks on Adobe’s network revealed between 38 to 150 million names, encrypted credit/debit card numbers, poorly secured passwords, expiration dates, and information relating to customer orders. Knowing that people too often use the same user ID (typically an email address) and passwords to access different website accounts resulted in many breaches of user accounts on social network sites like Facebook. More information can be found on Adobe’s Customer Alert site, and The Register online in the UK.
For this reason, it is strongly advised that subscribers of website accounts avoid using the same passwords (at least) to access different services on the internet. Resetting the password, however, may not be enough to protect against further breaches. On the contrary, unless the service provider has patched the leak and reissued new certificates, subscribers of the affected service are still susceptible, especially if private or primary key material has been exposed.
Recovery from this type leak, therefore, requires the owners of the service to first patch the vulnerability, and reissue new certificates according to the steps described above, prior to subscribers of the service resetting their passwords. As a precaution, all session keys and session cookies are considered compromised, and therefore should be invalidated or deleted by the subscriber according to the instructions provided by the affected service. As a further precaution, and to mitigate against similar breaches in the future, it is strongly recommended that subscribers of internet services also regularly change their passwords (at most) every 90 days.
Compromised Protected Content
This is the actual content handled by the vulnerable services. It can include, but is not limited to, personal or financial details, private communications such as emails or instant messages, or any other documents worth protecting by encryption. There is very little that one can do to mitigate against such a leak, except for contacting the service provider to determine whether or not they were affected, and to determine the likelihood and extent of what has been compromised.
Only owners of the service will be able to determine the extent and likelihood of what has been leaked since they are typically aware of the record structures used to store the data in memory. For example, instant message records consist of the fields for content type, metadata headers (examples of which include the To: and From: address fields) and the encapsulated MIME message body. In this case, the most that has been revealed are the (email) addresses and message content. Either way, the owners of the affected service should notify their customers accordingly.
Recovery from this type of leak entails invalidating and/or deleting all session keys and cookies (as above), and resetting the password only after X.509 certificates have been reissued. This, however, will only secure future communication with the affected service. Any previous interaction with the affected service should be considered compromised in the off chance it has been captured.
This includes all other details that have been exposed to the attacker. For example, this may contain technical details such as memory addresses and/or security measures taken to protect against buffer overflow attacks. In other words, depending on the computer architecture and/or operating system, this has the potential of allowing the attacker to inject malicious code into portions of the operating system kernel stored in memory, thereby enabling them to seize control of the affected system. This information, however, will lose its value when OpenSSL has been patched either by disabling the extension, or upgrading it to a fixed version. Therefore, the onus to rectify this problem is on the owner of the affected service(s).
There is no doubt that Codemonicon have discovered a very serious vulnerability in the open source software implementation of the RFC 6520 standard describing the TLS heartbeat extension for keeping active sessions alive without the need of continuously transmitting data. This is not to say that there is a flaw in the SSL/TLS protocol. On the contrary, not all versions of OpenSSL are affected by this vulnerability. It is clear that all implementations prior to the introduction of the hearbeat extension do not contain this vulnerability. This is why disabling the extension on affected versions of the software will resolve the problem. Furthermore, this does not mean that there is a flaw in the standard describing the TLS heartbeat extension. Version 1.0.1g of OpenSSL, which fixes the bug, does not contain the vulnerability.
How many internet/online services have been affected has yet to be determined, although there are already reports of some major Australian financial institutions such as GE Money recommending to their customers to change their password. Also, some major Australian retail websites such as those for the Myer Visa Card and Myer Card, as well as the website for the Coles Mastercard, also appeared to be vulnerable. For further details, read Aussie Sites affected by Hearbleed Bug on Yahoo 7 News.
The main concern about the Heartbleed Bug is that it does not leave any trace or evidence of a service being compromised. Therefore, statements issued by financial institutions claiming that they have “…no reason to believe that any customer data has been compromised”, is simply not true. The only true indicator that they would have is an integrity check on the data (which may take months to verify), and/or the number of customer complaints of the service (or a lack thereof) relating to inconsistencies or mismatches in their (financial) details. In their defense, however, one can argue the fact that many financial institutes terminate active sessions that have been idle for a prescribed period of time. This would imply that the heartbeat extension has been disabled by the service, and therfore exploitation of the bug is not possible. This is probably why other financial institutes which shall not be named are advising concerned customers that it is not necessary to change their internet banking passwords.
It seems that web services such as email, instant messaging and electronic commerce are not the only entities affected by the bug. According to Codemonicon and the 7 News article (above), it would appear that equipment such as routers, switches and firewalls, that connect homes and businesses to the internet could also be affected by the vulnerability. This is because of the firmware software driving these devices could also be using the version(s) of OpenSSL known to contain the vulnerability. This means that attackers could potentially exploit the bug in a similar manner to web services.
Although web services can be fixed relatively quickly by either disabling the heartbeat extension, or updating the software to a (fixed) secure version of OpenSSL, this is not so easily achieved on hardware devices. Device makers would have to check each product to determine whether or not it is affected by the bug, and update the firmware software accordingly. The onus then is on the end consumer to consult with the manufacturer and, if affected, download and install the firmware version containing the fix (if possible). Till then, attackers could continue exploiting the bug.
Vulnerabilities in software are discovered almost every day. One need only visit the MITRE website (who is the authority responsible for maintaining the Standard for Information Security Vulnerability Names) to see a whole list of them. Like any other software bug, some are easily fixed and deployed, while others require a workaround till the problem is solved. Classic examples include the vulnerabilities discovered in Java Runtime Environments affecting web browsers. One specific example includes that identified by CVE-2013-0422, which has the potential to impact the availability, integrity and confidentiality of the user’s system, according to Oracle.
Albeit not as serious as the one uncovered by the security engineers of Codemonicon, Oracle strongly recommended that customers apply the updates provided by the security alert that they had issued as soon as possible. The other alternatives are to disable the Java Runtime Environment under the web browsers’ options, enable it only for trusted web sites, or not install it at all.
Generally, it is left to the diligence/discretion of the consumer to keep up to date with the latest versions of the software to avoid exploitation of vulnerabilities discovered in older versions. The same principle applies to the versions of OpenSSL that contain the vulnerability. This, however, is no comfort to the majority that are/were indirectly affected. In this case, the best that they can do is avoid using the (online) service till a level of trust has been re-established.
Nevertheless, to secure against similar breaches in the future, it is always good practice to change or reset one’s password (at most) every 90 days. Some organisations force their employees to do it sooner. This, in all likelihood, has the potential to secure against any past traffic that could have been captured and deciphered from being used to fraudulently access online services. In all likelihood, and has the potential because of the weak passwords that are most commonly being selected; also because of the potential for attackers to exploit bugs (in the wild) that have not yet been discovered. Most importantly, because nothing is 100% bullet proof when it comes to computer security. The best that cryptologists can do is make the problem of deciphering the transmission of encrypted communication so difficult that it will take months if not years to crack. By then, the usefulness or practicality of the information uncovered would more than likely be obsolete.
In conclusion, one can only guess whether or not the Heartbleed bug has been exploited, and to what degree. The fact that it does not leave behind any distinct footprints does not provide the consumer with any degree of confidence for security or privacy. The fact that it has existed in OpenSSL implementations of modern operating systems for over two years makes it even more disturbing. What’s worse is that, now that the threat has been revealed, there’s a good chance that attackers will try to exploit the bug prior to it being fixed. This is especially true for affected hardware devices linked to the internet, since a solution to resolve the problem is not readily available.
Otherwise, this is a good opportunity for service providers affected by the bug to strengthen their security and renew the private or primary keys used to establish secure communication. Although this is a painful task, it prevents cyber criminals from further taking advantage of this bug. Resetting passwords on a regular basis, however, can help circumvent similar breaches in the future. Ultimately, the onus is on the consumer to keep up to date with the latest version of software to avoid exploitation of vulnerabilities discovered in earlier versions. This is especially true for OpenSSL. For those that are indirectly affected by the Hearbleed bug, however, the best that they can do is to avoid using the (online) service till a level of trust has been re-established.
As most of you know by now, Microsoft has announced (http://windows.microsoft.com/en-CA/windows/end-support-help) that technical assistance for Windows XP will end on the 8th April 2014, and the automatic updates that patch known security issues will no longer be available.
Furthermore, Microsoft will no longer be providing Microsoft Security Essentials for download. They will, however, provide antimalware signature updates for a limited time to those that have it installed.
How does this affect the average user still running Windows XP?
The computer will continue to function the way it always has. The biggest potential risk that the average user will face is that if a vulnerability is uncovered, Windows XP will not be able to cope with it, thereby leaving their PC vulnerable to harmful viruses, spyware, and other malicious software which can steal personal information.
What steps can be taken to secure a PC running Windows XP?
First and foremost, one should consider purchasing and/or upgrading their Internet Security software (as an alternative to Microsoft Security Essentials). This is a suite of software that defends the PC against intrusion and unauthorised use of resources, and is typically bundled in the form of Anti-Virus, Anti-Spy and Firewall software, which is available for purchase online through companies like Norton, McAfee, AVAST and AVG.
Be careful downloading the free or trial versions of these products, as they may only protect the PC against viruses (especially after the trial period of the software has expired). Ensure that this software is kept up to date, and that the vendors support Windows XP. In the case where they stop supporting Windows XP, one would need to consider an alternative solution.
Secondly, ensure that the PC is behind a firewall, whether it be one that is provided by software (e.g. the Internet Security suite of software mentioned above), or a router. The purpose of a firewall is to control incoming and outgoing network traffic by analysing the data packets, and determining whether or not they should be allowed through based on a predetermined set of rules. Essentially, it blocks unsolicited communications by other computers on the network.
The same could be said for plugins such as Adobe’s Flash Player, earlier versions of which have uncovered a vulnerability which could potentially allow an attacker to take control of an affected system. This is why it is always important to keep up to date with the latest releases. Ultimately, the only assurance against threats like this is to visit websites that are trusted and reputed.
One should also continue to use best practices when it comes to downloading software and reading email. Avoid downloading third party software containing embedded toolbars, as these typically contain malware. Also, do not open email attachments from unknown sources, nor provide any personal details when requested by unsolicited emails claiming to be from a financial institution.
How easy is it to upgrade to Windows 7 or Windows 8.1?
Unfortunately, one cannot simply upgrade from Windows XP to Windows 7 or Windows 8.1. Aside from the fact that some of the older computers do not have the capacity to cope with an upgrade, there are software limitations preventing a direct upgrade from Windows XP to Windows 7 (or Windows 8.1 for that matter). In this case a fresh install is required, meaning that all software and data on the hard drive, unless backed up, will be lost.
Unlike data, software cannot be copied back to the hard drive after a fresh install and expected to work. Therefore, one would have to rely on the installation disks that were either purchased or came bundled with the PC (presuming, of course, that they are compatible with Windows 7 or Windows 8.1). Fortunately, most Microsoft products are still supported under Windows 7 and Windows 8.1 (of course, depending on the Microsoft Support Lifecycle Policy for those products).
Assuming that a fresh install of Windows 7 or Windows 8.1 is successful, hardware limitations may further slow down the performance of the PC, especially after installing resource hungry applications like Anti-Virus and/or Anti-Spy software. Therefore, one would be forced to either increase the amount of RAM, hard disk space, or both.
Fortunately, the price of computers continues to drop, especially since tablets seem to be taking over the market place. If one is willing to settle for a new desktop computer, remember that there are a number of bargains out there with Windows 7 or Windows 8.1 preinstalled.
While Microsoft have announced that it will stop supporting Windows XP does not mean that it will cease to function. On the contrary, it will continue to serve many as it has done for so many years. Hopefully, by using the above discussion as a guideline, one can secure their PC and continue to enjoy running the applications in an environment that they have grown to trust.
We have finally got around to connecting the web site to our Twitter account. Please help us to expand our audience by following us on Twitter. Once again, your support is appreciated.
Now that the dust has settled from starting up a new business, the time has come to further improve the company web site. We have done so using WordPress. Doing so has allowed us to take advantage of the blogging capabilities of WordPress, which we have also linked to our Facebook page.
In the next coming weeks, further improvements will be made to the site, which will include linking it to our Twitter account. Suggestions on how we can improve the web site are welcome by either contacting us directly, via email, or leaving a reply comment to this post.
As always, please help us to expand our audience by either liking us on Facebook, or following us on Twitter. Your support is appreciated.