No, there is nothing all kernel exploits have in common.
Or at least, there is nothing unique to them and not present in standard, legal interaction with the kernel (such as using syscalls or accessing special filesystems). Typically, a kernel exploit involves making a syscall (an interface that allows userspace processes to communicate with the kernel) with arguments designed specially to cause unintended behavior, despite the syscall attempting to only allow valid arguments. Other exploits may involve concurrency issues (race conditions) between two syscalls. Let's look at a few examples:
CVE-2016-5195
This is better known as DirtyCow, and involves a race condition in the kernel's memory management, specifically Copy-on-write (CoW). Copy-on-write is a memory management technique that allows instantly duplicating a large amount of data, independent of how much data it is. When a range of pages of memory is CoWed, it is shared between two tasks. If one task modifies the page, only then is the page copied to allow it to be modified. That way two tasks can share the same physical memory while still not being able to interfere with each other.
The exploit involved a race condition with two syscalls, madvise() and ptrace(), between two tasks attempting to write to the same page. If a page is mapped in memory, and madvise(MADV_DONTNEED) is called, the kernel is told that the page will not be used in the future. Combining this with a ptrace(PTRACE_POKETEXT) call which writes directly to memory allowed modification of the original, read-only page due to the CoW bit being inappropriately removed. This could be exploited by writing to the vDSO, a small executable region of memory shared by all processes. If an unprivileged, malicious process were able to change the vDSO, then when it gets executed by innocent, privileged processes, those privileged processes could be compromised.
Both the madvise() call and the ptrace() call are benign actions. There is no reason to think that, by using them rapidly in a specific order, a page of memory in the kernel that is shared by many processes would end up becoming "owned" by a malicious process, allowing that process to change it however it wants. How could that possibly be detected?
CVE-2016-0728
This vulnerability involved exploiting a syscall, keyctl() for managing the in-kernel keyring facility. The bug involved an overflow of a reference counter, leading to the refcount wrapping around to zero. When a single keyring session is shared by multiple processes, the refcount is incremented. This is intended to allow the kernel to know when no one is using that memory anymore so it can free it.
Because of a bug in the kernel, there was as specific way to increment the reference counter without decrementing it afterwards, leading repetition of that action to increment the counter arbitrarily. Once this refcount leak caused the variable to wrap to zero, the kernel naturally thought that no one was using the object anymore, and that it would be fine to free it. However, there are still one or more tasks using that object when it gets freed. As a result, if they try to access it, they will be accessing unallocated memory. If the attacker then causes a memory allocation by creating another kernel object from userspace, and puts their own malicious data in there, the highly privileged kernel task that was previously referencing that memory area will instead access malicious code, resulting in its execution. This is termed a Use-After-Free vulnerability, or UAF.
Using the keyctl() system call and triggering memory allocations in the kernel are all normal, benign actions. How could such a thing possibly be detected without foreknowledge of the vulnerability? After all, the assumption is that a reference counter will not leak!
CVE-2017-1000112
The Linux kernel is able to "peek" at an existing packet of data without causing it to be removed from the receive queue, allowing a task to peek a bit of the data before actually taking it from the kernel. This is done with recvfrom(), using the MSG_PEEK flag.
A rather complicated bug in the kernel's implementation of UDP fragmentation offload (UFO) can allow an attacker who can set up a network interface with UFO to disable CRC checking, trigger fragmentation of a large payload, and copy a user-controlled number of bytes to another memory location. This can be used to overwrite an important struct with arbitrary data. A certain memory of this struct contains a pointer to a function, and if that member is modified to point to the address of malicious attacker-controlled code, the kernel can be made to execute it, compromising the system.
Configuring network interfaces is not a malicious activity, nor is disabling CRC checking, or using MSG_PEEK, but a specific combination of all this leads to overwriting a function pointer in the kernel, with devastating consequences.
Summary
It is true that many kernel exploits fall into just a few "classes" like UAF, integer overflow, refcount overflow, buffer overrun, etc., they all involve the system behaving in an unexpected way when told to perform a certain task. Whether or not this task is sane and should result in normal behavior, or is incorrect and should result in a returned error does not matter. The kernel is supposed to behave properly regardless of how one interacts with it, and the fact that there are bugs that allow completely legitimate interactions like telling the kernel that it's done with a page or creating new keyring objects to result in incorrect actions on the kernel's part is what can be abused by attackers. All interaction with the kernel should be defined, so even exploits attacking the kernel make use of defined but incorrectly implemented behavior.
There are, however, ways to prevent entire classes of exploits. For example, Control Flow Integrity (CFI) can be used to mitigate all forms of bugs that exploit out-of-order execution, like ROP. SMEP, SMAP, and grsecurity's UDEREF, while possible to be bypassed by leveraging additional bugs, can prevent all forms of unintentional access of userspace memory by the kernel, preventing exploits that involve modifying a function pointer to point to attacker-controlled userspace. These techniques cannot defeat all exploits as there are just too many, and they cannot defeat exploits using entirely new techniques (though thankfully those are rare).
Grsecurity is a company which aims to mitigate entire classes of bugs, and though it has shut down to the public (for only the time being, hopefully), there are still forks of it which are public. Many interesting exploit mitigations can be learned of by reading their last public patch source code.


Should a password based AES CBC encrypted string have extra security?

The ability to decrypt a portion of the ciphertext is not critical.

It is common practice, for example in disk encryption programs, to add a fixed (known) string to the ciphertext and thus check if the password fails.
Regardless which mode you are using, this would not be the critical point.

CBC mode has only one significant weakness:
CBC mode does not prevent tampering attacks, that means, an attacker who guesses a part of the ciphertext, is able to modify it according to its purposes.
If available, use GCM, EAX, CCM or OCB mode.


Apple ID scam, gave control of my computer for a few minutes

Worst case.

Strictly speaking, a machine where someone got to run something you don't know - whatever it actually did - is to be treated as "compromised", i.e., all accounts on it have to have their password changed, the data saved to backup before reformatting the machine, reinstalling the OS and restoring the documents - if you're really paranoid, the documents first need to be converted in a less vulnerable format (so for example all PDFs to Jscript-less PDFs, all Word DOCs to macro-less RTFs, and so on), and the backup virus-scanned from another, known good machine.

Also, any home banking accounts need to be re-secured, and all sensitive information (credit card numbers, emails etc.) checked and, if necessary, invalidated and re-issued.

Even apparently "innocuous" information might be used to impersonate someone even weeks after, and there are actually scamming "firms" that purchase such information from lesser criminals and "groom" them for weeks or months before striking (bottom line: you being scammed by an apparently innocuous "small fish" out of potentially sensitive information might end up, much later, with that information in the hands of those who can make the most out of it).
In its most visible form this is called "CEO email fraud". I have been personally involved in investigations in two such (much smaller, around USD 100,000) cases, but the latest case I know of is just days ago ("The CEO mail was false: 17 million USD lost"). So if you're involved with a large and possibly vulnerable firm (head accountant, books reviewer, CEO, lawyer, consultant etc.), take care to warn them. The market is so juicy that people are working hard at such heists.

Likelier (in MY opinion) case.

It is possible - I suspect "likely" - that nothing got compromised, and the guy at the other end of the line just typed some command like DIR /S or TREE to cause a lot of "computerish-looking" output.

The next step would have been to tell you that your PC had been infected, whatever antivirus you were using was no good, and you needed the new and enhanced antivirus from Apple Support.

Sometimes they also insist that if you refuse, they have no choice but to disable your Apple ID since it may be used to commit fraud, rape, arson, murder and rape.

At this point you are directed to a website where you can purchase said antivirus for a reasonable fee. And that is when you get it in the neck.

There several flavours of this scam:

"almost honest" scam: you are buying a semi-fake product that will also try to have you purchase additional plugins, enhancements, add-ons and so on.
credit card fraud: you enter your credit card details to make the purchase, and, well.
the application you're buying is not an antivirus at all but mainly a backdoor. Your system is now well and truly compromised, in addition to the financial damage. The backdoor access might also later be sold to worse criminals. Usually it gets immediate use as spam relay, cryptocoin mining and distributed denial of service, all services that are commonly marketed on the dark Web. It goes without saying that all interesting information on the machine will get pillaged (up to and including the worst case, above).


Why is forwarding port 80 more insecure than the others?

Forwarding port 80 is no more insecure than any other port. In fact, port forwarding itself is not inherently insecure. The security concern is that it allows services that are normally protected behind some kind of firewall to be accessible publicly. If the exposed service has any vulnerabilities or misconfigurations, it can and and often will be quickly exploited by attackers.

