Tuesday, March 30, 2010

How to configure an IPsec tunnel between a Cisco router and a Checkpoint Firewall


Complete these steps to set up the IPsec VPN tunnel:

1. Configure the Internet Key Exchange (IKE) proposal on both devices.

2. Configure the IPsec parameters on both devices.

3. Specify network ranges on both devices for passing traffic across the proposed tunnel.

For assistance with the configuration settings, resolving an IPsec tunnel between a Cisco router and Checkpoint Firewall as well as specific debug setting information, refer to Configuring an IPSec Tunnel Between a Cisco Router and a Checkpoint NG.

Once the tunnel is configured, attempt to pass traffic from a workstation on one side of the connection to a workstation on the other side of the connection. If you are able to ping, the tunnel is functioning properly. If you are not able to ping, determine the state of the connection by issuing the
show crypto isakmp sa and show crypto ipsec sa commands on the PIX Firewall.

If the show crypto isakmp sa command output shows anything other than QM_IDLE in the state, then phase 1 (Internet Security Association and Key Management Protocol [ISAKMP]) has not been properly negotiated and should be examined.

The results should resemble this example:

cisco_endpoint#show crypto isakmp sa

dst src state pending created QM_IDLE 0 2

The show crypto ipsec sa command identifies information about phase 2 of the connection (IPsec).

The proper peer and local endpoint for the tunnel should be identified. Furthermore, if traffic has been passed across the tunnel, the counters for both pkts encaps and pkts decaps should be incrementing. If either value is not incrementing, a determination can usually be made as to which side of the tunnel is having difficulty.

Given below is a portion of the command output:

cisco_endpoint#show crypto ipsec sa
interface: outside
Crypto map tag: rtpmap, local addr.
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
PERMIT, flags={origin_is_acl,}
#pkts encaps: 20, #pkts encrypt: 20, #pkts digest 20
#pkts decaps: 20, #pkts decrypt: 20, #pkts verify 20
#pkts compressed: 20, #pkts decompressed: 20
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

Thursday, March 25, 2010

shows the total number of accounts in zimbra

Login as root

root@mail:~# su zimbra

zimbra@mail:/root$ zmaccts

How to changes Zimbra Logon picture

Just put your custom logo .mg files on /opt/zimbra/jetty-6.1.5/webapps/zimbra/skins/_base/logos/LoginBanner.png , don’t forget to changes the files owner to zimbra:zimbra

if you want to edit logo url or page you can edit the skin.properties go to

edit this line :
LogoImgDir = /zimbra/skins/@SkinName@/logos
LogoURL = http://www.yourcompany.com

You can also changes the other modifcation on the login pages on /opt/zimbra/jetty-6.1.5/webapps/zimbra/WEB-INF/classes/messages/ZmMsg.properties

Setting maximum mail recipients in zimbra

To adjust:

su - zimbra
postconf -e 'smtpd_recipient_limit = 1000'

To apply settings:

postfix reload

To check current settings:

postconf | grep smtpd_recipient_limit


smtpd_recipient_limit (default 1000) parameter controls how many recipients the SMTP server will take per message delivery request.
-You can't restrict this to a to/cc/bcc field - it's all recipients. For that you'd have to use a regular expression in header_checks to arbitrarily limit the length of each header to something reasonable. (We could do this in the web-client though if someone wants to open an RFE in bugzilla.)

smtpd_recipient_overshoot_limit (default 1000) - The number of recipients that a remote SMTP client can send in excess of the hard limit specified with smtpd_recipient_limit, before the Postfix SMTP server increments the per-session error count for each excess recipient. "Postfix will 4xx the 'overshoot' addresses so a sending MTA can try them again later."

Then see the smtpd_hard_error_limit (default 20) parameter to know at what number of errors it will disconnect.

So you technically need to consider like 3 values here - which affect both inbound & outbound mail.

(I've heard of an smtpd_extra_recipient_limit but I've never used it / might just be for in queues.)

Then there's the throttling tools:

