Information Technology

US federal agencies must update by the end of the year or take all SolarWinds Orion apps offline. More

Image via matthrono (Flickr/CC2.0)The US Federal Bureau of Investigation says pranksters are hijacking weakly-secured smart devices in order to live-stream swatting incidents.
“Recently, offenders have been using victims’ smart devices, including video and audio capable home surveillance devices, to carry out swatting attacks,” the FBI said in a public service announcement published today.
Officials say pranksters are taking over devices on which owners created accounts but reused credentials that previously leaked online during data breaches at other companies.
Pranksters then place calls to law enforcement and report a fake crime at the victims’ residence.
“As law enforcement responds to the residence, the offender watches the live stream footage and engages with the responding police through the camera and speakers,” the FBI said.
“In some cases, the offender also live streams the incident on shared online community platforms.”
These types of incidents, called swatting, have increased across the US in recent years and have even resulted in people’s deaths through accidental shootings.

The first known cases of a swatting incident being live-streamed online date back to the mid-2010s. The difference between what the FBI is reporting now and those initial incidents is that devices weren’t being hacked.
Pranksters would identify social events that were being streamed online and would arrange the event to be swatted, such as weddings, church meetings, and more.

Many of these swatting calls are being placed through online services that provide anonymous calling capabilities — such as Discord bots and dark web services.

To counteract with this new rising hack&swat cases, bureau officials said they are now working with device vendors to advise customers on how they could select better passwords for their devices.
Furthermore, the FBI said it’s also working to alert law enforcement first responders about this new swatting variation, so they may respond accordingly.
As for device owners, the same advice remains valid: Use complex and unique passwords for each of your online accounts. Use two-factor authentication where available. More

Consumers in Brazil are mostly unaware of the country’s data protection rules and fail to question companies’ personal data management practices, a new study has found.
The survey carried out by Brazilian credit intelligence company Boa Vista with over 500 consumers between August and September 2020 suggests that over 70% of those polled do not know what the General Data Protection Regulations are.

more on GDPR

The vast majority of the consumers polled (90%) feel their personal information is not protected appropriately by the companies requesting them, while 77% have expressed concerns over potential misuse of their data. Of the Brazilian consumers surveyed, 40% said they have been victims of fraud.
On the other hand, 53% of the Brazilian consumers surveyed said they don’t always take measures to protect their privacy before informing their personal data to companies. While 88% of respondents said they don’t feel comfortable informing data such as their taxpayer registration number, 55% don’t challenge companies when asked for such personal information.
Brazil’s data protection regulations were sanctioned by president Jair Bolsonaro on September 18, after nearly a month of uncertainty over the actual go-live date of the rules. The board members of the body responsible for enforcing the regulations, the National Data Protection Authority, were appointed in late October.
A survey carried out by the Brazilian Association of Software Companies (ABES) in partnership with EY soon after the introduction of the rules found that most Brazilian companies still needed to adjust to the rules. A subsequent study by ABES and EY found the technology sector fared better, but 56% of companies in the sector still needed to comply with the new regulations. More

Muurman said
Image: Joakim Honkasalo
The Finnish Parliament said on Monday that hackers gained entry to its internal IT system and accessed email accounts for some members of Parliament (MPs).

Special feature

Cyberwar and the Future of Cybersecurity
Today’s security threats have expanded in scope and seriousness. There can now be millions — or even billions — of dollars at risk when information security isn’t handled properly.
Read More

Government officials said the attack took place in the fall of 2020 and was discovered this month by the Parliament’s IT staff. The matter is currently being investigated by the Finnish Central Criminal Police (KRP).
In an official statement, KRP Commissioner Tero Muurman said the attack did not cause any damage to the Parliament’s internal IT system but was not an accidental intrusion either.
Muurman said the Parliament security breach is currently being investigated as a “suspected espionage” incident.
“At this stage, one alternative is that unknown factors have been able to obtain information through the hacking, either for the benefit of a foreign state or to harm Finland,” Muurman said.
“The theft has affected more than one person, but unfortunately, we cannot tell the exact number without jeopardizing the ongoing preliminary investigation.

