One Reason You should hate Anti-Virus companies

Darn. After I signed up and downloaded the trial version of their product. It never stops sending me this stupid reminder, everyday. To stop this, you need to click a relatively small hyperlink at the bottom of the email to unsubscribe yourself.

It's a curse right?

Apa Macam Ni?

WASHINGTON (AP) -- The FBI is investigating a hacker attack on Citigroup Inc. that led to the theft of tens of millions of dollars, The Wall Street Journal reported Tuesday.

Citing anonymous government officials, the Journal reported that the hackers were connected to a Russian cyber gang. Two other computer systems, at least one of connected to a U.S. government agency, were also attacked.

Citigroup denied the report. "We had no breach of the system and there were no losses, no customer losses, no bank losses," said Joe Petro, managing director of Citigroup's Security and Investigative services. "Any allegation that the FBI is working a case at Citigroup involving tens of millions of losses is just not true."

The Journal reported that the attack on Citigroup's Citibank subsidiary was detected over the summer, although it may have occurred up to one year earlier. The FBI, the National Security Agency, the Homeland Security Department and Citigroup worked together to investigate the attack.

Cyber crime is of increasing concern to businesses and the federal government, with President Barack Obama calling it one of the "most serious economic and national security challenges we face as a nation."

Obama is expected on Tuesday to announce the appointment of Howard A. Schmidt, a former eBay and Microsoft executive, as the government's cyber security coordinator.

Using SHA-1 as message digest algorithm instead of MD5

In the light of a comment dropped by T.Rob in my previous post "A First Look at using MQ with SSL", I did some rough browsings about MD5 vulnerabilities and would like to share some of the links here.

Tim Callan's SSL Blog

SearchSecurity - VeriSign addresses MD5 flaws

Wiki - MD5

MD5 considered harmful today

The truth about the new attack on MD5 signatures

I guess for development purposes, it's ok for using MD5 based finger print/digital signature. We should now avoid using MD5 to perform critical application level hashing to prevent potential security issues. SHA-1 apparently is a better choice now even though it is theoretically vulnerable to the same issue albeit requires more significant processing power to do the trick.

Note that iKeyMan GUI, runmqckm (MQ 6.0) and Java keytool program uses MD5 as default signing algorithm.

For Java keytool, you can use the -sigalg SHA1withRSA option to override the default.

For strmqikm and runmqckm (MQ 7.0 uses sha1 by default, check here ), you can use GSKCapiCmd instead because it allows the specification of -sigalg sha1 to use SHA-1 algorithm


There's another way I found from the comments:

Option B is to acquire any IBM Java 6 JRE, add the IBMCMSKS provider to
java.security, and use the bundled ikeycmd or your /bin/gsk7cmd with
JAVA_HOME pointing at the new JRE -- sig_alg will be accepted there as well.

--
Eric Covener

MustGather information for Certificate problems

The following page provides useful information to diagnose problems with digital certificates.

http://publib.boulder.ibm.com/httpserv/ihsdiag/gather_certificate_doc.html#PKCS12

A First Look on using MQ with SSL

Secure Sockets Layer (SSL) technology is meant to provide a standardized solution to many security services such and authentication, confidentiality and integrity. Almost all distributed technology products nowdays comes with built-in SSL support. To name a few, IBM WAS, Apache Tomcat, Internet Explorer/Firefox and etc. Even sophisticated operating systems like i5/OS and z/OS has SSL integrated into the core.

The good thing about learning SSL is because SSL is one layer above TCP/IP (The transport protocol stacks) and below application layers such as HTTP, FTP, SMTP and blah, the concept is easily brings into new context.

I won't go deep into the major technical details of SSL in this post (maybe will do it in future posts), but there are a few jargons we need to share a common understanding. More information about these stuffs can be found in WIKI.

Certification Authority (CA) : A party designated to sign/issue digital certificates. Commercial CA such as Verisign.

Certification Revocation List (CRL): A list that stores the revoked/cancelled certificates

Digital Signature : A piece of information encrypted by the sender's private key.

Digital Certificate : A structure that complies to standards such as X.509 and includes also a digital signature

Certification Chain : A tree like relationship between signer CA, intermediate CA and ultimately the owner of the digital certificate.

Symmetrical Crytography : A branch of crytography focusing on shared keys.

Asymmetrical Crytography : A branch of crytography using non-shared keys to avoid key distribution issues.