smtpd_client_recipient_rate_limit (default: 0 no limit) - The maximum number of recipient addresses that an SMTP client may specify in the time interval specified via anvil_rate_time_unit (default: 60s -careful adjusting this affects other things)" and note that this is "regardless of whether or not Postfix actually accepts those recipients" Those over will receive a 450 4.7.1 Error: too many recipients from [the.client.ip.address] It's up to the client to deliver those recipients at some later time.

It may prove prudent to also adjust:
smtpd_client_connection_rate_limit (default: 0)- The maximal number of connection attempts any client is allowed to make to this service per time unit. The time unit is specified with the anvil_rate_time_unit configuration parameter.
smtpd_client_message_rate_limit (default: 0) - The maximal number of message delivery requests that any client is allowed to make to this service per time unit, regardless of whether or not Postfix actually accepts those messages. The time unit is specified with the anvil_rate_time_unit configuration parameter.

The purpose of these features are to limit abuse, as opposed to regulating legitimate mail traffic, but some use them that way.

There's also Policyd which can do sender-(envelope, SASL, or host / ip)-based throttling on messages and/or volume per defined time unit, plus recipient rate limiting.

To adjust:

su - zimbra
postconf -e 'smtpd_recipient_limit = 1000'
To apply settings:
postfix reload
To check current settings:
postconf | grep smtpd_recipient_limit
Note: When your looking this up, smtpd_recipient_limit is not to be confused with default_destination_recipient_limit parameter, which controls how many recipients a Postfix delivery agent will send with each copy of an email message. If an email message exceeds that value, the Postfix queue manager breaks up the list of recipients into smaller lists. Postfix will attempt to send multiple copies of the message in parallel. So that really isn't limiting the number of addresses, it just breaks it into chunks for other servers to accept easier

Change password zimbra user using zmprov

zmprovToday I was so sad cause the internet connection from home is too late, and when my user mail need help to change the password I have difficulties to access the administrator page from web. And I try to change the password directly from the server command. Ciayooo that is easy to do it…

Login to server as # root , than do su zimbra and follow the command below :

Create one account with a password that is assigned to the default COS:
zmprov ca name@domain.com password

Create one account with a password that is assigned to a specified COS. You must know the COS ID number. To find a COS ID, type gc .:
zmprov ca name@domain.com zimbraCOSid

Create one account when the password is not authenticated internally:
zmprov ca name@domain.com

Change the administrator’s password. Use this command to change any password. Enter the address of the password to be changed:
zmprov sp admin@domain.com password

To list all COSs and their attribute values:
zmprov gac -v

To list all COSs and their attribute values:
zmprov gaa domain.com

To list all user accounts and their configurations:
zmprov gaa -v domain.com

Zimbra – operating, how to


Zimbra resides in the /opt/zimbra directory, this directory can be migrated between servers as long as the architecture is the same (32bit vs 64bit)

Required Ports
Remote Queue Manager 22
Postifix 25
POP3 110
IMAP 143
LDAP 389
Mailbox IMAP 993
Mailbox POP SSL 995
Mailbox LMTP 7025

./install.sh installs the zimbra
./install.sh -u uninstalls zimbra
./install.sh -s reinstalls the configuration files
but does not touch the data
configuration file /opt/zimbra/config.xxxxx contains all passwords and needs to be backed up for disaster recovery and /opt/zimbra/conf/ localconfig.xml

Upgrade procedure
1. su – zimbra
2. zmbackup –a all –t /tmp/ -s mail.domain.com
3. check the status of the backup - tail /opt/zimbra/log/mailbox.log
4. check zimbra services – zmcontrol status
5. stop zimbra services – zmcontrol stop
6. check for any hanging processes – ps waux | grep zimbra
7. kill any processes that were not stopped – kill -9 procID
(any leftover processes that were not stopped with “zmcontrol stop” command
should be investigated as they can possibly indicate more serious issues)
8. run installer - ./install.sh
9. check logs - tail /opt/zimbra/log/mailbox.log

