Brainfoldb4u's Blog

Just another weblog

Archive for January 3rd, 2010

France's new Internet privacy law

Posted by brainfoldb4u on January 3, 2010

French government have created a new state agency called HADOPI stands for Higher Authority for the Distribution of Works and the Protection of Copyright on the Internet.
The law took effect from this new year 2010 after a long struggle in the parliament. According to this new law,Illegal downloaders will be sent a warning e-mail, then a letter if they continue, and finally must appear before a judge if they offend again. The judge can impose a fine, or suspend their access to the internet.

Posted in Government & Law | Tagged: , | Leave a Comment »

Researcher Uncovers Twitter, Google Calendar Security Vulnerabilities

Posted by brainfoldb4u on January 3, 2010

A security researcher uncovered some holes in Google Calendar and Twitter that may allow an attacker to steal cookies and user session IDs…

A security researcher has uncovered vulnerabilities in Twitter and Google Calendar that could put users at risk.

In a proof-of-concept, researcher Nir Goldshlager demonstrated cross-site scripting (XSS) vulnerabilities in Google Calendar and Twitter that he said could be used to steal cookies and session IDs. He also uncovered an HTML injection issue affecting Google Calendar as well that he said could be used to redirect a victim to an attack site anytime the user viewed his or her Google Calendar agenda events….

For complete article from eweek, click

Posted in Google, Penetration testing, XSS | Tagged: , , | Leave a Comment »

Conficker computer worm

Posted by brainfoldb4u on January 3, 2010

Decades biggest hackers innovation were Bots, and the biggest among was Conficker. Conficker was predicted by mian stream press as the work that would destroy the internet. But though it did not destroy the internet it with packing state-of-the-art encryption, and sophisticated peer-to-peer update mechanism, Conficker tantalized security researchers and resisted attempts at eradication, inhabiting at its peak as many as 15 million unpatched Windows boxes, mostly in China and Brazil.

The Conficker worm is a  computer worm that can infect your computer and spread itself to other computers across a network automatically, without human interaction.Experts thought it’s the work of an organized team of coders, and there are hints that it originated in Ukraine. And like most of the hacking out of Eastern Europe, the software has a profit motive: It’s been seen sending spam, and serving victims a fake anti-virus product that offers to remove malware for $49.95. Dude. It used to be about the mayhem.

Here are some information that worth to stay safe from the Downadup worm. I found these information on Norton website and thought worth sharing.

The Conficker worm, sometimes called Downadup or Kido has managed to infect a large number of computers. Specifics are hard to come by, but some researchers estimate that millions of computers have been infected with this threat since January 2009.  If you are unable to reach your Security suite web site, you may be infected. In that case you will need to get to a computer that is not infected, download specialized Conficker removal tool and run it on the infected machine before installing new antivirus software. Symantec has a detailed technical analysis of the threat.

What does the Conficker worm do?

The Conficker worm has created secure infrastructure for cybercrime. The worm allows its creators to remotely install software on infected machines. What will that software do? We don’t know. Most likely the worm will be used to create a botnet that will be rented out to criminals who want to send SPAM, steal IDs and direct users to online scams and phishing sites.

The Conficker worm mostly spreads across networks. If it finds a vulnerable computer, it turns off the automatic backup service, deletes previous restore points, disables many security services, blocks access to a number of security web sites and opens infected machines to receive additional programs from the malware’s creator. The worm then tries to spread itself to other computers on the same network.

How does the worm infect a computer?

The Downadup worm tries to take advantage of a problem with Windows (a vulnerability) called MS08-067 to quietly install itself. Users who automatically receive updates from Microsoft are already protected from this. The worm also tries to spread by copying itself into shared folders on networks and by infecting USB devices such as memory sticks.

Who is at risk?

Users whose computers are not configured to receive patches and updates from Microsoft and who are not running an up to date antivirus product are most at risk. Users who do not have a genuine version of Windows from Microsoft are most at risk since pirated system usually cannot get Microsoft updates and patches.

