Public Key Encryption instead of passwords

It's generally a good idea...

Asynchronous encryption comes with the advantage of not needing someone to remember a complex password. This is an upside because people tend to choose passwords that aren't complex or if they are forced to use passwords that are technically complex but are for real made up from their name, company name, some birth date and a random special char.

... But there are still some things you should think about.

Asynchronous encryption requires awareness too

You can of course give someone a pair of keys and a software that uses these keys but this won't make the connection more secure in any case. This is because in asynchronous encryption you need to keep the private key private but most people out there don't even know what asynchronous encryption is and they for sure don't know what a private key is and why they should hide it from other people. You need to educate them so they don't give the private key to anyone asking for it without knowing what it is or even putting it on a PC that is publicly accessible.

Asynchronous encryption needs to be implemented in a useable way

It relies on your audience if and how you can use it. If its mainly tech guys you can use it for sure and also in a way that requires some knowledge but if your audience is made up of people who think a String is a piece of underwear for women you might get in trouble using it.

You can observe this when it comes to online banking in the business area. Every time there is a new accountant who needs access to the online banking system they will call the IT guy because they aren't able to follow the instructions given by their bank to configure the client software which uses async encryption. So you'd better make it easy to exchange or update key pairs.


How can Insertion attack ever work and fool an IDS on a TCP connection?

The problem with some simple IDS/IPS devices is that they do not perform stream reassembly. They treat those two as different flows and throw the data away since they do not associate the two.

Luckily all modern IDS's perform stream reassembly. You can read about SNORT's implementation here: https://www.snort.org/faq/readme-stream5


Issuing and managing large numbers of certificates for client authentication

If you want to keep your budget down, I would recommend you look into EJBCA which is open-source and free to use, though a lot of the fancy enterprise functionality is in their pay version. They make the following claims about throughput:

  Since EJBCA uses standard relational databases, suitable for large scale and high performance you can easily scale EJBCA to hundreds of millions issued certificates, and with some care even billions. Depending on the architecture and interfaces chosen you can reach very low latency (sub 100ms) and very high throughput (>100 certs/sec). [source]

Though independent testing has found that this drops off pretty quickly when you get above 1 million certs issued.

Addressing the second part of your question:

  Is there any benefit to using a "real" CA to issue my server cert and generate my client certs for me?

It really depends what you are using the certs for. I know that a lot of Internet of Things (IoT) manufacturing processes use client certificates to allow the devices to authenticate to the corporate network during manufacturing to do things like first-time config, firmware download, and other things that you want to do securely. At the end of manufacturing, those certs are destroyed / never used again. In the case it's perfectly ok to use a private internal CA that is hidden from the outside internet.

If, on the other hand, the certs you issue during fab will remain on the device into production and need to be publicly verifiable, then that's a different story. [For example, if you make lightbulbs, and you need users' iPhones to be able to verify that they are talking to an authentic IPBulb, Inc lightbulb, or the bulbs need to be able to authenticate to a IPBulb, Inc server to periodically retrieve updates.] In this case you will need to have a public-facing CA that does all the key-update and revocation status checking stuff. This gets complicated fast and it may be worth your while to partner with a commercial CA just to avoid the hassle.

EDIT: Pulling in the comments bellow to make the Answer self-contained.

My reason for advocating to outsource your certificate issuance is mainly due to server load and response times when you have to deal with revocation and certificate updates. For most small-medium companies, it's cheaper to outsource this to a specialist than to hire top-notch datacenter engineers.

Revocation: The tricky part is that the server that's verifying the certs needs to be able to ask the CA "is this cert still valid?" and get a response back very quickly (like < 25 ms). This is called the Online Certificate Status Protocol (OCSP). As your infrastructure grows, a single OCSP server won't be able to handle the traffic, so you now you need live database replication, and load-ballancers, and good datacenter engineers to keep the response times low. This is beyond the scope of most small-medium companies, and cheaper to outsource.

For certificate update / re-issue: There's no problem with the client dowloading its new/re-issued cert before the old one expires, but you have to have servers that are actively managing this, that have certificate management ports open to the public internet (potential attack surface / hacking point). Also, for ~30k certificates all expiring in a short time-period of each other, the server load will be huge. Again, how good are your company's datacenter engineers?


Does adding dictionary words to passwords weaken them?

There's no problem with dictionary words to make passphrases; its a very good method of making a high-entropy password that you can actually remember. I recommend using four random words as a bear minimum; I typically use 6-10 diceware for to encrypt my ssh keys and encrypted password lists (about 80-128 bits of entropy if out of a ~7000 word dictionary or 100-166 bits with a ~100000 word dictionary).

If your password above was actually randomly generated from a set of 80 symbols and was 21 chars long it would have had an entropy ~132 bits.*

Yes, its well-known that you shouldn't use just a dictionary word (or two or three) with only minor modifications (capitalizing a letter or two; adding a number or random character at the end), as that will create low entropy passwords.

Your biggest worries with passwords are (a) password reuse (never share the same passwords with different entities), (b) passwords being logged or forced out of you (don't use passwords on systems where you may be keylogged), and (c) using very low entropy passwords (e.g., using a dictionary word with a couple numbers at the end).  I recommend using a password-management system like keepassx shared among your trusted computers in encrypted form, with a unique randomly generated password for each specific application you use; and encrypt that password list with a high entropy passphrase.

*As a digression, this specific password doesn't appear to have been randomly generated.  My guess was typed on a keyboard to generate it as two very unlikely patterns happened in the data:  18 of the 21 chars (everything but , K and x) came from the top two lines of the keyboard (keys from the bottom rows should have occurred about half the time),  and there was only one lowercase letter (should have occurred about 1/3 of the time).  For a truly random password these types of rare events (or worse; e.g., zero lowercase letters; or less than three chars from the bottom rows) should have happened only 0.07% of the time and 0.3% of the time respectively.  Granted you have to slightly discount that there are many tests to be applied (e.g., only left side of keyboard; etc).  Generating a non-random password potentially reduces the entropy significantly if the attacker can exploit it.


Encrypting user credentials using AES: how to hide the key

is it really necessary worrying about superusers? My gut feeling says no: in princible whathever the encryption method a superuser can read all the files and ultimately any kind of keys of the users;

Kind of. Even if the file is encrypted and the decryption is only done within the process the superuser has on most systems access to the process memory and can thus extract the decrypted data from there. Of course it takes way more knowledge to do that instead of just reading the plain file.

  is there a better way store a user profile other than encrypting it using AES or any other method?

That's not an easy question and depends a lot on the environment you work in, how you trust your users, how the overall security is, how sensitive the data are and maybe also a corporate policy or similar restrictions. If you don't trust the superuser or fear a system compromise then simply don't store and handle any sensitive data on the system. If users can be tricked into executing code on the system then it will not help if the files are encrypted but can be decrypted without user interaction...

In short: there is no general answer. There is no 100% security and you have to evaluate the risks in your environment and which risks are acceptable. Based on this you can then go the cheap high-risk way or the costly low-risk way or something in between. In some cases "better" means easier usability at the cost of a higher risk, in other cases "better" is low risk even if it causes usability problems and other costs. Having the key together with the encrypted data is definitely high risk which might be lowered but not eliminated by obfuscation of the key and anti-debugging features in the decryption software.


What's the difference between Anti-malware and antispyware?

Malware is a portmanteau of the words "malicious" and "software". Spyware is a portmanteau of the words "spy" and "software".

In terms of the words themselves, there's little or no difference between them. One might describe spying as malicious, just as one might say that a backdoor application has spying capabilities.

In terms of technical differences, spyware is a class of malicious software that attempts to steal some kind of information from your computer, such as your personal information (e.g. name, address) or your credit card number, keystrokes, etc. It could also be something less overtly evil, such as reporting statistics about your browsing habits back to an advertising agency.

Anti-malware software usually targets the broad range of malicious software. It looks for the stuff that causes damage, loss, unauthorised access, or annoyance - essentially what a layman would refer to as "viruses".

Anti-spyware tends to focus on less of the "delete your entire hard disk" types of malicious software, and more on the "this will steal your personal information" stuff, including the less overtly evil stuff that I mentioned before.

If you're wondering if there's any difference in how they work, there pretty much isn't. The monitor file and application activities and look for things that match a signature or heuristic, then block them or report them to the user.


Getting access to MAC address of access point from a device wired to the network

If the device is "evil" then it may contain a WiFi receptor and observe the message in the radio vicinity. It will then obtain all MAC addresses and SSID that it may wish for.

If the device is not evil to that point, but is only a casual, amateur evil, then it may still see the MAC addresses of devices that do WiFi with the "repeater". If the repeater behaves like most other repeaters, then it is a router (at the IP level) and the evil device will see frames (hence MAC addresses) only for the clients who connect to the repeater, not to clients who connect to the main access point. Moreover, WiFi-related features (e.g. SSID) will not be shown to the evil device, since it is wired. It is possible that the MAC address of the repeater itself, on the wire, will be identical to the MAC address used by the same repeater on the WiFi layer (some devices use per-interface MAC addresses, other use per-device MAC addresses).

Since all of this relies on some assumptions about the repeater, I suggest that you try it: instead of the evil device, plug a laptop computer and run a network monitor tool (e.g. Wireshark) to see exactly what frames show up on the wire.


I think this would be fitting:
CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.

Unless you have another exploit to access the computer, you'll need physical access. It's fairly easy to do and doesn't require PR or UI.
Let me know what you think.


Are auto-mounting hard drives a security issue?

Why are hard drives mounted by default in Windows OS, while they aren't in Linux OS?

Typical user-oriented GNU/Linux distros have automounters on by default.

  Is that a security issue?

More like a usability issue.

  If your computer was hacked, can unmounted drives be considered clean?

No, because the attacker could mount them, do his dirty stuff and unmount them again, and wipe the logs.  Only careful inspection of FS metadata will reveal when it was mounted (provided that the attacker didn't mess with it, which you likely won't be able to prove).


Security concerns with an ASP.net server error

Disclosure of ASP.NET Server errors is primarily an information disclosure issue

When this happens you are disclosing information about the technology in use.  If it's just the default errors (not the verbose ones) this is pretty limited, if it's the verbose one's you're disclosing stack traces and detailed ASP.NET version numbers.  The impact of this depends on other areas of your site's security.

If everything else is perfect, there's probably not a lot of impact, however where other security issues are present the verbose errors can be very useful to the attacker.  For example where an SQL Injection issue occurs, verbose errors can disclose the exact SQL statement in use, which is very useful to the attacker in exploiting the issue.

So really the exact impact is hard to say without knowing the details of your site, however given the fix is pretty trivial in most cases, I'd always recommend removing these on production sites.  Setting the Deployment Mode to retail is likely the easiest way to achieve this.


I think that an HMAC provides little added security if the session ID is something that is hard to guess. For example, a long secure PRNG. But if the session ID is simple to guess then there is the risk of session hijacking.

As the expressjs framework allows you to provide a session ID creation function that returns IDs with unknown security properties, an HMAC seems like a good strategy.

The default uses the uid2 library which looks like (I'm not a NodeJS user so I'm not certain) a secure PRNG (see source code). An HMAC seems of less value in this case.


Tomcat AJP vulnerability CVE-2020-1938 aka Ghostcat

The vulnerability is present in the binary interface that the AJP server provides, and will only be available to Apache HTTPd. Unless the AJP port is exposed to a public network, one cannot exploit it by simply issuing HTTP requests to Apache HTTPd.


Why does the CSR state/province name need to be the same as the CA certificate?

This logic is in the configuration (i.e. openssl.cnf) only.
There is likely something like countryName = match in it. It makes sense to have such policy for a company CA where the company is only in a single state (and such policy is often together with organizationName = match). But it does not make sense for a some globally acting CA which issues certificates world wide.
In other words: if such policy should be used depends on the use case and the configuration has to be adjusted to match the expected policy.


Whats the best way to make my internet traffic anonymous?

As far as hiding IP address goes:

Tor does provide a decent level of anonymity but creates its own set of problems, in particular Tor users are a frequent target for traffic sniffing and man-in-the-middle attacks due to compromised exit nodes (see How much can I trust Tor?), so I don't recommend it.

Instead of Tor you can use I2P, which does not suffer this vulnerability because it uses a predefined exit node (or the one you manually choose), and the exit nodes are usually well-maintained servers, so they're way less likely to be malicious or compromised.

VPN is easily tracked down by traffic analysis - tracking packet sizes, network lag and timings, etc. Tor is more resilient to that, and I2P is supposed to be even more resilient but it was not yet investigated as thoroughly as Tor was. Cryptohippie VPN also takes traffic analysis into account and adds additional layers of protection against it.

However, obscuring traffic origin is just a part of the problem.

A web browser is ridiculously easy to track using browser fingerprints, even you've disabled cookies, JavaScript, and everything else you can disable. Panopticlick explains what browser fingerprints are and demonstrates just how easy is, and it's not nearly complete - BrowserSpy.dk lists much more ways of tracking.

VPNs and anonymity networks do not (and usually can not) do anything about your browser fingerprint. You can reduce tracking, but not defeat tracking.

Here's one simple scenario to consider. Every time you browse the web without an anonymity network, the browser fingerprint is sent out there from your real IP. The fingerprint-IP pair can be recorded. If you browse the web with an anonymity network later, your browser fingerprint stays the same - others can still recognize you. Moreover, they may have your real IP address recorded. You're no longer anonymous.

It's enough to go online without an anonymity network just once to blow your cover, both in the past and future, forever (until you significantly change your software setup).

So remember you're being tracked, and NEVER EVER use the same web browser with and without an anonymity network.

In fact, this is not limited to web browsers. Other applications may have a fingerprint too (e.g. BitTorrent clients do), but they are not researched as thoroughly as web browsers were. If you're going to use an application via an anonymity network, be cautious about its setup and make sure it goes into the anonymity network right away, without contacting with the "non-anonymous" Internet even once. Otherwise your attempts at anonymity are in vain.

To avoid disclosing your IP by fingerprinting and not bother remembering which app should be anonymous and which should not (while every mistake is grave), I recommend running anonymity-oriented Linux distros, like Tails or Liberté. This way you'll be sure which programs are anonymous and which are not, and they won't be able to leak their fingerprints into the "non-anonymous" Internet because these distros explicitly prohibit any non-anonymous communications. It's possible to run them in a VM, but better do on a dedicated machine to avoid hardware-based fingerpriting and use better random number generators.

Finally, tracking may be not application- or instance-specific; user accounts on websites uniquely identify you (duh). If you want to stay anonymous, you have to access your user accounts via an anonymity network either always or never. The easiest way to do this is to establish a different identity for anonymous browsing.

Control your data online

Remember, you are tracked. You can reduce tracking, but not defeat tracking. And you leave a lot of info about yourself as you browse, from what your interests are to what places you visit to where you live. For example, search engine history tells a lot about you and sometimes can uniquely identify you. Some other websites collect A LOT of info about you or force you to disclose it, and what's worse, they often disclose it to third parties.

For a start, use an anonymous search engine: ixquick, startpage.com (anonymous Google with slightly outdated data), DuckDuckGo or run a local seeks instance to be sure. There are some search engines available inside I2P network too.

Social networks are evil. You can either not use them altogether or own your data by using Diaspora.

Online map services are not necessarily evil, but they get important info about you. I'm not aware of any anonymous map services, but of course I recommend avoiding Google Maps. Perhaps OpenStreetMap tracks less or doesn't track, but I haven't checked.

Same goes for email, IM, etc. Communicate via SSL'd and non-logged email and IM or use end-to-end encryption via a web of trust.

Finally, try to reduce tracking. Use a browser that supports DoNotTrack HTTP header and enable DoNotTrack headers in settings. Use some tracking-blocker browser extension. Use Mozilla Collusion to analyze and disable tracking. Use DNSCrypt if you don't want your ISP to know which websites you visit, or at least don't forget to check for DNS leaks if you're trying to use a custom DNS server without encryption. Remember you're being tracked at all times, no matter what you do to get rid of it. Read privacy policies. Be paranoid.


How to decrease the fraud level on SMS verification

im not sure you can prevent this using your current mechanics.
one solution has a timer on the code, but this is also easily thwarted depending on the bounty ($$) of that code.

Verification code mysite.com: 12345 Valid for 15 seconds.


Chinese hieroglyphs appear on screen when signing out of windows

Sorry to break it to you, but your system is definitely compromised. To be truly safe you must do a complete disk wipe.

Something you can attempt is a system restore. If you have a a restore point prior to the infection you can possible be saved. Usually one is created prior to Microsoft's second Tuesday of the month update. That being said it IS possible to infect this system restore, but prior to doing a complete reformat I'd advise at least checking into this option.

It is a significant risk to retrieve files from this infected machine, those files themselves could be corrupted. Files in the "My documents" folder or on the desktop are especially suspect to being infected. If you lift files be prepared to do a second disk reformat if the problem reappears.

If you do a complete disk reformat you're 99.9% safe. There are types of persistent malware which live in the bios but they are extremely rare (or from lenovo:) ).


The concept is that on a given "object" (say, a file), you have access permissions which detail who can access the object and under which conditions. The owner is an optimization: usually, among all the users who have permissions for a given object, one of them should have "all the permissions" and be generally considered as responsible for this object.

On Unix systems, traditionally, permissions on file are read, write and execute, and can be granted to three categories of users: the owner (a specific user), the group (each file is marked as being part of a group), and everybody else. This is a system which is not very granular, in that you can single out only a single user; rights for other users will be allocated on a group basis (at least). On modern versions of Unix, there are Access Control Lists which give much more flexibility, in a way similar to what is used in Windows. With ACL, or on Windows, any notion of "owner" is mostly an historical residue. On Windows, the "owner" of a file is any one of the users (or groups) who has "full control" rights on the file, but its purpose is mostly backward compatibility with code which predates ACL.

To sum up, ACL are sufficient for security and ownership is not required, but it often sticks around for interoperability with older code which does not know what an ACL is, but fiddles with "owner identities".


Remote PC shutdown security implications

One of the things that trouble me is that I failed to find anything related to security in that website, it sounds like a well intentioned hobby project that got exposure.

Yes, it opens a port and exposes a service. Knowing which port it uses is possibly very easy if you download it yourself, it is possible they don't randomise the port in use but even if they did a port scan would discover it fairly quickly. Then its a matter of playing with packets and see what sort of authentication is in place.

The immediate risk that I see is that the computer would shutdown or restart before you want it to happen, it seems however that this is targeted at home users where this wouldn't be much of a problem, even if it can be annoying I don't see a direct relation towards data loss or compromise, partly because it runs on Java and it is a sandboxed environment.

If you are concerned about security and need to use this tool, I would recommend not having the PC connected directly to the internet, you should still be able to use the program from within your home network, and if you want to be completely safe you can disconnect the internet cable from your home router.

The usual home safety recommendations apply, use strong encryption on your connections, if available only allow connections from specific MAC addresses...


How much stronger does a paragraph/sentence based password becomes with random characters added?

Use enough entropy then there's nothing to worry about.

For an 80 bit password just choose 8 random words.

Using your

correct $58j#O1, battery staple

technique with CSPRNG, assuming your password section is over the full character range (96 chars) then you have 10 bits + 6.5 * 7 + 10 + 10 = 75.5 bits.

These are both under the assumption the attacker knows your generation method. In reality they don't so this adds an immeasurable amount of entropy for an untargeted attack.


What is going on with my download of the recent Apple security update?

(The below is all speculation, I don't know how Apple's updater works internally.)

There are definitely architectures that can perform a secure update over HTTP.  Almost all Linux distributions distribute packages in plaintext, and verify them by verifying the hashes (SHA-1, SHA-256, etc.) from the repository metadata.  The repository metadata, in turn, is signed with a GPG key that your host verifies, and was installed with your original installation media.  (If your original install media was backdoored, all bets are off forever.)

So what does this have to do with your Apple update?  Apple could be using a similar scheme -- send a hash over HTTPS, download over HTTP, then verify the hash.  Software updates like this are a case where all you really need is integrity (I know some people would like confidentiality, but let's be honest, if an attacker sees you download X bytes over HTTPS from apple.com, and the latest apple update is X bytes, you've lost confidentiality already), and integrity can be achieved without sending the file itself over HTTPS.

In fact, this technique maybe preferable -- Apple could have a small number of servers serving update metadata under their direct control (i.e., URL and hash of the update) and then use a 3rd party CDN to distribute the update, reducing bandwidth costs, latency, etc.  If the update were served by the CDN directly over HTTPS without the verification step (i.e., all integrity is from HTTPS), then the CDN (or someone who compromises the CDN) could replace the update with a modified version.

Whether or not the duplicate ACKs are something to worry about is largely a separate question.  My level of concern would depend on a number of things: are they outbound or inbound ACKs?  What are the TTLs?  What are the sequence numbers?  It's really hard to say, but I suspect duplicate ACKs are far more likely caused by a network misconfiguration somewhere (even if not your network) than by an attacker.


Random Chrome Notifications and Strange Source Code

The site asks permission to send Web Push Notifications. That's not technically a malware and won't get detected as such. The site is just using this permission in a malicious way by sending these spam messages. That's pretty common.

Malwarebytes: Browser push notifications: a feature asking to be abused
Sites Trick Users Into Subscribing to Browser Notification Spam

  To remove them in Chrome, you can go into the Settings and search for
  Notifications, click on Content Settings, and then click on
  Notifications. Chrome will now display a list of sites that you are
  subscribed to or have blocked.

You must teach your parents some basic rules on the Internet: Don't click yes on everything. By default, select no if you don't understand the question. You could also tweak their browser to help them with this task:

Disabled web push notifications altogether by selecting Do not allow any site to show notifications from the Content Settings.
You could also disable location by selecting Do not allow any site to track your physical location.
Revise all Content Settings and disable everything your parents won't actually need.


Can any Android apps log my clipboard and upload it to their server without my permission?

Asking this question is like asking whether apps that you install on windows can hack you. The answer is that while the answer is supposed to be no, in reality it is a resounding yes. Somewhere in the world, there is going to be at least one hacker who can exploit Android's local AV systems. It's called spyware. So while it is SAFER to stick with the google play store, if you are concerned about this I would recommend installing a secure AV or switching to a more secure OS. And even then, you are never going to be ENTIRELY safe from spyware attacks.


This site uses a weak security configuration - SHA-1 signatures

EDIT - Updated based on comments from @AdmSelec below and info from GlobalSign

Whilst usually when that error pops up it'll likely relate to SHA-1 hashing, in this case it appears more likely that it relates to a bug in Chromium on OSX (details here).

Whilst the screenshot displayed doesn't show the certificate itself it does show information on the issuing CA indicating that it uses SHA256 and usually a CA will not issue a SHA-1 signed certificate from a SHA-2 signed Intermediate.

General Answer for seeing SHA-1 cert errors

The specific concern here relates to the SHA-1 hashing algorithm that is in use as part of your certificate.  SHA-1 was a commonly used algorithm for this in the past but it is now considered insecure, and modern browsers are starting to deprecate it (causing the warning your user is seeing), more information on the deprecation can be found here or here amongst others.

What you need to do is re-issue your certificate using an updated set of algorithms.  The instructions will vary depending on the company issuing it, but there are some pointers here which appear to include a reference for RapidSSL.

I'd expect if you contact RapidSSL support they should also be able to help.


Local network or local machine? For the latter, bind to localhost only for the webserver, database and such. If you are running the application in a LAN on a remote server, then HTTPS is not that strange. Depending on the threat you expect, create a access policy on the webserver.


You mistyped the URL:

http://drive.googe.com
http://drive.google.com
                 ^
                There

I confirmed that the redirect to router.php happens when you mistype the URL, and does not happen when you type it correctly.

Note that typosquatting (which is what this is called) is a serious security problem as you no doubt can see. Had the attacker simply showed a Google login, you would have given him your username, password, and possibly 2-factor token.

This is why you NEVER should manually type in a URL to anything remotely important. Use bookmarks or other similar references. And also use a password minder like lastpass, which will not be as easily fooled -- your password won't auto-fill on the wrong site, so you know that if the password doesn't automatically show up, then you're looking at the wrong URL.


Does using the same secret key for AES-256-CBC and HMAC-SHA512 in Encrypt-then-MAC potentially compromise the key?

This question is effectively answered by a variation of the question over on crypto.SE, here: Using the same secret key for encryption and authentication in a Encrypt-then-MAC scheme
The pertinent part of the answer is here: (emphasis mine.)

Potential problems with using the same key for encryption and MAC would be structural; [One] example is CBC-MAC, which is indeed identical to CBC encryption, except that you only use the last encrypted block as MAC. CBC-MAC works fine as long as you do not give to the attacker access to pairs (p,c): p is a plaintext block, c is the corresponding ciphertext block, for the key k which you use for CBC-MAC. But if you use the same key k for encrypting the data, then you are giving to the attacker a lot of such blocks.
With HMAC vs AES, no such interference is known.  The general feeling of cryptographers is that AES and SHA-1 (or SHA-256) are "sufficiently different" that there should be no practical issue with using the same key for AES and HMAC/SHA-1. However, simply defining that "difference" with any kind of scientific rigor would be hard, and it is not a much explored security feature. So that's one of these constructions which can be qualified as "no urgency to fix it, but don't do it if you can avoid it". A much "safer" way (in the sense of: "we know what characteristics of the involved algorithms we are exercising") is to take your master key K, and derive from it, with a good one-way Key-Derivation Function, a sub-key for encryption and another sub-key for the MAC. This can be as simple as applying SHA-256 on K and splitting the 256-bit result into two 128-bit keys.
There are some MAC and encryption algorithms which intrinsically support sharing the same key. This is exactly what happens in GCM.

So, the general consensus is that the security is ok, and you don't introduce vulnerabilities by sharing a key between AES and HMAC, but it is also general consensus that it isn't good hygiene to reuse a key for different purposes.  So what we resolve down to is that this construction is generally frowned upon, but there are no known or suspected security weaknesses at this time.


How is it possible to embed executable code in an image

The answer is simple. That was not a photo. And .pif is not an image format. Count on NYTimes to provide correct technical info.

As the log on NYTimes's article says, and as FireEye's actual report confirms, the file used was a .pif file. It's one of the less known of Windows's executable file extensions.

.pif is legacy from MS-DOS, like .com. It's intended to be a "program information file" (hence the name), storing a shortcut to a (DOS) program along with various info to the system on how to treat it. Even today, Windows gives .pif files a shortcut-type icon.

The funny thing is that, today, Windows doesn't really care if the .pif is really just a program information file. Try it: rename any .exe file into a .pif and run it. There might be some difference like the icon not displaying, but that's all. That's what uniform treatment of files of different formats gets you. Thanks, Microsoft!

Why does this happen? Short answer: Because Windows. Longer answer: Windows runs a .pif through ShellExecute, which technically should find a suitable program to open a file and then use it to open it. With .pif files, it first checks if it is really a file that points to an MS-DOS executable. If it doesn't conform to the .pif file format, ShellExecute checks if it contains executable code. If it does, it gets run as if it was a .exe. Why? Because Windows!

What did the suuper-scary genius hackers do? These guys didn't bother doing anything complicated: they made a self-extracting-and-executing SFXRAR archive out of a virus installer and a program (probably just a .bat) opening an image of a girl that they found on the internet, renamed that devilish contraption into a .pif file and sent it to the hapless freedom fighter.

Why did they use .pif? For two reasons, obviously:

Few people know that it can run as an executable file (thanks, Microsoft!)
It obviously sounds like .gif or .tiff or .pdf or something very image-y. Even you didn't doubt from its name that it was an image format, didn't you, OP? ;)

