Is a self signed certificate sufficient to prove the integrity of my executable? I have an EXE file on Windows that I have to distribute around. It's based on tclkit so an adversary could unpack it, change some tcl script inside and repack the exe.

I would like to know if this ever happen, so that if anyone complains about what they received I can check if the file is really the one I sent or if anyone modified it.

I plan to use a self-signed certificate to sign the exe, expecting that nobody would be able to sign it again without having my private key.

Is my reasoning correct? Or there could be a way to change the file and still make it appear as if it was signed by me?

It's important that the person receiving the file checks it against your public key. Anyone can create a self-signed certificate, and you can put whatever meta-data you want into it. So, two self-signed certificates can look and behave identically, the only thing that differentiates them is the key pair used to sign it.

In other words, and answering your comment on Jeff's answer, you can't visually distinguish between a legit and a forged certificate, if for instance the OS or browser or whatever pops up a window showing its details. Certificates signed by a trusted authority, OTOH, will be shown together with a name/link that is harder (nigh impossible?) to be forged.

But if your public key is published/sent to your customers, they can verify (or you can later prove) whether or not the file is legit. Since nobody else know your private key, they can't create a certificate (self signed or not) that matches it, even if the meta-data look the same.


Testing malware or bad url's from a SIEM What would be a good approach for testing malware or bad URL's from things picked up from my SIEM to validate them? I was told to set up a VM for these tests but don't want it to hit the internal network.

If you have no skills in malware analysis and reverse engineering, you should try Free Automated Malware Analysis Sandboxes and Services first and install a hardened Cuckoo Sandbox in a VPS to get a detailed dynamic analysis.

To do malware analysis and reverse engineering in a VM safely and effectively, you need to learn a lot from books, videos, articles and tutorials. Browsing the website Tuts 4 You would give you lots of useful reading materials.

Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software [Michael Sikorski, Andrew Honig] is classic book for you to start the malware analysis journey.

Reverse Engineering for Beginners is a good frequently updated book to learn reverse engineering.

Open Security Training provides high quality free courses on reverse engineering & malware analysis topics.

Hasherezade has more tips for you on her blog:
https://hshrzd.wordpress.com/how-to-start/


How secure are my passwords in the hands of Firefox using a Master Password? I'm relying on Firefox to remember my passwords, using a Master Password of more than 25 characters. How secure is this set-up?

In short - Firefox uses triple DES in CBC mode with Master Password.

More details: nice article about this topic is here: http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html and if you want some more details, here is mozillaZine article: http://kb.mozillazine.org/Master_password. This article gives you a detailed comparison between the major browsers.

It is believed that it is safe to store passwords such way, however, I do not trust any software. Maybe it sounds too paranoid, but we can never know where the vulnerability hides.


How does someone conduct a risk assessment of a B2B Integration? I'm not very familiar with B2B integrations. No one in our small organization is, but we need to conduct some assessments. How does one assess a B2B integration? It seems like there would be gaps between a risk assessment framework like NIST or ISO and both the technical and non-technical elements of an integration.

You conduct a B2B integration risk assessment the same way you generally do any other risk assessment. What are the risks of connecting your enterprise system with another business' enterprise system? What do you allow them to do in your system? Do you restrict them from accessing systems they shouldn't with ACLs? Do you make sure there are no shared accounts they use to interact with your system? Do you log all of the activity they do within your network? All of the things a framework like NIST does for your entire enterprise can be pointed at that connection with the other business.


Why does Adobe recommend not setting CSP headers for its web fonts? In this help site, Adobe recommends not setting CSP for web fonts saying:

  The CSP policy does not allow you to set an exception for inline styles added by a script from a specific domain.

and

  Adobe Fonts uses inline styles and fonts as data URIs to provide our service, and making exceptions for these negates a lot of the protection provided by a CSP.

What do they mean by it? And if my site already has CSP set, how do I use Adobe fonts if I shouldn't set CSP for it?

Disabling CSP altogether is not recommended, but you do have a security impact by allowing inline styles. For example, you could use the following policy:

default-src 'self';
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https: 'report-sample';
style-src 'self' 'nonce-rAnd0m123';
object-src 'none';
base-uri 'none';
report-uri https://csp.example.com;

This would use 'strict-dynamic' for scripts, and would require you to add a nonce to every tag where Adobe Fonts wants to inject their webfonts. This may or may not be possible, depending on how Adobe Fonts works.

What is the worst that could happen?

If you really have to allow 'unsafe-inline' in your style-src directive, then you may open yourself up to CSS Injection, which may lead to stolen credentials. Of course, CSP should not your only defense against such things, so please don't see it as such.

What about the CSP directive on their website?

Adobe suggests the following CSP directive:

script-src 'self' use.typekit.net;
style-src 'self' 'unsafe-inline' use.typekit.net;
img-src 'self' p.typekit.net;
connect-src performance.typekit.net

The focus on whitelists suggests that this directive was added back when CSP was still very young and only whitelist-based approaches were possible. By using the 'nonce-' approach, you cam ensure that only the inline scripts loaded in specific locations are allowed.


Storing encryption keys Think of this scenario:

you've got an application that manages some files
some of these files contain sensitive data that should be encrypted on disk
the application is configured to start by itself after a reboot
the server on which the application runs is patched and rebooted regularily

How would you manage the encryption key?

For this situation unless using a hardware encryption module the raw keys have to be available to the machine. For the encryption to offer any real benefit the keys must be stored in a format which is harder to read than the underlying files.

This means either

store the files on a separate machine to the application. If the application server security model is broken they still have access to everything but if the file server is accessed all they get is encrypted information.
Store the keys in a way that they aren't readable to the application. This is usually done by having a process running as a more privileged user read the keys then pass them through to the application on start. This means the only way any attacker gaining access as the same user as the application (assuming no opportunity for privilege escalation) can get hold of the keys is to read them out of memory or a core dump of the application.


How significant is the invalid SSL cert at aoprals.state.gov? For up to 4 weeks, the US Department of State's Office of Allowances web site has been using a security certificate whose chain of trust only goes to the State Dept's own CA, with no root CA. Browsers put up scary warnings.

I imagine tech journalists would put this on their front pages, but they haven't. Am I overly concerned, or should I be shouting louder about this? I don't know what the Office of Allowances does.
Update: thanks for the great explanations, deploying their own root cert internally makes sense for some purposes.

You should not be shouting about this at all, it's (probably) totally fine.

This does look a bit odd, possibly a misconfiguration, but it depends who the target audience of that web page is.

Option 1 "bad cert") This site is meant to be consumed by the general public and should have a publicly-trusted certificate.
Option 2 "should be firewalled") This site is meant to be consumed by members of that department and should probably be behind a firewall (ie not accessible to the internet)
Option 3 "working as intended") This site is meant to be consumed by members of other government departments, so is meant to be internet-facing, but only consumed by people with the government's root certs installed in their browsers. (ie they really don't care whether you trust their site or not because you are not the target audience).

A quick look at the web page looks like it's meant to be accessed by government employees abroad who work for various departments, which sounds a lot like Option 3 "working as intended":

  The office compiles statistics of living costs abroad, quarters allowances, hardship differentials, and danger pay allowances and computes the established allowances to compensate U.S. Government civilian employees for costs and hardships related to assignments abroad.


Removing Unnecessary Services & Packages in a MySQL Ubuntu 12.04 Server As part of hardening a MySQL 5.6 server running on Ubuntu 12.04 LTS, unnecessary services and packages will have to be removed.

For a server that is serving only as a MySQL server, what services and packages should we remove? Is there a list of services/packages that we can use?

you're going the wrong way.

for debian-like systems the right way is:

install a minimal system (e.g. from netinst)
install the hardened-packages
install wanted servers/applications

this assures to have only needed services and packages installed, no need to remove unwanted services like 10 years ago :)


IT Contractor with domain administrator credentials best practice? We are going to be hiring an external contractor to do some work on our SharePoint server and they will need admin rights for kerberos setup and etc.

What are the best practices of setting up the user account that this contractor will remote in as?

Are there some legal documents that should be signed that will protect our enterprise?

Also we will be setting up VPN access for this user through a Meraki firewall, are there any steps that should be taken there?

Is there any way to track this users activity in the network?

So general best practices first:

Do not use generic accounts (i.e. ConsultantCo) rather use named accounts (i.e. JSmith_Consultant). One for each contractor.
The contractor probably doesn't need Domain Admin. Local Admin on the SharePoint server (and whatever other systems are needed) should be sufficient.
Enable logging on the box(es). If possible, ship the logs to another server that the consultant doesn't have access to for review/audit purposes.
Enable time-based logins. In other words, restrict the user's ability to logon to only the times they should be doing work.

For Meraki MX Appliances:

Similarly, make sure the user does not have excessive permissions, if the Meraki VPN users are not tied to AD, then configure a separate (complex) password for this account as well.
Enable logging, Meraki supports exporting to syslog for reviewing activity.
I don't believe Meraki has implemented time restrictions on VPN access yet, so manually disable the account when not in use (nights, weekends, holidays, etc.)


Exchange of DEK and KEK (encryption keys) between app server and key server In my application, it is required to encrypt a user's data before inserting it into the mysql database. I am using AES algorithm to encrypt the data using a 256 bit hash (and is calling it Data Encryption Key, or DEK in short).

To make the system more secure, instead of storing DEK in plain text in the app server, it is stored in encrypted form (en_dek) in the app server. The key to encrypt the DEK is stored in a totally separate server and is called the Key Encryption Key (KEK). So everytime a data is to be encrypted / decrypted, first the KEK is used to decrypt the en_dek, which gives me the actual DEK, and then this DEK is used to encrypt / decrypt the user's data.

