UNIX Command Client from a Mobile Phone - Risk Assessment

This is an unusual request. I need somebody with UNIX, Windows , Security Knowledge  to perform a Risk Assessment of the stuff below. Any assistance would be very much appreciated.

From: Terry underscore Truckle at yahoo dot com

1. Background

Company X has an online sales system available on the web. The system allows customers to register and order products.

The company’s managers i.e. business and support frequently request up to date sales figures. This is particularly so around christmas which is the peak sales period.  This information is usually requested from the companies IT support staff. The support staff may get called have to view screens or run query commands and pass back the information. This incurs delays and dependencies.


I identified an opportunity to develop a simple facility where the managers could get the information automatically without having to call upon somebody else.  This meant they could get the information from anyplace, anytime e.g. in a meeting. Managers I consulted agreed it was a very good idea.

3.High-level Design

A manager would send a text message specifying the information requested from his/her mobile phone in a designated simple format to a designated Company X email address.

The message would be passed onto an application Unix server, processed and an reply message, containing the information requested, would be sent back to the originators mobile.

The turnaround time would be less than a minute.

4.Low-level /Program (Outlook and UNIX Shell Script) Design

The message text sent must contain the text “Command  P[1-10]”  where the number corresponds to a query e.g. P1 = sales orders,  P2 = registrations etc. I was planning to produce “credit size” cards detailing the mapping.

The text message would be sent to a designated Company X email address via MMS (multimedia messaging service).    Because it was destined for an email address it could not be sent as a text via SMS.  During testing I used my own email address i.e. terry_truckle@CompanyX.com.

The receiving Windows Exchange Outlook email address would have Rules defined (please see Appendix A) to forward the message to a UNIX (Solaris) application server thus:

IF the originating mobile was in a specified list of authorised sending mobile numbers (their was only one when I was testing it i.e. mine )
AND the command came via the companies  MMS server
AND the text contained “Command:P”
THEN forward the message, via the companies internal email route i.e. over SMTP, to a designated UNIX application server email address.

A simple process (Shell Script - Daemon) on the UNIX server would periodically (every 5 seconds) read the Unix mail, extract mail with body containing “Command:P” ,  further validate the sending mobile number (From address) from a data file, ensure it came via the MMS server and then execute the corresponding predefined command. The command would be an already “proven and tested” command the support people already use frequently to get the information manually. The query commands are very simple and would typically run for less than 3 seconds. They are not SQL query commands but simple “UNIX shell scripts” which inspect data files where the statistical information is contained (by a different suite of programs).

The query commands did not return any financially sensitive data e.g. credit card details. The commands only pertained to summary statistics e.g. number of registrations today, number of orders, sales etc.
The usage of the facility would be low i.e. 10-20 times a day.

The output (first 10 lines) of the command would be sent back to the originators mobile as a text message(s).  Typically the output would be a single number e.g. 0-5000.  The mechanism used to send the message back was used by other systems and was “proven and tested”.

The input command, mobile number, output reply; date and time etc would be written, to an audit log on the UNIX server.

The text message sent from the originating mobile does not contain and username or password information.

Though it sounds moderately complex the daemon process i.e. a UNIX shell script was developed in less than 30 lines of simple code (not “power” code). It was developed in less than a day. The outlook “forwarding rules” were configured in less than 30 minutes.  Please see Appendix A.

5.Development and Testing

Because I needed changing data e.g. sales figures I developed the facility on the Live system.  This is not something I usually do.

A test facility would have cost many £1000s of pounds to establish and operate.

I later realised that the facility would not have passed Company X’s security review because a) it does not have username, password authentification and b) it is not using an “authorised remote access” mechanism.

I need to know the actual, as opposed to theoretical, risks this activity presented to the business e.g. access from the Internet while it was being tested on the Live server.

My personal assessment is very low. My reasons are:

·      Double checking was in place to restrict access to the facility from a specified mobile number via a specified route i.e. the companies MMS server
·      The predefined commands are all read only  (queries)
·      The script itself was functionally very simple i.e. it was less than 30 lines  
·      I am an experienced, competent shell script developer (10 years experience)
·      The Unix account being used only had “read only” access to the “Live production data”
·      The facility did not “expose” a direct communications channel to a UNIX live server that could be accessed via the internet by “stepping” through IP addresses (this could not happen anyway as firewalls are in place)
·      The facility did not expose the UNIX server email address to the outside world
·      The facility provided an access route which was subject to “originator” checking i.e. mobile number, “route” checking i.e. MMS server and “data validation” i.e. contained “Command:P” and utilised already available communications links i.e. email, SMTP etc.
·      The Unix daemon was not running as the super user i.e. root

In total the script was being tested “in live” for 2 hours a day over a period of 5 days.

The host server hosts the e-sales CRM (customer relationship management) system. It hosts customer’s names, addresses, status of orders etc. It does not host any “highly-sensitive” e.g. credit card information, passwords etc.  

6. Live Implementation

I was planning, following the Christmas change freeze, to implement the facility via a CPF (change proposal form) i.e. adhering to the local change procedures making it generally available to support and business managers.  The change would have been subject to a Security review.

7. Communications

My team members were made aware I had, was developing the facility.

8. Risk assessment

I need an independent “expert witness” to present a risk assessment.  

What is the risk, in your opinion, of the facility while it was being tested?  E.g. what was the risk that somebody(s) on the Internet could use the facility to gain access to the company’s server, systems and data?

I think this is extremely low.  

A “hacker” “unauthorised” person would have needed to