SSL Handshake : A process in SSL protocol to establish SSL communications between SSL client and SSL server which includes negotiating algorithms, exchanging keys and encrypting messages.

SSL Key Store/Key Ring/Key Repository : A storage medium (usually a physical file) that keeps keys and certificates. Usually a password is needed to open the medium.

And many more terms as you delve into the realm.

I will assume the use of IBM Webpshere MQ6.0 and Windows XP.

---

In IBM Websphere MQ, SSL is only used during client mode communication. Bindings are direct and not involving SSL. More precisely, SSL can be configured for message channels and MQI channels. Message channels are meant for queue mangers (QMs)intercommunications and MQI channels are for MQ clients interaction with QMs.

Note: SSL is not used for access control purposes. In MQ, if you need to perform authorization checks, you might need to implement something called exits.

I will configure the following settings to demonstrate the usage of SSL for message channels (For MQI channels, it will be a future post by itself):

* 2 Queue Managers
* QM communications using Sender-Receiver channel pairs.
* 2 properly configured keystores, one for each of the QM.

The steps are:

1. Creating MQ QMs


2. Creating Key Stores


3. Creating Self Signed Certificates


4. Exchanging Certificates


5. Configuring QM


6. Creating and Configuring channels and listeners


7. Test out SSL connections

---

Assume %MQ_INSTALL_PATH% = C:\Program Files\IBM\Websphere MQ\

1. Creating MQ QMs
   
   Create 2 queue managers with name qm1 and qm2
   
   
   
   
   
   
2. Creating Key Stores
   
   I will be using GSKit iKeyMan utility that comes with Websphere MQ. Otherwise you might want to use other similar tools such as OpenSSL. The keystore format is CMS and their file name is ended with a .kdb extension.
   
   Command line version of iKeyMan is iKeyCmd (runmqckm)
   
   To run iKeyMan, proceed to command prompt and execute
   
   

   
   STRMQIKM
   

   
   
   
   
   
   
   
   
   
   
   Then choose from the menu bar [Key Database File] -> [New]
   
   Select [CMS] as the type, enter "qm1.kdb" as the file name as specify C:\ as the location for this example.
   
   
   
   You are required to key the key store password to protect your key store and you must tick the [Stash the password to a file?] option.
   
   The screen will looks like below once the keystore is successfully created and you can see that the iKeyMan preloaded some trusted CA certificates for you.
   
   
   
   
   As one of the best practice, you should remove all the preloaded certificates and remain only those necessary to prevent potential security issues.
   
   Repeat the above procedure for qm2's keystore with [CMS] type, "qm2.kdb" name and C:\ location.
   
   I recommend you to open another instance of iKeyMan (strmqikm) to avoid confusion when switching between key stores.
   
   


3. Creating Self Signed Certificates
   
   While you opened qm1.kdb in iKeyMan, from the [Key Database Content] filter, select [Personal Certificates], see below:
   
   
   
   Click on the [New Self Signed] button at right hand side and fill in the form like the screen below:
   
   
   
   In Windows platform, MQ will use the key label to identify which certificate to be used to authenticate a queue manager.
   
   The key label must be prefixed with "ibmwebspheremq" and then concatenated with the queue manager name, in this example "qm1", all in lower case. Here the key label is "ibmwebspheremqqm1".
   
   Repeat this step for qm2.kdb keystore but with the key label "ibmwebspheremqqm2".
   
   
   


4. Exchanging Certificates
   
   In the same screen, select [Extract Certificate] button.
   
   
   
   
   
   For ibmwebspheremqqm1 certificate, extract it to C:\qm1.arm
   For ibmwebspheremqqm2 certificate, extract it to C:\qm2.arm
   
   
   For qm1 keystore, import C:\qm2.arm by selecting [Signer Certificate] from the [Key Database Content] drop down and click [Add]. Specify "qm1.kdb" and C:\ as the location and when you click [Ok], a [Enter a label] message will prompt you to specify a label for the to-be imported signer. Enter "ibmwebspheremqqm2" and press [OK]
   
   
   
   The qm2 certificate will appear as one of the signer in the list.
   
   
   
   By now, your settings should be:
   
   

   
   -qm1.kdb (Keystore for Queue Manager qm1)
   --ibmwebspheremqqm1 (Personal Certificate for qm1)
   --ibmwebspheremqqm2 (Signer Certificate for qm2)
   
   -qm2.kdb (Keystore for Queue Manager qm2)
   --ibmwebspheremqqm1 (Signer Certificate for qm1)
   --ibmwebspheremqqm2 (Personal Certificate for qm2)
   

   
   
   