Now my question is:

[1] Should I send (en_dek + data) to the key server or should I fetch the KEK into the app server? Which one is more safe practice?

[2] Both these methods have a flaw that if an attacker is able to get access to either of these servers, he will get to know both KEK and DEK. How can we prevent this?

[3] When we talk about key rotation, which of the two keys (DEK and KEK) is rotated?

Should I send (en_dek + data) to the key server or should I fetch the KEK into the app server? Which one is more safe practice?

Sending the key en_dek to the key server to be handled there is pretty much how a hardware security module works at a high level. The advantage of this approach is that the key material never touches the application server. So any compromise of the application server can only decrypt the keys that are currently in memory, as well as potentially submit decryption requests to the key server. However, the attacker does not automatically get access to the master key itself, which is important.

Given you're already talking about sending the data to another system to be decrypted, I wonder if it might not be better simply to send the data, thereby hiding the key entirely from the application server?

In any scheme like this, the security of the key depends entirely on the security of the server or HSM on which it is stored. Usually, true HSMs are reasonably good at protecting keys unless you're very handy with electronics.

  Both these methods have a flaw that if an attacker is able to get access to either of these servers, he will get to know both KEK and DEK. How can we prevent this?

You can't, except by using a dedicated HSM, which is essentially what you're discussing building. I would simplify the scheme and keep the keys on one server dedicated only to cryptographic operations, and keep that server locked down.

For more on these two points, see the OWASP rules on cryptographic storage.

  When we talk about key rotation, which of the two keys (DEK and KEK) is rotated?

Ideally, both. Rotating the KEK should be easier, since DEKs are fixed size and there shouldn't be all that many of them. Rotating DEKs might be harder if you are encrypting lots of data.

From the OWASP page, which says it better than I can:

  Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.


valid PDF signature without using hardware HSM or usb Token I have a DMS system(alfresco) that needs to sign approx 50.000 valid signatures a year.
The signing certificate needs to be acquired from one of the affiliated sub-CA's.
So according to the Adobe CDS certificate policy, are they obligating me to use a hardware HSM or usb Token? I want to use SoftHSM instead. It is free & opensource (but no hardware).

Is this possible?

The CDS Certificate Policy (available here) specifies in section 6.1.1

  Subscriber key pairs must be generated in a manner that ensures that
  the private key is not known by anybody other than the Subscriber or a
  Subscriber’s authorized representative. Subscriber key pairs must be
  generated in a medium that prevents exportation or duplication and
  that meets or exceed FIPS 140-1 Level 2 certification standards.

SoftHSM is not FIPS 140-1 Level 2 compliant. As far as I know, level 2 and upper requires a hardware cryptographic module.

Note that the AATL program (successor of CDS) has similar requirements but it provides a larger set of Certification Authority which could provide you either a physical signature certificate or a signature SaaS solution.


How to protect web server private keys on Ubuntu with Nginx without exposing any plain text credentials? I'm developing a set of internal websites and services for a customer who has high levels of bureaucracy and strict formal rules about many things, one of them being "not storing passwords in plain text".

So, when they inspected my system configuration manual, they immediately pointed out that they could not accept storing private key passwords in a text file for Nginx to load on startup. It doesn't matter that the file is readable only by root.

My arguments, such as "if someone got root access to your server then you have bigger problems than leaked private keys", "The attacker could extract the keys from server process RAM anyway, no matter what encryption is being used", "It's a recursive problem because if I encrypt the password file, Nginx will need the password to decrypt the password file to decrypt the keys" did not work.

It seems, the customer is just used to how IIS works - the private keys are protected by CNG mechanisms and you don't have to store plain text passwords or keys or API tokens anywhere.

How do I achieve that on Ubuntu and Nginx without making things too messy?

I really don't want to migrate everything to Windows and then explain the customer why they need one more Windows Server licence when the initial idea was to use free Ubuntu server.

It is important to understand exactly what the requirements are and how they can be met, as in what is an acceptable solution to both parties. As everybody always says, security is about compromises.

You can have the pvt keys encrypted and nginx will ask for the password every time it starts. This is OK security wise, but not practical at all;
You can have the pvt keys encrypted and have nginx read the passwords off a file. Personally I find this to not have a security benefit if the password file is to be stored on the file system since there is still enough information to decrypt and reveal the pvt keys, particularly to the root user. It's merely an additional step;
You can have a system whereby you enter a passphrase into the kernel keyring every at every boot and use that to control encryption of the nginx password file. Again the passphrase can be extracted off the keyring by root, so this is an additional step that's trickier to compromise than just reading a file. Plus you need to handle the temporary decryption of the password file: A possible solution is to decrypt the password file into RAM, start nginx then scrub it from RAM immediately after the daemon starts;

You could make use of a hardware device instead of the kernel keyring that either contains keys or contains material required to decrypt content, again to expose the password file temporarily. This will make it more difficult to compromise the keys, it is not dependent on a hardware device being available;


how to check what process connects to my squid I found today, that I have open proxy (squid on Debian). I fixed the firewall rule, and now I'm not. But someone still uses this proxy - it looks like it is proxying from inside my machine. I try to find which process is using my proxy.

I have Debian with lxc-containers. squid is in one container (172.16.0.2), and I think, that process which is using my squid is on the host machine:

1520955127.112     43 172.16.0.1 TCP_MISS/200 585 GET http://766dsw.top/ - HIER_DIRECT/54.36.219.10 text/html

How to get the process? (Maybe it isn't from inside?)
I run the iptables -j LOG, and got this:

Mar 13 18:14:56 zenon kernel: FORWARD  IN=enp2s0 OUT=lxcbr0 MAC=00:19:b9:1c:83:c4:00:1d:aa:cf:bd:a0:08:00 SRC=101.254.225.243 DST=172.16.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=14541 DF PROTO=TCP SPT=49875 DPT=8080 WINDOW=256 RES=0x00 ACK URGP=0

but I remove every rule of prerouting from firewall about 8080 port and 172.16.0.2 address... and of course iptables -A FORWARD -P DROP

and somehow it still passes....

Finally found the problem - of course it was firewall.

I use droplist from this tutorial and put rules iptables -I FORWARD -j droplist somewhere in the middle of rules. But this rule has to be first rule

#!/bin/bash
_input="/root/blocked.ip.db"
IPT=/sbin/iptables

$IPT -F
$IPT -F nat
$IPT -A INPUT -P DROP
$IPT -A OUTPUT -P DROP
$IPT -A FORWARD -P DROP

$IPT -X droplist
$IPT -N droplist
egrep -v "^#|^$" $_input | while IFS= read -r ip
do
    $IPT -A droplist -i eth1 -s $ip -j LOG --log-prefix "IP BlockList "
    $IPT -A droplist -i eth1 -s $ip -j DROP
done

# Drop it
$IPT -I INPUT -j droplist
$IPT -I OUTPUT -j droplist
$IPT -I FORWARD -j droplist

and the rest of the rules


Reading locally-stored emails sent encrypted As far as I know, when Alice sends an encrypted email using PGP to Bob then the email will be encrypted using Bob's public key. Only Bob can decrypt it (as long as no one else has Bob's private key).
As far as I know, Thunderbird implements exactly this behavior. Thunderbird 78 has this function built-in, for previous versions you need the enigmail-addon, which is doing in fact the same.
But when I open Thunderbird I can read in cleartext the encrypted emails which I have sent to other people. How is this possible? Does Thunderbird store an unencrypted copy of the emails anywhere?

Thunderbird prior to the completely re-written version 78 provided encrypted GPG/PGP email support via the Enigmail plugin.
Sending encrypted email used both your public key and the recipient(s) public key(s). This was easy to see simply by selecting the sent email. You would be prompted to enter your own Private Key to decrypt the sent mail, or you could look at the message source and see the -----BEGIN PGP MESSAGE----- content.
Thunderbird 78 is a complete re-write and no longer uses Enigmail or GPG. It now uses a subset of OpenPGP.
It still includes both your public key and the recipient(s) public key(s) but it's less easy to verify, you'd have to open the email via an editor outside of Thunderbird 78 to see that the sent copy is indeed encrypted.
So what's going on with Thunderbird 78 and the OP's question, "Does Thunderbird store an unencrypted copy of the emails anywhere?"
No it doesn't store unencrypted email, it stores your Private Key and auto opens everything!
Now it gets even fuzzier.
The New Thunderbird developers will tell you that the stored Private Key is encrypted, and it is, but it's automatically accessible via another key stored in the Thunderbird database, in the clear.
The next level of fuzz is that the official line here is that if you use a master password then the database is protected by the master password. This is true, but this means all of your private keys are protected by only the same master password.
The net result is that Thunderbird 78 automatically opens all your encrypted mail because it has all your PGP secret passwords. The developers insist that this is for search and sort convenience and is what users desire.
By contrast, Enigmail never writes private passwords to disk, they exist only in your head and in RAM while being actively used. Additionally opening one key does not open other keys.
Interlink is a Thunderbird XUL based fork. It supports Enigmail and Lightning plugins. You can even drop your current Thunderbird profile (Pre-78) into Interlink and be instantly converted over. It runs on Linux and Windows.


How Secure to is to forward CCTV stream to device's cloud In my home CCTV, the video stream is forwarded to the Device's own cloud environment and we need to hook up our mobile views via that. I hope all the other device's streams are also forwarded in to the same could environment(same manufacturer). How secure is this in terms of privacy ?

How can we stream this video into our own cloud environment and view from the mobile? Can we set up our own cloud back up as well ?

How secure is this in terms of privacy ?