Seeing how a mix of other ports were allowed (notably 21 - FTP and 8080 - HTTP alt/proxy, which don't typically use TLS and could be considered insecure), it seems like the concerns aren't really security oriented, and are fallacious at best. Perhaps there is some business reason they do not want to expose port 80, but there is no valid technical reason I can see to disallow port 80 while allowing other common ports.


Hardware-based full disk encryption without pre-boot authentication

Disclaimer, my info is old, I haven't tried this in a while.

If the disks support hardware based FDE or Bulk Data Encryption, and you have an integrated lights out or similar capabiltiy on your server, you can try booting to this utility and executing a secure erase.

http://www.fitzenreiter.de/ata/ata_eng.htm

(not free for commercial use, etc.)

If I recall, the capabilities are not accessible after boot time by design.  This makes it harder for malware to kill your disk, or somebody from being able to steal your key or making it easier to bruteforce your harddrive password.

Check the cababilities of your disks in your manuals.   This might not solve your problem, but the site has a lot of information about how this ATA Security Extension stuff works.

Edit:  This has a good discussion about why what you're asking to do may be very difficult:

https://social.technet.microsoft.com/Forums/windows/en-US/01b843c3-3fb7-4c53-b51c-8693be591caf/how-can-i-prevent-windows-xp-sp3-from-sending-ata-security-freeze-lock-command?forum=itproxpsp


What is the difference between the "sig" files and the checksum files, such as on the PuTTY download page?

What is the functional difference between these file types?

Checksums ensure data integrity.
Digital signatures additionally ensure data authenticity.

When downloading a file, errors may occur during that process. Malware also could modify the downloaded file if you're machine is infected. The file's fingerprint (checksum) is there to tell you that the file is not altered.

An attacker may host a malicious version of PuTTY on his website and makes it available to download. Verifying the checksum in this case is useless: the only way for you to be sure that you did not download a malicious version of PuTYY is to check its  signature(s).

  Also, while I know how to check the checksums of the downloaded
  files, how can the sig files be used (on Windows)?

This is more a Super User question. You have there the same question as yours.


Is there a Yubikey equivalent to "stealing the hard drive"?

Short answer

Where would this data live on the device if not on something like flash storage?

It probably is flash, but it's put in a chip that's hard to take apart and examine without destroying the data you're trying to read. It's not impossible to do, but it's really quite difficult and expensive. It's not like a hard drive or flash drive where you can just remove it and plug it into a new computer.

Long answer
It is stored on a tamper-resistant solid-state chip. Most likely it is flash, but is designed in such a way that it's difficult to non-destructively remove the IC cover to expose the actual die (a process known as decapping). There are many ways to achieve this, but they can all be bypassed with enough effort. You should assume that anyone with a sufficiently-equipped laboratory will be able to break into it.
The usual way to read data from a poorly-protected IC (such as an 8051 chip with the firmware read-protect bit set) is to decap it with acid and then take a detailed photograph of the die. This makes it possible to reverse engineer the design and find the relevant components that will be storing the data you want. If you know where the data is stored, you can simply read the bits off it by examining the electrical properties of those components. A protected IC (like a TPM or Yubikey) merely attempts to make this more difficult. Many barriers are put in place to slow this down, to obfuscate the location of the secret data, and to increase the chances that the die will be damaged during decapping.
For example, see this discussion on forensic recovery from microcontrollers. It has this to say:

Decapsulating the YK4 and sticking it under an optical microscope reveals, well, not a whole lot. Pretty much every active part of the die apart from the bond pads is shielded by a metal layer that prevents the kind of visual inspection and simple UV tampering I described earlier.
One would have to de-process the device further using more exotic (and dangerous) acids or by wet lapping to reveal the true structure hidden underneath. These are destructive processes that render the circuit non-functional.
That’s not to say these types of defenses can’t be bypassed, but getting around such protections usually requires significant investment. Other types of mitigations focus on the detection of decapsulation by placing light sensors on the die itself to detect when the chips powers up after the molding compound has been removed. SIM cards often include an active mesh layer that can detect when a single trace has been cut.

Another technique to retrieve data is to use glitching attacks, which are made possible when the voltage or clock are controlled externally. If the voltage or clock are varied, it can induce glitches that may result in side-channels that expose secrets from the otherwise "sealed" integrated circuit. A well-designed secure storage system will make this nearly impossible, but new attacks are discovered from time to time. You can never completely rule glitching attacks out, but they may not be easy. If someone is going to decap the chip and expose the die and run it while beaming lasers at individual transistors and traces for fault injection attacks, there's not much they won't be able to recover.
Regular passive side-channel attacks (monitoring power usage, heat, sound, or radiation during processing of sensitive material) are easier to protect against. This can be done by using constant-time operations which take the same amount of time regardless of the data being processed, or with masking, which ensures that an operation takes the same amount of electrical power regardless of what is being processed. This is very effective and protecting against passive attacks, but glitching attacks as described above may force the system into an undefined state that violates the security guarantees provided by constant-time operations and masking, and could reveal secret data.


What servers or clients are immune to related-domain cookie attacks? (*.example.com)

I want to identify browsers, servers, or implementations that are immune from related domain cookie attacks (e.g. a.example.com vs b.example.com).

That is simple: there are none. It's a basic part of the design of cookies that a.example.com gets to write cookies scoped to example.com, that will be picked up by b.example.com.

There are browser differences in what cookies ‘wins’ when the same name is defined at multiple levels, and there is a difference in IE vs the other browsers in that IE will scope a cookie set at a.example.com to *.a.example.com if it has no domain, whereas other browsers scope it to only the exact domain.

  Lacking any tangible solution, could this mitigated by software that tracks and verifies each cookie's "type" and persists that.

Not directly. There is no way to read the domain/path/etc options from a cookie.

All you can do is attempt to guess at what level the cookie was set, and try to verify that by deleting the cookie at that level (by settings expires in the past). If the cookie disappears, you guessed right; if it's still there, try a different domain/path combination.


Is it a bad idea to forward a suspicious email with an attachment - even to a secure address for analysis?

Servers passing messages is really not a problem.

Your mail client has already opened the email so you forwarding it on is not opening your machine up to any further risk.

The mailbox to send these things to is usually on a machine that has strong security and sand boxing capabilities (or can be created on the fly as a VM)

If concerned, always delete, however forwarding on to your analysis team is essential if they are to understand it.


If you want to allow plugins, the only realistic methods to keep the parent application secure are:

Review the code

Only permitting submissions that can be reviewed and putting in place sufficient resources to actually do the reviews. The reviews can be automated or manual, a mix of both is undoubtedly best.

Review-only submissions also require some kind of official marketplace for plugins and you should also have the ability for end users to review and feedback publicly.
Apply a restrictive security model

You could ensure that plugins can only take certain, relatively safe, actions. For example, you could prevent them from contacting URL's outside of your own to stop them from "phoning home" and leaking data.

You could extend that further to allow less safe actions but only after a manual code review.

Doing both together is the best approach.

These are fairly common processes but obviously take time which equals cost. The second option is the cheapest but can also be the hardest to implement securely.

There are many examples of where this kind of thing fails badly, the most obvious being the Android app store where malicious apps are regularly discovered though all too often, only after years of being in the store. The Windows app store also suffered from this in its early days. As far as I can remember, each of the 3 main browsers have also had malicious extensions at some point.

To help protect yourself, you should only choose well used extensions that have consistent and large numbers of positive reviews. Preferably ones with well-funded support. Obviously you should keep the extension use to a minimum and something like Extensity for Chrome is good as it allows you to easily and quickly turn extensions on and off at will. Try not to use newly submitted extensions until you can see that they have been tried and trusted by others.

If you can, keep an eye on the news so that you may spot when an extension is highlighted either for having been independently security reviewed or when it has failed. And also watch out for extensions changing ownership as the new owners might not be quite so honest.

Realistically, most people are not going to be able to do those last recommendations though.


What are the major security differences between Chromium and Firefox?

Chrome handles web content of tabs (including javascript execution) within sandboxed processes. This means that even if Chrome's javascript engine has an exploitable bug such as a buffer overflow or memory corruption vulnerability which can be used by an attacker to get remote code execution, then the attacker's code still can't get access to the user's filesystem without another exploit against a second bug in the sandbox system itself.

Firefox doesn't use a process sandbox like this, so a single vulnerability in its javascript engine for example is all that's needed for an attacker to get access to your filesystem, etc. Firefox uses a single process for most of everything currently, which means that it can't make effective use of process sandboxing. There is ongoing work on this as part of the e10s project.


Are there any Common Weakness Entries (CWEs) applicable for hardware security weaknesses?

Yes. There is now the Hardware Design CWE View.
It lists CWEs such as:

CWE-1247: Missing or Improperly Implemented Protection Against Voltage and Clock Glitches
CWE-1248: Semiconductor Defects in Hardware Logic with
Security-Sensitive Implications
CWE-1232: Improper Lock Behavior After Power State Transition
CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic

Have a look at the view - specifically this page for the issue you mentioned. I believe it is still a "draft" at this point, but may be useful for you.


Answering title question: YES

Of course, this only really applies to cars with remotely-accessible electronic systems. So, most vehicles made before the turn of the millennium are probably safe in this regard. However, there are other ways to electronically "hack" a car if the attacker has physical access too.

Answer to "how hard is it": It depends

This goes for any broad category of applications - not just cars. It all depends on exactly how the software was written, what safeguards are in place, and how competent the people maintaining the code are. It also depends a lot on the competency and resources of the attacker.

Much of the answer to this question won't really be certain until someone discovers and discloses a vulnerability in the system. But then, of course, it's too late. You can only hope that the manufacturer of the system built in enough effective security to ensure that it will be a long time before any worthwhile and exploitable vulnerabilities are found.


What are the pros and cons of site wide SSL (https)?

Since most of the other answers here deal with the downsides of site-wide SSL (mainly performance issues - btw these can easily be mitigated by offloading the SSL termination, either to an SSL proxy box, or an SSL card), I will point out some issues with having only the login page over SSL, then switching to non-SSL:

The rest of the site is not secured (though this is obvious, sometimes the focus is too much on just the user's password).
The user's session id must be transmitted in the clear, allowing it to be intercepted and used, and thus enabling the bad guys to impersonate your users. (This is mostly what the Firesheep hubbub was about).
Because of the previous point, your session cookies cannot be marked with the secure attribute, which means that they can be retrieved in additional ways.
I have seen sites with login-only-SSL, and of course neglect to include in that the Forgot-password page, the Change-password page, and even the Registration page...
The switch from SSL to non-SSL is often complicated, can require complex configuration on your webserver, and in many cases will pop up a scary message for your users.
If it's ONLY the login page, and f.e. there is a link to the login page from your sites home page - what is to guarantee that someone won't spoof/modify/intercept your homepage, and have it point to a different login page?
Then there is the case where the login page itself is not SSL, but only the SUBMIT is - since that's the only time the password is sent, so that should be safe, right? But in truth that removes from the user the ability to ensure ahead of time that the password is being sent to the correct site, until its too late. (E.g. Bank of America, and many others).


What should I know about SPDY before enabling it?

SPDY has been reported to be vulnerable to the CRIME attack, but this will be patched in next protocol version. The specifics of CRIME target HTTP cookies, so the fixed protocol will do something special when compressing cookies (namely, it will not compress cookies with the rest of the headers; instead, it will use a dedicated channel to transport the cookie values, with a specific code stating "same cookie than previously").

As a general rule, encryption leaks data length, and compression (any kind of compression) makes the length dependent on the data byte values, thus increasing the information leakage. Encryption and compression don't mix well together. I personally would recommend not activating SPDY for HTTPS. For plain HTTP, however, go on; it won't make things worse security-wise than the mere fact of using plain HTTP.

It would be interesting to gather some hard data on the actual bandwidth benefits of SPDY. Google initially boasted about making page loading "55% faster" but this was in lab conditions. Actual speed-ups may vary quite widely on the kind of request that the site handles. As usual, there is no performance issue unless demonstrated by unambiguous measures.


Operating system encryption of a Virtual Machine

Depending on the Windows 7 version you have, you could use the built-in Windows BitLocker.

But please notice that this would be an additional encryption within the VM and not from your Mac's point of view.

See here for a more detailed description and a step by step guide for BitLocker


What Ubuntu packages are still affected by gnutls bug CVE-2014-0092?

According to Canonical's CVE tracker gnutls26 package is totally patched, while gnutls28 on Precise (12.04) and Saucy (13.10) are still affected, and others versions are not affected. There aren't any bugs related to fix these versions in Launchpad either, so, unless your are using 12.04 or 13.10 is safe to say that you are not affected by this bug.


Can I hook "vssadmin.exe delete" process?

Yes, but wouldn't you also need to hook wmic shadowcopy delete as well as other ways to do this?


The authenticate tag (M) should be as large as possible. The larger it is though, the more overhead for transmitting a single message. Generally you would want the tag to be at least 80 bits, which is 10 octets. Ideally, you should have a tag of 128 bits, or 16 octets, or M=16. A larger tag makes it more difficult for an attacker to forge messages without being caught. A 128 bit tag results in each forged message having a probability of 2-128 of being accepted, resisting a computationally-bound attacker.

The message size (L) specifies how small the nonce will be (nonce size is 15-L octets). You want a random nonce to be large enough the birthday paradox is not an issue. For this, 96 bits, or L=3, should suffice. This size is the standard used for GCM under a random nonce, which has proven to be quite secure. Since 100 messages per day over 30 years results in only a little over a 106 messages, it would also be safe to use a 64 bit nonce in theory, but 96 bits will prove safer if more messages are sent.

You should be generating a new session key using asymmetric cryptography each time the device is turned on. This will prevent an attacker who records messages from being able to retroactively decrypt them after obtaining a single master key as can be done with WPA and WPA2. This is referred to as forward secrecy, and ensures that an attacker cannot retroactively decrypt old sessions. Forward secrecy requires the use of ephemeral DH or ECDH for key exchange, rather than plain RSA.


Simple: You can't easily filter/censor/virusscan/log the content if the connection is encrypted.

So there's three general ways to react:

install an SSL interception middle box that decrypts, scans, and re-encrypts SSL connections. This requires cooperation from each client PC. (By installing the middle box's CA certificate as trusted.)
block port 443
shrug and give up. Just scan HTTP connections and don't scan HTTPS connections.


Distinguish between Wi-Fi Captive portal and MitM attack

About Chrome

According to https://www.google.com/chrome/browser/privacy/whitepaper.html

  In the event that Chrome detects SSL connection timeouts, certificate
  errors, or other network issues that might be caused by a captive
  portal (a hotel's WiFi network, for instance), Chrome will make a
  cookieless request to http://www.gstatic.com/generate_204 and check
  the response code. If that request is redirected, Chrome will open the
  redirect target in a new tab on the assumption that it's a login page.
  Requests to the captive portal detection page are not logged.

  You can disable navigation error tips by unchecking the box in the
  "Privacy" section of Google Chrome's options.

About Chromium OS

https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection explains :

  Shill, the connection manager for Chromium OS, attempts to detect services that are within a captive portal whenever a service
  transitions to the ready state.  This determination of being in a
  captive portal or being online is done by attempting to retrieve the
  webpage http://clients3.google.com/generate_204.  This well known URL
  is known to return an empty page with an HTTP status 204.  If for any
  reason the web page is not returned, or an HTTP response other than
  204 is received, then shill marks the service as being in the portal
  state.

  Many, or perhaps most, captive portals found in Hotels, Coffee Shops,
  Airports, etc, either run their own DNS server which returns IP
  address for all queries which point to their webserver, or they
  intercept all HTTP web traffic and return a 302 (redirect) response.
  The captive portal detection works very reliably with these types of
  portal to indicate that the service is not fully online.


Google accounts may choose to "never ask again" for a 2FA authentication on a "trusted" device, so even if 2FA is enabled for an account, it doesn't need to be "that" much active as your security policy assumes from 2FA.

So if you need to protect yourself from a compromised Google account (even one using Google's 2FA), you'll need to perform "some" extra step of authentication on your behalf. This could be implemented by adding and enforcing your own 2FA on your website, but doing so can also bring some hassle or confusion to your users.


Is it secure to store encryption key (encrypted with master key) with the data it was used to encrypt?

The real question to ask is "what is your threat model?" What sort of
  attack are you trying to prevent? Are you creating a digital lock on a
  diary to keep it safe from your sister's prying eyes, or are you
  Edward Snowden, on the run from several three letter agencies with
  billions of dollars of funding? AES-256 is currently labeled as
  sufficient to use in the US government for the transmission of TOP
  SECRET/SCI information. That's pretty much the highest classification
  level they could clear it for, so the US government is pretty darn
  confident that nobody can break AES-256 on the timescales required to
  protect our nation's greatest secrets. (Well, almost. What it really
  says is that they are confident that nobody outside of the US
  government can break AES-256. What you believe that that says about
  whether the US government, themselves, can break it depends on your
  threat model... and whether you engage in discussions of whether
  heavy-duty tin foil makes better hats or not)

Reference

AES key encryption is secure enough for keeping the data safe. In my opinion if the master key M is compromised, it can lead to decrypting all the key X. If you use a public key encryption to encrypt key X, only a partial of the data would be compromised. Say for example, there are two users U1 and U2, and there public keys be PubU1 and PubU2, private key be PriU1 and PriU2.

When U1 want to share his credentials with U2, the application uses PubU2 to encrypt the key X, so that when U2 want to access the data he will first decrypt using PriU2 and then uses key X to decrypt the data.


Is WhatsApp or Facebook Messenger secret conversation a reasonable method for transferring passwords?

Both Facebook Messenger (using secret conversations) and WhatsApp implement end-to-end encryption, which means that when you send a message your text is encrypted on your computer and decrypted on the destination computer. The text of your messages is not visible to anyone in between unless they break the encryption, which for practical purposes is not going to happen (unless you happen to be the subject of a national security investigation, in which case you've got bigger problems than sharing your Netflix password with the wonks at the NSA).

However, beware that end-to-end encryption only protects the communication channel itself. It does not protect you from threats such as:

Malware, such as keyloggers or screen grabbers that have been installed on your machine or the destination machine
Friends/family who decide to re-share or change your password without your permission
Netflix, who monitors these things and will see that your account is being used in multiple geographic places and thus probably being shared against their terms of service. Netflix has plans that allow multiple streams among family members, so this in itself is not an actionable issue unless your password is somehow shared widely.
Law enforcement, if you happen to live in an area that has criminalized password sharing
As pointed out by daniel in the comments, Facebook (who owns both Facebook Messenger and WhatsApp) might accidentally provide weak security or be complicit in breaking user security (e.g. in order to assist a law enforcement investigation). As proprietary applications (not open source) neither of these softwares have been vetted by outside security researchers, so Facebook might have a poor implementation or they might be copying/inspecting your data at either the source or destination device. Additionally, since these applications create and control the encryption keys used to implement the end-to-end encryption, you must assume that Facebook can break the encryption if they so desire (or anyone they would give the keys to, e.g. law enforcement).
Another excellent point from Gert van den Berg in the comments: some messaging apps will automatically back up to the cloud. The security around cloud storage is not nearly as strong as the end-to-end encryption used in the communications channel. See, for example, the Fappening attacks for more info as to how the cloud represents a threat to data privacy. (Even for supposedly deleted data!)


Bypassing XSS filter replacing characters?

Yes. This is exploitable in some browsers via UTF-7 techniques, and other older browsers via surrogate Unicode characters (some old browsers let you use weird "equivalent" characters for < and >, for example).

Don't use blacklist filtering. Filtering and encoding are hard problems and you shouldn't try to tackle them yourself. You need to be able to contextually encode content for the specific content type and context you're outputting content to. Consider using a library such as OWASP Reform, which supports PHP, Python, Java, ASP, and ASP.NET platforms.


Weird Log Record from researchscan1.eecs.berkeley.edu (169.229.3.91) - is this a hack attempt?

We're all being scanned by researchers at Berkeley.edu

Is this a hack attempt ?

This is a research scan performed by the University of California at Berkeley:

This is a research scanning machine from the University of California at Berkeley. This machine regularly conducts scans of the entire Internet so you may have been scanned as part of an ongoing research project.
The primary contact for this project is Bill Marczak (wrm at icsi dot berkeley dot edu) and the advisor for the project is Vern Paxson.
If you have been or are currently being scanned and would like to opt out, please email wrm at icsi dot berkeley dot edu with the IP ranges you would like to exclude in CIDR format.
If you have been or are currently receiving DNS requests, ICMP echoes, or TCP SYNs and would like to opt out, please email bjones99 at gatech dot edu with the IP ranges you would like to exclude in CIDR format.

Regarding your question, assuming the scanning machine is not compromised, then I don't think it's a hack attempt. It's probably just a check to see if you are hacked.
In many countries, conducting scans which attempt to hack random machines is illegal. An upstanding, well-known university would not be able to get away with breaking the law on such an epic scale.
You can opt-out of the scans if you like, or just block their scanners in your firewall. I've listed the additional scanner addresses at the end.

Legitimate uses for scanning
It's certainly possible that they're attempting to assess whether or not your machine is infected by a particular strain of malware. This is not the same as a hacking attempt. There are legitimate research reasons to know whether or not a machine is infected by some type of endemic malware.
When you read an article in the news which states how many computers worldwide are infected by certain types of malware, where do you think they get the numbers from? Scanners like these are one of the many different ways to obtain that data.

There are other scanners
Below is a list of other addresses they use
169.229.3.90 - researchscan0.eecs.berkeley.edu
169.229.3.91 - researchscan1.eecs.berkeley.edu
169.229.3.92 - researchscan2.eecs.berkeley.edu
169.229.3.93 - researchscan3.eecs.berkeley.edu
169.229.3.94 - researchscan4.eecs.berkeley.edu

Update with Response from Berkeley
I contacted the folks in charge, and this is their response:

We are performing a measurement study of a particular phenomenon on the Internet. To accurately asses the behavior we're performing a daily scan of the IPv4 space by sending a single benign packet to every IP on port 80 consisting of 64 random bytes of data. [...] No, we are not attempting to gain unauthorized access. [...] It's simply randomly generated data that conforms to a certain set of criteria.


Can someone obtain URL (or just domain name) by using IP destination address of a packet even when HTTPS is used

So your question asks if a URL or Domain Name can be obtained. The actual URLs in the session will NOT be be visible to the person observing the traffic if HTTPS is used because the encrypted session is established before HTTP requests are made to the server. The Domain Name of the public IP address can be obtained by looking at the certificate used in the handshake. Also, it is sometimes possible to find/deduce the domain name by DNS, however multiple domain names can be assigned to one IP address, so just going off the IP address isn't always fruitful. There are services that use Passive DNS to keep track of domain names associated to IP addresses, so you may look into that as an option.

ALSO, if this is your corporate network and you want to monitor activity on your companies machines, you can install your own certificate into your workstations and decrypt the traffic in a secure segment of your network, then encrypt it again before it leaves your network. This will allow you to observer all URLS, content, etc even if HTTPS is used.


Does higher range wi-fi mean less secure?

Technically, the WiFi network is no less secure with a stronger signal.

What your friend might be referring is that with a stronger signal, it will invariably increase the amount of people trying to hack into the WiFi network.

I haven't seen these ads but the "bonus" these ISPs might be referring to is to reduce the need for a wireless repeater to get the a stronger signal throughout a property.

Although unlikely, the ISP's might also be selling this as a method to create a wireless mesh network.


How should SSL traffic be treated once it has been terminated?

I don't think it really matters how your application handles the data; if an attacker can access your application's memory you're busted anyway, no matter what security measures you take. So after the connection has been terminated it doesn't matter how you handle it, but it matters how you store it.

The answer is that you should store it encrypted, but then the problem is how to keep the encryption key private: Where to store a key for encryption?

Besides this, I don't think there is much to it.


Error when using metasploit mimikatz module

Was running into this exact issue, and for me it was related to the process and architecture I was injecting into (using x32 instead of x64). After migrating to an x64 process, and then loading mimikatz, I was able to dump credentials as expected.


The security is not in the BLE technology, but in the way the company implements the solution.  Your best bet is to go with a door lock manufactured by a reputable security company that boasts a 3rd party vet the security of the device.


x86_64 is little endian so the mandatory zero bytes come at the end of the address/string and are already present in the existing return address.  That means you don't need to write those last few bytes.  You might still have problems if there were zero bytes less significant than the most significant non-zero byte.  These are best avoided by careful target selection.


What mechanisms prevent me from "ptraceing" a signed OSX application?

You should probably start with trying to debug the application with lldb to determine why you can't attach to the process.

System Integrity Protection

If an application is signed with the Hardened Runtime option, or is signed with Apple's own certificate (as Apple's official software is), System Integrity Protection (in the kernel) will prevent you from debugging the application.

If you tried to run such an application under LLDB you would see one of these error (not 100% sure why one versus the other appears):

  error: process exited with status -1 (Error 1)

  error: process exited with status -1 (cannot attach to process due to System Integrity Protection)

To get around this you could try either disabling SIP or removing the code signature (codesign --remove-signature application.app).

PT_DENY_ATTACH

A running process can also request that the kernel deny attempts to trace the process. If lldb shows an error like the following, that's probably what you are dealing with.

  Process 1234 exited with status = 45 (0x0000002d)

The most-common and safest way an application will do this is through the ptrace function call (although I've also seen it done through the syscall directly, which I've written about previously).

ptrace(PT_DENY_ATTACH, 0, 0, 0);

This is kernel-enforced so to get around it you would have to prevent the application from ever asking the kernel to deny attaching (either through the debugger or patching the binary). Historically there were also some kernel extensions to disable this feature, but I don't think any are still maintained.


gpg agent and caching symmetric encryption passphrase for writing

I also wanted to do this (with symmetric encryption, no keys) and Xen2050's mention of gpg-preset-passphrase was helpful, but I still was stuck on how to derive the correct cacheid to use with gpg-preset-passphrase to associate the passphrase with the encrypted file.

tl;dr the cacheid is the 8-octet hex-encoded s2k salt randomly chosen on encryption, prefixed with the letter "S", e.g. S0123456789ABCDEF:

/path/to/gpg-preset-passphrase --preset S0123456789ABCDEF <<EOF
$PASSPHRASE
EOF

See this detailed answer for instructions on encrypting, getting the cacheid, presetting, and decrypting with passphrase from variable (no prompts at all): https://superuser.com/a/1485486/1093343


Does having an unused Ubuntu print server running pose a security risk?

As I said in a comment. Is a good practice to disable always unused services. Printer services are as vulnerable as other services. I mean, it depends of the version. Some versions have exploits to gain access in the same way like Samba. You should have your systems updated and everything should be ok.

A couple of examples of vulnerable versions of Samba and print servers:

https://www.exploit-db.com/exploits/36741/
https://www.exploit-db.com/exploits/10/
https://www.exploit-db.com/exploits/7550/

To your question "Does the print server piggyback onto the samba protocol and that's why it shows up next to samba on the home net?", the answer is yes. Like in Microsoft machines, they are related.

Anyway, if from outside there are only access to ssh and sftp and if you have strong passwords and updated versions, you should not have problems. Anyway, nothing is impossible. :)


Internal code-signing certificate on Windows

You'll probably want to use the code signing tool as part of Visual Studio, and makecert.exe will probably be easier to use for cert generation. You'll have to make sure you get the proper cert template though otherwise the code signing will fail. A good source of information could be found here: http://msdn.microsoft.com/en-us/library/ie/ms537364(v=vs.85).aspx

If you store the code signing key locally the net security gained is pretty low. You'd really want to at least move it off to a secure machine, or possibly store it on a VM, on a removable disk, encrypted, and never connected. The problem with this though is that any time an app loads the DLL, Windows will attempt to validate the signature and try to verify that the certificate hasn't been put on a revocation list, which means an outbound call to an unknown location, causing blocking timeouts, which leads to awful performance and random things failing to start.

You'd probably want to stand up a full CA (gag) to get this all working properly. Alternative options are to get an actual code signing certificate from a trusted CA, and sign the DLLs using that. Though if those DLLs ever got out into the wild with your signature odds are good your cert will be revoked... eventually.

As well, if you're doing this to core Windows components then you'll likely just break your installation since the internal protections will freak out about the unknown signature.

Lastly, if you're doing this to certain non-Microsoft drivers or kernel-mode components, you might have a bad time because Windows hard codes CAs that can sign certs for certain components that have certain key usages. See: http://www.alex-ionescu.com/?p=146.


AP accepts packets from a machine not connected to it
  from arbitrary senders

Normally, deauthentication [and other management] frames don't have to be encrypted (i.e. require an existing authenticated 'connection' between the AP and the client). Therefore, they can be spoofed.

The way to protect against this kind of attack is to use Management Frame Protection (check out http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/82196-mfp.html#climfp):

  Specifically, client MFP encrypts management frames sent between access points and CCXv5 clients so that both access points and clients can take preventive action and drop spoofed class 3 management frames (that is, management frames passed between an access point and a client that is authenticated and associated). Client MFP leverages the security mechanisms defined by IEEE 802.11i to protect these types of class 3 unicast management frames: disassociation, deauthentication, and QoS (WMM) action.

What are the legitimate uses for deauth frame?

In addition to just that, termination of the secure communication (e.g. 'Forget this network'), there are a few possible reasons specified by 802.11, like these (reason/description):

2 - Previous authentication no longer valid
3 - Station is leaving (or has left) IBSS or ESS
4 - Disassociated due to inactivity

(you can read more at, for example, https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes or  )

Why is it that Access Points do not implement these Management Frame Protection mechanisms?

It is available in many APs, but usually "Optional" by default, to prevent client connectivity issues. You can read more in this answer: 802.11w protected management frames - Wi-Fi

Personally, I think that it is not such a big deal, because (a) strong PSKs make bruteforcing long and non-so-effective, (b) you can just wait for a legitimate client to leave and come back to catch the handshake. I.e. it makes it harder to get in, but doesn't prevent the possibility.


How does malware downloaded by JavaScript get executed, and why would you distribute malware in a .js file?

Even if the malware is successfully downloaded by the user, wouldn't he still have to execute it himself to infect his system ?

In the case that no exploit was used the malware has to downloaded and explicitly executed by the user. This is usually done via social engineering, i.e. declare the software as an software update or necessary plugin to view some illegal content, as an antivirus needed to resolve an immediate problem (scareware) or the malware is simply bundled with some software the user likes to use.

  In malicious emails, why would you send a .js file as attachment that'll download the malware rather than the malware itself directly ?

The current wave of malware in mails uses .js (or less often .vbs and .wsf) in an archive (mostly .zip). If the file gets extracted from the archive and executed it will not be executed by the browser but by the windows scripting host (WSH). WSH has not the restrictions and safety measures of the browser which means the WSH program can download the file and immediately execute it without needing manual interaction by the user.

Having a .js is more innocent than a .exe or .com as attachment and the chance that it gets blocked by the antivirus is smaller. And usually the .js files are heavily obfuscated and it is impossible to declare a fixed signature for the file or even have a reliable execution inside a sandbox. Additionally the executable file often gets served by the webserver with an innocent content type (i.e. claims to be in image) so that it does not get scanned by the firewall.


Generating and securely storing MFA/2FA recovery tokens

The backup keys essentially become equivalent to your password. The guidelines you are looking for are the same guidelines for storing your personal passwords. There won't be different guidelines.

The one slight difference between passwords and MFA codes is that you tend to need those codes very infrequently (maybe only ever once), and when something has gone wrong. That means that you need to follow the password management guidelines for "disaster recovery" or "business continuity" in business.

That usually means printing/writing them out and storing the physical media safely (locked, sealed, somehow obfuscated in case someone stumbles onto them) and in a way that you can access it when things have gone wrong. The details of this approach highly depend on the scope of "what can go wrong". Personally, I go with the earthquake/flood scenario where I lose my device and desktop and need to log into a new/strange device.


If there is an update available for your BIOS, then you should absolutely update it. Many vulnerabilities in firmware are found and only fixed through an update of the BIOS itself. Forgoing an update could leave you exposed to known vulnerabilities, including those that could allow malware to persist in the BIOS.


Your private key is never sent to the other site so it's perfectly safe to reuse the public key. It's also OK to reuse the same key your local computers. However, bear in mind that if someone steals the key, they then have access to all of them. This may or may not be a concern.


Is accidental credit card fraud possible?

Its is extremely unlikely for this to occur by accident.

If a magnetic stripe becomes corrupted then the checksum on it will let the machine know and not perform the transaction.

So this would require both the data to become corrupted and the internal checksum to be corrupted in such a manner that everything adds up.


Is it possible to get infected by opening an email in Android Gmail app?

TLDR

  Is it possible to get infected this way?

Yes, it's possible.
Is it likely? No.

Actual Answer

Let's take a look at your scenario from the attack surface perspective and also suggest methods to mitigate as much as possible.

First of all its a must to always keep your Android and Apps up to date with the latest version. For example, both Gmail App and the download component of Android have suffered from vulnerability in the past, though for the time of this writing there is no known vulnerability in both as far as I am aware.

  The email has been downloaded by the Gmail app in my Android phone (probably including the attachments).

A good attack surface reduction would be to disable the app auto-download feature of attachments. The following article should help.

  From reading the email on Gmail's app: same answer. Or it could contain malicious Javascript... although I'm not sure if Gmail's app renders Javascript or only html and css.

Although super paranoid, however, since its roughly possible attack vector, you can use a different app such as Thunderbird and view your emails without HTML rendering. Unless you work at a nuclear facility or part of UN human rights watch etc this is overkill.

  From the notification itself: yes, if the email body somehow exploits a vulnerability in Gmail's app or in Android. (Is there such a thing? Is this answer still valid?)

I can't remember an actual exploit/vulnerability taking advantage of the notification mechanism (this would be crazy difficult to exploit properly) but again from attack surface perspective you can disable notifications from the app.

  From the Word attachment: I guess again yes if it somehow exploits some vulnerability in the Gmail snippet function.

Similarly to my previous comments, no known exploits was ever found as far as I am aware in gmail preview feature but you can disable the preview feature from settings. This is a good practice to avoid miss clicking malicious links etc.

  Assuming the .docx actually was a virus, I guess it would focus on Windows and Word, not in some Android / Gmail vulnerability, right?

Correct, you are probably looking at a typical malware spam campaign.

  In this specific case, I've already deleted the email, should I do anything else? Reboot the phone or something?

In this specific case, it seems like you don't need to do anything, its not a targeted attack and its not focused on you or your Android. Though it was fun answering your other questions (:


Who can see the traffic of others in different kinds of LAN

Your assumption is mostly correct but not completely.

As you suspect, cases (b) and (c) are the same because it is of no relevance whether the switch is built in to some other hardware or standalone. So I will call both cases (b).

An ethernet switch will normally optimize the traffic flows so that packets are not sent to ports where they don't need to go. It's done with MAC address leaning and is the reason why the second copmputer will not normally see the traffic between the first computer and the Internet. But it's not a guarantee so you should never count on it. You should view it as an opportunistic performance optimization instead. There are situations where it will not be effective:

Soon after the switch has reset and before it has had a chance to learn MAC addresses.
If the number of MAC addresses that the switch sees exceeds the maximum number of MAC addresses it can learn.
If the layer 2 topology of the network has recently changed, packets might get sent to the port through which a MAC address used to be reached.
etc...

The first two of those situations will result in the switch sending packets to every port, just like with a dumb hub.

Furthermore, broadcast and (sometimes) multicast packets will still be flooded to all ports even when MAC address learning is in use. That won't affect the traffic between the first computer and the Internet directly, but the first computer can still easily leak important information this way through DHCP requests, mDNS advertisements, and so on.

  Is there any possibility (ARP poisoning/ spoofing etc.) where the second computer can see the traffic of the first one, considering case c) (and b))?

Sure. Using a switch instead of a dumb hub generally doesn't prevent such things as ARP poisoning or for example spoofing a DHCP server, unless the switch has specific security features to prevent it (and those features must be turned on, configured correctly, and managed).


This looks like more of a web-programming question than security  question, but my answer is that you would do it similarly to any other authentication request, namely with a username and password as part of the initial web request. You could follow this link on c# mobile authentication, specifically in the context of RESTful services (the answer seems to give starting points for multiple methods though, one of which should be suitable for your application) as a start.


You bring up a number of topics, but in the end only really ask one question. Let me address some of the topics mentioned briefly by referencing some of my other answers here.

  Last year there was several warnings that WPA2 is broken, hacked

This would specifically be referencing KRACK. While this was a major security find, the real world implications of this vulnerability are limited. See my answer here for more on my reasoning that KRACK isn't really a major concern.

  Now there are announcements that WPA3 is comming in 2018

I go through a number of details regarding WPA3 in my answer here. Feel free to check it for more information. The key point I keep making to people though is that while WPA3 is proposed by the the WiFi Alliance, to my current knowledge it is not in any way related to a current 802.11 amendment (which is the actual standard defining wireless networking operation).

  My wifi equipment has the possibility for RADIUS authentication. Should I implement it now, while waiting WPA3, or maybe RADIUS authentication could be permanently safe solution?

Now to your question. This is really a question that is begging for opinions as different people will have different reasons to say yes or no to it.

Let me say that this is something you must decide for yourself. 802.1X RADIUS authentications are much more secure than using PSK, however it is still using WPA2, so that doesn't change.

Keep in mind that security and usability are often at odds with each other. Adding the additional security of 802.1X authentication to your wireless environment will make it more secure. But you will have additional complexity in configuring your clients properly to take advantage of the extra security. Additionally, many consumer devices (game systems, media players, etc) do not support 802.1X wireless authentications.

In the end, you must decide for your environment if the extra effort/complexity is worth the extra security. For some it will be, for others it won't.


What are the alternatives for a bearer token mechanism?

There's HMAC/signature based authentication. With HMAC/signature, the secret token is never sent over the wire, but instead the message only contains the MAC/signature, which is valid only for that particular message and cannot be copied to a different message. The MAC/signature is calculated based on a secret token on the client machine and the hash of the message.

Most HMAC/signature based authentication uses software token, which is fine for most purpose, but if you also want to prevent the the token from being duplicated, you can also use hardware based token. With hardware based token, the secret token is kept on a cryptographic HSM which is not accessible to application code.


You might want to look at this answer as it bears on your question; in short, IPSec is overkill for single-port communication requirements and can be difficult for dynamic client environments.  SSH forwarding or sufficiently correct TLS is better for your use case.

That being said, I assume you're talking about Microsoft RDP, which has it's own innate encryption abilities.  While it requires some care to securely implement, it is possible to have a reasonably secure installation of it.  You should carefully consider whether you can achieve your goals with the native capabilities rather than bolting on outer layers; such hybrid solutions often have a hidden security cost due to their complexity.


A similar, but potentially stronger concept is to remove access to the tables entirely and manage all data access through stored procedures, as @CodesInChaos alluded to in a comment.

If a user doesn't have access to run SQL queries directly against the table, then you have complete control over the data that can be returned to the application.   The stored procedures in this model become an API for the database, essentially.


A security concern I dicovered with simcard devices

As you found out, a SIM card is only required for initializing a connection to the mobile carrier and is not required anymore until the device loses the connection and needs to reconnect (which happens very frequently with mobile devices when you move them around). Your device might power down when the SIM card is removed, but there is no good reason why it must do that.

But cloning a SIM card is not as easy as you think. Every SIM card stores an unique Authentication Key which is only known to the network carrier. This key can not be read through normal means. During the connection process, the carrier sends a random number to the device. The SIM card then uses a cryptographic function which takes that random number and the authentication key as inputs and outputs a new number based on these. This function happens inside the SIM card, not on the device, so the device never processes the authentication key. That number is then sent to the network carrier. The same happens on the carriers side, and when the numbers don't match the connection attempt is aborted.

The calculation is (relatively) cryptographically secure, so it is not (easily) possible to reverse-engineer the authentication from observing which random number gets which response from the SIM card. It has some vulnerabilities, though.


A blockcipher like AES is a keyed permutation. In the case of AES it takes a key and then turns a 16 byte block into another 16 byte block deterministically.

To encrypt something with a block-cipher you need to use a mode of operation. Typically those modes take an IV (similar to a salt) which should be different for each message you encrypt. This difference in the IV leads to a totally different encrypted message. Encrypting the same message with the same IV and key returns always the same ciphertext. Encrypting several messages with the same IV and key weakens security, but by how much depends on the mode.

The required properties for an IV depend on the chosen mode, sometimes it needs to be unique(e.g. for CTR mode), sometimes it needs to be unpredictably random (e.g. for CBC mode). But it generally doesn't have to be secret, so you send it to the recipient alongside the ciphertext, typically as a prefix.

There are some modes designed for deterministic encryption. Using those modes you still leak if two messages are the same, but nothing more. You should only use those modes when you require determinism.


How can I explain to the client that rfc2385 TCP MD5 Checksums can't be turned on for linux webservers?

Using MD5 for consistency checking is a clear violation of CWE-327: Use of a Broken or Risky Cryptographic Algorithm.  Any protection that RFC-2387 provided,  is voided by the use of an outdated, and insecure algorithm.

Rapid7 is making the internet less secure with this recommendation.  This BS "vulnerability" is more pointless noise that drowns out real findings.  Rapid7's blind recommendation of RFC-2385 makes HTTP request more difficult to process, thereby making the web server more pone to DDoS attacks.

I would complain to Rapid7, and encourage them to seriously reconsider this  cargo-cult security  recommendation.  Just because its easy to test for,  doesn't mean it is relevant.  Ask Rapid7 to tell your client that this isn't a concern.


What kinds of attacks are possible with credentials to a read-only Postgres user?

A few things:

Bugs

There are two sources for bugs here: Your role definition, and the database software itself. If you configure the role wrong, or the database software has a bug which allows people to do things they shouldn't, then... well, it depends on the exact bug, of course, but really anything can happen.

"I can constrain the contents of the SQL query"

Given SQL's complexity, that's a lot harder than I think you realize. Sure, it's possible, but there's really only one way to do it effectively: Make a query builder client, and build the actual query serverside. You might still introduce a SQLi vuln by accident, but it'll be easier to constrain than arbitrary SQL.

A better way?

I'm basically stealing this from Anders, but in my defense, I did also have the same idea independently -- funnily enough, even with the same inspiration.

In short, use a throwaway database. Postgres natively supports read-only replicas, where the data only ever flows one way, but if you want to be paranoid you could always set up a job to manually move files over. Postgres supports that, too.

Then, once you have your read-only replica, you can expose it to the world and basically not care about it. It's read-only at the database level, so there's no chance of any privilege bugs; your attack surface is now smaller. It's much easier to reset than your real production database -- just nuke and reinstall. You can filter out data you don't want them to see and entirely exclude it from the database they have access to. As a nice plus, because this is so well-supported by Postgres, it's really easy to scale up to meet demand. Likewise, if one of the servers gets DoSed, you can just tear it down and spin up a new one in its place.


Sniff Android and IOS app traffic for privacy audit

Have you installed the certificate from Charlesproxy on your Android/IOS device?
If no, the TLS handshake will fail, and you have no connection.
If yes, it is possible that the app uses Certificate/Private-Key Pinning. In case it's very difficult to intercept the connection.

For Android you can setup an Android-Emulator with root (https://www.genymotion.com/) and install the xposed framework. There is a Module too hook the validation-funktion. But this don't work for all ways of implementin certificat-pinning.

You can also disassemble the APK-file and patch the code. After that you can reassemble the code and install the app.


First:
No, as an attacker, in order to make your phone auto connect to a spoofed wireless network with the same essid of your 'home network', he needs your AP MAC address, which your phone is not probing, and also he must uses same security levels as your AP 'with the same keys'.
Second:
Yes, WPS is a vulnerability and it's been exploited by many tools. And sadly WPS is enabled by default on many APs.
Third:
Also Yes, you can crack WPA1 and WPA2 using a good dictionary attack, all you need is time and a well defined dictionary.


Cross-origin resource sharing is dangerous,  and more effort has been put into locking down the SOP than technologies such as CORS which bend the rules.  At the end of the day I don't want people reading my email because I'm visiting their website.  (They need to earn that right with an 0-day!)

CORS is strictly a JavaScript feature.  Although,  I hadn't thought of it until this post,  but why shouldn't CORS be used to break other SOP rules?   This can be implemented in a secure way, and more importantly it would be regular.

Can a domain access another domain without Ajax and CORS?  The answer is yes,  after all we had a solution to this problem before CORS.   Before CORS, there where two major ways that web apps broke the SOP.  The first method is to use a Cross-Domain Proxy which is a server-side component to fetch inaccessible content on behalf of the client.  The second method is XSS,  yes people actually intentionally implemented an XSS vulnerability for the purposes of resource sharing,  which is indiscriminate.  As a result CORS is strongly preferred over these methods.


Is it possible using a browser or other utility to export the CA that was used to sign a certificate?

The root CA certificate which is responsible for a leaf certificate is usually not sent within the TLS handshake. If you already have the CA locally installed in the browser you can export it there (details depend on the browser) but if it is unknown to the browser or system this is not possible. All you can get is the name of the issuer from looking at the issued certificate and then you have to find out where in your infrastructure the certificate has been issued and what root CA was responsible for this.


Does default ModSecurity protect enough against XSS?

You should review the XSS Street-Fight (with ModSecurity) Blackhat preso

It outlines the following ModSecurity mitigation strategies for XSS:

Input Validation (Whitelist/Blacklist Filtering)
Generic Attack Payload Detection
Identifying Improper Output Handling Flaws (Dynamic Taint Propagation)
Application Response Profiling (Monitoring the number of scripts/iFrames)
JavaScript Sandbox Injection (ModSecurity’s Content Injection Capabilities)


Does a drive need to be wiped before encrypting it to be completely safe?

SSD are almost always manufactured to actually have more memory cells than the advertised capacity. This extra capacity is used to replace failed memory cells so the drive maintains the advertised capacity during the expected lifetime of the drive. This is handled automatically by the drive's controller and normally isn't visible to the operating system.

What this all means is that unless you do an ATA Secure Erase and the ATA Secure Erase is implemented correctly (many SSD drives didn't implement ATA Secure Erase correctly), there's a chance that some remnants of the data may remain on the drive even if you overwrite the entire visible area of the disk with full disk encryption. Specialised forensic tool may thus be able to recover data from this spare capacity.

Whether or not this is a practical concern, really depends on the sensitivity of the data and what you're going to do with the drive afterwards. If you are going to immediately hand over the drive to a competent, malicious adversary, they'd be able to recover data from the spare areas. If you are going to actively use the drive for a while, chances are the write balancer would overwrite any remaining data after a while.


Is opening both TCP/UDP less secured than just TCP or UDP when needed and why?

So, SSH needs port 22/tcp.  You're asking if opening 22/tcp and 22/udp presents a security vulnerability.  The answer is "no" if nothing is listening to 22/udp. If some other application is listening to 22/udp, an application which you wouldn't want open to other hosts, then it could.  There are such combinations (syslog and rsh share 514, for example).

That being said, there's really not much excuse for not knowing which an application uses.  On Linux, for example, you can use netstat -tunlp or lsof -i to see which program is listening to which port(s), and tune your firewall rules correctly.


Is VRFY command enabled on SMTP server usually considered a vulnerability?

Yes, but often as part of a combination of vulnerabilities. For example, if you find a system that has a login (FTP, telnet, or other) that needs a username and password, and there's an SMTP server on the same network or even server, then the VRFY command  (can often give clues to the usernames that might work for brute forcing the login.

Sometimes these very 'minor' vulnerabilities, often leaks of information, can be combined into something more serious.

Unless there is a very good reason to have this function on an SMTP server, it's a good idea to turn it off.

Similarly, you could consider silently dropping emails to non-existent accounts so that the email server can't be used for user enumeration (bouncing off emails looking for failed deliveries), but this is controversial because it's sometimes more important to tell legitimate users that they have made a mistake in the email address (and with silent drop they wouldn't know).

And... it suggests that the server lock-down might not be as good as it could be and might be worth looking at a little more closely!


Based on which criteria is this outbound traffic being blocked? Only HTTP passes, on any TCP port?

It's certainly possible to block based on more sophisticated protocol detection than simply the port.

It's also quite possible that the traffic is being broken by accident. Domestic Internet providers will often assume that their users are doing conventional things and optimise their networks accordingly.

One useful test would be to establish a VPN from the B site and see if it works when it is tunnelled through B's ISP.


Why isn't stealing cookies enough to authenticate?

Technically, even if the contents in the cookie were to be encrypted, if cookies are properly copied to the new browser and the new browser sends the same HTTP headers (same user agent string, referrer is as expected, computer has same IP address, and all other headers the server could have previously stored and and compare against), the server theoretically wouldn't be able to differentiate between the original browser and the new browser.

I'm assuming that you're trying to copy the cookie(s) from a site that auto-logs you on every time you open your browser and you haven't logged out.

Some sites could use other ways to detect if this is a stolen cookie/session, but it's a losing battle because all those can still be spoofed E.g.:

Check if the IP address changed
Is the User-Agent the same
Check if the referrer makes sense
Any other HTTP headers that the browser sends

To answer your question, you should be able to make it work if you're dealing with an auto-login site and you haven't logged out. Make sure that all the HTTP headers your new browser is sending are the same, that the IP address is the same, the referrer is the expected one, same user agent.

Note that also perhaps the service you're using is using a 2nd cookie that you forgot to copy, and thus creates an anomaly and kicks you out.


Which brute attacks are more common? Ones that use dictionary words or random symbols?

Statistics on the attack methods aren't reliable. For example, we could say that a password like this-password-is-really-awesome-dude-believe-me is better than 3h8wnho9 because we could suppose that the average attacker would focus on 8-char alphanumeric passwords rather than long sentences, but is this assumption even true? We don't have a way to compute precise statistics. Also, in the information security field, the average case is often not very interesting. You need to consider lots of different cases and assess their specific risks for you.

So how can you choose a secure password if you don't know the method hackers are going to use to crack it? Well, you don't need to know how a hacker is going to try to crack your password, if you make sure your password has enough entropy. For example, if your passphrase has been generated by diceware and has 128 bits of entropy, then it won't matter if the attacker has a good dictionary or a good supercomputer, because they won't be able to crack it by bruteforce. Problem solved!


How can an outsider tap into communications between two physical sites?

The data bits which flow one machine to the other must travel in some way, over wires, optic fiber, radio waves or some other medium. At any point, information can be eavesdropped.

The very low-grade attackers will eavesdrop where it is easiest, i.e. close to either end. This is made easy with many WiFi hotspots; it can also be done with wired Ethernet by plugging into the same switch and "convincing" that switch to degrade to hub mode (i.e. broadcast all packets).

Somewhat higher-grade attackers will hijack one of the routers in the path. Each IP packet from machine A to machine B may have to hop through one or two dozens of routers. A router is nothing less than a computer in its own right (although most of them have a special packaging which makes them look like "network equipment"); as such, they have security holes (e.g. see this one, among many others). When an attacker gains complete access to the internal operating system of the router, he can spy on all the packets which go through the router, and also modify them arbitrarily.

Other attackers will plug in between routers. For radio links, this is as easy as having an antenna (some very directional high-frequency links can make that a bit more difficult). When the link is a simple Ethernet, this can be done even by amateurs. If you consider, for instance, a connection from Boston to Chicago, chances are that it will go through subterranean cables, long parts of which being just buried under a few feet of earth. These are not guarded and can be tapped into quite discreetly.

There are reports that some spy agencies have tried to do just that for at least 15 years, targeting no less than undersea cables, which requires a bit more work than just some night-time hiking and a shovel. Interestingly enough, what the NSA found hardest was to process the high bandwidth data (with the then available computing power).


Bash wildcards - Manipulate globbing to delete arbitrary files

I thought about the possibility that sticking a NUL byte (\0) to the path would cause glob() to ignore the part after the NUL. That's exactly how C strings work and filenames are passed to e.g. system calls as C strings.

But that doesn't seem to happen: on my system (Debian's PHP 7.0.27), both glob() and unlink() demand a string without NUL bytes, and error out if you give one. And any other character would be valid in file names, so glob() would have no reason to drop the rest of the path.

The possible issue with NULs is mentioned with an example in the online manual, so it's possible that some older version of PHP would have been vulnerable. Null bytes related issues:

  As PHP uses the underlying C functions for filesystem related operations, it may handle null bytes in a quite unexpected way. As null bytes denote the end of a string in C, strings containing them won't be considered entirely but rather only until a null byte occurs.


How can I do a maintainable and significant risk assessment in an organisation with thousands of assets?

There are many commercial asset management solutions that auto-discover assets and their relationships such as Service Now.

Then the discovery scans run daily or weekly on a schedule to keep it up-to-date.

Of course, nothing is perfect so it has to be put directly into the shoulders of the server and app owners to on a recurring basis and after any change control to update or fix any incorrect data or add missing data in the inventory.

For example:

a project can't go live until all systems, apps, and their relationships are updated
a new pc or server cannot be deployed until it's in the inventory
a system is decommissioned they must remove it from inventory

The risk assessor then should just be given access to the inventory but should not be required to maintain it


big O for finding hash of length n O(2^n) or O(2^(n-1))?

First, you misread the page: this is not about collisions. The Wikipedia page says:

  the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately O(259)

The important word here is "desired". The attacker wants to find an input that hashes to a specific, given output. This is called a preimage attack. By contrast, a collision attack is about finding two distinct inputs that hash to the same value, without any constraint on that common output value; this is not at all the same thing (and collisions are in fact vastly easier, down to about 230 evaluations for a 59-bit output).

That being said, the average attack cost is indeed 259, not 258, because this is a hash function, not a block cipher. You speak of "searching half the namespace" but there is, in fact, no such thing as a "namespace" in that case.

When you try to brute-force a 59-bit key, there is a defined space of possible keys (all 59-bit sequences) of size 259, and you know that one of them is the solution, and you can try them all in due order, without ever trying twice the same. Under these conditions, you can expect to find the right one after, on average, trying half of the possible keys.

This is not so here. In the case of CGA, the problem is about finding an input (which is quite larger than 59 bits) such that the output is a specific target 59-bit sequence. As you try various possible inputs, you get the corresponding outputs, but (that's the critical point) these outputs are (from your point of view) random (as in "random oracle"), and, in particular, you may get the same one several times. In fact, it is expected that you will get your first duplicate after trying about 230 inputs or so (that's the so-called birthday paradox), and, as you accumulate such random outputs, you will get more and more collisions. If you try 259 distinct inputs, and hash them all, then you will not get all 259 possible outputs, but substantially fewer (about 63% of them).

In other words, when you do the brute force attack on the hash function, some of your effort is wasted, because it yields 59-bit outputs that you already had with another possible input. This lowers the success rate, and thus increases the overall attack cost.

Assuming the hash function behaves like a random oracle (i.e. no known structural weakness), then the probability of finding the right 59-bit output every time you try some new input is exactly 2-59, and, by definition, this means that you have to try on average 259 times before finding a match. This is an average: you may get lucky and find a match earlier; you may also get unlucky and find a match later, with no upper limit. This (again) contrasts with the "search the key for a block cipher" situation, where you know that the attack will work after trying, at most, all possible keys; in the preimage attack for a hash function, you do not even get such a guarantee, only an average.


You do not need a passphrase for your RSA key. But if your key gets compromised (for example, because you carry the key on a thumb drive and you lose it), an attacker could immediately access the assets the key is protecting.

Using a strong password will give you more time to change keys in case of a key compromise.

Related question on Superuser:

Do I need to have a passphrase for my SSH RSA key?


Burpsuite accidental defacement, should I be concerned?

Number one rule of penetration testing: don't do it on things that don't belong to you. Yes, it is merely a spider. However, people think wget is a scary hacker tool and the US govt. actually used that in a case. I appreciate that you rectified your mistake, and I think that reflects well on you. You have a few options here, depending on your moral beliefs:

Honesty. Send the webmaster a note with what happened and how to fix it. This could go a few ways -- you either make a webmaster happy, you piss them off and get tangled up in it, or you get no response.
Run away. Act like it didn't happen. The website will chug on and no one will be the wiser. Of course, someone may notice your activities in the web log, and they most likely will not be motivated to track you down.

To be quite honest, both of these are decent solutions. And in the future, don't run Burp against targets you don't have permission to test on. It saves everyone's time :)


Are SSH certificates more secure for service accounts?

Lets break down your problem into three parts:

1) Identity provisioning: Ideally you should strive to provide an identity to each of your servicer at the time of deployment. This is generally done using leaf X.509 certificates signed by a CA which is trusted by all entities in your infrastructure. The private key of the CA should not be accessible to anyone. For kubernetes and most cloud vendors, this is achievable via some kind of Cert management service.

2) Authorization: This is an open area for creativeness. Even in large DC operations like google, state of the art is to maintain an authorization file which contains data like ACL (which service can talk to which service). All services pull this file from a central known location periodically and use them to provide access.

3) Certificate revocation list: This list is stored in a central known location where all certificates which are compromised stored. All certificates keep a local copy of CRL and update it periodically. The minimum time you keep the refresh, the window a hacker has is small.

Now during SSH call, your server needs to check following:

1) Incoming client has an identity signed by CA.

