So, you want to hide information until a certain date, for your daughter. This must resist her attempts to retrieve this data too early.

Just use any encryption software (GnuPG, VeraCrypt, even 7-zip, etc), encrypt your documents (the data) and put them on a external hard drive or a tablet, then put the encryption key or the randomly-generated password (the secret) on the USB thumb drive.

Make sure to put the drive containing the encrypted data in an hazard-free location (you  don't want it to be destroyed by fire, flood or extreme changes in temperature and air pressure). Make sure your daughter knows how to find it. Give your secret (the thumb drive or the password) to a notary to be released on your daughter birthday. Add it to your testament too, bad luck happens. I would recommend to print on paper a long randomly-generated password (use a password generator) instead of an encryption key on a thumb drive as it will be more resilient to time than any electronics. Also, the notary will prefer a piece of paper. You can add a description of the location of the hard drive next to the password.

If you're looking for a way to ensure the data cannot be retrieved before a certain date by means of software or hardware only, I'm afraid this cannot be done. Whatever the chosen "solution", it would be very easy to fool its date and make it believe the day has come to release the data.

For added peace of mind, I would recommend saving your encrypted data on two hard drives and storing them in two different locations. You can also look up Parchive: apply it to your encrypted data to generate redundant data. This will be useful to recover from the corrupted bits likely to occur when time will take it's toll. Also, prefer a "classic" HDD over an SSD to hold you data, as HDD have a proven record to be able to sustain data for a long time without power.


A replay attack was detected (4649) & Exchange Healthmailbox

One item to check is whether or not a result is false positive.  The final portion of the log states a caution of the results:

This event indicates that a Kerberos replay attack was detected
- a request was received twice with identical information.
This condition could be caused by network misconfiguration.

Microsoft help docs at https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4649 also recommend doing a manual investigation as part of checking to see if this is a false positive.

I've done scans that have ended up with false positive and needed additional checks.


Certificates(CA certificate and EE/Local certiificate)

Does saying yes on prompt automatically means that Im trusting the certificate and Ive verified the fingerprint through some OOB means?

Correct, so it's the user's responsibility to verify that these are the correct certificates.

And also, the Hashing and encryption is done for the whole certificate content or just the public key of the CA server?

It's definitely possible that the complete certificate is hashed. Other options are to only hash the subjectPublicKeyInfo ASN.1 structure in the certificate, or only the subjectPublicKey inside that (i.e. the public key with or without algorithm identifier).

Once we obtain the local-certificate from the server, how do we verify that its from the right source or server and authenticity of it?

The Simple Certificate Enrollment Protocol (SCEP) ensures that using the trusted certificates installed in the first step. This involves encrypting the certificate request for the CA and verifying the signature after the certificate is returned. All this is completely automated and requires no user intervention.

How does, B authenticate the certificate? Or how does it know that it has come from A?

It has to trust the CA that issued the certificate. And it uses the identity (e.g. the subject DN or a subjectAltName, e.g. a FQDN or an IP address) to verify it is the correct host.

I know there is a signature verification done, but what is decrypted and what is compared to prove that the peer authentiicity.

There are several aspects to this. Host A will provide a signature with its private key as part of the the authentication protocol (e.g. TLS or IKE), which B verifies with the certificate received from A (basically the signature is decrypted and the data is compared to locally produced authentication data). The second aspect is verifying that the received certificate is trusted. For that B builds a trust chain to a trusted CA certificate and the signatures in that chain are verified. And as mentioned above, the identity of host A also has to be confirmed by the received certificate.


Paypal sent an email addressing me with one of my old passwords as my name

It seems like the spammer got your personal information including your password through a security breach somewhere. Why did they use your password instead of your name? I would say it was an honest mistake on their side. They just mixed up the fields when designing the spam mail.

When you are still using the password somewhere, you should change it ASAP. In the future you should avoid using the same password for different services. Data breaches become more and more frequent, and they even hit larger companies which really should know how to secure their systems. Using a password manager like KeePass can help you to manage all the different passwords.


Relationship between HTTPS and SSH Public Keys

The two keys you show are encoded differently - obviously, the first is base64 encoded, and the second is hexadecimal encoding.  You would need to determine the formats used and their encoding to determine how to reconcile the two.  And in both cases it's a packed structure, not just raw key data but discrete bits of data like key type, exponent, and modulus.

Fortunately for you, somebody already figured out how to convert between the two.  Lars Kellogg-Stedman walks through the RFC 5246 format of the SSH key, and uses the PyASN1 Python module to convert to PKCS#1 format.


Do my router and OS "know" which URLs I visit, if SSL is used?

The full URL is protected by the end to end encryption of HTTPS, but the target IP and hostname (the full name of the host, i.e. FQDN, i.e. something like
www.example.org) are not. Thus the router could get the name of the host you visit but not the full URL (i.e. not the path after the hostname):

 https://www.example.org/some/secret/page.html
         |-- visible --||---- protected -----|

An application on the same OS as the browser might be able to get the full URL if it has the same or even more access rights than the browser and could thus inject code into the browser process or read internal data from the browsers memory. By injecting into the browser it could even not only read the full URL but has access to all the other transferred data and can modify these. This is for example done by malware targeting online banking.


What is the most hardened set of options for GCC compiling C/C++?

I don't code for gcc, so hopefully someone else can add to this, or correct me. I'll edit it with responses. Some of these will not work for all circumstances.

-Wall -Wextra Turn on all warnings to help ensure the underlying code is secure.
-Wconversion -Wsign-conversionWarn on unsign/sign conversion.
-Wformat-securityWarn about uses of format functions that represent possible security problems.
-Werror Turns all warnings into errors.
-arch x86_64 Compile for 64-bit to take max advantage of address space (important for ASLR; more virtual address space to chose from when randomising layout).
-mmitigate-rop Attempt to compile code without unintended return addresses, making ROP just a little harder.
-mindirect-branch=thunk -mfunction-return=thunk
Enables retpoline (return trampolines) to mitigate some variants of Spectre V2. The second flag is necessary on Skylake+ due to the fact that the branch target buffer is vulnerable.
-fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 Your choice of "-fstack-protector" does not protect all functions (see comments). You need -fstack-protector-all to guarantee guards are applied to all functions, although this will likely incur a performance penalty. Consider -fstack-protector-strong as a middle ground.
The -Wstack-protector flag here gives warnings for any functions that aren't going to get protected.
-fstack-clash-protectionDefeats a class of attacks called stack clashing.
-pie -fPIE Required to obtain the full security benefits of ASLR.
-ftrapv Generates traps for signed overflow (currently bugged in gcc, and may interfere with UBSAN).
-D_FORTIFY_SOURCE=2 Buffer overflow checks. See also difference between =2 and =1.
-Wl,-z,relro,-z,now
  RELRO (read-only relocation). The options relro & now specified together are known as "Full RELRO". You can specify "Partial RELRO" by omitting the now flag.
  RELRO marks various ELF memory sections readonly (E.g. the GOT).
-Wl,-z,noexecstack
  Non-executable stack. This option marks the stack non-executable, probably incompatible with a lot of code but provides a lot of security against any possible code execution. (https://www.win.tue.nl/~aeb/linux/hh/protection.html)
-fvtable-verify=[std|preinit|none]
  Vtable pointer verification. It enables verification at run time, for every virtual call, that the vtable pointer through which the call is made is valid for the type of the object, and has not been corrupted or overwritten. If an invalid vtable pointer is detected at run time, an error is reported and execution of the program is immediately halted.(https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)
-fcf-protection=[full|branch|return|none]
   Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. Only available on x86(_64) with Intel's CET. (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)

If compiling on Windows, please Visual Studio instead of GCC, as some protections for Windows (ex. SEHOP) are not part of GCC, but if you must use GCC:

-Wl,dynamicbase Tell linker to use ASLR protection.
-Wl,nxcompat Tell linker to use DEP protection.


How effective are timestamps as a countermeasure for Replay attacks?

This solely depends on the tolerance itself. Usually, a few microseconds of skew will be reasonable to tolerate as long as the time heartbeat is in reasonably short intervals.
Nonces; a special kind of “token” - by the way, time stamps can be abstracted to being a token as well:)


What are these ip adresses my computer is connected and how do I block them if they are malicious?

Understanding netstat and getting useful information

HERGESTELLT  means that there is a connection. Ports that have been opened by server programs on your computer are in state LISTENING (ABHÖREN) instead. Looking at the target ports, this is likely web traffic with the exception of the first one.

In order to get more useful output, you need to use some parameters for netstat as explained in the documentation:

netstat -a -n -o

-a will include ports in state LISTENING,
-n will show the real ip-addresses instead of the DNS reverse lookup.
-o win include the process id (use the Windows Task manager to look it up).

Please keep in mind that in case your computer got infected, you cannot trust the output of netstat as the malicious program might have manipulated it.

Owners of ip-addresses

For the cases in which the IP-address is visible in your log, the owners are as follows:

193.247.193.85: Google
46.105.131.100: Astro Empires is a Massively Multiplayer Online Game
87.252.216.36: Gambling related online games
87.252.210.40: Casino Website

All of them seem to be normal websites, likely not related to trojans.


Can the network administrator of my university see what I have searched on Google?

Yes, given 1-3 you can be sure the connection is encrypted end-to-end between the browser and the server, and that a 3rd party cannot intercept the unencrypted message (without obtaining encryption keys through some other means).


Does Strict-Transport Security Header (HSTS) need to be applied to non 200 response pages (e.g. 403, 302)

While it's not good, and it should be fixed, it's likely not as bad as you think. HSTS applies to domains, so as soon as one response includes the Strict-Transport-Security header the browser will force all requests to redirect to HTTPS for the entire domain (and possibly subdomains, depending on configuration).

Resources like JavaScript and CSS are rarely if ever accessed directly by end-users, so the HSTS header should be received before these resources are requested anyway.

If there is a MitM and the user hasn't visited the site before (or the max-age of the HSTS header has passed) and the site isn't in the preload list, it won't matter that some responses include it and some don't; the MitM can use ssl-strip either way. HSTS only works after the browser has seen it, if you're visiting a site for the first time over HTTP you're vulnerable unless it's in the preload list.


It would be worthwhile to consider a single-tenancy server. By default, most providers will give you a multi-tenant server (which can be vulnerable, albeit difficult). Most multi-tenant servers are virtualized at the operating-system level, so you cannot see other user directories, as the operating system is totally independent of each tenant (e.g. you could be running WinServer 2016, another tenant could be running Debian, and another CentOS). In other circumstances (less desirable), you're all on the same operating system, just separated by a chroot (or similar). In this case, a compromised server can affect hundreds of websites.

TL;DR: It depends on your hosting plan. If you have an entire operating system to yourself, you're more secure than just sharing the same OS and being separated by software. The most secure option is to have a dedicated server.

Realize that a dedicated server will cost a significant amount more than your typical hosting. Most of the time this requirement is seen for HIPAA or SOX regulations.


Security Risks Involved in Deploying Win Server 2008 on a Linux host

Chris is basically there I think.

In my opinion, the best way to treat virtual machines is to not think of them as virtual machines but actual physical computers, with the advantage of being able to image them faster. Ask yourself if you installed another physical windows box on your local LAN what problems it would introduce. Consider that it needs the same defences.

The reason for this is that the temptation is to trust all network communications from a VM and think "it's a VM, so it is secure". Provided you realise you need some level of protection for the VM too as it can attack your host and your host can attack it if either is exploited, mostly, you should be fine.

There is current research into red pill techniques, as in "escaping the matrix". The idea is that if you can exploit a bug in the virtualisation hardware/software from the guest you might be able to exploit the host. Right now, I don't think that is much more than a research/theoretical/lab conditions issue, but I expect given the sheer amount of virtualisation going on, it will eventually be something we have to contend with.

I and others have answered some other points on the question of using virtual machines as a security measure for desktops, which might also interest you.


Security considerations for setting up remote access on a PC

You have not provided some key details helpful to answering your question such as whether the computer accessing your company network is company owner and centrally controlled and how the VPN is configured.

There are several best practices that you can do to better secure remote access:

  Implement multi-factor authentication (MFA) for remote users

Using MFA would strengthen security by requesting the user for another form of credentials in the form of something they have with them, or a biometric such as a fingerprint. Without MFA enabled, the security of this account would rely on the strength and safekeeping of its credentials.

  Restrict VPN access to company owned machines if at all possible

A VPN connection provides confidentiality and integrity for the data passing between the client computer and your corporate network, but the remote computer itself can be a serious threat. If the remote computer is not owned and centrally managed by your company IT department, then you are essentially allowing an untrusted computer access to your internal company intranet. If an attacker were to compromise the remote computer, he / she can use this computer to directly access your company network. In addition, given the data in transit is encrypted, it would be much more difficult for security technologies such firewalls / IDS to properly inspect the incoming traffic.

  Configure the VPN connection to timeout after a certain interval with no activity

By implementing this rule, you would lessen the likelihood of an unauthorized user from taking advantage of the VPN connection to access the company internal network.

  We dont have any additional security like a hardware firewall.

Please consider implementing a firewall before setting up remote access. As you are using remote access, ideally the firewall should support remote authentication features such as RADIUS or TACACS+ that centrally confirms the identity of remote users.


How to verify a signature of one entity by another using OpenSSL CLI?

I believe certs g2 and g3 are already present in the default trusted directory (/etc/ssl/certs/) which openssl uses to build the chain of trust and find the 'trust anchor'.

In my setup:

  g2 = GeoTrust Global CA
    g3 = Equifax Secure Certificate Authority

Both of these certs are present in the /etc/ssl/certs/ directory.

If you try out the same experiment with a self-generated chain of certs, you will find the behaviour that you expect.


Using composed, yet unsent email drafts to communicate

It's not a good idea. Also, that trick is older and more popular than you might think.
As with any security-through-obscurity pattern, it only works if the adversaries aren't aware of it. But since saving emails as drafts instead of sending them has been popular among criminals, terrorists and even found its way into pop culture, that technique rather attracts attention and certainly doesn't add security.
E.g., one popular case was the Petraeus and Broadwell affair:

The CIA director and his biographer had a shared Gmail account and wrote some of their personal missives as draft emails, which were left in a draft folder or an electronic, "dropbox".
[...]
Al Qaeda terrorists began using the technique years ago. It allowed them to exchange information without sending traceable emails. An account would be opened by one conspirator and a draft email written and saved. The account could then be opened by a co-conspirator with access anywhere in the world, who could read the draft email and delete it.
The process meant the information had never been sent in the form of an email, making the electronic trail weaker. The technique has since been copied by teenagers in many countries to avoid having their emails monitored by their parents.

(Source)

If you change a draft or delete it does the server preserve the drafts if they are never sent?

There is no way of knowing if deleted drafts are preserved, so better assume they are kept. Also, getting behind this trick might be as easy as searching the provider's database for email accounts that produce high amounts of drafts but rarely actually send emails.
Instead, encrypt your emails. There are plenty of cryptographically secure technologies, free providers and VPN services to do so anonymously and securely.


Would there be MITM attack even fix the heartbleed vulnerability?

I think I understand the question as:

  If a servers' private keys have been compromised, won't a MITM attack
  be possible even if the heartbleed vulnerability has been patched?
  (given that not all browsers mandate Certificate Revocation List (CRL)
  checking?)

And I believe the answer is indeed yes.

Patching against the heartbleed vulnerability prevents any further disclosure of server memory contents. Generating new keys is a precaution in case the old keys did leak. Revoking the old keys by means of adding them to the CRL is a public notification the the old keys are no longer valid.

However, as you've noted, not all browsers thoroughly check CRLs by default. The text below is summarized from a Netcraft article published by Robert Duncan on 13th May 2013 so may no longer be entirely accurate):

  Firefox does not download CRLs for websites which use the most popular
  types of SSL certificate (all types of certificate except EV which is
  usually displayed with a green bar)...even if OCSP were available, by
  default Firefox will only check the validity of the server's
  certificate and not attempt to check the entire chain of certificates
  (again, except for EV certificates).

  Neither Google Chrome on Android nor Safari on iOS present a warning
  to the user even after being reset. Safari on iOS does not make
  revocation checks at all except for Extended Validation certificates
  and did not make requests for the CRL which would have triggered the
  revocation error message.

  Google Chrome, by default, does not make standard revocation checks
  for non-EV certificates...

  Microsoft's web browser, Internet Explorer is one of the most secure
  browsers in this context. It fetches revocation information (with a
  preference for OCSP, but will fallback to CRLs) for the server's
  certificate and the rest of the certificate chain...

  Along with Internet Explorer, Opera is secure by default: it prevents
  access to the webpage. Opera checks the entirety of the certificate
  chain using either OCSP or CRLs where appropriate.

Therefore it would be correct (I think) to conclude that the risk of MITM attacks against TLS connections has significantly increased. From the linked article, a good way to protect against such attacks would be to use IE or Opera when visiting important websites.


How does "Microsoft domain authentication" prevent me from using passwort variants?

Windows domain password complexity is enforced by group policy, full info on what the 'password complexity' requirement means in windows is available here:
https://technet.microsoft.com/en-us/library/hh994562(v=ws.11).aspx

but here's the highlights:

May not contain your username (the one you login with)
May not contain any part of your full name (There's a whole paragraph on the technet page defining what a 'part' means)
May not be one of X old passwords (the number X is configurable by admins)
Must be at least X characters long (number X is configurable by admins)
Must contain 3 out of 5 of the following categories

a-z (lowercase alphabet)
A-Z (uppercase alphabet)
0-9 (numerical)
symbols/non-alphanumeric characters (!@#$%^&*, etc.)
extended Unicode characters (Chinese/Japanese characters, etc.)

Unless they've implemented a third-party solution there's no 'substrings of old passwords' option. My recommendation if you're interested in using the NIST passphrase recommendation, I'd choose a new passphrase each quarter, and then add on an numeric/symbol end (which can stay the same quarter to quarter).

e.g.

q1 : Jumpingtheshark382##@

q2 : Talktothehand382##@

q3 : He'sgoingthedistance382##@

etc.


Is it possible to encrypt persistence in metasploit?

Well, i'm not sure if that's possible or not.

But i think the reason that the persistence is detected by almost every antivirus, is caused by the heuristic analysis, so even if you encrypt the persistence ... it is possible it will be detected in any case.


Is storing the bcrypt salt in isolated database a good idea?

Now, attacker will be able to build a custom rainbow table for that salt to run attacks

I don't think you understand what a rainbow table really is and how much effort it is to create one. Basically a rainbow table is a trade-off where one invests lots of time (and memory) initially and then can crack lots of password hashes faster, as long as the relevant hash is covered by the rainbow table. To crack a single password it is way faster to just brute-force it instead of creating a new rainbow table with the specific salt. The protection against attacks based on rainbow tables is thus not to hide the salt but to use unpredictable and sufficiently long salts so that the attacker does not have already a pre-built rainbow-table.

In other words: there is no need to protect the salt against the attack you imagine.


Does GPG encryption via subkey harm file quality?

The idea behind encryption is that the original can be restored by decrypting again, that means that the process is lossless and thus the quality of the "file" is not harmed.


Connect to Mysql database from remote host without remote access

If Mysql is only accepting local connections (as configured through CPanel), and the people who know the passwords don't have any shell access to your machine, nor any other way to open a local network connection, then they cannot connect to your database and therefore their knowledge of the password doesn't make a difference.

Nonetheless, you are taking the risk that one of these assumptions is violated.

If at some point you accidentally misconfigure the database authorizations in CPanel, or if you decide you need remote connections from some purpose (e.g. because you want to split your service and put the frontend and the backend on different machines), then at this point your data will become exposed. You'll have to change the passwords at that time, and the more you wait, the more places you'll likely have to update, and the higher the risk that you'll forget that the passwords are known.

If at some point the people with the passwords gain access to your machine, they'll be able to access your data. This can obviously happen if they get shell access, but that's only one way. Even if you grant them some restricted access for a different purpose, it may allow them to open local network connections. The most obvious way is if you let them use that server as a relay, but it could also come through less obvious interactions. It's also possible that one of the applications running on your server is partially broken, for example allowing an SQL injection. You might have a low-importance application that only accesses some unimportant table and has an SQL injection vulnerability; if someone exploits that vulnerability and they know some database passwords then they can access all these other databases and not just the unimportant one.

As those people know your passwords, you don't only need to trust them not to misuse them. You also need to trust them not to expose them. Even if they're perfectly honest, if they store your passwords in a file and their machine is compromised then your passwords will be compromised.


Can a Logitech wireless headphone usb receiver be infected?

Assuming it doesn’t present a USB storage device, the simple answer is: no, it won’t be infected in most reasonable scenarios.

The more complicated answer is that any complicated USB device could theoretically be reprogrammed to act maliciously. This could be especially useful to jump air gaps or ensure that all machines used by an individual are infected.

How could this happen? Two examples:

An attacker could reprogram the firmware to act as a different USB device, perhaps temporarily. For example if you’re not using your USB receiver it could present as a keyboard and type keystrokes (open Powershell, download some malware etc.).
Firmware could be reprogrammed to exploit a bug in the vendor drivers. For example triggering some form of buffer overflow or double free by violating the expected protocol.

There are significant hurdles to achieving these aims, for example:

Many devices can’t be updated. The firmware is fixed during manufacture.
Most commercial devices won’t have a lot of spare capacity. The manufacturer will try to use the smallest micro controller and memory possible.
Update mechanisms will be proprietary and undocumented, requiring substantial reverse engineering.
Many (but not all) devices will have code signing or update validation at the micro controller level, typically to prevent counterfeiting. This is more likely to affect common brands, reducing the risk of widespread attacks.
Lots of common devices use generic drivers, provided by the operating system. These will (hopefully) present less chance of vulnerabilities.

However, the chances of this are incredibly slim. Slim enough they probably won’t appear in most corporate threat models, but would potentially register for a defence manufacturer and certainly for sensitive Government departments.


How is this Identity aware encryption description different from simple authorized access?

This does sound kind of smoke-and-mirrors (you'll find that all over the place in infosec, sadly). They could have been adding some meaningful security if the app couldn't decrypt user data without the user logging in - that would mean somebody walking off with the whole system still would have had no access; they'd need to do an online attack against each user as the sign in, which takes longer, risks detection, and doesn't work if you do something like steal a backup.
Mind you, the "steal a backup" case - which does happen - is an example where encrypting the data using a key that the server (much less the DB) doesn't store does help. But as you point out, adding per-user encryption really doesn't add much there; if the attacker can get any key out of the HSM, they can presumably get them all. I guess one possible advantage of per-user keys is that, if an attacker gets write access to the DB, they can't overwrite data in one part with data from another part (depending on the cipher and the way it uses IVs/nonces, and how granular or holistic the integrity checks are, this might otherwise be possible).
EDIT: I suppose it could be useful as a second layer of authorization check. If somebody finds an authz bypass in the app then normal access controls wouldn't stop them from accessing another user's data. However, if each user's data is encrypted with per-user keys, then an authz bypass might not actually let you access somebody else's data anyhow. So yeah, it might be a defense-in-depth thing.

Tech companies in general, and especially fintech companies, love to make extravagant claims about their security. Most of them are meaningless, though, or at best are addressing some tiny threat when the most likely attack vector by far is simply spearphishing or similar. I think this is likely to be one of them. But... hey, at least they use encryption at rest and store the keys in an HSM? That's better than a shocking number of companies (though those facts alone don't guarantee any added security, depending on how those systems are used).


Who initiates an authorization code flow?

Consider the example of signing into your site (https://example.net) via your Google account.
In this case, you [and, by extension, your digital "user agent": Firefox or Chrome] are the "resource owner"; ExampleNET is the "client" (and also the "relying party").
The client, ExampleNET, initiates the flow by directing you, the resource owner, to emit that HTTP request you described.
Sounds weird? Look closer at that request.
See the nonce field? That had to be prepared by the client. More significantly (though missing from your example), in the same vein is the state field: also prepared by the client as they prepare to initiate the flow by [re]directing the resource owner to that big URL.
Now, they may or may not have "warmed the flow up" by pre-initializing the nonce (which, if they're using, they should be recording to check it against later), or by quickly generating it when the resource owner expresses intent to use that flow (by e.g., loading the Login page), and they may have done this in response to activity from you which clearly signaled intent to start that flow (such as e.g. clicking the Sign In Via Google link...)
but they're still the ones initiating the flow by giving you the (potentially ephemeral) necessaries to take the—from the resource owner's point-of-view—"first" step of the login flow. That's why the client is described as initiating it here.


Is a multitenant web app built on Apache Cassandra more resilient against DoS attacks?

Well if you have multi-tenant app, you need to monitor each tenant service, and in case of fail, redirect him to a working cluster.
Basically, what you do in this case, you redirect affected customer to a blackhole, while the rest remains unaffected.
For example, if each of your tenants is using different FQDN, you can block affected customer on L7 load balancer you mentioned. In any case, you can make load balancer to detect DoS and block it automatically.
Ideally you need to work out the load balancing using geo-graphic regions and DOS detection as well per-tenant monitoring, so all of this at once will give you automation you are looking for. Also the security and user isolation is also here important, that the CPU spike will not affect another tenant.


validate file encryption without decryption key

To a large extent, the question makes no real sense, because the data is opaque for the server. Since the server will not, in any case, be able to read the decrypted files, whether two files are identical or not should not have any impact. In fact the complete scenario must be made clearer.

You have a server. The server stores "encrypted data" on behalf of some users who will send to each other the decryption keys; all decryption and encryption occurs elsewhere, and your server cannot do it. We have to assume that there is an out-of-band mechanism by which users exchange decryption keys.

What you want, as the server's owner, is to recognize when several instances of the same file are uploaded to your server, so that you may pay for the storage space only once (I just read somewhere that "The Hobbit" was the most copied movie of 2013, so you might assume that your envisioned platform would contain several hundreds of copies of that multi-gigabyte movie file). Normal, secure encryption should prevent outsiders from being able to make any assertion about the data contents, including being able to recognize whether two encrypted files have the same contents. In that sense, the de-duplication you are looking for is a weakening of the security model. We can predict that some users would not like it; for instance, if de-duplication works, then you (as the server) can detect when a user is uploading "The Hobbit".

(When de-duplication works, then it becomes possible to do some exhaustive search on file contents; this is easy to do for files which are duplicated a lot, because a file which is known to many users cannot be really that secret; and in the context of "intellectual property enforcement", heavily-duped files are of prime interest.)

If we speak in generic terms, then you cannot enforce de-duplication, because any two users who want to evade it can simply double-encrypt their data. User 1 first encrypts the file with an extra secret key, that he will share with User 2; that key is chosen randomly, so the encrypted file won't match any other instance of the same data; that encrypted file is then encrypted again with your service. Users can do such double encryption because the data is just, in fine, a file on their disk, and we assumed above that users can talk to each other independently of your server. As long as users can talk to each other, then they can exchange secret keys that you don't know of.

In some very specific contexts, it is possible to prove that some encrypted data fulfills some algebraic property without revealing it. See non-interactive Zero-Knowledge proofs. This is used in some electronic voting protocols, so that the prover may demonstrate that what he encrypted is really either a 0 or a 1, not any other integer, but without divulging the actual vote value. This won't apply to a generic file storage system, because "normal files" don't follow a discernable mathematical structure.

Therefore, if you want to enforce de-duplication against uncooperative users, then you must make it so that users cannot talk to each other. That's easier said that done... and it looks hardly feasible, since for the site to be really useful, the sender and recipient must be able to agree on at least a reference key, used to locate the file on the server.


How to find the location of the device connected to router

Your approach is to this issue is wrong. If someone is accessing your WiFi without your consent, pinpointing their location will not necessarily help you.

Instead you should harden your access point so that your current "guest" and others cannot access it:

Set a strong password
Select a strong authentication/encryption mechanism
Enable MAC filtering
Change and hide your wireless network SSID name
Turn off guest networking

This will not only solve your current problem but protect you against similar problems in the future.


1) Depends.
The VPN itself indeed only encrypts from 1 to 2, however,
if 3 (The website you're visiting) supports TLS/HTTPS, 2 -> 3 is also encrypted and secured, only not by the VPN.

E.g:

  1 = user 2 = vpn 3 = web-server Without TLS: 1
  ---[VPNencryption(plain_text)] -----> 2 ---[plain_text] ----> 3 With TLS: 1 ---[VPNencryption(tls((plain_text))] -----> 2
  ---[tls(plain_text)] ----> 3

2) VPNs mostly make use of tunneling protocols. One of their features is that they can e.g encrypt data, or use a specific protocol that the underlying or standard network does not necessarily support. So you don't always need to edit network-configurations or anything similar.
And it's mostly the Link Layer.


SSL data is indeed split in records, each record beginning with a recognizable 5-byte header, and containing up to 16384 bytes worth of application data. What happens when records are missing depends on the negotiated algorithms.

Important note: SSL, by definition, is meant to ensure confidentiality of data. You should not be able, from the outside (i.e. with Wireshark), to decrypt the data, unless you have a privilege access to secret values known to the client or the server (e.g. you have a copy of the server's private key). I assume here that you have, indeed, such an access. From that access, you could obtain the "master secret" (the main shared secret resulting from the handshake) and then the encryption keys used for application data in both directions.

If the encryption algorithm is a block cipher (3DES, AES...) in CBC mode, then each record can be decrypted separately:

If the protocol version is TLS 1.1 or TLS 1.2, then the IV for the record is also embedded in the record itself, so the complete record data is recoverable.
If the protocol version is older (SSL 3.0 or TLS 1.0), then the IV is the last encryption block from the previous record; if you missed that previous record, then you don't have the IV... so you won't be able to obtain the first 8 or 16 bytes of the cleartext data of the record you have. The rest of the record contents will still be available.

If the encryption algorithm is RC4, then things are a bit more complex. RC4 is a stream cipher with a running state. The computed encryption keys are, really, the initial state of the algorithm for the first encrypted record. Each subsequent record is encrypted using the internal state that RC4 reached at the end of the previous record. For successful decryption, you must maintain that state in synch with what the client and server do.

It so happens that RC4 works by generating a long stream of key-dependent pseudo-random bytes, which are XORed with the data to encrypt (or decrypt). This means that the internal state reached by RC4 depends on the number of bytes encrypted so far, but not on the values of these bytes. Therefore, the eavesdropper (you) may recover from a "hole" by guessing how many bytes you missed. Decryption over a hole would then look like this: from the last known RC4 internal state (the one reached at the end of the decryption of the last observed record), loop over possible lengths for the missing record(s), and for each of them, work out the RC4 state at the start of the next observed record, and see if that yields a "meaningful decryption". Since SSL records also embed a MAC value, verifying decryption success can be done reliably (since the MAC key comes from the same source as the encryption key, I suppose that you also got that one). The process can be computationally expensive if the hole is big (e.g. if you missed up to one full megabyte of data, then you have to try a million "missed length" values, which will take a few seconds or even minutes of computations if the next record is big and you need to recompute the MAC to know whether decryption is successful).

Compression can make your task harder, too. Usual SSL clients and servers tend not to use compression, because compression leaks information on the compressed data (encryption hides data contents, not data length, and compression makes data length dependent on data contents -- in HTTPS contexts, this is called the CRIME attack). But if they do, then the "normal" compression algorithm for SSL is DEFLATE, which is stateful: the contents of each record will depend on the contents of previous records. Coping with a "hole" will be harder, just like bad sectors on a harddisk can kill a complete compressed archive.

An interesting comparison point is DTLS. This is "TLS for datagrams", i.e. TLS ported to packet-based transport mediums where packets can be lost (in simple terms, DTLS is "TLS over UDP instead of TCP"). Packet loss will imply the same issues than the ones you face, for the normal client and server this time. DTLS works around them by using the following:

RC4 is not allowed in DTLS.
The IV is explicit in each record (DTLS reuses the record format from TLS 1.1 and 1.2).
DTLS is silent on the subject of compression. One has to assume that if compression is used, then the sender shall arrange for stateless compression, which is still possible with DEFLATE but requires a "full flush" at the start of each record (see this on DEFLATE flushes). This decreases compression efficiency, since it prevents (by construction) cross-record data redundancy elimination.


What options are available for implementing DLP?

One approach is to lock down endpoints to block the egress points, which includes:

Disabling local media: USB, SD cards, CD writers, firewire, etc. Many enterprises attempt this - disabling USB is considered a standard baseline - but rarely are all these blocked. Thin clients can do this more robustly than a normal computer.
Blocking network egress: this is harder; some enterprises use a content filtering proxy to block file sharing sites and webmail, but they never block them all, and in particular corporate email needs to be allowed.
You need to prevent unauthorised devices connecting to the network, as these will not have local media disabled, so can be used to egress. Some enterprises attempt this with network access control (NAC).

I see this done in many environments, but never comprehensively. But even if this could be implemented perfectly, there is a major problem: it's too restrictive. We disabled USB because we want to stop Joe copying the top secret database onto a USB stick. Now, Joe may want to - quite legitimately - put some non-confidential marketing material on a USB stick to use at a conference. The lockdown prevents this - it doesn't have any concept of classification, so it can't distinguish between a public presentation and a top secret memo. Most enterprises have a process to request USB be re-enabled, with a business justification, but at that point Joe can steal the top secret database.

To improve on this, various vendors have created Data Loss Prevention (DLP) tools. Some of them are called Data Loss Mitigation (DLM); it's the same technology. These work in various ways, but most have an agent on the endpoint, and a central management system. When the system is installed, various key documents will be marked as confidential, and some patterns may be used (a popular one is 16 digits, indicating a credit card number). Now, when Joe tries to write a file to his USB stick, the agent checks whether the file is confidential, and then allows (or doesn't allow) the file to be written.

Commercial DLP systems are now pretty mature and try to address all the local media and network egress points. It's important to realise that they are only intended to stop your internal staff. They will not generally stop hackers (despite the claims some vendors make). Still, they are a good technology to have, and although they are not that widely used, I think most security conscious organisations should have it. I think the cost/benefit ratio is better than you get from IDS.

As people have mentioned, one egress point that nothing can protect is people. You can stop someone copying a 10gb database to a USB drive. But if the top secret data is one sentence ("it was xxxx who shot JFK") then someone can of course read that, remember it, then leak it outside your organisation. And to stop someone photographing their screen you would need physical security controls, like confiscating personal electronic devices.


Problems with using a non-reserved top-level domain for local DNS resolution

What are the problems with using a live top-level domain for internal name resolution?

You may find yourself unable to reach real hosts belonging to the real organization registering that domain in the future, because your DNS queries will be short circuiting that access.  You may also leak queries reflecting internal organization (server names) in some circumstances (e.g., a laptop "off the network" querying public DNS instead of corporate DNS).

Specifically, what are the security implications?

If you have systems somehow querying "real" DNS, they'll either leak dns names and/or be potentially redirected to hosts they didn't intend to go to.  That could lead to credential leakage as a worst-case scenario.

In addition, does this somehow conflict with some fundamental way on
how DNS and name resolution is supposed to work?

Well, it's bad manners, and any breakage that resulted would be well-deserved.
See this answer for a list of TLDs that are safe for private use.


How can I search for registered domains, but not unregistered domains?

You can also search through http://www.namedroppers.com/. I had not personally used this before but a quick test showed that it does find adjacent domains fairly well. It looks like the online search is free but you have to pay to download the list.

Disclaimer: I am not affiliated with http://www.namedroppers.com/ nor do I endorse their service.


Difference between STRIDE and Mitre ATTACK

MITRE ATT&CK describes the different stages of an attack, derived from the Cyber Kill Chain model, and then points out the main tasks of each stage. Finally, it describes a list of common TTP used for each task.

It is useful to establish indicators to catch an attacker at any of these stages, as it mostly describes an arsenal of techniques and the general flow of an attack.

What it doesn't capture so well is which vulnerabilities the attacker is going to exploit and the general attack categories. This is what STRIDE and other threat modeling techniques do, typically with a more system-centric approach.

From "Threat modeling: designing for security" by A. Shostack:

  When you threat model, you usually use two types of models. There's a model of what you're building, and there's a model of the threats (what can go wrong).

Although STRIDE doesn't really model the system, it does provide some broad categories of attack, which are not tied to a specific stage nor to a specific version (like the detailed TTP described by ATT&CK).

Moreover, but this is more of a personal consideration of mine, generic threat modeling methodologies like STRIDE can be easily adapted to consider not only IT security, but information security as a whole.

Both ATT&CK and STRIDE are useful, but for slightly different purposes.


How can you use the information from Gmail's "Show Original" feature to check if an email really came from Google?

If you are reading in Gmail and use the "Show Original" option, and the from address is from a Google domain (should be no-reply@accounts.google.com), then yes those three indicators are enough.

For a more in-depth review of the mail path, you can copy all the headers (everything above Content-Type: in the block below where you see those pass marks) and use a 3rd party analyzer to see the in-s and out-s.  I like MX Toolbox (https://mxtoolbox.com/EmailHeaders.aspx) -- just paste the headers in there and click "Analyze" to receive a full break down of what it all means.

Also, to be "phish proof", even if the message is from Google, you should manually go to your account settings to take remediative action.  This is a rule for every web site/service; never ever trust an emailed link that asks you to update security information.  Login to your account by hand, then go to your account security and take action from there.  It is a super easy rule, and a sure-fire way to avoid being tempted/trapped by a well-crafted spear phishing message.  Just head to accounts.google.com and take care of it from there.


OAuth2 Client Credentials Flow with assertion JWT: How to share the client's public key?

Using JWKS you put your public key at a known URL:

https://YOUR_DOMAIN/.well-known/jwks.json

  Cyber security guidelines tell me to rotate / cycle secrets regularily.

While I think it is a good idea to be able to rotate your secrets in case they get compromised, I don't think it is uniformly good advice to rotate secrets regularly.  I think it is acceptable to keep the same key pair for several years.


If you use Official Snort Ruleset then it is already included inside ruleset:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN Nikto Web App Scan in Progress"; flow:to_server,established; content:"(Nikto"; fast_pattern:only; http_header; pcre:"/^User-Agent\x3a[^\r\n]*?\(Nikto/Hmi"; threshold: type both, count 5, seconds 60, track by_src; reference:url,www.cirt.net/code/nikto.shtml; reference:url,doc.emergingthreats.net/2002677; classtype:web-application-attack; sid:2002677; rev:14;)


Is it possible to MITM TLS without maintaining connection between proxy and remote server?

From a technical point this is impossible. TLS MITM is only possible by having separate TLS connections from the proxy to both the client and the server. You need to maintain the state of both the TCP and the TLS stack for the full duration of the interception because otherwise you could not receive, decrypt, re-encrypt and send the data from the client to the server and back. But this does not need to be done on a single machine but can be made to scale will over thousands of systems.


WordPress theme infected by 5a9fa481.megaline.co malware

If you can view the access logs for the site that can be helpful. I've been able to find the attack vector for wordpress sites this way in the past.  If there's nothing there then it's likely it's coming from someone else on the host.  Perhaps you could move it to digital ocean ($5 per month for a VPS) to rule out being a problem with the shared host.


Can we still provide confidentiality when cryptography is outlawed?

Thanks for the insightful question. The more I think about it the more it feels like someone has pulled the rag below my feet (living without cryptographic protection).

Analyzing the resulting threats (strictly from the business point of view - the requirements of dissidents etc. are a different story), I see them being:

Corrupt government officials who will (ab)use their position to sell confidential enterprise information passing through channels they control.
Business antagonists who will try to eavesdrop on your communication channels.

A very first thought would be to work on two fronts; diversification of paths and leak identification:

Without (or with watered down) encryption I would think that one should try a. to break down critical messages to smaller chunks and then b. diversify the paths each one would take. He would thus make life a bit more difficult to people eavesdropping by multiplying the paths they would have to work with. I suppose some of these paths should be more "traditional", like normal post, messengers etc. that the government can inspect but not the antagonists.

This of course does not exclude the government from reading all messages from all channels simultaneously, so I would suggest a kind of watermarking solution to identify  "non authorized leaks" coming from corrupt government officials. Or perhaps also adding fake (but traceable) messages in the mix?

Even governments that for their own reasons want to inspect all communications don't want to be branded as "business unfriendly". They would then probably take steps to punish any of their officials that abuse the eavesdropping capability for personal gain. A few, well publicized, cases of gov officials caught red-handed or just an announcement that the enterprise can effectively track leaks would help prevention big-time.

Now, how about a solution for the "always-on" blackberry crowds?


How can the impact of cold boot attacks be minimized?

One approach is to use highly non-redundant key schedules. For instances, if you can recover any large piece of AES's expanded key schedule in memory you can run the expansion in reverse and recover the original input (which then allows you to generate all of the round keys, even if you were only able to recover the values from a single round, or even portions of different rounds). To some extent, this is intrinsic to AES's design, so it's hard to avoid, but for contrast consider Blowfish's sbox expansion design - it seems quite difficult to recover the master key or the entire sbox if you manage to recover, say, half of the sbox values.

Another approach, one that works with AES, is to simply ensure the key never hits RAM by keeping the entire state in SSE registers or debug registers. This approach is only usable by an OS kernel, but often the kernel is going to be doing the crypto that is most prone to a cold boot attacks, like disk encryption, so this could be a promising approach.


What do i call this vulnerability Technically?

What kind of vulnerability is this?

This kind of vulnerability is usually referred to as "Business Logic Abuse". Business Logic refers to any business-related process, such as "If people reach the finale, they get a certificate".

The fact that you can get a certificate without participation is a way to circumvent this business logic.

Will this be eligible for a bug bounty?

No. Their website lists which kinds of vulnerabilities are eligible for a bug bounty and your vulnerability is not among those. Furthermore, your vulnerability has absolutely minimal impact, and a forged certificate could be made in a number of ways (e.g. image manipulation software, etc.)


How to compare contents of encrypted files on decentralized system?

If you're asking whether two pieces of ciphertext can be compared to glean information, no. The whole point of encryption is to maximize information theoretic security, or in other words, minimizing the amount of information revealed by a ciphertext about the cleartext upon cryptanalysis. Ciphertext indistinguishability, a property of modern public key cryptosystems, is also relevant here. Essentially, the ciphertexts resulting from two pieces of text being encrypted with the same cipher should not have a guessable correlation with their original plaintexts.

Seeing as they have no mutual communication, you could ask Alice and Bob to provide signed hashes of the cleartext to prove they know the same information (without revealing the actual information), but there's little you can do with ciphertext.


Can android application be repacked with original developer's signature?

If you have access to the developer's private key, you can just sign the modified APK with their key and be done. If you don't, you won't be able to.

To create APK signatures, RSA and DSA is used. You won't get through them. However, this means nothing if you can find a hash collision because what's verified by a signature is not the message (which is the program along all its data in this case) but the hash of the message. It's possible to change the message and leave space for a part you don't care about and then to just iterate through the possible values of that field you created, hash the new message, move on to the next iteration if the hash isn't equal to the original hash, and stop and remember the modified message once the hash of it is the same as the original one.

The default hash for APKs is sha1. sha1 is weak. But not weak enough for anyone to find a second message with the same sha1 hash anytime soon. Furthermore, developers can use stronger hash functions than sha1 so finding a fitting second message becomes even more unlikely.


Scanning a Foreign Network for Active Hosts using Nmap or Hping3

I think the Answer is No.

Assuming the router has no port forwards set from Private Network to outside, Its not possible to scan a Private Network (NAT) from outside the Private Network(From the Internet).

Lets say your NAT has IP address like 192.168.0.xxx.
Now these exact IPs will be located in many other NAT's.

If you scan something like 192.168.0.10 you either end with Host not found or will probably scan someone one else who is reachable from the private network you are currently on.

EDIT: If you really want to do it, you can setup Port forwarding  for the hosts in Private network and then scan the router IP for open ports.

UPADTE: After setting up Port Forwarding,the command will be nmap -sn -v RouterIP . But lets say you mapped HostIP:8080 to RouterIP:9090. You will get port RouterIP:9090 open. So you require to know the Mapping between RouterIP and hosts ip


To sniff traffic you must either have access to a system on the path or you must be able to redirect the routing of the IP packets in a way you get on the path.

Both is common for unauthorized access. Most routers and servers allow to trigger dumping or redirection of traffic.

You asked for doing that without cracking so there is no threat in your very specific scenario.

BTW: I personally think threats often come from the local network. It is not unlikely that persons in a local network with access to sniffing has the biggest incentive to invade privacy (because they actually know the targets personally). This can be true for household, school or work settings. Sniffing in that setting would be immoral (and most likely illegal) as well, but it does not always require specific system hacking.


one way might be using a smartcard or similar for the authentication, nobody can read a password or similar from a smartcard and when you pull it, nobody is going to access your HSM, at least in theory.


Secure log in without sending plain test to server

With your proposed system, anyone who intercepts the login transaction can store a copy of the password hash and use it in place of the password to impersonate the user.

If you really can't use SSL to protect communication, look into challenge-based authentication systems, where the password is never transmitted over the network, but instead proof that the password is known is transmitted, and this is done in a method that prevents replay attacks.


In order to login, since you can't add a public key in the remote server, you need a private key. So some choices you have are:

enumerate more and maybe you get lucky by finding the corresponding private key
check if you can access sensitive files e.g. /etc/shadow etc... and if you can try to break a user's hash. Maybe the password revealed can get you ssh access.
Since, from your comment this is an old debian system, as you correctly pointed out, brute-forcing the corresponding private key is worth-trying.


What are the benefits and disadvantage of disabling <TLS1.2 client side (in browser)?

The big disadvantage to users in this case would be that they could no longer access sites which don't support TLSv1.2. Data on those sites is fairly hard to find  (I found a survey from 2014, which found about 1/3 sites supported TLSv1.2, but that's ancient in web terms), so this might be a huge problem, or might be a non-issue, depending on what your staff need to access.

Some of the known issues with earlier TLS versions are actually implementation issues with servers which support them. For those, there isn't any direct client benefit to disabling the protocols.

In terms of avoiding the use of 3DES and other weak ciphers, that's a separate issue - you can use 3DES with TLSv1.2, although there is usually very little call to do so, since a system with support for TLSv1.2 will support stronger ciphers. I'm not aware of a reliable method to reject the use of specific ciphers from the client side.


That hostname file is owned by group ID 1002, and there is no entry in /etc/group mapping any group name to GID 1002, so ls -l simply shows the group number instead of a name.  And when a bare GID is displayed, unlike a named group, it is right-justified, making it look like it has leading spaces compared to any longer group names.  Here you can see with three files that I created and gave user/group ownerships that would demonstrate this:

$ ls -l foo*
-rw-r--r-- 1 gowenfawr          1002 0 Aug 23 01:29 foo
-rw-r--r-- 1 systemd-resolve nogroup 0 Aug 23 01:30 foo2
-rw-r--r-- 1 gowenfawr       cdrom   0 Aug 23 01:33 foo3
$

There's no particular security concern here, except perhaps that somehow your /etc/hostname file got it's group ownership changed.  You might want to search for any users which belong to that group:

$ awk -F: '$4 == 1002 {print $0}' /etc/passwd

and you might want to search for other files with that group ownership:

$ find /etc -gid 1002 -ls
   136023      4 -rw-r--r-- 1 root   1002    25 Aug 13 05:26 /etc/hostname

If you were to find that, say, /etc/passwd and /etc/shadow were owned by 1002, that would like indicate a serious security concern.

If, as you comment, /etc/resolv.conf and /etc/network/interfaces are also owned by that file, then you almost certainly have a DHCP client or other network manager that is managing those files and setting the group ownership to 1002 when it updates them, likely in response to a configuration file that says to use GID 1002.  A blunt way to check for this would be

$ grep -r 1002 /etc/*

but that may have a false positive or two.  If you find a networky named config file with an entry like "group = 1002" then that's your culprit :)


How to patch Bash on OSX in wake of "shellshock"?

First, you don't need to do this unless you are are offering web services to the public internet from your Mac. If you are not, wait until there is an official security update from Apple.

However, if you are offering web services, you might want to update.

Official Patch

Apple has released an Official Bash Security Update Here

Checking whether you are vulnerable

To confirm that you are using an outdated bash:

$ which bash
/bin/bash
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

The most current bash is 4.3.25

Unofficial Update Method: Compile Bash from Source Code using Homebrew

If you don't have Xcode installed, you'll need the Xcode command line tools, which can be installed by

$ xcode-select --install

Or from the developer portal https://developer.apple.com/downloads/index.action?=command%20line%20tools download command_line_tools_for_osx_10.9_september_2014.dmg

To install Brew (http://brew.sh):

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Then do:

$ brew doctor

Follow any instructions if there are problems. Many common problems are addressed at http://www.moncefbelyamani.com/how-to-install-xcode-homebrew-git-rvm-ruby-on-mac/#troubleshoot-homebrew

Then update brew to the latest list of packages:

$ brew update

To get the latest bash 4.3.25:

$ brew install bash

This installs bash into /usr/local/Cellar/bash/4.3.25/bin/bash

The old bash and sh still exists at /bin, so after installing you'll rename the old executables to a new file.

$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old

If you are very paranoid, you can remove execute permissions on the bash_old

$ sudo chmod a-x /bin/bash_old /bin/sh_old

Then create a symbolic link to the new bash 4.3.25 that brew installed.

$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh

Reboot and it is complete.

A warning — this may break some existing shell scripts that might rely on bash 3.2 or the differences that the Mac sh has over the linux sh. There is a much more sophisticated answer to replacing bash and sh from sources at
https://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7

In most cases it is best to wait for official updates.

-- Christopher Allen


If I use SSL, do I need to hash the password before sending it to the server?

There is generally no reason to encrypt passwords client-side. Let's consider a situation without SSL first, but with password encryption:

Bob is logging in to his account. He goes to the login page, enters his username and password, and logs in. As Eve is monitoring the exchange, she does not see the password, as it is encrypted.

This would only happen, however, if Eve is only monitoring the connection (which is almost never). Here's what would actually happen if Eve could modify the connection:

Bob is logging in to his account. He goes to the login page. However, Eve intercepts this request and removes the encryption code. Bob enters his username and password, and logs in. As Eve is monitoring the exchange, she does see the password, as it is not encrypted. To make Bob not suspect anything, she forwards the request with the encrypted password to the server and returns the session token to Bob.

In this situation, we can see that encryption is useless when the encryption code can be compromised. It would be useful, however, when the application's code can be trusted (e.g. delivered by a CD and signed by the developer) and the data is exchanged over an insecure connection (i.e. without SSL). This isn't the case with a website over HTTP.

What if this was done over SSL? Well, there would still be no point in encryption client-side. The attacker wouldn't be able to see the exchange, and if it was compromised, then the attack shown above could be used. Also, this raises a point of rolling your own crypto: yes, you aren't making the algorithms yourself, but you are using encryption somewhere where it is done elsewhere. Also, people who have JS disabled or have browsers without the crypto API, the whole thing would not work. The point of how JS may be insecure isn't that serious, as unless specific HTTP headers are sent, JS would be able to grab the password anyways.


Keep receiving delivery failures for emails im not sending

The most likely culprit here is that somebody is spoofing addresses from your domain. There are a few ways that you can help remote network operators identify that the mail was likely spoofed. The main two things you can do is:

Setup Sender Policy Framework (SPF) records to identify which email servers are the only authorized email servers for your domain.
Setup DomainKeys Identified Mail (DKIM) to sign all your outgoing mail so remote email servers can drop mail that either not signed or has a broken signature.

Google Apps makes setting up both things really easy from an administrator standpoint.

Neither SPF or DKIM will prevent people from spoofing email from your domain, but it certainly helps prevent email server operators from processing and delivering any spoofed spammy mail.


Theoretically anyone who is capable of connecting to your network is capable of sharing it without your permission.  Any device connected to your network can create a private LAN within the original LAN and share the Internet connection by allowing devices to correct to the new, inner LAN.  This is sometimes known as a double-NAT.  If the repeater is configured this way, then from your point of view there will only be one additional device on the network (the repeater) no matter how many people connect to the repeater.

Fortunately, most off-the-shelf consumer repeaters do not normally work this way; instead of creating a new LAN the repeater will extend (bridge) the original LAN, so anyone who connects to the repeater will be connected to your main network and thus be subjected to MAC filtering.  Even so, your best bet would be to talk to your neighbor to make sure the repeater is extending your LAN rather than creating a new one.

You should also be aware that MAC authentication is a very weak method of wireless security.  All devices connected to a wireless network broadcast their MAC addresses in plaintext, so it's trivial to listen for them and then spoof the MAC address of a valid client.  If MAC authentication is your sole method of protection, you should really consider giving your customers WPA2 keys instead. If you have the necessary equipment to do WPA2-Enterprise you can even give each customer a distinct login and password.


How to inject XSS using Response Splitting in the following scenario?

You should try the scenario like this;

request
POST /Login?redir=/%E5%98%8D%E5%98%8ALocation:%20https:%2f%2fevil%2ecom HTTP/1.1
.
.
.

Maybe response will be like this;

response
HTTP/1.1 302 Moved Temporarily
.
.
.
Location: https://evil.com
.
.

Open Redirect Vuln. (https://cwe.mitre.org/data/definitions/601.html)


Is it sensible to tunnel TLS traffic over another TLS?

If I understand it correctly, this is a rough network diagram of your situation:

You're saying A and B want to talk, but they can't directly so they use Relay. You are thinking of having A set up an encrypted connection (TLS) to Relay and then using Relay as a proxy for connecting (over yet another TLS tunnel) to B.

This sounds complicated, but basically if you use an https proxy or any VPN server (say, mycompany.example) and connect to another https site (say, bank.example), you are already layering encryption on encryption. Let's see how the possible options work out (layering or not layering).

Option 1: encrypt A<->B but not A<->Relay nor B<->Relay

If you don't tunnel inside of the tunnel, you would be sending packets from A to Relay and from Relay to B unencrypted. But since they are destined for B, the traffic will be encrypted for B, nobody can read the connection contents (only A and B themselves). The only information you are leaking to anyone listening on the path between A<->Relay and Relay<->B is that A and B are communicating. The Relay will not be able to read the connection contents.

Option 2: encrypt A->Relay and A->B

If, like you're asking, there is a tunnel between A and Relay and between A and B, then people listening on A<->Relay can only see that A is communicating with Relay; and people listening on Relay<->B will again only see Relay communicating with B. The Relay will not be able to read the connection contents.

Option 3: encrypt A->Relay and B->Relay

Finally there is the option of encrypting the connection from A to Relay but not from A to B (and assuming B still sets up a (TLS) connection to Relay because it's behind NAT). In that case the traffic is transparent for Relay, but anyone observing will only see the connection from A to Relay and from B to Relay.

So it depends on whether it's an issue if people intercepting the lines can see the destination of the packets (namely A and B). Double encryption means double CPU power for A and B (only singular for Relay since it doesn't decrypt the contents, only the outer layer), but I'm not sure that makes a big difference or you would have mentioned it.

(Credits: the image was made with https://draw.io. The XML is in the source of this post.)


Can ssh keyfile security be broken in a few hours if the file is exposed?

No, your SSH key can't be broken in a few hours if you choose a strong passphrase.  I read the web page you quoted, and it is just bad writing that leaves a mistaken impression.  The statement there is inartfully phrased.  The website claims:

  An SSH key passphrase is a secondary form of security that gives you a little time when your keys are stolen. If your RSA key has a strong passphrase, it might take your attacker a few hours to guess by brute force. That extra time should be enough to log in to any computers you have an account on, delete your old key from the .ssh/authorized_keys file, and add a new key.

That's phrased in a pretty confusing way.  I suspect what they mean to say is that a good passphrase will take at least several hours to crack.  In fact, a strong passphrase will take a lot longer than that to crack; probably days or years, or longer, depending upon how strong your passphrase is.

Because of poor phrasing, this web page might leave the impression that even if you choose a strong passphrase, an attacker could still recover your SSH key in at most a few hours.  That is not correct.  If you have a strong passphrase, it will take a long time for an attacker to recover your SSH private key.

Someone with permission to edit the web page should fix it to correct the confusing phrasing.


Any usable random source for keys will give you keys that are as randomly distributed across the whole key space as possible.

Thus, the expectation value for "an attacker tries this key in their N-th attempt" is N=|key space|/2.

If you have knowledge of your attacker's search order, you can of course exploit that. But in practice, it's always going to be worse to restrict your key space (or change the uniformity of key generation), because you then give your attacker, who previously had 0 bit of info on your key, some amount of bits of certainity about your key.

Best case is that the slow down in attack is linear to the secrecy you've lost, but realistically, you weaken your overall system, because from a non-uniformity of the key bits follow non-uniformities in the ciphering process, and suddenly you're converting a cipher against which the best attack is a brute-force one, into one where you can make statements about the plaintext from the ciphertext without even knowing the key completely.

So, no, don't do that.


Thanks. Other than using nmap built into the mac, I also was using Kali on a VirtualBox image which was experiencing the same issue.

I started to believe the issue was being caused by the Fios Actiontec router, but during my testing, I was playing with the Virutalbox network settings for the image. By setting the Kali VM to use bridge mode instead of NAT, Kali started working fine.
It still doesnt work using the Mac's nmap, but now that Kali is working, it doesnt matter.

Thanks for all the help!


New files appearing on my web server (I did not create)

Yes, you should be worried.  Those are most likely chunks of a segmented file(s).  Your system appears to be being used by someone to distribute files.  Likely whoever had the keylogger got your server username and password from there.  You should definitely change all of your passwords and consider resinstalling the operating system on your local box from original media or at least restore a known uncompromised backup if you can tell when you got comproised.

You should also contact your hosting provider's security team and let them know what happened.  They may be able to assist you with clean up and ensure you get your account back under your control safely.

Good Luck.


When should police be notified about host intrusion?

I can only provide one Dutch case: A webdesign and hosting company (with approximately 100 clients) had a password hacked that was used for everything. (Yeah, don't get me started on all other security issues there.) A few websites were defaced, and private information from the owner was made public. Overall relatively little damage, but damage with a clear origin (we had the attacker's IP which was not a proxy and traced back to the same city).

We printed out the logfiles that we were able to get together (logging was malfunctioning on most websites...), and my boss went to the police with the information. At the police station, nobody knew anything about computers, but everything was written down best they could. The people usually taking these cases were having a training and would probably pick it up next week.

Next week came and passed. Next month came and passed. We called for updates, nothing. The case would have been a simple lookup (ISPs are required to log which IP is owned by whom at any given time), but they didn't do anything.

To the best of my knowledge, it's now 6 months later and the case hasn't even been looked at yet. I still think you should always go to the police with a breach, but the odds of it being solved are low when there is no big money involved.


What ways can you monitor all changes made on a Linux server?

Two different approaches could be used.

File integrity monitoring.

Host based intrusion detection software such as AIDE can be configured to record hashes of important files on the system and then perform periodic scans to report on files that have changed.  In your case, if the contractors sometimes have root access, some steps would need to be taken to ensure they could not modify the hashes to avoid changes being detected.

Audit logging

The Linux auditd Daemon can be configured to log all commands run by an administrator.  As described in this question;
In https://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers

In this case it would be wise to use syslog to send the logs to a remote server that the contractors do not have access to in order to prevent them tampering with the logs.


Why is my RADIUS Certificate not automatically signed with the root CA Certificate on my iPhone

Please bear in mind that whatever you are trying to use is dependent of mutual support on the server/authenticator and client sides. This is not always trivial to achieve.

Why do I need to trust the server's certificate if I have the root CA's certificate installed?

This behaviour is entirely dependent on the client's implementation (the supplicant). Yes having the server cert signed by the CA should be seen as a significant proof of trust, provided it's not expired or revoked (if the client checks).
On a windows workstation for example you can either trust CAs specifically or let the user review and accept the server side certificate at the first connection. But if the server side cert is signed by one of the selected CAs, the user doesn't get a dialog about the cert.

AFAIK the whole point of certificate-based authentication is to prevent MiTM attacks that other methods are vulnerable against.

Conceptually it is instead about mutual authentication, and providing solid proof to the client that the server is being spoofed. It is up to the client to decide what to do with that information. Hopefully and usually it drops the connection. If not, it's as much at risk of MiTM as if it didn't use cert based authentication.

There is a username option when selecting the network on the iPhone, which does get matched against a backend SQL database by the freeradius server regardless of that username existing the server accepts the authentication. This page notes that the username is used in inner and outer authentication but to me, that doesn't seem to make sense as there is no inner and outer identity in EAP-TLS.

Conceptually you could have another EAP authentication dialog within the EAP-TLS channel once that is established. For example EAP-TTLS is often used to protect less secure authentication protocols like PAP. So this is left as an option for the server and client implementations to negotiate through the existing supported protocols and/or custom implementations.
This could also be used for a kind of multi factor authentication whereby a station and a user authenticate separately so that the admin can revoke access to the device or the user independently.


Does a 'mailto:' hyperlink spoil any preceding email obfuscation efforts in PDF?

Certainly all private information in any file that is published online and accessible by a potential adversary is at risk.

Regarding spam this is not the likeliest scenario, as they are plenty other sources of email adresses that require far less effort, such as leaked databases, mailing lists, public profiles of website showing your email address and any kind of public record such as DNS or in Germany the Impressum (which contains contact information of the webmaster and is legally required).
There are many more source, and mailto: is harvested specifically from scanned websites containing contact information. I have not found evidence that email harvesting is also done from PDF, but it certainly would be possible.

The conclusion is that it certainly makes sense to remove mailto:, in general treat any information that is contained in a publicly accessible file as analyzed by someone. So if some content is private and you do not want anybody to misuse it, don't put it in. What is removed cannot be misused.


Strange android app … possibly a mass malware?

Are you running Android 4.0.4 (Wikipedia lists it as the latest)? While they're not widespread, there is at least a few known vulnerabilities (such as this one and this one), and given that it's about a year old, I wouldn't be surprised if there were a few bits of malware like this around.

The malware you have contracted sounds like what Symantec is calling Android.Updtbot, and you may have some luck following their Removal instructions, or at least by downloading and installing a scanner of some sort to check over the phone.

If you're unable to scan/remove the malware; you're likely going to need to wipe the device completely and restore a clean version of the OS.

As a preventative measure, after cleaning or wiping your phone; be careful not to open links provided by someone you don't know, and you shouldn't open links from someone you do know that you weren't expecting to receive - whether they arrived by SMS, email or whatever. Since you have the option of installing and running anti-malware and anti-virus on your device, much like on your PC, you should install and keep up to date some sort of malware protection.


How to completely remove all traces of a file on Linux? (Overriding everything if needed)

Install scrub (secure erasing tool) and bleachbit (slack space scrubber)


Let's start with your last constraint: if the database is compromised, then attacker must not be able to extract a key from the database and decrypt messages.  A simple way to ensure this is make sure the key is not in the database.  That is, whatever keys/etc. are required to decrypt the messages are stored by each client, not centrally.

You said you don't want to encrypt each message for each person using their public key.  Is a per-person symmetric key also out?  The disadvantage there is that in an N-person group each message would have N signatures, and there would need to be N2 keys - so this is not ideal for large groups.

Instead, what if there was a single "group key", which everybody uses to encrypt their messages?  Everybody in this group would have this key.  Part of "joining" a group is where an existing member shares their copy of the key with you.  To prove authorship (if that's desired) you could sign each message with the public key of the author - edited messages would be signed with the public key of the editor.

If there's a single group key, you would need to rotate this key whenever someone got booted out from the group.  This would require a user commonly-accepted as a "group administrator" sending a message to each individual member telling them the new key.  In order for new members to be able to read the entire history, it could make sense for the old key to be encrypted with the new key and posted to the group (possibly as part of the "X has left the group" notification), so that new members can follow the message history back across this boundary.

So: a single group key stored in the clients not the servers, keys replaced whenever a member leaves the group and sent to each member (public-key encryted) by an admin, and each message/edit optionally signed by public key (different from the previous one, because you never sign and encrypt with the same key).  This seems to me like it would fit your requirements,  but it falls short on some other requirements - the gold standard is Whisper Systems, so you could read about how they do things.


Ways to reduce supply chain risks for java apps

Like I mentioned in my comment, supply chain risks can't be completely eliminated. This question, which I also linked to, explains it rather well.
Let's have a look at each specific point of concern:
Dependencies are downloaded as already compiled code.
This could be because the dependency is some proprietary code and source code is not available, or simply out of convenience.
You could either decompile and reverse engineer what the dependency does, or analyze the source code if available. The problem is, nobody does that. It's thousands of lines of code - your developers already have an enormous codebase to deal with, so asking them to basically learn a whole new codebase for every dependency will get people to question the sanity of whoever ordered that. In other words: Analyzing the source code for every dependency, just to ensure it doesn't contain any bugs or backdoors, will bring development to a standstill. And then you have to assume that programmers will spot the backdoor. Just for fun, here's a backdoor:
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

Try finding it. Keep in mind that this is 2 lines and you know there is a backdoor. Now imagine playing the same game with thousands of lines of code, and not knowing if there is one.
Problems with Jar Signatures
The fact that signatures are not checked by default is a feature. Requiring every Jar to be signed is not something that most developers care about - still only takes a handful of flags to enable that, so that's not the issue.
Problems arise only when developers of some library you want to use don't sign their Jars. Either use a different library or ask the developer to sign their Jars. However, even signed Jars don't stop an attacker from inserting a backdoor into the source code, depending on how well the signing practices of the developer are.
In essence, signing jars can help, but it's not the be-all-end-all of supply chain attacks. And against a malicious developer, it doesn't protect at all.
Developers can add arbitrary dependencies
Yeah, the point of build systems is to be easy to use and add as little friction as possible. That means developers are encouraged by the system to just add what they need.
Now, a responsible developer would consider the downsides of adding a new dependency to a project, weigh in whether this would be a reasonable thing to do or not, and then check how trustworthy the library and its developer is.
A less responsible developer just adds a library that sounds kind-of like it does what they need it to do, and then just see if it works. All an attacker needs to do is create a package named html-parser or json and tons of people will fly to it.
In summary...
nothing you can really do in practice. You can do the things suggested in the linked answer, such as running separate environments, doing code audits for specific versions, etc.. Aside from that, you just have to trust.


Are sequential patterns used in practice?

This depends on a lot of factors, like: vendor of the IDS, the settings, which signature is being triggered and what kind of attack is being initiated. In short yes, UTMs of the common vendors (CP, Fortinet, PANW) all store a copy of the traffic in memory for analysis.
For instance, you could configure in an IDS that a RDP Brute-force attack is only flagged as such when the signature has been identified X amount of times in the last N seconds. This is to prevent any false positives, especially when you have an IPS blade on top of it conducting preventive actions.
With regards to SIEM this completely flexible, you can build use-cases in numerous ways and correlate alerts from  various sources. For instance in the case mentioned above, you could correlate this with the log sources from the source-device and a Directory Service.


Why do Chrome extensions need access to 'all my data' and 'browsing activity'?

I install a plugin that allows me to click on any part of a page and it gives me the color of the clicked object

For this to work, the plugin needs to register a click event handler and it needs to interact with the document object model of the current HTML page.

HTML was originally designed to share scientific documents. And while we build complex web applications today, it remains document orientated at its core.

The browsers cannot know what parts of a HTML page contain sensitive information. For example if you login to StackExchange, it will display your username in the top navigation bar. On your bank website there will be information on your money transfer and account balance. There is no structural difference between those informations and a text saying "Your answer".

Chrome does offer some protection against malicious plugins by preventing them from arbitrarily accessing your harddisk. But a plugin that needs to interact with webpages, can do anything to them. All other browsers have the same issues, they just don't go into detail.


How many characters should a password be?

As long and as complex as allowed

You're using a password manager, so opt for the best you can do based on the limitations imposed by the website. If it will take you just as long to generate an 8 character password as a 100 character password that meets the requirements, it would be silly to go with less entropy for the sake of meeting some artificial limit you put on yourself.


How can I tell if a program (in this case Jitsi Meet Electron) has bad-enough vulnerablities making it unsafe for current use and/or protect myself?

Answering the question stated in the body, not on the title, you could run the wrapper under firejail, or even better, as a snap. Properly done, the application would run with no access to your filesystem, without needing a full VM / container (such as provided by QubeOS).
(note when using snaps, you should still care about updates inside the snap)
Jitsi Meet does work with firefox (unless disabled, the server could refuse it service), but Chrome/Chromium does indeed work better with audio/video applications (probably due to the way their javascript and multimedia stack works).
Since you seem to be using some kind of *nix distribution, you probably want to use Chromium rather than Google Chrome (Google Chrome is Chromium plus a few proprietary bits, plus branding). Chromium is probably the one packaged by your distribution. You may still dislike it, but most privacy issues should have been disabled (depending also on the view of downstream about patching and how (un)desirable those 'features' are).


How does iOS screenshot prevention (ScreenShield by Confide) work under the hood?

It's a security theater. It's a way to sell people products based on the appearance of security, without really adding any security.

I'd be really wary about any security claims made by products that touted such security theater. And yes, according to security researcher Quarkslab, the actual security implementation in Confide seems to be severely lacking to the claims made by the app. The encryption, while using the technologies similar to those used for end to end encryption, is effectively broken and doesn't really provide the same security property as a properly implemented end to end encryption.

With that out of the way:

  how does the screenshot prevention work under the hood.

They're simply checking for events/conditions that happens to coincide with a screenshot. I'm not familiar with the exact implementation on Confide, but detecting screenshot in iOS, while not straightforward, isn't that difficult. According to chpwn:

  How to detect screenshots on iOS (like SnapChat)

  The process is pretty simple, and relies on a quirk of iOS: taking a screenshot cancels all touches on the screen. Because of that, anything that you want to protect will require you to have the user to touch the screen to see. If that works for your purposes, the general solution is to simply intercept the touch cancellation, and quickly remove any sensitive information from the screen.

No, Confide wasn't the first to figure out a way to detect screenshot in iOS. I very highly doubt that their patent is worth anything other than marketing talk.


What are some good, free tools to run automated security audits for PHP code?

There's a static code analysis tool for PHP called RIPS.  I've not had the chance to use it as yet, but it sounds like it's in the right kind of area for what you're looking to do.

On the commercial tool side of things, Fortify SCA has support for PHP, as far as I know.


Difference between white-box testing and secure code review

Security code review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. OWASP

With this in mind consider Grey-box testing:

  A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A grey-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used. Wikipedia

Pentesters will identify vulnerabilities by reverse engineering software into assembly code and working from there to identify attack vectors, such as a buffer overflow. But, by the definition above secure code review must be white-box testing.

To answer your question, secure code review is performed by white-box testing, exclusively. There may be some instances where individuals could skew this definition to fit the example above, but as reverse engineering assembly code is not source code, I will not acknowledge this.


You are using bound params which is a great start. This tiny snippet of code should be fine against regular input SQLi but there are a few other potential issues:

You are not validating/sanitising the input. Although your are using bind, you should still be doing this
You are assigning the password to a session variable. Why? You effectively have the plain text PW floating around your web app
You are not sanitising the DB output before storing it in the SESSION variables. Not knowing what your other code looks it is impossible to see how this would be exploited. Just don't take the chance.


Ad-Banner Rendering Sites Serve with malicious content - how to respond?

My question is, why all the Ad-severing servers are termed as CnC in most reports like they claimed in this below report and how do we respond?

Because the way advertisement is done today on the internet make it easy to use ads to serve malware or do social attacks. There is already the term Malvertisement for malware delivery through advertisements and as far as I know all of the major advertising networks were affected already. If you search for malvertisement you will find lots of examples, reports that it is rapidly increasing and that is even used in micro-targeted attacks.

Unfortunately there is no sure way to find out if a place you offer for advertisement will serve malware. The process of including the advertisement is very dynamic and lots of parties are involved and real time bidding makes it easy to include the malvertisement only at specific times, for specific browsers, specific source IP address or similar. This way it is impossible to find out with random inspection if there will be malvertisement or not.

Part of these malvertisement attacks are compromised ad-servers, like the one from Yahoo in 2014, OpenX several times or MadAdsMedia 2015.


http://scanme.nmap.org/

This host exist solely for the purpose of testing nmap. Here is the wording from the page:

  We set up this machine to help folks learn about Nmap and also to
  test and make sure that their Nmap installation (or Internet
  connection) is working properly. You are authorized to scan this
  machine with Nmap or other port scanners. Try not to hammer on the
  server too hard. A few scans in a day is fine, but dont scan 100 times
  a day or use this site to test your ssh brute-force password cracking
  tool.


Can BeEF hooking be stopped with Content Security Policies

Yes. The Beef hook is just an advanced payload for an XSS attack that relies upon the script-src tag. If you have a healthy Content-Security-Policy, victims browser will refuse to load the external beef hook.

CSP is a secondary line of defense in case you have a HTML-injection vulnerability.