One of the Australian websites belonging to global electronics giant LG has been hacked by a collective calling itself the Intra Web Security Exploit Team.
According to Asher Moses of the Sydney Morning Herald, the site, lge dot com dot au, was pwned over the weekend, and was still in embarrassing post-hack distress this morning:
(The BeWiz track is called TwistedWanted. I’m not sure if that’s a reference to Twisted Matrix, the event-driven networking engine written in Python, to UK indie music company Twisted Music, or something else. Listening to BeWiz’s whole track was a mission I was unwilling to accept.)
When the simulated attack is complete, the attackers announce, perhaps not without some justification:
It seems as though your website has been hacked.
How did we get past your security?
What security? 😉
The LGE site was taken off the air mid-afternoon Sydney time:
It’s back now, redirecting to an apparently-unsullied www.lg.com/au.
(Enjoy this video? Why not check out the SophosLabs YouTube channel?)
Don’t end up in this sort of situation. Being defaced is bad enough, but at least you can see what’s gone wrong and take action to fix it.
Most cybercrooks don’t seek publicity by advertising your insecurity. They take what they can get and deliberately avoid drawing attention to themselves. You might become aware of their intrusion only after your customers’ personal information has been sold on underground forums and used to commit fraud or identity theft.
For more information on securing your website, download the SophosLabs technical paper “Securing Websites”. In addition to advice on common attack techniques including SQL injection, the paper also discusses establishing a secure foundation for your site and how to deal with external service providers.
3 comments on “LG hacked – website defaced to show simulated intrusion”
Many companies could employ hackers to strengthen their security, I know some do. I believe what happened in this case was a good thing for LG Australia, How would LG Australia they know how secure they were if this didn't happen.
In Section 5 of the technical report, first bullet point of "Breaking the code" section, do you mean "Always *disable* global variables"?
Whoops. That's an error in the technical paper. We're in the process of revamping the paper – may take a week or two.
Thanks for getting in touch.