Concerning your actual question ("how is it possible to embed executable code in an image"). Yes, it is possible to execute code via a specially crafted image provided it is opened in a vulnerable program. This can be done by exploiting an attack like a buffer overflow. But these specific hackers were most probably not clever enough for this.

Edit

Interesting note: these guys actually used DarkComet, which has the ability to generate compressed executables with different extensions, .pif being in their list. I'm not sure about displaying an image, but this could be a functionality added in a newer version.

Another edit

I see you're asking on how to protect against this specific "vulnerability". The answer is simple.

First, make sure Windows shows you file extensions. Windows mostly hides them by default (thanks, Microsoft!)

Then learn this by heart: .exe .com .cmd .bat .pif .vb .vba .vbs .msi .reg .ws .wsc .wsf .cpl .lnk. These are the best known file types that can easily execute potentially malicious code or otherwise harm your computer if opened, whether you have vulnerable applications installed or not. If someone sends you such a file saying it's an image of a pretty girl, you can be sure it's another low-profile hacker like these syrian guys.

Another option is simply being pro-active and checking and double-checking any downloaded file with an unfamiliar file format. It could be malware, you know.

As for real images with exploits... you could probably try keeping your software up to date.


Source where you can find if a CVE has a patch or not

I'm not aware of any good out-of-the-box services, but I usually cross-reference with sites like:

SecurityFocus: It usually references CVE. Patch status filed under "Solution".
PacketStormSecurity: Allows fulltext search (can search for CVE ID). Patch status filed under "Mitigation".
OSVDB: Has an option to search with CVE ID. Patch status filed under "Solution".
IBM XForce: Allows CVE ID search. Patch status filed under "Remediation".


Is it ok to send roles and permissions data to the browser in a RBAC system?

It's fine as long as it's for convenience only and does not serve a security function. And if exposing that information does not create a vulnerability in your system.
Anything you send to the client can be manipulated and exposed by the client.
You want to ask yourself, "if I was malicious and I had this information, how could I abuse or misuse the system?"


How could you detect and defend against this type of (local) man-in-the-middle attack?

The result of this attack is not really different from someone compromising your router, your ISP, your VPN endpoint or similar:  the attacker will be able to intercept and modify the traffic.

Depending on the way the attack is done and depending on the characteristics of the line (i.e. FTTH vs. xDSL vs. cable...) one might detect changes to the line behavior like increased error rate, lower bandwidth or larger latency but if the attacker has done a proper job everything will look fine and nobody will notice.

Apart from the described problems with unprofessional hacks (bandwidth, latency) there will be no visible difference on the network layer if only passive sniffing is used. But if traffic modification is done you will notice it with protocols which have a built-in integrity check, like in case of HTTPS or VPN.

One defense against the attack would of course by to physically secure the line against the attack. But usually the line is not in your full control. The other way is not to defend against the hack itself but against its results: since the attacker wants to sniff and/or modify the traffic you should only use protocols with built-in encryption and integrity, i.e. send all your traffic through a VPN.


EDIT: I am leaving my previous answer for people who wonder about the same question but without the exact same symptoms. However, I have made a mistake. This is not an attack, it is simply an error. The URLs in question are legitimate and this problem is widely known. Thanks to schroeder for pointing that out in a comment.

Previous answer:

There can be several reasons for what you are seeing, to name a few:

There appear to be some vulnerabilities for the router you have. Since you mention your router is being managed by your ISP, I don't find it hard to believe that your router is not completely up to date. So It is possible that your router has been exploited remotely, and is now trying to redirect you to malicious sites (googlevideo.com instead of google.com, for example).
Someone has infiltrated your network in some way and is now trying to redirect you to a malicious site using DNS poisoning.
An attacker has modified your host file locally to redirect google.com to another IP. This is possible through compromising your own machine.
Some technical error that is not malicious, or has not originated from your network (for example, an error with your ISPs DNS server).


Why is Google using Local File Inclusion and Directory Traversal attempts on my site

It might be that somebody is including these links into his page for the Google bot to notice and follow. If you then block the IP address since it looks like attacks you will block the Google bot from indexing your site. And maybe this is what this somebody wants to achieve, i.e. make your site harder to find. It could be a competitor using Blackhat SEO methods or just somebody who does not like you. Another possibility is that this somebody later checks the Google index for the seeded URLs to find out if the Google bot found some interesting content there.

See also Google Bots Doing SQL Injection Attacks from 2013 for a similar problem.


Exploit Stack Based buffer overflow (x64) while controlling rbx register

What you can do when you control a register depends on what the attacked code does with that register. So it is hard to make a generic answer.

In the x86-64 ABI, the %rbx register is one of the registers that the callee must preserve, so if a function uses %rbx, it must first save it, and restore it upon exiting. A consequence is that most functions will not use %rbx if they can avoid it. In the 32-bit ABI, the %ebx register is typically used to save the address of the GOT (the base table used to do dynamic linking) so modifying %ebx could possibly allow fiddling with subsequent function calls; but in the 64-bit ABI, PIC code typically uses RIP-relative addressing, which does not use %rbx.

To see what you can do with %rbx in a specific situation, you really have to disassemble the attacked code and see how it uses that register (or not) in the instructions after your alteration.


SSL certificate fails to adhere to basic constraints and PCI compliance

The error report you link to states that the problem is in the lack of a "Key Usage" extension in a CA certificate (that is, a certificate which has been signed by an upper CA -- probably a "root certificate" -- and which is used to issue other certificates).

From the current X.509 Internet profile (this is RFC 5280, successor of RFC 3280 which itself obsoletes RFC 2459), section 4.2.1.3, the rules for that extension are the following:

when the extension is present, it restricts possible usage of the public key to exactly those listed in the extension;
usage of a key to validate issued certificates is called "keyCertSign" (so a CA which has a Key Usage extension must include that flag in the extension, otherwise things will not work);
conforming CA must include that extension in all CA certificates they issue.

So the lack of Key Usage extension in a CA certificate implies that the über-CA which created that CA certificate did not follow the rules (that's the third point, which was added in RFC 3280 in April 2002, so that's not exactly new). However, an application which uses that CA certificate without Key Usage extension is not entitled to reject the certificate path on that basis. Even though the Key Usage extension is lacking, the paths which include the CA certificate should still be validated by applications such as Internet Explorer, and indeed they are validated properly.

Resolution is easy for the über-CA: it just has to reissue the same CA certificate, with the same name and key, but this time with a Key Usage extension. This is a matter of a single signature, which involves, say, 1 millisecond of CPU time. Yet, since the lack of Key Usage extension does not prevent the CA certificate from "working", there is no incentive for the über-CA to do so (otherwise they would have done it years ago).


Which function to hash 128 bit API key with?

but what hashing key should i use? md5 or sha1 are not considered
  secure. sha256 produces bigger output than the key itself so it seems
  like it doesn't make sense to use 128bit key with sha256

It's okay for the output hash to be longer than the input being protected. Sha1 and Md5 are both deprecated for certain applications, so probably best to avoid those options.

Since you are hashing 128 bit keys you may be fine just using one round of sha256. This is based on the understanding that you are hashing random 128-bit api keys and not passwords. The advice for hashing passwords will be very different.


I am looking for feedback on Secure Development Lifecycle for Scrum that has been tested?

Very good question... SDL and Agile are often seen to be at loggerheads, though they dont need to be.
In fact, I recently gave a talk at OWASP about this (Agile in general, not necessarily SCRUM), and met with some skepticism at first... but eventually most were convinced of the possibility, at least.

I agree about MS's SDL, while I think its one of the best models for large companies, it is "heavy" (as I said in another lightweight SDL question), and has quite a lot of overhead. (though I dont think its academic, it just doesnt apply to most of us).

Without setting up a complete SDL here, and without context of knowing your org, I would say these are some of the important elements:

Training (which is already a big part of most Agile practices)
Map SDL requirements to Agile tasks, and allow the team to complete these themselves. It's not about passing your checkpoints...

Non-functional stories added to backlog
Completion criteria (sprint / release)
Product security requirements -> "ab user" stories

Frequency based "Wedges" (not wedgies)

Some tasks are one-time requirements, simply need to be completed like any other requirement
Some tasks are for every sprint - these are designated "Sprint Completion Criteria"
Some are only for public releases (some methodologies seperate the two, some treat every sprint as a public release) - "Release Completion Criteria"
Sometimes you might want to do a "Security Spike" - a whole sprint focused on different security aspects
MS idea of "Bucket" requirements seems nice, though I've never implemented it and would depend greatly on the culture/needs of the org. (Set up a group of req's with the same classification, or "bucket", and each time you need to choose one from each bucket).

This is just the general outline... Let me know if you want more detail. Of course, what goes into each wedge, and what activities must be performed when/how, really depends on knowing your organization, culture, needs, risk profile, etc etc.

I find the overriding change in concept from "Classic" SDL (or "Waterfall" SDL) that needs to be accepted is:

  "Classic” SDL was about control.
  Agile SDL is about visibility


Fear of mac Spoofing. Two Mac addresses appearing on Router page with only 1 digit variation

It is likely that your connectivity problems are because the new wifi networks are conflicting on the same channels. Change channels.

The reason why you are not coming up with answers on infosec forums is because this isn't an infosec issue, this is a basic networking issue. Many devices have the 2 MACs for a single device. There is actually a duplicate of t

By the way, the router does not modify your MAC for connectivity.


How to log into sites that you have set up Google 2 Step Authenticator if you lose your phone?

You can install Google Authenticator on another device. However, that new application will not have access to the prior secret shared between the server and your phone.

In Google's case, they recommend printing out backup passwords and keeping them somewhere safe in the event anything happens. It is up to other sites using Google Authenticator as a means of 2FA authentication to provide similar ways of recovering from such a loss. The HOTP and TOTP algorithms themselves do not allow for any recovery.


Appropriate way to encrypt passwords/financial info?

I would suggest to you trying KeePass. It is a password management utility that allows you to store username/passwords for several accounts.

As far as I am concerned, KeePass encrypts all your account credentials using a master password. This information is stored into a encrypted file. Then, you can send or share this secured file whenever you want.

I hope it fits to your needs. You may get more info http://keepass.info/


The warning is talking about "access to your Facebook account", not complete control.

Self-XSS works like any XSS. While you cannot read the httpOnly session cookie, you can:

read any data available to the attacked user (messages, secret groups, profile infos, etc)
send arbitrary requests in the name of the attacked user (send messages, create posts, etc)
display arbitrary data to the attacked user (fake messages or posts, phishing attackers, etc)


