Tab-Nabbing With Dns Spoofing Using Backtrack

 

Description: In this Tutorial I have Explained how to use SET ( Social Engineering tool kit) for Tab nabbing and DNS Spoofing using Ettercap to make it more effective in LAN.......

In next tutorial I will Explain How to do it using port 443 of attacker machine instead of using port 80. So that even if victim type https://url instead of http then also he/she get attacked.

Sumber 

Read More...

VeriSign Demands The Power To Take Down Websites/Domains

I was scanning the news today, and nothing much was going on. There were some half-arsed stories about Anonymous and LulzSec – but nothing really worth writing about. And then, and then I spotted this, which quite frankly scares the shit out of me.

As much as it may well have a use in law enforcement, I’m sorry but I don’t want any single organization, corporation or entity to have the power to take out domains.

It’s just plain wrong, and well the UK has already started tabling something like this back in September.

VeriSign, which manages the database of all .com internet addresses, wants powers to shut down “non-legitimate” domain names when asked to by law enforcement.

The company said today it wants to be able to enforce the “denial, cancellation or transfer of any registration” in any of a laundry list of scenarios where a domain is deemed to be “abusive”. VeriSign should be able to shut down a .com or .net domain, and therefore its associated website and email, “to comply with any applicable court orders, laws, government rules or requirements, requests of law enforcement or other governmental or quasi-governmental agency, or any dispute resolution process”, according to a document it filed today with domain name industry overseer ICANN.

The company has already helped law enforcement agencies in the US, such as the Immigration and Customs Enforcement agency, seize domains that were allegedly being used to sell counterfeit goods or facilitate online piracy, when the agency first obtained a court order.

That seizure process has come under fire because, in at least one fringe case, a seized .com domain’s website had already been ruled legal by a court in its native Spain.

Senior ICE agents are on record saying that they believe all .com addresses fall under US jurisdiction.

But the new powers would be international and, according to VeriSign’s filing, could enable it to shut down a domain also when it receives “requests from law enforcement”, without a court order.

Yes VeriSign do manage all the .com and .net domains, but they aren’t technically ruled under the US jurisdiction – there are plenty of .com domains that are hosted outside of the US, including the DNS infrastructure.

What I’m especially interested in, is how they plan to handle the fact that lots of things are illegal in some countries and perfectly legal in others. The part that scares me is they will be able to take down a domain without a court order, just on ‘request’ from a law enforcement agency.

To me, that opens it up to abuse – if you are going to do something like this, at least institute a due process to manage it properly.


“Various law enforcement personnel, around the globe, have asked us to mitigate domain name abuse, and have validated our approach to rapid suspension of malicious domain names,” VeriSign told ICANN, describing its system as “an integrated response to criminal activities that utilize Verisign-managed [top-level domains] and DNS infrastructure”.

The company said it has already cooperated with US law enforcement, including the FBI, to craft the suspension policies, and that it intends to also work with police in Europe and elsewhere.

It’s not yet clear how VeriSign would handle a request to suspend a .com domain that was hosting content legal in the US and Europe but illegal in, for example, Saudi Arabia or Uganda.

VeriSign made the request in a Registry Services Evaluation Process (RSEP) document filed today with ICANN. The RSEP is currently the primary mechanism that registries employ when they want to make significant changes to their contracts with ICANN.

The request also separately asks for permission to launch a “malware scanning service”, not dissimilar to the one recently introduced by ICM Registry, manager of the new .xxx extension.

That service would enable VeriSign to scan all .com websites once per quarter for malware and then provide a free “informational only” security report to the registrar responsible for the domain, which would then be able to take re-mediation action. It would be a voluntary service.

Scary thoughts really. However the malware scanning service sounds like something that would help the Internet clean up all the nasty stuff, but then again – do the registrars really care, and would they respond?

Either way, I don’t like the fact that these draconian control laws may be placed on the Internet as we know – that basically allow US law enforcement agencies to take down domains as they please.