5. Configuring QM
   
   I will use RUNMQSC command line utility to perform most of the configuration. Of course, you can use MQ Explorer.
   
   Execute
   
   

   
   STRMQM qm1
   STRMQM qm2
   

   
   
   to start both of the QMs.
   
   
   
   Execute
   
   

   
   RUNMQSC
   

   
   
   to enter MQSC interactive session for qm1.
   
   Check out the current SSLKEYR attribute by executing
   
   

   
   DIS QMGR SSLKEYR
   

   
   
   
   
   By default, the value should be C:\PROGRAM FILES\IBM\WEBSPHERE MQ\QMGRS\qm1\ssl\key
   
   We will change it to point to our qm1.kdb.
   
   Exexcute
   
   

   
   ALTER QMGR SSLKEYR('C:\qm1')
   

   
   
   

   
   Note: Do not include the .kdb extension in the value of SSLKEYR.
   

   
   
   
   
   

   
   Note: I recommend you to open another instance of command prompt to work with qm2.
   

   
   
   
   Repeat this step on qm2.
   
   

   
   RUNMQSC qm2
   DIS QMGR SSLKEYR SSLEV
   ALTER QMGR SSLKEYR('c:\qm2') SSLEV(ENABLED)
   DIS QMGR SSLKEYR SSLEV
   END
   

   
   
   


6. Creating and Configuring channels and listeners
   
   Execute commands below for qm1.
   
   

   
   DEFINE QLOCAL('qm2') USAGE(XMITQ) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) TRIGDATA('TO.qm2')
   
   DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(10001)
   DEFINE CHANNEL('TO.qm1') CHLTYPE(RCVR) SSLCIPH(RC4_SHA_US)
   DEFINE CHANNEL('TO.qm2') CHLTYPE(SDR) CONNAME('localhost(10002)') SSLCIPH(RC4_SHA_US) XMITQ('qm2')
   
   START LISTENER('LISTENER.TCP')
   REFRESH SECURITY TYPE(SSL)
   

   
   
   
   Execute commands below for qm2.
   
   

   
   DEFINE QLOCAL('qm1') USAGE(XMITQ) TRIGGER INITQ(SYSTEM.CHANNEL.INITQ) TRIGDATA('TO.qm1')
   
   DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(10002)
   DEFINE CHANNEL('TO.qm2') CHLTYPE(RCVR) SSLCIPH(RC4_SHA_US)
   DEFINE CHANNEL('TO.qm1') CHLTYPE(SDR) CONNAME('localhost(10001)') SSLCIPH(RC4_SHA_US) XMITQ('qm1')
   
   START LISTENER('LISTENER.TCP')
   REFRESH SECURITY TYPE(SSL)
   

   
   
   


7. Test out SSL connections
   
   You can now test the connection by starting sender channel in each queue manager manually.
   
   To do this in qm1, execute the following:
   
   

   
   START CHANNEL('TO.qm2')
   DIS CHSTATUS('TO.qm2')
   

   
   
   To do this in qm2, execute the following:
   
   

   
   START CHANNEL('TO.qm1')
   DIS CHANNEL('TO.qm1')
   

   
   
   If the channel communications are successful, you will get screen similar to the one below:
   
   
   
   Pay particular attentions to the attributes
   
   

   
   STATUS=RUNNING
   SSLPEER=
   SSLCERTI=
   

   
   
   

   
   Note: If you need to change any of the SSL related attributes like key store location and channel SSL settings, remember to issue the following command:
   

   
   
   

   
   REFRESH SECURITY TYPE(SSL)
   

   
   
   

   
   Note: To troubleshooting problems, you can check out the QM error logs located at %MQ_INSTALL_PATH%\QMgrs\qm1\errors\
   

   
   
   

Security hole exposes utilities to Internet attack

By Jordan Robertson, AP Technology Writer

SAN FRANCISCO (AP) -- Attackers could gain control of water treatment plants, natural gas pipelines and other critical utilities because of a vulnerability in the software that runs some of those facilities, security researchers reported Wednesday.

Experts with Boston-based Core Security Technologies, who discovered the deficiency and described it exclusively to The Associated Press before they issued a security advisory, said there's no evidence anyone else found or exploited the flaw.