Yes, depending on the underlying database security a single SQL Injection attack can affect other tables in the same database and even tables in different databases or in very specific cases tables running on different database instances.

It is even possible to update/read from multiple tables at one time using a single database query.  Since you tagged your question as mysql here is a MySQL query for updating multiple tables:

UPDATE Books, Orders
SET Orders.Quantity=Orders.Quantity+2,
Books.InStock=Books.InStock-2
WHERE Books.BookID=Orders.BookID
 AND Orders.OrderID = 1002;

Reading is as simple as using a JOIN:

   SELECT t1.name, t2.otherColumn
   FROM Table1 as t1
   LEFT JOIN Table2 as t2
   ON t1.id = t2.id

Obviously the effectiveness of these queries will depend on the underlying table structure, but you can absolutely read from unintended/multiple tables using SQL Injection.

An example of when this would not be possible is if the tables in question all belong to different schemas, each with a specific account that can access.  Example:

app1.ImportantTable
app2.OtherTable
app3.BigTable

If each of these schemas is configured to only allow a different user access then there can be no unintended access.  So if there is a App1User setup in the database that can only read/modify the app1 schema, it will not be able to select data from tables in the app2 schema.


Does GOOD Dynamics Proxy comply with EU data legislation?

I am not sure what the concern is here. Presumably you currently use a mail provider that you send unencrypted mail through.

Or if it is sensitive mail, you'll encrypt before you send it, right?

Using Good, you'll be doing the same, but you will have some additional protection for the device itself, and some segregation of your corporate mail from the user's personal mail (ie no copy and pasting from corp email to their own one)

It also allows you to restrict access to applications - allowing users to use their own device to connect, rather than a corporate device. If your data is sensitive you may encrypt end to end anyway, but in any case you'll have a contract with the provider to detail what their responsibilities are.

As regards compliance, where a regulator asks you for your compliance information, those aspects you have outsourced are still within remit, so you need to be able to answer them. The only ways to do this are by requesting this information from the 3rd party or by auditing them.


Well I guess first off, what port are they going through your firewall and getting to the domain controller? You just need to make sure they can get through port 389 for LDAP if they are authenticating against AD. I'm not sure what else you are asking in regards to what traffic should be allowed from the clients, that's up to you to set the rules for your environment.

Personally, I'd set up a security group in your firewall/vpn appliance (assuming you have a vpn appliance or function on your firewall). Generate some certs from your internal CA and create a web login (some vpn appliances will have one built in already). Only distribute those certs to the people you want to access your network from outside of your organization. This is now limiting access to only that PC you originally wanted to do, since the cert can only be installed to one PC.


In short, yes and no. You can't completely remove blur but you can definitely revert some of the changes.

If you have a choice between blurring and blacking/whiting something out, go with the latter. Blurring essentially rounds and moves things around, and with the right algorithm for certain blurs information can be revealed. By adding a layer that can't just be removed, you've removed the possibility of somebody sorting the messed up information.

  Remember, you want to leave your visitors with NO information, not blurred information.

Sure, a face might be nearly impossible, but why leave a chance? It's surprisingly easy to deconvolute an image now, and who knows what could happen in the future?

Faces will probably be fine if you do it correctly (use your brain and don't just barely blur something), but for sensitive information just black it out. The government doesn't blur sensitive papers, they use thick black lines to censor it.

See: Blurring Images Not So Secure, Can we technically un-blur images?, and
Why blurring sensitive information is a bad idea


How is hibernation supported, on machines with UEFI Secure Boot?

Is hibernation compatible with UEFI Secure Boot?

For that you need to look at section 27 of the UEFI spec. In this specification, you will see a full explanation of the protocols in use. I'll briefly summarise them - this is a rough interpretation and might have loose edges (if you want a definitive interpreration, find one of the UEFI people :) ):

The EFI_AUTHENTICATION_INFO_PROTOCOL section defines a number of methods for getting and setting authentication information for a number of different implementations.
Signing UEFI drivers (support applications for the UEFI firmware). Since UEFI executables are based on the Windows PE image file format, you can think of this as comparable to authenticode for EFI modules.
EFI_HASH_PROTOCOL provides the programming API for hashing.
Then the juicy parts: firmware/OS key exchange. This is responsible for enrolling the platform key. EFI refers to two modes:

Setup mode
User mode
The former mode refers to a setup without an enrolled key, the latter to one with an enrolled key.

The enrolled key is the private key root from which image signatures will be trusted.
passing public keys to the OS firmware section is exactly what it sounds like - a protocol for notifying the firmware of a key it should use to talk to the operating system.
UEFI Image Validation refers to the process of checking a UEFI Image (bootloader etc) against a signature database.
The signature database is a list of valid UEFI images which have been signed with the platform key. An image must match a signature in the signature database to boot.

There is a reason for covering these EFI spec details is to point out that the UEFI Secure Boot spec covers to what extent UEFI secure boot extends - that is, it aims to achieve two things:

The UEFI Loader will only load EFI Images whose signatures are present in the signature database if UEFI secure boot is enabled and a platform key is enrolled (this is done by the platform owner).
The UEFI spec provides a means to communicate information between the operating system and the UEFI firmware to interrogate the signature database and EFI variables.

The important point here is that there is no requirement for an EFI Image, once loaded, or an OS Kernel once loaded to enforce signing on anything it subsequently loads.

For example;

Fedora will enforce signing all the way down for the kernel and respective modules - see this status update and this
Have a read of this article on the UEFI shim that came out of the Fedora EFI boot process. This shim can optionally have a UEFI variable set to disable signing checks on later parts of the boot process - like the kernel. In more detail
Ubuntu itself will not be signing its kernels:

  Therefore, we will only be requiring authentication of boot loader
  binaries.  Ubuntu will not require signed kernel images or kernel
  modules.

So, ok, let's get back to UEFI:

  Similarly, evil malware could presumably create a crafted hibernation file (containing a modified version of a real hibernation file, modified to insert malware into the running kernel) and then force a reboot. Upon reboot I presume this will load the hibernated image into memory -- which would seem to violate the security goals of UEFI Secure Boot.

Yes. This is a perfectly good attack vector for current operating systems and has its origins in the pagefile attack.

Both of these attacks work because the kernel (used to, in the case of the Windows kernel) blindly loaded data from disk back into RAM. Correct modification lets you alter drivers, install your own etc and off you go, ring 0 and one compromised system.

In a UEFI secure boot environment, the EFI firmware guarantees that your bootloader will not have been tampered with up to the point of shutting down the EFI firmware and proceeding to the operating system. That's about it. UEFI secure boot doesn't guarantee the loaded operating system is unmodified, or that the loaded operating system has loaded altered images from boot. That is up to the operating system to check and enforce.

Now some personal thoughts:

  Does it pose any security risks to the goals of UEFI Secure Boot

I suppose it does, in the sense that what you expect from UEFI Secure Boot is a sane state kernel. That's not what you're guaranteed to get, but it's what you expect.

  how are these risks being addressed in deployed uses of UEFI Secure Boot?

I think more accurately these risks are being mitigated across the board by code signing initiatives such as AuthentiCode. 64-bit Windows, for example, will not load unsigned driver code unless you perform a special dance involving F8 and boot menus. Most Microsoft images are signed and - I don't know but would guess - ntkrnlmp.exe is signed and validated by the Microsoft EFI bootloader.

As you can see, distributions such as Fedora have certainly adopted this approach as security of the system as a whole means little if you have simply got a verified bootloader.

The next stage of this process I suspect is to close attack vectors such as hibernate. For example, the page file attack was fixed by Microsoft. It is trivial to fix if you consider that you simply need a signed checksum which you can produce using, for example, one of the keys stored in the EFI firmware and verify in boot, either in the bootloader or the kernel.


If you are seeing repeated exploit attempts from a particular IP address it makes sense to block it, or better yet NAT it to a honeypot. Sure, many attackers will have a whole set of compromised servers they can try from, so blocking one of them won't stop them,  however it will force them to respond to you and may convince them that other targets are worth while.

Don't obsess over it though,  you could spend all day blocking IPs and there will still be a million more.


Is the typical hotel wifi authentication insecure?

As Julian said, the lack of HTTPS allows for man-in-the-middle attacks. He also mentioned access point spoofing, which are relatively common, especially in certain countries.

What else should I be aware of?

I'm of the opinion that authentication is the least of your worries.

Without properly-implemented https, a man-in-the-middle attack - which can be performed by a state-level actor (think Chinese government, GCHQ, or the NSA) - or anyone with access to the network you're connecting to - attackers can inject malicious payloads into the website in question. All of your traffic can be snooped and replaced with malicious content.

Imagine you request jQuery.js, but the website in question serves you jQuery-hacked.js. This hacked version of jQuery ends up doing everything normally, but also provides an additional feature: it loads malicious javascript which you wouldn't normally be receiving, which introduces a vulnerability or ten.

Even worse, since websites can check to see whether or not you have a Flash installed and running, along with it's version, there could be an injection of a malicious, albeit invisible Flash plugin into your webpage. I've experienced this attack in several places abroad.

At that point, it would not matter if you were behind seven proxies. Once remote code execution happens, or they use Flash to poll your unique hardware information, you're screwed.

Options to Help Protect Sensitive Information

Since this is a website about information security, and a lot of things we do here at our jobs include keeping information secure, then you should be aware of what can happen, and also take the necessary steps to avoid an information breach.

You'd do well to avoid all open WiFis (including hotels) unless you don't care about the device and it's contents. I personally use unsecured WiFi all the time simply because I don't care about the devices or it's contents, and also because I intend to study the spooky action going on behind the scenes.

Here's what I'd do if I had to protect sensitive information such as protected health information, personal information (customer data), or even government secrets:

Do not use public WiFi.
Do not use Flash. Ever.
Do not enable Javascript unless you have to. Also, use NoScript.
Use HTTPS Everywhere.
Do not use Java in your browser. Ever.


Is it correct that targeted attacks from highly trained and
  well-funded hacking groups are practically impossible to defend
  against?

For the average person, or even corporation, in my opinion the answer to that question is a resounding YES.

Have you ever seen the types of technology organizations like the NSA have at their disposal? Check out https://nsa.gov1.info/dni/nsa-ant-catalog/

Boom. Mind blown.

  Is there a rule of thumb for what the cost to attack vs. cost to
  defend against an attack is?

Not really.

  Is the cost to defend typically higher?

Defending can cover a very broad base of technologies and a very wide network footprint. It can be easy to fall into the "Jack of All Trades, Master of None" scenario.

An attacker can pinpoint and target specifically what they choose.

Defenders have to be right 100% of the time, attackers only have to be right once.

For these reasons I believe we can all agree that the cost to defend is typically higher.


You are getting hung up on the "life cycle" terms and not looking at the big picture.

PKI is a concept. It is the infrastructure for the idea of public/private keys along with the processes and protocols to make it work. It introduces the idea of a CA along with defining their responsibilities.

KMS is a product. It answers the question, "what do I do with all these private keys I have from the CA?"

PKI has protocols and guidelines for dealing with certificate life cycles, but a KMS actually implements life cycle management for specific keys for a specific organization using PKI standards.


It's not dangerous in and of itself, but I would still advice against it for two reasons:

It serves no purpose. If you want to make the session ID harder to guess, just add more random data instead.
It might be tempting to use the username from the session ID instead of fetching it from the server side session store or the database. This would be a security vulnerability, since users could impersonate each other just by changing a cookie.


Multiple running instances of rundll32.exe

It could be a virus, or could just be a program that needs to be run within a rundll32.
You could have more information on what's being run by using Sysinternal's Process Explorer : click on each rundll32, and see its properties, or which filehandles it is using (could be tricky determining what is legit, and what is not...)


Certificates do not by definition proof who is behind it. If you trust that 'source' is entirely up to you. This is why most 'secure' connections made with certificates are for confidentiality and integrity, but you still don't know who you are talking to. CAs do have rules that tell the certificate owners not to share the private key, but in practice that is very hard to check.

You can also go up the chain and say 'I don't know Coca Nuts Unicorns Ltd, but I do know the authority higher up the chain, Verisign for example.' If verisign is ok with it, maybe so are you? This is a slippery slope though, because CAs will hand you a certificate as long as you give them some money, some account info and a email address. You just can't be sure of who is behind that certificate.

There is a concept with certificates, extended validation, which does help you out there. The basics of that concept are that the owner had to get validated by the certificate authority.

  An Extended Validation Certificate (EV) is a certificate used for HTTPS websites and software that proves the legal entity controlling the web site or software package. Obtaining an EV certificate requires verification of the requesting entity's identity by a certificate authority (CA). Web browsers show the verified legal identity prominently in their user interface, either before, or instead of, the domain name. During software installation, the verified legal identity is displayed to the user by the operating system (e.g., Microsoft Windows) before proceeding with the installation.

See: https://en.wikipedia.org/wiki/Extended_Validation_Certificate


Heartbeat requests are intended for use with connectionless SSL over UDP.  A simple ping tells you only that the computer at the other end is up (or not); by including a payload, a program can associate heartbeat requests with specific transactions, detect dropped or out-of-order replies, and do other things that a simple "are you there?" can't do.

That said, I suspect the real reason that heartbeat requests have a payload is that they were modeled on ICMP "echo" requests, without understanding why ICMP echo permits a payload.  The ICMP echo payload is intended for low-level network troubleshooting.


How to prevent a specific program from reading my files?

I have not heard of any software providing this functionality but windows itself gives you two options

1) run it under an account (runas command)that does not have permission to access your sensitive files

