WebApp Sec mailing list archives

RE: Help Exploiting MQ


From: Robert.L.Grill () wellsfargo com
Date: Wed, 1 Sep 2004 21:09:51 -0700

MQ relies mostly on encryption for security, usually works in conjuction
with JMS.  Will probably be replaced by SOAP.

Would love a fake MQ packet generator.  IBM has some good rebooks on MQ.
Wrote this article a while back.


JMS and MQSeries Security

In Risk Analysis, the fear of the unknown is a factor in the decision
making.  Often an unknown is a new technology that users don't see but
happens behind the scenes.  An example of this is a new paradigm in
application interfacing called Java Messaging Services (JMS), it has been
gaining popularity, and because it usually only takes place behind corporate
networks, it has not received much attention from the security community.  

JMS is a set of standard Application Programming Interfaces (API) that are
used as a common language (or protocol) for enabling applications to
communicate with each other across platforms and applications.  JMS provides
the API's but it does not provide the routing across the network.  The
routing is accomplished by a program such as MqSeries (MQ), JMS written for
MQ evaluates the content of messages and routes them to the appropriate
application.

Data sent by one program can be stored in a queue and then forwarded to the
receiving program when it becomes available for processing.  Without using a
common message transport and queuing system such as MQ, each application
must be responsible for ensuring that the data sent is received.  Without
JMS, maintaining communications between different types of applications as
they are revised and eventually replaced with newer architectures creates an
enormous programming burden in large companies.

MQ works as a message broker in order to add routing to JMS.  A rules engine
analyzes the messages and determines which application should receive them,
and a formatting engine converts the data into the structure required by the
receiving application.  

MQ & JMS are analogous to e-mail (Outlook and SMTP) systems that provide
similar transport functionality.  The primary difference is that MQ deals
with transactions between programs, whereas e-mail deals with messages
between people.  The MQSeries server is an application, similar to email,
that runs on Windows NT, the clients run on platforms such as OS/390,
OS/400, UNIX, NT, etc..


MQ software provides a central point of communication between applications
such as browser enabled applications on a server and legacy applications on
a mainframe.  Moreover, without a messaging system, each application must be
custom programmed to call the other and ensure the data arrives.  This adds
complexity to the environment and lengthens the time to market for new
applications.  Once companies conform to a common messaging interface,
future connections between applications will be more easily developed, and
the message queue will hold transactions that are currently not deliverable
due to system or network failure or overload.  Micro$oft's version of this
model is called .NET.

However, the risks associated with this architecture include:

*       Integrity - how does one know that a message sent from one
application was received by the other without being altered?

*       Confidentiality - is the data being sent to the correct recipient?

*       Authentication - is the message sent from a trusted source?  What if
anyone sent a message, would it update data on the target system?

*       Authorization - is the application sending the message authorized to
alter data on the target system?  What if a cracker had control of a trusted
system, could transactions be made on the target application system?

As these are the Auditor's concerns, they unfortunately may not be the top
priority for developers.

JMS Security

In summary, JMS has no security functionality built in; the security
mechanisms must be implemented at other locations in the stack.  For
example, if all transmissions were encrypted using a Public Key
Infrastructure (PKI) this would ensure authentication, confidentiality, and
message integrity if the digital signature and certificate authority scheme
were correct.  This would also pose a challenge for administration, having
each program with a valid certificate, and saying nothing about
authorization.  

One noteworthy item is that MQSeries replaced Remote Procedure Call
technology.  

MQSeries Security

As noted JMS sends its messages to another middleware application that is
responsible for routing the messages to their intended application (this is
routing at layer 7).  This discussion will focus on IBM's MQSeries but other
messaging middleware is available.  

The question is, how does MQSeries prevent fraudulent messages without PKI
implemented?  Additionally, if PKI is implemented, how does MQSeries know
that an authenticated application is making an authorized transaction?

Provisions for this eventuality does not appear to be addressed.  After
someone writes a fraudulent JMS transaction, as a proof of concept, this may
be of further interest.


Research

The books on the subject of MQ and JMS focus mostly on getting it to work,
with security as an afterthought.  The main sources used in this article
were a search in Google for JMS security and IBM Redbooks on MQ.  Amazon
indicated two books on JMS each covering 1 and 3 pages on security according
to their index, respectively.

There is an IBM Redbook sg245306 entitled MQSeries Security, this Redbook
talks about how to implement PKI with MQ.  


Current thread: