How to remove quarantined virus securely?

Although a lot depends on the anti-virus software, I'll try to answer your questions:

  1) What is the best practice and secure way to deal with them? Delete from quarantine, or let them in there?

Do you plan to study the virus and its working? If yes, then you might want to keep it (This will require a restore of the file).
Do you think it might be a false positive? If yes, report it to your anti-virus vendor for a re-evaluation, and if it turns out to be a false positive, you can restore the file(s).
If you don't plan to do anything with the file (and don't want to restore it either), you can delete it.

  2) If i delete a file from the quarantine, does it mean that it goes to the "recycle bin" of the computer and is thus still existent on my PC, and could be recovered by some tools like Recuva? Or will it be gone for ever

This largely depends on the implementation of the anti-virus. No reputable vendor would send the file to recycle bin.
Can they be recovered? Potentially yes. Even if the anti-virus program performs several iterations of deletion on that part of disk, the file could be potentially recovered using specialised techniques and tools.

  3) What happens if there are files in the quarantine and you accidentally de-install the antivirus program from your PC, what happens to the files?

It should not affect your system, as the files are stored in a binary format. More details can be found here.

EDIT:
As user user21820 points out in the comments, there's nothing to worry about if the file in the quarantine is deleted using multiple overwrites.


Extra features required for TrustZone to provide main security features

Strictly speaking, you can't do anything with TrustZone itself. TrustZone itself is an isolation feature of the CPU core. It adds another level to isolation between processes: in addition to user/kernel or user/kernel/hypervisor, there's normal-user, normal-kernel, normal-hypervisor, secure-user and secure-kernel. But since normal-kernel mode (or normal-hypervisor mode if the hypervisor is in use) can access the whole RAM, there's no place to put code and data out of reach of the normal world. To do something useful with TrustZone, you need not only a core with TZ (which is the case of all Cortex-A CPUs) but also a TrustZone-aware memory controller on the CPU (which some manufacturers omit). A TZ-aware memory controller can firewall memory regions to block a region from being accessed when the CPU is in normal mode. In addition, the DMA controller should also be TrustZone-aware, otherwise the normal world may be able to circumvent memory protections by leveraging a peripheral (e.g. set up DMA between memory used by the secure world and the flash controller, then read the content back from flash).

If your CPU includes a TZ-aware memory controller, it supports isolated execution. However, this alone is of limited use because without other features, the isolated execution environment only runs whatever code was there when the isolation was set up, and can't keep anything past a reboot.

Secure boot, where each stage of the boot process verifies the signature of the next stage before allowing it to run in the secure world, allows whoever controls the ROM to control what runs in the secure world. All Cortex-A processors boot from ROM (as in, actual read-only memory, not flash or EEPROM).

This is still of limited use because you have a secure environment… to do what? If the only privilege that the secure environment has is access to a particular region in RAM, that doesn't do anything useful.

CPUs that leverage TrustZone additionally have a secret key that's accessible only to the secure world. See Does the ARM TrustZone technology support sealing a private key under a code hash? and Secure keys in hardware. With secure boot (for code integrity) plus isolated execution plus one bootstrapping privilege (access to a secret key), the software running in the secure world can implement features such as remote attestation and a limited form of secure storage.

The secure world can store data persistently by encrypting and authenticating data and letting the normal world take care of storing the encrypted blobs. This guarantees the confidentiality and authenticity of the data, but not its integrity. The normal world can still delete data, and can roll it back. To prevent rollback, the secure world needs at least a small amount of rollback-protected storage. In practice, on mobile devices, this is done with the cooperation of the flash controller. The flash controller dedicates a partition to the secure world, known as replay-protected memory block (RPMB), and uses the RPMB protocol to communicate with the secure world on the main CPU, using a shared key that is established when the device is manufactured. Secure storage doesn't need to involve the device user at all: the secure world already has a secret key, it doesn't need to derive one from a password, which would be weaker (typical passwords, even with strengthening applied, are weaker than a run-of-the-mill 128-bit secret key).

“Trusted path” in this context refers to an isolated channel between the CPU and a peripheral. A trusted path needs support inside the CPU, not only TrustZone, but also a peripheral that can be put in a secure mode where it only obeys the secure world, and the bus(es) in between need to isolate the communication. The most deployed kind of trusted path on mobile devices is with the display subsystem, to apply DRM to video rendering. Providing a trusted path for user input and display is technically difficult and not widely deployed.

Remote attestation is not needed for secure provisioning: a server can send data encrypted with a key that only a specific device can decrypt, it doesn't need to receive an attestation from the device. It might want to receive an attestation, either because that's how it discovers the device's public key or because it wants additional content in the attestation (e.g. knowing what software versions it's running).

The big thing you left out is: who controls all of these features? Ultimate control belongs to whoever decides who signs the code that the ROM is willing to load, and that's usually the chi manufacturer, and they allow only code from the device manufacturer. On mobile phones and tablets, the end-user typically has no access to the secure world.


Cross-platform browser link highjacking/redirect issue in Chrome

Well, your symptoms tell me that this should be a sort of adware program. I mean all these hijacked links and ending up on these random websites are certainly signs of an adware-like infection. It is one thing that Malwarebytes didn't find anything related to this. I wouldn't give up there. I would scan my system with Adwcleaner or any other free or trial version of reputable antimalware software you can trust. On top of all this, I would also reset my browser(s) on a just in case basis. I hope this makes sense and helps solve your issue.


It seems like you are really looking for the tool netdiscover.

Netdiscover works by sending and listening for ARP packets. (active and passive mode). Since it is ARP, its limitation is that it only work on the same LAN (layer 2) - you cannot traverse gateway's.

You do not have to change the ip address on your interface with this tool.


Why does IV not need to be secret in AES CBC encryption?

I think it's easier to split this into its component parts, and consider them as separate entities: AES and CBC.

AES itself does not "basically consist of XORing together chunks of the block" - it's a much more complicated affair. Ignoring the internals of it for a moment, AES is considered secure in that without knowing the key, it's practically impossible to recover the plaintext or any information about the plaintext given only an encrypted block, or even in situations where you're given parts of the plaintext and you need to find the remainder. Without the key, AES might as well be a one-way function (and there are MAC schemes which rely upon this!). Discussing the technicalities around the security of AES and similar block ciphers is extremely involved and not something I can cover in an answer, but suffice to say that thousands of cryptographers have been looking at it for almost two decades and nobody has found anything remotely practical in terms of an attack.

The diagram you posted above describes CBC. Block ciphers, such as AES, aim to be secure for encrypting one block with a secret key. The problem is that we rarely want to just encrypt one block, but rather a data stream of indeterminate length. This is where block modes, like CBC, come into play.

Block modes aim to make ciphers secure for encrypting multiple blocks with the same key. The most simple block mode is ECB, which offers zero security in this regard. ECB involves independently encrypting each block with the same key, without any data fed between blocks. This leaks information in two ways: first, if you have two identical plaintext blocks, you'll get two identical ciphertext blocks if you use the same key; second, you'll get two identical ciphertext streams for two encryptions of the same message with the same key. This is a problem as it leaks information about the plaintext.

CBC solves this problem by introducing a "cascading" effect. Each plaintext block is xor'ed with the previous ciphertext block, resulting in originally equal plaintext blocks no longer being equal at the encryption step, thus no longer producing equal ciphertext blocks. For the first plaintext block, there is no previous ciphertext block (you haven't encrypted anything yet), and this is where the IV comes in. Consider, for a moment, what would happen if instead of an IV we just used zeroes for the -1th block (i..e the imaginary ciphertext block "before" the first plaintext block). While the cascade effect would make equal plaintext blocks produce different ciphertext blocks, the same entire message would cascade the same way each time, resulting in an identical ciphertext when the same full message is encrypted multiple times with the same key. The IV solves this. By picking a unique IV, no two ciphertexts are ever the same, regardless of whether the plaintext message being encrypted is the same or different each time.

This should, hopefully, help you understand why the IV doesn't need to be secret. Knowing the IV doesn't get an attacker anywhere, because the IV is only there to ensure non-equality of ciphertexts. The secret key is what protects the actual data.

To emphasise this even further, you don't even need the IV to decrypt all but the very first block. The decryption process for CBC works in reverse: decrypt a block using the secret key, then xor the result with the previous ciphertext block. For all but the very first block, you know the previous ciphertext block (you've got the ciphertext) so decryption is just a case of knowing the key. The only case where you need the IV for decryption is the very first encrypted block, where the previous ciphertext block is imaginary and replaced with the IV.


Is there a way to create separate environments on your computer with no way of detection?

Depends how much scrutiny you want to defend against. It would theoretically be possible to use full disk encryption with multiple partitions, decrypting each based on a distinct password. This falls apart if a user looks at the disk manager application in Windows though - they'd see partitions they couldn't use (but which they could reformat and take over the space of). It would also fail if they opened the computer, looked at the drive, and started wondering why they couldn't use all that space.

At a Windows level, there are various ways to determine whether there are other users, so you'd be able to see their presence, even if you can't access their data. These vary from names showing in quick access login screens, to being able to see the contents of the c:\Users folder or the security permissions screens.


Any way to auto execute a file in windows

That would be a very large security hole, so no, generally speaking, there isn't any way to do that. There have been security bugs in the past that permitted things like this in specific scenarios (such as downloading a file that executes when viewed in Windows Explorer), but they were patched. There are ways to do this if you have arbitrary control over where the file downloads to (in fact, that's relatively easy; just drop it in the user's "Startup" folder in their Start Menu or modify some shortcut that the user runs regularly), or can otherwise make certain changes to the file system, but just dropping a file in a temp directory won't do it.