2) run it in a sandbox/ virtual environment like hyperV or virtualBox so your sensitive files literally don't exist in the context of the program executing


Is using Google Forms to share “passcode protected” information safe from brute force attacks?

No, this is not secure at all. You don't even need to brute force anything. Both the password and the secret are right there in the source code of the form page. All you have to do is to use the "inspect" or "view page source" feature of your browser in order to see it. You can easily test this yourself by creating a form with a "password" and a "secret" and then doing a search in the source code of the form for the secret. The input validation feature isn't designed to be used for password protecting data, so it shouldn't be used this way.


What is the collision likelihood of MD5 when non-numeric values are removed?

Don't put too much faith in such anonymizing. Indeed, MAC addresses fit on 48 bits, out of which two are used for administrative reasons, leaving only 46 bits (at most) unknown to someone eager to recover the MAC addresses (indeed, the attacker can assume that the MAC address from a physical user machine will be "unicast" and "globally unique", so the two least significant bits of the first byte will be 0).

A good GPU will be able to compute more than 233 per second (see benchmarks here; the machine with 8 AMD R9 290X achieves more than 93 billions of MD5 per second); so that single off-the-shelf GPU can crunch through the complete 246 space in a couple of hours.

More importantly, recovering MAC addresses for tracking people makes sense only for an attacker who has known MAC addresses to track. The attacker needs not hash all 246 possible MAC addresses, only the few dozens (or hundreds or thousands or even millions) that he is trying to follow. A basic laptop, with no GPU at all, can do that in a fraction of a second.

That being said, the question you asked still makes sense mathematically. If we assume MD5 outputs to be "mostly random" values in the 2128 space, then each character in the hexadecimal string has probability 10/16 of being a digit, independently of the other digits. All the possible inputs will fall into one of the 33 categories for the 33 possible lengths for the resulting strings (0 to 32 digits). The probability of an MD5 output to fall into the category n, i.e. to contain n digits and 32-n non-digits, is:

Pn = (32!/(n!(32-n)!))·(10/16)n·(6/16)32-n

On average, if you hash k MAC addresses, you will get zn = k·Pn values in category n, and you can expect a collision when that number zn begins to get close to the square root of the space of possible values in that category, i.e. 10n. In other words, when k reaches 10n/2/Pn for some n, you are in trouble.

Let's get some numbers on that; the threshold for the various categories is:

n =  0  ->           42756232765793.7
n =  1  ->            2535132744529.3
n =  2  ->             310327495880.8
n =  3  ->              58880502453.6
n =  4  ->              15409365312.7
n =  5  ->               5220931252.0
n =  6  ->               2201337901.8
n =  7  ->               1124508269.7
n =  8  ->                682753416.9
n =  9  ->                485787572.5
n = 10  ->                400746570.8
n = 11  ->                380181578.5
n = 12  ->                412196472.8
n = 13  ->                508357082.1
n = 14  ->                710713497.4
n = 15  ->               1123736707.7
n = 16  ->               2006720463.1
n = 17  ->               4045452147.9
n = 18  ->               9210846925.9
n = 19  ->              23717908021.4
n = 20  ->              69233179091.0
n = 21  ->             229881262361.1
n = 22  ->             872338056547.2
n = 23  ->            3806833704700.6
n = 24  ->           19261224288561.1
n = 25  ->          114205011141017.5
n = 26  ->          804844014914874.4
n = 27  ->         6871878670370940.0
n = 28  ->        73015449033077408.0
n = 29  ->      1004393786461416580.0
n = 30  ->     19057032197633204000.0
n = 31  ->    560451732845470400000.0
n = 32  ->  34028236692093846000000.0

Bottom-line: when you hash MAC addresses with your "remove letters from hexadecimal" rule, you should see the first collision appear when you have hashed about 380 millions of addresses; it is expected that the first collisions will be for resulting strings of length 10 to 12 characters.

While 380 millions is still a large number, it is considerably below the values normally expected from a hash function with 128 bits of output; if you somehow kept the actual MD5 output, you would be safe until about 264 hashed MAC addresses, i.e. a lot more than is actually possible, since there are only 248 possible MAC addresses (246 in practice, as explained above).

Therefore, if you want to hash the MAC addresses, I warmly suggest that you do not remove the letters. Instead, if you must have digits and only digits, then use an encoding which keeps all the information. MD5 output is 16 bytes; the 32-character hexadecimal representation is just that: a representation. You could use an alternate representation which produces only digits. For instance, you could interpret the MD5 value as a big integer, and encode that in base 10. The corresponding Java code would look like this:

// MD5 output is a byte[], in variable md5out
String result = new BigInteger(1, md5out).ToString();

Since MD5 output is 16 bytes, the resulting integer will fit in at most 39 digits.

But remember what I wrote at the beginning: as an anonymizing system for MAC addresses, a hash function is not a very good tool... it will mostly thwart casual eavesdroppers, but why would such an eavesdropper be interested in MAC addresses anyway ? It is not an information that you can use "across the Internet". Competent attackers who are in position to exploit MAC addresses, on the other hand, will be able to see through such an anonymizing layer.


Solution to remain anonymous on a website that dismiss tor users?

Tor -> Startpage search -> view by Ixquick Proxy. This always worked for me the few times I've needed it.
or just use https://ixquick.com search engine instead of Startpage.

As for setting Tor up to do this automatically without the hassle, I don't know.


Is FeliCa encryption safe? Yes, but also no.

Yes, insofar as there doesn't appear to be any published cryptanalysis attacks against the cryptography employed by FeliCa.

No, because it isn't an open standard. This makes it difficult for cryptographers from all over the world to review and audit the function. Instead, Sony is relying on a small pool of experts, increasing the likelihood of there being a vulnerability that undermines the security of the system.

