Nytro

Trimite mail catre Lucian Constantin, Ionut Ilascu sau alti jurnalisti care se ocupa de asa ceva. Sau catre thehackernews. Ceva de genul ar putea sa faca valva prin media.

Foarte detaliat! Am scris si eu cate ceva despre subiect in lucrarea de licenta.

Da, e OK aici. De fapt nici nu conteaza. Continutul e de calitate, ne ocupam noi sa il aranjam daca e nevoie.

Frumos, poti posta pe forum si celelalte blog posturi!

Nu prea ajuta, poti incerca Ghidra gratuit sau IDA Pro, crackuit. Pentru ce ai nevoie de aceasta decompilare?

Hacker politist* In cel mai rau caz...

Da, e "secure", cine mai are floppy-uri pe acasa in ziua de azi?

Daca combinam Covid cu security... https://nypost.com/2020/08/11/john-mcafee-apparently-arrested-for-wearing-thong-instead-of-face-mask/

Un pacient bolnav de Covid-19 in spital. Bani decontati (de catre Soros si Bill Gates, desigur! Asa au zis la Antena3). Cam asa se proceda pentru a obtine sumele acelea oferite pentru "falsi infectati" (inainte sau dupa deces).

TLS 1.3 cu ESNI. Cred ca toate detaliile sunt aici: https://blog.cloudflare.com/esni/

Aici nu vorba de trafic slab ci de faptul ca ceea ce blocheaza acum nu poate fi monitorizat. In pachetele TLS in general se poate vedea serverul destinatie (e.g. rstforums.com). Ei bine, cu acest nou feature, nu se mai vede si ei nu au cum sa stie pe ce site-uri intra oamenii...

Clasic China. Monitorizare peste tot. Cel putin asa pare din-afara. Stie cineva vreun chinez sa ne zica parerea?

Salut, ar trebui sa incepi cu domeniul in care te descurci cel mai bine, de exemplu web security. Trebuie sa tii cont de un lucru: multe nu sunt chiar "real-life". Adica desi sunt "usoare" probabil va trebui in continuare sa iti dai seama la ce s-a gandit autorul cand a facut acel exercitiu. E normal ca la inceput sa nu rezolvi prea multe. Dar incercand sa rezolvi, vei invata foarte multe lucruri. De fapt rezolvarea in sine nu te ajuta cu nimic, ci drumul pe care il parcurgi ca sa ajungi la flag.

Adevarul despre masti! https://9gag.com/gag/a6KDq5b

Explozia din Beirut (Liban) NU EXISTA! Ati vazut-o voi? Stiti pe cineva care a murit acolo? Nu e mai grava ca explozia unei petarde! E o minciuna prin care televiziunile vor sa ne sperie si sa ne controleze! Sunt interese mari la mijloc!

Sunt o gramada de tool-uri care fac asta. Incearca 2-3 si gaseste un dictionar de parole bun. Sau genereaza tu o lista de parole.

Interesant, dar are sens. Multe mizerii ca sa blocheze accesul la anumite site-uri pun in hosts 127.0.0.1, nu e vorba doar de acel telemetry shit. Cat strict despre telemetry, exista metode mai practice, ca oprire a serviciilor sau mai stiu eu ce. Asta cu 127.0.0.1 e un cacat.

La pretul ala cu 9000 BTU? Nu.

Incearca "social engineering". Tu, ea sau cineva apropiat, incercati sa discutati cu individul respectiv si sa vedeti ce vrea si de ce face asta. Poate aflati cate ceva despre el sau poate se da de gol cine e.

Red Hat and CentOS systems aren’t booting due to BootHole patches Well, you can't be vulnerable to BootHole if you can't boot your system. Jim Salter - 7/31/2020, 10:43 PM Enlarge / Security updates intended to patch the BootHole UEFI vulnerability are rendering some Linux systems unable to boot at all. Aurich Lawson 53 with 31 posters participating, including story author Share on Facebook Share on Twitter Early this morning, an urgent bug showed up at Red Hat's bugzilla bug tracker—a user discovered that the RHSA_2020:3216 grub2 security update and RHSA-2020:3218 kernel security update rendered an RHEL 8.2 system unbootable. The bug was reported as reproducible on any clean minimal install of Red Hat Enterprise Linux 8.2. Further Reading New flaw neuters Secure Boot, but there’s no reason to panic. Here’s why The patches were intended to close a newly discovered vulnerability in the GRUB2 boot manager called BootHole. The vulnerability itself left a method for system attackers to potentially install "bootkit" malware on a Linux system despite that system being protected with UEFI Secure Boot. RHEL and CentOS Unfortunately, Red Hat's patch to GRUB2 and the kernel, once applied, are leaving patched systems unbootable. The issue is confirmed to affect RHEL 7.8 and RHEL 8.2, and it may affect RHEL 8.1 and 7.9 as well. RHEL-derivative distribution CentOS is also affected. Red Hat is currently advising users not to apply the GRUB2 security patches (RHSA-2020:3216 or RHSA-2020:3217) until these issues have been resolved. If you administer a RHEL or CentOS system and believe you may have installed these patches, do not reboot your system. Downgrade the affected packages using sudo yum downgrade shim\* grub2\* mokutil and configure yum not to upgrade those packages by temporarily adding exclude=grub2* shim* mokutil to /etc/yum.conf. If you've already applied the patches and attempted (and failed) to reboot, boot from an RHEL or CentOS DVD in Troubleshooting mode, set up the network, then perform the same steps outlined above in order to restore functionality to your system. Other distributions Although the bug was first reported in Red Hat Enterprise Linux, apparently related bug reports are rolling in from other distributions from different families as well. Ubuntu and Debian users are reporting systems which cannot boot after installing GRUB2 updates, and Canonical has issued an advisory including instructions for recovery on affected systems. Although the impact of the GRUB2 bug is similar, the scope may be different from distribution to distribution; so far it appears the Debian/Ubuntu GRUB2 bug is only affecting systems which boot in BIOS (not UEFI) mode. A fix has already been committed to Ubuntu's proposed repository, tested, and released to its updates repository. The updated and released packages, grub2 (2.02~beta2-36ubuntu3.27) xenial and grub2 (2.04-1ubuntu26.2) focal, should resolve the problem for Ubuntu users. For Debian users, the fix is available in newly committed package grub2 (2.02+dfsg1-20+deb10u2). We do not have any word at this time about flaws in or impact of GRUB2 BootHole patches on other distributions such as Arch, Gentoo, or Clear Linux. Sursa: https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-booting-due-to-boothole-patches/

17-Year-Old 'Mastermind', 2 Others Behind the Biggest Twitter Hack Arrested July 31, 2020Mohit Kumar A 17-year-old teen and two other 19 and 22-year-old individuals have reportedly been arrested for being the alleged mastermind behind the recent Twitter hack that simultaneously targeted several high-profile accounts within minutes as part of a massive bitcoin scam. According to the U.S. Department of Justice, Mason Sheppard, aka "Chaewon," 19, from the United Kingdom, Nima Fazeli, aka "Rolex," 22, from Florida and an unnamed juvenile was charged this week with conspiracy to commit wire fraud, conspiracy to commit money laundering, and the intentional access of a protected computer. Florida news channel WFLA has identified a 17-year-old teen named Graham Clark of Tampa Bay this week in connection with the Twitter hack, who probably is the juvenile that U.S. Department of Justice mentioned in its press release. Graham Clark has reportedly been charged with 30 felonies of communications and organized fraud for scamming hundreds of people using compromised accounts. On July 15, Twitter faced the biggest security lapse in its history after an attacker managed to hijack nearly 130 high-profile twitter accounts, including Barack Obama, Kanye West, Joe Biden, Bill Gates, Elon Musk, Jeff Bezos, Warren Buffett, Uber, and Apple. The broadly targeted hack posted similarly worded messages urging millions of followers of each profile to send money to a specific bitcoin wallet address in return for larger payback. "Everyone is asking me to give back, and now is the time," a tweet from Mr. Gates' account said. "You send $1,000; I send you back $2,000." The targeted profiles were also include some popular cryptocurrency-focused accounts, such as Bitcoin, Ripple, CoinDesk, Gemini, Coinbase, and Binance. The fraud scheme helped the attackers reap more than $100,000 in Bitcoin from several victims within just a few hours after the tweets were posted. As suspected on the day of the attack, Twitter later admitted that the attackers compromised its employees' accounts with access to the internal tools and gained unauthorized access to the targeted profiles. In its statement, Twitter also revealed that some of its employees were targeted using a spear-phishing attack through a phone, misleading "certain employees and exploit human vulnerabilities to gain access to our internal systems." Twitter said a total of 130 user accounts were targeted in the latest attack, out of which only 45 verified accounts were exploited to publish scam tweets. It also mentioned that the attackers accessed Direct Message inboxes of at least 36 accounts, whereas only eight accounts' information was downloaded using the "Your Twitter Data" archive tool. "There is a false belief within the criminal hacker community that attacks like the Twitter hack can be perpetrated anonymously and without consequence," said U.S. Attorney Anderson. "Today's charging announcement demonstrates that the elation of nefarious hacking into a secure environment for fun or profit will be short-lived. Criminal conduct over the Internet may feel stealthy to the people who perpetrate it, but there is nothing stealthy about it. In particular, I want to say to would-be offenders, break the law, and we will find you." "We've significantly limited access to our internal tools and systems. Until we can safely resume normal operations, our response times to some support needs and reports will be slower," Twitter added. This is a developing story and will be updated as additional details become available. Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Sursa: https://thehackernews.com/2020/07/twitter-hacker-arrested.html

