How does IP address spoofing of a bad address work?

Spoofing an IP address is possible, though not very easy to do for the average person. The reason being that most ISP's will drop spoofed packets as they leave your network. This is even more applicable to bogons as they are generally filtered at the ISP level, and border firewalls.

If a spoofed packet does make it to your server, you should understand that there is no valid return path for that packet. An attacker spoofing an IP address would not be able to see any data from the server itself, but it could still be used in something like an amplification attack or to trigger an event within the servers services.

When talking about reserved private addresses, the likelihood of them hitting your network is very slim. Just because something is unlikely doesn't mean it is impossible.

The idea is that you should not be accepting these packets through your public interface, because what lies on the other side is not trusted. Just because your ISP should and most likely does filter these doesn't mean that you should not be doing the same.


ARP - forwarding or dropping with IPtables

You haven't specified your network setup (how things are wired together), which makes it difficult to figure out what's going on.

Writing "1" to /proc/sys/net/ipv4/ip_forward tells the kernel that your computer is acting as a router: that is, you've got two network interfaces on different subnets, and the kernel should act to pass packets between them.  If you genuinely have such a setup, then your iptables rule should work as you expect.

Most likely, your computer is acting as an ordinary host (single network interface on a single subnet), and the packets you are trying to filter never even come near it.  In this case, you'll need to re-wire your network so that packets from "host A" pass through it on their way to the router; you'll also need to configure your computer to act as a switch, bridge, or router (your choice, depending on how you want it to handle passing packets between the network interfaces).


With this scheme you are certainly making an attacker’s life harder. Here is the general attack algorithm for cracking bcrypt-protected plaintext passwords:

Obtain hashes (obviously)
Generate candidate passwords for password cracking tool
Perform the cracking attempt

And here is the attack algorithm for cracking your sha1-hashed-than-bcrypted passwords:

Obtain hashes
Generate candidate passwords for password cracking tool
Calculate corresponding SHA-1
Perform the cracking attempt

So, as you can see, the attacker must perform one cheap additional step to crack the password. So, your scheme should provide at least the same security level as using bcrypt to protect plaintext passwords.

As a small bonus, you are getting scheme which is not implemented out-of-box in common cracking tools. It will make password cracking even harder if the attacker is not very sophisticated and will not be able to figure out hashing scheme. But this feature is security by obscurity, so it is better to expect that attacker will know all about your password hashing approach.


Can malware spread via bluetooth file transfer in Android?

can malware spread when sending a clean file to someone or receiving
it via bluetooth ?

As you mentioned, malware uses pair-wise  communication mechanisms such as Bluetooth to spread. But whether the file you want to send is clean or not does not prevent you (or the destination deice) from being infected because one of the common ways that malware uses to propagate is to   exploit  vulnerabilities  in  the Bluetooth communication stack as you can read further in A Preliminary Investigation of Worm Infections in a Bluetooth Environment

If so, does it need some action from the user to start the malicious
code ?

There is malware that depend upon user interaction for  a successful  infection. We can mention, for instance, the famous Cabir worm that propagates over Bluetooth using  caribe.sis that displays a warning message:

This worm requires the user to click on Yes to get installed successfully. But as I said before, not all worms work need user interaction like this.


Full Disk Encryption within a VM, how secure is it?

To protect your VM, you really have three options.  Each of them is probably equal to the other in terms of security, provided that you use them properly.

Whole-disk encryption within the VM.

Never save the VM machine state - always shut it down completely.
Do not use the host system's sleep, suspend, or hibernate functions while the VM is running.

Wrap the VM files in a TrueCrypt container.

Make sure to only open the container when you need it, and close it when you're done.
Do not use the host system's sleep, suspend, or hibernate functions while the container is open.

Whole-disk encryption of the host system.

Do not use the host system's sleep or suspend functions - always hibernate or shut down.

Each of these can be used independently or in conjunction with any or all of the others.  However, keep in mind that multiple layers of encryption may begin to significantly impact performance.

Personally, I would start with option 3.  If you don't want to go that route, or you want to add another layer of security (e.g.: have a different encryption key for your VM than you do the host, on a multi-user host system), I'd pick option 2 next.


Does the recommended course of action for preventing Logjam on Tomcat servers really eliminate all risks of weak DH keys?

So I think I've interpreted your question correctly. If not, fire away in the comments.