There are ways for an Office document to ask the user for permission to do unsafe things, and those unsafe things can include running programs. However, these requests will cause somewhat-scary-looking warning dialogs that users much approve the risk of before the attacker's code will run.

Also, there's usually no need to drop a file on the user's system, if you have some way to execute an arbitrary program. Run the program over the network or (if you can use command-line parameters) just have CMD or Powershell execute a script that you stuffed into the command line.


It depends on the file you're trying to match. By default dotdotpwn does not require string matching (-k). It is required if you specify a specific file to look for or you are experiencing false positives. As a general rule I tend to look for c:\windows\win.ini as this file is present on all versions of windows unlike c:\boot.ini. By examining a known good win.ini file you can look for a keyword you like, otherwise -k 'mci extensions' should do the trick.

You didn't give an example of the commands you wrote so I'll just guess that you didn't correctly quote or escape the [, ] or space characters. Dotdotpwn will match on the word boot, without the brackets, but a more accurate match reduces the likelihood of false positives.


the dangers of internet forums - what is FUD, what is not

I think you can safely live normally ;)

The user in this forum propably just took a guess on your UserAgent. This is neither considered hacking nor does it do any damage on your pc. There is even a Website telling you what OS you use, only by visiting it. There are also more informations about how this is working.


Can malware physically damage a hard drive?

You can definitely brick a HDD or SSD by flashing it with incorrect or corrupt firmware.  Most drives will accept firmware updates while in use.

Of course a sufficiently determined person can probably repair the damage, but in most cases this would be written off as a drive failure and the drive replaced.


Can advertisements read cookies of the website it is on?

Any script included into a page can read all cookies for which the httpOnly attribute is not set. Access restrictions for scripts are not determined based on the domain the script was loaded from but only in which page it is loaded into. This means all scripts loaded into a page have the same access and control over this page, no matter what the origin of the script was. Regarding cookies this means that you need to protect any sensitive cookies like session ids with httpOnly if you have included third party scripts which are outside of your control and trust into your page.

But including such scripts into a page working with sensitive data is a bad idea anyway, since such scripts can not only read cookies (unless httpOnly) but also extract information from forms (like login credentials) or change the client side application logic. See also Should I be worried of tracking domains on a banking website?.

Note that these statements apply only to third party script which is directly included into the main page. If the script is instead only inside a third party iframe inside the main page it can neither read cookies on the main page nor access or modify the DOM on it.


JWT with SSL still need HMAC or RSA signature or I am just paranoid?

"Signing" JWT's is not a defence against Man-In-The-Middle attacks. As you say, using HTTPS so that TLS/SSL employed is.

Adding an HMAC to a JWT prevents the current user of the session from tampering with the claims.

Take this one:

{
  "admin": false
}

A malicious user may be able to escalate their privileges:

{
  "admin": true
}

Ensure that you have a strong private key and a HMAC authenticated token is enough. Ensure that every JWT checks the HMAC authentication.

RSA is only really useful if you need to send a token to another party or server and you wish to solve the key distribution problem.


There is nothing to worry about. Tons of web-crawlers are bombarding our websites with requests like that. Probably they are trying to figure out if someone uploaded web-shells (and renamed them as judge112233.php, ip.php, etc.) to your server.

Just make sure that your server hasn't got these files.


How to secure/cleanup my accounts after having an old email account breached