One can only guess: If the data are not encrypted for transport they can be easily sniffed. If the data are encrypted for transport but not at rest a hack at the cloud storage might make them available for others. If they are encrypted for rest but the provider of the cloud storage has the key they can access these. If they are encrypted on the origin device and a key is only shared with the viewing device it might be safe.

Note that in all these examples encryption means proper encryption and not some self-made algorithm or messed up implementation of well-known algorithm or weak algorithm which is often done by less experienced developers and/or because of hardware constraints on the device. The same is true for key sharing.

Apart from these a passive listener might notice when and how many data are transferred and thus make assumptions about the activity (some CCTV send only when they notice activity). And depending on the system it might be possible to block transmission of data without notice to the viewer or even replace it with different data.

  How can we stream this video into our own cloud environment and view from the mobile? Can we set up our own cloud back up as well ?

That's a product specific question you have to ask the vendor.


Could you store your passwords in a phone app governed by a QR code? I had an idea a little while back to have an ID card with a QR code on it that you kept in your wallet. When you want to access your passwords (view them directly), you need your ID card and to scan it with your password protected iPhone. This then reveals your desired passwords.

But I'm thinking about it more and it doesn't seem to offer any extra "security" or protection of your passwords. You have your phone password memorized, so that's secure. Once you get into your phone and open the customized QR reading password app, you could just have direct access to your passwords right there instead of having the QR code layer. But, say we add the QR code step, of scanning the QR code to get access. Maybe it only works on your phone. So you have your phone password and a QR code protecting your password.

Does something like this offer any extra security? I'm thinking along the lines of n-factor auth and having an actual physical ID card in the mix.

Could ...? Sure. I think you meant Should ...? No, one shouldn't rely on QR code. Using QR code is similar to writing password on a sticker, but is even worse. The major difference is, that QR code is designed to be easily read by phones.

QR code can be duplicated. For instance, when you are waiting in line, many people around you can easily make picture of your QR code when you are using it, and then they can reuse whenever they want. Reading a text on your ID card from some distance can be hard. But QR code can be recognized much easier from the same distance.


Disabling RC4 HMAC encryption in Windows Active Directory prevents current Kerberos attacks? Disabling RC4 HMAC encryption in Windows Active Directory prevents current Kerberos attacks?

I understand that RC4 HMAC encryption is dangerous in Windows Active Directory, since it relies on the user's NT hash as the encryption key for requesting a TGT ticket.

The recommendation seems to be to upgrade from RC4 to AES. But why is this more secure?

Indeed, AES is stronger encryption than RC4, but can't the attacker still request a TGT on behalf of a specific user by obtaining the user's NT hash?

Please correct me, if some details are wrong.

You would have to ban RC4 entirely to be protected. This is possible and it would prevent an attacker from requesting a TGT with an RC4 request. This is a global setting you apply to DCs. One thing to note is that most users do end up using AES eventually (unless it's explicitly disabled) as Windows/Active Directory will optimistically enable it as it determines that users can support it.

RC4 is weak for a number of reasons, but it's a weakness of the crypto system and not just the algorithm.

RC4 is just horribly broken
RC4 key derivation has no salt, so it's relatively trivial to brute force
The integrity protection is an MD5-based HMAC

AES is preferred because it uses salts during key derivation, and uses a stronger integrity protection algorithm (SHA1 HMAC).


Android leaking app analysis In my thesis I'm trying to analyze leaking private data on Android apps. I noticed that the vast majority of data is encrypted.

How can I analyze this data without decrypting it?

Rory, one method of getting information of this nature from your device is to use binary instrumentation in order to read what the app's functions are seeing.

Frida is a toolkit that will help do this for you. See here for more information: https://www.notsosecure.com/pentesting-android-apps-using-frida/. It works by decompiling, adding gadgets to and then recompiling the binary in order to allow you to see what's happening inside the functions or to rewrite them altogether.

Drozer is another toolkit (unrelated) that can help you look at an app from the perspective of another app. See here: https://resources.infosecinstitute.com/android-penetration-tools-walkthrough-series-drozer/#gref. It's useful for when you're pentesting android databases, it can be used to query the db directly using the app's exported functions sometimes.

I don't know if this pertains to your question but I thought I should note it. Analyzing encrypted data without violating the confidentiality of that data is difficult. The only way I can think of a computationally secure way to do this would to use a TEE to decrypt and analyze the data, send the analysis to userspace, re-encrypt the data in the TEE and wipe memory. That way all computations on the secure data are done in an isolated processor space that is cryptographically secure as opposed to decrypting in userspace where malware will have a chance to access the data. Does this help?


What can I do to separate users best way if they are allowed to run their ruby (python) code I have Ubuntu server 12.04 on VDS and I allow users to run their own Rails applications on behalf their own accounts. That means:

They can use any shell they want
They can upload what they want, e.g. .so libs
They can call any function from any .so lib they uploaded

What can I do to separate them as much as possible and to save my server from being taken under control in such circumstances?

I'd say your best bet would be to have each user on a virtualized environment where you can sandbox their activities. That is assuming your server can handle the additional load.


User login credentials used for file encryption A system I'm implementing requires a user to create a single user, with a single login password.

I want to have a single password for the system, and not require multiple different password entries in order to encrypt/decrypt files after login in (the main purpose of this system).

The way I've implemented this is: when the user first setups on the account password,

the password is hashed (bcrypted) *
a salt is generated *
a crypto key is generated using PBKDF2 (based on the salt)
256 random bits are generated
the 256 bits are encrypted with the key derived using PBKDF2 *

All of the above "*" information is stored in a database

The decrypted 256 bits are used for the actual file encryption/decryption.

The reason I'm doing it this way, is if the single user decides to change his password, the files will still be decryptable (i just have to re-encrypt the random 256 bits with the new password).

Is this a common and secure approach?

Yes, this is a workable approach. A few issues string to my mind, though.

You should salt the bcrypt hash as well, not just the PBKDF2 function
You should not use the random 256 bits directly as an encryption key (unless you know exactly how your RNG works and always will work in all future versions). Use that random data as an input material to a proper key derivation function (like HKDF) instead.


How is the available entropy in /dev/random calculated (or estimated)? It seems (to a non-expert) that /dev/random is acclaimed to be useable as a source of pure random data.  However, I am curious as to the analysis of the file /dev/random.

/dev/random is a collection point of noisy data from hardware.  The file is expanded as more noise is gathered from hardware; as new noise is added, the old data is shifted around so that the file as a whole represents a sort of source of entropy.

I will assume that /dev/random will be used only once to avoid issues arising from reusing a one time pad.  Then there is one thing bugging meーhow the entropy is estimated.  I am less interested in the answers to the following questions themselves, and more interested in whether past research has considered these questions and provided anything relevant.

How is the number of bits of entropy in the file calculated?  I suspect that it is not size of the file, since stat and ls -s return 0, but the number of bits of entropy is available in /proc/sys/kernel/random/entropy_avail. Is it something like the number of bits that can be obtained without learning anything but the bit itself?

I didn't really understand the explanation in the source code or in Gutterman et al.  I suspect that one cannot feasibly compute this value exactly.  However, can one guarantee that if I read less than entropy_avail bits from /dev/random, then the entropy in that string is approximately the length of the string?  In other words is the value of entropy_avail a conservative lower bound on the number of random bits that can be obtained from reading /dev/random?

I would be very interested for a reference on the last one!

There is a short paper on the ePrint cryptography archive that could answer your question.
Basically the author interprets the code of the entropy estimator as Kolmogorov-type entropy estimation where an event is "random" if it didn't happen too close from the previous event, if the time between two consecutive events is not too predictable and so on
Here is the link that will answer the question better than I did
http://eprint.iacr.org/2012/487.pdf


Sending access tokens from server to client best practice I'm trying to write an app that will let a user see multiple Gmail inboxes at one time. I am storing the refresh token for each account in my database.

However, I would like for almost all traffic to and from Gmail to go through the browser - I don't want the unnecessary step of the server retrieving mail and sending it to the client, since I am not going to do anything with the emails server side.

This is the same (or same type of) token that the user would get if I did access token retrieval on the client. So when the user logs in, is it safe to grab an access token server side and send that to the client (over HTTPS of course)? If not, what would be the best practice here?

I might even speculate that this is 'more' secure than storing the access token in a cookie or local storage. Users auth with my app via a JWT, then perform a GET to my server for the Gmail access token. So the Gmail access token is never stored anywhere client side. Any corrections?

You cannot do this, and I will explain why. I am assuming we are talking about OAUTH2, which states clearly what you can and cannot do with a token. OAUTH2 divides clients into five categories:

Confidential
Public
web-Application
Browser-Application (Client side)
Native-Application (Client side)

Each of these use their own authorization methods to obtain the access key (grant types). Before you can query an authorization token at all, you must have registered the application with Google and got an client id (and secret) in return.

Getting to the point; when you registered the client you chose a client category, and I am guessing webapplication (client credential) based on you topic. However, once chosen a type, you promise to use any tokens for that client type only. If you were to send the access token from the server to the client, you break that promise.

OAUTH2 divides client types for a reason, primarily based on security and the ability to keep tokens secret for some time. If you want to store the access token in the client side, then switch to Implicit. Obviously, you cannot use the key on the server for the very same purpose.

The image below demonstrates the differences.


Exploit for a CSRF to a POST server with specific "Accept" header? Say the attacker owns a domain, attacker.com. Attacker wants to create a webpage on it to make a CSRF attack toward the victim.com server. The targeted page is victim.com/target.php which only accepts POST request, with a specific Accept header of, say, application/x-foo.

With such setup, I couldn't find a way for the attacker to craft a CSRF page:

If attacker does a <form action="victim.com/target.php" method="POST"> then I see no way for the attacker to set the Accept header and so the target.php file won't do any action
If the attacker makes a const xhr = new XMLHttpRequest(); xhr.setRequestHeader('Accept', 'application/x-foo'); then the browser preflights a CORS request OPTIONS to the target.php which responds nothing (because it's not POST) and so the browser won't make the CSRF request
The attacker cannot use a URL-based CSRF (like victim.com/target.php?param=xyz) becausse it's not POST either
Attacker does not own the victim.com server so they cannot put a non-cross-domain XHR inb there

Even tho I cannot find an exploit, it feels very unlikely to me that a simple check such as ($_SERVER['HTTP_ACCEPT'] !== 'application/x-foo') in the victim's webpage is enough to prevent any CSRF attack... still, I see no exploit?!

It seems very close to OWASP's custom header CSRF prevention but Accept is not custom: does this change a thing?

According to the documentation[1], the accept header is a "CORS-safelisted request header" and therefore should not trigger a preflight. Thus, checking for that header (unless the server requires an invalid character in it) should not be sufficient to prevent CSRF.

Non-simple requests get pre-flighted, but "simple" (safelisted) ones do not. As long as your server doesn't send back CORS response headers that permit the preflighted CORS request to proceed, and there's no way to make a valid simple request, that works.

[1] Thank you for the link, @Steffen Ullrich


Protecting Android debug bridge that is connected to the internet I have an android device which acts as a brain for my home security that has access to cameras, heat sensors, motion sensors and some appliances.

I have enabled android debug bridge on my android device so I can send commands if I am away from home, like querying my motion sensors.

How can I  add a level of security for my android device which is left exposed to the internet?

You basically have a powerful debug service without authentication listening on TCP port exposed to the internet.

Don't expose it to internet

Do not just put it on the internet. Put it behind a firewall (I guess just plain home router NAT would also count) and set up VPN (or ssh tunnel or similar) so only authorised people can connect.

Put it behind a firewall

Above option is preferred, but this might be acceptable to you as well (but is vulnerable to man-in-the-middle attacks).

a) Configure firewall to only allow connections from specific IPs

b) Use port knocking