1. zmschedulebackup – command to schedule backups

2. /etc/crontab – has a list of all zimbra crons
3. zmbackupquery – lists all backups, status of the backup

4. tail /opt/zimbra/log/mailbox.log – to check the log for the backup

5. zmbackup -f -a all -s mail.domain.com – (-f full, -a account, -s server);
this will perform a full backup on all domains on server domain.com

1.In disaster recovery restore LDAP info first
2. zmbackupquery - to find out the label
3. zmrestore -lb labelhere -a admin@domain.com -ca -pre restored_
(this will restore the admin mailbox with a new name,restored_ admin@domain.com)
4. ldap password - less /opt/zimbra/config.7835
5. reset ldap password –
> zmcontrol start
> zmldappasswd -r newpass
> zmldappasswd newpass


most of commands are issued as a zimbra user,

zmdumpenv -p - to find out all information about the server
zmlicense -p - to see the license
zmzimletctl listzimlets all - lists all zimlets
zmprov sp admin@domain.com password - reset admin password
zmprov ca - create account
zmprov aaa - addaccount alias
zmprov -h - help
cd /opt/zimbra/libexec/ ./zmfixperms – fix permissions
(su –root, chown -R zimbra:zimbra /opt/zimbra, cd /opt/zimbra/libexec,./zmfixperms)
zmstat-chart -s /opt/zimbra/zmstat/2008-03-16/ -d /tmp/charts/ - create charts


/opt/zimbra/conf/log4j.properties.in – change level of logging

/opt/zimbra/logger/db/data/mail.domain.com.err - logger
/var/log/zimbra.log - Mail delivery, Postfix
/opt/zimbra/log/audit.log - logs connection and SOAP requests
/opt/zimbra/log/clamd.log - checks if messages are deferred (not delivered)
/opt/zimbra/log/freshclam.log - clam av log
/opt/zimbra/log/httpd_access.log - log for aspell only
/opt/zimbra/log/mailbox.log - MAIN LOG; mailbox delivery and storage,
socket connection,jettylog, jabber
/opt/zimbra/log/zmmailboxd.out - java log file


Slowness reasons

- Postfix queue backup
- MySQL slowquerries (myslow.log)
- Process CPU utilization
- Client responsive time by protocol
- Disk utilities
- Database connections – poll latency
- Cache hitrates
- Database connections in use
- InnoDB buffer pool hit rate
- JVM heap activity
- Thread dump


exhaustive how to: http://files.zimbra.com/docs/skins/index.html

1. location of static logos
2. Customizing login page:
set the following:
clientLoginNotice = Service provided by domain Inc
splashScreenCopyright =
zimbraLoginTitle = Log In
zimbraLoginMetaDesc = domain.com
3. favicon.ico

1. cat /opt/zimbra/log/audit.log | grep "authentication failed" | wc -l
(for brute force attacks, possibly setup a cron job and have it mailed)
2. any script that has an extension .init (/opt/zimbra/libexec)
will reinstall the service. Use it with caution

Friday, March 12, 2010

Spam Filter

su - zimbra
vi /opt/zimbra/conf/salocal.cf.in

header DSPAM_SPAM X-DSPAM-Result =~ /^Spam$/
describe DSPAM_SPAM DSPAM claims it is spam
score DSPAM_SPAM 1.5

header DSPAM_HAM X-DSPAM-Result =~ /^Innocent$/
describe DSPAM_HAM DSPAM claims it is ham
score DSPAM_HAM -0.5

%%uncomment VAR:zimbraMtaMyNetworks%%trusted_networks %%zimbraMtaMyNetworks%%
%%uncomment VAR:zimbraMtaAntiSpamLockMethod%%lock_method %%zimbraMtaAntiSpamLockMethod%%

rewrite_header Subject *SPAM* _STARS(*)_
bayes_auto_learn 1
bayes_min_spam_num 60
bayes_min_ham_num 60
add_header spam Flag _YESNOCAPS_
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
add_header all Level _STARS(*)_
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME
blacklist_from *@capp.ch
blacklist_from *@the-machine.net
blacklist_from *@accedoconsulting.com
blacklist_from *@veloxzone.com.br
blacklist_from *@allaboutfaces.com

zmmtactl stop ; zmmtactl start

Locked status and error messages

1. Login as #root

2. Change to zimbra user#su zimbra

3. Copy this code $ vi /opt/zimbra/jetty-6.1.5/webapps/zimbra/WEB-INF/classes/messages/ZMsg.properties

4. Find this account.CHANGE_PASSWORD = Your password in no longer valid. Please choose a new password.

Wednesday, March 10, 2010

Delete mails via cli based on date

It then uses zmmailbox to search for emails meeting the criteria that you put in the variables, uses sed to trim and create a temp file containing the messageID of the messages to delete, then uses zmmailbox again to parse the temp file, and delete the messageIDs.

I've found that even though I've set the search -l to 100000, it only deletes approx 2500 at a time. I'm not sure why. That's why it prompts for a loop in the end.

Remember to su to zimbra.

Feel free to rip me apart for my week skills. I'm sure there is plenty of room for improvement, and I'd like to hear it.

Here it is:

#version .1

echo "Enter the username.:"

echo "Enter the time that you would like to delete messages up to, in mm/dd/yy format. Example 04/10/09:"

echo "What folder would you like to delete these messages from?:"

echo "You will now be deleting Messages from the $THEFOLDER folder up to $THEDATE for $THEACCOUNT."
echo "Do you want to continue? (y/N): "
read ADD

themagic ()
touch /tmp/deleteOldMessagesList.txt
for i in `$ZIMBRA_BIN/zmmailbox -z -m $THEACCOUNT search -l 100000 "in:/$THEFOLDER (before:$THEDATE)" | grep conv | sed -e "s/^\s\s*//" | sed -e "s/\s\s*/ /g" | cut -d" " -f2`
if [[ $i =~ [-]{1} ]]
echo "deleteMessage $MESSAGEID" >> /tmp/deleteOldMessagesList.txt
echo "deleteConversation $i" >> /tmp/deleteOldMessagesList.txt

$ZIMBRA_BIN/zmmailbox -z -m $THEACCOUNT < /tmp/deleteOldMessagesList.txt >> /tmp/process.log
rm -f /tmp/deleteOldMessagesList.txt
echo "Completed. Run again for same user?"
read ADD

while expr "$ADD" : ' *[Yy].*'
do themagic

Tuesday, March 9, 2010

Add alert when account locked

The script ships with 4 authentication failure checks.
- IP/Account hash check which warns on 10 auth failures from
an ip/account combo within a 60 second window.
- Account check which warns on 15 auth failures from any ip
within a 60 second window. Attempts to detect a distributed
hijack based attack on a single account.
- IP check which warns on 20 auth failures to any account
within a 60 second windows. Attempts to detect a single host
based attack across multiple accounts.
- Total auth failure check which warns on 1000 auth failures
from any ip to any account within 60 seconds. The recommended
value on this is guestimated at 1% of active accounts for the MBS.

Edit file /opt/zimbra/conf/auditswatchrc.in or All values can be
tuned via zmlocalconfig parameters.

zimbra_swatch_ipacct_threshold=10 (max failures for an IP & account pair)
zimbra_swatch_acct_threshold=15 (max failures for an account)
zimbra_swatch_ip_threshold=20(max failures for a specific IP)
zimbra_swatch_total_threshold=60(all failures max trigger count)
zimbra_swatch_threshold_seconds=60(the duration window it has to happen in)

zmlocalconfig -e zimbra_swatch_notice_user=admin@domain.com
/opt/zimbra/bin/zmauditswatchctl start

Sau khi chỉnh sửa :
su - zimbra
postfix reload

Monday, March 8, 2010

Monitor Zimbra

1. Zimbra Logging Levels
- FATAL : being unable to contact the MySQL database
- ERROR : a single mailbox having a corrupt index or being unable to delete a message from a mailbox
- WARN : user log in failed
- INFO* : server startups,mailbox creation/deletion,account creation