General rule of thumb when this happens (and it's a pain): You have to go through the old account, figure out what other online services are linked to it, and then update your login info on all of them.

Linked online services being defined as:

Services registered to the compromised account
Services for which you have recorded login or recovery info on that account.

If you used the old account as a recovery address for your new account, delist the old account immediately and constantly monitor your new account for reset requests.

Additionally, any personal or otherwise sensitive data you had stored in the account should be considered compromised. If you stored your personal identifying info on that account, you might consider registering for an identity protection service. If you have credit/banking card numbers and/or PINs contained anywhere on the account, cancel all affected cards and ask for new PINs where applicable.

A good way to do recovery email addresses is to have a single account on a trusted/reputable online email service with extremely strong login info (and preferably one that doesn't deactivate your account due to lack of use). Store the login info encrypted on 2 personal computers that never leave your house and preferably no one else has access to.
Use this account solely for recovery; NEVER use it to register for online services as this will expose the email address. Harder to get hacked if no one else knows about the hidden recovery address.

Why this works:
First, make some generous and slightly unrealistic assumptions - the user never gets keyloggers or similar malware and the email service never gets compromised. The recovery email is never typed in on any other website so hackers have no way of knowing it exists. The only way they can gain access: grabbing the computer with the login info and decrypting it. This means they would need to find the geographic location of your house, climb in through a window or unlock a door, figure out which computers have the encrypted info, and then hack the encryption. That's an extremely tall order for anything short of a government-sponsored hack or an "inside job" (where a roommate or family member somehow records the decryption key and takes the recovery account).


How to perform safe authentication via HTTP?

Ordinary HTTP of all sorts is unencrypted.  If you want to protect your data, it has to be sent over HTTPS.


why Common Criteria evaluation wont give 100% security

First, there is no such thing as 100% security in the first place. There are only ways one can try to achieve the best security for a specific cost and then one needs to be able to handle the remaining risk (or ignore it if it is too unlikely).

Apart from that certifications like Common Criteria only cover a specific part of the system, i.e. the target of evaluation. For example with the recent ROCA vulnerability in smartcard chips the product had a very high certification (EAL7) but the specific part of how prime numbers were selected during key generation was not evaluated.

And then, software is complex. And the more complex it is, the harder (i.e. impossible) it is to completely describe what it should do and to create tests which cover every detail and variation and combination of this functionality. And then the auditors need also be able and have the time to understand everything, check everything and not make errors or wrong assumptions themselves.
For example at EAL7 (Evaluation Assurance Level 7) formal verification is required which is practically impossible to do with complex systems like firewalls (where you currently get at most EAL4+). And even the first EAL4 evaluation of a product often takes years to complete, in which time usually new features were added to the product already and bugs were fixed - which are not covered by the evaluation but which are needed by the customers.

  ... if system has passed a CC evaluation ie. EAL4, what can we say about the security of this system?

Certification is a best effort but not perfect. It is still way better then no certification and higher assurance levels are better than lower ones since more efforts were done to validate design, functionality, development process etc, i.e. more potential problems are covered.
So, higher level means more assurance and less bugs. But not necessarily in the whole product but only in the part which got evaluated. Thus you need to get the actual evaluation report to find out what is covered by the evaluation and which parts in which depth.


Security of viewing a website containing Java applets offline

As I understand it, an untrusted Java applet run in the browser is going to be sandboxed, so I don't believe it will have any more access to your system if you download it and run it in your browser locally than if you run it from the originating server, or from your browser cache, at least by design.

However, you should be concerned about Java applets, period.   The number of vulnerabilities discovered in the JRE in the last few years is absolutely staggering.  It's highly inadvisable to allow Java to run in the browser, so I would suggest that you don't want to run untrusted applets under any conditions.


REMME: Does the blockchain offer a real advantage here?

Note that this is not a scientific review of what they do.

From the technical side they are essentially doing certificate based authentication (i.e. similar to client certificates in the browser) only that the certificate and revocation information are stored in a public Blockchain (actually they use Bitcoin in the current version) and that they thus try to avoid having a central CA. This idea is not that bad by itself and is actually not that new either.

But there are some signs on the companies site which look suspicious too me:

Their website is full of claims like "unbreakable", "eliminating the human factor from the authentication process", "perfect". I'm very cautious when someone has such claims when talking about security.
The "As Seen on..." sounds more like TV advertisement but not like a serious security product.
Their white paper makes interesting claims like "Various parties (including Google) have tried to solve those issues, but without
success[2]" -  where [2] is simply a link to the web site of the certificate transparency project without any explanation on why this project does not solve the issues. But of course it sounds awesome to claim that they've solved a problem Google could not solve.
As can be seen from their white paper the way they work was changed multiple times within the short time they exist - which does not provide much trust in that they already know what they do. And in fact several more changes are already planned.
And many more. For example their white paper is also a mix of tiny details for specific technical parts one one side and then planning of the companies future (Q1/2018: public sales phase, Q3/2018: sales office in London ...) on the other side, which is just strange for my understanding what a white paper should be. Interestingly they refer in the white paper itself to version 1.0 of the paper released in Q3 and version 2.0 in Q4 2017 - only that the white paper itself says clearly version 0.2, a version number which probably more matches its immature state.

Based on this I would argue that this is more an attempt to make money from the current hype to Blockchain, Bitcoin etc than a product I would trust.


Single sign on - is this a secure way to log in?

You simply state "site 2 checks if the page that is redirected from is really site 1"... how?  There isn't a good way to do this without further information that site 1 can use to verify it's identity via a challenge from Site 2.

This also seems overly complex for passing an authentication.  All that really needs to be done, as long as Site 1 and Site 2 both communicate with each other and know each other, is for them to agree between themselves on a token and redirect the user with that token so that one site knows it is the same user that was on the other site.

Don't roll your own, use OAuth or something similar, it will allow better integration with more sites and is also a well supported and tested standard.


Are Https-only cookies vulnerable to CSRF attacks?

Yes, CSRF is still possible, and it works the same as CSRF would normally work.

The HTTP-only flag is useful for protected a cookie from an XSS attack which injects JavaScript to try to read the cookie and send it back to the attacker. For protecting against CSRF attacks, it is completely useless.


X.509 Why is the signature algorithm added twice in the Attribute Certificate?

This is a remnant of some old fears. Peter Gutmann's X.509 Style Guide, an old (2001) but instructive read, includes the following paragraph:

  This rather misnamed field contains the algorithm identifier for the signature
  algorithm used by the CA to sign the certificate.  There doesn't seem to be
  much use for this field, although you should check that the algorithm
  identifier matches the one of the signature on the cert (if someone can forge
  the signature on the cert then they can also change the inner algorithm
  identifier, it's possible that this was included because of some obscure attack
  where someone who could convince (broken) signature algorithm A to produce the
  same signature value as (secure) algorithm B could change the outer,
  unprotected algorithm identifier from B to A, but couldn't change the inner
  identifier without invalidating the signature.  What this would achieve is
  unclear).

So one might infer that, one day, probably around a coffee machine during a pause between two meetings, somebody made an elaborate but not really funny crypto-joke, and it was overheard by somebody else, who did not get it, and proceeded to stir up feelings of anxiety somewhere in the dark corner of a sub-committee. More generally, X.509 makes a lot more sense if you read it as Mary Shelley's draft notes for "Frankenstein", translated for some reason into ancient Ugaritic.


Are FaceID/passcode logins secure over public WiFi/hotspots?

To know whether each individual app is secure in that scenario cannot be answered without thoroughly auditing each app. But assuming they are securely using TLS for all communications, any type of local biometric authentication probably doesn't have anything to do with what traffic is sent to the server.
The application is probably already logged in to the server, possibly already sending data and synchronizing your accounts in the background, and only requests biometric authentication from the OS to check if an authorized user is holding the device. So in that light, if the app does not properly implement TLS and is already communicating with your account credentials in the background, it is already inherently insecure; whether or not you use biometrics don't contribute either way in that case.


What can a web application developer do to protect user information from powerful adversaries like the NSA or China

As you can probably tell, I'm not a security researcher, I just develop web apps for a small startup.

That's your answer right there. Don't be a Dave an invent your own cryptography scheme. Just stick to known protocols that have been studied extensively. It appears that you are already doing just that.

Let's say that the NSA really has backdoors into every single cryptography protocol ever (it's just an assumption, it's most likely not true so relax....). What makes you think the NSA who hires a lot of very smart people cannot break your homemade scheme?

Just continue doing what you have been doing and you will be as secure as you are ever gonna be.


By default, OpenSSL files are created in Privacy Enhanced Mail (PEM) format. SSL files that are created in Windows operating environments are created in Distinguished Encoding Rules (DER) format.
Under Windows, you can import a file that is created in either PEM or DER format. However, a digital certificate that is created in DER format must be converted to PEM format before it can be included in a trust list under UNIX.

Here is an example of converting a server digital certificate from PEM input format to DER output format:

OpenSSL> x509 -inform PEM -outform DER -in server.pem -out server.der

Here is an example of converting a server digital certificate from DER input format to PEM output format :

OpenSSL> x509 -inform DER -outform PEM -in server.der -out server.pem


Warning generating OS X payload with msfvenom

"Platform" stands for the OS platform of the payload, whether it is Windows, Linux, OSX, etc. you provide it with --platform
"Arch" stands for processor architecture you are targeting (x86, x64). You use --arch


How do Malware Analysts detect spoofed information?

Well we know that spoofing an IP address (over TCP) is highly improbable due to the three-way handshake that takes place.

On the other hand, spoofing a MAC address is a fairly trivial task. Your only detection for spoofed MACs is to look at the MAC and try to determine the manufacturer (the first three values (i.e. the three "XX"s) denotes the manufacturer in an address like XX:XX:XX:12:34:56). Note that only bad MAC addresses, in other words, MACs that don't resolve to a manufacturer, would be clear indications of spoofing. If the actor spoofs a valid MAC, this will be harder to detect.

Typical controls to mitigate spoofing include using SSL (over TLS) with a certificate signed by a Certificate Authority (CA).


How is private key protected in Java JKS keystore file?

details about [JKS] format.

This is implemented by sun.security.provider.JavaKeyStore
(source in mercurial)
but is pretty simple and based on Java's Data{Output,Input}Stream conventions:
4-byte magic number, 4-byte version number, 4-byte count of entries; a variable number of entries each containing 4-byte type, length+(modified)UTF name, 8-byte timestamp, length+encoding+certcount for a privatekey, and type (in practice always X.509)+length+encoding for the/each certificate; and at the end hash of password plus preceding data for integrity check.

  The store password is just to verify the integrity of the file?

Yes. The JCA API, and the JKS format, allows each privatekey to be encrypted with a separate password, which can be different from the store password. keytool for example allows you to specify a key password, but defaults it to be the same as the store password. However, some programs cannot cope with differing key and store passwords; in particular, those using the default trustmanager and/or keymanager for SSL/TLS (and thus HTTPS) so in those cases the same password must be used for both store and key(s).

  How does the private keys are protected?

Each privatekey is PBE+hash using a 'proprietary' scheme in sun.security.provider.KeyProtector
(source in mercurial) and formatted in the file as a PKCS#8 EncryptedPrivateKeyInfo.


Are Multi device usage and bots in Telegram an excuse for only ssl encryption?

TL;DR: Secure key management is hard. Who knows, but probably eats into profits.

I would think that the big problem is that if Telegram is going to allow you to do any sort of crypto and present yourself as the same person across multiple devices, they have to do one of two things: manage the keys for you, or allow you to manage the keys. If they manage the keys for you, then they hold the keys, which means they can be subpoenaed or stolen. If they encourage you to manage your own keys, it probably opens users up to a lot more opportunities to misuse their own keys, resulting in a less secure product.

If you you want E2E encryption in chats with bots, I suspect it's not an issue of what is possible, but rather what is cost effective. What is the use-case for needing encrypted chat with bots, and how much would it cost to develop, implement and maintain? Again, assuming a profit motive, why should telegram increase costs on its revenue stream? What liability do they assume by managing keys?


This was entirely my fault. I'm not sure what happened, but the file I was trying to decrypt was not encrypted by my key. I tried a different file and it worked.

I'm not sure how that happened, but testing the same file on the old machine first would have saved me a ton of time :).


Is sshpass utility insecure than manual ssh password authentication?

It's less secure than doing it manually, but if you're using Jenkins, you're clearly trying to automate.  That being said, pay attention to the sshpass home page when it says:

Most users should use SSH's more secure public key authentication instead.

Use of sshpass will probably leave the plaintext password in logs files and/or command history logs, which is highly undesirable.  A passwordless key would be more secure than that.


SSL cert minimize downtime key rotation strategy

You assume incorrectly: a cert does not have to be revoked when re-issued. It is typically a different process altogether. This means that you should add a last step to your plan: revoke the old certificate once you are done with installing the new one.

Clients will not cache your certificate. In fact, they cannot keep a cached copy since it is your server that is sending your cert as part of the SSL handshake. They might keep a copy of the CRL in cache for as long as it is valid but that should have only very limited impact on security and none on availability.

Finally, you don't have to restart the servers, you can just restart the process/services using your certificates. It will still cause existing connections to be dropped but it should be much faster than restarting the whole server.


I'll begin by answering with two other questions :

If you roll your own solution, how much time will it take you ?
If your API is public by design, how fast can your developer understand a non-standard authorization mechanism ?

OAuth 2.0 has the benefit of being pretty popular so you can expect your clients (developers) to already know it. You don't need to document all the gore details, you can just point beginners to the specs and existing tutorials.

Also if you're using Java, deploying your own authorization server with Spring Security + Spring Boot or Spring Cloud will be a matter of days, even if you start from scratch. Securing your resource servers (HTTP API) with Spring Security is also made easy.

From a very pragmatic standpoint, OAuth 2.0 is less overkill than building your own solution.


How to make the browser redirect me to HTTPS on a specific site?

Yes you can install plugins to your browser such as HTTPS everywhere:

https://www.eff.org/https-everywhere%20

HTTPS Everywhere was inspired by Google's increased use of HTTPS and is designed to make HTTPS automatically used whenever possible.

It automatically switches sites from insecure "HTTP" to secure "HTPS". It will protect you against many forms of surveillance and some forms of censorship.


How can winlock virus change Windows Registry without admin permission?

The user part of the registry(HKey_Current_User) is writable by unprivileged applications.

The machine part of the registry (HKey_Local_Machine) is only writable by privileged programs.
Some subkeys might require different permissions, but this is true for most keys

To change the shell for the current user, you can modify HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, which is in the user part of the registry, and thus probably writable by unprivileged applications.


I suspect TPM-LUKS is what you're looking for.

It uses luks encrypted volume which is widely supported and store the password/key within the TPM (NVRAM).

The key can be sealed (Trusted Computing terminology) against the proper boot sequence (BIOS, PCI ROMs, MBR, Boot Loader, etc). In other words, the key is derived from the running environment. If something change, the key won't  be the same hence decryption of the volume doesn't work.


There are two vulnerabilities, each triggering a jump to address zero:

The first, inside markContainingBlocksForLayout:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb09fdb70 (LWP 2039)]
> 0x00000000 in ?? ()
  (gdb) bt
> #0  0x00000000 in ?? ()
  #1  0x0194b82b in markContainingBlocksForLayout (this=0x2e29944, owner=
      0x2e298e4, oldChild=0x0, fullRemove=true)
      at third_party/WebKit/WebCore/rendering/RenderObject.h:946

