South Korea blocked port 25 for Security Issues Posted by Adel Mubarak , Wednesday, November 16, 2011 at 3:51 PM, in Labels: Security

Summary: South Korea is considering a nation wide block of port 25, as a anti-spam countermeasure aiming to reduce the volumes of spam affecting the country.

The ban, set to go in effect as of December, will replace port 25 with port 587 and 465 for SMTPS.

Spamming through web-based email is yet another way for cybercriminals to bypass the newly introduced regulations. Once the CAPTCHA-solving process for popular free web-based email providers has been outsourced to Indian providers of CAPTCHA-solving services, thousands of newly registered emails will be automatically used for outgoing spamming purposes, once again successfully bypassing the newly introduced regulation.

Mostly because of the way modern malware and spam networks operate. For instance, modern malware has built-in SMTP engines that are port-independent. Moreover, geolocated and malware-infected hosts within South Korea could be automatically updated using the new specs in a matter of seconds, once again continuing the abuse of legitimate networks, while playing by the newly introduced rules.

Code Vulnerability Scanner, Android Mobile App Posted by Adel Mubarak , Saturday, November 12, 2011 at 3:19 AM, in Labels: Security

The Nessus Android app enables you to log into your Nessus Scanner Server to Remotely Control your vulnerability scans by Applying start, stop and pause for your Hosted Internet Web-application as well as analyze the results directly from your Android device.

Download it NOW

Ruby's RSA Crypto Bug Posted by Adel Mubarak , at 2:17 AM, in Labels: Ruby

The Ruby developers had a near miss with a crypto disaster when an "awful bug" crept into the language's source code development tree. A simple programming error made the library generate RSA keys that caused the encryption mechanism to produce clear text. Luckily, the error was caught before it made it to any release version of Ruby, but it provides a good example of how a simple error can have potentially far-reaching effects.

The RSA asymmetric encryption technique differentiates between secret and public keys. The public key consist of a modulus n and an exponent e. The plain text, m, is encrypted according to the mathematical formula c = m^e mod n

The point is that the cipher, c, can usually only be decrypted with the secret key. However, the Ruby bug generated RSA keys with an exponent e=1. This only leaves c = m mod n

As m is always less than n, the RSA formula collapses into a variation of the legendary ROT26 cipher : c = m

Among other things, RSA is used for digital signatures. A signature generated with a key from a Ruby system with the defect is equivalent of a blank cheque, as it will cause any signature to be considered valid. Incidentally, the problem was caused by a trivial programming error that has nothing to do with cryptography: in a for loop for setting individual bits, the criterion for abandoning the loop was set incorrectly, causing every loop to be abandoned after the first iteration.

The problem only affects programs that have generated RSA keys with development versions of Ruby. The recent release of Ruby 1.9.3 is not affected by the problem. Where the problem does exist, the encryption and decryption functions appear to be working correctly; the bug has no effect on externally generated keys that are imported. Users of the development version of Ruby should check their Ruby programs if they generate keys and, if necessary, generate new keys as soon as possible.

Juniper Routing Problem disrupts Level 3 network Posted by Adel Mubarak , Wednesday, November 9, 2011 at 12:35 AM, in Labels: Linux Kernel

Yesterday several US and UK ISPs, including Time Warner Cable, Research in Motion, Eclipse Internet, Easynet and Merula, reported a range of errors and problems on the Level 3 backbone. Level 3 has now confirmed the reports. The cause of the problems appears to have been a bug in Juniper's Junos router operating system affecting the border gateway protocol (BGP).

US ISP Phyber Communications has told various US media organisations that other networks using Juniper routers were also affected by the failure, with most affected devices generating a memory dump and then restarting. Juniper manager Mark Bauhaus confirmed that the company had been made aware of the BGP error in edge routers on Monday morning. He stated that the bug had affected only a small number of Juniper customers and that the company already had a patch for the problem which was awaiting distribution to affected routers.

Source: Linux.com

XtreemOS, Enabling Linux for the Grid Posted by Adel Mubarak , Monday, July 18, 2011 at 9:03 AM, in Labels: Linux Kernel