What to do if you are infected

If you are reading this page, your computer is probably not infected with Conficker as the worm blocks access to most security web sites.

If you have a computer that is infected, you will need to use an uninfected computer to download a specialized Conficker removal tool from. The tool is available here:

Or, you can restore access to security web sites on an infected machine by taking the following steps:

  1. Click Start > Run.
  2. In the Run box, type the following: cmd
  3. Click OK.
  4. Type the following and then press Enter. cd..
  5. Repeat the previous step until you get to the root level, or C:\>. Note that if your root drive is not C, the letter will be different.
  6. At C:\> type the following: net stop dnscache
  7. Press Enter. This disables the domain blocking feature of Conficker and you should now be able to reach security Web sites including ours. You should now be able to download the Conficker removal tool here.

Posted in Botnet, Hacking, Information Security, Worms | Tagged: , , | 1 Comment »

The Decade’s 10 Most Dastardly Cyber crimes

Posted by brainfoldb4u on January 3, 2010

It was the decade of the mega-heist, when stolen credit card magstripe tracks became the pork bellies of a new underground marketplace, Eastern European hackers turned malware writing into an art, and a nasty new crop of purpose-driven computer worms struck dread in the heart of America.

Now that the zero days are behind us, it’s time to reflect on the most ingenious, destructive or groundbreaking cybercrimes of the first 10 years of the new millennium.

Read the complete article by Kevin Poulsen from Wired  magazine

Posted in Hacking | Tagged: | Leave a Comment »

Cross site scripting scenarios

Posted by brainfoldb4u on January 3, 2010

Web pages contain both text and HTML markup that is generated by the server and interpreted by the client browser. Web servers that generates static web pages have full control over client browser. But servers with dynamic pages do not have complete control over how their output is interpreted by the client. Question is, does the client side browser has enough information to recognize if the script is malicious or legitimate and take proper actions accordingly.

Many web servers generate web pages dynamically. For example, a search engine may do a database search and then build a web page that has the result of the search. Any server that creates web pages by inserting dynamic data into a template should check to make sure that the facts to be inserted does not contain any special characters (e.g., “<“). If the inserted data has special characters, the user’s web browser will mistake them for HTML markup. Because HTML markup can introduce programs, the browser could interpret some data values as HTML tags or script and not displaying them as text.

If a web browser is not performing checks for special characters in dynamically generated web pages, then in some cases an attacker can choose the data that the web server inserts into the generated page. The attacker can trick the user’s browser into running a program of the attacker’s choice. This program will execute in the browser’s security context for communicating with the legitimate web server, not the browser’s security context for communicating with the attacker. Thus, the program will execute in an inappropriate security context with inappropriate privileges.

Todays browsers are capable of interpreting and executing scripts — created in such scripting languages as JavaScript, JScript, VBScript — embedded in the Web-page downloads from the Web server. When an attacker introduces a malicious script to a dynamic form submitted by the user, a cross-site scripting (XSS) attack then occurs. An XSS attack leads to undesirable effects. For example, the attacker gains the ability to capture the session information, peer into private user details such as ID, passwords, credit card information, home address and telephone number, social security/tax IDs, and so on. If the targeted Web site doesn’t check for this type of malicious code, misuse of the user is probable.

Hackers take several steps to cut the risk of having the script identified as malicious, the attacker might encode it with a different encoding method, such as HEX. With this alteration, the Web site displays the malicious content on the page as if the displayed information is the valid content from the site. If the Web application doesn’t confirm the comments, all the attacker has to do is to coax the user to select the malicious hyperlink, after which the Web application collects confidential data from the user. This enables the attacker to capture the user’s session and steal the user’s credentials, redirect to a page on another Web site, and then insert code that can poison cookies, expose SSL connections, access restricted or private sites, or even trigger a number of such attacks.

