Details of the ZSE hacking. It happened twice and it was through Joomla

Posted by

On Saturday, we posted information revealing that the hacking of the ZSE website that happened last week was at the application level. We have since received more details of the hacking incident itself and it appears the ZSE website was used by the hackers to host viruses and a phishing website.

According to our source, the website itself runs on the Joomla content management system (CMS) with some custom PHP code used by the developers, Adept Solutions.

The ZSE website was apparently not only attacked once, but twice.

The first time, a virus file on the address ‘http://www.zse.co.zw/…/sexy/video_safadeza.com’ was discovered on 25 July 2011. Apparently, the virus was flushed out by the hosting company. The second infection was detected on 3 August and this time, using the administrator privileges, the attacker had planted a phishing site on the ZSE website. The phishing site was meant to fool unsuspecting customers into believing they were on a Brazilian bank website, the Santander Bank, and the planted website’s address was ‘http://www.zse.co.zw/www.santander1.com.br/’. The real Brazilian Santander Bank website address is www.santander.com.br

The ZSE website was taken down after the second compromise and still down.

advertisement

So far, it appears the attackers were not particularly interested in the ZSE website itself or any information it has, but just found it vulnerable enough to be used to host viruses and phishing sites. We imagine there are hundreds other local websites out there that are similarly unsecured and possibly compromised as well. The ZSE is just a high profile organization hence this being news.

There have been worse website hacking incidents in Zimbabwe, the notable one being that of a website belonging to Zimbabwe’s largest telecoms firm, Econet Wireless Zimbabwe. In December 2010, Econet’s broadband website was defaced by an individual apparently unhappy with the quality of services offered by the company.

