RE: Research Project- If you wanted to Hack an AS/400 theoretically, what would you do? (NFM) -- MIDRANGE-L

Breaking into an iSeries is as easy as the system administrator allows
it to be (and based on our experience auditing machines, that would be
"too damn easy").  The steps are as simple as 1,2,3... Access, Explore,
Attack.

1.  Acquire Access:
To do this you will (usually) need to compromise a user profile.
Obvious candidates are the IBM default (especially QUSER), application
package defaults (JDE, S2KOBJOWNER, etc), or any of your user profiles
who use default passwords (Password=User name).  The number of default
passwords that we find is tremendously high.  In fact, I have seen three
systems this week where the number of users with default passwords was
in the 100's.  If someone knows your user ID naming scheme, then it can
be pretty simple to hunt for an unguarded profile.  

Another target-rich area are ID's like TEST1 - TEST9, or STUDENT1, etc.
There are obvious ID's that many shops set up and forget about - and
those ID's can often be compromised with default passwords.  

If an attacker already has access to the system and is just trying to
gain greater access (or hide their true identity), then default ID's are
a great source of additional authority.  Look especially for vendor ID's
whose profile's are not secured (*PUBLIC, or any user, has more than
*EXCLUDE authority to the user profile object), as these profiles can
easily be hijacked by someone who already has access to the system - no
password required.   It's the OS/400 version of identity theft.

There are also some exploits that can be launched over default SNA
configurations using QUSER, even if you don't know QUSER's password.  If
you think that QUSER is not a threat to your data, see point 2...


2. Explore Authority:
Once you have access, any kind of access, then you can explore what your
ID can do.  Of course you're not limited to just the telnet interface,
so don't count on command line restrictions alone to provide security.
You can explore a system using tools such as FTP, ODBC, OPSNAV and
RMTCMD as well.  The goal for an attacker here would be to either find a
specific piece of information that was unguarded (assuming the attacker
already knows what they want), or to search for things that seem
valuable yet unguarded.  And if you are running a purchased software
package, the names of libraries important files may already be well
known to the attacker.  

Remember that the user ID that is doing the searching will have
authority to anything that *PUBLIC can access, and may also have the
authority of one or more group profiles.  If, for example, the User, the
Group, or *PUBLIC has *CHANGE authority to the file, the attacker can
read and/or change any data element in the file.  And of course if
*PUBLIC has access, then seemingly innocuous ID's such as QUSER become a
big problem - they have as much access as all of your regular users.

If you, the security officer, explore the authority listed on your
objects, you will likely find that many (*ALL?) of the production data
files are secured such that either your user's group (JDE, S2KOBJOWN,
etc.) or the catch-all *PUBLIC has *CHANGE or more authority to the
data.  If this is true, then the security officer has to look at ways of
preventing access (such as deploying Exit Programs), or redesigning and
re-implementing the security model to prevent users from having direct
access to the data.  As a test, you could catalog your most important
data files and review the authority that your users have to those files.
If your system is like most iSeries shops, you'll want to block access
from tools such as FTP, Remote command, etc. with exit programs, rather
than redesign the existing security model.


3). Exploit the opportunity
Now that you have access, and you know what you're authorized to do,
this iSeries is your oyster.  Exploitation becomes a simple matter of
deciding what you want, and what tool you want to use to go and get it.
All of the various communications utilities (TCP and SNA) that are
enabled for the iSeries are potential routes into the system, and each
route has its relative strengths and weaknesses.  Some allow the
transfer of data, (FTP, ODBC, DDM, DRDA, etc.) and some allow the
running of commands (FTP, DDM, *RMTSRV, etc.).  Most of these tools
provide some level of help text to simplify the task of accessing the
/400, and all of the client side tools are readily available over the
internet.  If the attacker has a mind to steal data, this can be done
usually without leaving any trace as there is no native logging of data
transfer requests.  If the attacker's designs are even more malicious,
then data corruption or destruction is possible, but that tends to leave
pretty obvious signs of intrusion.

So, one way to answer your own question might be to create two new user
ID's, one that is not a part of your user community, and one that is a
clone of your least powerful user.  After you have done this, log onto
your system via something like FTP with these ID's and see what these
users can see.  This is essentially taking a "attacker's eye view" of
your security.  that will give you the best sense of how secure your
system is.


jte

  
P.S. I'm not sure if your question was pointed at potential holes in the
operating system.  But, yes, I totally sidestepped that part of the
question, and for good reasons.  While there are bound to be holes in
the OS (no system is perfect), they tend to be well guarded, and fixed
fairly soon after identification.  If you want to attack a /400, the
more fruitful approach is to focus on the under secured applications and
users.  That's where the big payoff is.

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Wills, Mike N. (TC)
> Sent: Wednesday, January 28, 2004 7:09 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Research Project- If you wanted to Hack an
> AS/400 theoretically, what would you do? (NFM)
> 
> On this route. I would have a sniffer run and try to pick
> up usernames and
> passwords. If you aren't using SSL with CAE this will be
> easy. If you log on
> with QSECOFR from other locations (besides the console)
> without SSL, you
> might as well give everyone the password. Then with that I
> would see what I
> can get into with that person's username and password. Try
> to shut down the
> machine, or try to get into sensitive material this person
> isn't supposed to
> have access to. This would be a start.
> 
> Mike Wills
> Lawson Programmer/Administrator
> Taylor Corporation
> Email: mnwills AT taylorcorpNOSPAM DOT com
> AIM: iSeriesCodePoet
> 
> -----Original Message-----
> From: Adam Lang
> 
> Try to get some sort of internal contact with the company
> and get a username
> and password.
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.