“This case is exceptional in Finland, serious due to the quality of the target and unfortunate for the victims,” the official added.
The KRP also said that “international cooperation has taken place in the investigation,” but did not provide additional details.
Norway disclosed a similar incident this fall
But while government officials didn’t mention it, the incident is eerily similar to a similar hack disclosed in a neighboring Scandinavian country.
Earlier this fall, Norway’s Parliament disclosed a similar breach of its internal email system, with hackers accessing some officials’ email accounts.
This month, after a months-long investigation, the Norwegian police secret service (PST) attributed the intrusion to APT28, a group of hackers linked to Russia’s military intelligence service, the GRU.
A recent Microsoft report highlighted a recent trend in APT28 tactics towards targeting email accounts with credential stuffing and brute-force attacks. More

Image: T.H. Chia
A group of mysterious hackers has carried out a clever supply chain attack against Vietnamese private companies and government agencies by inserting malware inside an official government software toolkit.

Special feature

Cyberwar and the Future of Cybersecurity
Today’s security threats have expanded in scope and seriousness. There can now be millions — or even billions — of dollars at risk when information security isn’t handled properly.
Read More

The attack, discovered by security firm ESET and detailed in a report named “Operation SignSight,” targeted the Vietnam Government Certification Authority (VGCA), the government organization that issues digital certificates that can be used to electronically sign official documents.
Any Vietnamese citizen, private company, and even other government agency that wants to submit files to the Vietnamese government must sign their documents with a VGCA-compatible digital certificate.
The VGCA doesn’t only issue these digital certificates but also provides ready-made and user-friendly “client apps” that citizens, private companies, and government workers can install on their computers and automate the process of signing a document.
But ESET says that sometime this year, hackers broke into the agency’s website, located at ca.gov.vn, and inserted malware inside two of the VGCA client apps offered for download on the site.
The two files were 32-bit (gca01-client-v2-x32-8.3.msi) and 64-bit (gca01-client-v2-x64-8.3.msi) client apps for Windows users.
ESET says that between July 23 and August 5, this year, the two files contained a backdoor trojan named PhantomNet, also known as Smanager.

The malware wasn’t very complex but was merely a wireframe for more potent plugins, researchers said.
Known plugins included the functionality to retrieve proxy settings in order to bypass corporate firewalls and the ability to download and run other (malicious) apps.
The security firm believes the backdoor was used for reconnaissance prior to a more complex attack against selected targets.
ESET researchers said they notified the VGCA earlier this month but that the agency had already known of the attack prior to its contact.
On the day ESET published its report, the VGCA also formally admitted to the security breach and published a tutorial on how users could remove the malware from their systems.
PantomNet victims also discovered in the Philippines
ESET said that it also found victims infected with the PhantomNet backdoor in the Philippines but was unable to say how these users got infected. Another delivery mechanism is suspected.
The Slovak security firm didn’t formally attribute the attack to any particular group, but previous reports linked the PhatomNet (Smanager) malware to Chinese state-sponsored cyber-espionage activities.
The VGCA incident marks the fifth major supply chain attack this year after the likes of:
SolarWinds – Russian hackers compromised the update mechanism of the SolarWinds Orion app and infected the internal networks of thousands of companies across the glove with the Sunburst malware.
Able Desktop – Chinese hackers have compromised the update mechanism of a chat app used by hundreds of Mongolian government agencies.
GoldenSpy – A Chinese bank had been forcing foreign companies activating in China to install a backdoored tax software toolkit.
Wizvera VeraPort – North Korean hackers compromised the Wizvera VeraPort system to deliver malware to South Korean users. More

Image: ZDNet
Russian cryptocurrency exchange Livecoin posted on message on its official website on Christmas Eve claiming it was hacked and lost control of some of its servers, warning customers to stop using its services.
According to posts on social media, the attack seems to have happened on the night between December 23 and December 24.
Hackers appear to have taken control of the Livecoin infrastructure and then proceeded to modify the exchange rates to gigantic and unrealistic values.
Before Livecoin admins managed to gain back access to some of their systems during late December 24, the Bitcoin exchange rate had ballooned from the regular $23,000/BTC to more than $450,000/BTC, Ether grew from $600/ETH to $15,000, and Ripple price increased from $0.27/XRP to more than $17/XRP.

