Security Audit of IBM’s AS/400 System i: Part 2
Process Segregation for AS/400 security audit
This post is a continuation of part 1. We will dive deeper into the security audit of IBM AS/400 and system i. As we are aware that AS/400 is not just an application, it provides a complete environment to run the application including front-end(Green screen), business logic, backend, file storage and operating system support. So no third party interaction is allowed in the application for the execution environment.
In this case, the complete AS/400 environment becomes the scope of security audit to make sure the overall environment is secure. Considering the same, we segregate the security audit process in 3 major categories.
• System Security Analysis
• System Configuration Audit
• Application Logical Testing
System Security Analysis
The ‘System Security Analysis phase covers the security assessment of system environment which works as a container to run the application. Any system, running the application is one of a layer for an attacker to break into to get the access of all applications (including target application) running in that particular system. To secure an application, we must ensure that system which is providing the environment for running that application is also secure.
The system security analysis covers these critical points to analyze and ensure system security.
• System OS version.
• Open ports on the system.
• Services that are running on the system.
• Default services enabled on the system.
• Accessibility of system to end user.
• Vulnerability analysis of the services running on a system
Tools might be helpful to complete this phase :
There are a lot of tools available which helps in port scanning, service enumeration, vulnerability assessment and analyze other systems/network services. Below are the most common tools which are efficient and user-friendly and considered to be flexible for all types of environment.
NMAP can help you in port scanning and service enumeration where Nessus helps out with the vulnerability assessment for the services running on a system. Combination of NMAP and Nessus create a perfect suite for any Auditor while doing a security assessment of a system/network.
With the help of NMAP and Nessus or any other alternate tool, we need to ensure that we can identify all the ports, services running the system and point out the vulnerabilities existing in the system. This phase should cover all the above-listed points to ensure the security of the system which is layer 1 for our application.
Security Configuration Audit
Every system/application has a layer of inbuilt security to run the application with a secured configuration to avoid any unauthenticated/ unique access into the system. The system security configuration is designed by vendors to run with a best security practice which becomes user-friendly for system administrator or end user to configure the system as per standard security guidelines.
AS/400 also have some inbuilt security configuration to ensure the security of a system. All the system security configurations are easy to understand and implement for any AS/400 administrator who is capable of operating the AS/400 systems.
Mentioned below is the checklist for security configuration of AS/400 which can help to configure the AS/400 system with security best practices.
Download our checklist here: AS400 audit checklist Security Brigade
Note: This checklist is created based on the experience of audits Security Brigade has done so far. It’s not derived from vendors or any other external resources.
Application Logical Testing
Application logic testing covers the core logic behind application be it like business logic, data transmission, bidirectional component interaction and other checkpoints playing a crucial role in the application environment.
Logic and processes may include:
• Data transmission between client-server
• Request endpoints
• Communication protocols and conceptual behaviour
• Input processing
• Business logic layer integration and data processing
• File system
• Data storage
• Input/Output Encoding/Decoding
• Origin verification
• Application client accessibility and behaviour
• Application client enforcement
• Data manipulation during transmission
In the previous post, we mentioned specific challenges you may face. The system is entirely different from other conventional systems, so we need to work out to set up the testing environment first.
For security testing of any application, an auditor needs below parameters to work on:
• Architecture of system
• Protocol Analysis
• Setup the environment to view/modify/replay traffic
• Understanding the application logic
• Request/Response Analysis
• Local memory analysis
The above parameters are possible if we can view/modify/reply to the data transmission between client-server. So, first of all, we need to set up an environment which allows us to monitor and manipulate the application traffic. With HTTP/HTTPS based application this is easy, but when it comes to different protocols with security checkpoints of a vendor, it becomes complicated to work with.
We have already mentioned the architecture of this system in the previous system. So let’s have a look on the possibilities an auditor have to work with these systems in respect of security audit.
Analyzing The Protocol :
As per the standard protocol and design by the vendor, AS/400 work on TCP and allow to connect with the application via telnet. So there is no involvement of HTTP/HTTPS in this case which could help us to audit the system smoothly.
So we need to work on the initial analysis of system behaviour first to analyze the protocol so that we can figure out the solution to view/modify/replay the requests.
Here, Wireshark helps you analyze the traffic on a particular network interface. You can quickly filter out the traffic of as/400 with the below filter.
IP.src == <Your Local IP> && IP.dst == <IP of AS/400>
Once you can see traffic for AS/400 sent from your system or as/400 client terminal you can analyze and find the protocol it is using for communication.
IBM iSeries AS/400 Character Encoding: AS/400 uses different character encoding, but in most of the cases you can see that it uses EBCDIC which is a traditional character encoding for any application written in Cobol. In the next step, we need to figure out a solution/tool which helps us to deal with traffic over TCP with EBCDIC character encoding or any other encoding it is using.
Setup The Environment To View/Modify/Replay Traffic :
AS/400 comes with an IBM suite which has various utilities to connect, configure, troubleshoot and maintain the system. IBM emulator is one of them which help an end user to connect to the system. The same uses telnet instance in the background for remote connectivity.
We now need to think how we can place our proxy tool in between the IBM emulator and AS/400 system. We are using the below mediators as proxy tools for this purpose to capture/modify/replay the traffic :
• Echo Mirage
• ITR(Interactive TCP Replay)
We can have a look below to see the data representation in ITR :
However, thinking from a different perspective, here we have 2 ways to connect to AS/400.
- Using IBM Emulator provided by the vendor.
- Using telnet terminal with third party utility or system itself.
While connecting through IBM emulator, you’ll encounter a green screen window to operate the system as shown below.
Analyzing both ways for connectivity you should see that you are not able to capture the traffic using any of the above proxy tools if connecting via IBM emulator but you can capture the traffic while you connect directly using any telnet terminal. There might be the main reason which does not allow us to capture the traffic while connecting with IBM emulator. One of the main reasons is that IBM emulator is wrapped with their security checkpoints which do not allow an end user to route the traffic through other non-standard utilities.
“So we can eliminate the first challenge to capture the traffic by directly using telnet client instead IBM emulator to connect to AS/400.”
Still, if the system is configured to use only IBM emulator and deny the connection request with other utilities, we have to go with python to replay the request for testing which is not an efficient solution to deal with this challenge, but it is undoubtedly going to reduce your effort.
“So we can eliminate the second challenge to capture the traffic by using python scripts to reduce the effort and replay the requests.
Once we can capture/modify/replay the traffic, our setup is ready to proceed with the technical audit.
Understanding The Application Logic :
AS/400 based application is the standard application and provides you functionalities from inbuilt modules as per the user’s need. So all the modules are already created as per the standard procedures and guidelines. Whenever a new requirement comes, the particular set of modules are configured and provided to the end user.
The application process on the server itself and only remote access of the application can be used by the user, so there is no logic base at client end which can be exploited from the front end and manipulation between client server. The application allows a user to select particular options or write the commands (if CLI is provided to users) and these directly goes to the server so in this case, no manipulation is possible.
The application is just an interface to interact with the backend, and business logic for the same get processed on the server itself where the user does not have any command over the logic manipulation.
Moreover, we can try the below test cases to ensure the security from front end :
• DB2/SQL Injection
• JCL Injection
• Command Injection
• Input Validation Issues
• Logical Errors
• User Enumeration
• Privilege Escalation
• Insecure Cryptographic Algorithms
All of the above issues are straightforward to test as we perform testing in standard thick/thin client applications. Few of the test cases can be done with the help of inbuilt tools provided in the IBM suite such as iSeries Navigator.
iSeries Navigator allows us to access the integrated file system of AS/400 which can be used to analyze the storage, privileges, directories, security configurations, SoD and many more. This tool also helps us in configuration review of the file system as well as other access control related checkpoints.
Checkout Accessing the integrated file system
These request and response are purely EBCDIC encoded and can easily be seen in plain text also, but as we already know, the application logic is processed on the server itself so there is a minimum chance of doing a client-side manipulation which could lead to a severe compromise.
The below request can be seen to understand the application encoding character set transmitted in EBCDIC :
The system is developed and owned by IBM, so they have their parameters and security checkpoints to ensure the secure transmission of data. So an auditor has to mainly focus on the client side testing and security configuration review.
Local Memory Analysis :
AS/400 based application use its inbuilt integrated file system which we have discussed in previous post and analysis of the same’s discussed in the above phase. Now we mainly focus on the local storage analysis at runtime.
WinHex is a well known and efficient tool for memory analysis which allows us to monitor and analyze the memory at runtime. It is a multipurpose tool for computer forensics, data recovery, and low-level data processing. For this audits purpose, we’ll take benefit of this tool for memory analysis from the security perspective. With the help of WinHex, we can check, how the application stores data in memory in the runtime environment.
Download our checklist here: AS400 audit checklist Security Brigade