WEBVTT

1
00:00:03.200 --> 00:00:06.400
This is Decrypted. Monday, the twenty-first of September.

2
00:00:06.400 --> 00:00:11.720
SolarWinds fixes a hard-coded key in its access rights tool.

3
00:00:11.720 --> 00:00:18.080
On Thursday SolarWinds published a fix for a flaw in Access Rights Manager.

4
00:00:18.080 --> 00:00:22.800
That's its product for managing access rights across a company's systems.

5
00:00:22.800 --> 00:00:30.080
The flaw is a hard-coded static key, and it lets an unauthenticated attacker run code remotely.

6
00:00:30.080 --> 00:00:35.360
SolarWinds doesn't mention any exploitation, and I won't claim any.

7
00:00:35.360 --> 00:00:40.320
But a secret baked into software is one of the oldest design mistakes there is.

8
00:00:40.320 --> 00:00:45.360
And this one sits in a tool whose entire job is knowing where your permissions live.

9
00:00:45.360 --> 00:00:49.360
Next. What SolarWinds has said.

10
00:00:49.360 --> 00:00:56.240
The advisory covers C V E twenty twenty-six, two eight three two six.

11
00:00:56.240 --> 00:01:01.800
It's scored 8.8, High, on the C V S S scale.

12
00:01:01.800 --> 00:01:05.440
It affects Access Rights Manager 2026.

13
00:01:05.440 --> 00:01:10.640
2 and every earlier release, and it's fixed in 2026.

14
00:01:10.640 --> 00:01:19.360
2.1. The weakness is classed as C W E-321, use of a hard-coded cryptographic key.

15
00:01:19.360 --> 00:01:24.240
SolarWinds credited Kai Huang of Armadin with reporting it.

16
00:01:24.240 --> 00:01:31.039
The Hacker News covered it on Saturday, and notes that the advisory says nothing about attacks in the wild.

17
00:01:31.039 --> 00:01:35.280
SolarWinds hasn't published how the key is used.

18
00:01:35.280 --> 00:01:38.960
So I won't guess at the exact route to code execution.

19
00:01:38.960 --> 00:01:41.040
What matters is the shape of the mistake.

20
00:01:41.040 --> 00:01:44.280
And also. One key for every door.

21
00:01:44.280 --> 00:01:52.667
Imagine a hotel chain that cuts a single master key, builds it into the lock design, and ships identical loc

22
00:01:52.667 --> 00:01:56.320
ks to every branch. Nobody needs to pick anything.

23
00:01:56.320 --> 00:02:02.080
Anyone who gets hold of one lock, or its drawings, holds the key to all the others.

24
00:02:02.080 --> 00:02:05.120
A hard-coded key works the same way.

25
00:02:05.120 --> 00:02:08.560
It's the same secret inside every installation.

26
00:02:08.560 --> 00:02:13.200
So it stays secret only until someone takes one copy of the software apart.

27
00:02:13.200 --> 00:02:16.320
After that, it belongs to whoever looked.

28
00:02:16.320 --> 00:02:23.360
The customer has no obvious way to change it, which is presumably why SolarWinds' fix is a new version rather

29
00:02:23.360 --> 00:02:25.600
than a setting.

And also.

30
00:02:25.600 --> 00:02:31.520
What a defender can do.

In my reading, an attack like this involves no login.

31
00:02:31.520 --> 00:02:34.560
So there's no run of failed passwords to alert on.

32
00:02:34.560 --> 00:02:39.440
What you can control is knowing where the product is, and who can reach it.

33
00:02:39.440 --> 00:02:45.120
As the name suggests, Access Rights Manager is built to manage access rights.

34
00:02:45.120 --> 00:02:51.440
So my inference is that a server running it is well connected to the systems whose permissions it tracks.

35
00:02:51.440 --> 00:02:54.240
That makes it a poor place to be surprised.

36
00:02:54.240 --> 00:03:01.600
First, find every installation, including forgotten test ones, and upgrade to 2026.

37
00:03:01.600 --> 00:03:09.056
2.1.

Until that's done, limit network access to the server to the administrators and collectors that genuinel

38
00:03:09.056 --> 00:03:15.160
y need it.

And if you can't patch promptly, ask SolarWinds directly what the exposure looks like.

39
00:03:15.160 --> 00:03:18.560
And finally. The Secure by Design lesson.

40
00:03:18.560 --> 00:03:24.800
The N C S C's Software Security Code of Practice implementation guidance is blunt.

41
00:03:24.800 --> 00:03:28.360
"You should avoid hard-coded credentials in your software.

42
00:03:28.360 --> 00:03:35.440
" It also asks vendors to identify every credential that would cause harm in the wrong hands, naming passwords

43
00:03:35.440 --> 00:03:38.440
, certificates and A P I keys.

44
00:03:38.440 --> 00:03:43.360
The Code, produced by D S I T and the N C S C, is voluntary.

45
00:03:43.360 --> 00:03:46.560
The design decision that prevents this flaw is dull.

46
00:03:46.560 --> 00:03:53.152
Generate a unique secret when each installation is set up, or keep it in a proper secret store, instead of co

47
00:03:53.152 --> 00:03:54.720
mpiling one into the product.

48
00:03:54.720 --> 00:03:58.800
The cost is some engineering work for the vendor, once.

49
00:03:58.800 --> 00:04:04.400
The cost of skipping it is paid by every customer at the same moment, the day someone extracts the key.

50
00:04:04.400 --> 00:04:09.920
For UK buyers, that turns into a procurement question rather than a technical one.

51
00:04:09.920 --> 00:04:17.120
Ask suppliers, especially those whose tools hold privileged access to your directories, to show how they meet

52
00:04:17.120 --> 00:04:20.480
the Code and how their product handles keys.

53
00:04:20.480 --> 00:04:24.400
A vendor that can't answer in a paragraph has told you something useful.

54
00:04:24.400 --> 00:04:31.688
Buying software that manages access to everything else means your control over your own systems depends on de

55
00:04:31.688 --> 00:04:34.560
cisions made in someone else's build process.

56
00:04:34.560 --> 00:04:36.601
You're entitled to ask to see them.

57
00:04:36.601 --> 00:04:42.241
That was Decrypted. The written version and every source are linked in the show notes.

58
00:04:42.241 --> 00:04:43.361
Thanks for listening.

