New answers tagged

0

Well, actually, Ransom32 is not an .exe file, it's a .scr (which is basically the same thing) and he doesn't use WinRAR code but NSIS code in the latest version that I've found on the web. We can easily unpack the scr file to see interesting things : First, the NSIS script file will launch a .NET 4.0 installer if not found on the system Then it'll ...


2

What are some reasonable/interesting ideas of ways to address this issue practically? GPG encryption, with steganography to hide the fact that you're using encryption in plain sight. The basic idea you need to avoid mandatory compromise to encryption, is find any data channel that is not blocked and use non-compromised encryption over that data channel. ...


5

The first line 'iayQS28R... is a key to be XORed with the bytes given in the code variable. When interpreted by Javascript, it does nothing because it's just a string constant. But the script opens its own source file (something you can't do in pure Javascript, but you can with the extra packages that are available when Windows runs a Javascript script as a ...


0

You can try to create a SSH tunnel to tunnel HTTPS through it. I guess this post explains how to perform this in an effective way, otherwise you can find a lot of guides on the web explaining how to create a SSH tunnel.


0

Actually, even if that header could solve the problem, the second part is a human factor: the hosters/developers/webmasters are about to use it, actually...


16

Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header? No. X-XSS-Protection is only used to enable or disable the inbuilt filtering[*] - which is generally enabled by default anyways. So a more fitting question would be if XSS reached its end-of-life with browser filters. But again, the answer is no. XSS is still a ...


1

There are multiple reasons for this (sending data all over the place). If you are phishing with the intent of exploiting something, you may have something like mod_redirect running in the background to target specifics. E.g.: if UserAgent = IE && Windows 7 then send them to this particular page with Win7 IE specific exploits or if UserAgent = ...


2

Nope, no software exploits, just classic exploitation of dumb users. The payload is distributed in a self-extracting RAR file. A self-extracting RAR file is really just an executable extractor with the .rar file appended to the file. Such a file is an executable file with the .exe extension, and has a feature to run arbitrary code after extraction. The ...


2

This is not Javascript breaking out of a browser's vm/sandbox but rather an executable that runs with full local user privileges that happened to be written in Javascript... There's nothing to harden as local Javascript app platforms like NW.js are designed to allow exactly that and like all other platform/frameworks they can be used for good as well as for ...


3

The most important thing to consider here is that this type of JavaScript malware does not run in a browser. It runs in a special runtime called NW.js which gives powerful NodeJS API's not found in a browser. While NW.js shares many technologies with the Chromium browser, it is not a browser but a type of native wrapper for making desktop apps, and this ...


0

Another problem not mentioned yet: you mentioned the JavaScript is served over plain HTTP. This means that a "man in the middle" (MITM) attack can modify the JavaScript enroute, removing the encryption, or even doing more nefarious things. You CAN do encryption client-side (there are some cases this makes sense) but it CANNOT replace HTTPS, only supplement ...


4

Parsing BBCode in a safe way that does not open the doors to XSS hell is a tricky task, and there have been many failed attempts. As you yourself note, the way you currently do it is vulnerable to XSS - all you need to do is post [script src="evil.js"]. Just using htmlentities() will not solve this for you, it is much more complex. This blog illustrates the ...


4

This does not look exploitable to me. The only user input here is the location variable. However, it is only used to check if the protocol is HTTPS or not and then change the URL of the included script accordingly. There is no way to sneak any parts of the URL, like a query parameter, into g.src. Also note how it is constructed through concatenating hard ...


3

You can use a CSPRNG for the IV. This can be stored next to the encrypted text. The IV does not need to be kept secure, it just must be random.


12

Thanks Alexandar O'Mara for pointing me in the right direction - it was a small tip, but it got me there. I ran nslookup with the domains and got: C:\Users\xxx>nslookup scorecardresearch.com Server: router.asus.com Address: 192.168.56.1 Name: scorecardresearch.com Address: 103.16.230.165 C:\Users\xxx>nslookup sb.scorecardresearch.com Server: ...


5

Are there any frameworks that work this way? Sure. Twig or Django would be two examples. The inverse of this is clearly a far more secure default, ie. all dynamic data is escaped, unless you specifically tell the framework not to. Yes, this is a lot more secure. Is there something I'm missing? The one downside is that XSS is context-sensitive....


6

If you look at the page source, there is a JavaScript function rwt() executed on onmousedown event. <a href="http://security.stackexchange.com/" onmousedown="return rwt(this,'','','','1','AFQjCNHano0MrEGop-Wp0eV_bNhmdh7OtQ','H4np7JuYNqsCuTIjB-78Eg','0ahUKEwjzldecwZfNAhWEVxoKHX8OAnwQFggdMAA','','',event)"> Information Security Stack Exchange</a>...


1

There are two parts on http://stegosploit.info/ The first one is about hosting the javascript exploit in an image file loaded through canvas. As such, it's not really interesting since in order to be exploited, the attacker would already need to be able to insert javascript into the webpage. The second part involves also including the html into the image ...


1

To answer the question: The website admin must be in on the exploit. The encoding technique is there to obfuscate the actual exploit scripts, thus flying under the radar from current detection methods. It still requires HTML/Javascript to be on the webpage in order to decode and run the exploit. That is to say, if I had encoded an exploit into ...


2

Even if this would work and you could block JavaScript from performing XMLHttpRequests - which as shown by @Alexander is not the case (ActiveXObject would be another alternative) - it doesn't really limit the dangers of XSS. An attacker still has a number of possibilities: Defacement Phishing: For example, add a login form, which sends the entered data ...


8

Are there any caveats to this approach? (security-wise) Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead: XMLHttpRequest = null; var iframe = document.createElement('iframe'); iframe.style.display = 'none'; // optional document.body.appendChild(iframe); var XHR = iframe.contentWindow....


133

A good option is to harden your Content Security Policy. It allows you to fine-tune which resources the browser will load/run, and is supported by most browsers. Consider the following header: Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self'; This tells the browser to disable scripts, frames, connections and any other objects/...


1

Yes, it is a problem, maybe even a big problem, but "XSS" probably isn't the right term. What could possibly go wrong? remote code execution using svg, especially older browsers off-site images leak your user's IP address (aka lat/lon), userAgent, and net performance malicious images themselves been vectors, lots of 0days in the past A special or even ...


1

No, in modern browsers no XSS is possible via the style or src attribute of an <img> tag. So neither of these would execute the JS code in any up-to-date browser: <img src="javascript:alert(1)"> <img src="x.jpg" style=background-image:url('javascript:alert(2)')"> Support for Javascript in CSS attributes has long been abandoned. You can ...


1

This appears to be the same as CSRF, except that the payload is executed by JavaScript. Because X-Frame-Options is set to prevent framing, the JavaScript can only be executed if the GET request is opened in a new window (or tab). <img> tags won't work because any HTML or script returned in the response won't be interpreted by the browser. If your ...


0

Sometimes for non persistent tracking purposes, websites encode a string that is propagated across each page of the site you surf through. If you have a browser history entry of such a page, clicking through it refreshes the history on the server side. This assumes you do not use no history settings on your client.


1

There is no way to get the password directly You can not get the user password directly from the forum. Simply because you cannot access the browser using javascript. So you will not be able to get the saved passwords in the browser. This would be a huge security failure There are 2 ways to access an account from a XSS vulnerabilty As we saw, it isn't ...



Top 50 recent answers are included