Security issues

Magic version

All versions

Purpose of this page

In time security issues have occurred with some versions of Magic. This page puts all known issues together at one place (try this with some Microsoft products) so that no one can say he didn't know about it.


This document contains a very rough and subjective classification of security issues:

1. Severe risk means: All flashlights are on. Leave the room immediately. No time for panic. Don't forget the beer in the refrigerator.
2. Moderate risk doesn't mean what it says. ANY security flaw in a production system can prove fatal under the right circumstances. And the right circumstances will occur and bite you when you aren't prepared. But you can't have a listing without a classification can't you?

Issues are sorted in descending order of the last affected Magic version and within the same version the more severe security risk comes first.

People

Version

All past, present and future versions

Security risk

Severe risk

Overview

The greatest security risk comes from within your own organisation. No matter how well defended the system is on paper, when the management gives it no consistent priority and when the end-users are careless and say it's not their responsibility too, then the front door of the company's system may be firmly shut but everywhere in the building, windows and back doors are wide open and swing in the wind.


And what about you? How well do you know your business? Do you know that when you do not set a Public Rights Access Key you could as well publish the Public Rights of your applications on the intranet? And that when you don't set a - strong - key as the Super Right Key someone else who managed to access your MCF files will? And that, when you allow end-users access to the Magic Development help files and documentation, in time some bored employee in your organisation will take it up and will teach itself some nasty tricks of black magic?

Solution

For what others do you cannot stand but at least you should informe yourself and be prepared.

Code injection via the Range / Locate Expression facility

Magic version

All versions up to Magic 9, fixed in Magic 10

Security risk

Severe risk

Overview

Leaving the Allow Locate and the Allow Range options to "Yes" wich is the default for online tasks let the end-users gain access to the Locate / Range by Expression dialog. Expressions that are set in this screen can be executed by Magic in the same way as any Evaluate expression. This lets end-users execute any code that any Evaluate expression can execute. This includes reading and exporting sensitive information the end-user is not authorised to access or modifying and deleting any data.

Using the Range / Locate Expression facility to read and delete data

1. Execute any online Magic task with the Allow Locate or the Allow Range option set to Yes.
2. Enter the Range / Locate Expression dialog by pressing <CTRL L> or <CTRL R> and then <CTRL E> or by selecting the appropiate options in the Options pull-down menu.
3. In the Expression edit field of the Expression Rules dialog enter the following expression (example):

   INIPUT('[I_AM_HACKER]FIELD1='&VARNAME('A'VAR),'TRUE'LOG)
   
   Or:
   CALLPROG ('2'PROG)
   
   Or:
   MNUSHOW('Menu','TRUE'LOG)
   
   Or:
   DBDEL('1'FILE,'')
   
   Or why not try:
   (DBDEL ('1'FILE,'') OR 'TRUE'LOG) AND (DBDEL ('2'FILE,'') OR 'TRUE'LOG)...(DBDEL('xxx'FILE,'') OR 'TRUE'LOG)
4. Press <ENTER> and <ENTER>.

All entered expressions are executed, regardless of the permissions granted in the application to the end-user. And when the user doesn't know enough from Magic, there is the "Functions" button and maybe the Magic Development Help function to help him on his way.

The expression that is entered in the Expression Rules is executed once for each record of the data view. When you run this expression in a task with a serial number in it you can use this number as a counter and your Locate / Range expression becomes a batch task. For instance, when you enter a Range / Locate expression from say the Customers task with say variable Z beeing the CustomerNo, you can enter expressions like:

Off course you always can use the INIPUT and INIGET expressions to create your own counter when desired.

Solution

First: disable the Range / Locate Expression dialogs or set a right on it so you can control who may use this.
Second: apply appropiate rights on the data outside Magic. You can set and deny rights in the database, in the operating system and in the network middleware where apllicable.

In Magic 9 there are several ways to application-wide disable or restrict access to the Range and Locate facility.

Disabling the Range and Locate acts all together

You can simply disable the Range and Locate dialogs by creating handlers for them in the Main program. These handlers, one to intercept the Locate a Record Internal event and one to intercept the Range of Records Internal event, are empty except for some remark lines that explain their purpose.
Set Subtree to Yes, Propagate to No and Enable to Yes or set this to not granted some appropriate Right.

Don't forget to remove or put a Right on the corresponding menu options that reside in the default Edit pulldown menu, otherwise you should expect questions from some attentive end user. Don't get confused by the Table Locate menu options in the default Edit pulldown menu. The Table Locate and the Table Locate Next events are toolkit actions that are used internally by the Magic engine and are irrelevant for the user interface in Runtime mode. Best you should remove them right away.