Confusingly there are several factors in diffie hellman: are you doing it over elliptic curves or not, what size group have you got (let's assume "strong" and "not strong") and whether you generate ephemeral private/public keypairs or not.

The problem with logjam is this: if you have a plain old group variant of DHE, then if you can persuade the server to downgrade to the export (weak variety) level strength, then with some precomputations made before you can break the secret generated for a session in minutes.

This is conditional on being able to downgrade size variable to a smaller one - if you can do this over the plain old DHE variant, then you're in business.

This requires the cipher suite have DHE_..._EXPORT_... in it, such as TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA. Now that has a bunch of other problems like 40-bit DES and whatnot, but essentially, there could feasibly be some servers out there that support EXPORT variants of DHE with better symmetric ciphers. Or they could actually be negotiating 40-bit DES if persuaded.

The point is to perform a downgrade attack. The cipher suite list you've given doesn't allow for export ciphers.

You could turn off all non-EC variants of DH. However, this might limit client side support. Whether or not you can be so limiting is really up to you. But "DHE" in and of itself is fine, unless there's export in there somewhere. Make sure export ciphers are disabled, and follow Thomas' advice in the answer you linked.

Now on to SSLDHParametersFile - in DHE, the prime and generator of the group can actually be fixed ahead of time - the bit that is ephemeral is the private key chosen in that group. This way, by setting the parameters you can control what size group your server uses.

For example, the output of this might be:

openssl dhparam 2048 -text
<snip>
    PKCS#3 DH Parameters: (2048 bit)
    prime:
        00:bd:90:31:72:a5:bf:eb:96:b0:0e:1c:1e:3f:ff:
        cd:0a:e2:fc:14:72:50:19:f8:6d:e9:25:3c:3d:21:
        3b:3c:e3:93:9b:2e:a1:b5:98:dc:25:88:9c:9e:55:
        1a:78:36:a8:10:67:f2:f1:37:e7:6b:c7:b8:39:85:
        a7:ec:aa:e9:2f:4e:10:17:fd:72:e1:22:2e:ab:97:
        4b:bf:7b:a2:68:6d:94:a8:ae:df:e0:fb:66:ad:79:
        02:9c:09:ba:47:60:40:12:a8:27:46:ba:8f:a9:8b:
        bd:f5:d2:4e:67:0c:7a:49:f3:9d:80:98:50:4d:8c:
        72:38:47:91:4b:54:1f:3b:74:b5:81:30:c7:89:71:
        b0:87:8a:82:66:b0:06:f6:2e:a6:2b:e8:18:51:23:
        2d:09:d9:0a:87:03:7b:85:8a:27:c6:bd:fa:e9:16:
        70:b3:bf:ad:77:d5:55:72:22:e7:7c:6b:4e:31:2c:
        86:91:7a:51:11:ac:23:9d:5f:3d:f1:f2:83:02:98:
        72:a2:a4:c5:a8:26:40:25:02:59:00:80:22:37:ac:
        38:95:07:76:f5:31:3d:19:f6:81:36:6c:14:fa:d8:
        46:10:e1:b4:fa:5f:e2:9d:2f:a1:78:47:5d:9c:f9:
        ac:0c:06:83:dc:f4:2d:81:17:d4:34:1b:6f:c2:c7:
        2c:0b
    generator: 2 (0x2)

Tellingly, from your example bug, it sounds like it is not possible to use these parameter files quite yet with Tomcat. I'm not an expert on Tomcat, so, I can't really say but if you have instructed the cipher suites to not allow export, OpenSSL should default to a 1024-bit DH group, which is good enough for now.

You can, then, when the patch is available, upgrade your DH parameters as you see fit.


How can I determine whether or not a POS terminal violates requirements in the PCI DSS?

I would say no, these devices are not compliant.

I did a search for "T4220", which found two listings on the PCI PTS site. Both are for hardware versions newer than what you have told us, and one of them is marked as EOL.

IANAQSA, but given that you cannot find the device you're interested in in the PTS, I would stop wondering about what other rules they may or may not be breaking and just replace them with something current.


Depending on your application, you might not need "all" the CA certificates, but only the ones that you are able to trust.

You can use the Mozilla CA Certificate Store at:

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/

Those are the CAs that are trusted in e.g. Firefox.


Is this an exploit attempt and howcan I analyse it?

NOPs are just padding. Your best bet is to perform a file analysis, or behavioral analysis (what does it call, what files does it load, etc) of the binary if you are that concerned. You could search the md5/sha1 checksums on sites like Virustotal, ThreatConnect, ThreatCrowd, etc. Since you mentioned you are compiling into Windows, my guess is, the NOPs are just used as padding in order to function under Windows. Again, to be on the safe side, upload it to Anubis, Virustotal before you waste time, if something extreme has been seen (open source translates to potentially thousands of downloads) someone has uploaded the file for strangeness


A PC constantly scans my network for IP addresses using ARP

A lot of home networking "helper" apps, for network printers, network webcams, etc. will continuously scan the local network looking for devices. Some network appliances will too, like NAS devices, for similar reasons (looking for local printers).  Is the device doing the scanning a Windows PC with a bunch of typical desktop apps installed?  That would be the first place to look (after you simply identify which host it is doing the scanning).  It is interesting that it's focusing on 0-30 instead of the entire local subnet, though.  That sounds more like software looking for a device on a default IP to help with first-time configuration.

To get to the bottom of it, look at what happens when it does find a device (assuming you are using wireshark from inside that zone it's searching) to see, is it trying to open a specific port? A range of ports?  Does it do nothing?


Available alternatives for exchanging public keys for emailing

As this is asked on Information Security, it's crucial to first concentrate on how the keys should be trusted. Unlike SSL PKI with certificate authorities (CA), PGP is based on a web of trust. Anyone could send you an email with a self signed PGP public key, claiming it's really the key of the sender. It's as easy to spoof as the email itself. The responsibility of accepting and trusting it is on recipients side. Building such feature to email clients would create false sense of security.

Retrieving keys directly from key servers sounds like a bit better idea, but it doesn't actually give any guarantee, either. Anyone can send keys and signatures to the key servers and it's better to manually check who else trusts the unknown key, unless you can't check from independent source that the fingerprint matches. The keys would be retrieved using a keyring management software instead of the email client; e.g. the Kleopatra certificate manager and GUI for GnuPG a built-in functionality for this.

Best method for validating a key would be to ask personally, but I'd publish the key on a CA signed TLS protected web site, possibly with a DNSSEC signed IP address. This way your key would be behind two independent public key infrastructures (SSL + DNSSEC), making the source quite trustworthy regardless who have signed your key and could the recipient trust your web of trust.

For example, many national computer emergency response teams (CERT) publish their PGP keys on their HTTPS websites, and some are properly signed with DNSSEC, too:

US-CERT, SSL from GeoTrust, some problems with DNSSEC on Akamai
JPCERT, SSL from Cybertrust Japan AV CA G2, perfect DNSSEC chain
NCSC of New Zealand, SSL from COMODO, some problems with DNSSEC
CERT-FI, SSL from Thawte TLS SRA CA G1, perfect DNSSEC chain
check yourself how has the CERT team of your country arranged this. :)

There is an experimental RFC 7929 for DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP from 2016, introducing a new DNS Resource Record (RR) type, OPENPGPKEY. This would be easy to automate on an email client. However, the RFC 7929 itself notice the problems with the security of this approach (section 7.6):

  Anyone who can obtain a DNSSEC private key of a domain name via coercion, theft, or brute-force calculations, can replace any OPENPGPKEY record in that zone and all of the delegated child zones. Any future messages encrypted with the malicious OpenPGP key could then be read.

  Therefore, an OpenPGP key obtained via a DNSSEC-validated
  OPENPGPKEY record can only be trusted as much as the DNS domain can
  be trusted, and is no substitute for in-person OpenPGP key
  verification or additional OpenPGP verification via "web of trust"
  signatures present on the OpenPGP in question.


No, this is correct, you are putting PPP packets into your SSH connection. The idea of a VPN is that you are tunnelling, which basically means that you have an SSH connection (a tunnel) that looks like PPP when you are sending something into it. Thus, if you send a request through your tunnel with a protocol like HTTPS, your packet on the wire will look something like this:

Ethernet( IP( TCP( SSH( PPP( IP( TCP( TLS( HTTP( your packet payload)))))))))

Tunnelling itself is not a security thing; another common use of tunnelling is 4to6 routers, which allow you to tunnel IPv6 traffic over an IPv4 network. Similarly, you can use a SOCKS proxy to forward web requests over SSH to make it look like your requests are coming from somewhere else.


Should I put a potentially insecure program online?

"runas" will protect you from only a portion of the threats.

There are a few ways you could handle this. You need to lock down the firewall to prevent outgoing connections that you do not intend. Logging and auditing need to be turned on (and reviewed!!) to catch tampering.

If the server is a VM, you could have it revert to a saved snapshot every hour, meaning that any malicious code could not persist.

Can you maintain a copy of the uploaded code and the IP address that uploaded it for forensic review?

In any case, you need to think of the server as already compromised and treat it as such. Segregate it on the network that it is on, and nuke it from orbit either regularly or at the end of your project. Make sure there is nothing else running on the server that could not handle being taken over (i.e. make your service the only thing running on the server).


Should I bother teaching buffer overflows any more?

Absolutely.  ASLR and DEP are defense-in-depth measures.  There are exploits that exist that can bypass each of them (for a real-world example, look at Peter Vreugdenhil's Pwn2Own exploit that he used against IE).

All you need to bypass ASLR for Windows is an information disclosure vulnerability that will let you know the base address of a loaded DLL in the process (that was the first vuln that Vreugdenhil exploited).  From that, you can use a ret-to-libc attack to call any function in that DLL.

The bottom line: stack (and heap) overflows are absolutely still relevant today.  They're harder to exploit than they used to be but they're still relevant.


Any 'active' login cookie is only valid for that session (see how SSL works).

Your method/concept of extracting an 'active' cookie from the phone and inserting into another session is technically possible but for it to actually work you need to first have a truly active cookie.


Checking for installed background processes in my phone

In all honesty, there's no way to be sure, other than by getting a new phone and deleting any iCloud backups that exist of your old phone. Restoring your iPhone to factory settings is a way to be reasonably certain, but if they've installed something on your phone, chances are that they don't want you to find out about it or remove it.


XSS via unsanitized window.location.search.split?

As Steffen pointed out in his comment already, you do not specify how you use the variable newUrl. An actual XSS vulnerability would trigger when using this variable in an insecure fashion in the HTML output.

You must also be careful when using the new code you are experimenting with:

var param = window.location.search.split('param=')[1];

This will return everything after param=. If there as another variable in the URL behind param, the full string will be returned, as you can see below:

URL:     http://example.com/?x=1&param=2&z=3
Command: window.location.search.split("param=")[1]
Result:  "2&z=3"

Depending on the actual usage of the variable, this might open up further exploit potential (e.g. circumventing filters). If an XSS attack is actually possible, must be evaluated based on the usage scenario.


Whats the point in setting up an open proxy?

Most of the time, this would be a misconfiguration, and those residential users are probably not aware until someone (their ISP) tips them off. Open proxies often tend to be short-lived, because they were not meant to be in the first place.
Even assuming the open proxy is not the result of somebody experimenting with software without the proper skills - people usually don't have security in mind when
plugging in a router, a NAS, an IP camera or some Internet-enabled appliance. But many of those devices are shipped with a default password, or no password, lax configuration rules, and may expose a number services to the Internet at large. But people just don't realize the stuff they are exposing unwittingly.


A third party Web site wants me to validate my domain ownership using a TXT record

Yes, under certain circumstances, they can.

TXT records are frequently used to verify the domain name ownership for various reasons, including (but not limited to) TLS (HTTPS) certificate issuance. For instance, this is how it is done with DigiCert which is one of, if not the, largest certificate authority in the world.

Note that the process is just the same as in your case: you need to take a seemingly arbitrary alphanumeric string (provided to you by the tool) and to put it in the TXT record of your domain.

A potential attacker can supply you with a string they have obtained from a CA's validation agent on your behalf and then obtain a valid HTTPS certificate for your domain. The certificate could then in turn be used e.g. for man-in-the-middle attacks against your Web site.

To address that scenario, most validation agents these days generate not just an arbitrary alphanumeric string for a TXT record but a string with a prefix which is expected to rather uniquely identify the validation agent. At the time of writing, the service you have mentioned seems to do exactly that: it just provided me with a string have-i-been-pwned-verification=e6c252c87a4bd0e0fd7cb39a057bb0b3, which contains an easily recognizable and apparently innocent prefix have-i-been-pwned-verification=.

See, it's highly unlikely that a different Web service (including CAs) would issue anyone a string with exactly that prefix.

(Make sure the prefix still stays there when you are going through validation.)

Aside from potential (and severe, thus unlikely) vulnerabilities in validation agents, prefixed strings with long and seemingly unique prefixes may be considered safe to put into a TXT record for a rather short period of time.


How to Break
To answer your question about 'how to break' - the easiest way is to use a 'ping' program that uses other protocols than ICMP and/or other options.
hping3 is in Backtrack/Kali (you said you used Backtrack/Kali, but hping3 is available for download), and it allows you to use TCP and UDP pings, and it allows you to use other ICMP types for pings.
TCP ping to port 80:
> hping3 -S xxx.xxx.xxx.xxx -p 80 -c 1

UDP ping to port 53:
> hping3 -2 xxx.xxx.xxx.xxx -p 53 -c 1

ICMP ping using the 'timestamp' type:
> hping3 -1 xxx.xxx.xxx.xxx -C 13 -c 1

Other tutorials for hping here.
Why it works
The typical 'ping' program uses a predefined ICMP echo request. This is very useful for diagnostics, but it is also easy to predict and block. As you can see, there are other ways to get the same functionality of ping by using other protocols and ICMP types.
How do you block?
If you want to block the normal ping program, you block ICMP echo requests at the firewall. But, hping3 uses valid processes in the protocols you need to serve webpages, which means that you can't block it. If you want block even hping, then you would have to block hosts from your firewall, which is likely not something you want to do with a website you want to be publicly accessible. (Actually, there is a way to block the use of hping, but the user of hping would have to use the stock or invalid protocol settings of hping. With more networking knowledge, it would be impossible to block.)
What you need to know
It is important to understand that the issue here was not with your understanding of the tools available, but with your understanding of networking protocols. You will be a better network security person by reading things like TCP/IP Illustrated. By knowing what ping did, and what protocols it used, you would have been able to answer your own question.


Is maintaining multiple keypairs for different services worth the effort?

Think of key pairs as an administrative range of systems and data that access is granted too.

If an attacker gets access to one what does he/she gain access to across everywhere this key pair is used?

If you used different key pairs for different services how would this limit the attacker's access?

Finally as an example, if you used one key-pair to move public images for a handful of web servers to and from a public image providing service (let's call it GifHub) and another key-pair for moving credit card data to a separate set of systems hosted by your credit card processor (ignore PCI for a moment). Can you think of any reason why you wouldn't want to give your public image providing service access to your credit card processing database? In this hopefully fictitious example, you might notice that one key-pair is protecting data that is public whereas the other key-pair is protecting credit cards. The reason you don't want to use the same key-pair for both is if someone attacks your image moving application you don't want them to be able to have access your credit-card database. Hence having multiple key-pairs provides a level of defense in depth which is something you want. So using separate key pairs for each service is generally wise.

Note: There are a LOT of other reasons you would want to use different key pairs for different applications or even data moving in different directions. It would take too long to cover all the issues here but yes there is a security benefit and it comes in the form of defense in depth.


Levels make everything tiered.  You can't have person A have access to one set of functionality and have person B have access to a different set of functionality but not the set A has access to.

Groups can be nested and you could even have levels within the group if you wanted to have a hybrid of the two.  Fundamentally it really depends on your security needs and how you want to approach it though.  Having security levels is far simpler from an implementation standpoint (you just store a number instead of a list of permissions to check against) if you can make it work for your needs, but it is also more limited.


Getting scanned on AWS Elastic BeanStalk

Any instance/ELB on the public internet will get a public IPv4 address. There are people/bots who constantly scan for vulnerable hosts on the internet, I'm no expert on the tactics they use but its entirely possible that they scan known ranges like AWS more frequently.

A google shows up several articles on the tactics that could be used e.g.: https://www.securitynewspaper.com/2015/10/15/how-to-scan-whole-internet-3-7-billion-ip-addresses-in-few-minutes/

As an example I recently tested this by creating an instance with no DNS name, just an IP address. It was scanned 22 minutes after being created.

Bottom line is if you're concerned about the security of your IP then dont put it on the public internet, if you have to then consider an IP whitelist to just allow your address or alternatively look at AWS WAF for rules to block malicious traffic.

As an aside this is possible because the number of IPv4 addresses is relatively small. The IPv6 range is much bigger so theoretically scanning all addresses will not be possible (or at least not easily)


NOPs tend to get flagged by anti-virus, so an alternate method can be used to 'slide' the execution to the shell code. The way you were told was to add 1500 bytes to the ESP, which (I'm assuming) should replace 1500 NOPs, landing you at your shellcode.

If you have not already seen this, you NEED to be reading corelan.be for awesome BO writing tutorials. Here is one that explains the add esp


Negative consequences of forced encryption of unencrypted secvices

Not knowing the use case, it is difficult to anticipate what would count as a downside.

But performance is often a problem. TCP has a flow control feature whereby it automatically slows down in response to perceived network congestion, so if you tunnel TCP on top of TCP, like e.g. FTP over ssh, or over OpenVPN with the TCP transport option, you can have surprisingly serious issues. The OpenVPN documentation explains this well, and switching to OpenVPN UDP can resolve. But then you might need to adjust default packet fragmentation, I once saw that become a problem. It helps if you know your way around a network sniffer like wireshark to diagnose / resolve such performance issues.

As for other issues, debugging the protocol you are encrypting obviously can't be done with a sniffer anymore once the traffic is encrypted,  unless you give your sniffer knowledge of the key. (Wireshark has some capabilities related to this.) But then that's also the point, so not sure if we should consider it a downside.

You'll also need sufficient processing power to handle the encryption / decryption. I find a Raspberry Pi 3 can stream video over OpenVPN very reliably (if you use UDP transport option and resolve any packet fragmentation issues), but that Pi is kinda busy. I find the processors in some cheap routers are not able to encrypt / decrypt that quickly - so just depends how much processing power you have conveniently available.


Verify password hashed with nonce when the password is already hashed on the server?

Am I right to say that this won't work if the password is not stored in plain text on the server? I fail to see how the server could verify the hash if the password is already hashed (with salt and pepper) on the server.

This scheme does require the password to be stored in clear-text. Very bad.

  Can this scheme be extended to work with hashed passwords somehow?

I'm sure it can, but there's no need. The scheme you've referenced is the HTTP digest authentication protocol. It was written in a day when SSL was considered to expensive to implement in many systems. Digest authn provided a way to login over clear-text channels without exposing the password. There's absolutely no reason to do that anymore. SSL is now effectively free.

In general, the risk of storing passwords on the server is considered to outweigh the benefit of having the server not having your password in memory for a short period of time (time from reception of password message until hashing begins and the cleart-text password's memory can be erased).

There are some situations where client-side hashing can make sense. For example, LastPass implements a unique authentication mechanism that involves both client and server hashing. They do this because they use your password as the basis for creating your encryption key and they never want the server to know your encryption key. So what they do is:

Many rounds of PBKDF2 on client to create a strong encryption key.
One round of SHA-256 to turn encryption key into what is effectively your password.
Send password to server. Note that the properties of SHA-256 make it computationally impossible to reverse the password back to your encryption key.
Server performs standard server-side hashing using PBKDF2 and salt.

Basically, the LastPass server does standard password storage but what it gets as a "password" is the result of client-side hashing.


Is using Gmail's browser-based client, more secure than using IMAP?

Based upon your password habits, I don't think it will make a substantial difference.

If you use a long, strong, random password, then it will be infeasible for anyone to crack your password through online guessing (i.e., automated attacks, where the attacker repeatedly connects to Google and tries one guess at your password at a time).  This is true even if Google doesn't use a CAPTCHA for the IMAP and even if Google doesn't do any rate-limiting after several erroneous password guesses (which they might).  Breaking your password in this way would simply take too long.  Consider, for example, a 8-character random password made of alphanumerics. There are 62^8 possible passwords.  That's about 10^14. So, to find your password, an attacker would have to try logging into Gmail 10^14 times. At a rate of 1000 login attempts/second, that'll take 10^11 seconds = 3,000 years.  Therefore, it's not worth worrying about it.

The weakest link in your security is likely to be something else -- e.g., the security of the client device you use.

In other words, the difficulty of guessing your password is not the weakest link in the chain, so (by Amdahl's law) it's not worth optimizing it: making password guessing harder won't make much of a change to the cost of the cheapest attack, and won't make much of a change to your overall risk.

P.S. I do recommend that you make sure to always use SSL or TLS, to prevent folks from eavesdropping on your password.  For instance, use IMAPS (IMAP over SSL/TLS) to connect to Gmail.  If your server happens to support both, IMAPS is probably superior to STARTTLS, because STARTTLS will fall back to unencrypted cleartext communications if it cannot negotiate TLS, whereas IMAPS won't.


Is it possible to Exploit this Line Feed?

I would try to just do something like this:

http://www.example.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E  TEST TEXT %3C/html%3E

to start with. Then, if you see 2 different responses, and one of them is a 200, and if you see the text, you can then try whatever stuff with cookies.


I think you are looking for softflowd:

Softflowd is flow-based network traffic analyser capable of Cisco NetFlow™ data export. Softflowd semi-statefully tracks traffic flows recorded by listening on a network interface or by reading a packet capture file. These flows may be reported via NetFlow™ to a collecting host or summarised within softflowd itself.
Softflowd can export using NetFlow version 1, 5 or 9 datagrams and it is fully IPv6 capable: it can track and report on IPv6 traffic and flow export datagrams can be sent to an IPv6 host. Any standard NetFlow collector should be able to process the reports from softflowd.


What are the pros/cons of using a threat detection system?

Pros

Instant feedback, handling the issue before the damage is done.
Knowledge of what is happening in your web app. For example, who is where and other information.

cons:

Takes more resources.


Secure Radio Frequency TX, RX module from replay attacks

IoT limitations will be serious to your system security. It may be fun to build but personally I would like strong security for the garage door. Anyhow, some general answers below.

AES is common secure alternative in the modern communication protocols. XOR will reveal your password to the eavesdroppers. Search e.g. "whats wrong with xor encryption" in this forum.
The TLS nonce is a good example of preventing replays. Its use is discussed here:
nonce in SSL/TLS handshake


The best solution would be to implicitly deny, i.e. allow exactly the data you want, but no other.

You could write regexps matching all input that's not according to your filter to find any odd input, that might be an exploit. It is also a good way to find valid input you omitted in your regex.

A username might be fine with [a-zA-Z0-9]+, rather than removing single quotes or similar to sanitize input.

EDIT:
This is the approach I would take:

Add regexps to implicitly deny all inputs, to fix this problem in the future.
Check the data in the log files against the regexps that were written in step 1
Remove all input data in the log files that matches the regexps.
Reduce the logs by counting identical rows and deduplicating them, so we don't have to look at 1000 identical rows, but still know that we had 1000 rows like that in the log files.
Check if any of the logged input should be valid. If so, update the relevant regex and goto step 2.
Check if any of the remaining log inputs look suspicious.


I am signing (HMAC) outgoing webhooks to allow users to verify their source, should I also sign outgoing responses?

This is a bad idea.

You are essentially (ab)using symmetric cryptography to implement asymmetric cryptography. In your approach, the following problems will arise:

If you only have one key, then every client you distribute the key to can effectively impersonate you
If you have one key per client, you need to worry about key generation, storage, exchange, deprecation, etc.

A much better idea would be to use any asymmetric cipher (Elliptic Curves, RSA, etc.). The scheme would then work as follows:

You generate a private and public key pair, and distribute the public key.
You sign the timestamp and body, then send it off to your client(s).
The client(s) use your public key to verify the signature, and thus both the authenticity and integrity of the message.


SSL/TLS in-memory data interception after decryption

Any attacker who gains sufficient privileges to inspect the memory of other process is an attacker who has full control over the machine -- at which point anything which happens in that machine can be known to the attacker. This is true of every machine and OS, including mobile devices; however, while multi-user servers with a Unix-like operating system are quite traditional, multi-user iPhones are quite rarer.

If the client can thus be hijacked, then there is no way out of it except making it so that the client never gets the cleartext data in the first place. But then, the client does not have access to the cleartext data, which reduces its functionality (e.g. it cannot show it to the user).

A reduced scenario is about virtual memory. When a computer has data in memory, that data may get copied into swap space by the OS, in an automated fashion. An attacker seizing the machine afterwards may thus get excerpts of sensitive data by looking at the swap space. If an application manages data which is exceptionally sensitive, it can ask the kernel never to write it to swap space; on Linux systems, this is done with mlock(). GnuPG does that, when it has private keys in memory.

A tempting alternative is to disable swap space altogether; modern computers have a lot of RAM, and use programming systems which don't interact well with virtual memory anyway (that's a known issue of garbage collectors). A computer with no swap space will, by definition, never let memory-based data be written to the disk; not that such a computer would not be able to go into prolonged disk-based hibernation mode.

It is worth noting that "mobile devices" (smartphones, tablets...), as a rule, don't have Virtual Memory, because their storage capacity is not up to it anyway. In that sense, mobile devices may be a better bet than traditional computers with "normal" configuration, when it comes to limiting data leaks through persistent storage.


AWS S3 resource access control through IAM permissions or bucket policies?

Restrict access to your S3 buckets or objects by:

Writing AWS Identity and Access Management (IAM) user policies that specify the users that can access specific buckets and objects. IAM policies provide a programmatic way to manage Amazon S3 permissions for multiple users. For more information about creating and testing user policies, see the AWS Policy Generator and IAM Policy Simulator.
Writing bucket policies that define access to specific buckets and objects. You can use a bucket policy to grant access across AWS accounts, grant public or anonymous permissions, and allow or block access based on conditions. For more information about creating and testing bucket policies, see the AWS Policy Generator. [[Note: You can use a deny statement in a bucket policy to restrict access to specific IAM users, even if the users are granted access in an IAM policy.]]
Using Amazon S3 Block Public Access as a centralized way to limit public access. Block Public Access settings override bucket policies and object permissions. Be sure to enable Block Public Access for all accounts and buckets that you don't want publicly accessible.
Setting access control lists (ACLs) on your buckets and objects.
[[Note: If you need a programmatic way to manage permissions, use IAM policies or bucket policies instead of ACLs. However, you can use ACLs when your bucket policy exceeds the 20 KB maximum file size. Or, you can use ACLs to grant access for Amazon S3 server access logs or Amazon CloudFront logs.]]

Extra Points!

In addition to using policies, Block Public Access, and ACLs, you can also restrict access to specific actions in these ways:

Enable MFA Delete, which requires a user to authenticate using a multi-factor authentication (MFA) device before deleting an object or disabling bucket versioning.
Set up MFA-protected API access, which requires that users authenticate with an AWS MFA device before they call certain Amazon S3 API operations.
If you temporarily share an S3 object with another user, create a presigned URL to grant time-limited access to the object. For more information, see Share an Object with Others.

Ref Link: https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/


The term to search for is "BGP hijacking".

The risk is low but non-zero. If an attacker can find a sufficiently sloppy ISP they can advertise their own route for the IP range block containing your clients IP. With sufficient sophistication they may even be able to set things up so they hijack the traffic from HQ to branch and then return most of it to the branch.

Now finding a sufficiently sloppy ISP may be difficult and the loophole is likely to be closed once the bogus route is discovered but there is certainly a window of opportunity there.


Heartbleed - is this scenario possible? how bad would it be?

They are two different services, that are not related.

PK Signing service

These keys use the CA's crown jewels.
They are protected as much as they can.
If they are lost, they will be Out of Business
So they use network segmentation, firewalling, HSM's, armed guards, whatever it takes to secure them.

Normal SSL website using a signed key (possibly but not necessarily from the service above).

Impact of compromise - embarrassing, reputation damage but not critical.

So, they 'could' choose to combine these two services, using the same key on the outside of their website, but as @StephenTouset says above, "It would take an astonishing amount of incompetence"


Why do some passwords not allow certain types of characters?

Any restriction of any shape or form on the passwords will decrease their entropy, making them weaker. Fewer limitations = more possible combinations. There's no technical reason why passwords should be limited in anyway*. It's not a programming related issue, it's a chimpanzee-related issue.

That is especially the case if you're properly and securely hashing your passwords.

* In some very old and legacy systems, there might be some technical limitations related to encoding, acceptable characters by the operating system itself, and so on. Of course, that doesn't exist anymore, and there's no reason for us to imitate the behaviour of those old systems.


Entropy on native memorable password on macosX keychain

Anders Bergh reverse-engineered the OS X Password Assistant and wrote a command-line utility which does the same job. From its source you can find out that all of the password generation is done by a proprietary undocumented library function SFPWAPasswordSuggest() from the SecurityFoundation framework.

Though the function is proprietary and no official Apple documentation exists, you can play with either the function itself or the command-line utility around it to figure out what it's producing. Allister Banks already did that in 2015, assumingly for OS X Yosemite, and came up with a code snippet which produces pretty much the same results (except for a few strange author's preferences, like limiting the range of available random numbers).

In a nutshell, SFPWAPasswordSuggest() picks two random words from a vocabulary and inserts a random number and one special character (in that order) between them. The random number length is such that the overall string length will be exactly as required, and there will always be a single special character. Regarding the vocabulary, OS X from Yosemite to High Sierra use /System/Library/Frameworks/SecurityInterface.framework/Resources/pwa_dict_en.gz, 287 kb in size and with 83935 English words of length between 2 and 24, for that:

$ gzcat pwa_dict_en.gz | python2 -c 'import sys
> sys.stdin.read(512)
> word_counts = dict()
> for num_of_letters_index in range(64):
>     value = int(sys.stdin.read(8).strip(), 16)
>     if value:
>         word_counts[num_of_letters_index] = value
> print "Distribution:", word_counts'
Distribution: {1: 26, 2: 191, 3: 1229, 4: 3170, 5: 5591, 6: 8913, 7: 12452, 8: 13462, 9: 12163, 10: 9820, 11: 7007, 12: 4516, 13: 2704, 14: 1429, 15: 691, 16: 329, 17: 150, 18: 61, 19: 21, 20: 5, 21: 3, 22: 1, 24: 1}
$

Here's how you can parse the file. In other OS X versions, the function may be designed somewhat differently; use dtruss ./sf-pwgen to figure out.

Note that GUI limits the length of your generated password with number 31. As far as I can see, the function doesn't produce an error for longer requests, yet is not guaranteed to work for passwords longer than 31 characters. Actually, for passwords above 67 characters, it's almost guaranteed to fail; as you can spot above the vocabulary doesn't feature enough words of sufficient length, and the generating algorithm doesn't handle this case well, simply returning a short passphrase consisting of only numbers and a special character:

$ ./sf-pwgen -c 1 -l 68
2814154076!
$

EDIT 24.01.2018: on behalf of Alex Recuenco:

Calculating entropy

Following @ximaera solution.

import math

x = {1: 26, 2: 191, 3: 1229, 4: 3170, 5: 5591, 6: 8913, 7: 12452, 8: 13462, 9: 12163, 10: 9820, 11: 7007, 12: 4516, 13: 2704, 14: 1429, 15: 691, 16: 329, 17: 150, 18: 61, 19: 21, 20: 5, 21: 3, 22: 1, 24: 1}

def entropy(pass_length, n_symbols = 30):
    combinations = 0
    for key, value in x.items():
        for key2, value2 in x.items():
            if (key + key2) < (pass_length - 1):
                combinations += value * value2 * n_symbols * (10 ** (pass_length - key - key2 - 1))
                # last value

    return {'combinations': combinations, 'entropy': math.log2(combinations)}

print(entropy(31))

Which when you run it:

> {'combinations': 1124445877165765109161692550890600, 'entropy': 109.79284135298234}

110 bits of entropy, maximum... I thought it would be better for some reason. The entropy of a password of just numeric characters of length 30 is approximately 100


Can someone explain the "Section 4.2.1.3. Key Usage" extension in RFC 5280 as it relates to TLS 1.2 RFC 5246

Great question! I don't know if there's definitive source for this, so I'm going to make educated guesses based on the RFCs.

TL;DR: the following keyUsage bits are supported in TLS 1.2 for end-entity certs:

   digitalSignature        (0),
   keyEncipherment         (2),
   keyAgreement            (4),

Now let's go through the keyUsages one at a time:

digitalSignature

 KeyUsage ::= BIT STRING {
   digitalSignature        (0),

This one is obvious, this is the normal RSA or ECC certificate auth.

nonRepudiation

   nonRepudiation          (1), -- recent editions of X.509 have
                        -- renamed this bit to contentCommitment

This is typically used for legally-binding signatures, such as eIDAS. I can't imagine you'd put this on a TLS cert.

keyEncipherment

   keyEncipherment         (2),

This will correspond to TLS cipher suites with RSA key transport, like TLS_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

RSA                RSA public key; the certificate MUST allow the
RSA_PSK            key to be used for encryption (the
                     keyEncipherment bit MUST be set if the key
                     usage extension is present).
                     Note: RSA_PSK is defined in [TLSPSK].

dataEncipherment

   dataEncipherment        (3),

I don't think there's a use for this in TLS.

keyAgreement

   keyAgreement            (4),

This is used when you have a Diffie-Hellman key in a certificate. This is definitely less common than it used to be, and people prefer the ephemeral versions -- DHE and ECDHE -- but TLS 1.2 does support it with cipher suites like TLS_DH_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

DH_DSS             Diffie-Hellman public key; the keyAgreement bit
DH_RSA             MUST be set if the key usage extension is present.

keyCertSign & cRLSign

   keyCertSign             (5),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The keyCertSign bit is asserted when the subject public key is
  used for verifying signatures on public key certificates.  If the
  keyCertSign bit is asserted, then the cA bit in the basic
  constraints extension (Section 4.2.1.9) MUST also be asserted.

You don't (or at least, really really shouldn't) use a CA cert directly for TLS, so I wouldn't expect to see this key usage on a TLS cert.

Similarly:

   cRLSign                 (6),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The cRLSign bit is asserted when the subject public key is used
  for verifying signatures on certificate revocation lists (e.g.,
  CRLs, delta CRLs, or ARLs).

So you shouldn't see that key usage on a TLS cert.

encipherOnly & decipherOnly

   encipherOnly            (7),
   decipherOnly            (8) }

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The meaning of the encipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the encipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for enciphering data while performing key agreement.

 The meaning of the decipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the decipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for deciphering data while performing key agreement.

These terms do not appear in RFC 5246, so I don't imagine a TLS server / client would know what to do with them, even if they were present


Can cookies with a complicated secret be manipulated?

It depends on the implementation. Insecure methods exist, such as only encrypting the data with AES-CBC, where the contents can often be modified even if they can't be decrypted.
The secure method is to use a cryptographic algorithm to verify integrity of the data. For example, HMAC can be used to verify the contents are unmodified. JWTs are a common example of doing this in practice. As long as the secret key is safe, the tokens cannot be modified.


Can linux (be made to) detect foreign connections to the ram bus?

This got cross-posted to electronics.stackexchange. The short answer is that it's not possible to detect all of this kind of hostile hardware attack in software.

If you had a probing device on the bus that actively requested memory reads, it would be possible to detect it by observing delays in memory reads. You'd have to specifically go looking for it by setting up an uncached read with timing measurements before and after, but you could detect it.

However, if I were building this sort of attack system I'd simply have a shadow dual port RAM connected to the same write lines, storing a copy of all memory access since bootup. I could then read from the copy without disrupting timing of the main memory access. It's not trivial to build such a thing - it requires careful attention to avoid disrupting the electrical signals to the RAM - but it's quite feasible against socketed or soldered DRAM. It's not feasible against internal RAM of a SoC, or stacked chip RAM such as in the Raspberry Pi.

(This is not to be confused with "cache snooping", which is a normal part of a multiprocessor system)

Edit in response to comment: it's not especially different on a multiprocessor system; on a NUMA system you need one snooping probe per memory bus. It's certainly something that requires a lot of effort and physical access, so it's mostly used for breaking into devices that you own such as games consoles and mobile phones. It's not something I'd expect to see in a datacenter; high-value target machines are likely to be locked away in tamper-alarmed cases to defend against this kind of thing.

(References? Does this SE have a Wikipedia-style ban on original research?)


Using burp-rest-api, how do I log into my web application in order to scan for vulnerabilities?

#Pass the user/project config json file
curl -X POST "http://localhost:8080/burp/configuration" -H "accept: */*" -H "Content-Type: application/json" -d "\"string\""

modify the following lines in project_config json file or string to spider the application based on form based login/authentication.

   ...

    ...

        "spider":

          {  "application_login":

             {  "mode": "automatic",

                  "password": " ",

                  "username": " "
             },

               "crawler":

    ...

    ...

Note : the project_config json example can be found in API documentation


Neither a virus scan nor a web of trust can judge the security of the website. WOT is just about the trust others have in this site, which says nothing about the security of the site in general and especially not of the security at the very moment. A virus scan will also not find typical coding problems like SQL injection or cross site scripting nor will it give you any clue how well your data are protected.

  How can I know if visiting a website is safe?

You don't. Which already starts with the problem what "safe" actually means?

Is it that the site itself does not try to deliberately attack you (phishing or malware), i.e. safe to visit.
It is about privacy, i.e. how much the site will track you? Is it about the safety of the data you enter into the website, i.e. safety of stored passwords and credit cards, no deliberate sharing with others etc.

  What about addons like WOT (web of trust)? Can their assessment of websites be relied on?

This is more like the rating of products on shopping sites or the rating of restaurants. If everything is bad the site likely behaves in a bad way. If everything looks good it can actually be good right now, it could have been good once, the rating could be deliberately manipulated ... So it is some kind of indicator but nothing you can fully rely on.


How To Secure a Computer Stick that Runs a TV

The best option IMO is to physically secure the box. That can take the form of locking the whole box up, or any of the options that lock USB ports.


Could IOT Botnets be Stopped by Static IP addressing the Devices?

Almost all IoT devices of the sort we are talking here (ie, consumer level) are deployed behind home grade routers (or ARE home grade routers) and are using IPv4 and NAT/uPNP to reach the internet.  That means they are sharing an IP with legitimate traffic for one and for another are using a dynamic IP, not a static IP, meaning there's even more opportunities for innocent parties to be caught up in such a blacklist.

Once the glorious world of IPv6 comes, we can likely do just that - assign each one a routable IP address and blacklist them as they get shown to be vulnerable.

One legitimate thing that CAN be done is for ISPs to perform source IP filtering - that is, don't let spoofed packets out, only let packets from IPs within the network.  That will help. Some.


Ransomware - All computers infected but one

The concept you are looking for is "persistence". You don't want to destroy your route to continue to extort the victim.
If you encrypt the machine that is your route in, then the victim will reformat/reinstall the operating system and wipe out your route in.
So, you leave the one machine (likely the first infected machine) alone, but launch attacks from it to the rest of the network.


What does GUID have, that a Whirlpool, MD5 or SHA-2 hash don't?

First of, a hash function has an input: you hash something. GUID (actually UUID) don't have any input. To generate "unique identifiers" with a hash function, you just don't use a hash function; you have to define what you are actually hashing.

There are several standard methods for generating UUID; all these methods aim at achieving "uniqueness" of the generated identifiers. Method 3 uses the MD5 hash function: you generate the UUID by hashing some data which is already inherently unique worldwide (e.g. a URL), but longer than the 16 bytes of an UUID. This method closely resembles what you suggest, except that it defines clearly what is hashed (or at least, it states in plain words that when hashing, you hash something and your UUID won't be more unique than what you hash). Method 5 is like method 3, but with SHA-1 instead of MD5 (output is truncated to 128 bits).

Other methods use physical or configuration elements of the local machine (e.g. MAC address and current time for method 1). Most method are "cooperative": they ensure uniqueness but new UUID values can be predicted. For many security-related protocols, when you need unique ID, you actually need ID that won't collide with previous ID (or will do so only with negligible probability) and cannot be predicted by attackers; for that, you need "method 4": the 128-bit UUID contains 122 random bits, generated from a cryptographically strong PRNG. This method will provide "strongly unique" identifiers, and is better than any homemade construction.


Can my location be tracked trough WiFI ?

If you are going off of exclusively wifi based tracking (ie assuming your XMPP and TOR are perfectly secure and undecryptable and you are also not leaking anything) it is possible to locate you physically if someone is on the ground looking for you.

This can be done in two ways:

The transmitting station (ie the coffee shop) has multiple directional antennas and multiple network cards. This is generally not a thing because who wants their wifi to be available only in an x degree cone. This however is more of a thing with cell towers who have very directional transmitters. Since the transmission station knows what antenna you are connected to/communicating with they know roughly how far away you are (very roughly) and what "cone" area you are in. This isn't an exact lat,lon coordinate but it limits the search radius.
Someone is on the ground using a directional antenna trying to determine where you are as your are communicating with the network. It's a similar idea to above but it is best described as "radio hide and seek". Someone can measure how strongly you are transmitting and then they can play "hotter colder" with you until they find you. This would of course be an instance where a three letter agency is after you. I've never heard of this being used against wifi clients but it should work just the same as tracking down rogue access points.


Userland:

understand how the Windows native API works, e.g. something like (and probably not accurate): ZwCreateProcess -> NTCreateProcess -> CreateProcess
https://undocumented.ntinternals.net/
https://www.google.com/shopping/product/10794697035904501181?q=native+api+book&biw=1486&bih=811&sa=X&ved=0ahUKEwjFzNPlkLLWAhVkJcAKHdwGDRYQ8wIIgwMwAA

Windows Internals:
https://www.amazon.com/Windows-2000-Native-API-Reference/dp/1578701996

You'll also want to know x86/x64 calling conventions (STDcall), e.g. how arguments are passed and return values.

Last, what the OS expects and how the return values are used.

Ring0:

Uninformed.org has a good writeup:
http://uninformed.org/index.cgi?v=10&a=2


Gathering network device data for security detection purposes

When starting an SEIM project, a step-wise approach to security events management is a good approach EG inventory and prioritize your infrastructure, and rate each device according to its security impact/exposure. For example, you will get more detailed security event information from a firewall than from a router. Likewise with web access logs, OS level event logs and HIDS.

  Is it normal for security guys to have direct access to firewalls, nac interfaces, etc

That depends on the organization and security processes. Firewall configuration may be left to network administrators, while security operations may be responsible for monitoring logs and auditing policy changes, while having no direct access to their configuration.

  is syslog output for what we actually want more appropriate?

At this step in your process, yes logs represent the main data source for your SEIM implementation. The biggest challenge in aggregating logs for use in SEIM is filtering out noise, and focusing on real security event signatures, in order to eliminate false positives, and avoid the "firehose" effect you mention.

As a suggestion, at this step, consider log aggregating services like PaperTrail and Splunk. You quickly get a view of all your log events and formats in realtime, and can begin to define filters, and generally understand what log data will be critical for your SEIM implementation.


The security of an SMB port exposed to the internet

All your questions have nothing to do with Unix but I guess you want an input from experts so here it goes.

It's secure as long as your password is complex enough and your Windows system is patched and rebooted immediately as soon as Microsoft releases a new Windows update and that happens each month. Updating your system 3-4 times a year like you said is a very bad idea.

There are security scanners like XSpider. nmap is mostly used for open ports and services discovery - it's not a security scanner.

Extra hardware is unlikely to help you if you have CIFS ports exposed to the entire Internet. What could help you is putting your Windows host in a DMZ or in a VM to minimize the damage to other hosts in your LAN in case this particular PC gets hacked into.


Bluetooth Security Mode 2 - is there a regular pairing, as in Mode 1?

But there should be some pairing first, before data signing can be
  used, right?

The initial pairing is completed on the physical layer (You have to press the button on the Bluetooth device) before the handshake/protocol is initiated. Your next question is:

  The problem is, if the pairing looks like in Mode 1, or its a
  different procedure?

The answer is No. The pairing is the same. Regardless of the Security mode, encryption mode, or service level. The initial pairing/setup starts with a button press (or some other physical interaction between authorized parties/ owners and the Bluetooth devices).

Source

Source


I can see login credentials on Facebook while using Maxthon browser

It's pretty simple. As you say, and Maxthon does not yet support HSTS. So for this reason Maxthon will be susceptible to MITM attacks unless you specifically use the https:// prefix for www.facebook.com.

  The green bar says that the site is "certified by CEAIA".

I find it misleading that they would show the site as certified when the connection is insecure. Perhaps I mis-understand the meaning of this message from Maxthon?

  Why facebook still process HTTP requests?

Probably this is not true. (except that they would provide HTTP 301 redirects to the secure site in addition to an HSTS header)

The more likely case is that SSLStrip is communicating with Facebook over HTTPS. Only Maxthon thinks it is HTTP because of SSLStrip.

  By the way, Maxthon was among other browsers recommended for Win10 when my friend installed it for the first time. Kinda scary that it's so insecure.

It's insecure if someone is tampering with your connection and you forget to use the https bookmark.


Custom word list generation for a specific web domain

A Python solution

You can use Scrapy which will make most of the work for you. You then would just need to use Counter() to get the top words (if looking for frequency counts).

You could also use a more low-level approach with Beautiful Soup to get the top 5 words:

# coding=utf-8
import requests
import collections
from bs4 import BeautifulSoup

thesite = requests.get("http://www.lemonde.fr").text

soup = BeautifulSoup(thesite, 'html.parser')
thewords = soup.get_text().split()

print(collections.Counter(thewords).most_common(5))

Since the output is

[('de', 223), ('la', 154), (':', 123), ('{', 115), ('à', 84)]

you could look at setting a minimal length of a "word" (3 perhaps?)

UPDATE: the code for a sorted list of most common words with 3 or more letters

# coding=utf-8
import requests
import collections
from bs4 import BeautifulSoup
import operator

thesite = requests.get("http://www.lemonde.fr").text

soup = BeautifulSoup(thesite, 'html.parser')
thewords = soup.get_text().split()

# keep only words over 3 chars

thewords = {w: f for  w, f in collections.Counter(thewords).items() if len(w) > 3}
topwords = sorted(thewords.items(), key=operator.itemgetter(1), reverse=True)

print(topwords)


Injected malicious code in temporary files

My answer may look ridiculous compared to your question, but you can simply use code signing to mitigate all of the scenarios you developed.

As you mentioned .net, you cannot "simply" inject code in a strong-named assembly without tempering it.

Before loading anything you verify its authenticity (against your digital cert).

Is this the ultimate solution? of course NO, but it will demand much more sophisticated malware than a simple code injector (whatever where..)


Cross-signing certificates for Windows Driver Signing

Cross-certification in Windows is done via certreq.exe tool:

certreq -policy <policy.inf> <certtocrosssign.cer> <outreq.csr>

where <policy.inf> is INF file that defines cross-certificate contents and constratints. <certtocrosssign.cer> is a path to a certificate file you are cross-signing. And the last parameter <outreq.csr> is the path to cross-certificate request. Before executing the command, make sure that you have a certificate with Qualified Subordination (1.3.6.1.4.1.311.10.3.10) EKU. This key is used to sign request.

  When I simply sign the public key with the cross-certificate in OpenSSL, the cross-certificate is presented as the root certificate.

no, cross-certificate is not root certificate (Subject and Issuer doesn't match). Issuer is the CA used to sign the request and Subject is the subject of CA you are certifying.

For more details, please refer to Microsoft whitepaper on cross-certification. Unfortunately, Microsoft removed it from their servers and you can get a copy from non-Microsoft web sites. For example, a copy downloadable from my personal weblog: 34 PKI & ADCS Whitepapers You Must Read. The document is called [Win2k3] Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003.


Is it a security risk to maintain an application developed for a version of .NET prior to 4.0?

No it's not a risk to run an earlier framework (except for 1.x), just make sure it's patched as described below.

All frameworks will get free security updates as described in Mainstream and Extended Support phase.  Each framework needs to have it's own service pack.  (scroll to bottom of that link)

To make things easier, .NET 3.5 SP1 is considered a core component of the Windows OS.  The standard Windows support guidance applies.  In particular:

.NET 1.0 is a security risk since no hotfixes have been produced since SP3 past July 14 2009
.NET 1.1 should be at SP1, though security hotfix support ends October 2013 unless you are running it on Server 2003 (security hotfix support for Server 2003 ends July 2015).
.NET 2.0 should be at SP2
.NET 3.0 should be at SP2
.NET 3.5 should be at SP1
.NET 4.0 will reach end of support on all OS on January 12, 2016
.NET 4.5 should be at 4.5.2.  Support expiration is based on the OS and the most recent service pack for that OS.  (e.g. Windows 7 SP1)

  What is the Security Update policy?

  Security updates will be available through the end of the Extended
  Support phase (five years of Mainstream Support plus five years of the
  Extended Support) at no additional cost for most products. Security
  updates will be posted on the Microsoft Update Web site during both
  the Mainstream and the Extended Support phase.

  Is the Extended Hotfix Support program required for customers to receive security updates?

  No. Any customer can report a security issue to Microsoft. Microsoft
  will review the issue. If a security update is created, it will be
  made available to customers as described earlier in this document.


Are SQL injection scans considered illegal?

It will depend on the legal system under which it falls. But you are still doing something hostile. Without previous written permission of the siteowner, you are committing a crime.

There is no way of proving you didn't have a malicious intent. Intent is the key component here. A ping can be done to see if your own internet connection is working or if a website might be down because of a failing server. But if your intent is the see if a site/server is vulnerable for a ping fload, then you are possible already committing a felony.

It will be up for a judge to decide, but consider this:

If you would be trying all the doors of a random car in the street to see it's properly locked and someone sees that, would they believe you were just trying to see if it's locked?


Can a non-privileged user modify the file descriptor table of an elevated process?

Once the process is started, this is not possible. As mentioned the only way to do this is via redirection however that happens inside bash (as you've noted in the comments) not inside the process and thus does not fit as a solution for your question.


Is it possible to decrypt half of a TrueCrypt file container if the other half of the data is missing?

Sort of. You can decrypt it as long as you have more than 128 KiB of data downloaded, as that is the end of the header and backup header and where the actual filesystem starts. However, even if you successfully decrypt it, remember that the filesystem will be cut in half too, meaning it will be massively corrupted. Depending on the filesystem, you may be able to recover all the files if they were stored at the beginning of the filesystem (I believe FAT does this), or very few, if they were spread out evenly (like in XFS). Now, the volume won't mount due to the corruption, of course, so you'll have to use recovery tools. But as long as you have the header, and the password, your question becomes "Is it possible to recover half of the files on a filesystem if the other half is missing?".

https://andryou.com/truecrypt_orig/docs/volume-format-specification/


Since your question is strictly about local exploitation rather than remote exploitation, I'll address it from that angle.

First of all, trust must exist between you and your host provider. Having a shared hosting, VPS, or even your own completely separate hardware as a server with that host are almost always the same. Your host provider is able to access your code, your database, and everything you're keeping on their servers.

As for your concern about other sites accessing your site, it depends; it all depends on the server's configurations. If the server is configured securely: access rights and directory permissions are set in secure fashion (each user has access rights to his own directories), server-side interpretation engine's (for example, PHP) threads are separate and all run under separate users, etc.

The most likely scenario in well configured shared hostings is exploiting a vulnerability in one site and then using a privilege escalation exploit to gain root access and from there the attacker can reach your site. In this case, having a VPS (even one with a system with an unpatched privilege escalation vulnerability) still offers more security than a shared hosting.

Those concerns must be discussed with your provider before signing a contract with them.


You are never connected to all nodes, only one. The whole principle of Tor is that only the first node knows where you are. The other ones needn't know.


Is file shredding effective in a virtual machine?

Not reliably.

Some virtual disk formats can be configured to use thin provisioning (disk space aren't allocated until it is used), and SATA supports TRIM command, which can be used to return blocks to unallocated pool.

Some virtual machines also supports snapshotting, and copy-on-write linked virtual disks shared between multiple multiple virtual machines. Some cloud providers can transparently teleport virtual machines, which requires copying the entire virtual disks to another physical machine, for load balancing or to allow hardware maintenance/failures. Virtual disk images can be copied around by defragment/scrubbing tool running on the host. The virtual machine's disk allocator is also free to rearrange disk blocks to optimize writes.

Unless you control the entire stack and takes steps to prevent these from causing leakage, you can't be sure that shredding would also work on the virtual machine even if you're sure that shredding works on the host machine.

The only way to be sure you're not leaking sensitive data, when using virtual machines, is to encrypt the sensitive data.


How to protect magnetic stripe in credit cards from being read?

You should look for EMI foil tape. It is designed for use as shielding in electronic circuits to minimise unwanted electromagnetic emissions. Avoid the stuff for sale on Amazon and eBay; stick to reputable electronics vendors such as Mouser, DigiKey, Farnell, RS Components, etc.

Another option is to wipe the magstripe completely, then set up and carry a prepay card as a backup for cases where you actually require the magstripe.


Can I use Kali Linux when I learn Backtrack well?

Backtrack will be fine for learning, especially if the course is geared towards it (which I get the impression it may be?) Kali is better in the long run, because it installs, so you can customise it more easily on a machine/VM.

Overall though, I'd advise really learning your stuff with Backtrack/Kali/Combination of the two, and then 'graduating' to putting together your own system in a distro of your choice.  Like is mentioned in the comments, Arch is good, although it takes a while to set up.

I prepared my Pentest box by working with Backtrack, then setting up an Arch VM adding what I needed, and it works nicely.


Why do malware creators use such clever technologies for such silly purposes?

Various reasons:

Attacker is often not the Developer - Developers of malware sell the packages to anyone - the payload will be then defined by the attacker. Some attackers want to be stealthy - some don't, in fact some delight in being obvious and notorious.

Practice - developing techniques

Apathy/Ignorance - end users are really no good at fixing problems that can't be resolved by clicking on antivirus or malware cleaners.

Money - click-thrus and clickjacking can make good money. Viagra/Cialis spam also makes money. Fake-malware removal tool downloads can make a lot of money.


With big numbers, Diffie-Hellman looks like this: we work modulo a big prime p, and we start with a conventional big integer g (in the 2..p-2 range). Each integer modulo p represents an achieved colour; g itself is the starting point, i.e. "yellow" in your picture.

Each paint is an integer; the range of possible paint tones is large (at least 2160). Mixing a new paint x with the current mixture v is modular exponentiation: the new mixture becomes vx mod p (you raise v to the power x, working modulo p, so you get back to an integer in the 1..p-1 range). Mixing no paint at all is equivalent to mixing the paint "1", because v1 = v mod p.

Diffie-Hellman works thanks to two characteristics:

One-wayness: given v and vx, it is hard to recompute x. In the paint analogy, anybody can mix paints, but nobody can "un-mix" that which was mixed.
Commutativity: mixing paint x, then paint y, yields the same result as mixing y then x. With numbers: (gx)y = gxy = (gy)x mod p. With paints, this means that putting yellow in blue yields the same green as putting blue in yellow. This is why Alice and Bob end up with the same colour.

In the picture, Alice and Bob start with yellow. Alice mixes orange in, while Bob uses cyan on his own paper. Then Alice and Bob swap their papers; Alice gets the yellow+cyan paper, while Bob now has the yellow+orange paper. Alice does not know that what she has at that point is yellow+cyan; she only knows that she has a mix of yellow and "whatever secret colour Bob uses". She then mixes in her own secret colour (the same that she used initially on her own sheet, now in the hands of Bob), and this gives yellow+cyan+orange. Similarly, Bob adds cyan to the sheet he got from Alice, and obtains yellow+orange+cyan, i.e. the same final tone. This works because each sheet was splashed with the secret colours of both Alice and Bob (orange and cyan), and the order of mixing does not matter for the final tone. This is secure because what travelled "on the wire" (in reach of eavesdroppers) is only mixed sheets: a spy would see a yellow+orange sheet, and even knowing that it is a mix of yellow and the secret colour of Alice, then working out that the secret colour of Alice is orange is hard.

Where the paint analogy breaks down: As all analogies, it is not perfect. There are two features of modular arithmetics that are crucial to security, and don't translate to paints:

Modular integers "wrap around". You can, at least theoretically, mix in a lot of distinct paints, and get back to the initial yellow. These number-paints can cancel each other; this is as if there were "negative paints" which remove pigments instead of adding new ones. With actual paints, extensive mixing can only reach some dark grey goo state.
Tones can be similar to each other, not integers. If a spy (let's call him Charles) observes the yellow+orange sheet from Alice, he can make experiments with yellow and his own stock of paints. For instance, if Charles mixes yellow with red, he will get something close to the sheet he observed, much closer than if he mixes yellow with blue. Charles could then try again with several shades of pink and ochre and orange, until he pinpoints Alice's secret colour. This would work with physical paints, but not with modular integers, where you have no way to guess whether you are "close" or "not close".

This illustrates a fundamental point: all of this protocol is about information. What Charles want is to "un-mix" the paints, but not necessarily to do so destructively; indeed, Charles' best interest is to let Alice's sheet reach Bob unscathed (there is no point in breaking a key exchange protocol if the victims don't actually complete the key exchange, and thus don't use the exchanged key). What Charles wants to do is to obtain a copy of Alice's secret colour (or at least a copy of the final tone), using his own stock of paints.


How to get Sqlmap to detect insertion point with sleep payload?

Burp Suite won't always pick up right detection. On your question, you noted the application seemed to be vulnerable; This meant it's never determined if it's a positive detection. You will need to check if the detection is Certain or it's just Tentative? (What does Burp Suite tell you?) If it's Tentative detection, you could try using SQLMap or rather try detecting manually.

  The application takes twice the time defined in sleep to respond (sleep 10 returns a response after 20 seconds)

Did you try that manually, if yes - there is a probability of a web application firewall.

Since, SQLMap is the approach which you've taken - I assume you should be targeting on a particular parameter using -p switch and then the name of the parameter which you are testing. You have noted that --risk & --level doesn't help. It's because if the parameter detection is Tentative, it's a false positive.

On a sidenote, use --tamper=ptm & tamper=charencode, let us know how that went.

Another way could be using --identify-waf switch to determine if the target is beyond a firewall which might be dropping interesting packets.


Can we verify that an app store ships the same code I have been shown?

Here is an idea of how you could verify the integrity of source code in a binary package:

Download the apk from a distributer, such as Google Play, and store the apk locally. Then compile the source code into an apk to create a sort-of identical version of the app.

Then do a binary comparison of 2 apk files and look for any differences and note their location. Then, disssemble both items with a tool such as IDA Pro and mnually check what the differences in the code are.

You can expect some differences, because the signing certificates wont match, but the underlying code should be the same, if not identical.

As an example, you might see that google version of the app has several functions that are not present in source, which can indicate some modifications to the original source.


A Web Application Firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation.
By making use of the rules many attacks such as Cross-site scripting (XSS) and SQL Injection, can be detected and blocked.

For a more depth description see the OWASP Website and Wikipedia.

When it comes to choosing a Web Application Firewall there is a good list on Wikipedia. Personally I would recommend ModSecurity when using Apache.

When choosing a WAF personally the two most critical things I would consider are how effective its default ruleset is (aka how effective is it out the box) and how customisable the ruleset is to suite your specific application. Most of the time by using the default ruleset applications will break and the ruleset will need modifying.
Obviously over things to consider are how effective its logging is, what sort of speeds it can handle, platforms it can support and how well maintained it is. As with any firewall its needs to be kept up-to-date to perform at its best against new attacks.

Although some IPS systems such as Snort do have rulesets that can monitor for Web Application attacks. In my experience I have found that an IPS is better for catching attacks at the Network level and a WAF with a good ruleset will work best for catching stuff at the application layer. Also by using a WAF you have a better choice of responses than you do with a IPS where you don't have to make a choice between block or allow instead you can take over actions.


Clarification on Cipher Suite definition in Wikipedia

In this case, they mean the same. The messages are the data.

Symmetric ciphers are much faster than asymmetric ciphers. If asymmetric ciphers were faster, we'd simply use them for all the data exchange.

But they aren't, so instead we use the asymmetric ciphers to agree on a key for a symmetric cipher. The much faster symmetric cipher is then used to encrypt the actual conversation - the bulk of the communication.


Is sending an Email without any PHI violates HIPAA privacy rule?

What if the email that is been sent only contain a link to login and nothing else ?

You are good to go. There is nothing to worry about if you send the mail which consists of link that asks the person to use login credentials to access PHI.

would the recipient email address itself would be considered as a PHI and violate HIPAA ?

Mail address is not health related data(so it doesn't violate HIPPA), it is a PII though.


Why is ICMP timestamping disabled on OS X?

The ICMP timestamp response contains the remote host's date and time. This information could theoretically be used against some systems to exploit weak time-based random number generators in other services


dangers of using WAMPServer on my home PC?

Port forwarding to your PC is almost always a bad idea. Also to run a webserver on the machine. If configured wrongly, which could well be the case, it could leak out a lot of personal information to the internet, in your case mainly to automated port scanners/attackers. Not to even begin with the problems of exposing a windows machine to the public internet (even if it's for single ports). If I were you I would either not forward a port and set up a local name for the server under which I could reach it, or at least set up the webserver on a different machine on the same LAN and port forward that - but not under windows, on linux or bsd. You could also use some cheap VPS and set up SSL certificates for a test domain to encrypt your traffic over the public net.

And don't trust random people wanting to look at your webserver, they could just as well look for easy targets.

TLDR: Close the ports! Think again if this is really what you want to do.
Consider more secure and more "state of the art" options than self-hosting
a public test site on your own PC.


can a x.509 certificate alone be used for user authentication?

What you describe is unworkable.

Without rewriting the SSL implementation on the client and the server, the client must have the private key for the exchange. The authentication comes from using CN as the identifier for the user - hence for webservers it contain the IP name of the server. For authenticating email addreses, the CN contains the ADDR_SPEC. What you put in your CN is up to you.

There is a further complication in your proposed method - the user must install the certificate, although this is not terribly complex.

You can't prevent a third party website from dreading the details of the client certificate if the user browses to that site (ISR that it is possible to restrict use of client certificates to specific sites, but don't remember the specifics). But they don't get to see the private key (via the SSL/TLS connections).

Your insistence on not providing the private key to the client makes any use of client certificates impossible.


Books, videos, and other resources for CEHv7

Check securitytube.net if you didn't already. It has tons of videos that will help you get a better understanding beyond just CEH.


There are a lot of free tools out there. You may not find a free tool with the exact same functionality as Burp, but you could use several tools to compensate for the limitations of Burp's free version.

use Owasp ZAP or Webscarab for their proxy functionality.
use Nikto and W3AF to scan web applications.
use SQLMap to exploit SQL injections vulnerabilities.
use XSSer to detect and exploit XSS vulnerabilities.
use Powefuzzer to fuzz parameters
use online encoder/decoders
use DirBuster to find hidden resources

All the tools mentioned above and several others are by default installed in recent Backtrack releases.

If you are looking for a tool that is closest in functionality with the Intruder, then I think that Wfuz with it's WebSlayer GUI is the one to try.


What shell binary should I use for the root account on a Linux system?

Depends. If there's a different set of attacks that can replace /bin/bash than some other files on your filesystem, then maybe there's a case for it. I used to make my root shell on Solaris a statically-linked /bin/sh. The reason was that /usr/lib was on a different physical disk than /, so in single-user mode it might not be possible to start a dynamically-linked shell. The fact that this also avoided touching any compromised shared objects was merely a side-effect.

In other words, if /bin/bash and your proposed alternative root shell are on the same partition, with similar permissions, there probably isn't much point. An attacker who can trojan one can trojan both.


How does LSA authentication on Windows work?

That diagram is very accurate for XP and previous. The reason it is so complicated is the several levels of abstraction involved.

There are two primary (as in, "most used") ways of logging into Windows - as a standalone workstation user, and as a member of a domain. In both cases, on XP those credentials pass through the LSA client and its server.

At the backend, then, LSA must determine "who to ask" to determine if the credentials are indeed valid. That's where the "negotiate" block comes in - which will do one of two things:

If the system is configured as a workstation, use the NTLM scheme as configured on the box and talk to the SAM database.
If the system is configured as part of a domain, talk to the server to see what it supports, and give it what it needs.

In essence, this process isn't all that different from negotiating what sort of hashing to use for say a HTTP authentication method: the server says what it wants (PLAIN, DIGEST, MD5) and I send the password as needed.

There is an allusion to other credential types fitting in here in the form of "msgina.dll". This is the component responsible for talking to the user after Ctrl+Alt+Delete and can be replaced to provide new UI such as fingerprint and smart card logon. In each of these cases, LSA must still talk to the backend database (whereever that is) to get an authentication token of some form.

You can also add extra authentication protocols to LSA via LSA providers. This is the corresponding "talk to the authentication database to determine if this is a valid user" component and you can read about these components here and directions for how to write one here.

Now, once this process is complete, the user is handed an authentication token called an access token. UAC aside, presenting this token is how processes indicate to the system they are already authorised to act on behalf of the user.

This is what is going on and how LSA and the various components fit together.

Now, part two of my answer. Flame targeted LSA for two reasons:

It is estensible. You can register new authentication protocols, new GINA/Credential Providers (XP/Vista+ respectively).
It runs on boot of the system, with NT AUTHORITY\SYSTEM privileges.

This makes it a marvellously good place from which to launch your malware and remain persistent on the system. See this analysis

As you can imagine, there are checks and balances preventing any old program from installing itself there and even being run there, by means of Authenticode. However, Flame used a stolen certificate to bypass this, which is where things got interesting. The information, specifically the Common Name, contained in the authenticode certificate is displayed as part of the authenticode warning dialog. So in this case, the malware would actually appear to be authored by "Microsoft Corporation". Once they click OK and run Flame with elevated privileges, it then has all the access it wants. It can then register itself as an LSA provider and will then be run automatically each time the system starts.


Can I prevent timing attacks with random delays?

This is actually a common misconception because intuitively, it seems like adding random delays should thwart timing attacks, until you think about it a bit deeper.

Theoretically, if the lengths your random delays are unbounded, ie drawn from [0, infinity] then it would thwart a timing attack for the reason that you suggest. In practice you A) don't want to make legitimate users wait an infinite amount of time for their login, and B) have to draw your random delays from some finite range [0, a]. This means that on average (ie with enough samples) you are simply adding a/2 to the time.

So let's say that without random delays you have the following timing profiles:

query existing user name: x ms
query non-existing user name: y ms

With random delays you now have (on average):

query existing user name: x + a/2 ms
query non-existing user name: y + a/2 ms

Since x - y = (x + a/2) - (y + a/2), the timing difference is still there for an attacker to exploit. The only thing that you've changed is that in addition to having to filter out network lag, cpu-scheduling lag, load-balancing lag, etc, they also have to filter out your intentional sorta-random lag. A successful timing attack will already be doing multiple queries for each username and averaging, but now they may have to add more samples in order to get their "clean" average.

Bottom-line: adding random noise may make the attack slower, but it will not make it any more complex.

The only real way to protect against timing attacks is to make sure that every possible code-path has takes the same amount of time.

query existing user name: x ms
query non-existing user name: x ms

Then there really is no way to tell those two apart.

Warning! Writing time-invariant code can be tricky, hence the maxim "don't roll your own". If you can find a login-manager that already implements timing-invariance, then using that would be both easier and safer.


The use of encrypted OAuth tokens is good approach to satisfying the security requirements in RFC-6749 section 10.  Encrypted OAuth tokens are in common use, Facebook is a good example.

OAuth tokens expire based on the expires_in parameter. Which means that a given token would be valid for a short time after the user logs out,  which is very low risk issue that majority of applications ignore.  Once the user logs out,  session riding attacks like XSS and CSRF should not be possible even if the OAuth token is still valid.


ASP.NET vulnerability CVE-2008-5100 (assembly signing bypass): is there a fix?

As far as I understand, this CVE is a dud. The strong name is basically a signature on the DLL, and the public key is identified by the "public key token", which is a SHA-1 hash of the key truncated to 64 bits. The core functionality of the "strong name" is to avoid clashes when several developers, who do not know each other, publish different DLL with the same name.

Strong names are also supposed to support a code integrity framework: a given application will reference a DLL by name, version and public key token; matching DLL will be found in the Global Assembly Cache. An evil attacker could try to load into the GAC a malicious DLL with the same name as a genuine DLL, hoping for another application (launched by another user) to load his DLL instead of the correct one. To do that, since the application contains the "public key token", the attacker will have to sign his Evil DLL with a key which matches the public key token -- and the public key token being a cryptographic hash, he cannot.

The CVE-2008-5100 is mostly about somebody noticing that signatures on DLL are actually verified when the DLL is installed in the GAC, not when it is loaded from the GAC. This makes sense: the GAC is protected from arbitrary alterations by the operating system. Thus, if the DLL was good on entry, it is still good afterwards. Or, more accurately, to modify a DLL which has been installed into the GAC, you need extensive administrative rights which make all of this moot: if you have that power, then you already own the machine in all possible ways. This explains the deafening silence of the Web about this CVE: it is a non-issue. It is like claiming that a lock which can be opened from the inside of a house is a security vulnerability, because a burglar who is already in the house could then open the door, and let... burglars come in ? See, when I use an analogy without the veil of technical jargon, the whole things becomes ridiculous.

So the report from the scanner is not appropriate. Your problem is to find the right way to shut it up. My recommendation would be to not use a "security scanner" which makes such stupid reports.

Now if we look at the details, there is something "suboptimal" in this "Strong Name" business; namely, the hash is truncated to 64 bits. This means that resistance to preimages is 264, which is high but still technologically reachable (an effort of that magnitude has been done publicly at least once)(apparently, a second effort of that kind has begun in several universities, to solve discrete log in a 128-bit elliptic curve -- to be concluded within an estimated ten years). An attacker could try to generate a public key which matches the public key token used for a specific DLL; if he succeeds, then he can make a fake DLL that will be accepted by applications, and for this he would only need "normal" access to the GAC (still not a worry if no potential attacker can open a normal user session on your machines).

Producing 264 RSA key pairs is expensive (not as much as you would believe because the attacker can make somewhat invalid keys, but still expensive) so I doubt this attack would be very practical, but the security margin is rather low.


Encrypting Data Without Sacrificing Query Performance

The problem is your solution:

"To maximize security we plan to encrypt each customer's data with a separate key."

Stop doing that.  Using a separate key for each customer doesn't scale.  Use a single key for the entire database.

Alternatively, encrypt the data using a hardware security module (HSM) before it's inserted into the database. Retrieve the encrypted data and then decrypt with hardware security module. Query performance will not suffer. Performance bottleneck is now move to hardware security module.


Is there a way to modify the value of a session token with HttpOnly flag set in this scenario?

Is there a way to change the value of SESSIONID when the victim access
the login page through attacker web server?

Nope. When the victim visits attacker's web server and loads the iframe, victim's browser directly establishes new connection (such as HTTP request) to the website inside the iframe, not by going through attacker's website first then the real website.


How safe is it to use developer's version of the browsers

Typically developer versions (called beta editions in the Software Lifecyle) are used to showcase upcoming features. Some of these features haven't gone through the rigorous testing as a stable (Release) version. To illustrate this, here is Chrome's explanation documenting the differences

  Stable channel: This channel has the full testing of the Chrome OS
  test team, and is the best bet to avoid crashes and other issues. It's
  updated roughly every 2-3 weeks for minor changes, and every 6 weeks
  for major changes.

  Beta channel: If you are interested in seeing upcoming features and
  enhancements with minimal risk, Beta channel is the place to be. It's
  updated roughly every week, with major updates coming every 6 weeks,
  more than a month before the Stable channel will get them.

  Dev channel: If you want to see the latest Chrome OS features, then
  you want the Dev channel. The Dev channel gets updated once or twice
  weekly. While this build does get tested, it is still subject to bugs,
  as we want people to see what's new as soon as possible.

What you can note are two things: Stable Channel "full testing to avoid crashes" versus Beta Channel: "minimal risk" and Dev Channel: "While this build does get tested, it is still subject to bugs" so you need to ask yourself: "Where is this beta going to be... What is the risk of using it?"

In production environments, betas are a no no, and are often contained on dev machines that are likely not connected to anything mission critical. If you're just talking about using something at home/hobbyist, you still should ask yourself what is the risk of someone finding a bug in a beta. What is the risk that perhaps my browser won't be a victim of a client side attack, and allow an attacker to get access to my connections/bank account information and so on.

Granted on the Stable side of the equation, bugs still make their way through however, these bugs are quicker to be patched than lower channels (beta, and dev). It all boils down to your tolerance.


No. Though reducing your direct exposure to the Internet with NAT does reduce some risks as long as you are on an Internet connected network there are many ways for attackers to reach you.

Examples of tactics that evade or ignore NAT (not complete):

application vulnerabilities in client/server (web browser) or peer to peer software (Skype) you run.
phishing emails or fake websites with malicious payload or links to attacker sites
"drive-by" malware embedded in ads on otherwise legitimate sites
IPv6 (if enabled) usually does not use NAT
attacks within VPN or GRE tunnels


How to safely connect a possibly infected computer to my home's internet?

Untrusted devices should be on their own, segregated network. Some wifi routers have a "guest" network, some separate the wifi from the ethernet. That's your best route.

Being on the same network means that any infection on the untrusted device can attempt to reach out to your own devices. The impact of that might be low, but that requires some understanding of the nuances involved.

Best case, put them on their own segment.