21

If the cookie gets stolen inside a public Wifi Hotspot all users of the Hotspot have usually the same public IP address. This means binding to an IP would not help against an attacker in the same local network. Apart from that if the public IP of users changes like it is the case with moving between networks (Mobile, WLAN university, WLAN at cafe, WLAN at ...


12

Session Hijacking through sessionId brute-forcing possible? Probably not. owasp says that a session identifier should be at least 128 bit long to prevent session bruteforcing. They give these example calculations: With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per ...


9

Yes, but the exact implications depend on the authentication techniques used by the website which set the cookies. For example, some websites may have particularly short expiry times for their cookies, or the website may do extra checks (for example IP address or browser user agent) before allowing authentication to continue. In general, session hijacking ...


8

There are 2 main reasons why cookies are easier to steal than login credentials: Cookies are sent for every request, login credentials are only sent once for each "session" If you sniff a network, it is less likely that you will be in place at the point when a user actually perform a login using its username and password. Cookies on the other hand, are ...


8

Most likely not. IPv6 support is still quite patchy in many parts of the world. The delay is most likely caused by bad routing or network packets having to go through too many hops. You can test out your IPv6 connection here. The hosts file is used to bypass DNS and make your access to websites matching domains listed slightly faster, not slower. A whois ...


7

Yes, in the past there have been lots of exploits that only relied on malicious HTML and CSS code. You are right in that parsing a complex, turing-complete language is potentially more error-prone, giving an attacker more tools to craft an exploit. Yet, there are many different ways in which the implementation of the used CSS parser or other modules ...


7

BeEF is best run from the MITMf tool -- both are available in most versions (especially recent) of Kali Linux. MITMf has an extension to BeEF not found in other places called BeEFAutorun. Both BeEFAutorun and BeEF Autorun Rule Engine (ARE) work similarly to XSSF and Trustwave SpiderLabs' beef_injection_framework, but the built-in ARE is superior and works ...


5

I did visit the page (from a safe place!) and it's triggering the beforeunload event to change the URL, like this: var exit=true; var temp_url = document.location.href; var url_pieces = new Array(); url_pieces = temp_url.split("/"); var goto_url = 'http://www.imagesnake.com/ad.html' ; window.onbeforeunload = function () { if(exit==true){ location....


5

You seem to be asking: Is it possible to reverse engineer Javascript malware Yes. And you don't need acces to the server to do that. However it is possible for the malware author to make it more difficult to do so. I won't enumerate the potential methods here - they are (mostly) well described elsewhere. Most attackers don't bother with such sophistication ...


5

If the browser honours the hosts file, i.e. it either uses the system DNS resolver API or reads the hosts file when doing its own DNS lookup, and the browser itself (or a plugin) is not complicit in the malicious act, then no. This is the case for most browsers; very few would not honour the hosts file. There is no provision within JavaScript to perform DNS ...


4

The error message indicates that the server expected a HTTP request but got a HTTPS request: \x16\x03\x01\ is the start of an TLS record. This probably means that your server configuration is wrong, i.e. that the server expects HTTP on port 443 and not HTTPS.


4

In Firefox or Chrome, is it possible for a web page script to compromise a user installed extension? Absolutely, extensions are getting their fair share of vulnerabilities. What bugs you need to look out for depends on how the extension interacts with web content. E.g., the LastPass addon for Firefox was shown to be vulnerable multiple times. Due to one of ...


4

DNS, in this context, is nothing else than a mapping of names to IP addresses. If you have a host entry saying ::1 example.com then it will contact ::1 whenever an application tries to resolve and contact example.com (unless the application does DNS lookups manually, purposely bypassing the hosts file, but that's not something JavaScript can do from within ...


3

There are Yara rules submitted by SANS ISC to detect BeEF, and these could be repurposed by yarashop for the network layer as a early-warning detection system. The author shows how to utilize Volatility to read into a memory capture and look for BeEF-related signatures and communications -- https://isc.sans.edu/diary/When+Hunting+BeEF%2C+Yara+rules+%28Part+2%...


3

These days Google uses HTTPS even for their search, which makes it relatively easy for you to verify that your connection is secure. This does not absolutely grantee that your connection isn't being rerouted by an attacker, but it does guarantee they're not able to view or manipulate your traffic and therefore the attacker would have little motivation to do ...


3

If the username and password were sent in plaintext, then yes, sniffing them is a better option. However, a common pattern is for the login process to be encrypted (for security), and then the remainder of the session takes place in the clear (because encryption imposes a bit of a performance penalty). In such a case, the username and password cannot be ...


3

To the best of my knowledge the problem you'll encounter in the described scenario is that certificates don't usually work by IP address This may vary from site to site, so test against your desired site by browsing to it via IP and seeing if you get a valid HTTPS connection. The rest of the question is more straightforward - yes browsers will give you a ...


3

It sounds like standard phishing page with the aim of stealing passwords and nothing more than that. XSS and CSRF attack will only work if these vulnerabilities exist in itune websites and not on any phishing page. When browser load website it uses cookie which is stored in browser with the name of its website and due to same origin policy it will not send ...


3

You cannot prevent XSS by using cookies, but you can prevent successful XSS attacks from stealing your cookies by setting the HTTP-only flag. HTTP-only cookies are not visible in the context of the javascript engine. This is the only connection I can see between XSS and cookies. What you should look into instead, is the CSP (Content Security Policy) HTTP-...


3

I see that the site is now suspended by hostmonster. Assuming he did not provide credentials knowingly or unknowingly, here are a few possiblities, if the phishing email was linked to the account compromised at all. 1. Clipboard content stolen The malicious page could have stolen clipboard data. 2. Malicious scripts The malicious link redirects user to ...


2

If a process (or a user, for that matter) acquires administrative privilege on a machine, it is able to do anything. Included replacing a browser extension with a malware browser extension without the user knowing it. Any security mechanism implemented inside the machine can be nullified by the malware. For instance, your homemade extension could verify its ...


2

The answer by tim about entropy is perfect on the topic of brute forcing the sessionId. But note, there are easier ways to steal the session. For example, if you issue the session over HTTPS (authentication) but then bounce back to HTTP, now your session is exposed in clear text. Anything that goes over HTTP can be assumed is screamed out loud and open for ...


2

Yahoo redirect virus can also be added to "browser hijacker" and a "potentially unwanted program" categories. Programs that belong to this group are spread using three different techniques: Traditional installation method. You can install Yahoo redirect malware or similar browser hijacker with a help of typical installation technique, which requires going ...


2

Steffen Ullrich is right about the dubious security gain. The reason we don't implement it in practice is due to the former prevalence of multi-homed NAT boxes where X computers would be reduced to N IP addresses (where X >> N). The side effect in the way this worked was the next request would come from a different IP in the same subnet, and you don't know ...


2

It seems that its like a black point in my mind that I think about browser when I research information security. Its clear that its the browser applies security rules while we navigate websites. In any event that if browser failed to apply cookie rules or origin policy; how we can detect that? You cant really tell if the browser fails at applying a ...


2

Definitively detecting these attacks will require a hardware radio receiver, like an rtl-sdr device. You can make some guesses based on how you think a remote mouse would have to act, but they're only guesses. (And you'd have false positives.) And you'd have to write all this code, because it doesn't exist. You can spend a lot of effort worrying and trying ...


2

If I understand this issue correctly, mouse movements are sent unencrypted by design, and keystrokes are sent encrypted by design, however the receiver also accepts unencrypted (and unauthenticated) keystrokes as well, allowing an attacker to inject them? Regarding detecting unencrypted mouse movements, I would say there is no easy way to detect such an ...


2

When in Firefox I type web.whatsapp.com for whatsapp web, I get a browser re-direct. That is concerning and could be an indicator for malware (adware) or a man-in-the-middle attack. Anybody knows some good approach about cleaning this sort of stuff from the sytem? Since you have only been giving generic information about what's going on I can only ...


2

I'd first like to make sure you fully understand what Beef is and what it's used for. Beef is a tool for performing exploitation in Man-In-The-Browser scenarios. The gist of it is a user's browser executes the beef hook script (either via xss, or in your scenario, a phishing site), the script then calls out to the Beef server, and the server is then able ...


Only top voted, non community-wiki answers of a minimum length are eligible