A drawback of the above method is that you can't use expressions like: KBPUT('LOCATE A RECORD'ACT&FILL('NEXT FIELD'ACT,<some number>)&'<some locate value>'&'OK'ACT) which in most applications are used to park a user on a specified record. With the above method these expressions won't work any more.

Disabling the dialogs by creating system event handlers

You can restrict the use of the Range and Locate dialog by creating an empty handler in the main program with the Trigger type set to System to catch the CTRL R and CTRL L keyboard events. Then you should also remove or put a right on the corresponding menu options that as a default reside in the Options pulldown menu.

Controlling the use of Range and Locate by altering the menu entries

A simple way to control the use of the Range and Locate facilities is to create a set of events, say UserRange and UserLocate in the Main program. Then you replace the events that trigger the Locate a Record and the Range of Records menu options in the default pulldown Options menu with your user events. In the Main program you can create handlers for your events. Now you have full control over the use and the usage of the Range and Locate facilities. You can write to a log file wich user when and in which task did use or tried to use the Range or Locate option. This information you can use to identify programs in your application that you may have to rewrite to overcome the need to use these options.

Why not just disable the Define Expression event?

Unfortunately it is not possible to intercept the Define Expression Internal event because this is a Toolkit Action that is used internally by the Magic engine and that is irrelevant for Runtime mode. (So why are they in the selection list?). It is also not possible to catch the CTRL E user press while in Locate / Range mode because in this mode no user invoked actions can be intercepted by a programmable handler.

Why not remove the CTRL R and CTRL L keys from the Keyboard mapping?

In most environments it is possible for end users to access and alter the Magic keyboard mapping file. When this is not possible it often is possible to start Magic with a directive to use an alternative keyboard mapping file. Therefore in general it is not recommended to base your systems security on these and other unencrypted support files. Magic ini files included of course.

The best solution for most cases

To condense the above lengthy discussion, in most environments the following configuration will meet all needs:

1. Create two dedicated rights: say UserRange and UserLocate (or combine them into one right). Grant this right to yourself and to others where applicable.
2. Create two events in the Main program, say UserRange and UserLocate. Trigger type set to "None".
3. In the default pulldown Options menu, in the menu-entries "&Range of Records" and "&Locate a Record", replace the Internal events with your corresponding User events. In the Properties dialog (press CTRL P) of the menu-entries, enter the newly created rights.
4. Create two handlers in the Main program. Let them be triggered by the CTRL R and the CTRL L System events. Set Scope = Subtree, Propagate = No, Enabled = Yes. The solely purpose of these handlers is to intercept the keyboard events in case the user is not authorised. Place a Remark in the handlers to explain their purpose.
5. In the Main program, create another pair of handlers. One for the UserRange event and one for the UserLocate event. Scope = Subtree, Propagate = No, Enabled = Yes. Now you can be sure that only authorised users (for instance Magic developers) can trigger these handlers. In these handlers you can raise the "Range of Records" and the "Locate a Record" Internal event. When you wish you can add extra operations, for instance for logging purposes.

The final solution

The real solution to this issue is to upgrade to Magic 10.

Documentation

http://groups.yahoo.com/group/magicu-l∞
Thread starting with message #11496: Security Holes in Magic ! by Malki.
Message # 11519, about turning off the Range Expression on a per task basis.

All past messages of the Magicu-l Yahoo users group are available in compiled help format at http://www.magicusergroup.com/∞ .

SQL code injection

Magic version

All versions, when using a RDBMS

Security risk

Moderate risk

Overview

SQL Injection is a term describing the act of passing SQL code - and executing it - into an application that was not intended by the developer. As such this is not a specific Magic problem. Magic developers working with a RDBMS should be aware of the issue though. In general the Magic database gateway protects you from SQL code injection. Only when you let users enter free text as a search string and you process this string using a Direct SQL task, you are vulnerable to this kind of attack. The potential consequences depends upon the security context of the Magic application. When the application acts as a "sa" and when the SQL Server service is configured with Windows administrator privileges than taking total control of the Windows system may be possible. The security risk is rated as Moderate because when developers adhere to some basic rules when using Direct SQL you can prevent any form of SQL code injection. The potential extent of incurred damage need not always be moderate however.

Attacking a system with SQL code injection

Say you have build a program where a user can enter a search string to find matching text in a database. You process the inputted textstring using a Direct SQL task that contains a SQL statement like:


where :1 stands for the variable containing the inputstring.
When executing this task the following statement is sent to the database:


Now imagine the end user entering this string:


Now, when the Magic program executes, this string is sent to the database:


You now can see that the inputstring that has been entered by the attacker appears to contain three functional parts:


The first part is the single quote (') at the start of the string. This quote closes the SELECT statement that is programmed in the Direct SQL task. As SQL allows for multiple commands on a single line, the SQL command interpreter goes on searching for the next command. The attacker provided this command with the second part of his inputstring. In the example above this is the substring: exec msdb..add_operator @name='Tarzan'. In our example the substring will be recognized by SQL server as a valid command and, given enough rights, it will be executed. In this, relative harmless, example a new operator will be created. The substring could be any valid SQL command however. The third and last functional part of the inputstring is the comment operator (--). This instructs SQL server to ignore the trailing single quote that was intended by the Magic programmer to finish the original SELECT statement.

Adding a new operator to the database will in general not be the ultimate goal of a SQL code injection attack. The attacker could for instance enter the following string:


When the application runs as a "sa" and the SQL server service runs with sufficient operating system privileges the attacker will now have an account with which to access the machine.

Another approach for an attacker is to enter a SQL code injection string anywhere in a table in the database and then sit back and wait till at some time the field that contains this code is used as an input parameter in a Direct SQL task. For instance, you enter your code in the column: ItemDescription of the "Item" table. Then at some time a program may run that uses the values of this column in the WHERE clause of a SQL statement in a Direct SQL task. At that moment the injected code will be executed in the security context of that occasion.

Acknowledgement for the SQL examples: SQLSecurity.com

Solution

The first thing you should do is to validate any inputstrings that you process with Direct SQL tasks to prevent malicious code from entering the system. You can create a dedicated program for this purpose that accepts the raw inputstring and gives a thumbs up or thumbs down back to you. It can write to a log file when a user tries to enter suspected code. Second, you should configure your SQL server service to run with the least privileges that are required to do its job. In the majority of cases the service will not need administrator privileges to run properly. Third, configure the security context of your application to use minimal privileges. Consider using a dedicated application when you need to do tasks from within Magic that require sysadmin or db_owner privileges. Fourth, be informed. Things change with new versions of RDBMS software and new intrusion methods emerge all the time.

Documentation

Run your favorite search engine with: "SQL AND injection"
Recommended site:~http:\\www.sqlsecurity.com

Security implications of using the Active Directory System Logon option

Magic version

Magic 9.30 and later

Security risk

Moderate risk

Overview

Using the "(Active) Directory" System Logon option that is available starting with Magic 9.30 has as a consequence that any person that:

• is able to make a copy of the Magic security file and the Magic application files (MCF files) and
• can transfer these copies out of the company network,

can easily obtain access to all rights granted to the Magic SUPERVISOR GROUP user group. When this person also can see the Windows domain user groups that exist in the company network this person can easily obtain access to the Magic user rights of all users belonging to these groups and will be able to logon in Magic as any such user and act on its behalf.

Obtaining Magic user rights that are not granted

1. Configure a foreign server as a Windows domain controller having the same Windows domain name as the company network domain where the companies Magic application is running.
2. Install Magic on the foreign server and create a Windows user group with the name: "SUPERVISOR GROUP" or any Windows user group you know to exist in the company network and that may be granted access rights to the Magic application and to the Public Rights.
3. Copy the Magic security file that is used in the company network to this foreign server.
4. On the foreign server, logon in Windows as a member of the Windows "SUPERVISOR GROUP" user group or another known Windows user group you created for this purpose.
5. On the foreign server start Magic while using the copied Magic security file and with the Magic System Logon setting set to "Active Directory". With respect to this copied Magic security file you do now have any rights that are granted to the Magic SUPERVISOR GROUP user group or any other Magic user group of your choice, but without access to the security settings this won't bring you anywhere.
6. Copy the Magic application(s) that are used by the company to the foreign server.
7. Now, in Magic as a member of the SUPERVISOR GROUP or another Magic user group you are able to see all rights with their keys in the Rights Repository that are defined in that application and that are granted to this Magic user group no matter whether these rights are defined as public or not.
8. Create a new Magic security file with all rights that you now know to exist in the Magic application(s). Create this Magic security file directly on the company network or create it on a foreign computer and copy it to the company network, name it say: MySecurityFile and copy it to a directory, say: "C:\temp\" of a local workstation that is connected to the company network and from where you can start Magic.
9. Create a shortcut or a batchfile to start the companies Magic application using the following Magic Environment directives:

You now are able to start the companies Magic application in the Magic SUPERVISOR role and you now have all rights you created in your security file. In your copy of the Magic security file you can create any Magic user logon you know to exist and act in its behalf, thus concealing your activities.

Solution

When you are using the "Active Directory" System Logon option you should not grant the Public Rights Access Key and the Super Right Key to Magic user groups that exists in the Windows domain (type 1 groups). You can grant these rights either to individual Magic users or to special Magic user groups that are ment to be used in the Magic SUPERVISOR role (type 2 groups). When these groups are used, the System Logon option is set to "None" or to "User Name". There should be no corresponding Windows security groups. The name of these groups should contain a descriptive part for convenience and a code that is difficult to guess for unauthorisated users. It may be clear that the built-in Magic SUPERVISOR GROUP user group should not be used for this purpose and best should not be granted any rights at all.

Do not deploy your application to end users as a MCF file. Use a MFF file format instead. Make sure that the MCF that Magic developers use is not accessible for unauthorised users.

You can set Application Access Keys on the MCF files but when you are deploying your applications you must remove this keys and reassign it afterwards because the Application Access Keys apply to MFF files too. This practice is error proned and in the long term can not be trusted upon.

Documentation

• Magic940SP5 PastReleaseNotes
• eDeveloper Reference Guide V9.4 SP4d, January 2005

Security implications of the availability of the Full Logon System Logon option

Magic version

Magic 9.01SP3 up to Magic 9.30SP2

Security risk

Severe risk

Overview

The "Full Logon" System Logon setting which is introduced in Magic 9.01SP3 and was discontinued in Magic 9.30SP2 poses a severe security risk because using this setting someone can very easily circumvent the Supervisor password and log on as Magic SUPERVISOR or as any defined Magic user.

Obtaining Magic user rights that are not granted

1. Install Magic on a foreign server and create a Windows user with the name: "SUPERVISOR".
2. Copy the Magic security file that is used in the production environment to this foreign server and name it say: "My_usr_std.eng".
3. On the foreign server, logon in Windows as "SUPERVISOR".
4. On the foreign server, start Magic with the "Full Logon" System Logon option and using the copied Magic security file.
5. You now have full access to the security functions of the copied Magic security file with all SUPERVISOR privileges and all rights that are granted to this role.
6. Delete the SUPERVISOR password in the copied Magic security file.
7. Copy the altered Magic security file back into the production environment.
8. Create a shortcut or a batchfile to start the companies Magic application using the following Magic Environment directives:

You now are able to start the companies Magic application in the Magic SUPERVISOR role. You can see and use all public rights and all rights, public or not public that are assigned to Magic users or user groups. Furthermore you can see all secret names. In your copy of the Magic security file you can change the password of any defined Magic user and act in his behalf, concealing your activities.

Solution

Because of this issue, the use of Magic version 9.01SP3 through 9.30SP2 in environments where security could possible be an issue must be strongly advised against.

For alternative solutions see the next issue.

Documentation

• Magic940SP5 PastReleaseNotes

The Magic security file can be cracked

Magic version

All versions before Magic 8.30?

Security risk

Severe risk

Overview

A person who can obtain access to the Magic security file can very easily crack this file and make himself Magic SUPERVISOR with respect to this file. As a SUPERVISOR this person has full access to all privileges that Magic grants to this role.

Cracking the Magic security file

In the words of the discoverer:


"
To crack it I first created the user aaa in a dummy security file and made it part of the Supervisor group. After logging on as aaa I replaced the dummy security file by your file [the security file to be cracked]. If I go to the user ID's Magic asks me to logon. I cancel this logon. At this moment all security entries in the menu are disabled. Now I park om the Security file entry in the environment. The User IDs entry in the pulldown menu becomes enabled. I zoom on the password of the SUPERVISOR and replace the password. Now I can logon as a SUPERVISOR in your security file and read the secret name.
"


Credits to William van den Heuvel.

Solution

The best solution is to migrate to a later version of Magic (not Magic 9.01SP3 up to Magic 9.30SP2 however: see above). Next best is to use a seperate security file for the Public Rights key, the Super Right key and the toolkit repository access keys and to never let any unauthorised person get its hands on this security file - and that is the hard part. Another alternative is to write your own security system to control access to the Magic environment without relying on the Magic security file.

Documentation

http://groups.yahoo.com/group/magicu-l∞
Thread starting with message #49235: How to Crack the Magic Security File by Ian Ledzion. For an all in one overview, see message #49333 by Andreas Sedlmeier.

---

CategorySecurity