If there are no services listening on any port & if Nftables is enabled can I still get hacked ?

hifi100 · 07-17-2021, 11:06 AM

I wanted to know the answer to this question for a long time now.

If there are no services listening on any port & if Nftables is enabled can I still get hacked ?

syg00 · 07-18-2021, 06:54 AM

How did you make this post ?. And how do you read this response ?.

maw_walker · 07-19-2021, 10:22 AM

Quote:

Originally Posted by hifi100

I wanted to know the answer to this question for a long time now.

If there are no services listening on any port & if Nftables is enabled can I still get hacked ?

Need more info: server or desktop? When you say "hacked", what do you mean, at the web app level (server) or at the OS level (desktop)?

A-Okay · 07-21-2021, 11:24 AM

we could send you a payload. If the payload is executed on your system, it could theoretically setup a service and start it and then connect to it back. Correct me, if I'm wrong.

hifi100 · 07-27-2021, 09:26 AM

Sorry for the late reply. I don't know why but I didn't receive any email notification for this thread.

Quote:

Originally Posted by syg00

How did you make this post ?. And how do you read this response ?.

Yes I understand what you are saying. Sorry I should have written first 1000 ports. Some ports needs to be open to allow (at least) web traffic but those ports are opened only temporarily. I say temporarily coz I tested all ports using Nmap using the command

Code:

nmap -p- 192.168.xxx.xx

I found some ports open but when I repeated the same test just a moment after the first test it showed a different (open) port.

Quote:

Originally Posted by maw_walker

Need more info: server or desktop? When you say "hacked", what do you mean, at the web app level (server) or at the OS level (desktop)?

Its a desktop. By hacked I meant someone intruding into my system & viewing my personal files as if he is the owner.

Quote:

Originally Posted by A-Okay

we could send you a payload. If the payload is executed on your system, it could theoretically setup a service and start it and then connect to it back. Correct me, if I'm wrong.

Can you me teach what this "payload" is ? I mean under Windows executable ends with exe but under Linux it differs from distro to distro. Like for Debian & derivatives its .deb. For RPM based distros its .rpm. While browsing the web I have never found any site trying to push a .deb or .rpm so I am curious how does this payload which targets Linux looks like.

Turbocapitalist · 07-27-2021, 09:38 AM

Payload is any executable delivered by a successful attack, but only if it is suitable for the architecture. APT and RPM are not executables even if the do contain executables. Any given program has to be compiled specially for the specific type of hardware in order to be able to run once it gets into the system, otherwise it is just a stream of harmless bytes. The type of hardware would be x86 (Intel/AMD) or MIPS or Arm or POWER or even less comnon architectures. One example of that kind of thing was the Carna Botnet from 2012.

If you are talking about a desktop system, then the weak point would be the browser especially if you allow javascript-infected web pages to fetch and run javascript on your machine. A malicious actor could try many things, successfully, including Rowhammer JS, to jump from the browser into a privileged account within the system. There are really only two browsers these days, Firefox and the Chromiun-based ones. Both are full of more holes than Swiss cheese, since development is focused far away from improving the code.

If you want to mitigate the risk, then work out a custom SELinux or AppArmor profile and severely restrict what filesystem access the browser can have.

hifi100 · 07-27-2021, 09:45 AM

@Turbocapitalist
Thanks for that explanation. I am using a Corei3 Intel processor. I was using Firefox but now I am using LibreWolf. Despite being paranoid about security & privacy the one thing that I failed to do was cope with the Noscript addon. I mean I kept whitelisting scripts on various pages days after days & finally gave up. I am not using SELinux or AppArmor but I am running LibreWolf under Firejail. In your opinion is Firejail as good a SELinux or AppArmor in terms of the level of protection it provides ?

Turbocapitalist · 07-27-2021, 09:53 AM

Well with any x86 processor there is almost nothing which can be done beyond some of the more basic counter measures. If you want to know more about why x86 is a totally lost cause and beyond repair, see scholarly works about Spectre(r) and Meltdown(r) brand categories of speculative execution attacks. The use of speculative execution was ruled out as a bad idea in the 1980s, but Intel (followed by others) decided somewhat more recently to use it anyway to cheat on performance. The result is that x86 cannot be properly secured. That's an oversimplification but covers the main points.

Quote:

Originally Posted by hifi100

In your opinion is Firejail as good a SELinux or AppArmor in terms of the level of protection it provides ?

With any of those the results are 100% dependent on how your configuration allows or denies access. So the answer is, it depends entirely on what you have configured any of those to do. If they are configured to let the browser run amok, the browsers will potentially do so.

hifi100 · 07-27-2021, 10:04 AM

Quote:

Originally Posted by Turbocapitalist

Well with any x86 processor, there is almost nothing which can be done beyond some of the more basic counter measures. If you want to know more about why x86 is a totally lost cause and beyond repair, see scholarly works about Spectre(r) and Meltdown(r) brand categories of speculative execution attacks. The use of speculative execution was ruled out as a bad idea in the 1980s, but Intel (followed by others) decided somewhat more recently to use it anyway to cheat on performance. The result is that x86 cannot be properly secured. That's an oversimplification but covers the main points.

Frankly that's extremely depressing. As far as I know the majority of computer users all over the world are using x86. So suppose if I put a very secure perimeter firewall like OpenBSD in front of an x86 desktop will it gain any improvement ? I am asking this question simply out of frustration. In super secure environments where people cannot afford to get hacked, which architecture do they use ?

Quote:

Originally Posted by Turbocapitalist

With any of those the results are 100% dependent on how your configuration allows or denies access. So the answer is, it depends entirely on what you have configured any of those to do. If they are configured to let the browser run amok, they browsers will potentially do so.

Firejail is made keeping average user in mind. As an example the default profile for Firefox is made in such a way that only /home/username/Downloads can be accessed & access to stuff like /boot cannot be reached. I am not Firejail expert but this is what I have found about Firejail so far.

maw_walker · 07-27-2021, 10:31 AM

All home LANs should have some sort of firewall, be it hardware or software. Your router should have a built in firewall. Most cyber criminals are not going to bother with a single desktop because there is little or nothing to gain but some "script kiddie" might. You should still secure your system though. I have software firewalls running on all my systems, plus the firewall on my router set to "stealth" and no ports open inbound.

Keep in mind that all outbound traffic originating from your desktop will come back: that's how networking works. You can close all inbound ports on a firewall but not all outbound or you effectively isolate the machine you are trying to protect and you won't be able to access the Internet.

hifi100 · 07-27-2021, 10:55 AM

@maw_walkwer
Understood but what about Spectre(r) and Meltdown(r) ? That's hardware level suff.

Can someone please have a look at my lscpu output & tell me if I am patched.

Code:

$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz
    CPU family:          6
    Model:               94
    Thread(s) per core:  2
    Core(s) per socket:  2
    Socket(s):           1
    Stepping:            3
    CPU max MHz:         3700.0000
    CPU min MHz:         800.0000
    BogoMIPS:            7402.02
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clf
                         lush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm c
                         onstant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc c
                         puid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg 
                         fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time
                         r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_s
                         ingle pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad
                          fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap c
                         lflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp h
                         wp_notify hwp_act_window hwp_epp md_clear flush_l1d
Virtualization features: 
  Virtualization:        VT-x
Caches (sum of all):     
  L1d:                   64 KiB (2 instances)
  L1i:                   64 KiB (2 instances)
  L2:                    512 KiB (2 instances)
  L3:                    3 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-3
Vulnerabilities:         
  Itlb multihit:         KVM: Mitigation: VMX disabled
  L1tf:                  Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
  Mds:                   Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown:              Mitigation; PTI
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP condit
                         ional, RSB filling
  Srbds:                 Mitigation; Microcode
  Tsx async abort:       Not affected

maw_walker · 07-27-2021, 11:16 AM

That has zero to do with LAN security. If you install something that takes advantage of those vulnerabilities then all bets are off but having a vulnerable CPU does not mean your LAN is less secure. The attack vector from those vulnerabilities on a desktop involves having unpatched operating systems or other installed software that can leak data.

Turbocapitalist · 07-27-2021, 11:50 AM

Those unpatchable holes are relevant to the LAN and the original question because the browser may be going out and bringing in scripts or worse into a LAN-connected system and thus provide a level of exposure. Both categories of hardware holes are design-level and, futhermore, unpatchable. There are a handful of mitigations to lower the risk but nothing to eliminate it, not even updated microcode, except to leave x86 behind.

So far, most of the world has chosen to shrug their shoulders and pretend that neither category of problem is there for those still left on x86.

The browser itself has bugs, some of which get discovered before they are patched, some of those turn out to be exploitable. There the solution is twofold. First try to keep the software up to date / patched. Second use Firejail, AppArmor, or SELinux to ensure that the browser can only access a few directories and not dig around in either system files or sensitive account data. Also, not letting the browser run javascript reduces the attack surface greatly.

No single step will block all the attack vectors. See "layered security" or "defense in depth".

maw_walker · 07-27-2021, 12:02 PM

Agree and I thought about that when I posted. The javascript advice is good but sadly, that breaks about 90% of the Internet. Personally I hate javascript because there are so many terrible implementations of it out there but it's not going away any time soon unfortunately.