XtreemOS is a Linux-based Operating System, supporting Virtual Organizations over Grid Computing platforms. The development of XtreemOS is currently funded as an Integrated Project by the European Commission under the Sixth Framework Programme (FP6) sponsorship program. The project started in June 2006 to last for 48 months, thus ending in May 2010. As of beginning 2010, the project has been extended and will last until September 2010. The project is led by INRIA and involves 19 research and industrial partners from Europe and China.

Download it :)

Slow HTTP DoS Attacks Posted by Adel Mubarak , Sunday, March 6, 2011 at 4:29 PM, in Labels: Security

the recent OWASP AppSec DC presentation on Slow HTTP POST DoS attacks, the issue of web server platform DoS concerns have reached a new high. Notice that I said, web server platform and not web application code. The attack scenario raised by slow HTTP POST attack is related to web server software (Apache, IIS, SunONE, etc...) and can not be directly mitigated by the application code. In the blog post, we will highlight the two main varieties of slow HTTP attacks - slow request headers and slow request bodies. We will then provide some new mitigation options for the Apache web server platform with ModSecurity.

Network DoS vs. Layer-7 DoS

Whereas network level DoS attacks aim to flood your pipe with lower-level OSI traffic (SYN packets, etc...), web application layer DoS attacks can often be achieved with much less traffic. The point here is that the amount of traffic which can often cause an HTTP DoS condition is often much less than what a network level device would identify as anomalous and therefore would not report on it as they would with traditional network level botnet DDoS attacks.

Layer-7 Connection Consumption Attacks

Ivan Ristic brought up the concept of connection consumption attacks in his 2005 book "Apache Security":

5.4.3. Programming Model Attacks

The brute-force attacks we have discussed are easy to perform but may require a lot of bandwidth, and they are easy to spot. With some programming skills, the attack can be improved to leave no trace in the logs and to require little bandwidth.

The trick is to open a connection to the server but not send a single byte. Opening the connection and waiting requires almost no resources by the attacker, but it permanently ties up one Apache process to wait patiently for a request. Apache will wait until the timeout expires, and then close the connection. As of Apache 1.3.31, request-line timeouts are logged to the access log (with status code 408). Request line timeout messages appear in the error log with the level info. Apache 2 does not log such messages to the error log, but efforts are underway to add the same functionality as is present in the 1.x branch.

Opening just one connection will not disrupt anything, but opening hundreds of connections at the same time will make all available Apache processes busy. When the maximal number of processes is reached, Apache will log the event into the error log ("server reached MaxClients setting, consider raising the MaxClients setting") and start holding new connections in a queue. This type of attack is similar to the SYN flood network attack we discussed earlier. If we continue to open new connections at a high rate, legitimate requests will hardly be served.

If we start opening our connections at an even higher rate, the waiting queue itself will become full (up to 511 connections are queued by default; another value can be configured using the ListenBackLog directive) and will result in new connections being rejected.

Defending against this type of attack is difficult. The only solution is to monitor server performance closely (in real-time) and deny access from the attacker's IP address when attacked.

The issue at hand with these attacks is that the client(s) are opening connections with the web server and sending request data very slowly. For those of you familiar with the old LaBrea Tarpit app for slowing down network based worms, this is somewhat of a reverse approach. Instead of the defender (LaBrea) sending back a TCP Window size of 0 to the attacker (worm) which would force the TCP client to wait for a period of time before resubmitting, in this scenario the attacker is the one forcing the web server to wait. If a web client opens a connection and doesn't send any data to the web server then the web server will default to waiting for the connection's Timeout value to be reached. Wanna guess how long that time interval is in Apache by default? 300 seconds (5 minutes). This means that if a client can simply open a connection and not send anything, that Apache child process thread will sit idle, waiting for data, for 5 minutes. Ouch... So the next logical question to ask from the attacker's perspective is - What is the upper limit on the number of concurrent connections for Apache? This depends on your configs but the main ServerLimit directive has a hard coded value of 20000 (most sites run much less). This limit makes it very feasible for a much smaller number of DDoS clients to take down a site vs. the extremely large number required for network-based pipe flooding.

