TrueCrypt Plausible Deniability - Linux As I understand it plausible deniability gives the user the option of having two passwords, one you provide the authorities/extortionist with and another that you might use for your self and files you may not want them seeing.

If someone were to use the plausible deniability and a court forced them to reveal their password in addition to the history file, are there any other files you might want to shred so as that there was not a record of using the "good" password?

As I see it you're as good as your weakest link, if there's a record of commands you've typed into your server isn't this all somewhat pointless?

As an alternative (or in addition) to completely disabling your command history, you could mount your encrypted volumes interactively. I haven't tried this myself, but the manpage tells us the -i option requests all security-sensitive information interactively from the user (so it doesn't get logged in your history file).

Of course as already indicated by others, if an "attacker" were to install a keylogger or such onto your system, none of these methods will work.


Converting ECC Private key to PKCS#1 format Is there any way to convert an ECC private key to RSA PKCS#1 format?
I have tried converting it to PKCS#8 first using OpenSSL:

openssl pkcs8 -topk8 -nocrypt -in EC_key.pem -out pkcs8_key.pem

This results in a pem file that is in (what i am assuming) the right PKCS8 format

-----BEGIN PRIVATE KEY-----
[snip]
-----END PRIVATE KEY-----

When trying to then convert it from PKCS#8 to PKCS#1 using the following command:

openssl pkcs8 -inform pem -nocrypt -in pkcs8_key.pem -out pkcs1_key.pem

I get the same file as from the previous step.

When using the following command for conversion:

openssl rsa –in pkcs8_key.pem –out pkcs1_key.pem

I get the following error:

  47049676604576:error:0607907F:digital envelope routines:EVP_PKEY_get1_RSA:expecting an rsa key:p_lib.c:279:

Can EC keys be converted to RSA PKCS#1 keys? And if yes, how?

There might be a bit of confusion here between "RSA Laboratories", the organization that edits the PKCS standards, and RSA, the cryptographic algorithm. PKCS#1 is one of the PKCS standards, thus edited by RSA Laboratories; it talks about the algorithm RSA, and only about the RSA algorithm.

In particular, there is no such thing as a "PKCS#1 format" for elliptic curve (EC) keys, because EC keys are not RSA keys -- they are EC keys, which is not at all the same kind of object.

However, confusion has spread a lot further, so let's unravel a few layers.

PKCS#1 talks about RSA and defines an ASN.1-based encoding for RSA private keys. It looks like this:

  RSAPrivateKey ::= SEQUENCE {
      version           Version,
      modulus           INTEGER,  -- n
      publicExponent    INTEGER,  -- e
      privateExponent   INTEGER,  -- d
      prime1            INTEGER,  -- p
      prime2            INTEGER,  -- q
      exponent1         INTEGER,  -- d mod (p-1)
      exponent2         INTEGER,  -- d mod (q-1)
      coefficient       INTEGER,  -- (inverse of q) mod p
      otherPrimeInfos   OtherPrimeInfos OPTIONAL
  }

We recognize here the various mathematical elements that constitute a RSA public/private key pair. Being based on ASN.1, this kind of object encodes (through DER) into some bytes. OpenSSL can produce and consume such a sequence of bytes; however, it is commonplace to further reencode these bytes into the traditional (and poorly specified) PEM format: the bytes are encoded with Base64, and a header and footer are added, that specify the kind of encoded object.

It is important to notice that the raw ASN.1-based format for RSA private keys, defined in PKCS#1, results in sequences of bytes that do NOT include an unambiguous identification for the key type. Any application that reads a DER-encoded RSA private key in that format must already know, beforehand, that it should expect a RSA private key. The PEM header, that says "RSA PRIVATE KEY", provides that information.

Since the PKCS standards don't talk about PEM, they provide their own solution to the issue of identifying the key type; it is called PKCS#8. A key in PKCS#8 format is again ASN.1-based, with a structure that looks like this:

  PrivateKeyInfo ::= SEQUENCE {
     version Version,
     privateKeyAlgorithm AlgorithmIdentifier {{PrivateKeyAlgorithms}},
     privateKey PrivateKey,
     attributes [0] Attributes OPTIONAL }

  Version ::= INTEGER {v1(0)} (v1,...)

  PrivateKey ::= OCTET STRING

What this means is that a PKCS#8 object really is a wrapper around some other format. In the case of a RSA private key, the wrapper indicates (through the privateKeyAlgorithm field) that the key is really a RSA key, and the contents of the PrivateKey field (an OCTET STRING, i.e. an arbitrary sequence of bytes) really are the DER encoding of a PKCS#1 private key.

OpenSSL, by default, won't let a PKCS#8 file live its life as a DER-encoded sequence of bytes; it will again convert it to PEM, and, this time, will add the "BEGIN PRIVATE KEY" header. Note that this header does not specify the key type, since the encoded object (turned to characters through Base64) already contains the information.