Here's the assembly dump at the faulting eip:

   0x0194b81b <removeChildNode(...)+1083>:  decl   -0x74ffd98c(%ebp)
   0x0194b821 <removeChildNode(...)+1089>:  push   %es
   0x0194b822 <removeChildNode(...)+1090>:  mov    %esi,(%esp)
   0x0194b825 <removeChildNode(...)+1093>:  call   *0xb0(%eax)
=> 0x0194b82b <removeChildNode(...)+1099>:  test   %al,%al
   0x0194b82d <removeChildNode(...)+1101>:  jne    0x194b67d <removeChildNode(...)+669>
   0x0194b833 <removeChildNode(...)+1107>:  mov    -0x24(%ebp),%edi
   0x0194b836 <removeChildNode(...)+1110>:  mov    -0x28(%ebp),%esi
   0x0194b839 <removeChildNode(...)+1113>:  jmp    0x194b728 <removeChildNode(...)+840>

The call instruction calls to the address at eax + 0xb0, which implies that 0x02e294f8 is zero (since eax is 0x02e29448).

Here's the second one, inside RenderObject::destroy:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb1646b70 (LWP 2100)]
> 0x00000000 in ?? ()
  (gdb) bt
> #0  0x00000000 in ?? ()
  #1  0x0194387f in WebCore::RenderObject::destroy (this=0x2e29cc4)
      at third_party/WebKit/WebCore/rendering/RenderObject.cpp:2152

And the disassembly at eip again:

   0x0194386f <WebCore::RenderObject::destroy()+15>:    xchg   %eax,%ebx
   0x01943870 <WebCore::RenderObject::destroy()+16>:    incb   0x3dd4a3c3(%ecx)
   0x01943876 <WebCore::RenderObject::destroy()+22>:    add    %ecx,0x24348906(%ebx)
   0x0194387c <WebCore::RenderObject::destroy()+28>:    call   *0x24(%eax)
=> 0x0194387f <WebCore::RenderObject::destroy()+31>:    test   %eax,%eax
   0x01943881 <WebCore::RenderObject::destroy()+33>:    je     0x194388b <WebCore::RenderObject::destroy()+43>
   0x01943883 <WebCore::RenderObject::destroy()+35>:    mov    %eax,(%esp)
   0x01943886 <WebCore::RenderObject::destroy()+38>:    call   0x194a680 <WebCore::RenderObjectChildList::destroyLeftoverChildren()>
   0x0194388b <WebCore::RenderObject::destroy()+43>:    mov    0x8(%esi),%eax
   0x0194388e <WebCore::RenderObject::destroy()+46>:    mov    0x14(%eax),%eax

This time, it's eax + 0x24, and eax is 0x02e29d38, giving us 0x02e29d5c. This implies that the memory at 0x02e29d5c is also zero.

The distance from 0x02e294f8 to 0x02e29d38 (just less than 2KB) implies that there are two separate allocations being accessed here, so they're almost definitely both different bugs.

The patch diff for the fix indicates that this is a use-after-free issue, where objects were being "merged" at the same time as being deleted. This may be vulnerable to a race condition, where the memory is deallocated, then re-allocated elsewhere in a probabilistic fashion, then jumped to by this bug, but I can't tell without really digging into it.

You could test the exploitability by doing a lot of memory allocations in a loop within your JavaScript (string manipulation is a good one) and then causing the fault during the loop. If the memory is overwritten, the use-after-free might attempt a jump to some of your string's value.


Risks with setting up a authentication-less public VPN

What you're essentially doing is setting up an unauthenticated public proxy with all of the security problems that come along with that.
First of all, your proxy will likely be of interest to several governments and large corporations, since it can be used to bypass filtering or location restrictions (e.g., for streaming sites).  That may lead to overuse or attacks on it to knock it offline.
More importantly, because anybody can use the VPN, it will be used for pretty much any type of abuse imaginable.  Things like sending spam via webmail, conducting DDoS attacks on other people, harassment, sending threats or SWATting people, exfiltrating data, or any of the variety of other unsavory things people do on the Internet.  Limits on rate and ports don't prevent any of these things from happening, since a single person can do a lot of damage with just a little bit of access to websites.
Besides these being bad for other people, your provider probably won't appreciate the abuse complaints, and you may acquire legal liability in any number of jurisdictions for facilitating these activities.  Since there's no authentication, you won't know who's responsible for this behavior.  Moreover, your IP addresses will probably be blocked pretty quickly, so you'll find that the VPN stops working for a lot of sites.
My strong recommendation is not to do this.  Providing this kind of service is not really a good idea on the Internet today because a small number of bad actors can do a huge amount of damage and if anything goes wrong, everybody will blame you.  Everyone providing abusable Internet services has the responsibility to have a robust system for dealing with abuse, and it doesn't sound like this design is going to provide you the opportunity to do that.


Did I get it right? OAuth2, OpenID and OpenID Connect

OpenID Connect is a federated identity protocol. Importantly, it defines the id_token which is an identity assertion that is analogous to a SAML assertion. It tells you who authenticated (i.e. the subject), who is the issuer of the assertion (i.e. the IDP), how the user authenticated (i.e. the acr or AuthnContextClassRef), when the user was authenticated, when the assertion expires, and many more important details. OAuth does not define such an identity assertion. SAML and OpenID Connect also define "metadata"--i.e. how the identity provider and relying party define the endpoint, keys, and crypto needed to validate an assertion. For example, how was the id_token signed? With what signing algorithm? OAuth has no comment on this topic. So without OpenID Connect, you would have to make up all this stuff yourself and define it. OpenID Connect standardizes this identity protocol using OAuth, so we can have standard client software and IDP implementations that are interoperable. It would be a sad world if you needed to know a different authentication API for every IDP. Read the old OReilly book on OAuth that tells you how to authenticate against Google, and then how to authenticate against Facebook just to get an idea how bad that world would be! And that was only two websites.


How do you remotely BOF without knowing source code?

Your understanding of BOF is not accurate, i would suggest reading the exploitation chapter in The Art of Exploitation to get better understanding .

Now regarding exploiting an application without knowing the source code , you can do this with a process called "Fuzzing" which involves sending variable length arbitrary data to where the application is expecting an input and monitor the app's reaction -using a debugger - (you will have to deploy the vulnerable
app on a local machine first so you can develop your exploit )
Once you're exploitation code is finished, you can deploy the attack against the remote machine (assuming it's not protected with some protection mechanism such as ASLR )  .


Big insurance website exposing StackTrace of Java JSON Parser

By itself, it does not represent a particularly large vulnerability.  It does, however have the potential to disclose information about the system which can make it easier to attack.  For example, with the stack trace you've given us, we can see that the system is running fasterxml.  A quick google search led me to the following list of vulnerabilities: https://www.cvedetails.com/vulnerability-list/vendor_id-15866/product_id-34008/Fasterxml-Jackson.html.   The system may or may not have one of those vulnerabilities.

Assuming the system is vulnerable to one of the listed vulnerabilities, we could still exploit the vulnerability, even if we were not shown the error message.  Hiding the stacktrace would not solve the underlying issue.  It would however, make it more difficult to detect.


Is PHP FILTER_VALIDATE_IP secure enough to $_GET an IP address?

There have been issues with filter_var when used with FILTER_VALIDATE_EMAIL in the past, however I cannot find any vulnerabilities with FILTER_VALIDATE_IP.

Even though an IP address does not contain characters that have special meaning within HTML (e.g. <) or have characters that can break out of a database query (e.g. '), I would treat the value like any other string value and use parameterised queries to store this within a DB, or HTML encode when displaying to the page.

This would guard against any future changes such as if it is later changed to a host name from user input - the value would still be safe for both operations.


How to set up a user-friendly NAS encryption?

Currently, your NAS is on the local network, and thus accessible only from the machines on the local network (you say that you trust your router). Therefore, if you fear anything at all, then, by definition, you are assuming that your local network is at risk, and that an "hostile entity" could plug on that local network.

As a corollary, if having LAN access is sufficient to gain root access on the NAS, then you must consider it as already compromised. Whatever the NAS knows, is known to the attacker. You are also already assuming that the attacker is kind enough not to delete or modify files...

Therefore, if any protection is to be obtained at all, then the data on the NAS must be encrypted with a key that the NAS itself does not know; the authorized clients would know the key, and collaborate in the management of the shared storage area which, from the point of view of the NAS, would be a big bag of opaque bytes. This would not fix the vulnerability with regards to data alteration, though. Also, I do not know of any production-ready implementation of a protocol for that; apparently, some people are working on it:

  In addition, we are designing a client-side encryption scheme for NFSv4. This latest version of NFS is intended for use over the Internet, and there are usage scenarios where clients store data on untrusted servers. In our encryption scheme, clients will encrypt data before it is sent to the server. This data will be stored in encrypted form, and will be decrypted by the client when the data is read.

But, really, you should not allow a NAS which can be remotely root-hijacked to be plugged at all on a potentially hostile LAN. You'd better isolate it somewhere, for instance behind a reasonably sturdy router, with which authorized clients would connect with a VPN, e.g. IPsec (which Linux should support natively). Bonus: once you have such a router installed, plug the disk into it, and ditch the NAS altogether.


Internet Explorer - Advanced Properties for Trusted Root Certificates

No. The dialog doesn't add these properties to certificates. It has nothing to do with the currently selected item – it merely adds them to the filter-by-property listbox at the top of the main window. (That's the one that says "Intended purpose: <all>".)

(The more specific name is a "certificate purpose", and the technical name is extendedKeyUsage aka EKU.)

