I Have Seen The Light

Quite funny how Google matches the ads to the content of your blog, or not ... My post about Gremwells MagicTree was accompanied by ads for table lamps and LED lights.

This is a reminder to carefully choose your blog-titles, apparently they matter more than the content of the blog itself.

Looking forward to see what they come up with for this post. Please disable your ad-blockers and share some of the mismatches of Google’s algorithm.

Have a nice week-end and I hope you enjoyed this enlightening message!

Xplico Network Forensics Tool on Amazon Linux AMI

A few days ago we at Astyran needed a tool that could extract data from a network capture file. A quick Baidu search and we found the tool Xplico.

The goal of Xplico is to extract application data from internet network capture. Brilliant, exactly what we needed. In layman’s terms: you feed Xplico a capture file, and it will extract all data (pictures, emails, VOIP call, …). And even better, it is free!

According to the website the features of the current version (0.7.1) are as follows:

• Protocols supported: HTTP, SIP, IMAP, POP, SMTP, TCP, UDP, IPv6, …;
• Port Independent Protocol Identification (PIPI) for each application protocol;
• Multithreading;
• Output data and information in SQLite database or MySQL database and/or files;
• At each data reassembled by Xplico is associated a XML file that uniquely identifies the flows and the pcap containing the data reassembled;
• Real time elaboration (depends on the number of flows, the types of protocols and by the performance of computer -RAM, CPU, HD access time, …;
• TCP reassembly with ACK verification for any packet or soft ACK verification;
• Reverse DNS lookup from DNS packages contained in the inputs files (pcap), not from external DNS server;
• No size limit on data entry or the number of files entrance (the only limit is HD size);
• IPv4 and IPv6 support;
• Modularity. Each Xplico component is modular. The input interface, the protocol decoder (Dissector) and the output interface (dispatcher) are all modules;
• The ability to easily create any kind of dispatcher with which to organize the data extracted in the most appropriate and useful to you;

But don’t be scared of these technical details, Xplico is really simple to use, that is, if you can run it… Source code is available and some packages for Fedora and Ubuntu Linux server and workstation.

Alas, no package on Amazon AMI version and thus we had no choice but to compile Xplico on AMI. Ok, we had a choice, but we thought it was fun (that was, before the third sleepless night) to have it running on our AMI. Anyway, here is the result!

Request a 64-bit Amazon Linux AMI instance. use SSH to connect and type the following:

   1:  sudo su - 

   2:  yum install sqlite-devel

   3:  yum install zlib-devel

   4:  yum install openssl-devel

   5:  yum install flac-devel

   6:  yum install libjpeg-devel

   7:  yum install libpng-devel

   8:  yum install libvorbis-devel

   9:  yum install libao-devel

  10:  yum install gnutls-devel

  11:  yum install libtiff-devel

  12:  yum install speex-devel

  13:  yum install gcc

  14:  yum install gcc-c++

  15:  yum install make

  16:  yum install libtool

  17:  yum install patch

  18:  yum install git

  19:  yum install php-devel

  20:  yum install mysql

  21:  yum install mysql-libs

  22:  yum install mysql-devel

  23:  yum install libpcap-devel

  24:  yum install wireshark-devel

  25:  yum install libXt-devel

  26:  yum install libXaw-devel

  27:  cd

  28:  git clone git://github.com/pinard/Recode.git

  29:  cd Recode

  30:  ./configure

  31:  make

  32:  make install

  33:  make clean

  34:  cd 

  35:  git clone git://github.com/yasm/yasm.git

  36:  cd yasm

  37:  ./autogen.sh

  38:  make

  39:  make install

  40:  make clean

  41:  cd

  42:  wget http://downloads.sourceforge.net/project/opencore-amr/vo-amrwbenc/vo-amrwbenc-0.1.1.tar.gz 

  43:  tar -xzvf vo-amrwbenc-0.1.1.tar.gz

  44:  cd vo-amrwbenc-0.1.1

  45:  ./configure

  46:  make

  47:  make install

  48:  make clean

  49:  cd

  50:  wget http://ftp.penguin.cz/pub/users/utx/amr/amrwb-10.0.0.0.tar.bz2

  51:  tar -xvjf amrwb-10.0.0.0.tar.bz2

  52:  cd amrwb-10.0.0.0

  53:  ./configure

  54:  make

  55:  make install

  56:  make clean

  57:  cd

  58:  wget http://ftp.penguin.cz/pub/users/utx/amr/amrnb-10.0.0.0.tar.bz2

  59:  tar -xvjf amrnb-10.0.0.0.tar.bz2

  60:  cd amrnb-10.0.0.0

  61:  ./configure

  62:  make

  63:  make install

  64:  make clean

  65:  cd

  66:  wget http://www.ladspa.org/download/ladspa_sdk.tgz

  67:  tar -xzvf ladspa_sdk.tgz

  68:  cd ladspa_sdk/src

  69:  cp ladspa.h /usr/local/include

  70:  cd

  71:  wget ftp://ftp.mars.org/pub/mpeg/libmad-0.15.1b.tar.gz

  72:  tar -xzvf libmad-0.15.1b.tar.gz

  73:  cd libmad-0.15.1b

  74:  sed ‘/fforce-mem/d’ configure > sedtmp

  75:  mv sedtmp configure

  76:  chmod +x configure

  77:  make

  78:  make install

  79:  make clean

  80:  cd

  81:  wget ftp://ftp.mars.org/pub/mpeg/libid3tag-0.15.1b.tar.gz

  82:  tar -xzvf libid3tag-0.15.1b.tar.gz

  83:  cd libid3tag-0.15.1b

  84:  ./configure

  85:  make

  86:  make install

  87:  make clean

  88:  cd

  89:  wget http://www.mpg123.de/download/mpg123-1.13.4.tar.bz2

  90:  tar -xvjf mpg123-1.13.4.tar.bz2 

  91:  cd mpg123-1.13.4

  92:  ./configure

  93:  make

  94:  make install

  95:  make clean

  96:  cd

  97:  wget http://sourceforge.net/projects/lame/files/lame/3.99/lame-3.99.4.tar.gz

  98:  tar -xzvf lame-3.99.4.tar.gz

  99:  cd lame-3.99.4

 100:  ./configure

 101:  make

 102:  make install

 103:  make clean

 104:  cd

 105:  wget http://www.wavpack.com/wavpack-4.60.1.tar.bz2

 106:  tar -xvjf wavpack-4.60.1.tar.bz2

 107:  cd wavpack-4.6.0.1

 108:  ./configure

 109:  make

 110:  make install

 111:  make clean

 112:  cd

 113:  wget http://mikmod.raphnet.net/files/libmikmod-3.2.0-beta2.tar.gz

 114:  tar -xzvf libmikmod-3.2.0-beta2

 115:  cd libmikmod-3.2.0-beta2

 116:  ./configure

 117:  make

 118:  make install

 119:  make clean

 120:  cd

 121:  git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg

 122:  cd ffmpeg

 123:  ./configure --enable-nonfree --prefix=/usr --enable-gnutls --enable-libmp3lame --enable-version3

 124:  make

 125:  make install

 126:  make clean

 127:  cd

 128:  git clone git://sox.git.sourceforge.net/gitroot/sox/sox

 129:  cd sox

 130:  autoreconf -i

 131:  ./configure

 132:  make -s

 133:  make install

 134:  make clean

 135:  cd

 136:  wget http://geolite.maxmind.com/download/geoip/api/c/GeoIP-1.4.8.tar.gz 

 137:  tar -zxvf GeoIP-1.4.8.tar.gz

 138:  cd GeoIP-1.4.8

 139:  autoreconf -i

 140:  ./configure

 141:  make

 142:  cd

 143:  wget http://sourceforge.net/projects/xplico/files/Xplico%20versions/version%200.7.1/xplico-0.7.1.tgz

 144:  tar -zxvf xplico-0.7.1.tgz

 145:  cd xplico-0.7.1

 146:  wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

 147:  gzip -d GeoLiteCity.dat.gz

 148:  rm -f *dat.gz

 149:  make

 150:  cd

 151:  wget http://downloads.ghostscript.com/public/ghostpdl-9.04.tar.gz

 152:  tar -xvzf ghostpdl-9.04.tar.gz

 153:  rm -f ghostpdl-9.04.tar.gz

 154:  dd if=/dev/zero of=/tmp/tmpswap bs=1024 count=2000000

 155:  mkswap /tmp/tmpswap 2000000

 156:  swapon /tmp/tmpswap

 157:  cd ghostpdl-9.04

 158:  ./configure

 159:  make

 160:  cd

 161:  cp ghostpdl-9.04/main/obj/pcl6 xplico-0.7.1 

 162:  rm -rf ghostpdl-9.04

 163:  git clone git://github.com/sam-github/libnet.git

 164:  cd libnet/libnet

 165:  ./autogen.sh

 166:  ./configure

 167:  make

 168:  make install

 169:  wget http://sourceforge.net/projects/ucsniff/files/videosnarf/videosnarf-0.63.tar.gz

 170:  tar -xzvf videosnarf-0.63.tar.gz

 171:  cd videosnarf-0.63

 172:  ./configure

 173:  make

 174:  cd

 175:  cp videosnarf-0.63/src/videosnarf xplico-0.7.1

 176:  cd xplico-0.7.1

 177:  sed -i  ‘s/DLT_IPV4/228/’  dissectors/ip/ip.c

 178:  sed -i ‘s/DLT_IPV6/229/’ dissectors/ipv6/ipv6.c

 179:  sed -i ‘s/apache2/httpd/’ Makefile

 180:  mkdir /etc/httpd/sites-enabled

 181:  make install

 182:  cd

 183:  rm -f *.tar.gz

 184:  rm -f *.bz2

 185:  rm -f *.tgz

 186:  swapoff /tmp/tmpswap

 187:  rm -f /tmp/tmpswap 

At this moment, you can test the installation and rund xplico from commandline.

Next time, we try to get the web-enabled version running! Meanwhile, have fun!

History

2012/02/08 First version. Still some rough edges.

Ami does Experimental Arachni

Yes, Debbie is now Ami and no doubt she still brings happy endings to many towns.  Heads up, this blog reveals all in just three minutes, while Ruby needs 20 minutes to finish you of. Stop reading about “the best bang since the Big One” (see The Hitchhiker's Guide to the Galaxy) and do join us on this very hot day in Singapore and fire up your lap-tops to hit on something interesting and possibly catch a big fish.

Who told you that Information Technology was not sexy and fun? But sit back and relax, I was just trying to pimp my blog and penetrate the blogosphere!

I definitely did not want to bore you with the current most popular search terms in Singapore since everybody already knows where to find Chrissie Chau playing beach volleyball, nobody wants anything to do with Naomi Neo even on a Friday afternoon, and floating around is just not a good idea at Chingay.

Better play the Singapore Sweep or the Singapore Toto and be a happy camper. Or read this blog and brag at your fellow geeks that you just installed the experimental version of Arachni (a powerful fire-and-forget web application security scanner) on an AMI (Amazon EC2) image in 3 minutes. Hmm, maybe I do need a break ...

Anyway, here is your week-end assignment, fresh from the Astyran press.

First of all, install the latest and greatest version of Ruby on your AMI as we already explained in an earlier post. Ruby does a lot in 20 minutes, but this installation should not take you that long.

Here are the other commands needed for installation: 

   1: sudo su -

   2: cd

   3: gem install rake-compiler

   4: yum install libxslt

   5: yum install libxslt-devel

   6: yum install libsqlite-devel

   7: git clone git://github.com/Zapotek/arachni.git

   8: cd arachni

   9: git checkout experimental

  10: rake install

That’s it! Just fire up Arachni and hit on your favourite site (with the necessary approvals of course):

   1: cd

   2: arachni http://www.example.com --report=xml:outfile=arachni.xml &

Note that there are a myriad of command-line options available. You even have more options than food reviews available at Makansutra!

Afterwards you can upload the report in Gremwell’s MagicTree thanks to our XSLT sheet to translate Arachni XML output into a format that MagicTree understands. 

Have fun and do not forget to like us on Facebook! See you all next week. Now I’m hungry, so go where?

Deliberately Vulnerable Applications

Deliberately Vulnerable Applications are created to demonstrate vulnerabilities or test someone's skills in detecting those vulnerabilities. They can also be used for training purposes. At Astyran we often use those in training sessions and workshops.

Sometimes these applications are also used to compare the capabilities of automated tools, but the results should be taken with a large grain of salt: vendors have been known to tweak the capabilities of their tools to the vulnerable application rendering the results of the test questionable.

Keeping an up-to-date list is a challenge, so I intend to update this post every month. Currently the descriptions are taken from the authors websites. I will play around with the applications and see if they really are in sync with vulnerabilities we often find in real web applications.

If you have any comments or suggestions to further improve this list please don’t hesitate to contact me!

Applications

This is the list of intentionally vulnerable applications that need to be installed locally:

• Badstore: Badstore.net is dedicated to helping you understand how hackers prey on Web application vulnerabilities, and to showing you how to reduce your exposure. The demo software is distributed as an ISO image.
• BodgeIT: The BodgeIt Store is a vulnerable web application which is currently aimed at people who are new to pen testing.
• Butterfly: The ButterFly project is an educational environment intended to give an insight into common web application and PHP vulnerabilities. The environment also includes examples demonstrating how such vulnerabilities are mitigated.
• DVWA: The Damn Vulnerable Web App is a PHP/MySQL deliberately vulnerable application. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.
• Exploit.co.il: A vulnerable web app designed as a learning platform to test various SQL injection Techniques This is a fully functional web site with a content management system.
• Exploit-Db: Exploit-DB is not really a deliberately vulnerable application, but keeps an archive of vulnerable public domain web applications.
• ExploitMe Mobile Android Labs: This is an open source project by SecurityCompass demonstrating Android mobile hacking. The labs will help learn you about
  • Parameter manipulation of mobile traffic
  • Encryption of traffic
  • Password lock screens
  • File system access permissions
  • Insecure storage of files
  • Insecure logging
• ExploitMe Mobile iPhone Labs: This is an open source project by SecurityCompass demonstrating iPhone mobile hacking. The labs will teach you about:
  • Parameter manipulation of mobile traffic
  • Encryption of traffic
  • Password lock screens
  • File system access permissions
  • Insecure storage of files
  • Insecure logging
• Hackme Bank: Hacme Bank™ is designed to teach application developers, programmers, architects and security professionals how to create secure software.
• Hackme Books: Foundstone Hacme Books is a learning platform for secure software development.
• Hackme Casino: Foundstone Hacme Casino™ is a learning platform for secure software development.
• Hackme Shipping: Hacme Shipping is a web-based shipping application developed to demonstrate common web application hacking techniques.
• Hackme Travel: Hacme Travel is designed to create secure software.
• Hackxor: Hackxor is a webapp hacking game where players must locate and exploit vulnerabilities to progress through the story. Think WebGoat but with a plot and a focus on realism and difficulty. Contains XSS, CSRF, SQLi, ReDoS, DOR, command injection, …
• LampSecurity: LAMPSecurity is a series of vulnerable virtual machine images along with complementary documentation designed to teach Linux, Apache, PHP and MySql security.
• Mutillidae: Mutillidae is a Deliberately Vulnerable Set Of PHP Scripts that implement the OWASP Top 10.
• OWASP iGoat: The iGoat tool is a learning tool, primarily meant for iOS developers. Like WebGoat, iGoat users explore a number of security weaknesses in iOS by exploiting  them first. Then, once each weakness has been explored, the iGoat user must implement a remediation to protect against each weakness and validate that the remediation was successful. Hints and other background information are provided, right down to commented solutions in the source code, so that developers can use iGoat as a self-study learning tool to explore and understand iOS weaknesses and how to avoid them.
• OWASP GoatDroid: This is the Android equivalent to the iGoat Project. This project will help educate Android developers on security issues they’ll encounter when writing applications. 
• OWASP InsecureWebApp: InsecureWebApp is a web application that includes common web application vulnerabilities. It is a target for automated and manual penetration testing, source code analysis, vulnerability assessments and threat modeling. InsecureWebApp is primarily a teaching aid to challenge and improve secure design and coding skills.
• OWASP Vicnum: Vicnum is flexible web app showing vulnerabilities such as cross site scripting, SQL injections, and session management issues. Helpful to IT auditors honing web security skills and setting up 'capture the flag'.
• OWASP WebGoat: Webgoat is a deliberately insecure J2EE web application designed to teach web application security lessons. In each lesson, students must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application.
• Pandemobium:  Pandemobium is a collection of open source intentionally-flawed mobile applications that are intended to be used by developers and security analysts to explore mobile application security topics.
• Peruggia: Peruggia is designed as a safe, legal environment to learn about and try common attacks on web applications. Peruggia looks similar to an image gallery, but contains several controlled vulnerabilities to practice on.
• PuzzleMall: Puzzlemall is a vulnerable web application designed for training purposes. It is prone to a variety of session puzzle exposures. 
• SQLoL: SQLol is a deliberately vulnerable PHP application. It allows you to exploit SQL injection flaws, but furthermore allows a large amount of control over the manifestation of the flaw.
• WackoPicko: WackoPicko is a vulnerable web application written in PHP used to test web application vulnerability scanners
• Webmaven: WebMaven (better known as Buggy Bank) was an interactive learning environment for web application security. It emulated various security flaws for the user to find. This enabled users to safely & legally practice web application vulnerability assessment techniques. In addition, users could benchmark their security audit tools to ensure they perform as advertised.

Collections

This is a list of collections of vulnerable applications:

• Dojo: The Web Security Dojo project comes preloaded with several web app targets and tools for an easy no-install environment to get you started with learning web app security testing.
• Moth: Moth is a VMware image with a set of vulnerable web applications and scripts, that you may use for testing web application security scanners, testing static code analysis tools (SCA), giving an introductory course to web application security
• OWASP BWA: The OWASP Broken Web Applications Project is a collection of vulnerable web applications that is distributed on a virtual machine.
• Stanford Securitybench: Stanford Securibench a set of open source real-life programs to be used as a testing ground for static and dynamic security tools. All the benchmarks are Java J2EE applications that can be run on a Web server.

Online

This is a list of online applications that can be used for testing and learning. I did not include tool vendor websites, since it is not clear if these can be used by anyone (usually there is a statement that they can only be used for demonstrating the capabilities of the tool sold by that vendor):

• Enigma Group: Enigma Group provides a series of challenges for people to test their pen-testing skills.
• Google Gruyere: Google Gruyere shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you'll get a chance to do some real penetration testing, actually exploiting a real application. Specifically, you'll learn the following:
  • How an application can be attacked using common web security vulnerabilities, like cross-site scripting vulnerabilities (XSS) and cross-site request forgery (XSRF).
  • How to find, fix, and avoid these common vulnerabilities and other bugs that have a security impact, such as denial-of-service, information disclosure, or remote code execution.
• HACKME Game: this is software security (web applications) learning game, intended to help raise awareness and interest in the subject of software security as well as train developers.
• OWASP HackAcademic: The OWASP Hackademic Challenges Project is an open source project that helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. This is both an online and downloadable project. A customized version for Appsec Europe is online at http://www.hackademic.eu/.
• p0wnlabs: Online versions of vulnerable applications and distributions.
• Watcher Test Pages: Test pages for the Watcher tool, a Fiddler add-on which aims to assist penetration testers in passively finding Web-application vulnerabilities.
• X5S Test Page: A small working example of how to use the x5s tool to detect encoding and transformation issues that can lead to XSS vulnerabilities.

Tool Testers

Although not strictly related to deliberately vulnerable applications, a list of applications that can check and rate the capabilities of tools is very important. Any consultant should know exactly the capabilities and limitations of his toolset. If a tool is lacking in coverage or depth, another tool might be appropriate to fill the gap or the tester might need to use his brain cells more.

A consultant who does not know what the limitations, strengths and weaknesses are of his tools will miss vulnerabilities. Having a complementary set of tools will aid the consultant to deliver a cost-effective, comprehensive test in a limited amount of time.

Name	Description
OWASP SiteGenerator	OWASP SiteGenerator allows the creating of dynamic websites based on XML files and predefined vulnerabilities (some simple, some complex) covering .Net languages and web development architectures (for example, navigation: Html, JavaScript, Flash, Java, etc...).
Stanford SecuriBench Micro	Securibench Micro is a series of small test cases designed to exercise different parts of a static security analyser. Each test case in Securibench Micro comes with an answer, which simplifies the comparison process.
Wavsep	A vulnerable web application designed to help assessing the features, quality and accuracy of web application vulnerability scanners. This evaluation platform contains a collection of unique vulnerable web pages that can be used to test the various properties of web application scanners.
Wivet	A benchmarking project that aims to statistically analyse web link extractors. In general, web application vulnerability scanners fall into this category: given a URL(s), they try to extract as many input vectors as possibly they can to increase the coverage of the attack surface. A recent list of the results can be found here.
ZAP Wave	A collection of examples of vulnerable pages for the ZAP proxy.

Lists

Here are some other sources on the Internet related to lists and discussions of deliberately vulnerable applications.

• http://securitythoughts.wordpress.com/2010/03/22/vulnerable-web-applications-for-learning/
• http://www.irongeek.com/i.php?page=security/deliberately-insecure-web-applications-for-learning-web-app-security
• http://zastita.com/079938/vulnerable-by-design.html
• http://www.felipemartins.info/2011/05/pentesting-vulnerable-study-frameworks-complete-list/

Updates

20/02/2012 added Pandemobium
29/01/2012 added SQLoL
28/01/2012 spellcheck
12/12/2011 added yet another list, added Hacmegame
26/10/2011 Added ExploitMe Mobile
20/09/2011 Added Puzzlemall
26/08/2011 GoatDroid is released
08/08/2011 Added link to SecToolsAddict
27/07/2011 Added link to GoatDroid
26/06/2011 Added link to Zastita.com
20/06/2011 Added OWASP iGoat, WackoPicko

Do Androids Dream of Secure Apps?

I love the book “Do Androids Dream of Electric Sheep?” by Philip K Dick (Kindle link here), the book Ridley Scott based his science fiction movie Blade Runner on. The book tells a compelling tale pondering on the age-old question ‘What makes us human?’.

I am not a philosopher, so I leave it up to you to answer the above question, while I will make an attempt to keep this blog to the topic of application security and especially the question of today ‘how to write a secure Android app?’ or better, Astyran’s speciality: ‘how to test an app for security?’.

Hmm, now that I think about it, maybe I should just have made a reference to another Ridley Scott movie, “Alien”, since this is more about ripping apart an app.

Luckily many people tried to answer the question about secure apps, so here is my list of application security resources for Android apps with some - hopefully useful - comments. 

Background

A lot of information is available on the Android security model, so here is only a quick rundown:

• No app has by default permissions to perform anything that would adversely impact other apps, the Android OS or the user;
• Applications, whether Java based, native or hybrid, are sandboxed, and at installation time, the user must explicitly give permissions to share resources or data with other apps;
• The security model is based on Linux. Normally apps get a distinct user-id, but the developer can set a fixed one which allows (maximal two apps at the same time) to share data and resources.
• Data is by default only accessible by the app’s user-id, but files can be made world-readable and/or world-writeable by setting a flag in the code at creation time.  

Note however that modifications by the phone vendors might have removed all these security features.

Google

Google provides a nice overview of the security features build into Android. This is good reading before the start of development or security review. They also provide a security FAQ for developers, security practices (I still need to integrate most high-level practices in the checklist below), more general security information and a discussion group.

The above information (and especially the FAQ) can be used to make a high-level checklist for your Android app security review, such as the table below.

I stress that these are only Android-specific issues, generic application security vulnerabilities or weaknesses must be checked too! 

Item	Check	Notes
01	Verify the signature on the .apk file. Make certain this is not the debug key generated by the Android SDK tools. Not security related, but might be interesting for your client: make certain that the cert validity ends after 22/10/2033 or the app cannot be published in the Android market (a validity period of more than 25 years is recommended).	The certificate can be self-signed. It is just used to grant or deny apps access to signature level permissions and requests to share the same user-id. This means anyone can publish an app, without being controlled. An amusing example of what might happen is given on Jon Oberheide’s blog.
02	Verify if a shared user-id is requested, which one is used, and assess the possible security impact.	Check out the requested user-id, in the <manifest> element in the AndroidManifest.xml file. This request only succeeds if the apps are signed by the same certificate. Whether or not this sharing of user-ids is a security issue, can only be verified by looking at both apps. Talk to your customer, or make this remark in your report.
03	Verify all requested permissions and ensure that they are appropriate.	Install the app and/or look at the <uses-permission> element in the AndroidManifest.xml file. ’Appropriate’ depends on your customer’s business goals.
04	Verify all requested permissions and make note of the potential attack surface.	Input (e.g. from logs, test messages, internet) might be malicious and might be a source of Cross-Site-Scripting vulnerabilities or other defects.
05	Verify all permission definitions and make certain they are correct and inform the user appropriately when needed.	Permissions for app operations are configured in the <permission> element of the AndroidManifest.xml file.
06	Check the permissions given to other applications and verify that they are not overly broad or dangerous.	This is done by verifying the android:permission attributes in the AndroidManifest.xml file. Check the <activity>, <service>, <receiver> and <provider> tags. Note that services and activities are exported by default. If this is unwanted, they should have an android:permission attribute. Receivers are also by default exported. Check the <receiver> element.
07	Verify the URI permissions for a content provider and ensure the are correct and not overly broad or dangerous.	Check out the permissions and intents in the <grant-uri-permission> element in the AndroidManifest.xml file and grantUriPermission(), revokeUriPermission() and checkUriPermission() in the source code.
08	Implement input validation within an  intent receiver to confirm that it is properly formatted for the invoked receiver, service, or activity.	Note that intent filters are not security features; this is often misunderstood by developers. Verify this by looking at the source code for all receivers, activities and services that are exported (this is the default).
09	Check the fine-grained permissions granted to other apps.	Verify the calls to CheckCallingPermission() in the source code. This is a more fine-grained method to check permissions.
10	Verify that file-permissions are not overly broad.	Look at the permissions of files/databases created by the app, or verify the permissions in the source code, especially world readable or writeable settings (look for MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE flags)
11	Verify the use the execSQL().	Look at the source-code. ExecSQL() is vulnerable to SQL Injection.
12	Review storage on external storage such as SD cards. These should never be used for confidential data.	Encryption is only available since Gingerbread, but does not block apps from accessing each other’s data. Files stored on external storage are world-readable and writeable.
13	Review the loading of executable files from external storage.	See above. The executable files should be signed and cryptographically verified before loading. Verify this by looking at the source code.
14	Review the possible information leakage using the back-up service.	Android makes no guarantee about the security of your data while using back-up. Cloud storage and transport service might differ from device to device. Applications using the device provided backup have the backup agent declared in the android:backupAgent attribute in the in the AndroidManifest.xml file.
15	Verify the use of Security Best Practices for in-app billing.	Check out the list of Security Best Practices for in-app billing and verify that it is implemented.
16	Verify that logs do not contain confidential information.	Logs are a shared resource on Android, and are available to an application with READ_LOGS permission. Verify the logs manually or review the source code and searching for ‘Log’ (the relevant class-name is android.util.Log)
17	Verify that usernames and passwords are not stored on the device.	Review files created by the application or the source code if available. When an AccountManager is used, the CREATOR must be checked before passing the credentials. Other possibility is to use checkSignature() to verify that only your own applications can access the AccountManager or use the KeyStore if only one application will use the credential.
18	Verify the use of a secure random number generator to initialize cryptographic keys.	Not really Android specific. Look for SecureRandom and correct seeding, and KeyGenerator in the source code. Do not create your own encryption protocol. Keys must be stored in a KeyStore.
19	Verify the security design and implementation.	Check the implementation of Android best practices. Note: I intend to make this into a more detailed checklist, if not already covered by the above checks.

Tools

Note that some JAVA tools might be relevant too. Of course, there are also commercial tools available, but I leave it to their marketing departments to spread that message.

Tool	Comments
androguard	Provides reverse engineering and malware analysis of Android applications.
androidAuditTools	Toolset written in Ruby to visualize file system differences before and after running an app. This blog explains it all.
ApkInspector	Visualizes compiled Android packages and their corresponding DEX code and tries to create a unified platform that combines several existing Android reverse engineering tools. A video with overview can be streamed on Tudou.
napktool	Decodes binary Android apps to nearly original form and rebuild them after making some modifications.
ComDroid	COMDROID is an online tool that detects application communication vulnerabilities. It emits warnings for both sending- and receiving-based Intent vulnerabilities and gives additional details on when the developer may be misusing Intents.
ded	Decompiles Android Apps.
dex2jar	This converts Android's .dex format to Java .class format. Afterwards one can use a Java de-compiler such as JAD or JD-GUI to look at the source code.
DroidBox	Offers dynamic analysis of Android Applications in a sandbox.
pptpd	Not really an Android tool, but can be used to set up a VPN server. Configure your device to connect to this VPN in order to sniff the network traffic between app and server.
smali	Assembler/Disassembler for Android’s dex format.
smartphonesdumbapps	Scripts to analyse Android and iPhone applications from Denim Group.
StowAway	STOWAWAY is an online tool for identifying permission use in Android applications.
TaintDroid	Tracks how apps use sensitive information. In order to use this, you must flash custom-build firmware in your device.

Deliberately Vulnerable Applications for training purposes

I just updated my generic list of deliberately vulnerable applications, here the Android applications:

• ExploitMe Mobile Android Labs: This is an open source project by SecurityCompass demonstrating Android mobile hacking. The labs will teach you about:
  • Parameter manipulation of mobile traffic
  • Encryption of traffic
  • Password lock screens
  • File system access permissions
  • Insecure storage of files
  • Insecure logging
• OWASP GoatDroid: This is the Android equivalent to the iGoat Project. This project will help educate Android developers on security issues they’ll encounter when writing applications.

 

Other Resources

Some links I found useful while doing the research for this blog.

• Using Static Analysis to review file access in Android Apps, by Dan Cornell
• Static Analysis of Android Applications, by Peter Teoh
• Smartphone Secure Development Guidelines from ENISA 
• The OWASP mobile security project (not much activity, alas)
• http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks

Remark

Remember, the above items are not the only things that are important for Application Security on Android, they are just the Android specific items! Everything else (e.g. see OWASP testing guide) must still be verified too! Think SQL Injection, XSS, secure communications, …

History

29/01/2012 - first release.

Installing Ruby v1.9.3 on Amazon Ami Image

At Astyran we love to use virtual servers in the cloud, since they are quite convenient to run and test some tools. Unfortunately, the Amazon Linux image, only includes an older version of Ruby, while most tools now require Ruby 1.9.2 or higher.

So here is the procedure:

• create a (micro) EC2 instance (64 bits) - note: this is for free, for the first year!
• login (use SSH) as ec2-user, and enter the following in the shell:

$ sudo su -
$ yum groupinstall 'Development Tools'
$ yum groupinstall development-libs
$ yum install readline-devel
$ yum install zlib-devel
$ yum install openssl-devel
$ yum install libffi-devel
$ yum install libyaml-devel
$ yum update
$ wget ftp://ftp.ruby-lang.org//pub/ruby/1.9/ruby-1.9.3-p0.tar.gz
$ tar xzvf ruby-1.9.3-p0.tar.gz
$ cd ruby-1.9.3-p0
$ ./configure
$ make
$ make install
$ make clean
$ gem update --system
$ ruby --version (this should give you the newly installed version)

That’s it! Have fun using Ruby!

Application Security Training in Singapore and Kuala Lumpur

Just a quick update. We fixed the dates for the regular Astyran application security training sessions in Singapore and Kuala Lumpur. Visit our website for the details!

We also have a new training offering: Web Application Vulnerability Assessment (WAVA) and Ethical Hacking.

About WAVA and Ethical Hacking

This hands-on course provides participants with insight and knowledge about typical web application vulnerabilities such as Cross-Site-Scripting and SQL Injection. More important, the course focuses on the techniques to detect those weaknesses in your critical applications.

Contrary to other ethical hacking courses we do no focus on how to hack an application, but teach a standardised and repeatable process to detect software vulnerabilities before criminals exploit them or even before your application goes live.

In short, after the course, the trainees will be able

• To assess your application in a repeatable and consistent manner;
• To provide you with a quality report in line with the requirements and expectations from the regulatory authority, the Payment Card Industry (PCI) or your auditors, customers and partners.

Repeatable Assessment Process

This standard process we teach is based on generally accepted best practices such as the Testing Guide from the Open Web Application Security Project (OWASP) to check for typical application level vulnerabilities as well as software design related errors.

The approach focuses on manual work using the acquired skills complimented by widely available tools.

Quality Report

Trainees will be given a template report and trained to use this. The report provides value for both management as well as the development team.

This reporting template is based on requirements from the OWASP Application Security Validation Standard (ASVS) and includes further explanations with relevant links to the Common Weakness Enumeration (CWE) and the Common Attack Pattern Enumeration and Classification (CAPEC).

Course Format

An experienced application security consultant will give the course, consisting of lectures, quizzes and workshops where participants will learn to assess applications for security issues using their acquired skills and widely available tools.

Who Should Attend

The course would be highly beneficial to attendees who will provide internal or external web application vulnerability assessments. In particular, the following audience would appreciate the course:

• Staff in a Quality Assurance (QA) role
• Developers creating web applications
• Junior Application Security Consultants

More information needed? Contact Astyran!