Citect Pty. Ltd., which makes the program called CitectSCADA, patched the hole last week, five months after Core Security first notified Citect of the problem.

But the vulnerability could have counterparts in other so-called supervisory control and data acquisition, or SCADA, systems. And it's not clear whether all Citect clients have installed the patch.

SCADA systems remotely manage computers that control machinery, including water supply valves, industrial baking equipment and security systems at nuclear power plants.

Customers that use CitectSCADA include natural gas pipelines in Chile, major copper and diamond mines in Australia and Botswana, a large pharmaceutical plant in Germany and water treatment plants in Louisiana and North Carolina.

For an attack involving the vulnerability that Core Security revealed Wednesday to occur, the target network would have to be connected to the Internet. That goes against industry policy but does happen when companies have lax security measures, such as connecting control systems' computers and computers with Internet access to the same routers.

A rogue employee could also access the system internally.

Security experts say the finding highlights the possibility that hackers could cut the power to entire cities, poison a water supply by disrupting water treatment equipment, or cause a nuclear power plant to malfunction by attacking the utility's controls.

That possibility has grown in recent years as more of those systems are connected to the Internet.

The Citect vulnerability is of a common type. Called a "buffer overflow," it allows a hacker to gain control of a program by sending a computer too much data.

"It's not a very elaborate problem," Ivan Arce, Core Security's chief technology officer, said in an interview. "If we found this thing -- and this was not that hard -- it would be easy for someone else to do it."

Citect is a subsidiary of French power-equipment giant Schneider Electric SA. Company representatives did not return repeated calls for comment.

Citect said in a statement included in Core Security's advisory that customers should isolate their SCADA systems entirely from the Internet or make sure they use firewalls and other technologies to prevent the systems from talking to the outside world.

Normally, the facilities that use SCADA systems fix flaws privately and very little is revealed publicly about any problems.

What's clear is that such control systems are increasingly vulnerable to Internet-borne threats, since viruses and worms have disrupted service in power plants, automobile factories and gasoline pipelines -- even when those facilities weren't targeted.

Alan Paller, director of research for the SANS Institute, which operates the Internet Storm Center, an early warning system for computer attacks, said Core Security Technologies' discovery shows many major facilities may remain vulnerable.

"It dashes the defense of, 'We're different, we don't have that kind of problem,'" Paller said. "That's why this is significant."

DB2 Audit Facility for Dummy

IT security auditors came and approached me, asking about DB2 user query activities, security events and blah blah. Let me see, o yeah, we got application specific audit trails. HR system got their own, ERP too and not forgetting that small little ETL program that IS people wrote. Of course, having domain specific audit facility is not a sin and they are one of the standard practice. However, DB2 provides an audit facility which is generic enough to capture almost any events happened in your databases.

Check out this DB2 program, located at <DB2_INSTALL_PATH>\bin

db2audit

Before you start to use db2audit, you should configure the AUDIT_BUF_SZ parameter in DBM configuration file. By the way, db2audit is controlled at Instance level. Setting AUDIT_BUF_SZ to non-Zero value indicates a multiple of 4KB. This is the buffer size before the audit records written to disk.

Then, you can check the current settings of db2audit, by using this command

db2audit describe

You will see something like below:

DB2 AUDIT SETTINGS:

Audit active: "FALSE "
Log errors: "TRUE "
Log success: "TRUE "
Log audit events: "TRUE "
Log checking events: "TRUE "
Log object maintenance events: "TRUE "
Log security maintenance events: "TRUE "
Log system administrator events: "TRUE "
Log validate events: "TRUE "
Log context events: "TRUE "
Return SQLCA on audit error: "TRUE "

AUD0000I Operation succeeded.

For example, if I just want to log audit events for authentication and authorization, both when success and failed, and rollback application if the system unable to generate the audit logs, perhaps due to system failure. Then I use this command:

db2audit configure scope checking,validate status both errortype audit

I will get the results below, when I submit "db2audit describe" again

DB2 AUDIT SETTINGS:

Audit active: "FALSE "
Log errors: "TRUE "
Log success: "TRUE "
Log audit events: "FALSE "
Log checking events: "TRUE "
Log object maintenance events: "FALSE "
Log security maintenance events: "FALSE "
Log system administrator events: "FALSE "
Log validate events: "TRUE "
Log context events: "FALSE "
Return SQLCA on audit error: "TRUE "