Basically, if you check "Client Auth" here, you can easily filter the cert list for just those which have this usage permitted.

But

You can, however, find a very similar list in the information dialog of individual certificates, under the View button. It does allow removing specific usages, or – I think – adding new ones.

For example, if you have a cert with both "email" and "client auth" purposes, but only use it for email, you can use this to avoid clutter whenever your browser asks you to choose a client-auth cert.

I suppose this could be used for trusting server certs that lack the "server auth" purpose – although it would be somewhat incompetent for a server to even use such a cert...


The security features of using Git might not be straightforward as they depend on what you're using it for, but here are some ideas.

Version Control - duh. But if you're using Git to track configuration files, Software Defined Networking, infrastructure provisioning code, or a deployed application, and suddenly things don't work. You can (theoretically) revert to a known good configuration, see what changes were made, and see who made the changes. This provides auditing and (a form of) disaster recovery. Furthermore, if it's used to manage puppet configs or Infrastructure as Code, it can serve as self-documentation. All of these can protect against downtime.

Hashing - Though SHA1 is considered much less secure now that an intentional collision has been demonstrated, it's still unreasonable to expect almost any malicious actors in a reasonable amount of time to be able to modify anything in your git repository that would stand against scrutiny.

Those are really the only benefits that come to mind, but using something for a version control of configuration files is a huge deal for enterprises. When you have many people capable of "fixing" configurations on your networks and servers, version control provides a very strong mitigation. Generally it would need to be paired with configuration management like Puppet or Salt.


Best practices for notebook anti-theft. Computer tracking

A GPS receiver uses a non-negligible amount of power; even more so if it also transmits its measured position (source: my smartphone; when the GPS is activated, battery life time drops from about 4 days down to less than 1 day). Making an active tracking device up and running whenever a battery is attached may thus lower the laptop autonomy.

Also, battery removal is quite easy on many laptops. If the thief thinks that a battery-powered GPS tracker is present then he may simply remove the battery.

Anyway, a GPS-based tracking device may deter a thief only if the thief is aware of the feature, and thus decides not to grab the laptop and run. It requires even more: the device is a good deterrent only if police forces follow through, i.e. they really use tracking information to pursue and arrest the thieves. Right now, not enough laptops have such a tracking feature, and most will transmit the data only when actually booting up. A laptop thief who is after the hardware (for its reselling value) will simply reformat the disk, not letting it boot up. A more advanced criminal who is after the data will remove the hard drive and hook it on another computer, thus bypassing the GPS tracker.

It so happens that there are many sloppy amateurs in the laptop-stealing business. Many will grab the hardware opportunistically, and then go straight to their home, and boot up the machine "to see what it contains". In that situation, tracking applications like Prey may help: when the machine starts, it records its location (with the GPS) and sends it automatically. With such apps, you may contain the damage from a laptop theft within reasonable limits -- sometimes you can even recover the laptop.

If your data is valuable, though, you cannot really expect that attackers will be so bad at what they do. Targeted attacks will be performed by people who know what they are after, and who will do things properly:

Wrapping the laptop in tinfoil just after stealing it (apparently it works if you put a dozen layers).
Battery removal (just in case).
Extraction of the hard disk for inspection on another computer.

Hard disk encryption (preferably the whole disk, not just a dedicated partition), with a strong password, will be a much more efficient method to keep the data safe.


What cipher mode is usually used for network traffic encryption?

Modern network traffic encryption uses GCM by default.

ECB is used for teaching students about encryption. It's not really useful for anything else.

CBC is the simplest secure mode for static files, but it lacks authentication, so should never be used over a vulnerable channel (network). It's been obsoleted or deprecated from such uses.

It's not really ideal for files either, just simple. File encryption is generally best served by GCM-SIV (opinions will vary). For disk encryption the current industry-standard mode is XTS.

GCM combines most of the performance of CTR with good security, authentication and moderate overhead. If you plant to implement AES, use open source GCM implementations. Write only as much of your own code as necessary to integrate and call third-party libraries.


Does TLS 1.3 mitigate the BREACH vulnerability?

This article, under BREACH sums it up pretty well.

  BREACH targets HTTP compression, not TLS compression

With that said, the random record padding can be done on a higher level of encapsulation and not on the TLS record itself. You do not want to be obscuring the length of the record but the whole response.

Here are the preventive measures mentioned in the post above,

Disable HTTP compression
Separate secrets from user input (these secrets can be taken as a CSRF token)
Randomize secrets per request
Mask secrets (effectively randomizing by XORing with a random secret per request)
Protect pages against CSRF
Hide the length (by adding random numbers of bytes to responses)
Limit the rate of requests


You could first have a look at Grabmotion - a freeware application which uses a webcam as a motion detector that can then email you pictures of whatever triggered it.

It's not connected to the door, but if you had the door in it's sensor range, it could work just as well.

Grabmotion isn't the only one - google will show you many free ones - but it seems closest to what you want straight out of the box.


About performance of Smart card for performing 3DES in a MD5 hash

If your smartcard is any good, then it will commit seppuku rather than allow the 3DES key to be exported. If the key can be exported, then the smartcard is no better than a USB disk. Correspondingly, you should not have a choice: have the smartcard do the job it was designed to do.

(And, MD5 ? Really ?)

Also, a smartcard is a piece of hardware; it may fail, especially if employed repeatedly and continuously (smartcards are not usually designed to be operated in such a way). You'd better have a backup plan, to readily initialize a new smartcard with the same key. If you can do that, then you can produce several smartcards and use them concurrently, which would give you a performance boost. And if you cannot rebuild a smartcard after a hardware failure, then your project looks doomed.


Temporarily store master password locally in online password management system

Take his password to decrypt a copy of the entire database; and re-encrypt that using a locally generated key, from some good seeds.

Store this 're-encryted' version locally only and use the time sensitive key to decrypt this as needed. If any changes are made then re-request the password  (as you should anyway for changes) for when they are sent.


Why does LastPass store password hashes on the server at all?

Yes, you're right - the hashed value is for authentication so that the encrypted data is not given out without the correct credentials being supplied to the service.

Another similar service, Roboform, does have different authentication and decryption passwords for each account. However, there was a serious flaw that when the web interface was used - the master password was sent to Robofom, even though they were not meant to ever receive it.

See this answer for full details of the LastPass authentication and encryption process, albeit being derived from the Security Now podcast.

From these details, my best guess is that the LastPass decryption key is calculated by:

DK = PBKDF2(HMAC-SHA256, password, email, <user set>, 256)

and the authentication key provided by the client JavaScript or application before LastPass service gives you access to your encrypted blob:

AK = PBKDF2(HMAC-SHA256, DK, password, <user set>, 256)

However, this is stored hashed on their backend:

Stored_AK = PBKDF2(HMAC-SHA256, AK, salt, 100000, 256)

As you can see, there is an awful lot of work to be done in order to get from the cleartext password into the form that the hash is stored in on the backend. The number of client side rounds (as indicated by <user set>) can also be increased, depending on the capabilities of each user's least powerful device, this is then hashed again on the client, and finally hashed server side before comparison with the stored hash. This means there's still an awful lot of work to do should an attacker gain access to the server stored hashes (as they may have already done).


I take it because the SSL certificate on the email host's webmail does not cover mydomain.com.

This is correct. To cite from What SSL certificate do I need?: "DNS settings like same IP address or alias (CNAME) do not matter at all, all that matters is the name given in the URL.". And since the name you use in the URL is not covered by the certificate you get the validation problem.

  ... is there any other way to prevent that "Your connection is not Private" warning?

Since you make sure that the URL matches the certificate you need to either change the URL or the certificate. The first can be done with a HTTP(S) redirect as you've already noticed. For the second some service providers might let you setup your own certificate. If this is not possible you might try to setup your own server with your own domain and proxy all traffic to the original web application. Note that this might not work with all applications, i.e. some might have the expected name hard coded somewhere in the application.


Is there a better way to have secure downloads without the requirement of an account?

Security needs to be balanced with usability.  Encrypting the file with the email address ads only a tiny amount of additional security, and adds complexity for end users.

Locking out the user for 2 weeks after a mere 10 bad attempts is also overkill.  I could easily see someone in a company trying 10 times and being unsuccessful and causing you and them enormous headaches.  A 25 character randomly generated code is already protection enough, so why worry about brute force attacks that will just cause you trouble?

Expiring the link after a certain period of time is fine, and relatively standard.  That means compromising the email box doesn't compromise the file.


Is there a point to Dnscrypt when using VPN?

It depends on what you are trying to achieve.

If you are trying to prevent DNS leaks, DNSCrypt isn't what you need. DNSCrypt is intended to prevent DNS spoofing, which is quite different. You could think of it as Privacy vs Man-in-the-Middle.

  DNSCrypt is a protocol that authenticates communications between a DNS client and a DNS resolver. It prevents DNS spoofing. [...] and doesn't prevent "DNS leaks", or third-party DNS resolvers from
  logging your activity.

If you want to verify your VPN doesn't leak DNS, you should look into its configuration. there is usually an option which might not be checked by default.
You can test it here for example https://www.dnsleaktest.com/

For DNSCrypt, it's up to you to decide if it's suited to you. If you don't think it's overkill, go for it.

In the end, it all depends on your VPN Server/Provider and the level of trust you have in its configuration.


Crackstation "Secure Salted Password" Java example - is it really secure?