Once the exchange rates were modified, the mysterious attackers began cashing out accounts, generating gigantic profits.
In the message posted on its website, Livecoin admins described the incident as a “carefully planned attack, which has been prepared, as we assume, over the last few months.”
“We lost control of all of our servers, backend and nodes. Thus, we were not able to stop our service in time. Our news channels were compromised as well,” the company said.

“At the moment, we partially control frontend, and so we’re able to place this announcement,” it added.
While the main web-based exchange portal si down, Livecoin is now urging users to stop depositing funds and making transactions through other interfaces like the site’s API and mobile apps.
As it happens with most cryptocurrency hacks, several users have cried foul play and are now claiming the entire hack was an inside job.
Livecoin said it notified local law enforcement.
According to CoinMarketCap, Livecoin is ranked as the 173rd cryptocurrency exchange on the internet, with roughly $16 million in daily transactions. The site has been active since March 2014. More

Images: Citrix // Composition: ZDNet
Threat actors have discovered a way to bounce and amplify junk web traffic against Citrix ADC networking equipment to launch DDoS attacks.

While details about the attackers are still unknown, victims of these Citrix-based DDoS attacks have mostly included online gaming services, such as Steam and Xbox, sources have told ZDNet earlier today.
The first of these attacks have been detected last week and documented by German IT systems administrator Marco Hofmann.
Hofmann tracked the issue to the DTLS interface on Citrix ADC devices.
DTLS, or Datagram Transport Layer Security, is a more version of the TLS protocol implemented on the stream-friendly UDP transfer protocol, rather than the more reliable TCP.
Just like all UDP-based protocols, DTLS is spoofable and can be used as a DDoS amplification vector.
What this means is that attackers can send small DTLS packets to the DTLS-capable device and have the result returned in a many times larger packet to a spoofed IP address (the DDoS attack victim).

How many times the original packet is enlarged determines the amplification factor of a specific protocol. For past DTLS-based DDoS attacks, the amplification factor was usually 4 or 5 times the original packet.
But, on Monday, Hofmann reported that the DTLS implementation on Citrix ADC devices appears to be yielding a whopping 35, making it one of the most potent DDoS amplification vectors.
Citrix confirms issue
Earlier today, after several reports, Citrix has also confirmed the issue and promised to release a fix after the winter holidays, in mid-January 2020.
The company said it’s seen the DDoS attack vector being abused against “a small number of customers around the world.”
The issue is considered dangerous for IT administrators, for costs and uptime-related issues rather than the security of their devices.
As attackers abuse a Citrix ADC device, they might end up exhausting its upstream bandwidth, creating additional costs and blocking legitimate activity from the ADC.
Until Citrix readies officials mitigations, two temporary fixes have emerged.
The first is to disable the Citrix ADC DTLS interface if not used. 

Citrix ADCIf you are impacted by this attack you can disable DTLS to stop it. Disabling the DTLS protocol will lead to limited performance degradation, a short freeze and to a fallback.Run following CLI command on Citrix ADC: set vpn vserver  -dtls OFF https://t.co/Tpdnp8k9y3
— Thorsten E. (@endi24) December 24, 2020

If the DTLS interface is needed, forcing the device to authenticate incoming DTLS connections is recommended, although it may degrade the device’s performance as a result.

If you are making use of Citrix ADC and have enabled DTLS/EDT (UDP via port 443) you might need to run this command: “set ssl dtlsProfile nsdtls_default_profile -helloVerifyRequest ENABLED”. This will prevent you from future UDP amplification attacks. #NetScaler #CitrixADC
— Anton van Pelt (@AntonvanPelt) December 21, 2020

Actually the vast majority of deploys will become unstable with that. To be safe until January, better block UDP.
— Thorsten Rood (@ThorstenRood) December 22, 2020 More