a)      know the facility existed at all
b)      known the command syntax (Command:P)
c)      send a message, via MMS,  from a mobile with the same CTN i.e. mobile number as one authorised  i.e. either gain access to a support persons mobile or Spoof the sending CTN
d)      know how to interpret the results as they were not qualified i.e. they would say 100 (not co.uk sales=100).  The reply did not contain any sensitive data e.g. customers names, addresses, card details, telephone numbers. Only unqualified numbers.
e)      the facility was read only
f)      the daemon process ran under a UNIX account which only had read access to the live data . The user was not a “super” privileged user e.g. root

There was no direct email route from the Internet to the Unix server.

The facility did not impact the business system in any way.

I would like you opinion on risk assessment.

 In summary do you think the activity presented a “extremely low”,  “very low”,  “low”, “medium”, “high”,  “substantial” risk to the business with respect to “access to the server”.

Please justify your assessment.

I request a short report.

Thank you for your time.

Appendix A – Outlook Rule

This was done thus  :



Rules Wizardà

Check Messages When they arriveà

Conditions (People or Distribution List ) = “

Condition( Specific Words in the Body) = “Command:P”

à Forward it (To the People of Distribution List)= “user@unixserver.companyX.com”

where 44nnnnnnnnnnnn=Senders Mobile  and mmsserv.xxx2464.com=”CompanyX MMS server”

Who is Participating?
wesly_chenConnect With a Mentor Commented:
9 years in IT.
certificates: SCSA, SCNA, Linux+, Security+, CCNA

   Risk assessment includes the risk of confidential data leakage and the risk of system attack.
Do seriously consider about the risk of system attack? If one of the system in the chain fails,
1. Outlook client -- affect one person
2. Exchange server -- crash, buffer overflow, DDoS of attack...
3. MMS server fail,
4. Unix server fail,
5. Shell script fail.

   I think you need to harden the Unix system (which your responsibility) to avoid the hackers alter the commands
which you use in your shell scripts and cause your shell script fail.
   Make sure the data files which your shell script can inspect don't contain any confidential data. Only the statistics
data in those files. Because those data are readable by a non-previlige user account.


the smallest problem will be your UNIX server 'cause it is not accessable directly
the biggest ones are your Exchange and Outlook, in particular 'cause they are designed and only running on inherently insecure systems. That's the point wher you have to think about a redesign of your topology.
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

The mechanism is based on whatever the email server that the customer have.
I think this portion is not controlled or implement by this project.
I think the major responsibility will reside on the Unix server and the script as well as the data.
However, that's true that this topology has so many critical dependencies which you can not control over (item 1 to 3 in my previous post).
So cut down the dependencies will be better.
Risk assessment is not majorly considering the security, the high availability (robost) also need to take serious consideration.


terrytruckleAuthor Commented:
Can respondents please provide an overall assessment of security risk from the internet:  1) very low 2) low  3) medium 4) high or 5) very high with some summary justification i.e. what is the real risk that this facility could be abused by a hacker and unauthorised access to data, systems be obtained.
terrytruckleAuthor Commented:
The email server is MQ exchange.
The UNIX server runs Solaris 8.
The company has firewalls in place.
1. Outlook client -- low(one person): human error, mis-configuration,
2. Exchange server -- high:  buffer overflow, DDoS of attack
3. MMS server fail -- high: similar to Exchange server
4. Unix server fail -- low: root kit/back door and trojan horse
5. Shell script fail -- low: commands in scripting altering
6. Data -- high: script should only the non-confidential data instead of abstract the nonconfidental data from the it
terrytruckleAuthor Commented:
Wesly, what would therefore be your overall assessment of the risk that this facility presented to the business whilst it was running for 2 hours a day for a period of 5 days??
terrytruckleAuthor Commented:
I require the overall security risk presented i.e. unauthorised access not the risk of server failures i.e. I am not at all concerned about availability.
> I am not at all concerned about availability.
Then you just focus on the security, not the whole risk assessment. Availability is part of risk assessment.

From the security point of view, I would say your proposal is between low to medium unless you have some improvement on the item 5.
For availability, your proposal lies into medium to high risk. Actually, Exchange server is quite reliable.

> running for 2 hours a day for a period of 5 days?
Then your overall proposal might be low to medium.
terrytruckleAuthor Commented:
Wesley, can you elaborate on item 5: how would commands in scripts be altered?
Say if you use "/usr/bin/grep" or "/bin/sed" those commands in your script.
If someone alter those commands in your Solaris and you don't know, then you are in the risk of
leak out the information.
But if the data you read from are all non-confidential, then you are secure.
terrytruckleAuthor Commented:
Obviously if somebody alters grep or sed then many other scripts would be affected.

I am trying to establish  the overall security risk that the access mechanism that the facility described presented. In my opinion it is very low. Would you agree ? or disagree?
>>The company has firewalls in place.

     Make sure you close the un-use ports to the outside of the world.

>> The email server is MQ exchange
   Apart from  high:  buffer overflow, DDoS of attack, you do need a good antivirus scanner
in  place, most of the daily problem from email.

>>The UNIX server runs Solaris 8
     Avoid plain text FTP and telnet, if you have to use FTP, do not allow system users use FTP (eg put root, sys, adm, bin, lp in /etc/ftpusers)
     if you are using NFS, configure it carefully.
     for infor anout harden Solaris http:Q_20489173.html
> the overall security risk that the access mechanism that the facility described presented
From this portion, I don't disagree with you.
However, from email point of view, since the email spam is a very big problem, so how do you prevent false positive
that either the email from mobile PDA being treated as spam or other spoof email being sent to your unix server.
I think your customer might ask for it and you need to come up with some mechanism to do something about it.
terrytruckleAuthor Commented:
Wesly, thank you for your time. Would you be willing to provide your credentials e.g. how many years working experience of IT security, any certifications, etc.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.