Caveat: I am not an expert on the FeliCa system.


What is your approach to handling Guest Internet access?

We provide an open guest wireless network that only blocks categories like porn, gambling and racist.  The corporate network blocks a little more, like social networking, but the guest network can't access internal resources.  Nobody gets "unrestricted" access, we always block sites categorized as malicious.  If there is a specific site categorized wrong we are willing to change it, but any site blocked needs to be reviewed individually.  If a vendor doesn't like it they can supply their own cellular network card.

All common types of VPNs are open outbound on our network.  In our environment if a vendor is on-site and needs to connect to their corporate network that's fine; if we didn't trust them we wouldn't hire them.

Auditors connect to the guest wireless network.  If they need data from a system they tell us what query or report is desired and we run it.  At no point are they given direct access to any of our systems.

To more directly answer your question, if the IT systems used conflict with a project that IT is not supposed to be involved with or know about I'd say that project needs their own internet connection.  They would also need to be off the corporate network if they are running independent of the main security system and I'd guess they are operating outside of your policies around system security (unless you have a lot of these and put it in the policy).


In Same Origin Policy, why are different protocols considered a security violation?

To begin, an ORIGIN is composed of Protocol + ResourcePath + Port, so http:// is different to https://.

The reason why the protocol is included in the origin is because the document/resource is served, potentially, from a completely different system. HTTPS uses port 443 by default, HTTP port 80 by default. Additionally, even though you can transfer a plaintext file via FTP (port 21) HTTP (port 80), HTTP (port 443) etc. etc. each of these protocols have very different protections and controls in place.

The security concern comes primarily from questions around provenance. Big word, I know. This means, simply, that content served over port 443 is KNOWN to have originated from the place saying so. It has a certificate to prove it, that certificate is tied to a particular domain name, and if no shenaningans have been taking place and the method used correctly, you can be really sure  that the content served over HTTPS came from who you expected it to come from.
This is not the same for content coming from port 80 via HTTP. In fact, HTTP was designed to allow midway points to cache, and indeed modify the data on its way to you.

Because of these differences, content served from different protocols is seen to be within separate trust domains, which do not necessarily trust the security of the other. For example, lets say you view a webpage serving content via HTTPS (the HTML) and content via HTTP (the advertising scripts and images). Cross origin prevents lower trusted objects (advertising) from reading higher trusted content (the balance of your bank account).

CORS, at its core (haha) goes back to the Bell - La Padula model which is widely used today to separate low security clearance from high security clearance interactions.


My subjective opinion is that these particular courses are not worth it for you.

These courses are expensive at $4,000+ per course. They are highly structured and compacted into a short time period. These courses are perfect for someone who needs to learn a lot quickly and will do well in a structured intense formal environment.

Based on the assesment test you appear to know a good bit of material. You don't seem to be in a hurry, and it looks like you are more interested in learning how to write good software than earning a certification or writing security papers. (I have a security certification, and I like reading security papers.)

In my opinion learning to write secure software is best done by writing software, having peers review it, testing it, discovering vulnerabilities, and fixing the vulnerabilities. Don't assume that it all has to be done for your employer. Follow announcements and news at OWASP or CERT.org or Dark Reading. Contribute to a honeypot project. Read and answer questions at security.stackexchange.com

It takes time for security knowlege to be collected, ordered, and formatted for classroom teaching. While some instructers will throw some of the 'latest developments' into their classes, most of the class will be well vetted security knowledge.

I think that the classes have value, just not for you.


Is it safe to allow untrusted field names in JSON?

There's no inherent security risk.

Of course, you remain at the mercy of the security of the library with which you are parsing the JSON, and you remain at the mercy of the security of the application which will make use of the parsed JSON.


Storage Encryption

I'm sorry. Encrypting the storage of your devices won't change anything about your internet activity.
Encrypted data has to be decrypted before you or your device will be able to access it. Every time.
This means that encrypted devices are just as insecure as it was without encryption if stolen while powered on and unlocked.
Nothing about this encryption of device storage will have any effect on your online security or privacy.
Encrypting storage will only make the contents of that device harder to access if someone should gain direct physical access to the device while locked.

Online privacy
True privacy is almost impossible online.

Your searches have to be readable by the search engine.
If you submit an unintelligible (encrypted) search query, your only results will be ones containing similarly unintelligible data instead of what you want to find.
Google/yahoo/duckduckgo can't perform useful searches unless you tell them what to look for.

Facebook and Google
Facebook and Google are two of the worst big-tech companies to track your every activity around the web. Even those who never created profiles with FB/Google have shadow-profiles. Created solely to enable tracking and sale of ID/gathered info to anyone who pays.
Tracking

Logging in with Google/Facebook profiles will kill any / all attempts at online privacy/anonymity until you clear all browser data/cookies and change any other identifying data-points they can collect...
The protective anonymity provided by VPNs/Proxies/TOR disappear when your browser still has Session/Ad/Tracking cookies from earlier when you load the first page containing tracking/social media/advertising content like scripts/widgets/buttons.
Example: Facebook like/share/comment objects that are embedded on any site will track users and send user info back to FB. Logged in or not.

For 100% security

For any data you don't want the entire world to see:

Keep it OFF devices with networking/internet.
Never upload such data to "the cloud" (Google Drive, Dropbox, Picasa/Google Photos, iCloud, etc.)

The only way tech-companies can't use your phone to spy on you:

Throw away your smart phone, get a dumb one.


Considering that SRP is better than SSH and Basic Auth, how can it be implemented in a website?

SRP is being implemented into SSL, so browsers are beginning to support it. Another option (albeit, much slower) is to run SRP in Javascript. Since the server supplies the javascript code, however, this is an attack point. So, it would have to be delivered over SSL, and the client must trust the server, which makes SRP with Javascript less than ideal.

There is more information on using SRP with OpenSSL, which seems fairly current.

For more information:
https://stackoverflow.com/q/2778629
http://srp.stanford.edu/download.html (includes patches for OpenSSL)
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Real_world_implementations
http://trustedhttp.org/wiki/Main_Page (has information on chrome and firefox support)


Books to study for GCIA (GIAC Certified Intrusion Analyst)

Speaking as a certified GCIA, the exams will be an order of magnitude easier with the courseware ("official study material") than with related books.  I've also certified GCFA, a couple other expired certs, and worked with the exam writing teams some number of years ago.  They are constrained to make sure that exam questions are directly supported by the courseware (for the obvious reason), so there's a distinct advantage to using courseware - if it's in the exam, you know it has to be in the courseware somewhere.

They used to sell it for something like $500; I understand they've stopped selling it online.  If you can physically get to a conference, or make an arrangement with someone, they do sell the courseware in the bookstore during the conference.  I don't think you need a conference pass to get into the conference bookstore, but I could be wrong.

You are correct that GIAC offers a Challenge exam.  You get practice exams with it, so if you wanted to prep with other books, that would give you an indication as to whether they were enough before you actually take the pass/fail test.

My advice: if you're looking at buying a $200 pile of books versus the $500 courseware, I'd consider the additional $300 well spent, given that the Challenge exam is $900 on the line.


You should avoid the "weak" cipher suites:

Cipher suites with no encryption (with a NULL in the name).
Cipher suites with 40-bit or 56-bit symmetric keys (DES, DES40, RC4_40, RC2_CBC_40)(3DES is fine, though).
Cipher suites marked "for export" (with EXPORT in the name: they are weakened to comply with pre-2000 US export regulations).
Cipher suites with no server authentication (DH_anon).

No sane software will enable these by default, or at all. But it is safer to check explicitly...

You may want to avoid RC4 because of the bad press (it still takes some millions of connections with the same encrypted data to hit the known weaknesses, which is not a huge security margin, but the attack is not really practical yet). Some people want to avoid CBC-based block ciphers because they fear the BEAST, but it does not work any more. Similarly, use of MD5 in SSL/TLS is safe, but the idea that "MD5 is broken" is so widespread that using MD5 tends to trigger questions and justifications and endless debate. In practice, your system won't be broken into because you used RC4 or MD5 or AES-CBC or any other non-weak cipher suite; we are in the realm of public relations here.

Among possible options, you should avoid compression unless you make sure that it does not apply to your exact context; this is because encryption hides data contents but not data length, and compression makes length dependent on the contents. In a Web context (HTTPS), this is called the CRIME attack.

If possible (depending on your server software and server certificate), try to use the DHE cipher suites: they provide Perfect Forward Secrecy. Said otherwise: if you use a non-DHE cipher suite, and some bad guy manages to steal your server private key, then he will be able to decrypt past connections (connections which the attacker observed passively, from the outside, before the actual key theft). PFS is about avoiding that. (But, of course, PFS or not PFS, it is much better if your server private key is not stolen at all.)

Don't use SSL 2.0. In practice, SSL 2.0 still offers some decent protection against passive attackers, but active attackers can play nasty tricks. If your client and server software supports SSL 2.0 but not SSL 3.0 or TLS (1.0 or ulterior), then your software is more than 15 years old and almost certainly has a lot of other problems.


Is my ISP hosting malware or has it suffered a sub-domain takeover, or is my router compromised?

Why you get the strange domain

Your ISP gives you an IP when you connect to the internet. There is a type of DNS record used to link an IP to a hostname (called a PTR record, which explains why the domains you listed all start with ptr). If you visit this site you can see your current PTR record.

Why the 3G internet does not have a hostname

It is possible your 3G IP does not have a PTR record.

Why are these domains treated as malicious

As you can see from the Transparency report, all subdomains of ip6.access.telenet.be are treated as mallicious.

This is probably because either:

Someone on your ISP deliberately hosted a malicious site and got the whole ISP flagged
Someone on your ISP got infected with malware which hosted a malicious site, causing the same effect

References

PTR Record | DNSMadeEasy


How do we cross-verify if the device is doing exactly what it is supposed to do?

There is a saying at my company:

  Quality Assurance is making sure that something does what it's supposed to. Security Assurance  is making sure that it does only what it's supposed to.

So unfortunately, I think your questions will lead you to a full security audit or penetration test, which, as you point out, requires great knowledge and skills which most people don't have.


What sort of steps can we take to definitively verify that a given rkhunter report is a false positive?

Why are you having rkhunter scan /dev?

If rkhunter works by calculating a hash on each file in a directory then comparing recent hash results against a database of original hashes, AND /dev is your device directory (so a non-normal filesystem), then /dev/shm is a shared memory device and not a static file.

Of course a hash on /dev/shm (shared memory) could be ever changing and producing alerts since it may not be static data.  As what's stored in that shared memory device changes so will its calculated hash change.

Consider prohibiting rkhunter from scanning some of these non-normal filesystem directories in Linux (such as /dev) by adding /dev to the preclusion list.

This has very little to do with your yum update.


How to implement WSS UsernameToken when password on the server is salted and hashed?

I am not sure which particular WS-Security spec you refer to. However, as far as I see, this spec (thanks to @logicalscope) only gives a suggestion as far as how to hash your password. In addition, the spec states that:

  Note that PasswordDigest can only be used if the plain text password
  (or password equivalent) is available to both the requestor and the
  recipient.

So in your case, the password is NOT available to the recipient. Only the already-hashed password.

Another important point to note is this comment on the spec:

  However, unless this digested password is sent on a secured channel or
  the token is encrypted, the digest offers no real additional security
  over use of wsse:PasswordText.

I would suggest using plaintext PasswordText but ensure the channel is, e.g. SSL protected (if you haven't done so anyway). This way you don't need to change the way your passwords are stored, you can hash them any way you want, and the password is still transported securely from the user to your app.


Is there a name for using a web site email feature to harass someone or the site?

As far as I know, the attack that you described is known as "Password reset email spamming", "Password reset email bombing" or just simply "email flooding".

Taking the definition from Techopedia:

Email Bomb:

  An email bomb is a form of Internet abuse which is perpetrated through
  the sending of massive volumes of email to a specific email address
  with the goal of overflowing the mailbox and overwhelming the mail
  server hosting the address, making it into some form of denial of
  service attack.

  An email bomb is also known as a letter bomb.

Also the definition from Cloudmark Security Blog says:

  DDoS attacks are not limited to websites. We are currently seeing some
  email inboxes being attacked by being inundated by blog forum sign up
  confirmation and password reset emails. A DDoS attack on an inbox is
  known as mail bombing, and it is a technique sometimes used by cyber
  criminals to cover up a more serious attack.

I also include two links where both terms mentioned before are used in a similar attack to the one you described, these attacks were reported on www.hackerone.com as part of a bug bounty:

password reset email spamming
The email API to reset password is unlimited and can be used as a email bomb

If you want to read more about this attack, I include some extra links:

Cloudmark Security Blog
The Return of Email Flooding
If you start suddenly getting email/spam "bombed" there's probably a reason
How Email Bombing Uses Spam to Hide an Attack
OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery
mail bomb
Reset password - should I prevent abusing it?


For that code, I wouldnt expect to get PHP injection, but I'd look at Cross-Site Scripting (XSS) instead.

For example, try injecting:

<script> alert('woot Security.SE rulez!');</script>


Is RMI considered untrusted input even with TLS?

Based on gowenfawr's comment and on some input from someone working in security, it seems like RMI is generally considered untrusted unless the connection is always both encrypted and authenticated.


What privacy methods exist for P2P transfers?

Well the only way to anonymize  your P2P is to use an overlay network. So this means using proxies/VPN's/Tor like networks.

Another option would be to use a server that is not registered in your name and that doesn't log anything.

There are also options where it is hard to get onto the P2P network. You can only get  onto their network when you are invited and trusted. These networks are called Private Trackers. It's not 100% anonymous, but more based on web of trust.


Does the local network need to be hacked first for IoT devices to be accessible?

The devices are designed to be accessible from outside the home. To offer this service to their owners, they make themselves accessible through the homeowner's router/firewall. The way they do this is by sending a UPnP packet to the owner's router that tells the router to open a port that connects back to them. They then listen for connections that arrive directly from the internet.

In other words, the devices first hacked their owner's routers by design, which exposed their own vulnerabilities.  (This has nothing to do with secured, private, or open WiFi, other than many IoT devices connect via WiFi; UPnP exposes the exact same vulnerabilities on wired devices connected by Ethernet cables, too.)

To protect yourself, disable UPnP on your router.


Why is it so difficult to stop Ad Blockers?

Adblocking works by either modifying the existing page so that it does not even attempt to load ads or by blocking the domains associated with ad-networks. From inside the current page there is nothing you can do against some extension or proxy denying access to a host, because this is simply outside of what you can do with HTML and Javascript. You could also not simply serve your ads from different hosts because this would need fundamental changes on the way ads are delivered, i.e. the model of few large ad-agencies which dynamically sell ad-space to affiliates etc.

The usual way adblock-blockers work is by including the ad-content from the same domain as the original page and avoiding URL's and HTML tags/attributes which might be typical for ads. This works mostly, but this way the ad-networks loose a large part of the flexibility (i.e. real time ad bidding). Also users can be tracked less (better for privacgy, worse for ad-networks) and the risk for the user to get infected by malvertisment is much lower.

The other way is to detect ad-blocking (i.e. detect if ads are loaded or not) and simply deny users access to the page if they have ad-blocking enabled. And to make sure that users don't work around outlaw bypassing the ad-block detection by using DMCA or similar laws. See Axel Springer bans adblock users from Bild online for a recent case.


How are mobile telephony networks like LTE and HSPA encrypted?

I suspect that @Jay Looney is correct; for authoritative answers, contact the service provider.  (who will report you to DHS and DMCA).

Blackhat description of attacks on HSPA includes a brief overview and architecture, that may address the portion of the question re: what parts are encrypted.  This resource also includes the following sentence,

  The reality is that most UMTS/HSPA devices are also GSM/GPRS/EDGE capable, and are
  configured to try and connect to a GSM/GPRS/EDGE network whenever a suitable UMTS/HSPA network is not available.

I found one source that asserts that the answer is Feistel encryption, but it doesn't address the key management issue. I continue to believe that is something that only the vendor can answer, and I'm willing to bet they won't.

Agilent provides some internal details, but I think that is more specific than you want. It may be useful as context/example.

You could always take a course in the subject for a mere $1500.


Pros and cons of my method of storing passwords in plain text files instead of a password manager (on linux)

It always comes down to threat models. What kind of attacks are you trying to stop?

The biggest problem I see with this approach is that it relies on disk encryption for the data-at-rest in the file, which is essentially lifted as soon as the user logs in. Now, your plain text passwords are only protected by your OS root file system permissions.

As a normal user, you browse a website and get a drive-by download which can execute code as your normal user. It is now inside the encryption perimeter. Any local priv-esc can now dump your password file.

The encryption "gate" is tied to your user login, so any process running as you is already past that step.

What you list as a "pro" for security, I'd put in the "con" category:

  (and I personally wouldn't like to have to type the HDD password multiple times during a session increasing the probability it is stolen, instead of just typing it at boot).

I'd think typing it multiple times, once per time you need to access the secure contents, would increase your security. Think of it like a timeout on access to your secrets. If you stay logged in, that plaintext password file is only being protected by OS file perms. You could walk away and leave your screen unlocked, or someone could just steal the laptop.

The point is, data is decrypted as long as you are logged in.  The bother of multiple entries of your master password gets you access to just the secondary credentials you need, when you need them, and no more. They otherwise remain encrypted.

Your system is probably just fine in practice, but there is a difference. That's why I said it really depends on your threat model.


Unless you are going to use the tool's agents during an investigation, I would keep the forensic tools off of production servers. Generally these tools are intended to be run in a client environment, such as on an investigator's laptop or desktop.

There are a few reasons for this suggestion:

persistence of forensic tools in a server environment can make further compromise easier
aside from memory collection, forensics should be done on an image, and so they would done outside of a live server environment
it is easier to collect and lock up client laptops or desktops for legal proceedings than it is a server farm with the forensic tools

The exception to this is case management software. There may be a want or need to have server-side case management software that investigators use during the life of an incident. This is not uncommon in enterprise environments. However, I separate this from the actual forensic software such as the EnCase and FTK packages that you mentioned. The case management should be where investigators comment on the incident, share details, but the image collection and management should be done in the contained client environment.


How to steal cookie on website with cors?

An attacker might influence what gets sent within a cross-origin request but he is not able to read the cookies which gets added by the browser to the cross-origin request. Even a wide open CORS policy does not change this.

An attacker might also not change where the cookies get send: cookies will only be sent to the site where they belong to, no matter what CORS policy exists.


What are these incoming connections in my wireless router logs?

One on several possibilities is that it is just the result of an outgoing connect.  You connect to port 80 on a web server(or any other port/server), but on your end the connecting port is randomly selected.

Logs on routers are usually very short lived, they usually have room for a few 100 or maybe a 1000 if your really lucky and that is it.

If you want to do some serious analyst you will have to find a compatible open source router firmware like Tomato or DD-WRT.  Otherwise you probably won't be able to access the logs.

Large groups of bot nets scan ports and ips randomly to avoid being detected as port scans.  In a year or so I have 62,000+ ip address attempt connect to different unused ports.  I add 100 a day or so.