AUD0000I Operation succeeded.

You can enumerate the list of possible values for SCOPE, STATUS and ERRORTYPE by just typing "db2audit" and submit.

After configuring the audit facility, to start the facility

db2audit start

To stop the facility

db2audit stop

And, whenever you set AUDIT_BUF_SZ to non-ZERO, you should also use

db2audit flush

for writing the buffer to disk.

2 output file formats are supported by the native extraction: Flat and Delimited.

Use "db2audit extract" command to extract the logs. For example, if I need the audit records for authentication and authorization events, in comma delimiter format for database PROD, then I use the command below:

db2audit extract delasc DELIMITER , category checking, validation database

This will generates a list of files with .DEL extention in <INSTANCE_DIRECTORY>\security folder. You can load the files into database by using LOAD or IMPORT utility.

Audit file will grows over time and you need to perform house keeping on it occasionally. To remove all audit records, use

db2audit prune all

Or more likely you will want to remove records prior to certain date.

db2audit prune date YYYYMMDDHH

E.g. db2audit prune date 2007050100 will delete all records where date prior to 1-May-2007.


Lastly, additional information you might need to aware of

Only SYSADM group members can perform auditing actions

Audit Configuration File located at <INSTANCE_DIR>\security\db2audit.cfg, and it is in binary format

Audit Log File located at <INSTANCE_DIR>\security\db2audit.log, and it is in binary format

By setting DB2INSTANCE environment variable, you can configure audit for different DB2 instances

IBM Data Warehouse Edition DWH Password Maze

Stringent user account security policy in the network domain can cause damaging maintenance headache in deployed IBM DWH multiservers environment. User account information are all around the places, in your DB2 services, WAS server, Alphablox and so on. The day when the user passwords expired or required account disabled, it will be the day DWE solutions face total outrage. Well, may be I'm just exaggerating.

Where do you update the user credentials in DWE environment when such a need arise?

Briefly speaking, at least the following locations:

1. DB2 Windows services, assuming Windows environment

Log On As for each DB services need to be updated.


2. Websphere Global Security Setting, assuming using LocalOS repository

This can be tricky. The easiest is to update the password before you shut down the WAS server. If the server already shut down and you didn't manage to update the password, then you wouldn't be able to start the server again because of authentication error. If this is the case, you got to manually disable the WAS global security by changing the "enabled" attribute of security:Security xml element to false in security.xml file located in /config/cells/Cell. Then start the server, update the password in LocalOS setting and turn on Global Security again by checking on the option in WAS Admin Console.

3. Data Sources defined in DWE Admin Console

Data Sources used by DWH application processes, which are not attached to WAS data source, must be updated.

Before you can perform this, you need to update the J2C user password in WAS for Admin Console to be able to connect to its repository. (Item 6)

4. Data Sources defined in Alphablox Admin Console

Usually this will be data sources for Alphablox cubes to retrieve IBM Cube Views meta data.

5. WAS account used by Alphablox for management

Alphablox uses a WAS user credential for connecting to WAS and managing Alphablx applications in WAS. This piece of information is located in Alphablox repository, /servers/AlphabloxAnalytics/server.properties.

Replace the line ws.admin.password.protected with ws.admin.password=<your_password_in_plaintext>

The issue here is that the new password will be in clear text. I read across some materials that say the password is encoded again the next time the server restarted. However, I don't see that happens in my environment.

6. WAS J2C Authentication entries

7. WAS JNDI Data Sources, assuming not using J2C authentication

8. Optionally, WAS Windows Services


Hope this is helpful to you.

Information Security Consciousness in Malaysia

I recently ran a network scan on some of the local IP segments in Malaysia, the results are within my expectation, i.e. quite a number of broadband service subscribers in Malaysia doesn't realize about the risks of their computers being exploited in the Internet, or maybe they just not literate enough to have such awareness. I seen file servers that are exposed to the Internet and yet share out some folders that store critical information like daily transaction files, quotations, and even human resources payroll data files. What will happen if I'm one of those destructive people that just go in and wipe everything out? Voila, they better have a pretty good business continuation strategy. Also, one thing I noticed is that these machines usually infected by some dated viruses and trojan horses like NetBus and BO. O yes, I forgot to mention that gigabytes of porn materials and illegal software are found in these HDD.