(As a further complication, PKCS#8 also defines an optional, often password-based encryption of private keys; and the traditional PEM-like format that OpenSSL implements also includes some generic support for password-based encryption; so you can have multiple combinations of wrappers that specify some kind of encryption, resulting in what can only be described as an utter mess.)

Now what does this tells us about EC keys ? EC keys are not described by PKCS#1 (that talks only about RSA). However, if there is a standard somewhere that says how an EC private key can be turned into a sequence of bytes, then:

that sequence of bytes could be PEM-encoded by OpenSSL with some explicit text header;
the same sequence of bytes could be wrapped into a PKCS#8 object.

And this is exactly what happens. The standard that defines the encoding format for EC keys is SEC 1 (nominally, the standard for EC cryptography is ANSI X9.62; however, while X9.62 reused much of SEC 1, the specification for encoding private EC keys is only in SEC 1, because X9.62 concerns itself only with the encoding of public keys). In SEC 1 (section C.4), the following is defined:

  ECPrivateKey ::= SEQUENCE {
         version       INTEGER { ecPrivkeyVer1(1) },
         privateKey    OCTET STRING,
         parameters    [0] EXPLICIT ECDomainParameters OPTIONAL,
         publicKey     [1] EXPLICIT BIT STRING OPTIONAL
  }

So an encoded private key contains the private key itself (a integer in the 1..n-1 range, where n is the curve subgroup order), optionally a description or reference to the used curve, and optionally a copy of the public key (which could otherwise be recomputed).

Let's try it. We generate with OpenSSL a new EC key pair, in the standard NIST P-256 curve (which is the curve that everybody implements and uses):

$ openssl ecparam -out ec1.pem -genkey -name prime256v1

We get this, in the ec1.pem file:

$ cat ec1.pem
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBdVHnnzZmJm+Z1HAYYOZlvnB8Dj8kVx9XBH+6UCWlGUoAoGCCqGSM49
AwEHoUQDQgAEThPp/xgEov0mKg2s0GII76VkZAcCc//3quAqzg+PuFKXgruaF7Kn
3tuQVWHBlyZX56oOstUYQh3418Z3Gb1+yw==
-----END EC PRIVATE KEY-----

The first element ("EC PARAMETERS") is redundant; it contains a reference to the used curve, but this information is also present in the second element. So let's use a text editor to remove the "EC PARAMETERS", and we keep only the "EC PRIVATE KEY" part. Now my ec1.pem file looks like this:

$ cat ec1.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBdVHnnzZmJm+Z1HAYYOZlvnB8Dj8kVx9XBH+6UCWlGUoAoGCCqGSM49
AwEHoUQDQgAEThPp/xgEov0mKg2s0GII76VkZAcCc//3quAqzg+PuFKXgruaF7Kn
3tuQVWHBlyZX56oOstUYQh3418Z3Gb1+yw==
-----END EC PRIVATE KEY-----

We can use OpenSSL to decode its structure:

$ openssl asn1parse -i -in ec1.pem
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING      [HEX DUMP]:17551E79F3666266F99D4701860E665BE707C0E3F24571F57047FBA5025A5194
   39:d=1  hl=2 l=  10 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   53:d=2  hl=2 l=  66 prim:   BIT STRING

We recognize the expected ASN.1 structure, as defined by SEC 1: a SEQUENCE that contains an INTEGER of value 1 (the version field), an OCTET STRING (the privateKey itself, which is a big-endian unsigned encoding of the mathematical private key), a reference (tagged with [0]) to the used curve (in the ASN.1 object it is the OID 1.2.840.10045.3.1.7; OpenSSL translates that to the name "prime256v1"), and (tagged with [1]) a copy of the public key.

We can convert that to the (unencrypted) PKCS#8 format:

$ openssl pkcs8 -topk8 -nocrypt -in ec1.pem -out ec2.pem

which yields this:

$ cat ec2.pem
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgF1UeefNmYmb5nUcB
hg5mW+cHwOPyRXH1cEf7pQJaUZShRANCAAROE+n/GASi/SYqDazQYgjvpWRkBwJz
//eq4CrOD4+4UpeCu5oXsqfe25BVYcGXJlfnqg6y1RhCHfjXxncZvX7L
-----END PRIVATE KEY-----

that we can decode with OpenSSL:

$ openssl asn1parse -i -in ec2.pem
    0:d=0  hl=3 l= 135 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim:  INTEGER           :00
    6:d=1  hl=2 l=  19 cons:  SEQUENCE
    8:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim:  OCTET STRING      [HEX DUMP]:306B0201010420(...)

(I have truncated the hexadecimal dump.) This structure is indeed a PKCS#8 object:

The algorithm identifier field says: "this contains an EC key" (technically, it uses an identifier whose name is "id-ecPublicKey", but since this occurs in a PKCS#8 file everybody knows that this really means an EC private key).
The file includes as key parameters a reference to the used curve.
The key value is encoded into the contents of an OCTET STRING. If we further decode that OCTET STRING, we will find the EC private key encoded as specified by SEC 1 (amusingly, the reference to the curve appears to have been omitted in that case, since it is already present in the key parameters).

Conversion can be made in the other direction (from PKCS#8 to raw SEC 1 format) with:

$ openssl ec -in ec2.pem -out ec3.pem

You will then get in file ec3.pem exactly what you had in file ec1.pem: a PEM-encoded object with header "BEGIN EC PRIVATE KEY".

Summary: There is no such thing as an "EC key in PKCS#1 format": PKCS#1 is only for RSA keys, not EC keys. However, there is another format, analogous to PKCS#1 but made for EC keys, and defined in SEC 1. OpenSSL can convert that format into the generic PKCS#8 with the "openssl pkcs8" command, and back into SEC 1 format with "openssl ec".


In a website that gives awards, is there anyway to ensure that one user isn't abusing the website and replaying the game by switching emails? I'm building a website that gives awards to users. After each game I ask the user for their email and send them an email to claim their gift.

Is there anyway to make sure that one user isn't simply opening new emails to take all the awards ? IPs can be changed so restricting them isn't a solution.

There isn't a foolproof way to stop this completely, the best you can do is to make it somewhat difficult for non-savvy users.

Primary tracking methods:

Cookies - Cookies are the first level of detecting previous visitors.  Using a unique cookie (like a nonce) has virtually zero false positives when asserting a user is a previous visitor.  Fortunately (or unfortunately in your case) it can be easily evaded by deleting/blocking cookies or using "private browsing" or "incognito" mode.
IP Address - The user's IP address would be the second level of detection used if no matching cookie was received.  If the IP matches, it's a decently high level of confidence that it was the previous visitor

  Side Note: You could also check if the IP address of the user is a known VPN, Proxy, or Tor exit node, and forbid awards to those if you're really worried about it.

ETag (web caching) - Servers can use the ETag header on responses for pages that the browser might potentially cache.  The ETag contains a unique value for the version of the resource being requested, such as ETag: 0123456789.  The next time the browser requests that resource it will send a If-None-Match: 0123456789 which either tells the server if it needs to send the latest version of that resource if it doesn't match, otherwise tells the browser to grab it from their cache if it does match.  This was originally designed for saving bandwidth, but of course this can also be used for tracking.

Browser/Device Fingerprinting:

If still not able to assert if the user has already received an award with the primary methods, and you're paranoid about people abusing the system, then your next line of detection would be browser/device fingerprinting.  This can be decently sophisticated when combining multiple metrics to generate a virtual fingerprint. Examples of such metrics:

HTTP Headers

User-Agent (Browser and OS version)
Accepted MIME types
Locale/Language
etc.

HTML5 Canvas and WebGL fingerprinting
WebRTC fingerprinting
Enumeration of browser plugins or extensions
AdBlocker presence
SSL/TLS protocol and cipher enumeration
Supported Fonts enumerated with javascript
Performance Bench marking with Javascript
Web Audio API fingerprinting

Web tracking software can factor these metrics together with different weighted scores for each one, to assert the user is a previous visitor with some degree of confidence.  Of course if your target audience is tech-savvy people, they can fairly easily avoid tracking.

Curious what your device fingerprint looks like?

These two sites might surprise you with how much information they were able to obtain by using some of these techniques listed above and possibly more:

https://www.deviceinfo.me/
https://amiunique.org/


CSR signature using elliptic curve We've been asked to generate certificate signing request using elliptic curve and we can't use any third-party library it's an embedded application with very limited resources).

We are used to generate CSR using RSA, but we can't find any documentation on how to do that with Elliptic Curve, specifically how to do the signing part. Studying OpenSSL-generated CSR it looks like there's multiple signatures generated, or a hash of some kind but we don't know. And OpenSSL source code is quite difficult to read when you're not used to.

Can anyone point us in the right direction?

I think it's kinda same as RSA you're used to. Most of CAs such as Digicert already supported, just use the same openssl toolsets.

For examples in Digicert guideline:

To create key in EC:

openssl ecparam -out server.key -name prime256v1 -genkey

And create CSR as usual:

openssl req -new -key server.key -out server.csr -sha256


What user was this spammer trying to authenticate as? I have a custom application that monitors and logs a user's SMTP session, and came across this spammer trying to use my MTA as a relay.

Is it possible to determine what username they are trying to log in as?

Waiting for a connection... Connected!

SmtpReceiveTestAgent_OnEhloCommand
DisableStartTLS: False
Domain: OWNEROR-KTATDUI
Spambypass False
AuthenticationSource Anonymous
HelloDomain
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 5.9.32.178
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 5.9.32.178:2648
SessionId 634767757514516172
Waiting for a connection... Connected!

SmtpReceiveTestAgent_OnAuthCommand
AuthenticationMechanism:
Spambypass False
AuthenticationSource Anonymous
HelloDomain OWNEROR-KTATDUI
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 5.9.32.178
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 5.9.32.178:2648
SessionId 634767757514516172
Waiting for a connection... Connected!

SmtpReceiveTestAgent_OnReject
Command: TlRMTVNTUAADAAAAGAAYAH4AAABSAVIBlgAAAAAAAABYAAAACAAIAFgAAAAeAB4AYAAAAAA
AAADoAQAABYKIogYBsR0AAAAP1fXonCW+WU07L/KUILITX3QAZQBzAHQATwBXAE4ARQBSAE8AUgAtAEs
AVABBAFQARABVAEkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdkWHUUPIHk2TIK1nq2Rj8QEBAAAAAAA
Acvo4+TJYzQFloTpuXluwygAAAAACABAAUgBFAEwAQQBZADMANgAwAAEAGABDAE8ATgBZAEMARQBYADM
ANgAwADAAMgAEABwAcgBlAGwAYQB5ADMANgAwAC4AbABvAGMAYQBsAAMANgBDAE8ATgBZAEMARQBYADM
ANgAwADAAMgAuAHIAZQBsAGEAeQAzADYAMAAuAGwAbwBjAGEAbAAFABwAcgBlAGwAYQB5ADMANgAwAC4
AbABvAGMAYQBsAAcACABy+jj5MljNAQYABAACAAAACAAwADAAAAAAAAAAAAAAAAAwAAC0ykOxCYthQLJ
DgBWZ1QybmTgAin969Z+a+/3oBg6+MwoAEAAAAAAAAAAAAAAAAAAAAAAACQAQAFMATQBUAFAAUwBWAEM
ALwAAAAAAAAAAAAAAAAA=
Original Arguments:
Parsing Status: Error
SMTP Response: 535 5.7.3 Authentication unsuccessful
Spambypass False
AuthenticationSource Anonymous
HelloDomain OWNEROR-KTATDUI
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 5.9.32.178
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 5.9.32.178:2648
SessionId 634767757514516172
Waiting for a connection... Connected!

SmtpReceiveTestAgent_OnHeloCommand
Helo Domain: 8.8.8.65
Spambypass False
AuthenticationSource Anonymous
HelloDomain
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 114.43.5.69
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 114.43.5.69:11968
SessionId 634767757514516612
Waiting for a connection... Connected!

SmtpReceiveTestAgent_onMailCommand
Auth:
BodyType: NotSpecified
DSN requested: NotSpecified
EnvelopeID:
FromAddress: 0503@msa.hinet.net
Oorg:
Size: 0
Spambypass False
AuthenticationSource Anonymous
HelloDomain 8.8.8.65
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 114.43.5.69
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 114.43.5.69:11968
SessionId 634767757514516612
Waiting for a connection... Connected!

SmtpReceiveTestAgent_OnReject
Command: RCPT TO: <superedm001@yahoo.com.tw>
Original Arguments:
Parsing Status: Error
SMTP Response: 550 5.7.1 Unable to relay
Spambypass False
AuthenticationSource Anonymous
HelloDomain 8.8.8.65
IsConnected True
IsExternalConnection True
IsTls False
LastExternalIPAddress 114.43.5.69
LocalEndPoint 10.10.10.242:25
RemoteEndPoint 114.43.5.69:11968
SessionId 634767757514516612
Waiting for a connection...

It seems they tried to login as test. This is the dissection of the field Command:

NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_AUTH (0x00000003)
Lan Manager Response: 000000000000000000000000000000000000000000000000
NTLM Client Challenge: 0000000000000000
NTLM Response: 7645875143c81e4d9320ad67ab6463f10101000000000000...
NTLM Client Challenge: 65a13a6e5e5bb0ca
Domain name: NULL
User name: test
Host name: OWNEROR-KTATDUI
Session Key: Empty
Flags: 0xa2888205
Version 6.1 (Build 7601); NTLM Current Revision 15
MIC: d5f5e89c25be594d3b2ff29420b2135


Sqlmap Sleepy User-Agent I was testing Burp Suite Crawl on some old php sites I made and it found Sleepy User-Agent
SQL injection vulnerability

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100
Safari/537.36 '+(select*from(select(sleep(20)))a)+'

And I am wondering how this can be applicable in sqlmap, I found that sqlmap can be used in Boolean-based and Time-dependent SQL injection (https://stackoverflow.com/questions/33708851/combination-of-boolean-based-and-time-dependent-sql-injection-in-sqlmap) but I can not figure it out how to use it in this User-Agent vulnerability

sqlmap have in test patterns Boolean-based with Time-dependent SQL injection but you must specify where you want to test SQL injections patterns.
So in my case I used option --user-agent="*" which should be empty user agent and * is specifying where this patterns will be tested (because in my case it do not require have something in it).
One more tip - when someone is using sqlmap over tor and want to test Time-dependent SQL injection, you must specify --time-sec= to atleast 4-5 seconds due the tor network speed.


synchronization of keyfob token generator At work, years ago, I used to have a key-fob device that was about the size of a thumb-drive.  It had a 4 digit LCD screen that the numbers changed every 60 seconds.  When logging onto certain servers, after entering my user ID and password, it would prompt me for the 4 digit passcode.
Now the key-fob was so small, I wonder how the process handled time drift.  Especially 15 years ago.
Possible ideas how this may work I came up with in my mind, not being too smart about such marvels:

The manufacturer is certain enough that the battery will last long enough, and the key-fob would stand up to dropping, being bashed in pockets/purses
The token has an atomic clock receiver in it to sync up every so often
When the server receives the token, it looks to seen when it last sent out that particular 4-digit code, and if it was "recently" (say within 15 seconds or so) it would say "okay"

But I doubt any of those are right.  Any ideas how that was handled?  I was always nervous about using a number that was about ready to expire.  I don't remember if I had to push a button on the key-fob to get a code.  I do remember it being fairly unreliable; worked about 80% the first try.

You miss one synchronization strategy:
If it's used semi-regularly (e.g. every few weeks), you only have to account for the amount of drift that can happen in a few weeks. Whenever you use a code, based on time and a secret key, to log in, the server first checks the accurate time code.
If the code for now doesn't match, it can trivially generate one cycle in to the future, and one into the past. If either of these match, we can be fairly certain that the clock of the token has drifted over a threshold. This fact is stored, as a offset. If the token is sending back replies that is 60 seconds late, we store that, and next time we try with that as the baseline.
Lather, rinse, repeat if token continues to drift. It does not allow huge drifts, but based on the number of codes in the past or future you accept, you can accommodate for as much drift as you need. It will weaken security a tiny bit.
Wikipedia says cheap quartz clocks approach 6ppm accuracy. Thus, we can expect them to be within 60 seconds of the server for at least 115 days. If we check two codes backwards and forwards, it can go for well over 200 days.
The allowed time window may be made as large as desired, perhaps based on last use, to allow for clock skew.


"No hack no fee" pen-testing agreements A common theme in security engineering is that perfect security is impossible (or at least highly unlikely). Consider Johnston's Infinity Maxim:

  There are an unlimited number of security vulnerabilities for a given security device, system, or program, most of which will never be discovered (by the good guys or bad guys).

With that in mind, how much sense does it make for penetration tests to be arranged on a "no hack, no fee" basis (analogous to "no win, no fee" legal engagements)? Put another way, does the Infinity Maxim hold true within the scope of real-life pen-testing scenarios? I'm interested in answers from experienced pen-testers, without reference to particular firms.

This is simply not a viable business option for security testing companies, as you can never know in advance what you will face during a pentest engagement.

Furthermore, those services are purchased by customers to evaluate the security level of a target application / infrastructure / device / whatever, the actual compromise of the target is only the consequence of a successful assessment, not the main objective.


How are Cloud based HSMs used for Encryption by an application that is on premise (behind the enterprise firewall)? Amazon CloudHSM (It is Safenet in the backend), Safenet Luna HSM SaaS version and other cloud HSM providers provide Key Management and encryption services on device in the cloud.

From my research, I understand that they can be used to encrypt some data and get the encrypted blob for storage in DB  / disk either on
- the CLOUD (Amazon RDS / Amazon S3) or
- On Premise behind the firewall (Local Database / Local File System)

(CloudHSM) <===== talking to ====> (On Premise  / Behind the Firewall application)

What are the Security concerns w.r.t this model ?
Any specific recommendations from Network Security point of view ?
Is this even a valid model in the first place.

In most cases, you would install the driver/engine software in your servers and would do PKCS#11 over TLS.

Be aware that some vendors' offering may not be a true HSM; specifically it may be the software and management around an HSM delivered as a virtual appliance. These are not meant to provide the same level of resilience to attack as a true HSM. The key-store is an encrypted file on the virtual appliance, and not an encrypted NVRAM inside a blob of epoxy. This means in theory, it could be repeatedly cloned for massively parallel offline cryptanalysis. As such, these virtual appliances will not receive FIPS-140 certification.

I cannot say which of the first-tier vendors I got this from, nor can I go into more depth, as some things are covered by NDA, but I would work closely with your employer's risk management team and audit to determine whether it is an acceptable risk to outsource.


Reply to potentially spoofed email A colleague recieved an unsolicited email along the lines below:

Dear Ms. Smith
please click on the following link to recieve Document X regarding
Project Y.
Yours,
Eve Nobody
eve.nobody@company.com

I suggested my colleague to reply to Eve Nobody, and ask whether the email is legitimate. Note, that we typed-in the address of Eve Nobody, since one could tamper with the reply-to header.
I assume three possible scenarios:

Eve Nobody exists and she did send the email
Eve Nobody exists, but she didn't send the email
Eve Nobody does not exist, and the email-server of company.com will reply with an error message

In all possible scenarios, we only interact with company.com, and not with any potential spoofer. Thus, I consider this course of action safe.
Was my advice sound, or are there other aspects to consider?

For context:

We are a firm which does research with academia and industry, hence we have plenty of information on our current projects along with the corresponding researchers. Thus, the information contained in the initial email (a reasonable title for Document X and the title of Project Y) can be gather from our homepage.
company.com is a legitimate company, and is involved in some research of ours.

You are focused on the person existing and not the account. Consider that Eve exists, did not send the email, but someone with access to her account did, and has entered an email rule to prevent your emails from hitting the inbox. You could carry on a conversation with that account but not Eve herself.
So I would add:

Account exists, email was sent from the account, but Eve did not send the email (compromised account)
Account exists, email was sent from the account, but Eve does not exist (dummy account)

In both cases, if you reply, you could be replying with the malicious actor and not Eve.
The best response is to contact Eve through some means other than email (call, other contact info, etc.)


My Firebase project has unknown users, has my google cloud service account been compromised? My project is a flutter app, it is in Internal Testing only, I am the only user. I've been working on this project for about a month and all of a sudden today I keep getting unknown users registering. These unknown users are not registering through my app otherwise I would see additional data in my Firestore database.
The only change I made today that I can think might be related is that I added the release SHA certificate fingerprints to my firebase project settings.
Security measures that I've taken: I changed all my passwords and turned on 2-factor authentication for my google accounts. Did not solve my problem, unknown users continue to be created.
I don't know much about service accounts but maybe my Firebase service account or a google cloud platform service account has been compromised? My Users and Permissions settings page says '10 service accounts also have access to this project.'
Are these accounts being created by google for some reason?
Here's a screenshot of my Auth users, there should only be one.

These accounts might be created by Pre-launch reports by Google bots. I had the same experience, the moment I published an app into Closed testing and enabled all countries these accounts started to appear in my Firebase Authentication Users report.
Try to provide your own Test account credentials in Google Play console under Pre-launch report settings and check if new accounts will still be created.


Why bother validating the hostname for a Google Recaptcha response? Google's Recaptcha has hostname validation "baked-in". When a user submits a Recpatcha response, the domain from which the response was acquired is validated against the whitelist of domains you provided when you setup the Recaptcha.

However, if you're using Recaptcha with multiple domains you have the option of disabling Google's default hostname validation and handling it yourself (https://developers.google.com/recaptcha/docs/domain_validation).

Google accompanies this with a prominent warning that not validating the hostname for any given response opens you up to a security vulnerability. But considering how easy it is to spoof the hostname, I don't see how this ever provided any degree of security enhancement.

A simple test proved to me just how easy it is to spoof the hostname value that Google uses to validate the origin of the Recaptcha response:

$ sudo nano /etc/hosts
127.0.0.1    spoofedhostname.com

And then when I sent a test Recaptcha response the result I got back was as follows:

{
    "success": true,
    "challenge_ts": "2016-12-24T14:15:22Z",
    "hostname": "spoofedhostname.com"
}

So Why Bother With Hostname Validation At All?

Hostname validation is largely known to be useless considering how easy it is to spoof.
This seems to have something to do with preventing an attacker from stealing your Recaptcha public key and then generating a bunch of valid Recaptcha responses, which they could store and then use when automating an attack on sensitive endpoints (/login, /reset-password). Theoretically, this could be used in some sort of brute force attack, but it doesn't really make sense considering the response tokens expire after 1 min. And you would still need to manually solve all the Recaptchas, which you could simply do on the actual domain. And, again, they could easily just spoof your domain even if you are doing hostname validation.

It just doesn't make any sense to me, but considering it's a Google product, I have to think that their security engineers know something that I don't.

What am I missing?

It may have something to do with people embedding your captchas on a site they set up, and using the solved captchas to spam your site.

For example, set up a site and give something for free (pirated movies/software, porn, etc) but ask for the captcha. Internally this is actually your captcha, and any solved captcha is passed down to a spambot targeting your site. This gives an attacker cost-efficient access to human captcha solving compared to the conventional captcha farms.

The hostname validation would prevent the captcha's JS from loading on an unauthorized site.

Update: I've recently implemented a demo of bypassing this by rendering the captcha on the original site in a headless browser and then using Websocket magic to stream it on my "bait" site (in this case a simple URL shortener that asks for the captcha before redirecting to the target site). This required considerable amounts of RAM (each Firefox instance was about 500MB) compared to the equivalent of rendering the captcha directly on the bait site, so this hostname verification feature is definitely a major pain for spammers.


server that responds on any port I want to make a server that responds open to every port that is scanned by nmap (TCP and UDP).

Are there a simple solution to do that?

You could just port-forward (i.e. DNAT) anything incoming from certain ranges to a single port with a generic listener of some form on it.

Something like:

iptables -t nat -A PREROUTING -s 1.1.1.1/24 -p tcp --dports 0:65535 -j DNAT --to-port 8080

Obviously, whether or not that actually works for your purposes depends on your use-case.


Setting up SFTP at Production Server is a Risk? There is a requirement to setup a SFTP server. This will be used by some of user b2b agents to upload files.

Such kind of setup is always doubtfully risky in production environment where user can upload the malicious content, I am not sure how this could be achieved but I'd rather not take any risk.

I need recommendations to get back to product team & would appretiate if this setup could be implemented in a more secure way. What would be the key pointers to achieve this setup?

EDIT:

OS: CentOS.

Anywhere you provide the facility to upload content, there is a risk of uploading malware. Either manage the risk or don't allow uploads.

Regarding the protocol, unlike HTTP(S) and SMTP servers, I'm not aware of any SFTP server which allows you to deal with the files as a synchronous operation triggered by the upload. However it is possible to do it asynchronously on Linux with minimal latency using inotify (but there are some complications over handling transfers that take a while to complete). You can also poll the directories or monitor the SFTP log to trigger processing on the gateway.

Regardless of the method you use, you should keep uploads and downloads separate, and keep each users uploads separate. And not make content available as a download until you've checked its content.

As to the processing required to deem that a file is safe....using an anti-virus product is one solution, however:

they are only effective against known exploits
most configure themselves to run on-access. This is nightmare for a gateway type scenario where you want to control the dataflow programmatically
the ones that can be configured to scan on-demand frequently do so as a single process - i.e. the program needs to load the entire virus definition file for each operation, uses a lot of memory, disk I/O and time

(a notable exception to 2 and 3 is clamdscan which acts as a frontend to a scanning daemon).


Threats against website running without TLS but with PGP messages Are there any threats against a web site that isn't running SSL but uses PGP to encrypt all information to the server (except session identifier)

The information flow is as such:
1. Session ID set on User browser
2. User selects a book from a list of books and submits it to Server
3. User submits Credit Card information to Server
4. Server displays downloadable book (link is randomly generated and temporary)

The main problem you find is with the validation of information, without validate the server's PGP key you can not confirm the integrity nor the confidentiality of your information.

What could happen:

Server: sends the public key to the client;

Man-in-the-middle: Receive the public key, and send his own public key to the victim;

Victim: Receives the attacker public key;

When server sends information to victim, the attacker would simple read, or change it, and then send it to the victim.


Software validation process Two days ago I asked that question:
Are web browser able to use camera without permission?

and I got an answer saying : "there have been multiple vulnerabilities in Flash, Chrome and even Facebook"

Is there a process to validate that a software developed by a company is safe ?
I mean, is it really impossible to prove that a software is safe ? internal or external process ?

Thanks a lot

The idea of provably secure systems exists, but it's not practical for large/dynamic codebases, although you do see it for some software related to cryptography. Also to carry out the checking required, would be far more effort than an ordinary user of the software would be able to go to.

For practical purposes it's very difficult for a user of software to know that it's "secure" (I put that in quotes as the word secure means different things to different people)

The best that's practical is usually to keep up with the vendors security releases, avoid software with a recent bad history of security flaws and minimize the amount of software you run when accessing content on an untrusted network (e.g. the Internet)


Strange Finished message in TLS I've tried to understand the content of the Finished message of TLS. I'm using WireShark to capture the traffic between my browser and the internet. I noticed a "strangeness" when the chosen ciphersuite is AES_GCM. Being it a stream-cipher, it has no padding, so, if I got it right, the data being sent in the Finished message should be:

8 bytes Explicit Nonce
12 bytes verify_data
16 bytes authentication tag

That is, 36 bytes in total. The "problem" is that the Finished message packet size is 40 bytes.
And here it is:
Server-to-client

Why is the message packet 40 bytes? And what are the red bytes?
And why does WireShark see two Hello Requests?
And another this... the Client answers with a 176 bytes packet:
Client-to-server

What am I missing?

EDIT: I didn't realize when I answered, but this is a dupe of Crazy Finished Message in TLS

The decodings as HelloRequest are indeed as @Stackz suggests because Wireshark can't decode encrypted records. It tries anyway, and only if it detects a decode failure it suppresses the decode and displays "Encrypted Handshake Message". Here it didn't detect the decode was completely bogus.

Every handshake message (within a handshake record) begins with a prefix of 1-byte msg_type and 3-byte length, see http://tools.ietf.org/html/rfc5246#section-7.4 . Thus you have:
* 8 bytes explicit nonce
* 16 bytes encryption of 1byte=0x14 type, 3bytes=0x00000C len, 12bytes verify_data
* 16 bytes authtag
TOTAL 40

On the client side, maybe the client immediately initiated another handshake; 136 bytes is plausible for ClientHello, especially if "optimized" with knowledge what the server just agreed to.


XSS: Character showing in DOM I have created an html page that redirects user to a test site that has an XSS vulnerability. I am able to successfully execute javascript via the vulnerability. However, I have found that some of the characters I am using as part of the XSS attack are displaying in the DOM. How can I hide these characters from showing in the DOM?

<body onload="document.forms[0].submit()">
    <form action="http://sometestsite.com" method="POST">
      <input type="hidden"
        name="login"
        value='"><script>alert(3)</script>' />
    </form>
  </body>

You are likely injecting into something like this:

<input type="text" value="[payload]">

What you are currently doing is closing the value attribute with " and the input tag with >, and then adding your script payload:

<input type="text" value=""><script>alert(3)</script>">

If you don't want the DOM to look broken, you need to fix the remaining characters (">). These are not from your attack string, but the remaining ones from the legitimate tag the application is using.

One way to fix this would be to use the following payload:

"><script>alert(3)</script><x y="

This will now result in:

<input type="text" value=""><script>alert(3)</script><x y="">


elearning pin authentication I work on a health and safety website which provides an online course with certification. We have recently strengthened security by hashing admin passwords.

The question relates to the user's access to the course. Currently an administrator will activate a student's serial by nominating a username. They then give this to the student who is responsible for setting their own password which is also hashed.

The issue is since hashing user passwords, it takes much longer for students to activate serials and access/complete the course. Previously, the administrator would activate a student serial on their behalf with a choice of username. The system would then automatically generate a unique password of approx. 12 characters which was stored in plain text. This meant the administrator could activate a series of logins for say 12 students at a time and print/issue a PDF with their full login. This system was much easier for everyone to understand, but of course the administrator could see their passwords.

What I am wondering, is there a distinction in security circles between passwords and an access code/pin. Say just a series of 3 inputs/select menus accepting values 1-10 for the user access instead of password. So the simplified pin could be stored/printed in plain text, on the understanding it is only temporary and will be erased as soon as the course is complete?

The idea is if its just a 3 digit pin then even if stored in plain text it is of no use to a hacker, because it is not going to be accepted as a password on any other typical website. Also only 2 attempts could be permitted to login before locking to avoid brute force attacks. The user may only need the access-pin for up to an hour while they complete the course before it is erased from the database. Is there a secure way of reverting back to a more simplified username + pin-based login for temporary e-learner access?

There are a bunch of different questions packed in here, so I'm just going to answer the surface-level ones.

Are temporary / single-use PINs acceptable in security circles?

Absolutely, but only if it's either A) one time use, or B) sufficiently long to prevent brute-forcing (ie 256 bits of randomness).

Example A: Google account verification email, the thing that's blanked out is a random one time use access token. If you try to click it twice, the second try will bounce:

Example B: It's also common to use this for generating a link for anonymous access to content, but here it's not one time use so the token needs sufficiently long and sufficiently random to prevent brute-forcing.

Is a 3 digit PIN long enough?

Maybe? Locking out a PIN after 2 incorrect attempts may solve your problem, but it also presents an easy avenue for an attacker to DOS your service (ie keep your users perpetually locked out and thus block them from accessing the service).

Personally, I would ditch the idea that the PIN is "replacing" a password, and instead follow Google's lead by emailing out a long one-time-use link that tells the server which user and which course to grant them access to. This will be both lower friction for your users, and less to go wrong from a security perspective.


Application level security...won't I end up just duplicating TLS? I'm creating a communications protocol for a custom device, and originally I planned to simply use Transport Level Security (TLS) as the means of security/encryption. I've been instructed (this is for a job) that Application Level Security (ALS, which I believe would have to be defined by me) must be used instead, with very vague justifications behind this decision.

In what sort of situations is TLS inappropriate (where ALS is appropriate)?

Is it likely that in the course of creating this ALS scheme, I'm likely to end up reimplementing (poorly) TLS, just at the application level?

Usually, when people say that they don't want TLS but something called "application-level", then the raw, naked truth is that they don't know what they are blabbering about.

Mind the "usually", though: there are situations where TLS is insufficient, and something else is needed and is to be applied at some level which can be dubbed "application". Main case is when some client has to send requests with some sort of enforceable responsibility; in short words, when requests must be signed so that, should problems occurs, the request could serve as proof during a trial. TLS does not do signatures; it uses signatures internally, but only for authentication. The client can be sure that it talks to the right server (and also vice versa, if client certificates are used), but it has no proof which could be convincing in the eyes of a judge.

Of course, people who require "ALS" but cannot give decent specifications are unlikely to be aware of such subtleties. They are probably just applying some piece of dogma that they do not understand. To counter that, do as they ask: implement some Application-Level Security which consists in exchanging "messages" as "sequences of bytes" which happen to be identical to what is described in RFC 5246.

This point has been made before, brilliantly, in an easy-to-grasp graphic format:

(I hope Scott Adams' lawyers will forgive me for quoting this remarkable piece of wisdom.)


Is XSS possible if I insert untrusted data into an quoted HTML attribute and HTML encode the " sign? If I insert untrusted data in a HTML attribute like this:

<img src="http://www.mydomain/<%untrusted_data%>">

and if I HTML encode the " sign in the untrusted data, is this particular code snipped fully protected against XSS? I know that I should be careful not to allow the user to insert the whole URL because then they could insert javascript:alert().

Yes, if the attribute is double quoted and you are encoding the double quote character, then it shouldn't be possible to escape from the quoted attribute.

However, I would also encode the & symbol because that can be used to start an encoded character in itself.

The HTML5 spec states:

  A double-quoted attribute value is specified by providing the
  following parts in exactly the following order:

  an attribute name
  zero or more space characters
  a single "=" character
  zero or more space characters
  a single """ character
  an attribute
  value
  a """ character

  In addition to the general requirements for
  attribute values, a double-quoted attribute value has the following
  restriction:

  must not contain any literal """ characters


MitM attempt resulting in ICMP redirects I am trying to 'man in the middle' a device on my wifi network. I have configured it to use my Linux machine (also in the wifi network) as a default gateway.

On the Linux (attack) host, I switched on IPv4 forwarding using

# sysctl -w net.ipv4.ip_forward=1

Then I start looking at the traffic from the victim device using wireshark.
I then saw that the attack machine sends ICMP redirect packets to the victim device, pointing it to the actual default gateway in the network. That is, obviously, not what I want it to do.

Then I tried disabling ICMP redirects using

# sysctl -w net.ipv4.conf.all.send_redirects=0

That seemed to work, but after a while the redirect packets started to appear again...

Any clues to what I can do to fix?

In my experience this

sysctl -w net.ipv4.conf.all.send_redirects=0

will not work properly on some systems what works for me is

echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects


Forgotten password or reset link, which is more secure to email? I originally posted this as a reply here in this thread but didn't get much feedback on it, and now I'm curious as to what others think is the best approach, or if there is any difference between the two approaches.

The original point was whether it was more secure to send out a password reset link when a user forgets their password to a website, or whether to send the original password unencrypted in an email.

Now not salting and encrypting a password is bad because when the database is eventually stolen from the website the attacker will have all the passwords clear as day.  OK fine, I get that.

But if we ignore the possibility of the database being stolen and only look at the user forgetting their password and going through the "forgotten password steps"; is it more, the same or less secure to send a reset link over a plain text password in an email?

My thinking is that it is the same.  Because if an attacker has access to your email by any means (he knows your email login details, or he's snooping the traffic somewhere) he therefore has access to the plain text password that's sent or the reset link - even if it is a limited time link.

The attacker could reset your password before you even know you have an email.

Is my thinking here flawed?

It's far simpler to get access to the existing corpus of email than to get access to the incoming stream.  For example, getting a couple of minutes of access to someone's system allows easy searching through their email.  So, for the case where an attacker has access to old mail, but not to the stream of new, incoming, mail:

You are relying on the user either changing their password after they receive it (unlikely, given that you've told them what it is), or deleting (permanently, not archiving or moving to a 'trash' folder, also unlikely) the reminder message.

If this doesn't happen, then if I get access to the user's email account some time later, then a (limited time/limited use, perhaps even limited such that the attacker cannot easily use it) reset link is not going to be any use to me, but having the (most likely still valid) password certainly is.

In addition, by sending me the plain-text password, you are demonstrating that you have this stored somewhere accessible.  In most cases, there is no need for this, because you don't need to encrypt the password (and salt/pepper), you only need to hash it.  If it's encrypted, then anyone with access to the database and the decryption key (e.g. probably most of the staff, or anyone that steals the code along with the database) is able to get the plain-text password.  If it's hashed, then you'd have to get it before the hashing takes place (e.g. during a login session).

Furthermore, although people shouldn't, it's very common to use the same password (or very similar passwords) on multiple sites.  That means that rather than providing a way to get into only one account, you're providing a way to get into many.

For the other case, where the attacker has access to all incoming mail (potentially even the ability to remove incoming mail before the user sees it), neither of these are secure.  The email account is high-risk, because if you have that sort of access, then you can likely go to every site that the user has an account with, and generate a password reset.  To avoid this, you need to use something other than (or as well as) your email account to get access, such as two-factor authentication.

Note that even in the latter case, a reset link is still superior: if the attacker changes the user's password via a reset link, then when the user tries to log in, they'll find out that something is wrong (too late, but at least they know).  If you're just providing the password, then the user has no idea that the attacker has silently gained access.


Why does AES encryption take more time than decryption? While I was studying the time consumed by some methods I found that encryption take more time than decryption. Is this right? I am using AES (the same steps will be taken during the enc and dec)

Several symmetric block ciphers (specifically ones like AES, DES, Blowfish, RC5) will take the same amount of time (within measurement error) for encryption and decryption, when operating on a single block (e.g., 128-bits for AES).

However, there are a couple reasons why it appears different when encrypting/decrypting multiple blocks.  For example, with cipher-block chaining (CBC), encryption must be done sequentially (encrypt block 0 before you can encrypt block 1 before you can encrypt block 2 ...), while decryption can be parallelized as the XOR step (with the previous block of ciphertext) is done after the block cipher is applied.

See the diagrams below (XOR is denoted with a circled plus ⊕).  To encrypt the second block of plaintext p[1], you use c[1] = AES_Encrypt(p[1] XOR c[0]), this means you can't generate c[1] until you are finished generating c[0].

Meanwhile to decrypt the second block of ciphertext, you use p[1] = c[0] XOR AES_Decrypt(c[1]).  This is not dependent on the previous block of plaintext p[0] so can be completely parallelized (and can run much faster on multi-core systems).

If you want fast decryption and encryption, you may consider using CTR as it can be parallelized on both encryption and decryption.

You also potentially should be wary of tests that are skewed because of caches on your system.  If you randomly decide to read a file from disk and encrypt it, it will take several milliseconds to read each chunk of the file; however the next time you access it the file will generally be cached in memory and be accessed much quicker.  Meanwhile for your decryption test that encrypted file that was recently written to disk will likely still be in a cache in memory and will not suffer the penalty from reading from disk.

CTR Timing

$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m58.217s
user    0m5.788s
sys     0m8.493s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m34.780s
user    0m4.800s
sys     0m7.748s
$ time openssl aes-256-ctr -e -salt -pass pass:passwd -in Fedora_64-bit.vmdk -out vmdk.encrypted

real    0m34.989s
user    0m4.120s
sys     0m6.444s
$ time openssl aes-256-ctr -d -salt -pass pass:passwd -in vmdk.encrypted -out decrypted

real    0m35.944s
user    0m4.140s
sys     0m7.008s

The first three encryptions show the effect of the disk cache, where the first access of a file was much slower than subsequent accesses.  It also shows that for CTR that both encryption / decryption of this 7.4 G virtual machine took roughly 35 seconds.  (On repetition occasionally, decryption would be faster or slower).


What's a secure way to prompt for a password and erase the cached password afterwards in Linux? So I have multiple hard drives encrypted with the same password and instead of having to enter it multiple times I'd like to have it set up so that after booting I automatically get a password-box displayed into which I enter the password once and which then mounts all the encrypted hard drives and securely removes the password from cache/memory afterwards.

It seems that this isn't yet possible via standard VeraCrypt. Hence it looks I need to write a short script to get this functionality. However for that I need to know how to securely prompt for a password and most importantly: how to securely erase the cached password after the volumes have been mounted.

I'm using Debian 9.1 with KDE.
(I'd also be interested whether there are any specific reasons why this isn't a standard VeraCrypt feature.)

I don't think you will be able to guarantee that.

So, let's assume you have a command that takes the password in a prompt, eg.

  echo mypassword | cryptsetup luksOpen /dev/disk volume`

And want to ask for the password once and open several volumes:

#!/bin/sh
set -e
read -p "What's the password? " password || exit 1
for disk in disk1 disk2 disk3; do
   FOLDER=/media/$USER/$disk
   echo "$password" | cryptsetup luksOpen /dev/$disk $disk && \
   mkdir -p "$FOLDER" && \
   mount /dev/mapper/$disk "$FOLDER/$disk"
done
password="xxxxxxxxxxxxxxxxxxxxxx"

This shell script would do. Except that, after bash finishes, and the memory is returned to the system, we have no guarantee that the password itself is not still in memory somewhere (no, despite that last statement your shell may not overwrite the location where it was saved).

So, we could rewrite this in C, and manually ensure that such location is overwriten, using something like memset_s (yes, a normal memset wouldn't do).

Still, there could be copies of the plaintext password in the stdio buffers, the ones used by cryptsetup, etc. The kernel will not give such pages to other programs without first zeroing them, but if a forensic investigator came freezing your memory slots with nitrogen and dumping it contents, it could still be there.

Moreover, the actual disk key (decrypted from the passphrase) will be in memory, for as long as you have the volumes mounted. So, it is probably not worth insisting on ensuring that much, and just letting the program finish would be acceptable.

I would suggest encrypting the main disk partition (and swap, of course), and have keyfiles for each of the other disks on there (they can be readable just for root). Thus, you only need to enter one password (at boot time) and will be able to decrypt all disks. There are no encrypted passwords laying out when the system is powered down, and if an attacker got root your system so they would be able to steal your keyfiles, he could access the files directly as well (and do too many other nasty things), so it doesn't make things much more insecure.

The main scenario for that I can think is where repeated access is obtained, eg. your encrypted disks are cloned, and later (after you shreded some secrets from them), they obtain your passphrase/keyfiles, thus being able to decrypt their earlier copy. They could probably do that as well by extracting the in-memory disk keys, but the existence of the keyfiles make things simpler. (In order to avoid this, change your passwords and keyfiles and rekey the disk after removing the Coke secret formula)

Hope this helps


/var got mysteriously renamed in /var.1 on CentOS6 server On one of our CentOS6 servers, /var got renamed to /var.1 tonight (around 3.24 am) and a new empty /var folder was created. Not surprisingly, it crashed soon after that.

Circumstances:

Over the last two days, we have been DDOS'd by botnet activity conducting an apparent reflection attack against a large local business
This (mail, name) server exposes imap(s) pop3(s) smtp(s), http(s) and 587 ports - all of them FortiGate and fail2ban protected. All experienced unusual activity related to the previous point.
The time of the accident is about the same of the standard cron maintenance activity

I am still poring over the logs. Because of the first point, malware would be an obvious suspect except that renaming /var is a pretty self-harming activity for some actor willing to take over the machine while concealing itself. So I am thinking at some maintenance task gone awry (such as a disk filling up during /var cleanup). However, I cannot think of anything that does similar shenanigans.

Is anybody able to shed light?

So, after some log perusal, it turns out no foul play was involved. Somebody made an editing snafu in a logrotate config file, about 15 days ago, for a monthly rotation
( var log /stuff instead of /var/log/stuff). As luck had it, it kicked in during the DDOS, clouding the picture - though, in truth, the var**.1** thing should have given me pause much sooner. Thanks to all who bothered.


Distribution of keys for a python messaging application I am developing a messaging application, more like a chat, in python just to teach my self how sockets work and to learn more about cryptography in general by using PyCrypto.

About my application:

The main purpose of this application cryptographic-wise is to secure messages sent over internet using an asymmetric encryption. Since I am doing this to increase my knowledge concerning cryptography I want it as secure as possible. In this application a client connects to a server and is added to a list holding all currently connected users. The client can now send a message to the server which echoes the message out to all other connected users.

My question:

As a small disclaimer: I am fairly new to encryption in general and there is a couple of things I cant wrap my head around. I cant quite figure out how I should distribute the public keys so that an asymmetric encryption can be used to secure messages sent to the server. From what I've read, there is supposed to be some kind of a server I can retrieve generated keys from but I cant seem to find such a service.

Also, if I would be able to retrieve a public key from a key server, how should I generate a private key so that it can be decrypted?

All help, suggestions and corrections are greatly appreciated!

-Tommy

A simple solution would be for each client to encrypt messages sent to the server using the server's public key, which is usually sent to the client as part of connection negotiation. The server can then decrypt the client's message using its private key, and then re-encrypt it using the private key to distribute the message back to the other clients - who can then read the message using the server's public key to decrypt.

'Better' solutions would involve distributing each the public keys of all connected clients as part of the initial handshake. The client would need some means of knowing how to associate a public key with the message sender which means that there is some information leakage outside of the encrypted text. This is better because now the server can be compromised and the information being transmitted is still safe, but comes at the cost of slower connection speeds and additional complexity.


Equifax Data Breach 2017 In September 2017 a large data breach at the US consumer credit reporting company, Equifax, was announced.

How did the criminals access this data?  What was the exploit?

The story below maintains a link to the testimony given by Equifax CEO Richard F Smith. In his testimony he admits that it was indeed the Apache Struts vulnerability that was used.

However, what is not revealed is how the instigators pivoted to escalate their privileges.

https://www.theregister.co.uk/2017/10/02/equifax_ceo_richard_smith_congressional_testimony/

This flaw has been exploited before, so there are some examples.

https://www.bleepingcomputer.com/news/security/equifax-confirms-hackers-used-apache-struts-vulnerability-to-breach-its-servers/


View windows vault with mimikatz I'm following this article to decrypt windows vault (On Windows 7 x86)

I've added two credentials for testing,

But in either Local or Roaming, I have nothing in the Credentails folder

Where I only have a policy file

What could be wrong here?

And if I'm going to do this with mimikatz alone, what commands should I use? The official wiki is empty

Maybe try this to show important files in your explorer?


Authenticate user based on mobile device identifier I have a hypothetical mobile game where players don't necessarily need to create accounts to play. Their data is keyed off of a device identifier like an advertising identifier (IDFA) or Apple's identifierForVendor or Android ID

For GDPR, I need to allow all users to download their data.

Is it safe to use the ID as an authentication secret to uniquely identify a user/device, or are these ID values predictable / published somewhere and easy to spoof?

If you can get the device ID, so can any malicious app
Think about it this way: would you want every other app on the player's phone to have the ability to send data to a centralized hub where they could then make fake web requests to your game on behalf of this user?
Now, sure, most of the apps on the user's phone aren't doing this, but do you really want to open that door?
If you want passwordless authentication and good security, you are probably better off going with a standard solution (Authy, maybe Authentiq, etc.).


Mobile App Security vs. Traditional PC Desktop Security In The New Era I have been using a Windows PC for many years now. Since Android has come to market, I have been very wary of installing apps that require unrelated permissions. Obvoiusly, these extra permissions could be used for malignant purposes, or they could just be used for troubleshooting... always hard to tell. However, I have never worried about this on Windows, which does not have an app store that lists permissions. Obviously, I am careful to scan all file types with a quality anti-virus before running, but I'm not sure the threats to the PC (in terms of trusting the software developer) are any different than the privacy threats of mobile developers. Most of the time I regard commercial software that I purchase or run for free as being developed by a company (although there are many lone developers out there as well).  The creation of the app store has provided a means for me to see many strange names in the developer section, and I'm not sure who to trust. Yes, an app may have many thousands of good reviews, but who has reverse engineered these apps, reviewed their source code, or monitored them while they sit and run to see what they do when you go to sleep? Again, with the PC, I never worried about it "going through my contacts" (there were none), "accessing my camera" (there wasn't one), "accessing phone call records" (there were none), etc. So this part is a little different from PC to mobile in many cases. (Yes, I know many PCs have webcams, contacts, etc.) However, a malicious developer could have free reign of my PC if his code passed the AV.

I'm not sure if it is the permissions list provided by the App Store that is so disconcerting, and that I am just not use to it...

{END WALL OF TEXT}

...But my question is in light of all that was stated previously (disconcerting and free-ranging mobile app permissions), has anything really changed in terms of the reality of privacy and permissions as people move from PC to Mobile? Should we just click "install the app" because that is what we were doing anyways on the PC?

{BEGIN WALL OF TEXT}

Bonus Points: I know that there are researchers out there who look for malicious apps, but there selections seem to be random and the information is scattered across multiple research labs. Is there a database or source for security reviews on specific apps (other than the permisions listed in the App Store)?

*Please no comments such as "Quit whining" or "How can you expect to have so many apps available to you without also having so many developers with strange names?" or "You want your cake and to eat it too?"... I am trying to figure out how to live in this new world.

No.

You should not click install the app. The process I go by is quite simple:

What is the app doing?
What are the permissions?
Is that permission really needed?

Now let's look at a simple example:

What is the app doing? Eg: Simple text editor.(Read/Write stuff from/to files)
What are the permissions?

Case 1:
Permissions: Read/Write files. Access microphone.
I am tempted to accept this one. Although this one asks for microphone it might use it for text/to speech. If it does this it should mention it in the description. Even if it does that, it could still be spying on you. But none the less, the app might be innocent.

Case 2:
Permissions: Read/Write files. Access microphone. Access contacts. Access network connection.
This one would make me have second thoughts. As said before, the app should be a simple text editor. There's no need for a simple text editor to use contact and connect to the internet.

Bonus:
If you want to go really hardcore, what you should do is reverse engineer the application. Look at how those permissions are being used within the app.  Where is my app connection to the internet. What is happening with that connection. where is the microphone invoked and where is the recorded sound going.


Proxied server requests + forwarding authentication info in a secure fashion We are using PassportJS with a couple of Node.js servers - Passport is just a library that is popular for Node.js server authentication - but we have some questions about how to use Passport with "proxy" requests. My main question is how do we (and should we at all) forward the headers and cookies in the original request to the proxied request?

For example - we make a browser-client request to server A which in turn makes a request to server B - we want the same client to be authenticated in the same way on both servers. Currently if the web client makes a request directly to both servers, the client is authenticated, but if the client authenticates with A and then A sends a completely new request to server B, then of course, that second request contains none of the auth info that is needed to authenticate the client on server B.

Considering we own both servers A and B, should we just include the headers and cookies from the original request in our request from server A to B?

is this considered a good practice? Any info would be helpful, thanks

I asked a similar question of Jared Hannson of PassportJS fame:

https://github.com/jaredhanson/passport-github/issues/52

Given a good answer here, I might copy it over there

This question is really one specific to your business needs.

In general what you have proposed is commonly done.  You are always faced with the challenge of balancing usability with security.  Take Yahoo or Google for example.  They authenticate you once then store information in one (or more) cookies that are passed to other sites with which they integrate.  Then look at the Yahoo wallet (when it was the prime thing for payment on the internet in the late 1990s and early 2000s), it required yet another authentication with different credentials.  They thought, and I agree, that this piece of their infrastructure needed an additional layer that was from the rest.  That is, they did not trust the main site credentials.

Note neither Google nor Yahoo pass the user passwords around their sites or store them directly in cookies or databases.  Rather, they establish a verification system.  For example the hash that becomes the cookie can contain tidbits of information identifying the browser client, a fraction of the source address, authorization tokens, ++++.  There are many sufficient schemes.

So, does the security of your site need the user to perform authentication for both servers A and B?  Only you can answer that.  If the answer is no, then you should trust the result of the authentication from server A. If your answer is yes, then authenticate at both places.


Is it possible to emulate real network printer i.e. to run some actual firmware in VM? I've got to the section related to network printers exploitation while going through one security course. Under "network printer" I understand standalone devices with a dedicated ethernet\wireless link, listening on port 9100, with some administration interface (web, snmp, vendor's custom app) accessible over the network, or something like that. There were several attacks I would really love to try to reproduce, but I'm definetely do not want to buy them all (actually some of them would cost me a fortune). But it seems that most of these devices nowdays run some kind of linux as firmware (at least the most expensive of them do), and this firmware is easy to acquire. So I thought there could be some project aiming to emulate some of them (well, we have GNS for Cisco, so why not?).

I must clarify: I'm not talking about some virtual printer shared from MS Windows host or about a generic linux box with some general purpose printing daemon listening on port 9100. I need an exact firmware of some really existing network printer running on a virtuall machine of sort. It needn't to actually print something (like, to file), but from all other perspectives it must handle all connections and requests as the real one would did.

Kind regards and thank you for help in advance.

I'd recommend Virtutech's SIMICS software. Note that Virtutech was bought by Intel and assigned to their subsidiary: Wind River.

Simics is a SIMULATOR, which has important distinctions from an EMULATOR (like qemu). See https://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference for specifics on the differences.

Simics simulates many (hundreds?) of architectures. You select the specific one you are interested in (in your case, the architecture in use by the desired printer) and load it's environment within simics. Then you load the software (kernel & OS if it has an OS) that you want to test. Afterwards you execute simics and it boots and executes the target software exactly as it would execute on the native hardware. This is a chief benefit of simulators versus emulators.

With simics you can pause execution, set breakpoints in the kernel, and reverse a crash! Indeed, you can encounter a crash and then effectively execute in reverse to understand what led to the crash. You cannot easily do that in an emulator and even if you were to attempt it the internal state of the emulator differs from the real hardware architecture of the target so the results are mixed.

BLUF: you need a SIMULATOR not an EMULATOR.

[edit]: Link to simics information: http://www.windriver.com/products/simics/


Sanitizing input for parameterized queries If I use fully parameterized queries everywhere, is it still necessary and/or security-relevant to somehow sanitize input? E.g. check that mail addresses are valid before sending a parameterized query against the database, or filtering out certain special characters from text?

I think of benign, but not-so-well-engineered 3rd party tools (maybe self-written scripts by the admin, or some fancy CrystalReports made by a non-technician) trying to consume unsanitized data from our database.

Right now, we have full unicode support against SQL Server (MySQL seems to have problems with Emojis), I'm not sure how to filter out security risks without losing that property.

No, it's not necessary. But please, read on.

Input sanitization is a horrible term that pretends you can wave a magic wand at data and make it "safe data". The problem is that the definition of "safe" changes when the data is interpreted by different pieces of software.

Data that may be safe to be embedded in an SQL query may not be safe for embedding in HTML. Or JSON. Or shell commands. Or CSV. And stripping (or outright rejecting) values so that they are safe for embedding in all those contexts (and many others) is too restrictive.

So what should we do? Make sure the data is never in a position to do harm.

The best way to achieve this is to avoid interpretation of the data in the first place. Parametrized SQL queries is an excellent example of this; the parameters are never interpreted as SQL, they're simply put in the database as, well, data.

For many other situations, the data still needs to be embedded in other formats, say, HTML. In that case, the data should be escaped for that particular language at the moment it's embedded. So, to prevent XSS, data is HTML-escaped at view time. Not at input time. The same applies to other embedding situations.

So, should we just pass anything we get straight to the database?

Maybe. It depends.

There are definitely things you can check about user input, but this is highly context-dependent. Because sanitization is ill-defined and mis-used, I prefer to call this validation.

For example, if some field is an supposed to be an integer, you can certainly validate this field to ensure it contains an integer (or maybe NULL).
You can certainly do some validation on email fields (although some people argue there's not much you can do besides checking for the presence of a @, and they have a good point).
You can require comments to have a minimum and maximum length.
You should probably verify that any string contains only valid characters for its encoding (e.g., no invalid UTF-8 sequences).
You could restrict a username to certain characters, if that makes sense for your userbase.
A minimum length for passwords is, of course, incredibly common.

As you can see, these checks are very context-dependent. And all of them are to help increase the odds you end up with data that makes sense. They are not to protect your application from malicious input (SQL injection, XSS, command injection, etc), because this is not the place to do that.

Users should be free to type '; DROP TABLE users; -- without their post being rejected or mangled to \'; DROP TABLE users; --. Note that I'm able to include such "malicious" content on sec.SE!

So, to answer your original question:

  ... is it still necessary and/or security-relevant to somehow sanitize input?

No, it is not. But please do properly escape the data where needed before outputting it. And consider validations, where applicable.

  I think of benign, but not-so-well-engineered 3rd party tools (maybe self-written scripts by the admin, or some fancy CrystalReports made by a non-technician) trying to consume unsanitized data from our database.

Then escape or filter the data before outputting to those tools, but don't mangle data in your database.

But really, those scripts should be fixed, or rewritten with security in mind.

  (MySQL seems to have problems with Emojis)

Little off-topic, but have a look at the utfmb4 charset for MySQL ;)


Is SESAME really used in Europe? I am looking at a text that mentions that the Secure European System for Applications in a Multi-vendor Environment (SESAME) was designed to address some of Kerberos weakness, with enhancements such as:

Use of asymmetric cryptography
Distributed authentication
Role based authorisation

I work mostly in the U.S. and Canada, but I also worked in Germany and Romania. I have used or implemented Kerberos everywhere but never heard of SESAME except in some textbooks.

Is SESAME for real? All I find is un-dated wishful thinking with dead links. Is there any security analysis of it or a reference implementation ?

It is difficult to determine what the authoritative source is for SESAME, which is an indication. The best link, which I'm sure you have seen, is from COSIC.

The first paragraph states:

  SESAME (a Secure European System for Applications in a Multi-vendor
  Environment) is a European research and development project, ...

All information and links for SESAME are all pre-2000. There also doesn't seem to be an IETF RFC filed for SESAME, except this draft from 1996.

SESAME is not used, but was an idea that was superseded by improvements to Kerberos RFC 1510.


Keepass 2.0 file attachment security I recently found the ability of attaching files to entries in KeePass 2.0: does KeePass just remember the location of files attached to the entry or does it encrypt the attached files inside the KeePass database somehow?

From the KeePass documentation:

  File attachments are stored encrypted in the database (like all other database content).


Could it be possible to hijack physical finger prints in digital form and use them to gain access to other devices and locations? With more and more devices accepting finger prints in place of passwords, could it be possible to "keylog" these finger prints on mobile devices, for example, by installing a rogue application and then reproducing that finger print either digitally or physically in terms of 3D printing to gain access to other devices or locations?

One thing I was thinking too is what if someone develops an app(legit) and asks to use your finger print. From there they could technically reconstruct it and use it against you or even sell it and associate it to your identity.

Here's a relevant section of Apple's "iOS Security" document:

  The fingerprint sensor is active only when the capacitive steel ring
  that surrounds the Home button detects the touch of a finger, which
  triggers the advanced imaging array to scan the finger and send the
  scan to the Secure Enclave.

  The raster scan is temporarily stored in encrypted memory within the
  Secure Enclave while being vectorized for analysis, and then it’s
  discarded. The analysis utilizes subdermal ridge flow angle mapping, which is a lossy process that discards minutia data that would be required to reconstruct the user’s actual fingerprint. The resulting map of nodes is stored without any identity information in an encrypted format that can only be read by the Secure Enclave, and is never sent to Apple or backed up to iCloud or iTunes.

To me this implies that the fingerprint never actually passes through the standard iOS memory, but rather directly to the secure enclave. Once it's in the secure enclave, it's transformed in a way that the fingerprint cannot be reconstructed. So on Apple devices, this does not seem to be possible even on jailbroken devices, except maybe in the case of an attack on the physical hardware.

Other devices such as Android are different. I believe Google has design guidelines similar to Apple's but manufacturers do not need to follow it exactly. I'm fairly sure that some early Android devices simply encrypted finger print data in the standard storage, but I'll look for a reference as I could be wrong.

Edit:

https://www.extremetech.com/mobile/211985-htc-caught-storing-fingerprint-data-in-unencrypted-plain-text
https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf


How important it is to change password regularly? A WWW-site guided me to change the password regularly. Should I believe what the say, if my current password is long enough random string?

Regular password changes are notionally a good idea because they guarantee someone can’t acquire your password and use it to snoop on you over an extended period of time. However, regularly changing your password won’t help much .

If an attacker gains access to your accounts, they’ll most likely use their access to cause damage right away. If they gain access to your online banking account, they’ll log in and attempt to transfer money out rather than sit and wait. If they gain access to an online shopping account, they’ll log in and attempt to order products with your saved credit card information. If they gain access to your email, they’ll likely use it for spam and phishing, or attempt to reset passwords on other sites with it. if they gain access to your Facebook account, they’ll probably attempt to spam or defraud your friends immediately.

Typical attackers won’t hold onto your passwords for an extended period of time and snoop on you. That’s not profitable — and attackers are just after profit. You’ll notice if someone gains access to your accounts.

Password changes in response to specific events are a good thing, of course. It’s a good idea to change your passwords on websites that were vulnerable to Heartbleed but have now patched it. Changing your password after a website has its passwords database stolen is also a good idea.

http://www.howtogeek.com/187645/htg-explains-should-you-regularly-change-your-passwords/


Backdooring PE binary compiled with ASLR I'm practicing backdooring PE binary compiled with ASLR in a WOW64 environment. The approach is pretty straightforward and basically is something like this:

Find code cave and a hijacking point. In this case, I choose not to patch the entry point but the shellcode will be trigged on user interaction.
After the hijacking point is reached, I found a useful way to jump to my code cave.
Once I'm inside my code cave, like standard approaches, I save my flags and registers with PUSHAD and PUSHFD instructions.
Execute successfully the shellcode: my reverse shell is connected and working flawlessy.
After that, I need to come back to the original flow, reconstructing the flags, registers and patched instructions.

In a no-ASLR environment, I can hardcode the original address back inside the ESP and executing standard POPFD, POPAD instructions. But now, how can I come back to the original ESP value? Also, I noticed that somehow the ESP address changes also in the offset and not only in the base address. Maybe it depends on some user interactions...

If I understand your question, you’re missing something very fundamental about how functions must behave.

Push operations don’t “save” values per se, they store values to the stack and then decrement the stack pointer. This means that the stack pointer must be at the same value (excluding the size of the data that was pushed) in order to restore” values by popping them. Everything is in band and depends on the integrity of the stack pointer.

When your function returns to the caller, the ESP/RSP value MUST be the same as when it was called when your payload finishes. This is how a “normal” compiled function works and it is required behavior for a program to work correctly. Otherwise ret instructions would be meaningless since they depend on the stack pointer being set to to the same place that the call instruction pushed the return address

If you allocate 64 bytes of stack space in your function, for example, you should increment the stack pointer back up 64 bytes when your function is complete. Don’t forget that both ret and call will modify the stack pointer slightly as well.

To troubleshoot your code, breakpoint at the beginning and end of your payload and verify you have properly restored the stack to its original value at the end, usually via a sub instruction or by using an immediate value with the ret instruction. In my opinion using sub is clearer.

tl;dr; When writing assembly code, think of the stack as the heap and be conscious of “freeing” any allocated stack space when you are done with it or at the end of the function. Keep the stack pointer in sync like properly compiled code would.


What is sent between an HSM and an application? When an application calls an HSM using PKCS#11/KSP/etc. what is actually exchanged between the two? For example, if a CA needs to sign a CRL, is the entire CRL actually sent to the HSM for signing?

Signing a CRL is like signing any other data and involves several steps:

Read the data you want to sign.
Compute a hash from the data you want to sign. This hash has the same length no matter initial data length and different data will result in different hash.
Encrypt the hash with the private key. The result of this operation is the actual signature.

This signature can then be appended to the signed data (added to the CRL to get the final, signed certificate to follow your example) to obtain the signed data.

As you see, the private key is only involved in the last step. It would be a waste of resources to send the whole data to the HSM, so the hash is calculated on the application side and only the hash is sent to the HSM to obtain the signature.


How can companies verify that a national security letter is real? It looks like that US national security letters are a prefect way of social engineering: they request confidential data from you and includes a gag order forcing you no to tell anyone about it.

There are countless of picture examples on the internet which can be used write forged one and submit it to an unsuspecting victims.

How can a company who gets one verify it really came from the government and not some criminal pretending to be the government? Given the fact they cannot tell anyone about it.

This doesn't contain an answer about how to verify that it's legit but this does answer other questions you probably have about it

EFF - NSL Letters

I would think that the portion containing the gag, to not tell anyone about it, doesn't include barring you from contacting the agency that issued the NSL to you, for further details.  For example, if it came from the FBI, you may be able to contact the FBI for further information about it.


Is it dangerous to serve user-uploaded Flash (SWF) files? I'm working on a site that has CMS functionality. I'm considering allowing users to upload Flash (.swf) files and then displaying them on my site.

Is this a bad idea?
Is there a way to do this safely?
What are the worst things that can happen, both to my servers and to visitors of my site?
What precautions can I take to mitigate these issues?

Older versions of flash .swf's contain vulnerabiltiies. A user could upload a clip created with an older version of Flash CS and thus expose hundreds of end users. If they don't have the latest flash player (and many don't), they could catch a nasty bug.

The .swf could be triggered to launch a cross-site injection that deploys an IFRAME within the user's browser window. Then it's game over. This blog post explains how it happens.
http://blog.sucuri.net/2014/11/malicious-injector-in-swf-adobe-flash-file.html

Yup. The actionscript contained within the .swf could launch a javascript housed on another website and cause someone to get a virus just by visiting yours.

None of the AV's in 2014 detected the badware. As a former Flash developer, I have since moved to Canvas HTML5/ jQuery as it works in mobile. See this example. It is fully compliant http://careerbuildermedia.com/atx/projects/portillos/pjb/code6/

In older browsers such as IE8 it fallsback to the equivalent flash player. The expertise to do this is high, but if you really want to support swf uploads you need a moderating process to remove the ones that aren't up to spec.


Securing a network attached storage on the internet I recently purchased a network attached storage for personal file storage and would like my family members to store files on the device from their computers as a remote backup.

I'd like to secure the port that's used to sync files so that only their computers will have access. The solution should be easy for them to implement and use on a daily basis. I believe that backing up files should be easy, seamless, and automatic. Most of these files are media (pictures, home movies, etc). Backing up files to an alternative cloud based system is not an option.

My problem is that each of these computers have dynamic IP addresses so it's not as simple as setting up the firewall to only allow from a handful of IP addresses. They don't change very often, but they do change.

I'm running a DDWRT-based (standard) router connected to the NAS so I can add custom firewall rules if needed or run a script. For the sake of this question, the port that the service is running on is TCP 5678. What's the best solution to secure access to the NAS?

Possible solutions:

Setup a VPN (not very convenient for users)
Setup firewall rules based on the entire network of the clients ISP
Setup firewall rules and update the IP address using a dynamic DNS service and a script that runs periodically

I've created a simple diagram to show my setup.

The answers will be protocol/application dependent. Basically, if you can use a secure tunnel or a VPN solution, you will have pretty good security. Someone might be able to knock on the port, but they won't be able to connect without credentials (and certificates if you can).

You could try to setup a simple VPN using something like Hamachi, TeamViewer, or OpenVPN. Once this is setup for your family with the certs and passwords, you could allow them to use any existing protocols or to access a network share (though for performance reasons I would not recommend just using a network share over Internet/WAN).

One solution that makes this relatively easy is to use any of a number of software which allow you to mount a drive locally via SFTP. They have free and commercial solutions for various operating systems (e.g., SFTP Net Drive, OSX Options, google for others). If you just want them to be able to drop file, this is a good lightweight solution because you can just make it another drive on their network and since its SFTP there is less overhead then other solutions. The caveat of course is that they either need to type a password each time they load the file or you need to store it on their system, but that is likely a concern with anything user friendly. You could also script something.

If you have passwords and certificates at your VPN level and let your firewall manage your VPN that would minimize exposure, but may be unnecesary (just because people scan my SSH sever, they don't get on because they don't have a cert + credentials).

For a pure automated backup, I would look at some of the free P2P features of CrashPlan. Other backup tools usually have an SFTP connection option as well, where you can do a traditional periodic file backup with incrementals, differentials, deltas, etc.


Does EMET prevent WannaCry exploit execution? Based on answers to the question How is the “WannaCry” Malware spreading (...), I understand it leverages vulnerabilities present in the SMB implementation. Assuming an unpatched and otherwise vulnerable system, would EMET (properly set-up to enforce DEP, SEHOP, ASLR and certificate pinning, in addition to importing the "Recommended Software" and "Popular software" mitigation lists) prevent this exploitation?

No, EMET won't prevent exploitation.

WannaCry uses the ETERNALBLUE exploit, targeting the MS17-010 vulnerability. This vulnerability exploits the Windows File Sharing Service (a.k.a SMB) on TCP port 445. This Windows File Sharing Service runs with SYSTEM level privileges, under the SYSTEM process - basically at the kernel level.

On the other hand EMET is a user-space protection tool to protect user-space processes like browsers, browser plugins or Office applications. EMET is injecting a DLL into every protected application, and provides protection through that DLL. By default, EMET provides almost no protection to the system (except enforced DEP, enforced ASLR, SEHOP). It only protects applications (Executable files) which have been configured to be protected by EMET.

A logical step would be to configure EMET to protect the SYSTEM process, but unfortunately this is not how operating systems work. Different memory protection strategies and implementations are needed to protect user-space processes and the OS kernel.


Are retail POSs still storing credit card info? A couple of years ago my bank sent me a new debit card and deactivated my old one unexpectedly. I suspect this was because of the Home Depot hack in which the details of some 56 million credit cards were stolen because they were being stored for no apparently good reason on Home Depot's POS system. The problem was greatly magnified because Home Depot was not just using the card information to execute transactions. It was actually storing the customers' card details permanently without their knowledge or consent.

Has this event resulted in retailers changing their policies and not secretely saving copies of their customer's card information, or are retailers still engaging in this conduct? Are card issuers like Mastercard doing anything about this, such as making it part of their merchant contract that the merchant does not keep secret copies of customer cards?

In the general vein of- is security around retail credit card processing improving- the answer is yes, in fits and starts.

The main driver has been the shift towards tokenization, whose most visible champion is ApplePay, but improvement is also manifest in the presence of machines at retailers which rather than accepting a swipe of the magnetic strip hold the credit card to construct a credential using the card's chip that is only valid for that individual transaction.

The card brands- Visa and Mastercard- have been aggressive in using their compliance regime- PCI- to require improvements from retailers. Most recently, in October 2015, there was to be a shift in rules with the goal of increasing risk of fraud liability for retailers who did not move to chip-based payments. This shift has not resulted in wholesale adoption of chip-based payments, but these are framed as exceptional cases, and compliance will increase over the next few years.

PCI regulations have always distinguished between "data at rest" and "data in transit" and the compliance standards for merchants who keep data at rest have always been significantly higher. Fines and other penalties for merchants whose PCI compliance submissions- called Reports on Compliance- are found through a breach or through an audit to dramatically depart from reality are very steep.

Now, are dumb practices still in place around the retail industry? Of course they are, and there is significant inertia as retailers continue to be under enormous pressure from Amazon. Their incentives are not to add friction to the customer payment process, or to increase their own costs with wholesale adoption of new technology.


OpenSSH downgrade attack I have tried to implement a downgrade attack against the SSH protocol as the first steps (encryption protocols exchange) are not signed, as per RFC4253.
The idea is to intercept (mitm) these steps and replace strong algorithms by weaker algorithms supported by both sides.

The replacement is working well, and server and client receive a weakened list of supported algorithms.
However, the communication is directly interrupted when the server receive the client's list.

I have expected some protection against downgrade attack to be implemented by the protocol, but I don't see nowhere in RFC (or log files) how.
SSL proceeds for instance by resending the first steps encrypted, to let the other side discover what the first steps were, and avoid this way any downgrade attack. But there is no re-send of anything tcpdump says.

What mechanisms prevent downgrade attacks on SSH?

Many thanks, and don't hesitate to ask for implementation details.

There is downgrade protection in the SSH protocol. The server and the client perform the DH/ECDH key exchange and calculate the shared secret. This shared secret, along with the server and client version strings and algorithm lists are hashed to produce a symmetric key.

If you change the supported algorithms, the server and the client will calculate different symmetric keys, unless you have a preimage attack on the hash function which also works if some of the input is secret.


How Google has an SSL certificate from itself and my browser doesn't give an error I know that I can create my own SSL certificate, but in this case the browser will give 'not trusted' error to the user, as the certificate is not browser trustworthy. So companies go and get an SSL certificate from a third party. But checking the ssh certificate of google, I realized they have certificate from Google Inc.; and my browser does not give an error for it. How is it possible? Did they created a sub company to issue themselves their own SSL certificates?

Google has its own intermediate CA. They have a webpage here https://pki.google.com/


Could you add SSL to a stripped stream? I have been thinking about an attack for SSL that would allow a third party to log all transmitted data. My idea is that you modify the client to connect to the server without SSL enabled and modify the DNS to return the attacker's computer. I was wondering if the attacker could then encrypt the data using the same parameters as the original client, making the server unaware that the connection had been tampered with. Please note, in this scenario the client would not be able to log the days itself.

TL;DR Could I strip SSL then add it later without a server knowing?

Normal:
Client <-ssl-> Server

Idea:
Client <-plain-> Attacker <-ssl-> Server

Unless mutual or 2-way authentication is being used, the server cannot confirm whether the client or an intermediary is its counterpart in the SSL communication. So your proposed attack scenario will succeed.

That said, modifying the code of a client in the fashion you suggest likely requires the attacker to have full access permissions to the client. At which point the attacker can copy the disk, install key loggers, etc... Basically, it is game over.