tail -f /opt/zimbra/log/audit.log | grep WARN | more

2. Reviewing mailbox.log Records
- Mailbox.log records valid and invalid login attempts, account activity such as opening email, deleting items, creating items, indexing of new mail, server activities including start and stop

3. Handler Exceptions and Stack Traces
- If an error occurs during the progress of an activity, a handler exception is
added to the end of the basic log record to notify you that an event occurred
during the execution of the process that disrupted the normal flow.

- Sometimes a stack trace is displayed after the exceptions notification. A stack logs the process in detail. A stack trace is a report of the threads and monitors in the zimbra’s mailboxd service. This information aids in debugging, as the trace shows where the error occurred. The last few entries in the stack often indicate the origin of the problem. When the caused by descriptor is included in the log line, this is the root of the error. In the example below, the error was caused by 501, bad address syntax.

007-06-25 00:00:10,379 INFO [btpool0-1064] [name=nriers@example.com;
mid=228;ip=;ua=zimbra Desktop/0.38;] SoapEngine - handler

4. Mailbox log files
- To review the mailbox.log for errors, search for the email address or the
service that is experiencing the problem. Also, search for WARN or ERROR
log levels, read the text of the message. When you find the error review the
records, tracing the events that happened before the problem was recorded.

Service Error - System Crashing
- When your system crashes, look for the startup message and after finding that
message, look for errors before the startup message date

Mail Error - Mail Delivery problem
- When you are looking for an error in mail delivery, start by looking for the
“LmtpServer” service

Account Error- Log in error
- Mailbox.log logs any successful or unsuccessful login attempts from IMAP,
POP3 or ZWC. When you are looking for a login error, start by looking for

Account Errors - IMAP or POP related
- When you are looking for a log because of an IMAP or POP issue, look for

Friday, March 5, 2010

Security in SMS Banking


SMS Banking

When people are hard pressed for time, the need for "anytime anywhere" banking gains utmost importance. Bearing this in mind, banks provide a novel service which gives retail customers account information and real-time transaction capabilities from their cell phones. With SMS banking the following services can be obtained:

  • Get account balance details
  • Request a cheque book
  • Request last three transaction details
  • Pay bills for electricity, mobile, insurance etc.

Part one of this two part series covers the SMS banking overview, the components involved as well as the secure network architecture in SMS banking scenarios.

SMS Banking Overview

In order to avail the services mentioned above, a user subscribing to a wireless carrier sends an SMS with a predefined code to the bulk service provider’s number.

Mobile Banking Architecture
Fig 1: Mobile banking architecture

The service provider forwards this message to the bank’s mobile banking applications. The mobile banking applications interface with the core banking servers (that contain the user account information) that service the request made by the user. The response is then sent by the mobile banking applications to the bulk service provider who in turn forward it to the valid user via SMS.

There are two ways in which a bank can communicate with a customer using SMS:

  1. In the first method the bank proactively sends data to customers in response to certain transactions. For e.g. account to account transfer, salary credit and some promotional messages. This data can be sent to the customer in two ways
    • E-mail to mobile (E2M) : In this method, the bank sends an email to the mobile banking application through a specific email address. This email may consist of the message content together with the mobile numbers of the customer. The mobile banking application in turn sends this message in a specific format (for e.g. XML tags are part of a HTTP GET message query string) to the service provider’s application server. From hereon the information from the XML tags is extracted and sent as a SMS to the wireless carrier which in turn forwards this message to the customer.
    • Database to mobile (D2M) : Here a mobile banking application continuously polls the banks database server and whenever a relevant event happens, for e.g. an account to account transfer, it forwards the specific message to the service provider’s application server. The message format may be the same as the one used in the E2M case. This message is then forwarded to the wireless carrier which in turn forwards this message to the customer.
  2. In the second method the bank sends data in response to specific customer query such as account balance details. The customer first sends a pre-defined request code via SMS to the Bulk SMS service provider’s registered mobile number. Depending on the message code, the bulk SMS provider forwards the SMS to a PULL application in the mobile banking server. The PULL application receives the request and forwards it to the core banking application for further processing. The core banking server then processes this message and sends the reply to the PULL application which in turn forwards in to the customer via the service provider. As in the above cases the request and the response for the PULL application may be a HTTP GET message with XML tags in the query string.

