Mobile Code Security

Mobile code

  • dynamically downloadable executable content is referred to as mobile code
  • includes platform-independent executable content which is transferred over a communication network, crossing different security perimeters, and is automatically executed upon arrival at the destination host
  • examples are Java applets, ActiveX controls, JavaScript, Safe-Tcl, servlet
  • “browser helper applications” and plug-ins
    • download from store
    • download on demand

Mechanisms

  • code signing
  • least privileges
  • code monitoring: resources usage monitoring
  • mobile code runtime environment
    • memory model partition the memory into safe and unsafe regions
    • safety check ensure every memory access refers to a safe memory location, e.g. Java type safety
    • resource access control by security manager, e.g. Java access controller
  • proof-carrying code: the proof that a piece of mobile code adheres to a safety policy is encoded and transmitted together with the code

Java safety

  • safety denotes absence of undesirable behavior that can cause system hazards, e.g.
    • Java manages memory by reference and does not allow pointer arithmetic
    • Java provides “final” modifier, which disables overriding class or method
    • Java supports automatic memory management, which prevents memory leak and covert channel
  • Java is a strongly typed language
    • an object must always be accessed in the same way and illegal casting is impossible, e.g. an integer cannot be casted to a pointer and access anywhere in the system
    • static type checking by bytecode verifier protects against forget pointers, access restriction violation, stack overflows, …
    • dynamic type checking ensure no array bound overflows or type incompatibilities
  • Java applet execution
  • Java 2 security model
    • using digital signature
    • run-time access control
      • stack check
      • enable privilege

Java signed applet (code signing)

  • definition
    • there is a program (or a piece of code) sent from the Web server to the client (i.e. the browser)
  • using the PKI and the browser technology
  • example
    • signed applet - Java applet with ‘digital signature’
    • treat the applet as a ‘document’ from server to client
    • the applet has a digital signature attached to it
      • the “applet + digital_signature” is a signed applet
        • when the server creates this applet, the server will put in this digital_signature as well
        • only the server (which holds a “private key”) can create this digital_signature
    • client will verify the digital signature
    • if the verification process is ok, client will allow the applet to execute
    • result: only applet from trusted server will be executed
  • yes or no answer
    • “yes” means
      • the web server (s1) providing the signed applet, is a valid customer of one of the CAs. So s1 is a good guy, and your PC or browser can execute this signed applet
      • but you still have to look into the certificate details to see exactly who s1 is
    • “no” means
      • the web server (s1) providing the signed applet, is not a valid customer of anyone of the known CAs
      • the browser let you decide whether to execute the signed applet or not

ActiveX controls

  • definition
    • Microsoft’s collection of technologies and protocols for downloading executable code over the internet
    • based on a technology that was not originally developed with network security issues in mind
    • something “between” a plug-in and a Java applet: extend browser functionality and allow automatically downloaded with a web page
  • types
    • native machine code: most dangerous type
    • Java bytecode: usually run inside the Java sandbox
    • a mixture of native code and bytecode
  • authenticode
    • ActiveX controls can be digitally signed using authenticode, Microsoft’s digital signature technology using public key certificate
    • a native code ActiveX control’s signature is checked only once: if the signature is valid and the signer is trusted, the control is downloaded
    • a Java bytecode ActiveX control’s signature is also checked at downloading
    • the actual access permissions are determined at runtime
  • procedure in IE
    • when IE downloads potentially dangerous content, it checks to see whether the code is digitally signed with a trusted certificate
    • depending on your browser security setting (high, medium, medium-low, low, or custom) for the zone the content is originating from and the success or failure of the authenticode verification process, the browser determines whether or not to automatically run the content
    • when prompted to allow or deny signed content, the user is allowed to inspect the signer’s digital certificate

JavaScript

  • definition and advantages
    • JavaScript provides a means of commanding the browser, including its graphical elements, from an HTML file
    • JavaScript is inherently more secure than Java applets because it cannot directly access the file system or open network connections (sandbox)
    • JavaScript are permitted to access only to data in the current document or closely related document (from the same site)
    • no access is granted to the local file system, memory space of other running programs, etc
  • JavaScript security
    • principle
      • there is no reason to trust randomly encountered code, and should treat them as hostile
    • security issues
      • it has access to all user information in the browser -> potential privacy violation
      • DoS attacks are possible by opening a large number of windows until the browser freezes
    • access control management: “same origin policy”
      • scripts from one web site do not have access to information such as usernames, passwords, or cookies sent to another site
      • e.g. using the handle returned by window.open(), the browser performs the same origin check
      • verifying that the URL of the document in the target window has the same origin as the document containing the calling script
      • 2 documents has the same origin if they were loaded from the same server using the same protocol and port
      • example
    • external script
      • externally linked scripts are considered part of the page they are embedded in, and thus can be linked in from other domain
      • e.g. the page at http://www.somesite.com/index.html could include the following script:
        <script type=text/javascript src=http://www.example.com/scripts/somescript.js></script>
        
        • this script will load and work as expected
      • the linked scripts are considered part of the page they are linked into
      • for the above example, if somescript.js tries access another window, it is considered to have come from http://www.somesite.com and subject to the some origin check

Summary

Security of Mobile Application

Mobile apps

  • a mobile app is a computer program designed to run on a mobile device such as a phone/tablet or watch
  • apps that are not preinstalled are available through distribution platforms app stores

Risks

  • malicious behavior
  • dangerous behavior
  • moderate risk behavior

Security requirement for mobile apps

  • traditional server-side requirement (much more than this in mobile security)
    • IT system security architecture
    • website security architecture
  • mobile client-side requirement
    • a device which can access to the system
    • contains
      • enabling authorized functionality
      • preventing unauthorized functionality
      • limiting permissions
      • protecting sensitive data
      • securing app code dependencies (e.g. heartbleed)
      • testing app updates
  • mobile app requirement
    • understanding mobile platforms (e.g. iOS and Android)
      • development APIs and security framework 
      • application permissions model (e.g. location, camera, microphone)
    • data management and data storage 
      • shared data
      • protected data
      • handle personal data and cache
      • data classification
        • what data should keep on the device and what data should send back to the server
      • data removal
    • protecting network communications 
      • apps can communicate with the services though different media, e.g. WiFi or 4G
      • how the apps interacts with the server
      • certificate, key and trust services
    • risk assessment 
      • does the app expose sensitive information of your backend system architecture
        • e.g. password of the database, admin account
      • can someone extract and modify your App to perform malicious actions