Cross-Site Scripting (XSS) – A Real-World Example

June 14, 2008 – 7:56 AM

Cross-Site Scripting (XSS) is an attack that’s pretty basic to detect, pretty basic in execution, and you’d think that it would be rather simple to understand. Unfortunately this is apparently not the case. I won’t go into the details of Cross-Site Scripting because others have beat that to death – but rather I’m going to go through a little real-world exercise for you. I’m hiding the actual URL until the site owner either does something about it, or ignores this issue long-enough for me to disclose it on this blog.

First, I’ve been looking around and just doing non-invasive, non-malicious checks to see how wide-spread XSS is on some of the sites I use regularly. I came across one that made me think, and so I got a little creative and came up with a real-world use-case for this vulnerability, and how it can be executed and cause real damage.

Looking at the URL and I though – gee, I bet I can make it look like the user has to click to get results and send them somewhere malicious.

Read the rest of the story…

Vishing Attacks Increasing

June 13, 2008 – 9:02 AM

In recent months, Web site compromises have become the most prevalent problem that threatens Internet users from all over. While this trend continues to dominate today’s security issues, let’s not forget about other threats that, although may be not as massive as these attacks, have equally serious ramifications against the victims.

Remember vishing? Well, here’s a refresher.

Vishing is a type of phishing attack that involves Voice over Internet Protocol (VoIP) technology in stealing user’s sensitive information, usually financial in nature. Like certain types of phishing attacks, it usually persuades users into divulging personal data by sending them legitimate-looking messages (via email, text message or sometimes even via telephone call), warning them that their account is supposedly to be suspended or has expired and instructing them to contact the number provided to prevent the suspension or to renew their accounts. Upon calling the number, users are directed to an automated voice mail system that prompts them to dial in their credit card numbers and PINs.

Earlier sightings of vishing attacks has been reported in 2006 and has been slowly and silently increasing its momentum since then. Last January, FBI’s Internet Crime Complaint Center (IC3) announced that the number of vishing-related complaints it received is rising at a considerably “alarming rate.” Trend Micro also noticed this movement as a couple of vishing attacks has been reported, among others, earlier this year.

And speaking of “growing sophishtication,” vishing attacks have seemingly followed the footsteps of Web site compromises and advanced phishing techniques by using toolkits in sending vishing-related SMS. Donald Smith of Sans Internet Storm Center came across SmssmtpSender, an automated toolkit that can be used for SMS spamming and vishing.

Read the rest of the story…

Top 5 Security Reasons to Use Windows Vista

June 12, 2008 – 8:32 AM

I cannot disagree with anyone that is apprehensive in moving from the current Windows desktop operating system that is installed for the majority of your users’ desktops to Windows Vista. We have all seen or heard the horror stories from past operating system upgrades. Applications do not work, drivers are not available, users do not adapt well… etc. Well, Vista does exhibit some of these issues. However, there are some compelling security reasons to make the move. In reality, I am going to suggest that you make the move for the IT staff immediately! This article describes the top 5 security based reasons to move to Windows Vista for all users in the environment. The reasons are valid and very reasonable.

UAC for Standard Users

User account control (UAC) went through numerous iterations and name changes during the Beta period for Windows Vista (code named Longhorn). The goals for solving end user issues were high and the results were reasonable. If your goal for UAC is to solve the LUA (Least privilege user access) bug, then you should continue on to bullet number two. UAC does not solve the LUA bug in any way shape or form. If you are not familiar with the LUA bug, it is the problem that is caused by poorly coded applications that force users to be local administrators in order to run applications. There are fixes to the LUA bug, if you go to XYZ you will find articles written to solve this issue.

What UAC does for end users is protect them against malware, adware, and other misbehaving applications that are running in the background. We all know that end users will click on nearly every radio button, read every email, and install any “fun or humorous” application. UAC is available to help protect the computer from the end user. The key to UAC is that any action that requires “administrative privileges” will prompt the user for the required credentials. If the user is not an administrator, the task can not be performed!

Read the rest of the story…

Major security sites hit by XSS bugs

June 12, 2008 – 6:03 AM

The websites of three of the security industry’s best-known companies include security flaws that could be used to launch scams against customers, according to a new report.

The report, from security watchdog site XSSed, verified 30 cross-site scripting (XSS) vulnerabilities across the sites of McAfee, Symantec and VeriSign. The flaws could be used to launch scams or implant malicious code on the systems of visiting users, according to XSSed.

Recent research has shown that attackers are increasingly – even predominantly – now using legitimate sites to host their malware, a tactic that makes the malware distribution sites more difficult to shut down.

XSSed’s results show that even major security firms are not exempt from the problem, according to XSSed.

In January XSSed found that 60 websites that had received a “Hacker Safe” certification from McAfee’s ScanAlert service were in fact vulnerable to XSS attacks.

McAfee and other major security firms have downplayed the seriousness of XSS flaws, compared for instance to flaws that allow an attacker direct access to customer data stored on a server.

In recent months the real-world exploitation of XSS flaws has boomed, exploiting major websites such as MySpace, Paypal and a major Italian bank.

Last week ScanSafe reported that 68 percent of all malware it blocked in May was found on legitimate sites that had been hacked, more than quadruple the level of a year earlier.

Such flaws can be used to steal user cookies, to steal website login credentials and to exploit users’ trust of a site in other ways, and in theory can be shut down quickly once the owner of the site is made aware of the problem.

Read the rest of the story…

New Zlob Trojan Alters Your Router Settings

June 12, 2008 – 5:59 AM

Another new development in the malware arena, this new version of Zlob will actually log onto your router and change the DNS settings to hijack your traffic.

Pretty interesting approach and it will work because 99% of people won’t change the default password on their routers. Let’s face it, have you changed it?

A new Trojan horse masquerading as a video “codec” required to view content on certain Web sites tries to change key settings on the victim’s Internet router so that all of the victim’s Web traffic is routed through servers controlled by the attackers.

According to researchers contacted by Security Fix, recent versions of the ubiquitous “Zlob” Trojan (also known as DNSChanger) will check to see if the victim uses a wireless or wired hardware router. If so, it tries to guess the password needed to administer the router by consulting a built-in list of default router username/password combinations. If successful, the malware alters the victim’s domain name system (DNS) records so that all future traffic passes through the attacker’s network first.

It’s a pretty nifty piece of logic and coding, pretty simple too once you’ve thought of the idea. Just grep the gateway address from the machine (using the correct interface) then try and connect to it with a pre-compiled list of default user names and passwords.

Then bingo you’re in a little insertion of new DNS servers and you’re set!

Relatively few people ever change the default username and password on their wireless routers. I see this often, even among people who have locked down their wireless routers with encryption and all kinds of other security settings: When I confront them about why they haven’t changed the default credentials used to administer the router settings, their rationale is that, ‘Well, why should I change it? An attacker would need to already have a valid connection on my network in order to reach the router administration page, so what’s the difference?’

Obviously, an attack like this illustrates the folly of that reasoning.

Indeed flawed reasoning, you should never leave anything with default passwords if possible as it’s just another weakness waiting to be exploited.

Not to say you will get infected with this malware, because that is unlikely, but someone on your network might…and if you haven’t changed the password the hijack could effect you too (it wouldn’t effect me because my DNS servers are static in my network interface settings as set by me).

Source: Darknet