Over the past few weeks, I have tried out Ubuntu, Manjaro, openSUSE and the latest Raspberry Pi OS release on the Raspberry Pi 4. I am going to complete this series with a look at Kali Linux, one of my favorite specialist Linux distributions. Kali is specifically made for security analysis and penetration testing, and is preloaded and configured for that purpose. The combination of the inexpensive and portable Raspberry Pi hardware and the Kali Linux distribution has seemed extremely promising to me for several years now, but so far it hasn’t really fulfilled my expectations. Hopefully the more powerful Raspberry Pi 4 and the more mature Kali Linux 2020.4 will remedy that.

Kali Linux for the Raspberry Pi can be downloaded from the Offensive Security ARM Images web page (not the main Kali Downloads page, although there is a link to the correct page there). There are four download images there:
A 32-bit image which will run on all versions of the Pi 2, 3, 4 and 400
A 64-bit image which will run on the Pi 2v1.2, 3, 4 and 400
An image specifically for the Pi Zero and Zero W
An image labelled ‘Kali Linux RPi’
These are all xz compressed images each about 2GB, which can be expanded and copied to a microSD card with this command:
    xzcat kali-linux-2020.4-rpi4-nexmon.img.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress
As always, carefully replace /dev/sdX with the actual device name for your SD card device.
Image: J.A. Watson
These images uncompress to about 9GB, so you will need at least a 16GB microSD card, and if you are going to do any serious work with it you will almost certainly need an even larger card.  
Keep in mind that the image will be written to the card with an 8.5GB root filesystem, and that will be expanded to fill the free space on the SD card during the first boot. So if you want to have a separate home or work partition, you should set that up on the SD card (using gparted or some such partition manager) before booting the first time.

Unlike most other Raspberry Pi Linux distributions, there is no “initial setup/configuration” dialog during the first boot, it just comes right up to the login screen. The default credentials are kali/kali, so once you login with that the all-important first step is to change the password (duh).

Kali Linux 2020.4 on a Raspberry Pi 4.
Image: J.A. Watson
Because there is no first-boot configuration script, there are a few other things which need to be done manually. None of these are terribly difficult or complex, but they go beyond what is normally necessary for a “user-friendly” (hand-holding) distribution. If you are advanced enough to use Kali (or attempt to use Kali), you should be used to this, or get used to this. If you are just starting out with Kali, I would strongly suggest getting the book Kali Linux Revealed, which can be downloaded from the given link, or if you are a truly dedicated geek like me, purchased in paperback.

Image: J.A. Watson
First, I verified that the root filesystem had been extended to fill the free space (see screen shot at right), then I copied the contents of /home to the new filesystem, and added a line to /etc/fstab to mount it on boot.
If the desktop wallpaper is not filling the entire display (there is a black band around the edge), go to the file /boot/config.txt and uncomment the line that says
    disable_overscan=1
Then reboot, and the image should fill the screen.
If you are using anything other than a US Ascii keyboard, the layout has to be changed. There are two ways to do this: for the GUI-desktop only, go to the desktop menu Settings / Keyboard / Layout, un-check “Use system defaults” and then choose the correct layout in the box at the bottom of the window. To make the change system-wide, including the text-only virtual consoles, edit the file /etc/default/keyboard, and change the value for XKBLAYOUT to the correct value (for example, “de” for German, or “ch” for Swiss German). This change only takes effect after a reboot.
The other thing that I find worthwhile to manually configure is the local timezone. This defaults to UTC, which certainly isn’t correct for Switzerland. I don’t see a way to change this in any of the Settings menu items or the Settings Manager utility, so I just used the command line to change it:
    sudo datetimectl set-timezone Europe/Zurich