2) Is the incoming client authorized to access my service?

3) Has the identity of this client been revoked?

If you follow all the three guidelines, you can have a robust mechanism to secure infrastructure which can scale easily to several thousand services.


The fingerprint of the DTLS self-signed certificate is exchanged through the signaling channel with the offer-SDP and answer-SDP.

During the DTLS handshake a session key is established and the fingerprint of the endpoint certificates is compared to the fingerprint exchanged in the signaling phase.
Therefore, the certificate cannot be replaced without the endpoints noticing.

The signaling server needs to be trusted.


Why is this version of OpenSSL (1.0.1e) not vulnerable to Heartbleed?

As mentioned by @void_in, they backported the patch. Check your package version like so:

dpkg -l openssl

From 1.0.1e-2+deb7u5, the security patch has been included.:

  openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

  Non-maintainer upload by the Security Team.
  Add
  CVE-2014-0160.patch patch.
  CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or
  server.

The files relating to 1.0.1e-2+deb7u4 can be found here, and you should be able to revert back to a previous version of a package by adding entries in the /etc/apt/preferences file.


There is actually a solution that will always succeed: Program A will guess the opposite of the value it receives, program B will guess the same value as the one it receives.

You can also think of that as such: A guesses that they will receive different numbers; B guesses they receive the same. One of them is bound to be correct. If you look at the following table (r for receive, g for guess), you will see that either A or B is always right (* denotes correct response):

