Author Archives: eremo

MS, the present attack on central MS systems – and the Bundeswehr

Posted on by

Some days ago I set up a list of questions regarding the Bundeswehr Leak of last week. During my discussion I touched the question that the BWI had praised its rollout of MS-based email-systems and Sharepoint platforms in large scale within the BW after Oct., 2021. Ironically I asked the question how the CCC would comment on this implementation of “notoriously insecure systems”.

Well, we do not need to ask the CCC any more. Yesterday, MS itself and the press informed the public once again that central key systems of Microsoft in the US are under attack. Probably a Russian hacker group is responsible. Actually, the present hacker activities continue and escalate an attack that already started in November 2023. It seems to be a fact that information gathered from core and central email systems is now abused systematically. Apparently, these emails have been stolen from executives and security staff. See also the article in the Washington Post about this topic.

You find more information at the following resources:

https://edition.cnn.com/ 2024/03/08/ tech/ microsoft-russia-hack/ index.html

https://abcnews.go.com/ International/ microsoft-russian-state-backed-hack-update/story ?id=107927553

https://www.reuters.com/ technology/ cybersecurity/ microsoft-says-cyber-threat-actor-has-been-able-access-internal-systems-2024-03-08/

https://www.washingtonpost.com/ technology/ 2024/03/08/ microsoft-hack-email-russia/

I hope that responsible managers at the BMVg or BWI read some of these information channels, too. And take notice of the comments of security officers of Sentinel One and CrowdStrike cited in the articles. And afterward reevaluate whether the broad rollout of MS-systems in the Bundeswehr really is a success story.

 

More fun with veth, network namespaces, VLANs – V – link two L2-segments of the same IP-subnet by a routing network namespace

Posted on by

During the last two posts of this series

More fun with veth, network namespaces, VLANs – IV – L2-segments, same IP-subnet, ARP and routes

More fun with veth, network namespaces, VLANs – III – L2-segments of the same IP-subnet and routes in coupling network namespaces

we have studied a Linux network namespace with two attached L2-segments. All IPs were members of one and the same IP-subnet. Forwarding and Proxy ARP had been deactivated in this namespace.

So far, we have understood that routes have a decisive impact on the choice of the destination segment when ICMP- and ARP-requests are sent from a network namespace with multiple NICs – independent of forwarding being enabled or not. Insufficiently detailed routes can lead to problems and asymmetric arrival of replies from the segments – already on the ARP-level!

The obvious impact of routes on ARP-requests in our special scenario has surprised at least some readers, but I think remaining open questions have been answered in detail by the experiments discussed in the preceding post. We can now move on, on sufficiently solid ground.

We have also seen that even with detailed routes ARP- and ICMP-traffic paths to and from the L2-segments remain separated in our scenario (see the graphics below). The reason, of course, was that we had deactivated forwarding in the coupling namespace.

In this post we will study what happens when we activate forwarding. We will watch results of experiments both on the ICMP- and the ARP-level. Our objective is to link our otherwise separate L2-segments (with all their IPs in the same IP-subnet) seamlessly by a forwarding network namespace – and thus form some kind of larger segment. And we will test in what way Proxy ARP will help us to achieve this objective.

Not just fun …

Now, you could argue that no reasonable admin would link two virtual segments with IPs in the same IP-subnet by a routing namespace. One would use a virtual bridge. First answer: We perform virtual network experiments here for fun … Second answer: Its not just fun ..

Our eventual objective is the configuration of virtual VLAN configurations and related security measures. Of particular interest are routing namespaces where two tagging VLANs terminate and communicate with a third LAN-segment, the latter leading to an Internet connection. The present experiments with standard segments are only a first step in this direction.

When we imagine a replacement of the standard segments by tagged VLAN segments we already get the impression that we could use a common namespace for the administration of VLANs without accidentally mixing or transferring ICMP- and ARP-traffic between the VLANs. But the results in the last two previous posts also gave us a clear warning to distinguish carefully between routing and forwarding in namespaces.

The modified scenario – linking two L2-segments by a forwarding namespace

Let us have a look at a sketch of our scenario first:

We see our segments S1 and S2 again. All IPs are memebers of 192.168.5.0/24. The segments are attached to a common network namespace netnsR. The difference to previous scenarios in this post series lies in the activated forwarding and the definition of detailed routes in netnsR for the NICs with IPs of the same C-class IP-subnet.

Our experiments below will look at the effect of default gateway definitions and at the requirement of detailed routes in the L2-segments’ namespaces. In addition we will also test in what way enabling Proxy ARP in netnsR can help to achieve seamless segment coupling in an efficient centralized way.