The value you give has to correspond to an entry in /usr/share/zoneinfo.
After getting this bit of configuration done, I took a closer look at the desktop and applications installed. This is an XFCE (4.14) desktop, with the menus extensively customized for the Kali distribution. The main menu contains the most useful security and penetration testing tools, and the “traditional” xfce menu has been moved to the “Usual Applications” sub-menu.
The default web browser is Firefox ESR, and my first impression is that it starts very quickly for a Raspberry Pi system – even for a Pi 4, in fact. Again, it has been customized for Kali, with a bookmark toolbar containing a useful group of items. I actually used Firefox on the Pi 4 to write portions of this post, and the performance was very good, with none of the lagging or difficulty that I have experienced on earlier Raspberry Pi / Browser combinations. The only problem I ran into here was that audio doesn’t seem to work, which I had already come across with openSUSE on the Pi 4, so I assume this is a more general problem that is likely to be fixed in a future release.
The default terminal emulator in the Favorites section is QTerminal, which is typical for an xfce distribution; but looking in the Usual Applications / System list, I see that the QTerminal drop-down is there, which I prefer so that there is always a terminal available on the F12 key, and UXTerm and XTerm are also included.
A quick check with uname -a shows that the Linux kernel is 4.19.118, and the 32-bit architecture is identified with armv7l.
SEE: An IT pro’s guide to robotic process automation (free PDF) (TechRepublic)
With the 32-bit version working very well, I decided to move on to the 64-bit version. Download, copy to microSD and initial boot were all identical to the 32-bit process. The difference in architecture can be confirmed with uname -a, which says aarch64 this time.
I went through the same checks and tests as I had done for the 32-bit version, with mostly the same results – but two significant surprises. First, keyboard layout configuration is inconsistent. Simply changing the system default in /etc/default/keyboard does not produce the correct layout in the desktop GUI; going to Settings / Keyboard and changing the layout there works, but only until the next reboot; but adding the desired layout twice in the Keyboard Settings causes the setting to be retained across reboots. I know that sounds weird, but I have tried this several times, in several different ways, and it is always like this – and only on the 64-bit version. Very weird.
The second difference, and the much more pleasant one, is that audio works in Firefox! Again, I have tried this several ways, and bounced back and forth between the 32-bit and 64-bit versions, and it is consistent – no audio in the 32-bit version, but it works in the 64-bit version.
With testing done on the Raspberry Pi 4, I moved on to the Pi 400. I took the microSD card with the 64-bit distribution and put it in the Pi 400, and it booted right up. That’s already good news, because at least one of the other Linux distributions I have tested didn’t boot in the 400.
Running through the same few tests as I had done on the Pi 4, everything seemed to be OK, including audio working in Firefox.  When I checked the configuration, I found two differences. The first was puzzling, but not particularly serious – the keyboard layout is correct, with none of the quirks that I struggled with on the Raspberry Pi 4. I have no explanation for this, but as long as it works, I don’t particularly care.

Image: J.A. Watson

×
screenshot-2020-12-23-14-00-17.png