rA | rB | gA | gB
0     0    1    0*
0     1    1*   1
1     0    0*   0
1     1    0    1*


The Shadow Server Foundation constantly trying to get access to mDNSResponder

Assumption
Those websites are (for the most of them) well known honeypots.
They are designed to do lots of things, including luring bots into their networks.
I dont think the shadow server foundation scan random IP for information gathering. If you ended up in their list, there is some probability that your global IP have misbehaved, or did something suspicious.
Answer
Your global IP is not your mac, it's the WAN gateway of your router. With the info you gave, we just know that one or multiple device(s) inside your LAN might have somehow misbehaved. It can be anything with a private IP address obtained via your ISP's router:

Phone
Game console
Computer
TV
Connected refrigerator
tablet
IP Camera
And a lot more.

If compromised device(s) there is, you have to find it. You don't want to be part of a botnet.
A second assumption could be that someone hijacked your wifi and did some nasty things. A third assumption could be that your ISP is misbehaving, if it's the case you can do nothing about it, so lets stick to those two possibilities:

One or multiple connected devices you own are misbehaving.

You got your WLAN breached.

I will try to guide you on how to perform some further investigations.
Going deeper

Breached WLAN ?

Goal: Find a connected device on your WLAN you do not own.
How to: From your router, monitor IP Leases / MAC address for at least one week. Check the past IP leases logs.