Continue reading →

After the Bundeswehr Leak and the explanation of the Minister of Defense – some more questions …

Posted on by

Today I heard the explanation of the German Minister of Defense regarding the probable cause of the leak of last Friday. What I understood was:

  • WebEx is hosted in a special variant (WebEx BWI) on servers of the Bundeswehr.
  • Clear rules are in place, but were not followed. One participant attended the WebEx session via telephone.
  • Systems were not compromised.

Are these explanations sufficient? Do they cover all concerns described in my previous post
“Some simple questions after the Bundeswehr Leak …”
on this topic?

In my opinion some questions remained open:

  • Why and by whom was the WebEx session set up such that a participant could access it via telephone at all? With a zero-trust and MLS-based session this should have been excluded …
  • Did the participants get an invitation with an option that offered an access to the session via telephone? If yes: Who sent this information via which channels? Is it excluded that already the invitation was accessible to foreign powers?
  • Why did nobody check by which devices and communication channels the participants were attending the session? At the beginning and during the session? Why did a log- and intrusion system not react?
  • Why did none of the other participants react to the fact that the poor guy in Singapore talked over telephone? Despite the clear rules in place …
  • How did the eavesdropping happen? Were the telephone lines of the hotel tapped? Or did the participant use a wireless headset with Bluetooth?

So, if it was a human failure it may have happened due to mistakes and unawareness on multiple sides – on the side of IT-administrators responsible for the session setup, on the side of the person which sent the respective invitation, on the side of the participant who did not use a BWI- or SINA-device to access the session.

Well, and I would say that when a session running through servers of the Bundeswehr was overheard by Russia, at least the session was compromised. And if someone can access an audio-session, which is enabled by and via a Bundeswehr server and which is intended to be secure, via an open telephone line then something is severely wrong in the overall security measures.

So, my dear Minister, as a concerned citizen I still do not sleep well. More explanations have to follow …

 

Some simple questions after the Bundeswehr Leak ….

Posted on by

I am following the present discussion about the leak of a communication between some generals of the German Air Defense from abroad. It really feels extremely embarrassing that the Russians could overhear a communication of high-ranked German army officers. And I do not know how to answer questions of retired Norwegian IT-specialists (of my age) here in the north of Europe … With German troops participating right now in huge Nato maneuvers in northern Norway. And believe me I have often criticized my Norwegian friends for a lack of IT-security awareness, in particular regarding the use of Microsoft and Zoom. And now this disaster in my home country …

From my point of view establishing a formal Untersuchungsausschuss (investigation committee) of the German parliament is only one of the necessary steps required to clarify what has happened. But it is an important one, together with internal and technical investigations within the Bundeswehr.

In this post I want to ask some simple questions which, in my opinion, should be answered. Any IT-guy having worked with or for public governmental institutions in Europe could ask them. None of the links I give below is classified.

Why WebEx at all?

The first point in all the TV and newspaper discussions is that there seems to be no doubt that the communication is authentic and that WebEx was used. Now, anyone with a basic idea about information security would ask the following question:

Why for heavens sake did the German officers use Webex at all? A product of Cisco, i.e. of a commercial US company? With published security problems during the Corona years? Why does the German military not have its own security protocols and measures in place?

Well, we and the US are allies, but … Yeah, but, … and Trump on the horizon.

It is a German company, “Secunet”, who has developed mobile systems (SINA workstations) compliant with for NATO certifications on different levels of security. See e.g.:
https://www.secunet.com/ loesungen/ sina-workstation-s
https://www.ia.nato.int/ niapc/ Product/ SINA-Workstation-S_730
https://www.bundeswehr-journal.de/2020/mehr-als-6000-geraete-sina-workstation-s-fuer-die-bundeswehr/
https://www.secunet.com/ueber-uns/presse/artikel/sicheres-mobiles-arbeiten-bwi-beschafft-sina-workstations-s-fuer-die-bundeswehr
https://www.secunet.com/ueber-uns/presse/artikel/secunet-beliefert-die-bundeswehr-mit-sina-sicherheitstechnologie-fuer-schnelle-eingreiftruppe-der-nato

These systems were bought by the Bundeswehr in relatively large quantities.

So, my first two open question are:

  • Why was WebEx used at all? Did the generals not have SINA-workstations available? If they had not, why not?
  • Under what conditions is the usage of WebEx regarded secure by the the responsible IT-specialists of the Bundeswehr?