Much like the salt, the iteration count isn't expected to be kept secret from attackers.  It does make the job of attackers slightly more difficult if they don't know the iteration count since that adds one piece of info they have to find elsewhere.  But that generally isn't expected to be a hurdle that they are unable to overcome.

By storing the iteration value alongside the password you make it easier for the iteration count to be updated on the system while still supporting the existing passwords until they can be changed.  Your password checking routine always knows the appropriate number of iterations to try when matching a password hash for each particular user.  Otherwise you'd have to try to accommodate different past and current possible iteration counts within the password checking code.

Randomizing the number of iterations doesn't really add much value since attackers aren't limited to cracking tools with hardcoded iteration counts or using precomputed rainbow tables with a certain number of iterations.


How to encrypt text so that when decrypting there are 2 (or more) decryption keys with potentially results?

With a xor based cipher this is trivial.

Message A xor random A' makes ciphertext C, C xor arbitrary message B makes random looking B'. Call A' and B' keys.

A, A', C, B and B' have to be the same used length. This would be most believable as a one time pad; with A' and B' being called pads and having extra length of random bits that aren't used appended.

Using more of A' for future messages might be expected but would mean changing the additional part of B' which if detected is a huge red flag for a one time pad. Also it means you have to secretly store A' which is by definition as hard as hiding A.


Question about birthday attack on password

I don't think that the birthday paradox applies here.

The birthday paradox states that in your case, if you have 4.6 × 1013 passwords, there is a 50% chance that two are the same.

However, you only have 3000 password hashes. So you would have to look up in the order of 5016/3000 passwords.

The chance that a random password is in your collection is 1-(1-1/5016)3000. If you try 1023 passwords you have a chance of
(1-(1-1/5016)3000) × 1023 ≈ 20%.


Give users a powershell script to run - Secure?

From a security perspective there is no issue, aside from maybe an awareness problem (e.g. users being taught to execute scripts they might not understand). Do note that most computers may not allow the execution of PowerShell scripts by default, it is something that must be enabled.

One thing to note: how does it actually email all of those things back to you? Does it open their Outlook or does it generate a file that they send back to you? You would not want to hardcode credentials in the script.

The best way would actually be to visit each user, and run the script yourself manually.


Security research on Operating system security measures, where to start?

The issue is that "security" as a standalone notion doesn't exists. You have different threats, and you can have specialized OS designed to address these threats.

A possible threat is that the OS code contains a bug opening the possibility for this code to act in an unexpected way (no matter if this "unexpected" behaviour is exploitable or simply a bug).

This threat is mostly a concern for specific embedded software. It is addressed by micro-kernels based OS. Micro-kernel having less code, this leave less room for bugs but also opens the possibility to formally prove the OS kernel correctness.

Another threat is information leakage from end-user general purpose environments (think about trojan, exploitable software, etc.).

This threat is address by OS compartimentation: it will divide the desktop  environment into several containers, restricting the communication between the container themselves and the communication between the containers and the external environment (network, USB, drives, etc.). Example of commercial solutions implementing this are PolyXene and Bromium, a free alternative is Qubes OS.