There are two types of attack to cover when a malicious client never sends a complete Request as specified by the HTTP RFC:

Request       = Request-Line                      ; Section 5.1
                   *(( general-header        ; Section 4.5
                    | request-header         ; Section 5.3
                    | entity-header ) CRLF)  ; Section 7.1
                   CRLF
                   [ message-body ]          ; Section 4.3

Google Android Malware Posted by Adel Mubarak , at 3:47 PM, in Labels: Google

There is bunch of Android apps pulled from the Android Market because they contained malware. There were over 50 infected applications - these apps were copies of "legitimate" apps from legitimate publishers that were modified to include two root exploits and a rogue application downloader. This isn't the first example of malware on Android, but it may be the first to affect Google's own Android Market . This new malware has been referred to as DroidDream, RootCager, and myournet by various researchers and media outlets.

So how does this malware work? First of all, we can start with the basics of how Android apps work. Android applications are mostly written in Java and use XML files for configuration. The Android compiler suite takes a developer's Java files, compiles them to class files, and then converts the class files into dex files. Dex files are bytecode for the Dalvik VM that runs Android apps. The XML files are converted to a binary format that's optimized to produce small files. The dex files, binary XML files, and other resources needed to run an application are packaged into an APK file. These files have the extension .apk, but they're just ZIP files. Once the APK package is generated, it's signed with a developer's key and uploaded to the Android Market through Google's website.

When a user wants to install an app from the market, the APK package is downloaded and extracted onto their device. When an application is started, the Android device runs what is called an Activity in the application. The initial Activity, the program's entry point, is specified in a file called AndroidManifest.xml.

The AndroidManifest.xml file in infected packages was modified by the malware author to first launch the malware itself instead of the original application's Activity. To create the infected APK packages they unpackaged the original application's APK file, modified files and inserted their malicious code, then re-packaged the app and signed it with their own key. The apps were uploaded to the market, and in some cases were downloaded tens of thousands of times. This is the modified portion of theAndroidManifest.xml file used by this malware:

These settings cause the com.android.root.main Activity to be executed when the application is launched. It also configures two background services located in the classes com.android.root.Setting and com.android.root.AlarmReceiver. In the original application, the main Activity is in a completely different class.

What does this com.android.root.main Activity do when it runs? There are a few different ways to figure this out. My current preferred method is disassembling the Dex bytecode using the baksmali disassembler which produces human-readable disassemblies of compiled classes. It's also possible to decompile Dex files into Java sometimes, but it's still good to be able to read the disassembled code. Here is a smali snippet showing what the com.android.root.main.onCreate() function does when it's executed by the Android system:

This code starts the com.android.root.Setting service. It works by creating an instance of the Intent object, passing com.android.root.Setting's class object to the constructor. Then it calls the startService() method of the Intent object. This is roughly equivalent to this Android Java code:

  Intent intent = new Intent(this, com.android.root.Setting.class);   startService(intent); 

Next, the malware will start the original main Activity for the application:

This code locates the class for the original Activity by calling the static functionClass.forName(), passing the Activity's class name as the argument. If the class is found, a new Intent instance is created for the class and then startActivity() is called. Here's a Java representation, without the exception handling:

  Class klass = Class.forName(“net.luck.star.mrtm.HomeActivity”);   Intent intent = new Intent(this, klass);   startActivity(intent); 

After this, the com.android.root.Main Activity exits. So at this point, thecom.android.root.Setting service is running in the background and the original application starts up on the device. The unsuspecting user won't notice anything amiss.

The exploits

Now we can take a look inside of com.android.root.Setting. The onCreate()method of this class will attempt to get root access on the phone using two separate exploits - a udev exploit (CVE-2009-1185), and one based on adb resource exhaustion (the so-called rageagainstthecage exploit).