Secure Network Architecture for mobile banking applications

The following is a diagram shows a structural design for the mobile banking scheme.

Secure Mobile Architecture

In the above diagram the 2-way SSL link between the service provider and between the mobile banking application and the service provider and also between the service provider and the wireless carrier ensures confidentiality of data. The email message sent by the bank is PGP encrypted and signed in order to ensure confidentiality and integrity of data.

The following diagram shows the recommended placement of the SMS banking components in the banking infrastructure.

Mobile Banking Components

In the above diagram, the E2M component is placed in the mail server which is present in the Internet Banking DMZ. It receives the email message from the mail server which is then forwarded to the service provider in the specified format over the SSL link. The D2M component in placed in the inner core-banking segment as it continuously polls the banking database for event related triggers as explained above. Finally the PULL component in placed in the Internet Banking server as it receives the message from the bulk service provider through a SSL link over the internet.


In this part of the SMS banking series we discussed the different components in SMS banking and the secure network architecture including placement of the different components in the infrastructure. In the concluding part of the series we will look into the application security perspective in the mobile banking application.

Mobile Banking Architecture

This two-part series on mobile banking security will help Bank security officers and auditors understand the security threats in Mobile banking. Here, I will present two popular mobile banking architectures and dive into the exchange of messages between the components. Next month, we will look at the threats inherent in this architecture and how to mitigate them.

The concept is different from SMS Banking which was discussed previously. The architecture is based on the specific requirement that the facility is provided through GRPS, GSM, CDMA, EDGE, 3G and CSD enabled mobile phones.

With Mobile banking, the following services can be availed of, but is not restricted to,

  • Viewing A/C statement
  • Viewing Cheque Status
  • Stopping Cheque Payment
  • Cheque Book Request
  • Fixed Deposit Enquiry
  • Bill Payment
  • Shopping/ Purchasing items

The services can be provided to customers directly by the bank or through a 3rd party vendor; and explanations for both are followed.

Mobile Architecture 1
Architecture 1: When the bank provides the service directly to the customer

The setup will have a web server, application server and the database at the bank’s premises. We shall call this the mobile banking server for ease of understanding.

The application will ensure what services are to be provided to the customer. Based on the banking services provided to the customer, the security of the infrastructure has to be built in. The database can be the same as the Core Banking database, having another table for mobile banking users.

The customer uses his/her mobile phones to transact through the mobile network. The Mobile banking server in turn talks to the Core banking systems of the bank for user authentication, processing transactions, authorization, etc.

Mobile Architecture 2
Architecture 2: When banks outsource this facility to 3rd party vendors

This is the more popular architecture as Banks can quickly roll out their mobile banking solutions by connecting to a 3rd party. This is also the architecture with more security issues as interconnection with a 3rd party is involved. In this architecture, the mobile banking servers are located at the 3rd party vendor’s data centre. These servers will talk to the Core Banking servers of the bank through a secured channel (dedicated or shared link) for authentication, authorization and transaction processing.

Pre requisites to using this facility

The customer has to first register with the Bank for using Mobile banking facility by linking the user’s mobile number with the account number.

Application functionality

The mobile banking facility can be provided to mobile phone users through a client or a web based access. Using the client or web browser, the necessary security features are to be built.

Customer performs banking transactions based the services like check account balance, fund transfer, bill payment, shopping, etc provided by the bank.

Mobile Message Exchange
Exchange of messages when a 3rd party provides the service to the bank’s customers