What are the security risks of the Service Bus, and how do you mitigate them? The Service Bus is software that can be installed on Windows or rented on Azure and allows someone to relay SOAP/WCF information over the internet in the form of a XML over HTTPS payload.

One risk that I see is that it essentially allows a user with only outbound HTTP/S access to accept "inbound" WCF calls though the external proxy.

Although this can be helpful to make an application "just work", I would see this as a bad thing from a security perspective.  My understanding is that this solution operates by polling an external Microsoft host for incoming data.

Considering that there may be legitmate business reasons for this technology, how will you secure your network from unapproved or malicious use of this relay?

My understanding of the service bus is that it works over specific ports in the 800 range -- I think.  If you disable outbound connections over those ports, then you can't get out to the service bus to get the messages.  Also, each service bus has it's own unique endpoint specific to the service in question so you could lock down access to only known endpoints.


image blocked by CSP policy even though the image is never requested The following CSP directive violation is reported:
[csp-report]
    (
        [document-uri] => https://mysite.com/my-page/
        [referrer] => https://www.google.com/
        [violated-directive] => img-src
        [effective-directive] => img-src
        [original-policy] => img-src 'self' https://various.uris <but NOT https://www.tailwindapp.com>
        [disposition] => enforce
        [blocked-uri] => https://www.tailwindapp.com/app/extensions/Tailwind_swoosh.png
        [line-number] => 4
        [column-number] => 31488
        [source-file] => https://mysite.com/wp-includes/js/jquery/jquery.js
        [status-code] => 0
        [script-sample] =>
    )

If I understand correctly, this means that a visitor to my-page was referred from Google search and in the course of viewing that page the file https://www.tailwindapp.com/app/extensions/Tailwind_swoosh.png was blocked. But I cannot understand how there was any attempt to display that file. It is certainly not directly referenced anywhere in my-page. The script https://mysite.com/wp-includes/js/jquery/jquery.js is not corrupted and makes no reference to that file. Nor does it appear in any other file or database for my site.
So, how can I figure out why there was any attempt to display that file in the first place?

There's a clue in the blocked URL:
https://www.tailwindapp.com/app/extensions/Tailwind_swoosh.png
The image reference was most likely added to the page locally by a browser extension. Probably this one: https://chrome.google.com/webstore/detail/tailwind-publisher/gkbhgdhhefdphpikedbinecandoigdel - from its description, "Schedule any image on the web by clicking the "Schedule" button when hovering over it." sounds like something likely to inject images (and other things) into arbitrary web pages.
Of course there won't always be this sort of clue, but browser extensions are often responsible for mysterious unexpected requests like this. Troy Hunt writes about the problem here. Client-side malware is another possibility.


Personal computer + employer's WiFi I decided to use my personal Macbook at work, so I'll be using my employer's network connection. But I'm really concerned about my privacy. I know I can do non-work stuff using Tor Browser or Brave's Private window with Tor, but what about my reminders, notes, voice memos and other Apple's built in apps? I am really freaked about my personal stuff. How can I prevent them from accessing it? I know they may never do it, but if there is even the smallest risk, I want to prevent it somehow. Let's say I create another user account specifically for work without logging my Apple ID and use it, will it prevent them from accessing my data stored on another (personal) account?

Well, using some dedicated VPN service like NordVPN, or like you said, Tor, should really be enough. That is, unless your employer or co-employees are really nosy or you don't work while you're supposed to. Other things, such as built-in apps, usually remain confined to local storage unless you decide to sync them. Even so, unless you decide to sync to reminders, memos to your non-work Apple ID, not much can me done. And as for preventing them from accessing data stored on your personal account, just make sure you have a strong password.

TL;DR Nothing much to worry.


Does having these ports open indicate any vulnerabilities? I installed Ubuntu Gnome a couple of weeks ago along with a few packages and some software. When I scanned my localhost using Nmap, I got the following results. Are there any obvious vulnerabilities, and how do I fix them?

> Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-03 12:25 IST

Nmap scan report for *********
Host is up (0.00012s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
25/tcp  open  smtp
443/tcp open  https
902/tcp open  iss-realsecure

Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds

There are some false assumptions here that you need to deal with before you can get any meaningful answer:

"Open ports are vulnerabilities." False. An open port is simply an address. It tells your operating system how to deliver network traffic to a program. The program may have vulnerabilities, but you can't tell that by just looking at its address.
"Scanning localhost shows what ports are open to the network." Nope. Your operating system has multiple IP addresses configured, and localhost refers to a special one that is not accessible from the network. A program can listen on a port that is bound to "any address" (the most common case) or it can choose an address to use. If it uses the localhost address, then it can only be accessed from within that computer. This is commonly done with SMTP and printer-related ports (like 631/tcp).
"Running Nmap will tell me what ports are open." Look at the output: Not shown: 997 closed ports. That means that Nmap only scanned 1000 TCP ports. That's the default, and it will catch the majority of network services, but it's not comprehensive. There are 65535 valid TCP ports, plus UDP and a small number of less-popular transports that use the "port" idea. Unless you suspect you are infected with a rootkit, it is nearly always better to use netstat, ss, or lsof to show listening ports on your own computer. These programs query the operating system directly, finish quickly, and can show all listening services, including information about the process that is using each port. Nmap is most useful for probing computers from the outside and building a complete picture of exposure.


Nested Truecrypt containers Which is more secure:

use one container encrypted with AES > Twofish > Serpent = 768bits key size
make an AES container, and inside it make another Twofish container then inside it make a third Serpent container

Which is more secure and which is faster, or are the two ways the same fast 30Megabits/sec?

The goal is to have a secure backup to be placed on CD.

You are looking in the wrong place. :-)

A basic dictum of security is to fix security issues which can be easily exploited before fixing issues that are hard to exploit -- which is just common sense.

The symmetric-key algorithms used in Truecrypt are already plenty strong. Look at this previous answer on AES before proceeding, please.

Your main concern should be key management, i.e. picking a good passphrase and keeping it secure. See here how an attacker would really go about attacking a Truecrypt volume.

From a typical security standpoint, it's senseless to use algorithms with a higher security margin than 128 bit AES unless your passphrase also provides sufficient (192 bit, 256 bit) security margin. See the handy table from Wikipedia to estimate how long a completely randomly chosen password or a Diceware based password would have to be to match 256 bits of entropy.

Creating, keeping and sharing high quality passphrases in a team is quite hard to do in practice. Focus your efforts there.


How can memory problems lead to code execution exploits? In reports on security exploits/vulnerabilities on desktop applications, I often read that memory problems lead to the execution of malicious code.

For example, the description of Internet Explorer vulnerability CVE-2018-8653 says (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8653)

  The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code

How does this work in general?

As far as I understand it, issues of this kind have in common that in a desktop application/process memory allocation was not done properly, i.e. there is something in the memory where it shouldn't or the other way around: There should be something there, but it isn't. So far so bad. Problems of this kind almost always lead to malfunction of programs or crashes. But how can an attacker use such an issue to inject/execute code?

The memory a program uses includes both what you would think of as "data" (text you wrote, an image you're viewing, the script source code your web browser downloaded, a string of text which is being built by that script...), what you might think of as "metadata" (a mapping of free and used memory blocks, pointers to the start of those memory blocks, pointers linking that text string to the functions that can be executed on it, pointers to loaded libraries such as IE's jscript.dll that parses and compiles JavaScript), and executable code (the actual binary code the CPU runs, including the DLL contents, the result of compiling the JS, and the functions on "objects" in data).