@andr82 - Cea clasica: session cookies. Cam astea ar fi, nu am alte idei. Dar pana la urma depinde de cum vrea fiecare developer. In trecut erau aplicatii care setau drept cookie user si parola si aceea era autentificarea...

Da, oricum e destul de RAR SAML. Si pentru JWT sunt niste reguli: - De preferat criptarea asimetrica sau un secret "puternic" pe ciptarea simetrica - De generat JWT dupa ce userul s-a logat doar, nu de exemplu la signup - De verificat intotdeauna semnatura si nu permis mizeriile cu algorithm 'none' - De nu pus date sensitive prin JWT - De ne reutilizarea se secretului pentru a genera JWT-uri diferite, pentru aplicatii diferite, ca apoi cineva sa le poata interschimba - De implementat corect flow-urile - De evitat open redirect, mai ales in redirect_url - De implementat protectiile anti-CSRF Desi lista pare lunga, mi se pare mult mai simplu, practic si eficient decat SAML.

Ar fi si cazul, ar trebui sa treaba pe un Linux embedded ceva. Oricum, e hardcore ce au facut aici: "To analyze whether the module exists a chip debug port, we scan the SoC with X-Ray to figure out the pins, which avoided damage caused by disassembling the equipment."

Seeing (Sig)Red Reading time ~13 min Posted by Felipe Molina de la Torre on 20 July 2020 Categories: Blue team, Digital forensics, Suricata After the SigRed (CVE-2020-1350) write-up was published by Check Point, there was enough detailed information for the smart people, like Hector and others of the Twitterverse (careful with the fake PoC!), to swiftly write a proof of concept to crash Windows DNS. CP did not publish enough details about how to convert this into an RCE, so it looks like a PoC to execute code is still going to take some time to surface. In this post I will describe how I created a Suricata rule to detect exploitation attempts of CVE-2020-1350. As Windows exploitation and debugging is not my strong point, I decided to jump onto the defensive side of the vulnerability to help blue teams and sysadmins detect the attack before their Domain Controllers catch fire. I started by reading the Check Point post, and others, detailing the vulnerability to get as much detail as possible to create a Suricata IDS signature with which to detect exploitation attempts on your network. I chose Suricata because it is a highly popular network IDS solution, its open source and it is easy to install and configure. This post will not describe the details of the vulnerability itself, as the original Check Point post and all the subsequent articles published on the Internet should be sufficient for anyone to understand the inner workings of it. Thus, I will assume you have read the details and understand the exploitation vector. Suricata Rules Syntax Before delving into the details, we should first understand the syntax of a Suricata rule. This is an example extracted from their documentation: drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:”ET TROJAN Likely Bot Nick in IRC (USA +..)”; flow:established,to_server; flowbits:isset,is_proto_irc; content:”NICK “; pcre:”/NICK .*USA.*[0-9]{3,}/i”; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;) In this example, red is the action, green is the header and blue are the options. The action determines what happens when the signature matches and can be “pass”,”drop”,”reject” or “alert”. Check here for more information about the behaviour of each one. The header defines the protocol, IP addresses, ports and direction of the rule. The options section defines the specifics of the rule. To detect SigRed, we are going to work primarily with the last two sections of the rule, the header and the options, leaving the action fixed as an “alert“. Bear in mind that Suricata can be configured as an in-line IPS, so you can also specify the “drop” action to protect your corporate Windows DNS servers from SigRed attacks. Creating the Rules Reading the original blog post describing the vulnerability, one could infer the following properties that a malicious DNS connection will have: First suspicious packet: Description: As DNS answers over UDP have a 512 byte limit for the length of the payload, the malicious DNS server would need to initiate the conversation over TCP. This is indicated by the DNS flag TC. Therefore, the first suspicious packet will be a SIG answer, coming from the external network (i.e. Internet) directed to your corporate DNS servers with the “answer” and “TC” flags set. Protocol/Layer: DNS over UDP. Source: Coming from port 53 (DNS answer) for an IP on the external network Destination: To any port of any of our Windows DNS servers. Flow: Communications established and flowing from the malicious DNS (server) to the victim DNS (client). DNS Flags: ANSWER (bit 1) and TC (bit 6) flags enabled. Answer Type: A SIG (0x18) IN (0x01) answer. Viewing this in wireshark may look as follows: Second (more) suspicious packet: Description: A DNS SIG IN answer over TCP packet with an excessive packet length and a compressed signer name pointing to the following byte coming from the external network (i.e. Internet) directed to your corporate DNS servers. Protocol/Layer: DNS over TCP. Source: Coming from port 53 (DNS answer) of an IP on the external network. Destination: To any port of any of our Windows DNS servers. Flow: Communications established and flowing from the malicious DNS (server) to the victim DNS (client). DNS Flags: ANSWER (bit 1) enabled. Answer Type: A SIG (0x18) IN (0x01) answer. Packet Length: Greater than 65280 bytes (0xFF00). Compressed Signer Name: Pointer to the first character of the queried domain name which is usually the byte 0xC00D, or any other value greater than 0x0D pointing to other characters of the queried domain name. Hint: Take a look here to understand how message compression works on DNS to understand why it specifically has to be this value. Again, within wireshark that may look as follows: Example of the second malicious DNS packet observed in the network on an RedSig attack Knowing what the suspicious packets may look like. we can translate this into Suricata syntax. (This is a process that took me a while, as it was the first time I was dealing with these kind of rules and I had to make my way around the Suricata documentation). In summary for the first approach, the rules for the two packets could be translated into the following (note the corresponding colours of the rule to the description above): First Rule: alert dns $EXTERNAL_NET 53 -> $DNS_SERVERS any (msg:”Windows DNS Exploit (TC header)”;flow:established,to_client;classtype:denial-of-service;byte_test:2,&,0x82,2;content: “|00 00 18 00 01|”;within: 120;reference:cve,2020-1350;sid:666661;rev:1;) Second Rule: alert tcp $EXTERNAL_NET 53 -> $DNS_SERVERS any (msg:”Windows DNS Exploit (Compressed SIG record)”;flow:established,to_client;classtype:denial-of-service;byte_test:2,>,0xFF00,0;byte_test:2,&,0x80,4;content: “|00 00 18 00 01|”;within: 120;content:”|c0 0d|”;reference:cve,2020-1350;sid:666662;rev:2;) For these rules to work in your environment, you will need to open your “suricata.yaml” configuration file and add an array with your corporate DNS IP addresses in the variable $DNS_SERVERS: Defining our internal DNS IP addresses After adding your DNS IP addresses here, save these two rules in a text file called “sigred.rules”, save them in the default “rules” folder usually located at “/etc/suricata/rules” and enable them in the “suricata.yaml” configuration file under the “rule-files” section: Multiple SigRed rules added to our Suricata installation To test whether the rules are working or not, one can run the Suricata client against PoC traffic captures. I tested these rules against three different traffic captures. The first one was the PCAP found in the first PoC written by Maxploit, the second one was the PoC written by Hector (thank you for the pcap), and the third one was the traffic capture I grabbed myself from one of our Jumpboxes. To test your rules against a PCAP, execute the following command on your Suricata box: suricata -r /home/user/sigred-dos-poc.pcapng -l /var/log/suricata/ Detection of SigRed exploit with Suricata I noticed two limitations in this first approach when writing the Suricata rules. The first limitation was that the first rule alone will trigger a fair amount of false positives on the network, as transitioning to DNS over TCP with SIG requests is not uncommon. So, the rule should be useful when triggered with the second one. If you only have the first rule triggered in your Suricata setup it may be worth it to investigate this as a potential incident (especially in the first weeks since the publication of the vulnerability), but if you have both rules configured you can be almost sure someone is doing nasty things in your corporate network. The second limitation is that we are making our rule to search for a hard-coded compressed Signer’s name with the value “0xC00D“. This compressed signer’s name is pointing to the first character of the queried domain – this is, the “9” in the domain name “9.ibrokethe.net” – to trigger the heap overflow (see “DNS Pointer Compression – Less is More” on the CP blog post). This is the value hard-coded in the Check Point blog post and the Maxpl0it PoC, but in reality you can point to other characters in the string and the exploit will work and not be detected by our Suricata rule. To tackle the first limitation, we can make a link between our two rules for Suricata IDS. To do so, we can introduce a new rule option called xbits. With this option, we set a flag (tc_requested) when the first rule is triggered. This flag can then later be queried by the second rule with the “isset” operator. If the flag is set, then the second rule will trigger an alert. If the flag is not set, the second rule will not trigger an alert. Introducing the xbits option we make our rules tightly coupled with each other, and the degree of certainty that we are facing the SigRed exploit is significantly increased. To tackle the second limitation, we should make our Suricata rule aware of other valid compressed names that will trigger the vulnerability, such as “0xC00E”, “0xC00F”, “0xC010”, etc. Thus, we can add a byte_test comparison to look for greater values than “0x0c” in the second byte of the compressed name. After addressing these two limitations, we end up with the following rules (note the red colour part of the rule to address the false positive limitation by combining the rules and the blue colour part of the rule to address other valid values of compressed names): alert dns $EXTERNAL_NET 53 -> $DNS_SERVERS any (msg:”Windows DNS Exploit (TC header)”;flow:established,to_client;classtype:denial-of-service;byte_test:2,&,0x82,2;content: “|00 00 18 00 01|”;within: 120;xbits:set,tc_requested,track ip_pair;noalert;reference:cve,2020-1350;sid:666661;rev:2;) alert tcp $EXTERNAL_NET 53 -> $DNS_SERVERS any (msg:”Windows DNS SigRed Exploit (Compressed SIG record)”;flow:established,to_client;classtype:denial-of-service;byte_test:2,>,0xFF00,0;byte_test:2,&,0x80,4;content:”|00 00 18 00 01|”;within:120;content:”|c0|”;within:31;byte_test:1,>,0x0c,0,relative;xbits:isset,tc_requested,track ip_pair;reference:cve,2020-1350;sid:666662;rev:3;) With these two rules, you would learn about the victim DNS server being targeted in the attack and the external malicious DNS server sending the payload. Once you have this information you would be able to take further incident response measures, such as blocking the malicious domain on your perimeter. With these two rules you will not get information about how your internal DNS got targeted by this exploit. Assuming we have already detected with the two previous rules the malicious domain name, e.g. “ibrokethe.net”, we could identify the attacker or victim of the attack by tweaking two more Suricata rules as follows: The first one to see if an insider is manually trying to attack corporate DNS servers, that is, manually executing a query to the malicious DNS server using something like nslookup or dig. In this case, one would see a DNS query packet trying to resolve the SIG (0X18) IN (0x01) entry of a malicious domain (ibrokethe.net), directed to our corporate DNS server: DNS SIG IN query to resolve the malicious domain name The second to see if an employee has been a target of an attack like the one described in the original Check Point post by smuggling DNS data inside of the HTTP protocol (see “Triggering From the Browser” section of the CP post). In this case, one would see a malformed DNS packet as follows : After identifying all of the relevant properties that a malicious DNS packet could have, we can create the following two rules to detect the insider or victim of this attack to a specific domain that you have detected (note the corresponding explanatory colours in the rule): alert dns $HOME_NET any -> $DNS_SERVERS 53 (msg:”Windows SigRed DNS Exploit (Insider Identification)”;classtype:denial-of-service;flow:to_server;byte_test:1,!&,0xF8,2;content:”|09|ibrokethe|03|net”;content:”|00 00 18 00 01|”;within: 5;reference:cve,2020-1350;sid:666663;rev:1;) alert tcp $HOME_NET any -> $DNS_SERVERS 53 (msg:”Windows SigRed DNS Exploit (Victim Identification)”;classtype:denial-of-service;flow:to_server;byte_test:1,!&,0xF8,4;content:”|50 4f 53 54 20 2f|”;offset:0;depth:6;content:”|09|ibrokethe|03|net”;distance:20567;within:100;content:”|00 00 18 00 01|”;within:5;reference:cve,2020-1350,sid:666664;rev:1;) With these four rules we would be able to identify a SigRed attack on a network and obtain the following details: The source IP address where the attack originated from and potentially whether it was a victim of the attack (rule 666664) or was active part in the attack (rule 666663). The target DNS name for the attack (rules 666661 and 666662) The malicious domain (rules 666661 and 666662). The malicious external DNS server (rules 666661 and 666662). I hope these rules are useful for someone out there and helps protect your corporate networks. Good luck catching the bad guy! Bibliography & Resources https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ https://www.ietf.org/rfc/rfc1035.txt http://www.tcpipguide.com/free/t_DNSNameNotationandMessageCompressionTechnique-2.htm https://github.com/maxpl0it/CVE-2020-1350-DoS https://www.immagic.com/eLibrary/ARCHIVES/GENERAL/WIKIPEDI/W120423L.pdf https://suricata.readthedocs.io/en/suricata-5.0.3/ https://www.securityartwork.es/2013/02/21/snort-byte_test-for-dummies-2/ Twitter Sursa: https://sensepost.com/blog/2020/seeing-sigred/