Actually, the answer to the second question may not be independent of the answer to the first one … as WebEx may be hosted on servers of the Bundeswehr.

Addendum, 05.03.2024: Another point which comes up during TV discussions is that some “experts” say there is reason to believe that the WebEx-session was set up without any end-to-end-encryption. This is really implausible. What is more plausible is that the session was set up with standard encryption and Cisco’s standard management of encryption keys. And maybe – due to mistakes – with allowance for some participants to use a telephone. Making the session insecure again …

A success message of the BWI of 2021 regarding the rollout of Cisco’s WebEx in the Bundeswehr

What did we read in 2021 as a success message regarding the digitalization of the German defense and public institutions?

” … Zusammen und in Echtzeit an Dokumenten arbeiten, E-Mails austauschen, gemeinsame Termine planen, Webkonferenzen mit und ohne Video abhalten, chatten und telefonieren – wenn alle Services komplett ausgerollt sind, ermöglicht Groupware Bw dies auf einer einheitlichen technischen Plattform und über alle zivilen und militärischen Bereiche hinweg. Die BWI startete am 1. Oktober den Rollout mit den Produkten Cisco Jabber und Webex. In einem zweiten Schritt werden im kommenden Jahr auch die Services E-Mail und Enterprise Content Management mit Microsoft Outlook und SharePoint ausgerollt.”

See: https://www.bwi.de/ magazin /artikel/ groupware-bw-bei-der-bundeswehr-perfekt-vernetzt-von-chat-bis-videokonferenz

Even without translation the combination of tools praised here would make a security aware person more than nervous. And one can only hope that the introduction of these systems only concerns the civil sector of the Bundeswehr. If not, well, … just ask the CCC what they would think of it.

Continue reading →

More fun with veth, network namespaces, VLANs – IV – L2-segments, same IP-subnet, ARP and routes

Posted on by

In the course of my present post series on veths, network namespaces and virtual VLANs

we have studied a somewhat academic network scenario:

Two L2-segments were attached to a common network namespace, with all IPs of both segments belonging to one and the same IP subnet class. The network traffic was analyzed for different route configurations. Only detailed routes ensured a symmetric handling of packets in both segments.

The IP-setup makes the scenario a bit peculiar. It is not a situation an admin would normally create. Instead the IPs of each segment would be members of one of two distinct and different IP-subnets.

However, our scenario already taught us some important lessons to keep in mind when we approach our eventual objective:

Sooner or later we want to answer the question how to configure virtual VLAN configurations, in which veth subdevices for tagged VLAN lines terminate in a common and routing namespace.

By our academic scenario we found out that we need to set up much more specific routes than the standard ones which are automatically created in the wake of “ip addr add” commands. Despite the fact that forwarding was disabled in the coupling network namespace! Only with clear and fitting routes we got a reasonable behavior of our artificial network with respect to ICMP- and ARP-requests in the last post (III).

Well, this is, in a way, a platitude. Whenever you have a special network you must adapt the routes to your network layout. This, of course, includes the resolution of ambiguities which our scenario introduced. The automatically defined routes were insufficient and caused an asymmetry in the ICMP-replies in the otherwise very symmetric configuration (see the drawing below).

Nevertheless, the last post and also older posts on veths and virtual VLANs triggered an intense discussion of two of my readers with me concerning ARP. In this post I, therefore, want to look at the impact of routes on ARP-requests and ARP-replies between the namespaces in more detail.

The key question is whether and to what extend the creation and emission of ARP-packets via a particular network interface may become route-dependent in namespaces (or on hosts) with multiple network interfaces.

While we saw a clear and route dependent asymmetry in the reaction of the network to ICMP-requests, we did not fully analyze how this asymmetry showed up on the ARP-level.

In my opinion we have already seen that ARP-requests triggered within ICMP-requests showed some asymmetry regarding the NIC used and the segment addressed – depending on the defined routes. But the experimental data of the last post did not show the flow of ARP-replies in detail. And we only regarded ARP-requests triggered by ICMP-requests. I.e. we watched ARP-requests created by the Linux-kernel to support the execution of ICMP-requests, but not pure and standalone ARP-requests.

Therefore, it is still unclear

  • whether routes have an impact on pure standalone ARP-requests, i.e. ARP-requests not caused by ICMP-requests (or by other requests of higher layer protocols),
  • whether routes do have an impact on ARP-replies.

The experiments below will deliver detailed information to clarify these points.

When I speak of ARP-tables below, I am referring to the ARP-caches of the various network namespaces in our scenario.

Continue reading →