The udev exploit is executed by the com.android.root.udevRoot class. The actual exploit code is compiled C and is located in a file named exploid in the APK's assetsdirectory. This file is an ARM Linux ELF executable, a compiled version of theexploid2.c exploit which was publicly released around July of 2010. The exploit works by using hotplug to execute a shell as root. To actually cause hotplug to run,exploid will modify the state of the WiFi adapter and then return it to the original state. Other public versions of this exploit instructed the user to perform that action manually.

The installSu() method makes use of a file named profile in the APK's assets directory, which is another ARM ELF executable which just calls setguid(0),setuid(0), then execv("/system/bin/sh") - a classic root shell. This gets installed as /system/bin/profile with 04755 permissions - giving it the ability to run any command as root.

The adb exploit is a bit more complicated. It's executed by thecom.android.root.adbRoot class and the actual exploit is the compiled C in therageagainstthecage asset. This exploit is also known as CVE-2010-EASY, and uses a resource exhaustion attack against the Android debug bridge process, adb. adbinitially runs as root, but drops privileges with setuid(). However, the return value from setuid() isn't checked. Since setuid() fails when the target user is over theRLIMIT_NPROC value, adb will continue running as root if the user's process limit is maxed out. The rageagainstthecage exploit first determines the RLIMIT_NPROCvalue and then creates enough processes to reach the limit. When the limit is reached, a single process is killed and adb is restarted to take its place.

The adbRoot class makes use of thejackpal.AndroidTerm library, also packaged with the modified APK, to communicate with the rageagainstthecage exploit.

Phoning home

Before the root exploits are attempted, the malware starts a thread to make an HTTP post to a remote server. The information is formatted as XML and looks like this:

          1.0     0            %s       %s       %s       %s       %s         

The interesting values here are IMEI (International Mobile Equipment Identification) which identifies the physical phone handset, and IMSI (International Mobile Subscriber Identification), which identifies the SIM card in use in the phone. These values are unique identifiers for your phone and tracking them allows the malware controllers to determine exactly how many devices have been compromised.

Dropping more malware

At this point, if the malware has root access, it can do anything it wants to the phone. The last thing that the com.android.root.Settings class does before terminating is install another APK package that's included in the infected APK:

This code first checks to see if the com.android.providers.downloadsmanagerpackage is installed. If not, it copies the sqllite.db file - in the assets folder of the APK - to /system/app/DownloadProvidersManager.apk. We haven't yet fully analyzed this app yet, but it appears to have the ability to download and install other apps on an infected phone. The included AndroidManifest.xml file configures theDownloadCompleteReceiver class to run as soon as the phone boots up (using theandroid.intent.action.BOOT_COMPLETED intent) as well as when the phone state changes – for example when an incoming call is detected or a phone call is initiated (using the android.intent.action.PHONE_STATE intent).

Conclusion

According to Symantec, there were 52 total infected apps published to the Android Market: 21 by kingmall2010, 21 by myournet, and 10 by we20090202. They also claim that there were anywhere from 50,000 to 200,000 downloads of infected apps before they were pulled from the Android market. While the infected apps are now gone from the market, any infected phone is still potentially compromised.

A piece of malware with root access to a phone can read any data stored on it and transmit it anywhere. This includes contact information, documents, and even stored account passwords. With root access it's possible to install components that aren't visible from the phone's user interface and can't be easily removed. For this reason, any compromised phone should be reset to it's factory default state - in some cases this may require a trip back to the phone store.

Last year at SummerCon, Jon Oberheide demonstrated how easy it is to trick users into installing useless and fake applications that can download external malicious components. It's not necessary for apps in the market to contain malicious code embedded in them. So while this particular piece of malware was detected quite quickly, within a matter of days, it is possible for rogue apps to be stealthier.

Security conscious consumers should be wary of the apps they install on their phone and only install apps from reputable publishers though the official Android Market. Here are some things to look for to identify an app from a reputable publisher:

• The publisher has a website with contact information
• The app is from the official and original publisher (i.e., if you are installing Angry Birds, ensure it's from Rovio Mobile Ltd)
• App has a high number of downloads, ratings, and positive reviews