To stop the XSS, we need to understand the venues that are more prone to XSS attacks. Most obvious venues are

  • Banking web page
  • Online forum and search boxes
  • Email messages with malicious links
  • Search engines
  • Setting up an account

Banking Web page

For example, let us consider an hacker who wants to gather information on a user of a example banking website, Attacker needs Login ID and password to enter into the web site, as all banking web sites contain secure login.  Hacker may try using both username and password as “test”. When the resulting error page comes back with a message that says that the user ID and password combination is wrong, the hacker finds himself in an ideal situation for inserting malicious code into the Web page. How?

He first enters the following into the ID text box: <script>alert('Test')</script>. Submits the form and then sees this JavaScript alert message: “TO BE DONE.” Now he knows that the site is prone to an XSS-style attack. attacker then might introduce malicious scripts  into the URL that redirects the submitted user information to code basically passes the user ID and password information of any user logging into the Web site along to the Web site of the attacker. Now that the script to hack the user ID and password is ready, the attacker sends e-mails and posts with attractive offers to banking Web site users employing this link. Prompted by the attractive offers, users might click on the link and log on to the banking Web site. The malicious script introduced by the attacker is executed by the browser and the data is passed to the hacker’s Web site. The rest is a cakewalk for the hacker to log on to the banking Web site with the victim’s credentials.

This situation is most probable in couple of scenarios like when a web server does not take adequate steps to ensure that the properly encoded pages are generated. And when inputs are suitably validated.

Search Boxes and Online Forums

Search boxes and online forums are  most commonly attacked avenue. An attacker inserts malicious code between scripting tags that the Web page accepts and interprets, using FORM or APPLET tags, depending on the page used. Inserted malicious code can do all sorts of harm by stealing session information or cookies. Vulnerability of this sort is prevalent given that a Web designer needs to have knowledge of many languages and technologies like — CGI, JavaScript, ASP, Perl, even HTML tags  can be used as a delivery vehicle for such attacks.

Email messages with malicious links

An attacker can send an e-mail about a banking Web site to a user. Suppose the e-mail contains a link with a malicious script embedded into the URL. The user may be prompted to click on the link and log on to the Web site, whereby the attacker can seize the user’s log on information. The same is true on a dynamically generated page if a link has malicious code in it. Consider the example of a malicious URL that might be a part of the page. If the attacker has the application display a set of HTML, trouble may creep in. Both the IMG and IFRAME tags allow for a new URL to load when HTML is displayed.

Search engines

Search engines that echo the search keyword that was entered are also vulnerable to such attacks. This is because malicious code can be entered as a part of the keyword search input that is executed when the user submits the search. Dangers can include accessing undesirable or private regions of the Web site.

Setting up an account:

When a user submits a form during e-mail account setup or during submission of a form with data in it, the Web application might show the same information after accepting the information as entered. The input content entered can contain such malicious information that may be executed by the browser. This can lead to leaking of critical information from the session and might expose private avenues of the Web server.

XSS attack consequences: Stolen cookies

Cookie theft occurs when the cookie issued by the application is hijacked for malicious purposes by an attacker. By suitably inserting script code into the URL that invokes the portion of the site that uses cookies and is vulnerable, the attacker captures the cookies and can cause damage to content as well as mimic business functions and perform fake transactions.

What an end user can do to protect from XSS?

Below are the ways that a user can choose to cut the impact of XSS attack.

  • Disable scripting when it is not required.
  • Do not trust links to other sites on e-mail or message boards. They may contain malicious code with damaging potential.
  • Do not follow links from sites that lead to security-sensitive pages involving personal or business information unless you specifically trust them.
  • Access any site involving sensitive information directly through its address and not through any third-party sites.
  • Get a list of attacks and the sites and boards they happened on and be careful if you need to visit one of them.

    Posted in Hacking, Information Security, Penetration testing | Tagged: | Leave a Comment »