Cores and Extras Heliotropic Computing

I can easily remember those days when I started learning J2EE and web technology. Database connectivity with a jsp / servlet  page often done by the following kind of code :
Connection con = DriverManager.getConnection(url , usrname, passwd);
This is an example of hard coded passwords where the actual password is used in the code to do some task. Hard coded passwords and cryptographic keys always increase the chance of security related problems.This kind of coding is not secured, first of all someone can use the generated class file with 'javap -c' and recover the password, username ... basically everything he wants to know. The password can't be changed without a patch , The whole developer team need to know the password , an unauthorized user who knows the password can easily gain access to the system ,  moreover the password will remain same across various companies and organizations who are using that product.

Same kind of security threat may come from hard coded cryptographic keys. It's not a tough job for an unauthorized user to gain access through questions where hard coded cryptographic keys are used. Using a hash function also won't be a safer idea as most of them are reversible and vulnerable to attack.

For more detail information and references , Check out :
http://cwe.mitre.org/data/definitions/259.html
http://cwe.mitre.org/data/definitions/321.html

We use Syslog to report system events. Now if you want to prevent unauthorized access to your system , monitoring logins is mandatory. Syslog provides an option to monitor failed logins . As a system administrator you may use '#logins -x -l username' to check login status of a particular user. But if you want to check failed logins to detect a potential threat about unauthorized access you need to take some easy steps. Before proceeding to those steps , some idea about a system file i.e '/etc/syslog.conf' is necessary.
Open the file , you will find some lines like :

*.err;kern.notice;auth.notice                   /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages

*.alert;kern.err;daemon.err                     operator
*.alert                                         root

*.emerg                                         *

Here the first field is Selector field and second field is Action field. Each line is written as Selector <Tab> Action ..in this way.  Selector field has again two parts , facility and level . They are written as facility1.level1:facility2.level2:facility3.level3 ..in this way. Action field determines where the message will be forwarded. Here *.err means error from any facility , kern stands for kernel , crit for critical etc. Detail description about facilities and levels is available here.
Now let's come back to the steps to detect failure logins.

i) edit /etc/default/login
here you can change the default values of TIMEOUT, SLEEPTIME, DISABLETIME, RETRIES etc. Make sure SYSLOG=YES is mentioned there. Now if you want to log a message after a single unsuccessful login attempt then make 'SYSLOG_FAILED_LOGINS=0'.

ii) create a log file : #touch /var/adm/faillog , give appropriate permission : chmod 600 /var/adm/faillog , select suitable group : chgrp sys /var/adm/faillog.

iii) edit /etc/syslog.conf
add a line : auth.notice<Tab>/var/adm/faillog

iv)then execute ' svcadm refresh system/system-log'.

Also check out man logger to know how to add entries to the system log, man  syslogd to log system messages and man logadm to manage endlessly growing log files.

Very often we need to create temporary files while creating a large piece of code. Common C library functions like tmpnam(), tempnam(), mktemp() etc are used to generate a unique name for a temporary file. These functions doesn't open that file. Other C functions like tmpfile(), mkstemp() are also available which generates a unique name for a temporary file as well as open that file. Now those name-generating-only functions are very much vulnerable to attack. There are several reasons behind that . Those functions generate random unique names for temporary files which are not too difficult to guess. So if an attacker can guess the file name and create a duplicate same-named filed between name generation and file opening process execution then it may cause serious security problems depending on file permissions and opening options . This is another aspect to keep in mind , file permission during creation and directory permission where those files would be stored ($ env | grep TMPDIR) must be set up with proper permissions to avoid security threats. So finally we can conclude that perhaps mkstemp() is the safest way to create temporary files as it creates and opens a unique file based on a filename template provided by the user combined with a series of randomly generated characters.

More detail information is available on Common Weakness Enumeration website.