Jobin C John

Makarajyothi

2011-01-15T06:00:00.000-08:00

അവിശ്വാസം

2011-01-15T05:50:00.001-08:00

ക്ഷേത്രം പണിതത് മനുഷ്യര്

2011-01-15T05:42:00.001-08:00

ക്ഷേത്രം പണിതത് മനുഷ്യര്‍, അകത്തുള്ള മൂര്‍ത്തി പണിതതം മനുഷ്യര്‍, പൂജാരിയും മനുഷ്യൻ ദര്‍ശനത്തിന് എത്തണതും മനുഷ്യര്‍ അങ്ങനിരിക്കേ മകരവിളക്ക് മനുഷ്യ സൃഷ്ടിയാണെങ്കില്‍ എന്ത് പ്രശ്നം.....!!
അപകടത്തില്‍ പെട്ട് അനേകര്‍ മരിച്ച ഈ സമയത്ത് അതിനെ പറ്റി ചിന്തിക്കാതെ മകരവിളക്കിന്റെ വിശ്വാസതയെ ചോദ്യം ചെയ്യുവാൻ തത്രപ്പെടുന്ന ഇവരെല്ലാം മനുഷ്യരോ അതോ കൃത്രിമമായി സൃഷ്ടിക്കപ്പെട്ട വല്ല ജീവികളോ..?

Why we won’t help you

2009-07-16T02:49:00.000-07:00

There is one scenario I see play out again and again on Web Design-L, css-discuss, and countless other forums. Newbie Designer posts a link to a test page, asking for help because it doesn’t behave as expected in this or that browser. Guru Designer replies, telling Newbie Designer that their page doesn’t validate, and that they should go validate their page before asking such questions. There is no further discussion; no further replies are posted; no one else is willing to help.

Why does this happen? Why won’t we help you?

The short, smart-alec, Zen-like answer is that we are helping you, you just don’t realize it yet. The full answer goes like this:

1.Validation may reveal your problem. Many cases of "it works in one browser but not another" are caused by silly author errors. Typos like missing attribute values can cause browsers to crash; validation catches these typos. Simple errors like missing end tags (such as or ) or missing elements (such as ) can cause different problems in different browsers. Small mistakes like this are difficult for you to spot in your own code, but the validator pinpoints them immediately.

I am not claiming that your page, once validated, will automatically render flawlessly in every browser; it may not. I am also not claiming that there aren’t talented designers who can create old-style "Tag Soup" pages that do work flawlessly in every browser; there certainly are. But the validator is an automated tool that can highlight small but important errors that are difficult to track down by hand. If you create valid markup most of the time, you can take advantage of this automation to catch your occasional mistakes. But if your markup is nowhere near valid, you’ll be flying blind when something goes wrong. The validator will spit out dozens or even hundreds of errors on your page, and finding the one that is actually causing your problem will be like finding a needle in a haystack.

VIPRE Antivirus

2009-07-15T07:36:00.000-07:00

VIPRE Antivirus + Antispyware is a new PC security software created by Sunbelt Software. We created VIPRE to be faster than most traditional security software like Norton or McAfee. VIPRE will not slow down your PC and it is highly effective at preventing and curing PC Infections. We would like your help promoting VIPRE to the public.
Antivirus Software

Adds

2009-06-28T01:29:00.000-07:00

amazing specials on Hotels

2009-06-17T02:35:00.001-07:00

Asiarooms.com is offering amazing specials on Hotels in Thailand, Indonesia, Malaysia, Japan and China. http://revtwt.com/198478

sample code for creating i-frame virus

2009-06-16T02:23:00.000-07:00

Once attackers found a vulnerable PHP script they first detected the directory hierarchy on the web site. In case of the sample PHP script , it looked like this:

for ($i = 3; $i < 500; $i++) {
if ($i == 438) continue;
flush_buffer('/home/sites/site' . $i . '/web:
');
iframe_account(array('/home/sites/site' . $i . '/web'));
}

From the code snippet above, you can see that all sites have their document root directory set as /home/sites/site[number]/web. The loop creates an array which is then passed to another function called iframe_account().

This function takes every director and performs a recursive search for 4 file types:

$file_types = array('php', 'htm', 'html', 'tpl');

It then opens the files and searches for the “” tag which is replaced with the malicious iframe and properly closed:

$iframed_content = str_replace(/'/', '', $content);

And lol – a mass attack happened.

Chance of virus attack and solutions.

2009-06-16T01:34:00.000-07:00

Name : Flame.so / Flame.php
Appeared : Summer & Fall 2005
Uses : PHP's Dynamic Loader function - dl()

Description: Attackers exploit insecure PHP scripts to
load flame.php and flame.so on the server. The
attacker then accesses flame.php which loads
flame.so as a PHP module. The active PHP module
injects malicious code within each PHP page.

Systems Affected: Any system with dl() function
enabled

Disable dl() in php.ini
– enable_dl = Off
The specific flame.so exploit has been patched in
PHP 4.4+ but can still be seen in different variations
due to the nature of the dynamic loader function

============================================

Name: Apache DSO
Appeared: Summer & Fall 2007
Uses: Apache's Dynamic Module Support

Description: Attackers exploit an insecure script to
place custom Apache module on the server. The
attackers then use a specially crafted URL to load the
module using Apache's Dynamic Module support.
This allows malicious code to be served into each
request.

Systems Affected: Any system running Apache 1.3.34
and lower

Uses a technique introduced in Phrack to ensure
code modification persists to new Apache children
http://www.phrack.org/issues.html?issue=59&id=8&mode=txt

============================================

Name: Random JavaScript Toolkit
Appeared: Fall & Winter 2007 and Early 2008
Uses: Root SSH Access

Description: Attackers gain root login information using
viruses placed on a user's PC. This virus sends all
login information used on that PC to a master server
where it is logged and used to install a rootkit which
serves malicious content into random web requests.

Systems Affected: RedHat 4/5, CentOS 4/5

Modifies 7 System Binaries
– /sbin/ifconfig
-/sbin/fsck
– /sbin/route
-/bin/basename
– /bin/cat
-/bin/mount
– /bin/touch
Technically not a loadable module (LKM), modifies
kernel directly through /dev/mem

Injects IFrame text into pages, after the body tag
Sometimes random, sometimes consistent

Need to have root to modify the binaries
The infected binaries ensure the rootkit persists after
a reboot
Someone logs in as root without brute force
Found simple port 22 passwords, and also
convoluted passwords on random ports
Attacker installs a rootkit based on Boxer
Serves malicious code to random web requests
without any direct html modification

=============================================

Name: Gozi
Appeared: Spring 2007
Uses: Login credentials
Internet Explorer lets Winsock handle SSL, Gozi
hooks this
Also takes all client certificates from the Windows
certificate store

Requests are encrypted and repeated to a data
collecting machine via HTTP in real time
Protocols like FTP, SMTP, IMAP, POP, HTTP all use
plain text
In order to obtain passwords, just watch the Ethernet
traffic
It's easy to download Winpcap and windump
Tools have existed for years in Linux that use
libpcap and grab all login information from plaintext
protocols

Attention to web developers about massive hacking attack

2009-06-16T01:24:00.000-07:00

It looks like the attack usually has two stages.

• Account passwords harvesting. On the first state they collect passwords for the accounts. We can call this stage "account passwords harvesting". Details on how they do that are fuzzy. The truth is that on a typical Linux server it might enough to get just one user account password to be in a reasonably good position to get the root via some king of little known or unpatched exploit. Zones and jails are better in this respect as they protect other users from easily compromised "suckers" who happily use passwords like 123456 or use infected with spyware PCs at home. Actually the complexity of the password should be beefed up to at least 8 characters. But this does not help if the user computer is infected with a keylogger. ISPs need to handle vastly difference classes of users and security is always as good as the weakest link.

• On the second stage the pool of passwords harvested is used to modify certain files. We will call this stage "mass modification of index files". It looks like this stage was automated and they use a special tool, called MPACK, to install malicious IFrames. Usually only main site index documents were targeted (ie. index.php, index.html, index.shtml, etc.). Malicious IFrames are usually installed at the beginning or at the end of the document. That might be because of different tools of different version/modes of work of MPACK. But there are other cases when all documents were modified by replacing HEAD tag