What I’m guessing, if this is implemented, it may well become a major target for Social Engineering efforts. What’s more effective than a traditional DDoS attack? Having the domain completely killed by VeriSign – that’s what. Read More...

The Inside Story of the Kelihos Botnet Takedown

Earlier this week, Microsoft released an announcement about the disruption of a dangerous botnet that was responsible for spam messages, theft of sensitive financial information, pump-and-dump stock scams and distributed denial-of-service attacks.

Kaspersky Lab played a critical role in this botnet takedown initiative, leading the way to reverse-engineer the bot malware, crack the communication protocol and develop tools to attack the peer-to-peer infrastructure. We worked closely with Microsoft’s Digital Crimes Unit (DCU), sharing the relevant information and providing them with access to our live botnet tracking system.

A key part of this effort is the sinkholing of the botnet. It’s important to understand that the botnet still exists – but it’s being controlled by Kaspersky Lab. In tandem with Microsoft’s move to the U.S. court system to disable the domains, we started to sinkhole the botnet. Right now we have 3,000 hosts connecting to our sinkhole every minute. This post describes the inner workings of the botnet and the work we did to prevent it from further operation.

Let's start with some technical background: Kelihos is Microsoft's name for what Kaspersky calls Hlux. Hlux is a peer-to-peer botnet with an architecture similar to the one used for the Waledac botnet. It consists of layers of different kinds of nodes: controllers, routers and workers. Controllers are machines presumably operated by the gang behind the botnet. They distribute commands to the bots and supervise the peer-to-peer network's dynamic structure. Routers are infected machines with public IP addresses. They run the bot in router mode, host proxy services, participate in a fast-flux collective, and so on. Finally, workers are infected machines that do not run in router mode, simply put. They are used for sending out spam, collecting email addresses, sniffing user credentials from the network stream, etc. A sketch of the layered architecture is shown below with a top tier of four controllers and worker nodes displayed in green.

Figure 1: Architecture of the Hlux botnet

Worker Nodes

Many computers that can be infected with malware do not have a direct connection to the Internet. They are hidden behind gateways, proxies or devices that perform network address translation. Consequently, these machines cannot be accessed from the outside unless special technical measures are taken. This is a problem for bots that organize infected machines in peer-to-peer networks as that requires hosting services that other computers can connect to. On the other hand, these machines provide a lot of computing power and network bandwidth.

A machine that runs the Hlux bot would check if it can be reached from the outside and if not, put itself in the worker mode of operation. Workers maintain a list of peers (other infected machines with public IP addresses) and request jobs from them. A job contains things like instructions to send out spam or to participate in denial-of-service attacks. It may also tell the bot to download an update and replace itself with the new version.


Router Nodes

Routers form some kind of backbone layer in the Hlux botnet. Each router maintains a peer list that contains information about other peers, just like worker nodes. At the same time, each router acts as an HTTP proxy that tunnels incoming connections to one of the Controllers. Routers may also execute jobs, but their main purpose is to provide the proxy layer in front of the controllers.

Controllers

The controller nodes are the top visible layer of the botnet. Controllers host a nginx HTTP server and serve job messages. They do not take part in the peer-to-peer network and thus never show up in the peer lists. There are usually six of them, spread pairwise over different IP ranges in different countries. Each two IP addresses of a pair share an SSH RSA key, so it is likely that there is really only one box behind each address pair. From time to time some of the controllers are replaced with new ones. Right before the botnet was taken out, the list contained the following entries:

193.105.134.189
193.105.134.190
195.88.191.55
195.88.191.57
89.46.251.158
89.46.251.160

The Peer-to-Peer Networks

Every bot keeps up to 500 peer records in a local peer list. This list is stored in the Windows registry under HKEY_CURRENT_USER\Software\Google together with other configuration details. When a bot starts on a freshly infected machine for the first time, it initializes its peer list with some hard-coded addresses contained in the executable. The latest bot version came with a total of 176 entries. The local peer list is updated with peer information received from other hosts. Whenever a bot connects to a router node, it sends up to 250 entries from its current peer list, and the remote peer send 250 of his entries back. By exchanging peer lists, the addresses of currently active router nodes are propagated throughout the botnet. A peer record stores the information shown in the following example:

m_ip: 41.212.81.2
m_live_time: 22639 seconds
m_last_active_time: 2011-09-08 11:24:26 GMT
m_listening_port: 80
m_client_id: cbd47c00-f240-4c2b-9131-ceea5f4b7f67

The peer-to-peer architecture implemented by Hlux has the advantage of being very resilient against takedown attempts. The dynamic structure allows for fast reactions if irregularities are observed. When a bot wants to request jobs, it never connects directly to a controller, no matter if it is running in worker or router mode. A job request is always sent through another router node. So, even if all controller nodes go off-line, the peer-to-peer layer remains alive and provides a means to announce and propagate a new set of controllers.

The Fast-Flux Service Network

The Hlux botnet also serves several fast-flux domains that are announced in the domain name system with a TTL value of 0 in order to prevent caching. A query for one of the domains returns a single IP address that belongs to an infected machine. The fast-flux domains provide a fall-back channel that can be used by bots to regain access to the botnet if all peers in their local list are unreachable. Each bot version contains an individual hard-coded fall-back domain. Microsoft unregistered these domains and effectively decommissioned the fall-back channel. Here is the set of DNS names that were active before the takedown – in case you want to keep an eye on your DNS resolver. If you see machines asking for one of them, they are likely infected with Hlux and should be taken care of.

hellohello123.com
magdali.com
restonal.com
editial.com
gratima.com
partric.com
wargalo.com
wormetal.com
bevvyky.com
earplat.com
metapli.com

The botnet further used hundreds of sub-domains of ce.ms and cz.cc that can be registered without a fee. But these were only used to distribute updates and not as a backup link to the botnet.

Counteractions

A bot that can join the peer-to-peer network won't ever resolve any of the fall-back domains – it does not have to. In fact, our botnet monitor has not logged a single attempt to access the backup channel during the seven months it was operated as at least one other peer has always been reachable.

The communication for bootstrapping and receiving commands uses a special custom protocol that implements a structured message format, encryption, compression and serialization. The bot code includes a protocol dispatcher to route incoming messages (bootstrap messages, jobs, SOCKS communication) to the appropriate functions while serving everything on a single port. We reverse engineered this protocol and created some tools for decoding botnet traffic. Being able to track bootstrapping and job messages for a intentionally infected machine provided a view of what was happening with the botnet, when updates were distributed, what architectural changes were undertaken and also to some extend how many infected machines participate in the botnet.

Figure 2: Hits on the sinkhole per minute

This Monday, we started to propagate a special peer address. Very soon, this address became the most prevalent one in the botnet, resulting in the bots talking to our machine, and to our machine only. Experts call such an action sinkholing – bots communicate with a sinkhole instead of its real controllers. At the same time, we distributed a specially crafted list of job servers to replace the original one with the addresses mentioned before and prevent the bots from requesting commands. From this point on, the botnet could not be commanded anymore. And since we have the bots communicating with our machine now, we can do some data mining and track infections per country, for example. So far, we have counted 49,007 different IP addresses. Kaspersky works with Internet service providers to inform the network owners about the infections.

Figure 3: Sinkholed IP addresses per country

What now?

The main question is now: what is next? We obviously cannot sinkhole Hlux forever. The current measures are a temporary solution, but they do not ultimately solve the problem, because the only real solution would be a cleanup of the infected machines. We expect that the number of machines hitting our sinkhole will slowly lower over time as computers get cleaned and reinstalled.

Microsoft said their Malware Protection Center has added the bot to their Malicious Software Removal Tool. Given the spread of their tool this should have an immediate impact on infection numbers. However, in the last 16 hours we have still observed 22,693 unique IP addresses. We hope that this number is going to be much lower soon.

Interestingly, there is one other theoretical option to ultimately get rid of Hlux: we know how the bot's update process works. We could use this knowledge and issue our own update that removes the infections and terminates itself. However, this would be illegal in most countries and will thus remain theory.
Read More...