29 Comments

  1. KuraiMGT says:

    This is outrageous, they and every other Zimbabwean website need to do better on web security. It dampens confidence of being secure in web solutions in the country. Developers are encouraged to raise their game

    1. ngth says:

      But as a customer are you repaired to raise your bill?   Secure development takes longer and costs more than script kiddie coding.

      A company like ZSE should have tendered a site and not gone with the cheapest option, would be interested to see what the tender process involved and the criteria on selection.

  2. ngth says:

    Thanks for the extra information, interesting to see we have reached the point were our interent in Zim is good enough that we are a viable target for hosting phishiing pages and viruses.

    One problem a developer faces is customer apathy, first developers have to fight over very low prices from inferior competition who do not want to put in the extra time to do a job securely (or lack the skills to do the work securely).  Secondly often these sites are fire and forget as in the developer makes a site which at the time was thought secure, but five years later it is hacked.  In the mean time the customer is not interested in spending the money on keeping the site upgraded.

    It is good to hear that at least the Hosting company has done its part in removing viruses and being as secure as they can be.

  3. kthaker says:

    phishing and identity theft are a very very serious problem…and i suppose that insecure websites provide a comfortable place for hosting these kind of sites.

    there is an anti-phishing website called http://www.phishtank.com which allows you to report suspected phishing emails/websites that you come across. this helps to identify and stop fraudulent sites from stealing peoples information.

    luckily, in Zimbabwe, because of how limited our online banks and payment systems are, there isnt a very big threat of identity theft here..but its definitely a different story overseas.

    1. BaDali says:

      not just “overseas”, over-borders as well.

  4. Solomon Kembo says:

    Ah its coz its a Joomla, come to Drupal ZSE.

  5. Raymond Swart says:

    Hahaha Solomon, not saying that Joomla is unhackable but in most cases we’ve found people put up a site and never update Joomla. This was more than likely the case. Drupal may be more secure but that is more likely cause no one knows how to use it? 

    The moral of the story is keep your setup’s up to date and make backups of your website. Unfortunately most business’s don’t think this is important until it’s too late.

    As for ZSE yes pay a little more than the cheapest rate in town with people who have a reputation and you’ll be a little more safer although not bullet proof.

  6. It was not the Joomla CMS at fault here, but the developers who did not secure and test their security. You cannot discredit the software but the builders of the software. I bet you they did not run the proper tests before they launched their website.

    Hacking happens, but it is how you recover and how you develop your website that matters. Whether Joomla, Mambo, Drupal, ASP, TYPO3, etc, you will still fight hackers.

    I also bet you that when this project was being done, it did not follow proper Systems Design methods, people just delved into coding without definition of the project or system structuring and planing.

  7. vince says:

    so joomla is really a security threat rite
    i thnk its coz of thirdy party plugins

    1. ngth says:

      The Joomla core (if kept patched up) is well written and secure (as secure as anything along those lines is going to be).  But yes most of the third party addons and custom components are very badly coded and allow easy security breaches.  One of the problems of such a system is the barrier to entry for the coder is very low, hence you get a lot of chaff with the wheat.  Its possible the breach at ZSE was an out of date joomla, a third party component or Adept’s code, I guess they wouldnt tell us that much though.

  8. Lon says:

    Some guys are already making money on this even, a seminar is going on in South Africa about the ZSE hACKING:
    http://www.isgafrica.org/blog/?p=977

    The basic lesson is: Secure your applications, design with the mind of a hacker whether you use Droopal or Joomla

  9. beginner says:

    can some help me clarify a few things.
    1. was the admin password for joomla cms weak or
    2. was the admin password for the hosting server weak

    i recently had a joomla site for my client hacked 
    the index.php file had been replaced. the answer i got from hosting company was it was a sql injection attack.
    is it possible. because i just replaced the index.php with a back and site was up again

    1. kthaker says:

      the fact that the attackers can manipulate files on your site, means that they have got access to your website from now on..either through the CMS, or via the server itself which has been compromised. In most cases, a competent hosting provider will be able to tell whether the entire server is a write-off, or if only a single site was hacked on that server. 

      Usually what happens on shared hosting servers, is that a single site gets hacked, then the attackers run scripts on the servers to replace all index.php/index.html files that it can locate. therefore showing that all the sites on the server have been hacked.. when realistically, only one site was hacked.

      SQL injection is a possible cause, however, there are many other ways to break into a website/server as well. the webhost should be able to give you exact and detailed information about the hack, and which files/modules on your server were used to get in (this is easy to get from server log files). if they cannot do that and rather give you a vague explanation of your site being a victim of SQL injection and not give any evidence (which can be found on the webserver logs), then most likely it was not your site that was broken into, but only had the index.php file changed by another hacked website that was hosted on that same server.

    2. ngth says:

      sql injection has nothing to do with knowing any admin passwords, to the site or the server.  It relies on not escaping special characters on a user input and that input being passed as sql to the database to be executed for example

      “; Drop Table tblUser; //

      However if you say they replaced the index.php then it would point to another problem or a misconfigured sql instance.  While it is possible for mysql to be told via sql to launch another application eg an ftp client and downloand and replace your index.php it really shouldnt have permission to (or at least your site’s mysql user shouldnt).   Either that or it was another attack eg using sql injection to get login details which matched the ftp details.

      If you are looking for answers in your case then you will need to get more details from the hosting provider.  But replacing the index.php and changing passwords will not protect you from sql injection you need to fix the insecure code.

      Or as kthaker pointed out it might not be your site at all, in which case consider changing hosts 😀

    3. Anonymous says:

      The fact of the matter is: if it is software- there is an exploit for it. Be it Joomla, WordPress, Drupal (Or Windows, Mac OS, Linux or BSD). Just that some platforms are more vulnerable than others.

      @ngth Wrong –  SQL injection has everything to do with admin passwords. It is typically used as the launching point of an attack. I would (hypothetically, of course) inject an SQL statement to display your table structure (to find out which table stores your passwords) as step 1. Step 2 would be to figure out what scheme the password are stored (plaintext? md5? using default salt?). Step 3 would be logging in as admin

  10. Art (The Idea Factory) says:

     

        @beginner, not sure where the weakness was, but in the security world always assume you have been compromised, because you probably have or are about to be. Always be in Disaster recovery preparedness mode. All the tips mentioned by the smart techies above, are notable and it could be both admin server and or the web CMS that had the weakness. It’s usually through the web apps that security of a system is compromised. I really agree with vince that plugins are possible security holes. The good thing about Opensource is that if a plugin is designed to be a backdoor entry into a system most notable developers will catch it in the code if they review the plugins that they are adding to their system. But most don’t’ because its all about completing the project and getting paid.  

    Here is the issue with the web! It exposes your services to a wide community instantly. I.E. this is not good news for the development company as no one would want to go with their solutions form here on, unless they up their game with some serious re-branding and a security focus in mind. So you could be in business overnight and out of business the following week. Take time to follow the development principles as mentioned by another poster, review logs regularly, and pay for some professional services. It will save you in the long run. Welcome to WEB 3.0+ 

  11. Fourwallsinaroom says:

    This is what happens when you use a template and do not lock it down.

  12. Guest says:

    alert(‘hello world’) 

  13. Anonymous says:

    had to get a paracetamol to finish reading what is being discussed here, well done Zimbos, we will make it

  14. Dev says:

    “Details of the ZSE hacking. It happened twice and it was through Joomla” It is very shallow to try and scare joomla users from using the CMS just because a joomla site has been hacked twice. The problem is not with the CMS but with the security measures applied by the hosting company and/or the developers.

    Please try and write reviews that are objective in future.

  15. Dev says:

    The title of your article is misleading. Joomla is not the cause of the hack, but a lack of securing the ZSE’s hosting platform or their website was the cause for the hacks. Your title implies that Joomla is not a secure CMS.

    1. Ahh, I get it. Sorry. I sincerely didn’t mean Joomla itself is not a secure platform. I assumed (incorrectly now it appears) that readers would be familiar with CMSes and they’d know open source CMS security is as good as its specific implementation strategy and not the technology itself. 

      The hacking could have been on any CMS. We’re on WordPress here at Techzim  and could easily suffer the same if we don’t patch up or don’t secure our inhouse developed extensions etc…or even if a hacker just gets ahead of us in this cat & mouse. In which case we’d title it “Details of the Techzim hacking. It happened 5 times and it was through WordPress”Thanks for the feedback.

  16. tinm@n says:

    I agree with Dev. When you say “done through Joomla” you imply that the hack was made possible or facilitated by Joomla. As though Joomla was the tool used to perform the hack. We know what you mean, but the semantics need a bit of correction

    1. thanks. See above response to @60736d8083b3078439a4762904ea330b:disqus 

  17. Anonymous says:

    Part of the problem is classifying the nature of the attacks which are happening … e.g. are they just ‘script kiddies’ out for some short term lulz, hacktivists trying to make a political point, or are they some sort of ‘advanced threat’? There’s an interesting article here for those interested: A new way of classifying hacking: evilness, impact, legality and complexity

  18. I like the way you create. Your design is very sleek and I appreciate studying your content. I’m advancing to the dental professional but will be returning later.

  19. Boosting says:

    I’d like to find out more? I’d want to find out more details.

Leave a Reply

Your email address will not be published.

css.php