When memory corruption occurs, an attacker can usually exert some control over where and how it occurs. For example, if the attacker finds a way to cause some data to be deleted but the program to treat it as still present (called a "use after free" vulnerability, and relatively common in JavaScript engines), the attacker's script could then create a new data object (such as an array of carefully-chosen bytes) that is a similar size and will be created in the same place as the deleted-but-still-usable object. The attacker then might set some value on the deleted object, but because the memory that defines the object holds some totally new data now (the attacker-crafted array) it actually changes some value that the attacker isn't supposed to be able to control such as the extent of the array. The attacker then uses the array - which the program now thinks is super-long, extending well beyond the allocated chunk of memory that it is actually stored in and into memory used for other things - and does something like change the "return pointer" metadata that says "when this block of code finishes, continue executing code over here". The attacker changes this return pointer so that the code that will run after the current function ends does something like launch a program the attacker wrote, executing arbitrary code on the victim's computer.

This type of attack (use-after-free to gain an arbitrary-offset memory read/write, using that to overwrite the return address into some attacker-desired function) is but one of many, many ways to exploit memory corruption. Some other memory corruption vulns are double-free (trying to delete the same block of memory twice, which is dangerous because you may end up treating attacker-controlled data as though it is actually metadata about the memory allocations and thus change data the user shouldn't have access to), buffer overflows on the stack or heap (two different places program data goes; the stack is where you'll also find things like return pointers and the heap where you'll find things like function tables and arbitrary-length arrays) where you can write past the end of a memory allocation and change other data, integer overflow where the program does some math on two numbers that ends up with a result too big for the program to hold in the space it reserved for that number, so it loses part of that number and treats the totally-different number as a pointer into safe memory when in fact it could be anything at all, and so on.


Is it possible to create a SMIME only PKI that *can't* be used for SSL? Assume I have a Root CA that I want to share with hostile untrusted 3rd parties.

Then constrain this root using specific EKUs at the root.

 OID=1.3.6.1.5.5.7.3.4        ; Secure Email

Next, create a Policy CA (controlled by the root) to restrict the permissions granted to untrusted CAs using Path=1, and Name Constraints (also see this).

Ideal outcome

I would like to issue SMIME certificates that are for signing only, and another for encryption (I understand that support varies on this)

Question

Is it possible to constrain the name, enhanced key usage, and key usage so that a hostile CA I delegate power to can't create HTTPS certificates, and can't create SMIME certificates for other domains?

If the above is true; I think that it's possible to create a SMIME only PKI (please correct me if I'm wrong).

I'm particularly concerned about the ability (or lack thereof) to constrain the key usage field in the CA, so that any properly (or widely deployed client) will see that the CA chain is not permitted to issue HTTPS certificates, and will reject one if offered.

The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:

KeyUsage ::= BIT STRING {
   digitalSignature        (0), -- Needed for SMIME and (EC)DHE TLS implementations
   nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
                                -- Accepted in some TLS implementations if (0) is missing
   keyEncipherment         (2),  Used in RSA based TLS
   dataEncipherment        (3),  Accepted in some TLS implementations if (2) is missing
   keyAgreement            (4),  Accepted in some TLS implementations if (2) is missing
   keyCertSign             (5),
   cRLSign                 (6),
   encipherOnly            (7),
   decipherOnly            (8) }

It is possible to create a root CA that cannot be used for SSL by... not using it for SSL !