Second, and much more serious, the wireless networking adapter is not detected on the Raspberry Pi 400. This worked perfectly on the Pi 4, but it simply doesn’t show up on the Pi 400. There is no wireless adapter or wireless networks shown in the drop-down from the Network Manager applet, there is no wireless adapter shown in the ip address output, there is no wireless device shown in the rfkill output, and there is no wireless adapter shown in the lshw output. (Interesting note: lshw is not installed by default, but it can easily be installed on the 64-bit version with sudo apt install lshw, but not on the 32-bit version – apparently it isn’t in the 32-bit repositories but it is in the 64-bit repositories.) I spent quite a lot of time trying to figure this out, with no success: apparently there is some sort of hardware difference between the Pi 4 and the Pi 400, but I can’t figure out what.
Shutting down and switching from the 64-bit card to the 32-bit card produced results that were consistent with what I have seen so far – it boots and runs, performance is good overall, but Wi-Fi doesn’t work, and there is no audio output.
The results from these tests on the Raspberry Pi 4 and 400 were good (well, except for the Pi 400 Wi-Fi), and the Kali download page says that these images should work on the Pi 3, so I decided to give that a try too. Both the 64-bit and 32-bit version boot and run on any Raspberry Pi 3, and the performance is, at least initially, not bad. It is noticeably slower than the Pi 4, of course, but that is to be expected. The problem comes when you start to run applications – even trying to do something fairly trivial such as display a web page, the system bogs down dramatically, and if you load it a bit more, it simply stops. I strongly suspect the problem is that these Raspberry Pi models have only 1GB of memory, and this problem is compounded by the fact that Kali doesn’t allocate any kind of swap space, so once the system starts to run out of memory, well, you’re basically screwed.
I also tried the Raspberry Pi 2, just for completeness. It booted and ran, but obviously had the same limitations and problems that the Raspberry Pi 3 had, because of the 1GB of memory. As expected, the Pi 2v1.2 ran with both the 64-bit and 32-bit versions, and the performance actually wasn’t noticeably worse than the Pi 3; the Pi 2v1.1 would only boot the 32-bit version, but even at that the performance again was comparable to the Pi 3.
The last member of the Raspberry Pi family to test is the Pi ZeroW. This requires a different Kali image than the others, but it is about the same size, 2GB download and 9GB installed, so again, it requires at least a 16GB microSD card. This might be a bit more of a problem with the Pi Zero, simply because it is old enough and small enough that a lot of them are currently running with 8GB cards.
I used a 32GB card, and the initial boot process took a very, very long time processing the expansion of the root filesystem. It did eventually come up to the login screen (after something like 5 minutes), it was obviously still terribly overloaded, because it took an extremely long time to even register the keyboard input of the login name and password, and after getting through that, it took several more minutes for the desktop display to come up and be ready for use.
SEE: Raspberry Pi 400: Its designer reveals more about the faster Pi 4 in the $70 PC’s keyboard
I didn’t want to be unfair to the Pi Zero, so I shut it down and powered off, and then booted it back up so I could time the boot without the process of expanding the root filesystem. On the Raspberry Pi 4, it takes approximately 30 seconds from power on to the login screen, but on the Pi ZeroW that took about 3.5 minutes. That’s not promising. It took another 5 minutes after entering the login info before the desktop finally came up and was useable. For me, this is very firmly in the “I can’t use anything this slow” category.
I was curious as to why and how the performance could be this bad, so I spent some time investigating. As best as I can tell, the primary problem is the simplest and most obvious one – the CPU is simply overloaded. Although it shows a very low CPU load when the system is idle (which it should, this means the system is not overloaded by the operating system itself), trying to run any application at all causes the CPU use to instantly peg at 100% and stay there. For example, the web browser included in this version of Kali is Midori (obviously because it is much lighter weight than Firefox), and trying to simply display the Kali Linux home page took more than three minutes, with the CPU statistics constantly showing 90%+ user time and 0% idle time.
The secondary performance problem is that the Pi ZeroW only had 512MB of memory, and this is simply not enough. Memory use statistics show that there is 10MB or less free memory even when the system is completely idle. Oh, and one other point about this, for the hard-core geeks who might be reading. The default configuration didn’t have any swap space at all, neither in a partition nor a swap file. I added a 2GB swap partition and activated it, and although that didn’t make a noticeable difference in performance, I did see that when I was running the browser it started to use 150MB or so of the swap area. When I then disable the swap, it took a minute or so to do that, and then the memory use statistics were right back to 280MB used and 145MB allocated for buffers and cache, with only 5MB free.
So, to get to the bottom line. Kali Linux on the Raspberry Pi 4 and Raspberry Pi 400, with 4GB (or more) of memory, is a pleasure. It’s easy to install, it runs very well, and response time is good. There are a couple of minor glitches with sound and wireless networking, but those are very likely to be worked out before long. This system is really what I have been wanting/expecting since the first time I heard about a Kali Linux port to the Raspberry Pi family several years ago. Unfortunately, though, on systems with only 1GB of memory the situation is completely different – and that includes the Pi 4, 3 and 2. It boots and runs, but it is far too easy to slow to a crawl, or actually stop, by running applications that need too much memory. Finally, the Pi Zero/ZeroW family, with only 512MB of memory is, for me, unusable.

Open Source More