Otherwise, more general solution can be achieved using an hardened version of an already existing OS. Here again, the question will be "Hardened against what threat?". This will provide an OS modified in a certain way to address a certain threat (Is it a server environment protecting against remote exploits? A multi-user environment protecting against one user accessing other user's data? Etc.).


How to prove the integrity of a digital file if certificates are not an option

Technically speaking, certificates don't prove the integrity of a file - hashes do.  The certificate signature is a way of proving that the hash hasn't been altered.

Therefore, the answer to your question is - you prove that a file has not been changed by taking a hash and comparing against the hash later.  In order for this to work, you need some way to authenticate that those hashes are valid.  Signing with a certificate is the standard method on a computer.  You could print them out, get a notarized signature on them, and stick them in a safe.  You could print them in a newspaper (put it in a classified ad, the difficulty of forging a newspaper and the timestamped nature of the newspaper provide authenticity).  You could email the hashes to 3 people whom you trust and ask them to provide them for comparison at a later date.


What are the sources of “SEC_ERROR_REUSED_ISSUER_AND_SERIAL” errors when using self-signed x509 Certificates in PKCS#12 files?

Here is the answer that I stumbled upon... there might be other answers, or work-arounds... if so, it would be good to collect them here.

After some struggle, I finally realized that the two certificates that pk12util was referring to were my client and my CA certificates (as bundled in the same PKCS#12 file). Both were signed by the same issuer (my CA) and both had been accidentally been given the same serial number in my Certificate Requests.

One of my problems while trying to understand this problem, has always been the fact that I could not find any "duplicate" certificates in the FireFox certificate database (either through the FireFox browser or using the certutil tool). Of course, in hindsight, the reason was simple, the two (conflicting) certificates had not yet been loaded into the certificate database, but were instead in my PKCS#12 file.

  After recreating my CA, Server and Client certificates carefully
  making sure that each had a different serial number, I was able to
  load my PKCS#12 file, and more importantly I was able to have my
  client (browser) and (Go) server authenticate each other.

A complete working example of a Go based Certificate Authority with certificate creation as well as mutually authenticating client/server applications can be found on GitHub diSimplex / ConTeXtNursery.

I hope this question/answer helps others who have this same sort of problem.


In DNSSec, are Delegation Signer Records always SHA-1?

To answer the question, no, the DS records have many different possible algorithms. This list can be viewed here.

I'd recommend moving from SHA1 hashes to at least SHA256. Personally, I use ECDSAP384SHA384 (Algorithm number 14).


Is the ACME HTTP-01 challenge secure against MITMs?

Indeed, the WebPKI is a cached distributed Trust-On-First-Use system. A CA is hosted very close to the internet backbone, and good CAs perform multi-perspective checks, meaning they are hosted at multiple places worldwide, each location connected close to the internet backbone, and they run the DNS or HTTP validation check from multiple locations.

If you are at an internet cafe with hijacked WiFi and try to do TOFU, you'll get MiTM'd. But it is much harder to MiTM the connection between say AWS and GCP - that traffic can probably only be MiTM'd by Amazon, Google, a Tier 1 ISP and the NSA.

Assume that any sovereign national government can MiTM a connection between any server hosted physically inside their country and a server outside the country. So, if e.g. Turkey wanted to MiTM any server in Turkey, it can. The government of Turkey can also order a Turkish CA to issue certificates that would be trusted by all browsers.

The protection against a CA being fooled by MiTM is the same as the protection against a CA being suborned and a CA being hacked: Certificate Transparency logs will show a certificate for your domain that you did not authorize. If this is noticed and reported, this will lead to the CA being nuked from orbit, live on mozilla.dev.security.policy. You can monitor the major trusted certificate transparency logs for your domains (or pay someone to do it for you, or someone else).


DMARC and SPF are setup for my non-www domain but doesn't work for www

"My website is up and running on www.example.com and I am sending automated emails from >my email address support@example.com."

When these automated emails are sent from your website or application, it sounds like they are being sent using their own mail server without any SMTP authentication. For example, a website may send out user registration email confirmation messages using sendmail or postfix mail server software which is commonly installed on web servers for this purpose, however those who send spam or spoofed email messages use the same techniques and can also claim to be sending email from support@example.com. With some configuration, your website could be sending authenticated emails, i.e. instead of using the built-in mail server software, the website connects to your domain's main SMTP server (could be Exchange or Office365 or Google etc, other mail server brands exist), authenticates with a username and password, just as you would if you were using an email client application on your phone or webmail, and then it sends the email.

  "No DMARC Record found for sub-domain. Organization Domain of this sub-domain is: example.com Inbox Receivers will apply example.com DMARC record to mail sent from www.example.com"

In the absense of a sub-domain DMARC record, the main record for the domain will apply. Unless you are using email addresses like support@subdomain.example.com this is not likely to be an issue. You could ensure there will be an SPF fail in this case by have a wildcard SPF record to cover any subdomains spoofers may think of, for example: v=spf1 -all, and enter * as the hostname for this record. This will not interfere with the SPF record you have created for the @ which covers your normal use of email for the domain, email addresses such as support@example.com.

  "A DMARC record is defined, but there are some issues with the configuration that may impact security, visibility, and deliverability for email sent from this domain."

Without more investigation it will be difficult to tell exactly which issue this may be referring to, however it might be as simple as the fact you're specifying an email address with the same domain name for the reports to be sent. If there are email delivery issues with the domain example.com your reports about it may not be received at support@example.com! Perhaps setup support@example.net or other different domain for processing your DMARC reports.

  "DMARC is not at enforcement for example.com. Anyone can send messages purporting to be from addresses on this domain or its subdomains."

This simply means you have p=none or p=quarantine at the moment. The first is ideal for when you're just getting started and need some oversight as to what's going on without wanting to cause problems unnecessarily. The second is a good mid-way point to start seeing messages quarantined (moved into Junk folders) when you're testing the effectiveness of which ones it blocks and doesn't. Eventually the aim for most organisations will be to set this to p=reject in order to ensure the messages simply get dropped and are never received. Since DMARC forensic reports are rarely implemented at present you might actually be safer going for quarantine until you are entirely satisfied that those being quarantined includes no genuine messages. Some tweaking may be required before you move to p=reject. The message you're seeing doesn't mean you've done anything wrong, just that your implementation is at the early stages.


Create sub folder's like /platform/invoices/useridclientA/. And store clientA's invoices in this particular sub folder.

Further disallow Navigation to this folder directly via server URL's like
https://www.example.com/platform/invoices/*.

Create a server side script(e..g PHP) which will validate the userid of ClientA and read the only clientA files on filesystem and allow him to download.

You can optionally further randomize filenames while generating invoices.


Have weaknesses in SHA-1 and MD5 ever actually been successfully used in an attack?

I'm not aware of any publicly known attack using collision in SHA-1, but MD5 collisions were probably used already 2010 within attacks. In 2012 it was discovered that a malware from the Flame attack had a valid signature from Microsoft, which was possible due to a MD5 collision attack. See http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx for more details.

As for using MD5 or SHA-1 with passwords: Simple hash some trivial password with MD5 or SHA-1 and then look up the hash with google. Example:

 password:   "secret"
 md5 (hex):  "5ebe2294ecd0e0f08eab7690d2a6ee69"
 sha1 (hex): "e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4"

The first hit on google for the MD5 hash presents you with the password, as does the first hit when searching for the SHA1 hash. Thus typical passwords can easily be detected as long as the hash is not salted.

Apart from that, even SHA-256 is a bad choice for passwords. These kind of hash algorithms are designed to be fast which only makes brute-forcing passwords easier. For more details about this topic see How secure are sha256 + salt hashes for password storage.


This stuff usually happens not because of malicious scripts but because the ad provider has ads with malicious content. Contacting the site owner will only make him aware but since he probably still wants to display ads he will not do anything about it.

What can you do?

Contact the ad provider and tell them they have malicious ads (Maybe they don't know?)
Download a Firefox Android ad blocker extension to block these in the future (You can browse through the extensions here).


It would have helped if you would have provided with the HTML code as well. However, i think the reason why it does not work is because the value of the hash anchor is not being utilized in the JavaScript.

It would have been exploited as DOM based XSS if this value was being used in JavaScript somewhere. Here's is an example of code vulnerable to DOM based XSS:

URL: http://www.example.com/page.html?default=French

Select your language:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
document.write("<OPTION value=2>English</OPTION>");
</script></select>


Is there a use-case that renders the password manager obsolete?

Your argument is contingent upon using a web based service. If you use your password manager for SFTP, encrypted drives, desktop apps, etc. then you don't have a self service reset option.

If we then want to continue the argument only for web apps, here are some issues:

This requires you to use one email address, which may not be practical (work versus personal email should not be commingled) or may not be desired (anonymity concerns, organization, shared email for a club, etc.). If you use multiple email addresses this also reduces the impact of one of them being compromised.
This requires the service provider to require an email address, not all services request or require you to provide an email address.
I am not sure you want to count on reliability of a reset service. This may take significantly longer for the reset email to go through. The service provider may (should) rate limit such requests.
Password resets are not designed for this purpose. A password reset may be part of a comprehensive analysis to put the account on a higher alert for monitoring. The account was just reset, this is unusual, so apply more monitoring and checks because the reset may indicate an account takeover. Password resets are not generally considered the norm.
For a password reset there is often challenge questions, so these still have to be entered each time. This is needed because the email account cannot be known to be secure or isolated to the user. Depending on who you ask, this is sort of combining "something you know" (challenge questions) with "something you have" (the email account).
I would personally rather the attacker had to break into my computer rather then find a flaw in the email providers system, internal networks, etc. I don't really feel like my email on the Internet is secure or private.
Even if this was super fast, in every case and there were no challenge questions, its still tedious, requires switching tabs, etc. You may also get distracted by your other emails, things may accidentally go to SPAM. I use a keyboard shortcut for auto-type, very quick and transparent. My password manager also clears out my clipboard.

At the end of the day, I think I have more control over my desktop password manager, it applies in many more scenarios, and its easier and more reliable.


First things first: don't panic. Don't do anything rash, and take time to think.

The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte values were more probable than others, especially in the first bytes of output. This leads to the possible following attack: assuming that a given secret message m is repeatedly encrypted, each time with a different key but always at the same position in the stream, then observing the encrypted data would allow to recover the message m. Indeed, if at position j key stream byte x is more probable than all other 255 values, and the attacker observes that encrypted byte value b happens more often, then he will guess that x = b XOR p for plaintext byte p, thus p = x XOR b.

It was usually assumed that though RC4 has biases of that kind, they were not really vulnerable in the practical usage of RC4 in, say, SSL/TLS.

The new results add a few more biases to those which were known, and in a more systematic way, and and gives measures. The measures partially confirm the stance above. Of course, the slides are prone to take an apocalyptic stance and to warn of utter breakage, because: 1. researchers need to do a bit of marketing and advertisement on their results, so as to attract funding, and 2. it is the Bernsteinesque style to shout that the End of Times is nigh, and that everybody else is wrong.

What the figures say is that it takes a few millions of connections for the attack to work. In a practical SSL/TLS setting, where the target is a cookie value, you won't open a new connection more than once every 15 seconds or so, because the browser and the server will "keep the connection alive", so it would take one year of 24/7 Web surfing, always on the same site, always immediately after the browser or the server decided to close the current connection, to become susceptible to this attack. Therefore, don't panic. There is no reason to rush and delve into cipher suite settings. Yet.

RC4 should still be phased out in due course. Indeed, the biases are slight, but bigger than previously expected ("we" thought that the "few millions" were "1 billion or so"). The safety margin is becoming quite thin. RC4 got a revival lately due to the BEAST attack, but it was already considered as a temporary measure. Indeed, the BEAST attack no longer works because workarounds were found.

One way to "fix" RC4, which has been suggested many times, is to drop the first 256 (or 512 or 1536 or whatever) bytes of output, since these are the most biased of them (the graphics in the slides show that quite clearly). But this would not be compatible with RC4-as-we-know-it, so it would make little sense to force that on SSL/TLS. If SSL libraries must be modified to implement a better algorithm, they may as well use one which is already standardized, i.e. GCM (see RFC 5288 for the integration of GCM into SSL/TLS). This would be better than a refurbished RC4 which would still has other biases (slighter, but still detectable, and not limited to the first bytes of output).

For now, do nothing. But see what Google will do. What Google does, the World will follow.

On an immediate basis, if you are really that worried, switch back to AES/CBC (or even 3DES/CBC), despite BEAST which, as explained above, does not work anymore with an up-to-date browser (and if the browser is not up-to-date, then the user has much more pressing issues to fix !).

In an ideal world, this new attack, despite its lack of immediate applicability, will prompt vendors to implement TLS 1.2 + GCM, and the Web will be safer.


Script Kiddies - how do they find my server IP?

You can't hide your IP address on the internet. They aren't secret.

Pretty much what @DeerHunter said. It's trivial to scan the entire internet. If they want, they can target all-known digital ocean droplets that are online.

They can do this on a timer so that when you go offline, or online, it will just keep trying as those may be high-value targets that could become vulnerable at a moment's notice.

Let me give you a very rough coding example. Let's pretend your IP address is 104.16.25.255. Let's get the IP address of www.digitalocean.com so we can easily check for associated IP addresses. www.digitalocean.com returns 104.16.25.4. Let's scan everything: 104.16.25.*

Scanning is incredibly easy from a programming standpoint

Let's assume we want to try and find all nearby associated IP addreses. Assume programs can handle numbers and patterns very well. Here's an example of an integer being incremented:

i++;

This increments the current value of i by 1. Let's assume i starts off as 1. After i++, you'll get 2. Check out this painfully simple loop:

for (int i = 1; i < 256; i++)
{
    scanIpAddress("104.16.25." + i);
}

An alternative one-line bash variant would be as follows:

for ip in `seq 1 255`; do scan_thingy_command 192.168.0.$ip --options -oG lol.txt; done

You just scanned 104.16.25.1, and changed i from 0 to 1. As the whole loop continues, it will go from 104.16.25.0 to 104.16.25.255. I don't have time to scan and look right now, however, it's possible that this tiny block doesn't just belong to digitalocean.

To find more targets on DigitalOcean, a programmer may change the numbers even more. For example, introduce another loop that nests the aforementioned loop on the inside, and add j: scanIpAddress("104.16." + j + "." + i);. This will allow them to scan 104.16.1-255.1-255.

From there, they can keep going backwards and nesting for loops until they get the entire internet. There are other, more efficient ways to do this, such as masscan, but this is the most basic way.

Again, this could also be done on the command line with one line:

for oct1 in `seq 1 255`; do for oct2 in `seq 1 255`; do for oct3 in `seq 1 255`; do for oct4 in `seq 1 255`; do scan $oct1.$oct2.$oct3.$oct4 --stuff; done; done; done; done

Other methods

The above example was a really rough example. They may be doing more, their code might be different, and they may be using entirely different methods and/or programs. However, the concept is pretty much the same.

It's also possible that the programs in question are just targeting everyone en masse.

So how can I hide my stuff online?

If it's online, whatever you are hiding, they will find it... or try to find it.

However, depending on your web server, you can try http access controls such as .htaccess. If you're using access controls - again, this depends on your web server - then it's likely that you'll be able to prevent others from viewing/accessing pages.

That won't protect you against non-website login attempts, though. And if you're denying them access to non-existent webpages, they now know you're really online, and can focus their attacks more easily! However, it's still good practice.

Here's an example .htaccess deny for Apache (2.4 and later):

Require ip 192.168.1.100

In the above example, you're denying everyone access to that folder, except your IP address. Keep in mind, 192.168.1.100 is a local IP address. You'll have to replace that with your public IP address.

Also, keep in mind that if your attacker is running a proxy/VPN on your machine, they can still access those pages. If your attacker already has access to the website, they can either edit the .htaccess or remove it. Nothing's 100%.

Just don't put anything online if you aren't ready to be scanned. Everyone has a plan until they get port-scanned in the mouth.


Is it a security issue to use the same self-issued certificate both as a certificate authority and as a server certificate?

When you talk about security, all this self-signed SSL stuff has nothing common with security. In order to implement proper SSL configuration for internal network, you have to:

Create your own CA server (depending on a platform, different products may be used. For example, in Windows you can use Active Directory Certificate Services, in Linux you can use CA software like EJBCA). CA certificate will be self-signed
Provide best security for your CA server: strict physical and remote access to the server.
Distribute self-signed root CA certificate to trust store on all affected clients
Use this CA to issue certificates to clients and web servers
Maintain revocation information for these certificates (CA server will periodically publish CRLs)

The reason is -- separation of concerns and security. Web servier is by default less secure. There are more chances that private key leaks from web server, because you can't guarantee adequate security for it because of web server specialization (be public). With dedicated CA you can provide better security, so less people can access it either, physically or programmatically.

If you lose SSL certificate, you can revoke it and issue a new one. Minimum server reconfiguration is required. No client reconfiguration is required. If you use CA certificate on web server, you will have to recreate every server/client certificate and reconfigure all of them in the case of key compromise.


Can I copy a PGP revocation to another server?

You mean a revocation-certificate, right?
The public-key remains the same, but you can calculate a 'message' stating your key is no longer in use and people can check this signed message with your public-key.
This is a certificate-revocation and it's made with your private key and then - just published.

Maybe you can grab your revocation-cert from somewhere and re-publish it again?


The KDBG is a structure maintained by the Windows kernel for debugging purposes. It contains a list of the running processes and loaded kernel modules. It also contains some version information that allows you to determine if a memory dump came from a Windows XP system versus Windows 7, what Service Pack was installed, and the memory model (32-bit vs 64-bit).


How to get public prime from DHE from TLS v1 DHE-RSA x.509 certificate?

I don't think you can do this with any openssl command line program. At most you might use -debug option with openssl s_client so that it shows you all the transferred data as hex and then you can try to figure out what this means. It is far easier to use Wireshark to sniff the connection and then look at all the handshake details. This gives you also the DH parameters you want to know:


As in the first line is it visible, he tried to use the Shellshock security hole of the bash shell.

His idea was probably the following: the Shellschock works by evironment variables, i.e. in some cases the bash would execute an environment variable as a shell function. And apache maps the parameters of the http requests (cookies, query strings, posted arguments, etc) to environment variables.

If there had been a cgi script on your server written in bash and interpreted by an unfixed bash shell, his commands could have been executed.

Later he tried to execute different shell commands. These commands had sent their output on tcp or udp protocol to a server under his control. It is because bash has an internal redirection mechanism to tcp and udp data streams, i.e. files beginning with /dev/tcp/ip/port are mapped to network sockets. It is an internal mechanism of the bash shell.
It was probably not a direct, manual attack, but a robot tracking for vulnerable servers.
The IP addresses he used are probably not his original server(s), but the ones he can already control remotely.


App uses html_safe method, possible issues

Here's an article explaining in details how html_safe actually works. In short, you should not call .html_safe in untrusted strings or in strings that contain other untrusted strings (e.g. "trusted #{untrusted} trusted").

If you have a trusted string (not user inputted) that you need unescaped, you can call html_safe in it, and proceed appending other strings to it (or appending it to other SafeBuffers). Every regular string appended to a SafeBuffer will be escaped, and thus can not cause XSS vulnerabilities. If you concatenate two SafeBuffers, however, no escaping will occur.

Also according to the linked article, the rendering of every view starts with am empty SafeBuffer, so every string you append to it will be escaped by default.


As of the current version (3.30), hashcat does not currently support truncated hashes beyond the half-MD5 modes. In my discussions with the team, I made the pitch (basically what I wrote here).

So far, they have expressed non-interest in expanding partial-hash matching to other types, as it's considered to be out of scope for the project. But this could change in the future.


How risky is to to use external DNS servers?

Here's what we can tell you:

Public DNS record is publicly accessible
Parts of the Public DNS systems can be subverted by sufficiently advanced attacker, unless measures like DNSSEC are taken and enforced

From these we can see several issues under the following scenario:

You have internal service but you used public DNS to map these names to your internal IPs.

an attacker could conceivably take over the external DNS to redirect traffic from your internal IP addresses to a server they control, possibly outside your internal network. This can be prevented by strong authentication between your internal servers or by network control to prevent most internal servers from connecting to external addresses or by requiring DNSSEC record. However, when you have thousands of different services, this may be unfeasible.

You have internal services with names that discloses who your partners are and what systems you internally have. This can be a business privacy issue, as your business may not want just anyone to be able to list who you worked with. There's nothing you can do about this, public DNS is public record, you should run internal DNS if you don't want your names to be used to infer what partners or internal systems you are running.

If these are a problem to you, then you probably should run your own internal DNS system.


Your assumption is correct.

John The Ripper by default will save its state every 10 minutes. When you ran it on your NUC the numbers first displayed to you were saved in the .rec file from one of those auto saved states. When you uploaded it onto the instance the state saved in the .rec file still showed the same numbers as your NUC because it was not updated yet.

When you deleted the .rec file a new one was created with the new numbers. If you want to see the numbers in live while it is running you can type any key into the console.

You can read a little more about it here.


Should the traffic between the containers need to be encrypted?

Whilst it depends slightly on the nature of the environment in use, in the general case I'd say that you likely do want to encrypt traffic between two containers.

In a default Docker setup (e.g. no fancy overlay networks to consider), containers communicate with each other over the default Docker bridge.  Also by default containers are assigned the NET_RAW privilege which means that amongst other things they can try to carry out things like ARP spoofing attacks (there are details of this in this whitepaper from Jesse Hertz

So if you use unencrypted communications between 2 containers, then there is a risk that a third, malicious, container running on the same host could try and sniff the traffic between your two containers.

How realistic that threat scenario is, will entirely depend on your application.


I observed that certain attacks could be both DOM-based and Reflected XSS

No. What you list are the same payloads for both DOM based and reflected XSS (both attacks are often exploited in similar ways). But what happens underneath that is still either DOM based XSS or reflected XSS (well, or stored XSS). It's never both.

The names for the different XSS types do not specify how an attacker will attack someone, but how the attack works. As you noted, both DOM based XSS and reflected XSS might be exploited the same way, eg:

http://example.com/index.php?user=<script>alert(123)</script>

But with reflected XSS, you will have a server-side script, which will take the user argument, and then place it into the HTML document it returns to the user.

On the other hand, with DOM based XSS, the browser will take the user argument and then place it into the webpage.

So the difference is how the payload ends up being executed user-side, and that can happen one way or the other. But it can't happen both ways at the same time*

well, technically, it could if the server as well as the browser place the payload in the website, but that's not really the point.


Trust companies for information storage?

it is never said how well this information will be stored and secured

It's untrue that you are not told about data protection promises from the provider (see privacy policy). Also, use/reuse of data is described (often in a fuzzy way) in the Terms & Conditions that we approve so quickly. Technical implementation of the security/storage systems (including encryption used) are rarely shared with end users, however most companies are cautious about making promises.

Ensure that the company that you trust has been through independent audits and has been certified to meet compliance standards. Depending upon the location, regulatory bodies have been known to act against deceptive practices.

Some studies do show that Data Protection guarantees are hard to enforce [EU] [US].

As an individual you have very little power for individual verification for most websites. The Australian Government has a simple 8 point list of what to look for before you trust an entity.


Are Windows password hashes salted with the user name?

The file containing passwords in Windows clients is called the SAM file. All passwords stored locally in the SAM file (e.g. local accounts) are hashed with a salt.

Active Directory on the other hand will store passwords without a hash, but in a different file on the Domain Controller.  Domain account passwords are stored locally by default for users to be able to sign on when they cannot connect to a DC, and these passwords are hashed with a salt as well.

See here: Does Windows really still use unsalted MD4 for password storage?


What's the best practice when using a VPN and a VM

Depends why you are connecting to the VPN, and the configuration of it.

Connecting to a VPN to access data on a different network: if you only need to access the data from within your VM, connect from your VM, else connect from the guest OS - minimal exposure.
Connecting to a VPN to hide network traffic from the network owner: Connect from the guest OS - all traffic encrypted.

In the first case, other traffic may or may not go through the VPN - this is the configuration part.

In either case, a VPN only protects against a limited range of threats: specifically those which result from network traffic being monitored. You'd still be vulnerable to malware, poorly coded websites, and people looking over your shoulder!


How does CVE-2013-4287 make Rubygems any more vulnerable?

You'd have to ask them, but most likely it's because the simplest and quickest way to demonstrate that the bug was somehow exploitable was the excessive CPU thing. Gets the point across without much work for the programmer.


Is it possible to retrieve SSH v2 credentials in a username/password authentication scheme?

Yes, password credentials can still be stolen through a man-in-the-middle method with SSHv2.

The victim profile will depend on the type of man-in-the-middle method used. For your example of arp poisoning from a client workstation, arp poisoning would maximally really grant middling between clients on the nearby local network, or all clients if the server is on a nearby local network.

Other middling methods, such as DNS poisoning could increase the victim scope.

Most SSH clients will remember the public key of an SSH server they have previously connected to. So regular users would likely get a scary error or warning when attempting to connect through a mitm.

Using private key authentication is one way to avoid disclosing the secret credential, even if the connection is middled.

Here is an example story tool description.
http://woff.hu/tools/ssh2-mitm-like-attack-with-jmitm2/