HP aims new enterprise security software at mobile, cloud computing

Security suites help businesses deal with threats from mobile computing, consumerization of IT, cloud services, social media

Hewett-Packard is expanding its Enterprise Security Solutions portfolio to help businesses deal with persistent security threats from cloud computing and social media.

The new security portfolio is aimed at helping businesses deal with threats arising from mobile computing, the consumerization of IT, the adoption of cloud services, and social media. Enterprises need to manage risk with a balanced approach to systematically assess these security threats, according to HP.

[ Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

To achieve this, HP is combining its security products and acquisitions into suites "designed to help enterprises establish and execute a comprehensive security strategy that addresses threats and potential liabilities resulting from the rise of mobility, cloud computing and social media," the company said in a press release Monday.
ArcSight, Fortify Software and TippingPoint have been combined in a risk management platform. With that platform in place, HP hopes to eliminate the fragmented security practices in the enterprise.

The company also unveiled several security tools. ArcSight Express 3.0 is aimed at detecting and preventing cyberthreats. HP Reputation Security Monitor lists malicious IP (Internet Protocol) and DNS (Domain Name System) addresses. Fortify Software Security Center suite tests for vulnerabilities. TippingPoint Web Application Digital Vaccine is used for sniffing out malicious traffic and for real-time identification of vulnerabilities in Web applications.

According to Tom Reilly, vice president and general manager of HP enterprise security products, businesses are building infrastructures that are "a patchwork of unrelated security products and processes." In a video explaining the new security tools, Reilly said that "the result is a proliferation of point solutions with no coordination across silos, business units or functionaries."

By combining its security tools HP hopes to eliminate this fragmentation. To do this HP also introduced new Information Security Management services, Enterprise Cloud Service threat management software and Application Security Testing-as-a-Service to identify and close vulnerabilities in the application layer.

nb : infoworld Read More...

How to Secure Web Apps Against XSS Flaws

As a security researcher, I regularly come across software vulnerabilities. Some can have a deep and lasting effect on the way customers and clients view the security of the organization and some can have a fairly minimal impact. However, when there are applications susceptible to a few basic types of attacks, I struggle to understand how these can continue to slip through each phase of development and into production. Frankly these types of vulnerabilities are simply irresponsible and dangerous to the end users.

There are a handful of vulnerabilities that fit into this group; cross-site scripting (XSS) being one of them – and we find them in just about every application we test. An XSS vulnerability allows an attacker to modify a web page however they see fit, sometimes by injecting javascript, flash objects, HTML or anything else the browser can render.

Because the payload is delivered by a vulnerable site, XSS will prey on a user’s trust relationship with the website they are visiting. This increases the likelihood a victim user will allow malicious code to run or software to be installed. The attack targets your application's users and not the application itself, but it uses your application as the vehicle for the attack. Essentially, the browser has no way of discerning if the code was created by the original developer or a malicious attacker because that script is usually downloaded or at least referenced from a trusted site.

If an attacker can get an XSS foothold into the victim’s browser they can access and do anything the browser can access or do. I’ll let that sink in for a second. Think about what we do in a browser nowadays, almost everything. XSS opens the door for direct data theft, through cookies and other site information or indirect data theft through phishing and other attacks.

Anything with a web interface is potentially vulnerable. We’ve seen XSS issues in mobile devices and desktop applications. Really anything that can render HTML. Primarily though, web applications fall victim to this type of attack.  When the script is stored in a database it becomes persistent, which is far worse because the same attack can be used for any user that browses to the site.

Web applications often echo user input back to them without altering it. Search engines are a good example of this type of behavior. Attackers can create and distribute URLs that contain a malicious script that gets reflected back to the user, this is, aptly named, “reflected XSS”. The most common example of this is the "page not found" error page which echoes the requested page back to the user.

What You Need to Know About XSS
Here are a few aspects of XSS attacks that your organization should be aware of relative to the impact of such an attack, but also which components and conditions that might enable XSS methods to exploit systems. 

• Confidential Information Disclosure - The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies or on the page itself.

• User Exposure - Even if an attacker cannot obtain the plaintext credentials of a user, they can act as that user by stealing session IDs.

There are a number of common mistakes organizations make that leave their applications vulnerable to attack. Some of these mistakes are enormously easy to rectify, while others might not seem so obvious.

• Failure to use whitelist validation before it is processed by the application.

• Trusting data retrieved from any database or other data resource

• Failing to encode any remotely provided data, including reverse DNS lookup, cookie contents, uploaded files, etc.

• Improperly converting "safe" tags to HTML.

• Displaying user input directly without encoding it appropriately for the context in which it is used.

• Checking user submitted data against a blacklist instead of a whitelist.

Input Validation is the Key to Protecting your Organization
XSS flaws might not be easy to identify, but are easy to remove from a web application. A security code review might be the best way to find flaws and search for all places where input from a user can make its way into the HTML output.

Many different HTML tags can be used to transmit a malicious JavaScript. Automated Web Scanning tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

There are a number of considerations when taking precautionary steps against this flaw, including what language your apps are written in and what your environment looks like. Here are some best practices as to how you’d remediate:

• Perform context sensitive encoding of untrusted input before it is echoed back to a browser by using an encoding library. Most of these libraries only convert the symbols ", &, <, and > to safe HTML equivalents, however a better option is to use an encoding library that will encode all characters except a trusted whitelist:

• Python: cgi.escape (only escapes 3 characters by default, escaping " is optional)

• ASP.NET: HttpUtility.HtmlEncode and HttpUtility.UrlEncode (only encodes 4 characters) Microsoft’s Web Protection Library is a better option here.

• Perl: HTML::Entities::encode (only escapes 4 characters by default, but it makes it easy to specify other unsafe characters).

• PHP: htmlentities and urlencode (only escapes 4 characters by default, and can optionally encode ' (single quote).

• Ruby: Rails has this built in with the ‘h’ or ‘html_escape’ methods.

• Untrusted input should be validated against an inclusion list before use. For example, use a regular expression to define acceptable character sequences and use it as a filter. If the input is meant to be a primitive type it can be cast appropriately to assure that it is the expected type (a type constraint) and then checked to ensure it's in appropriate range (a range constraint).

• In the case where there are only a limited number of acceptable inputs, then the input can be constrained to that set with simple if or switch control structures, or by matching against a fixed list of strings (a domain constraint).

Summary
XSS is just one way attackers are able to penetrate corporate systems from the application level. It’s critical that organizations take the necessary steps to protect their sensitive information by ensuring that the applications they are deploying are written securely.

Input validation ensures the application processes the data that the developers know it can handle. Input validation is absolutely critical to application security, especially where most application risks involve tainted input at some level. Most applications do not plan input validation, and leave it up to the individual developers, which can derail the security that gets built into the application.

If you are able to identify that your applications are susceptible to an XSS attack, the right amount of education, training and tooling can help you resolve this issue quickly. Additionally, if you can remediate those vulnerabilities in your Web applications early in the SDLC, you’ll save significant time and money later if an attacker penetrates that application.

nb : threatpost Read More...

Operation Black Tulip: Fox-IT's report on the DigiNotar breach

Fox-IT, the security auditors hired to investigate the compromise of DigiNotar, the digital certificate authority that signed fraudulent certificates for Google, the CIA and others, released their preliminary findings this afternoon.


It's at least as bad as many of us thought. DigiNotar appears to have been totally owned for over a month without taking action, and they waited another month to take necessary steps to notify the public.
Fox-IT's report shows that the initial compromise appears to have occurred on June 17th, 2011. On the 19th DigiNotar noticed the incident, but doesn't appear to have done anything about it.

The first rogue certificate (as far as we know), *.google.com, was issued on July 10th, 2011. All of the other 530 rogue certificates were issued between July 10th and 20th.

There are several very disturbing conclusions about security at DigiNotar and the investigation isn't even complete yet:

1. All of the certificate servers belonged to one Windows domain, allowing the compromise of one administrator account to control everything.
2. The administrator password was simple and could be easily brute forced.
3. Much of the malware and tools used in the attack would have been easily detected by anti-virus, had it been present.
4. The software on public-facing servers was out of date and unpatched.
5. They had no centralized nor secure logging.
6. There was no effective separation of critical components.

The attacker left behind a message in one of the scripts used to generate the rogue certificates, arguably tying this attack to the earlier attack against Comodo back in March of this year.
The message reads in part:

"THERE IS NO ANY HARDWARE OR SOFTWARE IN THIS WORLD EXISTS WHICH COULD STOP MY HEAVY ATTACKS
MY BRAIN OR MY SKILLS OR MY WILL OR MY EXPERTISE"

Fox-IT analyzed the lookups against DigiNotar's OCSP servers (which browsers check to see if a certificate has been revoked) and determined that during the active attack period more than 99% of queries originated in Iran.

_{Video showing origin of OCSP queries against DigiNotar's servers courtesy of Fox-IT.}

This is the most solid evidence yet that these certificates may have been used by the Iranian government or ISPs to spy on private communications of Iranian internet users. Many of the other requests not originating from Iran appear to have originated via Tor exit nodes or other proxies used by Iranians to avoid censorship.

This indicates that the method used to perform the man-in-the-middle attacks with these certificates likely depended on DNS poisoning at the ISPs.

While some folks are complaining that too much fuss is being made over this attack, it is far more important than many other stories that the security press have been obsessed with over the last two years.

This incident demonstrates in a real way the fragility of the SSL/TLS certificate trust model in use on the net today.

I hope adoption of replacement technologies like Moxie Marlinspike's Convergence take off in a meaningful way to provide us with more confidence in the security of our communications.

We now know not to trust certificates issued by DigiNotar, but how many of the 600+ other certificate authorities have similar security holes and may already be compromised?

nb : nakedsecurity.sophos Read More...

DigiNotar SSL certificate hack amounts to cyberwar, says expert

Dutch government revokes certificates used for all its secure online transactions, while CIA, Google, Microsoft and others affected by hack called 'worse than Stuxnet'

 

The Dutch government has revoked all trust in digital certificates issued by DigiNotar

The Dutch government says hackers who broke into a web security firm in the Netherlands last month issued hundreds of bogus security certificates that could be used on websites including the CIA and Israel's Mossad, as well as internet giants such as Google, Microsoft and Twitter.

More than 500 fake certificates, including some which could be used to send fake Windows updates to computers, and others which could be used when connecting to the CIA's site, were fraudulently issued in the hack, which occurred in July.

The Dutch government took the exceptional step of calling a press conference at 1.15am on Saturday morning to announce that it was revoking all trust in digital certificates issued by DigiNotar, which until then had been used for all online tax returns filed in the Netherlands.

The government said that browser companies are now rejecting all security certificates issued by the hacked firm. Microsoft's Internet Explorer, Mozilla Firefox and Google's Chrome will all reject certificates from the company. Apple systems require a manual update. Apple has not made any statement on whether it will revoke DigiNotar certificates.

The fake certificates could in theory be used to monitor users' communications with those sites without them noticing, but only by an organisation that also has the ability to reroute internet traffic to servers they control – most likely a government.

Iran's government has been suspected of involvement in the hack, which led to the creation of hundreds of fake security certificates used to create cryptographically secure links between users and sites. A handful of Iranian users of Google's popular email service are known to have been affected by the faked certificates, which would allow a "man in the middle" attack, where an apparently secure link could in fact be tapped by an intermediary. Security experts noted that earlier this year, Iran announced that it was changing the setup for its domain name servers (DNS) used to make connections to sites – which would give it the ideal opportunity to insert faked certificates into the system.

Roel Schouwenberg of the security company Kaspersky warned that the long-term effects of the DigiNotar hack could be more serious than Stuxnet, a computer "worm" that is believed to have been written by US and Israeli computer experts to attack Iran's nuclear facilities by destabilising computer-controlled systems in its uranium centrifuges.

"The attack on DigiNotar will put cyberwar on or near the top of the political agenda of western governments," he noted on the Securelist blog. "I remain with my stance that a government operation is the most plausible scenario."

He added: "The damage sustained to the Dutch (government) IT infrastructure is quite significant. A lot of services are no longer available. Effectively, communications have been disrupted. Because of this one could make an argument the attack is an act of cyberwar."

nb : guardian Read More...

Turkish hackers redirect traffic from websites and compromise passwords in DNS attack

Turkish hackers have carried out domain name system attacks on around 200 websites, including The Register, The Daily Telegraph, BetFair, Vodafone and Acer, redirecting traffic to third-party websites.

Although the sites were not hacked directly, the attacks put users at risk of having passwords and other details stolen if they attempt to log into the fake third-party sites under the hackers' control.

E-mails sent to the sites while the hack was live would also be redirected to the site substituted by the hackers.

Attacks on the domain name system (DNS) - which routes users to websites - rely on weaknesses in domain registrars to access the settings pages on the domain server to cause disruption.

"Instead of breaching the website itself, the hackers have managed to change the DNS records for the various sites affected," said Graham Cluley, senior technology consultant as security firm Sophos.

Many of the websites restored connections on Sunday, but because of the way that DNS works, it may take some time for corrected DNS entries to propagate worldwide, he wrote in a blog post.

"If you're in the habit of visiting and logging into the affected sites, you might be wise to clear your cookies so the hackers aren't able to steal any information from you," Cluley wrote.

Some of the affected sites appeared to show a message in Turkish by a group called Turk Guvenligi, which last month carried out a similar attack on a Korean company.

The latest DNS attack by the group appears to have targeted Ascio.com, which registers domain names, and Netnames.co.uk, among others, according to the Guardian.

On a Twitter feed, the hacking group said that they did it for entertainment and told the paper via Twitter that the purpose was: "Millions of dollars, large systems, small weaknesses and what I could do. Just for fun."

nb : computerweekly Read More...

DNS hack hits popular websites: Daily Telegraph, The Register, UPS, etc

Popular websites including The Register, The Daily Telegraph, UPS, and others have fallen victim to a DNS hack that has resulted in visitors being redirected to third-party webpages.

Web security tester Paul Mutton managed to capture a screenshot of what visitors to The Register saw:


Part of the message reads:

TurkGuvengligi
"Gel Babana"
HACKED
"h4ck1n9 is not a cr1m3"
"4 Sept. We TurkGuvenligi declare this day as World Hackes Day - Have fun ;) h4ck y0u"

The phrase "Gel Babana" is Turkish for "Come to Papa", and "Guvenligi" is Turkish for "Security".

Further websites which have been affected by the DNS hack include National Geographic, BetFair, Vodafone and Acer.

It's important to note that the websites themselves have *not* been hacked, although to web visitors there is little difference in what they experience - a webpage under the control of hackers.

Instead of breaching the website itself, the hackers have managed to change the DNS records for the various sites affected.

DNS records work like a telephone book, converting human-readable website names like nakedsecurity.sophos.com into a sequence of numbers understandable by the internet. What seems to have happened is that someone changed the lookup, so when you entered telegraph.co.uk or theregister.co.uk into your browser you were instead taken to a website that wasn't under the control of those websites.

Because of the way that DNS works, it may take some time for corrected DNS entries for the affected websites to propagate worldwide - meaning there could be problems for some hours ahead. If you're in the habit of visiting and logging into the affected sites, you might be wise to clear your cookies so the hackers aren't able to steal any information from you.

In many ways we have to be grateful that the message displayed appears to be graffiti, rather than an attempt to phish information from users or install malware.

The question now is how did the hackers manage to change the DNS records for these sites?
Here's a statement The Register published about the incident:


We will publish more information as it becomes available. If you prefer, follow me at @gcluley on Twitter for the latest news.

nb : nakedsecurity.sophos
Read More...