When a CA issues a certificate for a sub-CA, it does so within the context of a given trust contract. The sub-CA agrees to issues certificates only in accordance to a number of rules which are made explicit in the Certification Policy and the Certificate Practice Statement -- these are legal documents meant for human consumption. If you want a root CA which can be used for S/MIME but not for SSL, then the root CA must state in its CP and CPS that certificates which relate to this root CA must not be used for SSL. In particular, sub-CA take the formal oath never to issue SSL-able certificates (i.e. they won't put machine names in Subject Alt Name extension or in the Common Name part of the SubjectDN; and they will put a critical Extended Key Usage extension which says "for S/MIME only").

In X.509, there are two categories of such "PKI rules":

Rules which are enforced by the validation algorithm. Name Constraints, for instance, can (theoretically) be used to prevent validation of certificates such that the end-entity certificate's name is not part of a namespace of allowed names duly specified in one of the intermediate CA certificates.
Rules which are not enforced by the validation algorithm. The "no SSL" rule would be such a rule.

In pure X.509 theory, there is no actual need for rule enforcement in the validation algorithm; revocation is used to maintain order and punish misbehaving entities. However, in practice, revocation is asynchronous, and too slow to react to "flash attacks". An attacker who wants to run a fake server only needs ten minutes or so  to enact considerable mischief; seeing his certificate revoked two days later won't deter him. This is why a number of PKI rules are now enforced at the validation level, first of which being incarnated by the Basic Constraints extension: a certificate owner is not granted CA power.

There is (currently) no such automatic enforcement of rules pertaining to Extended Key Usage. If a CA wants to enforce a no-SSL rule, then it must not issue certificates which can be used for SSL, and it must make sub-CA swear to comply to the same rule. Lack of such enforcement is a problem only if a sub-CA misbehaves, and the obtained certificate can be used as a SSL server certificate to perpetrate some odious crime before righteous revocation smites the offending sub-CA.

(Note that the Key Usage extension only covers a handful of generic use cases, such as "encryption" or "signature", and this is unrelated to Extended Key Usage. Moreover, the Key Usage extension is no more inherited along a certificate path than the Extended Key Usage extension.)

There is another point where rules can be engraved: in the clients. Clients trust root CA (that's what makes them "root CA"), but they can trust them for specific roles only. See for instance this screenshot from the certificate viewer in Firefox's preferences:

The list of "uses" is configurable and allows the client to restrict a given CA to some specific situations.

This mechanism:

is not backed by information written in the root CA certificate itself, but by metadata which must be maintained by some out-of-band mechanism;
is not standardized (every system has its own notion of "roles");
is specific to root CA (trust anchors) and cannot be attached to an intermediate CA;
is worth anything only insofar as the relevant applications mind the restrictions and enforce them.

Yet it works. If you want an S/MIME-only root CA, then distribute it and have it installed in clients with the tag "for S/MIME only". This is as good as a full-path automatic EKU extension (if such a thing existed).


Does the "Special Groups" feature in Vista, 2008, R2, and Windows 7 apply to File System access? The Windows 2008R2 "Special Groups" feature allows for detailed tracking of domain administrators when they log into the machine. This is accomplished by editing a registry key or the LSA.

Is there a similar action that can be done for the File, Print, or other types of logging?

Yes. The answer is just plain old object-access auditing with audit policy and Audit ACLs.

First, you enable the system audit policy for tracking successful access of files and object. Don't worry, this won't make insane amounts of log messages (though domain controllers do get a bitnoisier due to default Audit ACLs (SACLs)).

Second, in active directory or the file system, you find objects you want to audit access to. Edit the properties, go in advanced security settings/Audit tab. Then you add the users or groups that you want to track, then you select the type of activity you want to track.

When users access this object, the system checks if there is a SACL and if this type of access should result in a security eventlog message.

A more thorough overview:
http://technet.microsoft.com/en-us/library/cc787413(v=ws.10).aspx


Utility of multiple signing subkeys when we're restricted to a single encryption subkey in GnuPG (PGP) As I understand it, GnuPG allows the creation of multiple subkeys, but multiple encryption subkeys are problematic because it's not clear which encryption subkey someone should use when sending a message.  As such, by default, when a person sends a message to you, their software will select the most recent encryption subkey.  This limits the utility of having multiple encryption subkeys on different devices, but not necessarily signing subkeys.

Now, imagine a situation where we have two laptops.  Neither laptop contains the master key, but only a single subkey for signing (S) and subkey for encryption (E).  Since we have trouble using multiple encryption subkeys, we have a setup like this:

Laptop 1: E, S1
Laptop 2: E, S2

Hence, each laptop has its own signing subkey, but they each share an encryption subkey.  Now, say we lose laptop 1.  At this point, using the master key, we can revoke the certificate for E and S1.  Since the master key was safe, we preserve our WoT.  However, since E is no longer valid, we still need to update laptop 2 with a new encryption subkey.  Since we always need to update laptop 2 in the case that laptop 1 is compromised, why should we prefer the setup above to a key setup

Laptop 1: E, S
Laptop 2: E, S

Certainly, if we're only signing, having separate signing subkeys for each device makes sense.  However, if we need to sign and encrypt, does it still make sense to have separate signing subkeys for each device?

Edit 1

Following up on @jens-erat's answer, I checked and GnuPG does allow us to specify exactly which subkey we use for encryption.  Simply, append ! after the specified key.  This forces GnuPG to use this particular key and not go through the normal calculation as to what key to use.  This is in the man file under the section "HOW TO SPECIFY A USER ID" under subheading "By key Id."  Then, as @jens-erat stated, we could add a bunch of notations to the key, which specify which key should be used for which situation or address.  By looking at the notation block with --list-sigs and then specifying the exact key with !, we can utilize multiple encrypting subkeys.  That being said, I don't think this is standard use and will likely cause use problems for people.

There are lots of possible use cases.

In the example you gave, by only revoking the subkey affected signatures of the other stay unharmed. Often, you will not immediately realize a computer was harmed and you have to put all signatures created in a given time frame in doubt. The other computer stays unaffected.
There are use cases that do not require an encryption key, but only signature keys, like code signing on a build server.
You might have a less secure, always-online signing key and a more secure offline signing key, for example by using an OpenPGP smart card.
And probably some more...

Finally, the lack of possibilities in choosing the subkey to encrypt to is mainly an issue in the software, not the protocol itself (although the standard could make use of some extension for declaring uses like "laptop", "mobile phone"; in a non-standardized way this could be achieved by using the notation packet).


How does Tor preserve anonymity if it uses normal Internet Routing? I'm studying Tor and Onion Routing and I don't understand how it preserves anonymity if the Internet routing is still done using public ip addresses.

Let's suppose we have the following Tor circuit: Tor Browser -> A -> B -> C -> Server.
If someone follows the traffic from relay to relay then the anonymity is broken.
Even though it uses 3 layers of encryption the routing is done by public ip addresses which are in clear text in the ip header.

Or when the server responds back it sends the packets to the public ip address of C. Some authority could follow to route from the server to C to B to A to the client and knows that the client is communicating with the server.

Can anyone say if I'm right? Or the entire security of Tor is based on the fact that no one can ever control all 3 relays (or statistically is very improbable)?

Broadly speaking the most basic premise of tor anonymity is that whatever happens between your entry point (usually a socks proxy into tor to which the browser connects) and exit node(s) is completely opaque and cannot be meaningfully reconstructed to determine the actual source of the traffic. (this is known to have limitations)

As Schroeder mentioned, this isn't to do with TCP/IP routing (even though the term is used extensively in tor documentation). If we expand your example from:

Tor Browser -> A -> B -> C -> Server

To

Tor Browser => Ta => Tb => Tc -> B -> C -> Server (where T* are tor nodes [Tc is an exit node] and B and C are Internet hosts that route traffic into the server)

What happens is that:

Server sees incoming requests from Tc incoming from router C;
Tracing of traffic if possible between Server and the public IP address of Tc;
(ignoring limitations, vulnerabilities and client-side surveillance) It is not possible to trace the path of traffic from Tc to the connecting Tor Browser, exactly as per Tor's design. In other words anything inside the tor network is meant to be untraceable;

Again please bear in mind that there are exceptions and caveats for everything. This is the basic concept put forward in a simplified way.


Nmap giving different result between Mac OS scan and Linux (Kali) scan I try to do a simple TCP scan on an Kubunt VM (is on VirtualBox), from two different OS.
From the Host (Mac OS system) and from a Kali Linux VM (tried VirtualBox and Parallels also).
Kali Linux (same result VirtualBox and Parallels) gives:

From Mac OS (run with root privileges, to simulate the same scan from Kali):

So run a Nmap scan from Mac OS gives more open ports on the same VM, with the same privilege of scan, etc.
Mind blowing...

If I scan just a port (from Kali VM) try the 110, the result is that is closed:

Why is it happening?

This can be because of many reasons. Such as the following:

Network Layout
Antivirus Software
IDS/IPS
Intermediate Network Devices
The version of your Nmap's
..etc

In your case, it seems like you are using your MAC OS as the host. While Kali Linux is a VM with the MAC host. If you have an Anti Virus software or Strict Firewall rules enabled, they could be dropping the requests begin generated by your KALI VM-nmap scan. Which is in turn giving you different results on the different hosts.

In Order to verify this hypothesis, you can try to boot up Kali as a host and try scanning the "said" machine again with the same versions of Nmap.


Is it safe to provide my details via an iframe, if the page in the iframe is secured with SSL? Visiting a streaming service I wanted to provide my payment details and was presented with a page that wasn't secured by HTTPS/SSL.

I didn't provide my details and contacted support asking them to fix this if they wanted my money.

The reply was that the payment details form was actually in an iframe and the source of the iframe is secured by HTTPS/SSL (and this I can verify).

But - is this secure? Can I feel safe with providing my payments details through an iframe, if the source of the iframe is HTTPS but the page displaying the iframe isn't?

It's a bad design and the entire page should use HTTPS, as this trains users to the unsafe practice of trusting and submitting private information over HTTP.  It would be trivial for a man-in-the-middle attacker to alter the outer HTTP page to not use the correct HTTPS iframe, but instead an attacker controlled iframe (possibly HTTPS to an attacker controlled domain).

Thus you need to check the source code of the iframe every time you submit private data (as there are no guarantees that the first time you inspected it was fine, but the next time it was altered by an HTTP tamperer).

Furthermore, as the page is loaded over HTTP, a MITM attacker could insert and run whatever javascript they want on the outer page (and hide these modifications in some obfuscated script that's loaded externally).  They could leave the original iframe with the right https URL if you clicked view-source of the HTML page, but in javascript they could hide or replace that iframe with malicious DOM elements that look identical (but leak your details to the attacker).  This is less of a problem with an interactive DOM inspector in modern developer tools (which shows the DOM as it currently exists, so you should be able to inspect the iframe), but again this requires a lot of verification work for every user who wants to safely submit data.


Auth / Login token schema According to this answer, a valid login token schema would consist of

the username (U)
the time of issuance (T) and
secret key K owned by the server only

The suggestion then is to concatenate the values as following:

token = U+T+hmac("sha256", U+T, K)

Does this mean the server would have to split the token to validate it, take the username and the time, rebuild the hash (with the same key) and then compare the new build hash to the provided hash in the token? Isn't it a problem to sent the username and time in plain text? Wouldn't it make more sense to encrypt the userid and time as well (and decrypt it for validating the token)?

Say, you're user "bob". You log in with your password on 2014-07-30H12:00:00 and the server, using your scheme, sets your cookie token to:

enc("bob", K)+enc("2014-07-30H12:00:00", K)

However, bob is malicious. While his boss Alice is away from her desk, he checks her browser cookies and finds out her token:

enc("alice", K)+enc("2014-07-30H13:00:00", K)

Bob doesn't need to know the secret key K on the server, since the value of enc("alice", K) never changes, so all he needs to do in order to spoof being user "alice" at any time in the future is to change his own cookie to replace the output of enc("bob", K) with the output of enc("alice", K).

The scheme with the hmac suggested above is not vulnerable to this attack. The server's returned token is something like this:

bob$2014-07-30H12:00:00$b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c

Bob can try to change "bob" to "alice", but when the server performs the validation calculation, the calculated sha256 hash won't match, and it will be obvious that either the username or timestamp have been tampered with. Bob cannot possibly calculate the hash, since he doesn't know the secret key used by the server.

The validation operation of split() and hmac() are extremely fast and take microseconds to perform. They will probably be faster than decrypting the tokens. Obviously, you'd be sending the token over a safe channel, such as over https using a secure cookie, so there is little need to additionally encrypt the username and timestamp in addition to the hmac.

Edited to add:

Even if you use the following instead:

enc("bob"+"$"+"2014-07-30H12:00:00", K)

this is still not good enough. Getting encryption just right is extremely difficult and the chances are there will be weaknesses in your implementation (all tokens issued to "alice" will start the same way unless you do the right thing with randomness and initialization). Since the attacker will know both the plaintext and cryptotext, there is a number of attacks they can try to figure out what the value of K is, unless you use the right algorithm with correct initialization parameters.

Furthermore, all good crypto always incorporates hmac for integrity checking anyway, so by attempting to simplify the process you'll end up either weakening it, or making it more complicated and computationally intensive.

Just stick to the username+timestamp+hmac(sha256, username+timestamp, K) recommendation and transfer it to the client over a secure channel. It's a scheme that known to work well.


A replay attack was detected (4649) & Exchange Healthmailbox We received alarms for this in our SIEM today. I believe it is expected and just "noise". The alarm was triggered immediately after Exchange cleared the ThrottlingConfig.log.
I know Exchange Server 2013 CU5, CU5 includes a Managed Availability probe configuration that is frequently restarting the Microsoft Exchange Shared Cache Service in some environments. The service is being added to provide future performance improvements and is not used in Cumulative Update 5. More information is available in KB2971467
So it looks like this event triggered alarm is a false-positive. Anyone else experience this?
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
    <System>
        <Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/>
        <EventID>4649</EventID>
        <Version>0</Version>
        <Level>Information</Level>
        <Task>Other Logon/Logoff Events</Task>
        <Opcode>Info</Opcode>
        <Keywords>Audit Failure</Keywords>
        <TimeCreated SystemTime='2018-09-20T20:14:12.793310400Z'/>
        <EventRecordID>79125070</EventRecordID>
        <Correlation/>
        <Execution ProcessID='700' ThreadID='5972'/>
        <Channel>Security</Channel>
        <Computer>DOMAIN</Computer>
        <Security/>
    </System>
    <EventData>A replay attack was detected.

Subject:
    Security ID:        NT AUTHORITY\SYSTEM
    Account Name:       SERVERNAME$
    Account Domain:     DOMAIN
    Logon ID:       0x3E7

Credentials Which Were Replayed:
    Account Name:       HealthMailboxXXXXX
    Account Domain:     DOMAIN

Process Information:
    Process ID:     0x673b81d620
    Process Name:       C:\Windows\System32\inetsrv\w3wp.exe

Network Information:
    Workstation Name:   -

Detailed Authentication Information:
    Request Type:       KRB_AP_REQ
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -

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.</EventData>
</Event>

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.


What attacks or exploits are possible when MAC address, IP, and Port of a WiFi access point are known? I just accepted a position at a small firm and was testing the previous WiFi setup for flaws and exploits that were possible. We have two AP's for business and guest connections, everything checks out on the guest (Free WiFi). But I just found a note (probably left by my previous positions tech), that has the business AP's MAC address, IP, and Port in plain sight in the lobby.

So my question is what attacks or exploits could have been possible during this time?

Business AP uses Mac address filtering, and I'm aware of MAC spoofing as a probability. Any others?

If the WiFi network is configured securely (which is a topic for another question), none of that information should be required to keep secret.

The MAC address of a WiFi access point is no secret: It is constantly broadcasting it anyway.

With "IP and port" you surely mean the IP and port of the web interface. When that interface has a password which is long enough to withstand a brute-force attack (having a username which is not "admin" or something equally obvious is a bonus), this should not be a problem. This is also no secret information: Most consumer-grade models have these hardcoded and with better wifi access points where it can be changed, it is often left on the default. So there aren't many guesses to make.


How does Tor guarantee anonymity of Tor network? To me it seems that the only thing Tor is doing for anonymity (not security!) is the fact that it does not record the traffic in and out, because obviously if every router was recording the traffic going through it (let alone publish that information), every pathway would be clearly visible and then anyone could backtrace anyone.

But how does Tor guarantee that nodes do not log their traffic and/or send them to an adversary?
I would bet that all NSA-helded routers would keep track of this and I bet that most of private-held routers would also do this since Tor is open-source and since people are naturally driven for evil.

Anonymity would still work if the nodes did not cooperate with each other (sharing traffic logs) or if the data passed through one honest node that does not log any information, but it's still a major flaw if most of the network you don't know if you can trust.

So how does the Tor network know whether to trust a node not to send traffic information to an adversary or to make it publically available?

It doesn't guarantee anonymity if enough of the network is controlled by a single adversary. There's no general way you can do so; if your whole connection goes entirely through adversary-run computers, your adversary is going to be able to track it, no matter what system you're using.

What Tor does is make it really, really, really hard for an adversary to control enough of the network to make this happen. It passes each connection through multiple nodes, so you have to control enough nodes that not just one but at least three nodes selected from the list are yours (in specific cases, it may use more than three). The reason Tor works is that with a single Tor network, you have lots and lots of people running Tor servers; an adversary has to compete with tons of legitimate nodes. It's the same basic idea as Bitcoin - make it so an attacker inherently has to compete with legitimate users, and then the bigger the system gets the harder it is to attack.


Is it true that the older the files are, the more likely it is they are clean if new scanners won't detect anything? Newer malware might not be detected, but if files are older, is it more likely they are clean when scanned with anti-malware scanners that have newer updates?

For example files that are few months old and files that are several years old?

How likely is that some old malware might still lurk in them and even newer updated scanners won't detect anything?

Antivirus vendors and administrators tend to disable scanning routines and pattern detection for older malware generations. They usually do this for performance reasons. The legitimization is, that old malware might be eliminated anyway in the meanwhile because there were so many detection mechanisms established for so long which would make it impossible for an ancient malware to survive. I did an analysis of the default protection filters of HP TippingPoint and revealed the same in the IDS/IPS sector.

The problem is, that the reasoning is wrong. Older malware might have survived because everyone thought it is extinct. There is a similar problem when it comes to vaccination.

Besides that it might be possible that an attacker/malware manipulated the timestamps of a file. Without integrity checking you can't tell if this really is the file that you expect it to be since an earlier point in time.


GitHub's Bash Shell for Windows is vulnerable to Shellshock. Can it do any harm though? After the news of the Shellshock vulnerability broke out, I remembered I had GitHub's version of a bash shell for Windows installed. Just to see if it also had the vulnerability, I executed:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

And got back:

vulnerable
this is a test

Still, being a Windows system, can anything malicious be done from the GitHub bash shell, other than mess with my repositories?

(GitHub v2.0.6.0 130c781)
(GitHub v2.4.0.12 34d40b7)

edit:

env x='() { :;};' bash -c "vi foldername/filename"

Confirming this can edit Windows system files.

I'm a developer on GitHub for Windows - we're closely monitoring the msysgit mailing list for progress on this, but we believe at the moment that there isn't any way to exploit this in GitHub's shell, because there is no escalation of privilege (i.e. you can only hack yourself).

We're definitely actively looking for scenarios where that is not the case, and if we find one we'll definitely be pushing out an update ASAP.

Update: We've pushed out a release that resolves the known Bash vulnerabilities mentioned in recent CVEs. We'll be on the lookout for future issues as well.


Is this parameter vulnerable to SQL Injection? The backend server is running Tomcat 8.5 (Java backend). The URL in question is:

https://website.com/application/servlet.do?currentOID=abc12300000000

I found that when I give an incomplete OID (i.e 1 char remove), or I add a char (i.e a or '), the server throws an error:

org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while insert object data for class com.abc, PK of the given object is [ oid=CBA000000AAAAA], object was GroupPageTab CBA000000AAAAA, exception message is [String or binary data would be truncated.]
    at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:243)
    at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1642)
    at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1557)
    at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1506)
    ...