User Authentication

  1. User uses the browser or the client to connect to the mobile banking server located at the 3rd party site. The connection over the mobile network is encrypted using public/private key. The public keys can be transferred during the client installation on the mobile phone or when the client first communicates with the server using the browser.

  2. The mobile banking server asks for authentication. Here, there can be multiple layers of authentication, one authentication for the 3rd party and another for the bank.

    1. The credentials required for the 3rd party should be encrypted by the client-side application using the 3rd party’s public key
    2. The credentials required for the bank should be encrypted using the bank’s public key

    Authentication can be based on both the 3rd party and bank’s credentials or just the bank’s credentials. Choosing the dual or single authentication depends on the role played by the vendor. If the vendor also requires authentication for its records and for other services it provides to customers, then having different authentication mechanisms should be a good idea.

  3. If both credentials are required, then user has to register with vendor by providing personnel details like name, e-mail-id, mobile number and bank account number; and creates an ID/PIN for the mobile user. These credentials can be used for authentication with the vendor. If only bank’s credentials are required, then these are encrypted by the bank’s public key and transmitted. The server will then forward the encrypted data to the bank’s server.

    1. If the vendor provides this infrastructure to multiple banks, the bank name should be encrypted using the vendor’s public key, so that it can pass the data encrypted by the bank’s public key to the correct bank.

    The idea behind having different encryption keys is to ensure that only data required by the vendor is accessible only to the vendor and the rest of the data is only available to the bank.

  4. Mobile user is authenticated with the mobile banking server at the vendor.

  5. The credentials entered by the user which is required for authentication with the bank is forwarded to the bank.

  6. The bank authenticates the user and provides a list of services which is available to the mobile banking server.

  7. The mobile banking server forwards the data to the mobile user.

User requesting a transaction

  1. The user selects the service he wants to perform like check account balance, bill payment, etc.

  2. The mobile banking server asks for re-authentication for critical transactions.

    1. Re-authentication with the mobile banking sever ensures that critical transactions are verified and mapped to the user.
    2. The re-authentication can be restricted with the vendor only; the user need not authenticate with the bank every time a transaction is performed. Again this depends on the role played by the vendor.
  3. User re-enters the credentials.

  4. Server authenticates the mobile user and forwards the data to the bank on how to process the mobile user’s service request.
    For e.g., checking the account balance service, the mobile banking server will contact the bank’s server on how to process the request.

Bank processing the transaction

  1. The bank server will ask for details required to service the user request

    1. Taking the above example, the bank will ask for cheque number and this is forwarded by the mobile banking server to the end user.
  2. The end user enters the details and sends it to the mobile banking server.

  3. The server again asks for authentication. Once authenticated, the mobile banking server will forward the cheque number to the bank’s server.

    1. This can be an optional check based on the criticality of the service requested. For e.g., if the bank provides fund transfer service, then it may be a good idea to again check for the user’s credentials. Again this is purely based on the criticality of the service provided
  4. The bank’s server will check the status of the cheque and provide the details to the mobile user via the mobile banking server.

Finally, this is just an example to show how the application should process requests from the mobile user. Based on the services provided by the bank, the security of the application can be built-in. For e.g., if the application allows fund transfer or bill payment, then the required security threats should be identified and mitigated.

In my next article, I’ll be discussing these aspects and also how to mitigate the threats observed while using this facility. The article will focus on security of some services provided by the bank like cheque request, account balance, mobile shopping, etc. Also how data is protected over during transmission and storage will be discussed.

The important part is maintaining Confidentiality, Integrity and Availability while using this facility without comprising on functionality.

Defeat SSL Using Null Prefix Attack

This article is about defeating SSL using Man in the Middle (MITM) attacks against SSL / TSL emulating certificates due to flaws in the operating mode of the Network Security Services (NSS). NSS is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. The possible targets for MITM tools are like Firefox, Internet Explorer, Chrome, Outlook, Evolution and any other tool that makes use of the libraries / API’s listed above.

Man in the Middle (MITM) Attack