Compromised devices ?

Goal: Find unexpected behaviors from the connected devices you own.(C&C server connection, weird port/socket/protocol utilisation, shadow server foundation IP / Domain outgoing connections)
How to: Capture all your router outgoing packets for at least 24 hours, analyse and filter the .pcap with wireshark or your favorite packets analyzer tool.
Good luck.


File extensions that should NOT be allowed to be uploaded

Let people store anything they want, rename the file to something random (SHA1 of random long number is enough), move them off the server root, and record the new name and original name on a database, taking care of sanitizing the filename.

List files using the original names on the filename (again take care with sanitization), and use PHP fpassthru or Apache mod_xsendfile to send the file, as both are able to read the file stored outside server root.

This way the client will not have direct access to the uploaded files, even files with invalid names will be safely stored.


Is kerberos unconstrained delegation partially safer than constrained delegation?

In short: no, unconstrained delegation is not more secure than constrained delegation (that does not necessarily prove the inverse either, but that's a different conversation).

You're conflating S4U2Proxy protocol transition with constrained delegation. Protocol transition is a mode of S4U2Proxy that lets a service request a ticket on behalf of any user without any evidence ticket. If you enable this feature then you've effectively delegated the role of domain controller to your application. This is not recommended for the majority of scenarios and is functionally orthogonal to constrained delegation. It also requires domain admin to enable by default.

Constrained delegation will not let you request a ticket on behalf of another user without that evidence ticket first. There's also an additional mode called Resource-based Constrained Delegation which flips the logic by letting the target service indicate who is allowed to delegate to themselves. If you compromise this service a user must still send an evidence ticket, and even then you can only request a delegated ticket to the approved list both the service and target have agreed on.


Are buffer overflows on websites stoppable?

Limiting text in an HTML form doesn't really stop buffer overflows because a bad actor can edit your HTML or not use it at all.

Buffer overflow vulnerabilities are caused by programming errors.  Programs processing the data on the server must, if using fixed size buffers, count characters as they're stored and store no more than the allocated number of bytes.  When the buffer is full, the program must either allocate more memory or stop accepting data.

For web sites, this means not writing CGI programs in languages like C unless you are absolutely, positively sure you know what you're doing, and maybe not even then.

If you are using a scripting language like PHP, the language processor can have buffer overflow faults.  About all you can do about that is keep PHP, web server (e.g. Apache) etc. up to date and read the bug reports.  Mostly at the programming level, one isn't dealing with fixed size "buffers" in those languages, but you should still check input lengths as part or normal data validation.

Secure programming requires that you make no assumptions about any data that comes into your program from the outside.  Instead you must validate everything.  Validate by checking for acceptable values, not trying to "enumerate badness."

Enumerating badness (Marcus Ranum's term) means trying to filter out the things you know are bad.  All the bad actors have to do is find some badness you didn't think of and you're hosed.  Instead, accept only those things you know are good and reject the rest.  If you mistakenly leave something out of the things to accept, your program will break and you will fix it.  That's far better than having a compromised system.


Unrestricted File Upload - Possible exploits

The specific files I would go after would be:

php.ini
PHP pages

These are very likely to have credentials embedded for database access or will give you clues as to where to look next.

my.cnf

MySQL configuration file

web.config

There may be some useful settings in IIS that can be retrieved by reviewing this file.

machine.config

Same as web.config but at the machine level.

Cache files

There could be some interesting data in the temp folder.

Those are the ones I can think of - once you start digging in these files, other ideas will probably emerge.

  Ending question: do you know other exploitation methods for the unrestricted file upload vulnerability if uploading a shell like above is not permitted?

You could try to upload a file that will be executed on next reboot or put it in a location that an admin may accidentally run the file.
You could perform a DOS attack by exhausting the disk space on the box.


Google Password Manager or Dedicated Password Manager

There is no right or wrong answer to this as "better" is a subjective term.
Things you should consider though:

Google Password Manager is not open source: This means it can not be audited by anyone outside of Google (are they stealing your passwords?... probably not, but who knows).
Bitwarden is open source: This means that members of the security community can audit it (does this ensure there is no vulnerabilities? no, but you can find them if you like).


For SAML 2.0 identity providers that support it you can pass ForceAuthn="true" as an attribute for the AuthnRequest. This will tell the IdP to not use any previous security context when authenticating the user.


how to validate PKCS7 signed message signed with a self-signed cert via OpenSSL CLI

#Try "-signer"
Add the "-signer" parameter.

Like so:

openssl cms -in demo.p7m -inform DER -verify -signer MYSIGNERCERTIFICATEFILE

EDIT: aint' working.


CAPTCHA enough to thwart user enumeration?

Yes!  In order for user enumeration in an account registration form to be at all useful an attacker will have to make thousands of automated guesses.  This vulnerability is not about informative error messages,  in fact even if you remove the error message you still cannot let two users occupy the same username.  By this general failure alone an attacker can determine that a username is in use.


Why can't we perform a replay attack on wifi networks?

Because the protocol is built to protect against that.

whereas when you wanna login to your wifi you would type in your password and the password would be encrypted then sent to the router which would decrypt it using a key

This is not how it works, on many levels. The password is never sent over the air, and it's a more complicated protocol, with multiple back and forth-messages - commonly referred to as a four way handshake.
It uses a nonce to ensure that the packets are not equal. The nonce is basically a random number added by either party to explicitly avoid replay attacks, by forcing the content to differ. The access point gives the client a nonce, and the client uses that nonce in further calculations. An attacker replaying the data would be betrayed by the fact that the AP can tell that it's not using the nonce supplied by the AP to the attacker.

Furthermore, if we have a look at the four way handshake, we see that neither party sends the actual secret over the air. They just prove that they know it for each other, so there's a mutual authentication.