and the OID CBA000000AAAAA, changes when currentOID is changed. Does this look like it may be vulnerable to injection? I'm inexperienced in JDBC so I am unsure.

No, the error does not indicate SQL injection.

  String or binary data would be truncated.

This means that the data you try to insert is too big for the column. If the column is of type CHAR(10), you can store 10 bytes in it. If you try to store 20 bytes in it, you get this error. This can happen even if the data is correctly handled and the page is not vulnerable to SQL injection.


What information should a error log record? I want to populate my error log with useful information if and when errors occur. I'd like to use the log to be able to spot and fix bugs on my site, but also to potentially log hack attempts. For a PHP web app, what information is considered vital and why? What info can be useful? What is overkill?

My current list is:

The type of error.
The corresponding error message.
The URL where the error occurred.
A timestamp.
The user's IP and user
agent.
The referring URL.

Usually the amount you log depends on the kind of error. The more critical the more you log.

In regards to other stuff you would want to log

Filename for the file that caused the error would be high up the list, with line number.
Stack trace information if the error was a result of an exception being thrown.

I don't think you can overkill the amount you log when an error occurs as long as its useful. The only time I have seen logs become really bad is when massive logs are being taken even when an error does not occur.

Some more information can be found on the OWASP website - Error Handling and Logging.


What's the purpose of "ExecutionPolicy" settings in PowerShell if the "-bypass" switch circumvents it? PowerShell's "ExecutionPolicy" allows for restricting all scripts from running, only allowing signed scripts, etc - see this article for reference.

However, if I simply do:

PowerShell -ExecutionPolicy Bypass -file MyScript.ps1

... I have effectively circumvented the configured Execution Policy anyway, and the script is successfully run (even with a completely 'Restricted' default policy configured).

What's the point in having different levels of policies available, if all I have to do is send a switch to bypass it, and it'll succeed?  Am I missing somewhere that 'Bypass' won't work under specific circumstances?  So far, I've not found an execution policy that wouldn't let it slip right on by anyway.

(Sincerest apologies if this were better suited for StackOverflow, but I came here first, since it deals with security policies.  I've searched a while to find an answer on this, but I can't seem to find a definitive explanation.)

From here (em mine):

  What is the PowerShell Execution Policy?

  The PowerShell execution policy is the setting that determines which
  type of PowerShell scripts (if any) can be run on the system. By
  default it is set to "Restricted", which basically means none.
  However, it's important to understand that the setting was never meant
  to be a security control. Instead, it was intended to prevent
  administrators from shooting themselves in the foot


Ordering of shared Phase 1/ISAKMP VPN policies The various Phase 1 settings of a VPN tunnel policy are fairly well-established (encryption, hashing, DH group, lifetime), but in what order are they considered applicable to a more-secure tunnel?
I am fairly certain I know which values of each tuple are more secure (please correct me if I am wrong):

encryption: aes-256, aes-192, aes-128, 3des, des
hashing:    sha1, md5
group:      5, 2, 1
lifetime:   3600, 28800, 86400

But which tuples should I prioritise in combinations?
Is the encryption more 'important' than the hash?  Is the hash more important than the group? Would an aes-256/md5/group5/3600 policy be deemed more secure than an aes-256/sha1/group2/3600 policy?

Background
I am running a Cisco ASA firewall, with a number of site-to-site VPNs (i.e. to client sites).  In the past, we have always put these in an additive/incremental fashion and pretty much just added whatever Phase 1/ISAKMP policy the client wanted to the end of the policy list.
Recently, a client has come back and asked that we change their Phase 1 settings from 3DES to AES256.  As such, we added the new phase 1 settings to the list, but it still establishes with the 3DES settings, which I did not take out in case another client VPN also used it (the ASA shares the Phase 1 policies, prioritises numerically and does not make it particularly easy to determine which policy is used by which tunnel).
It looks like, in an ASA-to-ASA tunnel, the recipient device chooses the policy from a list sent by the initiator, based on its own policy order not that of the initiator.  So it looks like I will have to reorder the policies.
Now, instead of just prioritising by loudest client, I would rather do so such that a policy considered more secure is prioritised over a weaker/legacy one, which should mean that an ASA-to-ASA tunnel will automatically pick the most secure route, while any policy-per-tunnel device should just use the one it is configured to use.

Possible solution
I have read that the purpose of the hash function is for the recipient to verify the decrypted packet, which might lend itself to the Encryption tuple being more 'important' than the Hash tuple.
I have also read that the DH Group is used initially to provide a calculable challenge against the pre-shared key, so it might stand that this is more 'important' than the Hash, too.
Lifetime obviously denotes how often to re-establish the tunnel, but plays no real part in the tunnel itself.
All of which leads me to think that order of importance might be:

Encryption
Group
Hash
Lifetime

Does this seem reasonable?

There are secure options, and less-secure options. How you order the secure options is less important than that you avoid the poor choices.

For example, DES is pretty handily broken because the key length is insufficient. It should simply not be allowed. 3DES is slow but theoretically not broken (though some say that certain governments have optimized hardware for DES/3DES cracking). It's best to avoid if possible, but depending on what clients you allow, you may have no choice but to allow it.