When we access the URL www.paypal.com from a web browser, the server responds by sending the SSL certificate. Firstly, the SSL implementation at the client checks is the Subject field in the certificate it received, against the domain URL which it is trying to connect to, and to provide authenticity.


An attacker can perform MITM attack and respond to the client when www.paypal.com is requested. But attacker cannot send a certificate for www.paypal.com, still he can send the actual PayPal certificate to client with public key embedded in it. He cannot decrypt the traffic because he doesn’t know the corresponding private key for that certificate. To gain profit, he needs to own a certificate for www.paypal.com.

Obtaining a Certificate

One can obtain certificates for his/her domain from Certificate Authority (CA) like Thawte or VeriSign. If the domain is to be signed, he has to submit the Certificate Signing Request (CSR). Certificate Signing is a simple structure defined in PKS#10 as shown.


At Thawte or VeriSign, the CA would check for the Subject, which is the exact entity for which the certificate is issued. Let’s say that we submit CSR for www.site.bankofameica.com where the Common Name is www.site.bankofamerica.com. The CA would look at the root domain (bankofamerica.com) and ignore the subdomain (www.site). Then the CA will do whois lookup for the root domain and contact the administrator of that domain to verify whether he is authorized to get signed to the domain or not. Since the subdomain is ignored by CA, we can request for signing a certificate with Common Name: xxxxxxxx.attackersite.com, xxxxxxxx could be anything. Still the CA checks for attackersite.com and signs the certificate.

For carrying out a MITM attack, we need a certificate for paypal.com but we don’t own paypal.com to get a certificate. However, we can obtain a certificate for paypal.com\0.attackersite.com. The CA will look only at the root domain attackersite.com, do a whois lookup and contact the administrator of attackersite and finally sign the certificate.


Now the attacker, being MITM, can forward the Hello from the client to the server and send the client the certificate of www.paypal.com\0.attackersite.com. Since the certificate has been issued by a trusted CA, the client accepts it and the attacker can sniff the whole traffic successfully.

How does it work?

When the client requests for www.paypal.com, the attacker, as MITM between the client and the server, will respond to the client by sending the certificate of www.paypal.com\0.attackersite.com. The browser compares the destination URL and Subject field of the Certificate to authenticate.

The code at the client browser would look like:
char *destination = getDomainWeAreConnectingTo();

char *commonName = getCommonNameFromCertificte();

bool everythingIsOk = (strcmp(destination, commonName) == 0);

The destination would be destination URL typed in the URL bar and commonName would be the Subject value of the certificate. A pointer will check both destination and commoName. The strcmp function will check every character of these values till it reaches the end of the string denoted by nocharecter “\0”. Hence the browser accepts the certificate and authenticates the server.

SSL Implementations Affected

The certificate obtained by this technique is valid for most of the SSL implementations, such as

  • Web Browsers: Firefox, IE, Chrome, Lynx, Curl
  • Mail Clients: Thunderbird, Outlook, Evolution
  • Chat Clients: Pidgin, AIM, irssi, centericq
  • SSL VPNs: AEP, Citrix, etc

Further Attack Deployment

Suppose an attacker wants to get the entire confidential data of all domains from the network. For this, the attacker will have to perform a MITM attack for each of the domains. It would seem that the attacker has to obtain certificates for all the domains. Instead he can obtain a single certificate and still be the man in the middle and sniff all the SSL traffic. This is possible by getting a certificate for *\0.attackersite.com. This certificate will match any domain the client is trying to connect to. The attack even works for *~.attackersite.com. Similarly the attack can be carried out for selective domains by grouping the domains and obtain a certificate for something like (www.paypal.com|www.etrade.com|www.bankofamerica.com|…)\0.attackersite.com.

Patches and Updates

Thousands of products are still vulnerable to this Null Prefix attack. More information about the patches to this attack can be found at:

Tuesday, March 2, 2010

In File PDF Trên Ubuntu

Sử dụng okular để mở và in file pdf chứa ảnh. Một số phần mềm evince , Adobe reader và epdfviewer cài đặt trên ubuntu sẽ in file pdf rất chậm.