MD5 is probably not a great solution either for crypto use because it is directly susceptible to attack, but again, depending on whom you're allowing to connect, you may not be able to avoid it. Chances are pretty good that if someone doesn't have access to AES and has to use 3DES, they won't have an implementation of SHA1 either, so perhaps MD5 and 3DES should be grouped together. It's also quite likely that such a person is actually calling from 1997 and perhaps you can make them some money by sending them some contemporary sports statistics. And perhaps you just want to drop 3DES and MD5 altogether, because really.

Decisions like 128, 192, or 256 are probably not particularly important; AES 128 is already 100% unbreakable accordingly to current understanding. AES-128 is faster, while AES-256 (theoretically) offers a wider safety margin. Bruce Schneier thinks that AES-128 has a better key schedule, so the security is likely a wash.
 So if you have a preference, prioritize accordingly.

And perhaps options such as lifetime may be important to your organization, or perhaps they are not. So In those cases you simply include all the options you will allow in whatever order you think is best-to-worst. The other party will do the same, excluding the options that their own policy does not allow. Together you'll agree on a combination incorporates the best allowable elements from each.


What information does a wireless access point have about connected devices? Which information about a connected device leaks to the access point it is connected to? What's the minimum amount of information that must be supplied to successfully connect, apart from the password?

So far, I'm only able to see reason for:

hostname
physical address
IP address

There is a lot more of information the access point has about any connected device. At least:

the protocol used
some kind of signal strengh
the current key for encryption
some history for packet delivery
the data sent and received as the first hop of the device to the network
time of the connection

Depending on the time constraints and the bookkeeping, also enough data to roughly guess the position of the device.

There might be even more data available; I would have to take a look at the protocol definitions to see what else is shared.


Is crypto.js vulnerable to heartbleed attack? We are using 'crypto.js' in our application.

Since 'crypto.js' uses open SSL ,are we vulnerable to heartbleeding attack?

If yes, what can we do to prevent it?

Crypto.js does not use OpenSSL, it is interoperable with some of the same algorithms, and is not vulnerable to Heartbleed. All the more so because usually you use crypto.js on the client, not on the OpenSSLified server.


Authorizing an Android app to carry out operations on backend server The users of my Android application can pay (using Paypal or in-app billing) to light a LED on a remote location. The LEDs are controlled, at each of the locations, by Internet-connected Arduinos.

When a user pays, the app sends a request to the server, which contains the amount of money paid. The server in turn is responsible for sending a POST request to the right Arduino.

Since anyone can decompile the application and figure out how to make a request to the server with an arbitrary amount of money paid, how can this exchange be secured?

User and password authorization (with hardcored values) will not work, because the user and password can just be extracted from the app
Embedding a key file will not work because of the same reason
Authorizing based on Google accounts will not work because I need to authorize the application, not the user (that is, the user can just use those credentials to make an arbitrary request outside from the app, which is not desirable)

I thought about leveraging the "payment confirmation" from the payment providers to ensure that a payment is done, but this payment is made in-app, so I don't know if it can be secure. Should I use a "return URL" so that Paypal (for example) makes the request to the server?

Thank you.

Process or verify the payment server-side. This works for paypal und afaik your server can see in-app purchases of a authorized app and specific user, too. Just dig into the documentation on PayPal, Google Play e.t.c


Why don't antivirus definition files get detected as malware I was wondering... if antiviruses store virus definition files that contain virus signatures then why wouldn't they get detected as malware by themselves or Windows Defender or any other AV out there?

That's a good question, and the answer is they do, or at least they did.
It used to be a common problem and was one of the reasons it was recommended not to install multiple virus scanners, because they would trigger on the other vendors signatures.
Currently nearly all signature files are encoded or packaged in some way that alleviates cross scans of signature files. For example the open source virus scanner ClamScan provides signatures as zip files although their extension is not ".zip". Uncompressing one of these signature files shows content like the following:
e6fec7dc14a74ded93fb9bc50f408e1c:101888:Win.Trojan.Mybot-3069
2fdfa9f7b22e209b4e4aee51109767c1:56320:Win.Trojan.SdBot-599
005d1d1c578316d70c1e0e4f56b61f5f:65341:Win.Trojan.SdBot-600
4ca8616bdd7a9e1d6c60b1d6793dee8a:182272:Win.Trojan.Startpage-295
e83beca0b22cb86b40e77230a41cb827:86493:Win.Trojan.Wootbot-88
8074bd1c4b28bf4296a7a5b85074769f:92672:Win.Trojan.Wootbot-89
90b59c2621ffa8c966f4209073808db9:151552:Win.Trojan.Wootbot-90
dc09af7adcb2f9d1acda2ab9dce0bcc5:104960:Win.Trojan.C-198

The scanner is looking for the binary patterns represented by each of these entries, however these entries are ASCII HEX representations of the binary string, not the actual binary string.
In order for the virus scanners to look for a match, the signature and the scanned files must be in a matching format before comparison. This could be ascii hex or a hash, or anything else but doing so to all of the files is a much higher overhead than simply converting the signatures to raw binary for comparison.
Converted to native binary signatures, they are now in a state that could easily trigger another virus scanner but generally this is now done in-memory only, and not written back out to a file.
For another virus scanner to key on the now native binary signature, it would have to be scanning simultaneously and scanning other in-memory processes. While less common now, this does happen!


My site has Certificate Transparency enabled but Chrome is still showing NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED I have a site called www.goflyla.com and I purchased the SSL cert from RapidSSL with Certificate Transparency  enabled.

SSLLabs give a green line saying Certificate Transparency: Yes (certificate):

Strangely, this only happens in Chrome (Mac version). I can still access my site in Windows and Ubuntu (Linux) Chrome but saying the site supplied invalid Certificate Transparency information

Checked with chrome://net-internals and embedded_scts is there:

I have narrowed it down to Chrome version 53.

What should I do?

Botched CT redaction
According to the CT lookup site (archived here) the certificate is logged as ?.goflyla.com. This looks very much like an attempt to redact the exact domain name.
And unfortunately that feature is not fully standardized yet. So it just doesn't work at the moment. (And any attempt to submit a redacted entry to the log will just result in Chrome 53 completely ignoring that log entry and saying: No log entry found. -- For details see SSLMate blog post linked below.)
So what can you do? -- I'm not sure. I'd guess one of two things:

Ask RapidSSL to fix the CT Log submission and re-submit with the unredacted hostname.
Buy a different certificate. And not from Symantec or a subsidiary. -- The reason is that Symantec was, for lack of a better word, sentenced by Google to CT log every new certificate (Archived here). -- (And it appears that that requirement also applies to their subsidiaries, like RapidSSL.) And other certificate authorities simply are not under that requirement.

Further reading:

SSLMate Blog, 2016-09-07, Why Chrome 53 is Rejecting Chase Bank's Symantec Certificate (Archived here.)

Despite the fact that redaction, practically speaking, does not exist, Symantec forged ahead and grafted redaction onto the original version of Certificate Transparency. The result is a Franken-certificate that works fine in browsers that don't support Certificate Transparency, but fails to validate in Chrome.

Log entry without redaction: https://crt.sh/?id=31180341&opt=cablint,x509lint
Log entry from later on that same day. Interestingly with the SAME serial number. I don't know what to make of that.   Also now with the weird redaction attempt of "?" Instead of "www": https://crt.sh/?id=30754735&opt=x509lint,cablint


What security measure one should implement before executing user uploaded files? I want to make a little programming puzzle on my website. There's going to be a task. The user will be asked to upload a C++ source file with their solution. The file should be compiled, run with some input and checked if it produces right output. What are the security risks? How do I make sure that the uploaded file won't be able to do anything malicious?

Alternatively, there are sites like Tutorials Point that let you compile and run C++ code. How do they manage the security?

It is impossible to analyze a program to find out if it will do anything malicious. That is true regardless of whether you are attempting to analyze the source or compiled code.

The way to do what you are asking for is done by compiling and running the code in a sandbox. Once the program has terminated (or after a timeout you have decided upon) you destroy the sandbox.

The security of such a construction is as secure as the sandbox you are using. Depending on the requirements of the code you need to run the sandbox could be either something simple like Linux secure computing mode, or something complicated like a full blown virtual machine - ideally without network connectivity.

The more complicated the sandbox you need the larger risk of a security vulnerability in the sandbox undermining an otherwise good design.

Some languages can safely be compiled outside a sandbox. But there are languages where even compiling them can consume unpredictable amount of resources. This question on a sister site shows some examples of how a small source code can blow up to a large output.

If the compiler itself is free from vulnerabilities it may be sufficient to set limits on the amount of CPU, memory, and disk space it is allowed to consume. For better security you can run the compiler inside a virtual machine.

Obviously these methods can be combined for an additional layer of security. If I were to construct such a system I would probably start a virtual machine and inside the virtual machine use ulimit to limit the resource usage of the compiler. Then I would link the compiled code in a wrapper to run it in secure computing mode. Finally still inside the virtual machine I would run the linked executable.


Virtual machine and viruses I have a 1tb hdd and I have installed windows 10 on 600gb and the rest space, I have given to kali Linux. I want to install vmware in kali Linux and test Malware samples. So if the virus does something, will it affect the first my windows partition files because in kali file explorer I see both my windows partition (c and d) . Thanks in advance.

So long as you use VMware with care it should prevent malware from affecting your host machine. That is unless the malware has a VM to host escape exploit, but they are relatively rare.

Some precautions you can take are as follows:

Don't connect the VM to your local network
Don't mount host folders or disks to the VM
Disable host-VM interfaces such as shared folders

You may find this guide useful: https://zeltser.com/build-malware-analysis-toolkit/