Can the U2F standard be used by servers to impose a specific category of hardware? I don't like that browsers, email clients, etc. come bundled with CAs and that there is no emphasis for a more decentralized authentication mechanism.
Fortunately, it's not too bad, because at the least, whatever is our favorite platform, we can create our own clients, say an IMAP client, using any programming language we like, say Python, with whatever bundled CAs we like.

It will be too bad that we lose that flexibility and start to depend on new platforms, new USB devices, etc. Sure, it is an open standard, but if it is a part of this open standard, that servers can accept only specific hardware such as special USB devices, then in practice, one programmer will not be able to program a client on the platform of his choice. Sure, any big company would be able to build a device that respects the standard, but still a lot of flexibility would be lost. I am not saying that this is the situation with the new FIDO U2F standard, but I am curious about that.

For me, a good standard must restrict as little as possible both sides. As soon as a "standard" allows one side to impose constraints on the implementation on the other side, even in the name of security, it seems that a fundamental notion of freedom, implicit in the open source original idea, is under attack. This original idea was to allow any programmer to create practical code with as little constraints as possible. It maybe that the situation is as before with CAs for website or email certificates and it is just that the current emphasis in on specific hardware on the client side - that would not be too bad.

My questions:

How can we build our own clients, using the platform and the language of our choice to connect with any U2F compliant server?
Is it possible to build, say an IMAP client, on the platform of our choice, to authenticate with any, say IMAP server, that respects the U2F standard?

U2F in and of itself does not provide a protocol for client-server communication. It provides a set of requirements that need to be met in order for the scheme to be considered authenticated. These requirements define a set of messages, but don't define how they get passed from the client to the server and back. As such, the answer to whether you can build a client for any generic server is: no, because there simply isn't a generic protocol. That said, you can certainly build a generic service that can process the messages sent, but you would need to define the mechanism by which the messages are sent.

Given the first answer, the second answer is necessarily no as well. This doesn't mean that you can't strap U2F on top IMAP and have it has an extension, but that naturally means it requires custom code on both sides.


How to manually check for rootkits on a server Does anyone have a general step by step list on how to try discover rootkits on a Linux or Solaris server?

I'm looking for to to manually find the rootkit, not by automated software.

For example:

Places to look for suspicious files?
Search commands to pick up weird file behavior?
Weird looking traffic picked up from sniffer?
Checking file integrity on important commands in order to know if you can trust it or not?

The number of options for places to hide, places to hook etc is so vast that any step-by-step list for manual checking is going to be incomplete.

And of course, there is a whole other story of kernel rootkits, which leave a very small amount of traces in the system, that can usually be discovered with forensic analysis if implemented correctly.

What you ask for is simply wrong: Even if I start listing things to check, it is going to be very misleading for anyone reading it. The average user's best bet is to use tools like chkrootkit and rkhunter, that while incomplete and easily bypassed, contain the 'list of things to check' you ask for and go through it in an automatic way.

Disclosure: My previous area of research was rootkit-related and I have developed various rootkits and rootkit detection software for linux platforms in the past.


Does anyone know what this encoding format for passwords is? I think it is a decimal array but I can't seem to convert it During a penetration test, I ran across a server that was storing passwords in its database in what seems to be a binary array of sorts:
password_table

1,12,12,12,122,21,13,00,00,00,000
11,112,443,12,31,09,100
110,1123,108,117,108,62,62

(slightly edited for confidentiality)
I've additionally managed to obtain a password fellfa to correspond to 1,09,10,81,15,11,51,09,000. The range of numbers seems to span 000 all the way up to 128.
Some of the lines don't even match up properly when split into triplets and some contain large numbers that don't fit in to the ascii charset even with offsets (45,119,142 for instance).
The server in question is a Tomcat server and the application is running a Java program. I considered that this might be a array of sorts but I can't seem to convert these arrays into anything readable or usable. Does anyone have any ideas?

The commas appear to be somewhat unrelated. When the commas are removed, most of the digits are in groups of three.
At first, it looks like a shifted ASCII substitution, just as Marc suggested - but with some variation:
109 = f (102 ASCII +7)
108 = e (101 ASCII +7)
115 = l (108 ASCII +7)
115 = l (108 ASCII +7)
109 = f (102 ASCII +7)
000 = a (???)

Note especially that the numbers are the same distance from each other than the letters themselves are in an ASCII table, but just shifted by 7 positions.
(But even when divided into triplets, your original posted passwords don't quite match - but that may be because of the obfuscation.)


Are path traversals attacks possible with invalid directories between? Let's say I can control the variable $path and the full path is generated as follows:

$full_path = "./valid_dir/docs/" . trim($path) ;
readfile($full_path) ;

where docs a non existent dir in the path.

Is it still possible ,with some trick perhaps to ignore docs, to perform a path traversal  attack ?

Is it still possible ,with some trick perhaps to ignore docs, to perform a path traversal attack ?

Yes, it's pretty simple, just use ../ and it will be normalized before the file is opened (on *nix systems anyway, I don't know for sure on Windows).

Something like this would work.

$path = '../test.txt';
$full_path = "./valid_dir/docs/" . trim($path);
readfile($full_path);


Is it possible to get malware through an incoming video/audio stream? (e.g. Omegle, Skype etc.) Is it possible for incoming video/audio streams to contain malware through exploits in the transfer of the video/audio?

It could be possible in some cases.
For example, imagine that the videoconferencing software has a vulnerability into the file format parser (E.g. buffer overflow)... then it could be exploited by a remote attacker.

Look at VLC for example http://www.cvedetails.com/vulnerability-list/vendor_id-5842/opec-1/Videolan.html


Has CVE-2014-6271 Shell Shock been mitigated completely what is the latest? I have patched my system however CVE-2014-7169 claims that the fix for 6271 was incomplete. Sure enough if I run the command below:

env X='() { (a)=>\' sh -c "echo date"; cat echo

It appears that function parsing is still executing code as I do not get an error like I am supposed to. So if 6271 allowed an attacker to execute arbitrary commands at will, does this mean that after being patched you are still vulnerable per 7169 but not to the same extent? If so, does this mean an attacker can still exploit the bug but running arbitrary commands is no longer an option? How much more "secure" is this? Can someone provide an example?

They're the same vulnerability.  CVE-2014-7169 was simply a bug found in the original patch for CVE-2014-6271 or "shell shock".

CVE-2014-7169 allows us to side-step the patch released for BASH that was rolled out alongside the original bug disclosure for CVE-2014-6271.

To test if your system is still vulnerable after applying the patch for CVE-2014-6271, simply type:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

If you can still pass characters from your environment variables into other environments, your version of BASH is vulnerable.  If so, you should see the date appear on your screen, and a file called "echo" will be created in your /tmp/ directory.

To update BASH type the following, depending on your Linux distro:

yum update bash

or

apt-get update bash


Autorunning program on a USB drive Is there a way to automatically run a program (e.g. Python or C++) on a USB drive and bypass the popup window in Windows 10 (showing the different choices you have for the drive)?

I have seen that someone converted a USB drive to U3-USB and were running it as a CD instead. Not sure if this works in Windows 10 though.

Actually, YES!

You can spoof USB HID, and then from there you can do anything. It isn't as simple as autorun though. I recommend using the digispark microcontroller (ATTiny) <- I used it, I can endorse it!

EDIT: If you need any help, say so, I can guide you

Edit no 2. Things like USBKill are a good defense against this kinda stuff


CSRF-protection using authentication token in HTTP header? I'm working on a web application which stores an authentication token in a cookie.

The only CSRF-protection is referrer checking.

I am considering improving this by moving the authentication token from cookies to a custom header, such as X-AuthToken.

The application is a single page application created using JavaScript.

I believe this should be a robust protection against CSRF-attacks, because if an evil site forces a users browser to do a HTTP POST, the auth header won't be included and the request will fail.

The auth token is generated on a per-session basis.

Am I right that this would offer CSRF protection or am I missing something?

Short answer: yes, it would be secure if correctly implemented (long enough, random, unique tokens, one per session, etc).

Long answer: If you decide to add a custom header to the requests sent to the server using JavaScript code, it is similar to sending an anti-CSRF value in the POST parameters (the more often used approach).

POST /test
Host: www.example.com
X-AuthToken: unique_random_value

p1=val1&p2=val2

or

POST /test
Host: www.example.com

p1=val1&p2=val2&x-authtoken=unique_random_value

So it's up to you to decide which option is easier to implement, but both should work in a secure manner.


Open ID, Storing card details, and PCI compliance If you store payment card details for a user, and you have a 'Login via openID' which includes services like Google and Facebook, is this allowed under PCI Compliance? Or do you need your own distinct openID login server?

For use by consumers, I believe you should be ok, but for use by employee's you'd potentially run afoul of PCI-DSS requirement 8.5.  OpenID provides an authentication mechanism independent of data and validates a user matches with the unique ID assigned to the user within your system.  For non-consumer users there are additional requirements for password complexity and changes that might not be enforced by a third party OpenID system, however for the consumer users (whose information is being protected), it seems to be allowable to let them use an OpenID to authenticate.


Safari downloaded my php source once. Should I worry? I uploaded via ftp, then typed in the URL of the script to Safari; Safari downloaded the source!!

This hosting site has never done that before - .php scripts have always executed.

I can't duplicate it. The page loads as php should now.

Maybe I just caught them while some .htaccess setting was changing?

Maybe my debug line ini_set('display_errors','stdout'); allowed this?

There was a 'compilation failed' error on the page.

So now, I gotta change my sloppy ways and write php code like it is exposed to view.

What could possibly have caused this anomaly?

OK, what happened was, I had recently changed the .htaccess file to use a newer version of php. Fine. But I had also downloaded that .htaccess file to my local server. The web address for the local is similar to the site. So.. fumble-fingered, I didn't notice Safari had auto-filled the address with my local site.
The local site was trying to run the script with the new version of php which it did not have, so it just delivered the script as a download. Not the best thing to do, I don't think, but at least it wasn't the live server.

So I have mutated the question to 'should I worry' about exposed php. After all, if my local server will deliver the script text under some conditions, might the live server, also?

Check your server php configuration as explained here.

Make sure you have AddType application/x-httpd-php .php in the httpd.conf file.
Use <?php instead of <?.


Would memory of EC2 instances behind a vulnerable ELB be readable by heartbleed exploit? It is public that Amazon's Elastic Load Balancers (ELBs) were vulnerable to the heartbleed exploit before they patched them all on April 8th.  I understand that the memory of these ELBs (and therefore the certificates on them) could be compromised, but I'm curious if there was any risk of memory exposure of the EC2 instances behind these ELBs (given that the EC2 instances were not themselves vulnerable, nor accessible from external IP addresses).

No.

The heartbleed-bug only compromises the memory of the operating system process which uses OpenSSL. The memory of any other processes is not compromised. When load-balancer and application server are different processes AND the load-balancer acts as TLS server (instead of just routing the raw data-stream to the application server which then does the TLS), the memory of the application server can not be compromised.


How does SAQ A-EP apply in the situation where no I frames are used I'm really disappointed in SAQ A-EP. I feel that as a web developer, there are just way too many questions that go over my head and I couldn't possibly know.

I use primarily Stripe and Braintree in my e-commerce solutions. So, there's this article of interest:

https://support.stripe.com/questions/what-about-pci-dss-3-0

They claim they're fully compliant under SAQ A. Stripe.js works by taking credit card data and passing it (via Javascript) directly to Stripe's servers, where the data is tokenized, and passed back to the merchant. Stripe says this makes a merchant eligible for SAQ A, however, SAQ A states:

  The entirety of all payment pages delivered to the consumer's browser
  originates directly from a third-party PCI DSS validated service
  provider(s).

Furthermore this article states:

SAQ A:

  Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, where no elements of the page originate from the merchant website.

SAQ A-EP:

  Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, BUT some elements of the payment page originate from the merchant website.  (Elements would be JavaScript, CSS or any functionality that supports how the payment page is created.)

To me, it sounds like Stripe still puts people under SAQ A-EP. Or PCI is very unclear, because both SAQ A and SAQ A-EP say that an iframe is acceptable.

But regardless of that, Stripe.js does not use iframes at all, so it seems to me it doesn't make one eligible for SAQ A.

Thoughts?

EDIT:

My mistake. After looking deeper into the Stripe.js code, I can see it's dynamically creating an iframe. I'm not sure what it's doing with it, but I'm sure they're performing some sequence of steps to be SAQ A compliant.

The page you linked to above says:

  The new version of Stripe.js meets these criteria by performing all
  transmission of sensitive cardholder data within an iframe served off
  of a stripe.com domain controlled by Stripe.

So Stripe does use iframes to make their customers eligible for SAQ A rather than SAQ A-EP, as long as you use the new version of stripe.js.


Steam and two-factor authentication The Steam platform is designed to encourage users to use two-factor authentication.  One of the community tasks (achievement-like objectives) on Steam is "Use the Steam Mobile App for two-factor authentication".  This is visible on public profiles for anyone.

This could let possible hackers quickly find out whether an account uses two-factor authentication, letting them choose targets more efficiently.

Should people be concerned about this security risk?  Should it be reported to Valve?  Or is it harmless?

Doesn't this feature completely undermine the purpose of 2FA as hackers would simply avoid accounts with it and choose other accounts that are valuable targets without 2FA?

I think this works a bit like a home alarm system sign. Just the sign itself in your front lawn will deter burglars from even trying to get into your home because of how much more difficult it looks like it will be.

In a similar sense, having this achievement acts like the sign: if an attacker saw this they might not even try to get into this account because it's increased perceived difficulty.

Does this increase the likelihood of another account being targeted?

I'd say yes since the pool of potential targets just became smaller, any individual in that pool has an increased chance to be a target

What can those without the achievement do to reduce their chance of being attacked?

Put up a home security sign (Enable two factor authentication!)

Summary: It doesn't undermine two factor authentication but, hopefully, encourages others to follow best practices in securing their accounts.


How to send a string format exploit through socket I'm doing a CTF exercise here:

https://c-wars.acnr.se/download/level2.tgz

There is a docker with the vulnerable service, which I need to found the value of a variable. I was able to do it by the following input:

== Login Service 1.0 ==
Username: %7$s
Password: a
Welcome: ACNR{_SERVICE_FLAG_}

My issue now is that the submission needs to call a function that is going to send this string by a socket, so I guess I need to escape it. I have tried %7$s, but didnt worked.

Submission format can be found at https://c-wars.acnr.se/download/MANUAL.pdf

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdint.h>
#include "gamelib.h"
uint32_t main(uint32_t argc, uint8_t ** argv)
{
svc_init();
svc_set(10000);
svc_writeln("gimme flag");
svc_readuntil('}');
return 0;
}

The solution wasn't related to escaping.

Was required to read the buffer before sending the string.

Here is the full solution:

https://github.com/ramonmedeiros/c-wars/tree/master/level2


How trivial is identifying a Tor user with JavaScript enabled/ 'allow scrips globally'? I was browsing using Tor, with Javascript enabled/ 'allow scripts globally'. I made an automated take-down request for something posted on a website, and the next day went back to check if the item was still there. It was, and irritated, i made the request again, and got an automated 'you have already made this request' type response on the website. Which is wierd because I was using a different Tor circuit than the previous day. So what is happening? Is it:

The website just acknowledging that 'somebody' already made the request?
The website recognising both requests were TOR users?
The website somehow identifying me as me despite TOR (presumably by some JS exploit)

If it's #3 then it must be pretty easy to identify TOR users who have JS enabled, no? Because it was just a random website not one inhabited by black-hat hackers or spooks. well, i assume not lol.

There are several ways to track visitors between sessions which are in no way hindered by TOR:

HTTP cookies (yes, even .onion domains can use cookies like any other domain)
Persistent storage with JavaScript in Localstorage or IndexDB
Persistent storage in plugins like Flash
Browser Fingerprinting, i.e. looking at a combination of browser version, installed plugins, screen resolution, installed fonts and what other information you can get. Each of that by itself might not be enough to identify someone uniquely but can be when you look at the combination of all of it simultaneously.

If you want to avoid getting tracked, you might want to use the TOR Browser provided by the torproject.org. It is a Firefox build with all of the above switched off as far as reasonably possible.


Server->Client distribution security Apologies in advance if this is the wrong SE site for this topic, though it should be a fairly appropriate match.

I am building a video game where one of the features available to users will be online multiplayer. I will be releasing the server software for free (and open source) with the hope that users will be able to run their own modifiable servers for their communities.

Servers may utilize "vanilla" resources freely, however some may opt to add their own resources such as textures and models. What I would like to accomplish is to enable clients to (with explicit user action) download the required assets.

To add a further layer of complexity, some of these assets are available for download publicly, while some are proprietary and only available through the server.

My main concern is the mitigation of malicious files through the distribution software. However, my "saving grace" may be that all the files that are distributed will be .png, .txt, .xml, .yml, and .mdl, and all will be usable in their existing forms without modification.

The files will not be pushed to the client, but rather the client will pull. This will eliminate any issues with the server having access to the client's filesystem, which could really do harm.

Now, for the question part of this:

Besides a large disclaimer letting the user know that it's their problem if something happens, where should my concerns be placed regarding the safety and validity of files?

All communications to and from the server will be encrypted, likely using something similar to the Signal protocol. Additionally, when a server admin uploads a file, I will have the server generate a hash which should allow the client software to verify that the file was not modified in transit, though nothing more.

A mass majority of the files transmitted will be .txt files, which by themselves should hold no inherent danger (to my understanding). Additionally, none of the files are executed. Code on the client's machine will parse the files and discard anything that is not the right format.

I understand that not every concern can be addressed here because the topic is fairly large, though any pointers on any potential issues or anything else to just be generally aware of will be appreciated.

Some stuff:

Part 1/4, the server resources:

  To add a further layer of complexity, some of these assets are
  available for download publicly, while some are proprietary and only
  available through the server.

And how do you prevent that a client downloads it and then takes the file and distributes it freely? Not at all, right. You need to give up on that plan, there's no effective protection.

Part 2/4, the connection:

Signal protocol and some plain hashes of the transmitted data? Don't roll your own... I'm not sure about Signal, but use eg. TLS and you  have everything. Encryption, integrity, authenticity...

Part 3/4, the end points:

Files, ie. byte blobs, don't do damage. Errors in file-reading programs do. And yes, even images and txt files ... it doesn't matter what kind of file: If the program has an error, certain file contents can lead to malicious actions.

What this means for you? Feeding an image to the OS to display it is alright. If the OS has an error, it's neither your fault nor you're in a position to fix it. Same for third-party-libs etc. (altough reporting bugs should be one of your tasks).
But your program is as important. The bug doesn't need to be in the grapics lib, OS etc. . Even if your program just reads the image from the net and passes it on, there could be a bug there (buffer overflow...) which can lead to an exploit.
I can't really tell you not to make bugs, because everyone does, but be aware that each of your own code lines has the potential to become an infection for all users.

And do not, never, not for any reason, trust the other side of the network and/or any previously saved files. Don't rely in the client that the other side is your own server, and vice-versa. Check everything that needs to be checked. Same for saved files: if you load them, run the same checks as for newly received content from the network.

Part 4/4, cheaters:

Again, as server, do not trust the client. This includes information like "I'm client number X" (can be faked, introduce a secure authentication system), "My highscore is XYZ" (haha. Save it server-side and always calculate changes there, without any client input), "I just shot enemy Foo and that killed him" (calculate server-side if there is an enemy foo, what weapon you have, what damage it can do, what health Foo had, where you pointed your weapon, if there's an obstacle between you and foo, if your last shot was too recent to shoot again, etc.etc.), and so on.

The client always lies to the server. And the server to the clients too. All files are evil. And all players are evil too. Keep that in mind, and 90% of the security work is done.


How to combat and prevent a lpcloudsvr302 and bk-coretag.js Virus? I recently came across a computer that was infected with a lpcloudsvr302 and a bk-coretag.js Virus. I did some research about the two Viruses and realized that their is no reliable source that helps users to remove the Viruses. Most of the website's I have come across basically tell users to download Software (A) then download Software (B)..etc.

So if someone can explain how to combat and prevent a lpcloudsvr302 and bk-coretag.js Virus, than that would be greatly appreciated.

Let me use a example of how we combat infections over where i work.

we mostly begin with analyzing, so lets say we found the bk-coretag.js virus, which is classified as an adware or malware virus... an innocent little bugger that annoys mroe then it does harm (if lucky!).

note that these virusses mostly appear through the installation of programs (i.e. when you install a program like CCleaner, it will ask you to "install this totally not obvious crappy adware tool you will never use", its easy to miss that, and click yes too hasty, BAM! you're infected).

these are common, you can remove them by running a virus scan (i prefer Malwarebytes for this task, since its powerfull and trusted: http://www.malwarebytes.org )

after you scanned, remove the program you think its attached to, since it has to come from somewhere (the indentifying is the tricky part).

after that, go to your browser, and reset all the setting for search engines and such, then restart your pc.

if it still occurs, you may have remoed the wrong program, so keep on digging till this works.

how to prevent? simple, when installing, read everything carefully, and WATCH WHAT YOU INSTALL, when installing random programs from the net, search around on google if theyre not "malwareliscious", and always keep your anti-virus up to date, and always a copy of malwarebytes on your PC, which runs nicly next to most anti virusses.


Practical security for an inexperienced database developer? (HIPAA) Hopefully my question isn't too unique to be asked here, but I didn't find anything similar after some searching.

As a relatively inexperienced developer (only one large project excluding this one under my belt) how can I best secure data at rest in MSSQL and in memory?

The server on which this application would run is itself HIPAA compliant to my knowledge (not my responsibility) but I imagine that a client machine would be highly vulnerable from within, and a severe HIPAA violation could cost my family's business dearly. I am in no hurry to finish this project at the cost of quality, as I am trying to help the business succeed, not get criminal charges pressed against them...

If it is too wide-scoped or vague of a question to answer here, I would be happy to get some security reading recommendations aimed at programmers. There is so much conflicting information and disagreement on best practices that a simple google search for a security layman is overwhelming. (If it helps, I'm working in C++ and MSSQL mostly, and limited to Windows environments, and avoiding non- "commercial-free" licensed tools like the plague.)

Any comprehensive solution is going to require depth, i.e. security in layers. Aside from hardening the system, restricting network access, having a substantial logging, auditing, and SIEM approach, you'll want to protect the data within the database as well.

Obviously protect any login information with a strong hashing algorithm like PBKDF2 w/ HMAC/SHA-256 and 100,000+ iterations or bcrypt or scrypt. MD5 or SHA-1 with single iterations is effectively plaintext, even with salting. Bcrypt will take care of the salting problem and the adaptive cost problem as well.

For HIPAA specifically, protecting PII is crucial. For sensitive information that you must be able to recall, strong encryption is a must (AES-128 or 256, using CBC, CTR (with unique nonces), or GCM mode recommended). Proper key management is also critical. Using a DUKPT system or some other transformative key derivation scheme to reduce key overlap or (ideally) an HSM to manage and protect the keys is a strong move in this regard.

For information that is sensitive but not required to be retrievable, but merely searchable, a strong cryptographic hash function (CHF) like SHA-256 (or even better, HMAC/SHA-256) will allow you to do (non-fuzzy) searching against that data in queries while protecting it at rest. This is less common in enterprise environments but for HIPAA concerns it should at least be evaluated against your performance needs.

If you have more specific questions, feel free to comment here. If they're self-contained we can answer inline but larger ones probably merit their own question on the site.

Oh, and never roll your own crypto. There are C# or .NET libraries written by professional cryptographers and cryptography developers to do anything you need. They are audited, updated, and have a high number of eyeballs on them. BouncyCastle is probably the best known.


How to use Unicode encoding for evading XSS filter? Recently, I have come across a reported XSS where the attacker is Unicode encoding the payload in HTTP GET parameters to evade existing XSS filter -

My question is - when does the Server/application convert the Unicode to plain text? Is it upon reading the values of GET parameters? If yes, then why not the filter is able to detect it?

The attack is not working, when the same payload is provided in plaintext.
App is deployed on IIS 7.

Any mitigation strategy for this type of evasion technique will also be appriciated.

UPDATE: https://www.ietf.org/rfc/rfc1738.txt restricts the use of unicode chars as URLs. what are the chances that IIS 7 still accepts unicode chars as part of URL GET values. I have some vulnerable php webapps for testing (DVWA, deployed in WAMP server) which are easily vulnerable to very simple XSS attack vectors like <script>alert(1)</script>. I tried replacing few characters with their Unicode equivalent but that encoded string doesn’t invoke XSS!!!

Use the package AntiXssEncoder of Nuget with:

Install-Package AntiXSS -Version 4.3.0

This Class has diferents encoders for each case in that this values is reflected, for example css, JavaScript, HTML, and URL; Use this methods depend on your case, for example:

In CSS use:
CssEncode("data")
In Javascript use:
JavaScriptStringEncode("data")

This solucion allow validate of major types for bypass the encoding, assurance to \u0027, %27 and much diferents options.

Other way is first normalize and encode the data, this allow validate for example, %u0027, \x00,%00 and change the value to specific language for evading bypass a validation.

https://msdn.microsoft.com/en-us/library/system.web.security.antixss.antixssencoder(v=vs.110).aspx
https://msdn.microsoft.com/es-es/library/ebza6ck1(v=vs.110).aspx

I hope that I help you.


Is the Android screen lock good enough to prevent access to an Android 8 device? I have Android 8 mobile phone and I need to give it for mobile repair center for battery replacement. There is chip car, but there are lot of data in my phone.

What I want to know is it enough having Android Lock Screen? Can repairmen access my data?

Regarding your given information it's kinda hard to answer your question. Since Android 7 File-based Encryption have been supported. It depends on the vendor of the phone if this is activated by default. I googled a bit about your phone (Huawei Mate 10 Lite) and haven't found official information about that. On reddit are some questions which state that this phone needs to use this type of encryption. So if I'm refering to this and the fact that you set a secure password on your phone it is safe to hand the phone over to a repairman.

But note:
If you hand it over, take care that you cannot see traces of your finger on the damaged display. If you see 4 touches at the position of the pinpad it won't be hard to guess your password. So clean the phone before you give it to them.


Is the save button delay in a Firefox download dialog a security feature? What does it protect? When I click to download a file through Firefox, a dialog window appears asking me whether I want to save the file somewhere or open it immediately once downloaded.

The OK button in the dialog window starts disabled, and doesn't enable until the dialog has had focus for around a second. The dialog isn't modal, and if I focus on another window the OK button will disable and again won't re-enable until the window has held focus for a second.

My partner lamented at this design, and asked me why she couldn't just click OK to download immediately - I responded that I've always thought it was a security feature. Now that I think about it however, I'm not certain exactly what behavior it could be preventing. I would have thought that it might prevent some malicious website from downloading a file secretly by forcing the download window to stay open for at least long enough to see whats going on - however it should be possible for a site to download stuff secretly in the background anyway. Regardless I presume most users would have clicked the 'do this automatically from now on' box at some point, and thus be unprotected anyway...

So, is this a security feature? If so what does it protect against?

Yes, it is a security feature, and the purpose of the delay is to prevent attacks based around tricking the user into entering input to skip past the dialog by popping it up unexpectedly when the user is in the middle of inputting multiple key presses or mouse clicks in quick succession. The two examples that are given in this blog post explaining the feature are:

A CAPTCHA that asks the user to type the word only. When they press n, a save dialog is popped up, and then the user will immediately press l and then y, which is the keyboard shortcut for OK on some browsers, unintentionally confirming the download
A webpage that convinces the user to double-click somewhere on screen, positioned so that when the dialog opens after the first click, their mouse pointer is right over the "OK" button, meaning that they immediately confirm it.

By disabling the button for several seconds, the input has no effect.

Mozilla bug report about the issue


Test STARTTLS configuration of SMTP server Is there an easy way to test an SMTP server to check for configuration issues associated with STARTTLS encryption, and report on whether it has been configured properly so that email will be encrypted using STARTTLS?

Think of the Qualys SSL server tester as an analogy: it is a great tool to quickly check a webserver to see use of SSL has been properly configured, and identify opportunities for improving the configuration to provide stronger encryption.  It knows how to recognize many common configuration errors and gives a grade.  Is there anything like that for STARTTLS on SMTP servers?

In particular, given a SMTP server, I would like to tell:

whether it supports STARTTLS,
whether its STARTTLS configuration has been set up properly so that email with other major email providers will end up being encrypted,
whether it supports perfect forward secrecy and whether it is configured so that the perfect forward secrecy ciphersuites will be used in practice (where possible),
whether it provides a suitable certificate that will pass strict validation checks,
whether it has any other configuration errors.

How can I do this?

Facebook and Google have recently highlighted the state of STARTTLS usage on the Internet and called for server operators to enable STARTTLS and configure it appropriately so that email will be encrypted while in transit.  Are there easy-to-use tools to support this goal?

Here are a several websites that provide tests that you may be interested in.

SSL-Tools is a web-based tool that tests a SMTP server for each of the items you mentioned; it tests for STARTTLS support, a certificate that passes strict validation checks, support for perfect forward secrecy, and other stuff:

https://ssl-tools.net/mailservers
StartTLS is a web-based tool that tests a SMTP server and provides a simple grade, along with many details on the configuration of the SMTP server (though no testing of whether perfect forward secrecy is used):

https://starttls.info/ (see the about page information about the service, or statistics about sites checked with their service)
CheckTLS is a web-based tool provide a way to test a SMTP server for STARTTLS server as well as whether the certificate is "ok" (i.e., it passes strict validation) and partial information on what cipher was negotiated when they connected to that SMTP server (but no information about perfect forward secrecy support):

https://www.checktls.com/
The following web-based tools check whether a SMTP server support STARTTLS, but do not perform any of the other checks mentioned in the question:

https://luxsci.com/extranet/tlschecker.html (see http://luxsci.com/blog/how-to-tell-who-supports-tls-for-email-transmission.html for introduction)
https://mxtoolbox.com/

If you have to check only one or two, try SSL-Tools and StartTLS.


Is there an online public list of generally trusted certificate authorities? Six months ago or so, I thought I saw a reference to a web site that managed a current list of trusted certificate authorities. I can't find the reference any more.

What I'm looking for is an authoritative list of trusted CAs (and their root certificates would be nice) that I could use as a foundation to build a trust store without needing to rely on extracting that information from a browser or whatever. It would be ideal if it highlighted the addition and removal of various CAs on the list over time.

Does that sound familiar to anyone?

There is no generally trusted list of CA certificates, i.e. different browsers and OS might trust different CA. But there is a list of CA's trusted by Mozilla which is used in various other projects too. At CA certificates extracted from Mozilla you can download both the current CA certificates as PEM and also a script to extract the certificates from Mozillas trust store.


Prevent Cross-site WebSocket hijacking with a custom header and no CORS Considering I am vulnerable to Cross-site WebSocket hijacking, so my WebSocket handshake (GET to example.com/wss) does not require a random (CSRF) token.

I have defined no CORS settings, so no custom headers can be added to cross-site requests.

Would it theoretically be enough to add a static custom request header, that is required for the WebSocket handshake to prevent a Cross-site WebSocket hijacking?

RFC 6455 says:

  Servers that are not intended to process input from any web page but
  only for certain sites SHOULD verify the |Origin| field is an origin
  they expect. If the origin indicated is unacceptable to the server,
  then it SHOULD respond to the WebSocket handshake with a reply
  containing HTTP 403 Forbidden status code.

and

  The |Origin| header field [RFC6454] is used to protect against
  unauthorized cross-origin use of a WebSocket server by scripts using
  the WebSocket API in a web browser.  The server is informed of the
  script origin generating the WebSocket connection request.  If the
  server does not wish to accept connections from this origin, it can
  choose to reject the connection by sending an appropriate HTTP error
  code.  This header field is sent by browser clients; for non-browser
  clients, this header field may be sent if it makes sense in the
  context of those clients.

The simplest fix is to check the HTTP origin header on the server side against a whitelist. Your library/framework may already provide secure defaults (no CORS) or have a way to configure this without requiring you to reinvent the wheel.

Since you do not expect any CORS requests, then you should verify that the HTTP origin header matches the URI of your website. According to the RFC, websocket upgrade requests should include this origin header. I confirmed on my own webapp that the header is sent even for the same origin.


RSA encryption : How to create ".arm" certificate file for Public key? I am required to store a certificate as ".arm" file only for a  public key that is intended for use in RSA Encryption.
I am currently able to generate the public key as ".key" file.

P.S I am new to encryption so, this may be a basic question.

Neither .arm nor .key are standard extensions. You should be more specific on who/what generated .key files and who/what is going to use .arm files.

I can only guess .arm refers to "ASCII armor" which is an old PGP jargon for Base64, a format where only 7-bit ASCII characters are used.

The PEM format is exactly that. Assuming .key files are DER encoded (binary), try to use openssl to covert your certificate to PEM format:

openssl x509 -inform der -in certificate.key -out certificate.arm


IIS FTPS Best Practise I have the task to place an FTP server in the company DMZ for our partners to store sensitive data that can not be sent by mail.

I have chosen the IIS FTPS. I will generate a self-signed certificate for server authentication. Also, I was planning to configure client certificate authentication.

I will open Implicit FTPS port 990 with source Any. Is there something that I can do to harden the FTP server, because source will be Any? What would be the best practice? Also is it smart to leave port 990 open, with source Any?

You should not worry about the source being Any. It is the common way for public server side protocols like FTP or HTTPS. Simply you should ensure that only the expected server(s) is (are) reachable on their open ports.

But FTP is an old protocol that was invented when firewalls and encryption were not used. It uses one TCP connection for the command stream, and a distinct one per file transfer. In the sendport mode, the data connection is initiated by the server form a well-known port (20 for FTP, 989 for implicit FTPS). That means that is is nice for your own firewall, but will cause headaches to your partners firewall admins: they will have to open input connection on their firewall to random ports...

The passive mode in a little more client firewall friendly, because the client will open the data connection. But only a little more, because the server will listen on a (quasi) random port and no longer on a well known one. And the nightmare is for the server side firewall: a legitimate connection coming from a random port and reaching a random port! In non encrypted FTP mode, the firewall was spying on the command connection to know the data ports, but no way if the command channel is encrypted...

This is one of the reason why FTPS is only seldom used, despite being a very robust protocol.


Is it safe to serve any user uploaded file under only white-listed MIME content types? Let's say I develop an application that,

Allows any user to upload a file of only white listed mime content type and extensions (word and pdf).
Serves those files with the allowed extension and content type.

Is this a security risk?  Why?

Will any browsers infer the content type from the file bytes (using magic headers) and discard the content type I am specifying in the headers?

What is the solution to make this secure?  Should I assert the files being uploaded have magic bytes matching the client provided mime type?

I know this question is similar to Is it safe to store and replay user-provided mime types?  , but  don't think it is a duplicate.

HTML content-sniffing, as outlined by Krzysztof; primarily but not exclusively IE.
jar: URL vulnerability in older Firefox
Content resembling a JAR file (GIFAR et al) - hosting something that could be interpreted as a Java archive implies XSS because of the different Same Origin Policy enforced by Java.
A file containing something that looks a bit like crossdomain.xml content can be targeted by loadPolicyFile call to get XSS for a Flash caller.

  Should I assert the files being uploaded have magic bytes matching the client provided mime type?

Insufficient against chameleons (files equally valid as either type).

  What is the solution to make this secure?

The only strong mitigation is to serve your untrusted uploaded content from a different hostname from your main site.

That different hostname can be a subdomain of your main site if you are only worried about direct JavaScript XSS/Same Origin Policy.
It must be a disjoint subdomain if you need to prevent it from reading cookies (such as session IDs). That is, it can be insecure.example.com if you have your main site on www.example.com, but in that case you must not also allow your site to respond on bare ‘example.com’. example.com cookies can't be prevented from inheriting into insecure.example.com on IE. Best practice: redirect all access to example.com to www.example.com.
It must be a completely different domain if you need to prevent cookie forcing: that is, insecure.example.com can write a cookie that will be read by www.example.com, potentially overriding cookies set by www.example.com. This is a less severe vulnerability: the ability to read the cookies typically leads to session hijacking, whereas cookie forcing leads only to denial of service (as www.example.com won't work without its cookies).
It must also be served on a different IP address, if you are concerned with a preventing cookie-stealing using a vulnerability in older Java plugins, or if you have other services running on ports which you would not want applets to be able to access.

Between them, browsers and plugins have made hosting uploaded files securely a terrible ordeal.


In what ways is Git a security measure? When the boss asks why Git is good, can I justify using security as one of the reasons?

Under Git, it's easy to track changes. Maliciously altered files can be revealed with a simple 'git diff' on the command line.

Even if attackers were able to do their own commits and rewrite the commit history, they likely would not be able to push to origin. But even if they could, other remote instances of the git repo would still retain the original history and get errors when they try to push.

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.


A potential CAPTCHA phishing attack against reCAPTCHA? In reCAPTCHA's API (without plugin), the key part is

 <textarea name="recaptcha_challenge_field" rows="3" cols="40">
 </textarea>
 <input type="hidden" name="recaptcha_response_field"
     value="manual_challenge">

The website embedding this API actually asks the user to retrieve a iframe from reCAPTCHA using a public key. Suppose stackexchange is using reCAPTCHA and it has a public key A. And I want to attack stackexchange by circumventing its CAPTCHA.

Suppose I have a website that has some legitimate users. I can embed a reCAPTCHA API in my website that using public key A, which is stackexchange's reCAPTCHA public key. Now after the users of mine solve the CAPTCHA, they will submit a CAPTCHA challenge id and solution to my website. After that, I can submit the same challenge id and solution to stackexchange using a automated script. Then I successfully bypass the CAPTCHA challenge of stackexchange.

I am not sure whether this attack is practical or not. Suppose the browser of my users do not fill the HTTP referrer field in the request to reCAPTCHA, which prevents reCAPTCHA knowing that my website is actually using stackexchange's public key.

It seems that no one is going to answer this question.

According to my experiment, Google uses HTTP referer to limit the usage of reCAPTCHA public. When register a new reCAPTCHA account, Google will ask you to type in the site (domain) where you will use the reCAPTCHA public key. Then when a user visits your website and is sending request to reCAPTCHA to retrieve the CAPTCHA image, his browser will put the domain of the website he is visiting into the HTTP referer field. Then reCAPTCHA will know whether the domain of the website that is using the public key is the same to the domain which owns the public key. If not, reCAPTCHA will issue a warning in the browser.


Client-side encryption, but cloud service can still decrypt data in the event of a death? Is this possible? I've been worried about this password manager, PasswordBox that seems to be gathering quite a bit of steam lately.

They seem to have raised VC funding and are offering a free password management and storage tool. Their team does not seem to have extensive crypto experience.

What really worries me is that their Security page mentions:

  All of your sensitive data is encrypted and decrypted on your computer by a master password > that only you know. This master password is NOT stored on our servers, so your secure data > can't be retrieved by anyone but you.

Meanwhile, their features page mentions that they can provide access to passwords to loved ones after a user dies (provided they have a death certificate). Detailed flow here

How can the key used to encrypt password data only be stored on the client and still allow a third party service the ability to decrypt the data in the event of a death. Why should anyone trust these guys?

Update:

PasswordBox responded to my inquiry on the subject. Personally, I couldn't really figure out what they're talking about. It could be a problem in my understanding. Below is a screenshot of their reply

This is a very interesting question. PasswordBox seem claim that they can never have access to your passwords. According to their FAQ page:

  PasswordBox servers will NEVER see your decrypted data

  PasswordBox never sees or stores your Master Password, so we can never
  gain access to your data

The only left possibility (that I can think of) is that half of the key might be stored in the client and other half is on their servers. So they truly cannot access your data, and when you request access to a loved one's account they have a way to send half of the key from their server to client (on the deceased person's computer or mobile) and thus the decrypted data is only on the client itself.

Please note that when I say "half of the key" it's because of my lack of knowledge in cryptography. There could be some way where two parties can share two parts of a key in a way that two parts are needed actually access the secret.

Update: Thanks to @DeerHunter's comment, it seems that there is indeed such a scheme, it's called Shamir's Secret Sharing Scheme. I've just downloaded the implementation and played with it a little. To me (again, very shallow cryptography knowledge) it seems like it could be a good candidate for the problem proposed in your question. You can try it for yourself.

SSSS-split(shares, threshold, secret)
SSSS-split(2, 2, "YOUR_KEY")

Shares = 2 (a piece for you, and a piece of the service)
Threshold = 2 (at least two of pieces are needed to recover the secret, here it means all the pieces)

Note: All of the answers (including this one) are just speculations. We still don't really know what is going on because PasswordBox aren't sharing much technical details. Lucas and I have already sent emails to PasswordBox and we're waiting for an answer. Once we receive a reply, the answers will be updated accordingly.


Will prepending random data (of random length) result in more secure communication? Many files begin with a "well-known" header sequence which I imagine helps a lot in performing cryptanalysis over a huge number of data transfers.

So I have the thought of prepending a block or two of random data to make cryptanalysis more difficult.

Let's say that the file is like this:

<Header 250 bytes><Contents>

So we prepend some random data (of random length) like this:

<Random data of random length><Magic Number><Header 250 bytes><Contents>

The receiving side, after decrypting, simply scans for <Magic Number> and snips everything up to that point.

Since the length is random, the attacker won't be able to guess where exactly the well-known parts will be.

Do you think this is a good idea? Or too much effort for not enough improvement?

No, this won't provide any improvement for encryption with any decent cipher. If a cipher is so bad that a known-plaintext attack is capable of fatally breaking it, then the cipher is worthless. A known-plaintext attack is one where an attacker has knowledge of plaintext/ciphertext pairs and, from that knowledge, is able to either calculate the key or otherwise perform decryption operations on arbitrary ciphertext.

If you want to make decryption via brute force or dictionary attacks harder, you should use a KDF like Argon2 that runs the user-specified password through a computation-intensive and memory-intensive calculation before it is fed to the cipher. If you want to make cryptanalysis of the cipher more difficult, all you need to do is use a cryptography library that selects a secure cipher for you, like AES or ChaCha.


HTTPS Everywhere (Firefox) allows mixed content on pages with images I use HTTPS Everywhere extension for Firefox, and recently I've started witnessing Mixed Content warnings from time to time, apparently when there are images with http:// prefixes (in particular at SE sites, on pages with imgur-links).
As I've learned, HTTPS Everywhere should deal exactly with those kind of things by changing prefixes to https.

I've also created a new profile to install only HTTPS Everywhere (to test 'some conflict between extensions' hypothesis), but it still gives the warning with similar circumstances.

What could be the problem and what should I do with it?

(software versions: Firefox 44.0.2; HTTPS-Everywhere 5.1.4)

(Originally I've posted this question on meta, but was suggested to ask this question here.)

HTTPS everywhere relies on a ruleset that determines which domains support HTTPS. The ruleset can be searched here, and I suspect if you search for the domains which host the insecure images they won't be there.

To some degree the problem you describe is expected, because if the site was fully compatible with HTTPS then presumably the website owner would send traffic to the HTTPS version without the need for HTTPS everywhere.

Despite this limitation, there is probably still value in using HTTPS everywhere. The most sensitive data is usually the page/document itself and the JavaScript so if they can be encrypted you'll receive most of the benefits of HTTPS.


PCI Compliant Secure Vault Design and Implementation I often see the phrase “Secure Vault” in PCI DSS documentations and I want to know if a “Secure Vault” must be a highly protected file with sophisticated technologies stored on a very secure hardware or simply it can be a database behind multiple layers of standard security mechanisms.

I mean if we want a high level of scalability could it be a database? Is there any standard for designing and implementing a “Secure Vault”? What are best practices for design and implementation?

Unfortunately I couldn’t find any handy documentation other than commercial datasheets of available products.

Any help appreciated.

"Secure Vault" is being used here in the context of tokenization, which almost always means "the Vault that someone else (e.g., your payment processor) keeps the cards in, and you only ever deal with the tokens that correspond to items in the vault."

You can, of course, implement a "vault" yourself - that means a data store for PAN data which meets all the criterion of the PCI DSS such as encryption, authentication, access control, logging, etc. etc.  Read the DSS, implement what it says, and do it well enough to pass an audit - voila, you're done!

But, again, "vault" is used to identify the data store backing tokens.  If you're storing cards in your vault right next to the system where you're storing and using the tokens, you haven't gained anything; you still have to do all the work of protecting the PAN data.  If you're not using tokens, it's not a vault, it's just a database with PAN data in PCI scope and subject to the DSS.

The purpose of tokenization is to limit the burden of the DSS.  If your processor stores the PAN data, and only gives you the tokens, then you do not need to store and maintain them to the same level of compliance that you would have to if you stored the PAN data.  "Vault" is just a term that describes this separation between the sensitive storage tier and the end-user (you, the merchant) tier (that is, the tokens).


Can android application be repacked with original developer's signature? I am researching on Android application repackaging. I know the original developer self-signs the APK. Is it possible for a hacker to fake the signature and make it appear as the original signature when repackaging?

If you have access to the developer's private key, you can just sign the modified APK with their key and be done. If you don't, you won't be able to.

To create APK signatures, RSA and DSA is used. You won't get through them. However, this means nothing if you can find a hash collision because what's verified by a signature is not the message (which is the program along all its data in this case) but the hash of the message. It's possible to change the message and leave space for a part you don't care about and then to just iterate through the possible values of that field you created, hash the new message, move on to the next iteration if the hash isn't equal to the original hash, and stop and remember the modified message once the hash of it is the same as the original one.

The default hash for APKs is sha1. sha1 is weak. But not weak enough for anyone to find a second message with the same sha1 hash anytime soon. Furthermore, developers can use stronger hash functions than sha1 so finding a fitting second message becomes even more unlikely.


Is this a secure way to connect with Tor? I was discussing the use of tor with a friend, and he happened to suggest a way to remain secure when using applications on the terminal (Lynx, Nmap etc.)

His suggestion was this:

ssh-keygen -b 4096
ssh -D 8008 user@127.0.0.1

And also add Socks4Proxy 127.0.0.1:8008 to /etc/tor/torrc

I understand what the SSH commands are. But why is this more secure than using something like

proxychains iceweasel www.google.com

... (replace iceweasel with whatever app you want), Proxychains is set up to use tor automatically, I also change static to dynamic.

Could someone explain if this is secure, and why?

No, it doesn't provide any additional security, and I don't see the point of your friend for suggesting that.

ssh -D 8008 user@127.0.0.1

Connects to your local machine creating a SOCKS proxy on 8008 (the ssh-keygen -b 4096 above is only needed once, and is used for not requesting a passphrase from you)

  And also add Socks4Proxy 127.0.0.1:8008 to /etc/tor/torrc

This makes tor exit through the proxy socks on 8008… which is the same as your own machine, so you gain nothing.

And you additionally need to configure the proxy (either with proxychains or local program configuration) on any application you want to use.

I see two possibilities:

* Your friend got confused and somehow thought that the proxy went in the opposite direction (ie. that it was ssh what connected through the proxy, and that tor listened on `Socks4Proxy` instead of connecting there)
* That instead of `127.0.0.1` (which always refers to your own computer) he meant connecting to a different host (you need a ssh account there). In that case tor would be connecting from that machine ip (as if tor client was running there). That would add one hop if someone «broke tor», although it's possible that you would be as easily found,  by looking which account started those connections.


Does setting a firmware password add security if FileVault 2 is enabled? On an up-to-date OS X computer with FileVault 2 (whole-disk encryption, minus the recovery partition), is any security gained by setting a firmware password, as well?

The firmware password adds very little value to the protection of your device. There have already been published loopholes for either:

Resetting the firmware password
Nullifying it completely

On several versions of the Mac OS. The FileVault encryption will be sufficient for protecting your information.


How to check if Android application is vulnerable to heartbleed I Am trying to find if an android application is vulnerable to heartbleed vulnerability.  I want to know how to check if the application is vulnerable to heartbleed by reversing the app file.

Heartbleed is primarily a server-side vulnerability and not in the client. You, of course, cannot detect the server-side problem from examining the client-side code. Even if the client has very old SSL code, you don't know what the server is running.

You can test the server for heartbleed at https://filippo.io/Heartbleed/.

Heartbleed on the client will occur if the client is using a pre-fixed version of OpenSSL. The client vulnerability could only be exploited by a server that the client has contacted. That is, a server cannot find your client by snooping the network or anything of the sort. The client must initiate the contact.

A successful exploit will allow the server to read the process memory of the client. (Reading memory with Heartbleed is tricky and it may not be possible to read all of the process's memory, but let's ignore that.)

(Thanks to @StackzOfZtuff for helping with this edit)


Server side SSH keys compromised I'm interested in knowing what could be the consequence if the server side SSH keys of a host were compromised.

The situation would be:

An attacker manages to read the SSH private keys of the server.
The attacker can MITM any connection to the host (because he's controlling the router, or w/e).

Does that mean that any data going trough any SSH connection can now be read by the attacker? I would say no because of some key exchange algorithms like Diffie-Hellman. Is that correct?

My guess would be that the worst an attacker could perform is impersonating the server, leading users to log into his system instead of the legit one.

Due to the use of the Diffie-Hellman key exchange, knowing the server's private key does not help a passive-only attacker. If the attacker wants to learn the data, then he must go active.

If the attacker knows the server private key, then he can impersonate the server, i.e. run a fake server and let users connect to it. For a full Man-in-the-Middle attack, the attacker must do a double impersonation: as a fake server when talking to the genuine client, and as a fake client when talking to the genuine server. If the server uses password-based authentication, then this is easy: the client will send his password to the fake server, at which point the attacker knows it and uses it. If the server expects a key-based authentication from the client, this won't work.

However, chances are that a fake server (non-MitM) can fool a client and learn secrets without going full MitM.


Using a VPN but Akamai Technologies still registers where my computer is? While browsing the Internet I realized I could access US websites from within the US using the VPN service Private Internet Access (PIA).

I tried accessing http://www.cc.com/ to see what would happen.

To my surprise I got to the website but was connected to an address in the Netherlands (https://www.tcpiputils.com/browse/ip-address/23.212.232.117). Even on the PIA forms it shows that I am connected to an address in the Netherlands (https://www.tcpiputils.com/browse/ip-address/23.214.61.105). Duck duck go connects to Ireland (https://www.tcpiputils.com/browse/ip-address/46.51.197.89).

Why are these connections registering my Geolocation (they realize my computer originates in the EU)? I thought PIA provided a secure connection to a remote server but this clearly shows that my connection to that server is being intercepted somehow.

Any help with an explanation would be greatly appreciated!

EDIT: After doing some digging it seems like Akamai Technologies (https://en.m.wikipedia.org/wiki/Akamai_Technologies) is circumnavigating the PIA VPN network. Some how it is still registering that my account is in the EU (and is delivering services from closer servers, like the Netherlands).

I still need clarification as to why this is happening. I thought the VPN encryption would prevent people from intercepting traffic?

The issue was due to DNS leakage.

To fix the problem I needed to find my VPN's DNS server. After that I had to set my network adapter to query DNS from that server.

The problem was fixed, akamai technologies no longer server up web addresses.


How did my exact name + birthday end up in PwnedPassword lists? I find my exact name + birthday in the form of FirstnameMiddlenameSurnameDayMonthYear, e.g. JamesWilliamMiller31052000
in the PwnedPasswords List.

But I have a very uncommon Surname (<100 people) and I am absolutely sure nobody has the exact combination of first name, middle name and surname

It gets even weirder because JamesWilliamMiller31052001, JamesWilliamMiller31052002, JamesWilliamMiller31052003, etc... all exist in that list, too. (Which rules out that my parents once have used this as their password)

How come that? Has that Password (I do NOT use this password, I just got curios what I could find in that list) actually ever been leaked?

Edit: My bad I modified the script doing the server request and broke it as I didn't go to check the validity of my programm again.
It gave back a count of 1 whenever it should be 0

Very interesting. My guess is that someone was trying to brute-force one of your accounts, so those attempts ended up in their personal cracking dictionaries, which got sold to get incorporated into a bigger list, which got sold ..., and eventually it ended up in the HaveIBeenPwned list.


Is is possible to avoid internal seeding of a RNG and seed the generator manually using OpenSSL's RAND_bytes()? I'm trying to write a random number generator with the OpenSSL library. The provided RAND_bytes() function is self-seeding with the /dev/urandom. That's why I am only able to reseed with the RAND_seed() function. So if I am seeding the generator, it will always be a combination of the internal and my own seeding.

Is there a possibility to avoid the initial seeding, so I can manually seed the RNG without any internal seeding taking place?

I want to avoid internal seeding and seed the RNG manually, because I try to write a cryptographically weak random number generator, for testing purpose.

Come to think of it, you could implement an engine with a weak RNG and insert it into OpenSSL using:

ENGINE_set_default(e, ENGINE_METHOD_RAND);

That should make sure that the random number generator is used. Of course it may be a good idea to ignore any seed information given to the random RNG by the OpenSSL.

This has the obvious disadvantage that it may be hard to find out when the random number generator is used for which function though. But I don't see how this couldn't work otherwise.


Should the MEID, PESN, IMEI1 and IMEI2 numbers be kept secret? On my Huawei PLK-AL10, when I type *#06# in the dialer, a window named MEID_IMEI would pop up and display some random strings. Note that someone can get this information through the "Emergency call" interface, without having to know the lock screen password.

I'm told that only mobile phones manufactured by Huawei show the MEID, PESN, IMEI1 and IMEI2 information if someone tries to dial *#06# using the emergency call dialer. Could this be a security risk?

There is no real security risk.

Those numbers displayed each represent a serial number of a certain piece of hardware. Cellular networks mostly use IMEI to track a stolen phone and put it on a blacklist.
There for no attack is exposed unless someone would get your IMEI and add it to a blacklist (very unlikely).

What you should worry about is your phone that is being accessed by someone else so take good care of that!


How is there a preview for a fake docx file in gmail I recently got a nasty email containing two files.  I didn't open them but did check and realised they were not docx files which was the intent but on gmail in the document preview it shows what looks to be word documents.  Is this a security flaw in the preview system for gmail.  Attached is an image

(https://i.stack.imgur.com/P9b69.png)

Most probably, those attachments aren’t attachments—they’re embedded images designed to look like attachments that link out to a fake Google sign-in page.

Below is a screenshot of gmail phishing attack where the attachment is not a pdf file but an image:


Port-forwarding to a web server on Raspberry Pi I've recently created a relatively simple smart Christmas tree which is a Raspberry PI Zero W powered LED strip.

In order to control it via IFTTT webhooks, I've started a lightweight flask server on the Raspberry Pi - on a specific port with several endpoints for different animations/patterns. Then, on the home router, I've configured port-forwarding to the flask server started on the Raspberry Pi.

Currently, the flask API is completely open, - though, one, in order to use it, would need to know the IP address and the port values.

The risks in terms of security in this particular case are, of course, minimal, but what are the general ways to improve the security of this home automation setup? Should I go for a full-fledged web server like Apache?

I was thinking to at least require a "secret" key in a cookie, which the IFTTT recipes and the flask server would only know. Since the resources of the device are limited, I guess, performance & security need to be carefully balanced.

The problem is less the open access to a server with some unimportant task. The problem is more that this server is probably located in the same network as more important systems (unless your home router provides network separation, most don't). Thus if an attacker manages to hack into this unimportant server he gets access to your whole important network.

There are several ways to make this harder:

If your home router provides network separation put this server into a network separate from the rest of your system. There are many information online about this.
Limit access to the server by requiring some kind of authentication. This could be plain text authentication with username and password, some secret authentication token or client certificates if HTTPS is used. What you use here depends a lot on how do you need to access the server (web browser from any system, web browser from specific system, mobile app...). In case of IFTTT see here for the possibilities you have.
Make sure that nobody can sniff the traffic and thus capture any plain text authentication or modify the traffic by using HTTPS.
Even if the attacker gets authenticated access to the API make sure he cannot exploit it further by using good programming practices and hardening the setup as described in the following.
No direct invocation of shell commands with arbitrary user controlled parameters, i.e. limit the parameters to specific values in the server (don't trust the client) or sanitize parameters if arbitrary values should be possible.
Don't run the server as root but run it as a user with low privileges. If you need to have root permissions to control the hardware write a separate local service with a small and secured API and let it communicate with your externally reachable web service (see privilege separation).
Ideally add some additional sandboxing, i.e. use containers, chroot, seccomp etc to make it hard to break out of the server. For example containers can also be used to limit network access, so that the attacker cannot access the internal network even when successfully breaking into the web service.
Harden you OS by having only minimal software installed and by keeping this software and kernel up-to-date. Privilege escalation attacks are unfortunately still common in Linux so once the attacker has low-privilege access by breaking into the web service he might be able to get root. Keeping the system up-to-date makes this much harder.


What makes servers vulnerable to Return Of Bleichenbacher's Oracle Threat (ROBOT) attack? Is server vulnerable if it supports RSA key exchange ciphers?
Can server be still vulnerable if it is running on unpatched vendor software but does not support RSA key exchange ciphers?
After applying vendor patches, Should RSA key exchange ciphers also needs to be disabled?
How to mitigate ROBOT (Return Of Bleichenbacher's Oracle Threat) vulnerability?

The server is vulnerable to Return Of Bleichenbacher's Oracle Threat (ROBOT) only if it is hosted on a vendor software with RSA implementation bug and server supports RSA key exchange ciphers.

See the list of known vulnerable vendors and patches https://robotattack.org/#patches

Note: Not all servers that support RSA key exchange are vulnerable. But it is recommended to disable RSA key exchange ciphers as it does not support forward secrecy.

Robot vulnerability Severity:

For hosts that are vulnerable and support only RSA encryption key exchanges, it's severe vulnerability. An attacker can passively record traffic and decrypt it later.

Mitigation steps:

Ideally, following both mitigation steps should be taken.

Update your server; patches are provided by most of the vendors.
If you patch your server your immune to ROBOT vulnerability.

Note: If the patch is not available from your vendor, you can mitigate with 2nd step.

Disable RSA key exchange ciphers (Recommended): But if you want to keep support for RSA key exchange ciphers.
Your server should at least support forward secrecy with modern browsers. (keep RSA ciphers last)

Identifying RSA key exchange ciphers:

SSL Labs uses TLS_* format. So that means all ciphers starting with "TLS_RSA" on the report.
OpenSSL uses the different naming convention. All ciphers with "Kx=RSA"


"Hacking" account when someone uses your email? I have, on multiple occasions, received this email from Twitter:

Since I have received it multiple times either this person clearly thinks the email is theirs or it's spelled similarly, something to that nature.

If I were to confirm the account, and the person were to start using it, wouldn't I essentially have a "backdoor/trojan horse" of sorts where I could simply reset the password and take control of the account whenever I felt like it? What if it were a bank account instead of a Twitter account, it could  have more sinister repercussions.

Other than it being an attack based on pure chance, you can't force someone to try to use your email, is it a viable attack? Is there a term for this kind of attack?

If I were to confirm the account, and the person were to start using it, wouldn't I essentially have a "trojan horse" of sorts where I could simply reset the password and take control of the account whenever I felt like it?

Given that they are not using 2-factor authentication, yes (though I don't think "trojan horse" is the correct term). They would be able to start using the account when it is confirmed, but you would have the ability to reset the password, and then log in as them.


Exploit only works in gdb tl;dr: Why my exploit only works inside gdb.

I'm very new to the buffer overflow and exploit development fields.  To improve my skills based on a serie of papers and videos I wrote this simple C software:

Note: I disabled ASLR

I believe that my question is different than this: Buffer overflow exploit works with gdb but not without because the author seems to have ASRL enabled.

#include <stdio.h>
#include <string.h>

void granted()
{
    printf ("\nAccess granted\n");
    return;
}

int main()
{
    char password[104];
    printf ("Enter your password: ");
    gets(password);

    if (strcmp(password,"p@$$w0rd"))
    {
        printf("\nFailed!!");
    }
    else
    {
        granted();
    }

}

As far as I know there is a little bug: it is possible to enter much more than 103 chars.

My first exploit objectives were to redirect the execution flow to the granted function.

To generate the exploit, I used the following command python -c 'print "A"*100+"\x9b\x84\x04\x08"+"BBBB"' > payload-access-granted

me@computer:~$ gdb bof3.bin
(gdb) r < payload-access-granted
Starting program: /home/me/bof3.bin < payload-access-granted
Enter your password:
Failed!!
Access granted

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

As you can see the payload did what was expected: Jumped to the granted function. Exploit is working...but

Outside gdb:

me@computer:~$ ./bof3.bin < payload-access-granted
Enter your password:
Segmentation fault (core dumped)

So, why does this occur? What didn't I do correctly?

Most likely, it is working, but the program crashes with the Access Granted printf not having been flushed to the screen.  Crashing on SIGSEGV does not cause buffers to be flushed.  Add fflush(stdout); after the printf call in granted, and you'll likely get your desired behavior.


Hashing password multiple times with different random salts I have read a lot of answers about this topic like:

https://softwareengineering.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times.
https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once
https://stackoverflow.com/questions/3786323/multiple-password-hash

None of these seem to talk about hashing multiple times with different salts.

Is this method of hashing:

hash(hash(hash(pass+salt1)+salt2)+salt3)

more secure than:

hash(hash(hash(pass+salt1)+salt1)+salt1)

where salt1,salt2,salt3 are different random salts, and the same hash function is used each time?

The three methods you show are all weak; three hash function invocations will not do much good, in a context where salts matter (you use salts because you envision an attacker would could, at some point, get a glimpse of the hash values; and, in that case, you need the function to be a lot slower than that). In any case, homemade assemblies of cryptographic primitives rarely achieve decent security.

To answer your explicit question: the value of salt is that they are not reused. In your first proposal, the "salt" is really the concatenation of three distinct sub-salts (that you call "salt1", "salt2" and "salt3"). In the second proposal, the same mechanism is used, but the three sub-salts are identical, which is a reduction of the space of possible salts. On the one hand, a shorter space increases the probability of reuse. On the other hand, reuse of some of the sub-salts still allows for some shortcuts on the attacker side.

Anyway, it is pretty hard to assess the differences in security of two hashing methods when they are both weak. Do yourself a favour: use a real, decent, well-designed and reviewed password hashing function. In practice, this means bcrypt. And read this answer.


Unencrypted FTP to transfer encrypted data - okay if IP-restricted? If unencrypted FTP over the public internet is the only file transfer option for a particular situation, what security concerns are applicable assuming:

The data being transferred is strongly encrypted by whatever / whoever is creating the files
IP-restriction is in place at the firewall level so only one designated IP can connect via FTP
There is protection in place on the FTP server against file deletion (though not overwriting)
The credentials aren't valid for any other services (e.g. SSH access)

If someone sniffs the username and password, could they even do anything with it?  I don't really understand what's possible with IP spoofing, but I'm thinking the only case where they could issue FTP commands with the credentials is if they had a privileged position somewhere along the network route and were able to spoof the IP that normally connects in via FTP - like a man in the middle type of attack though I'm guessing they could initiate it at will.

Of course if VPN / SSH port forward / etc. were options, those could be preferable, but I'm wondering about this particular situation.

It's hard to say what your definition of "OK" is, but generally, I'd say, no, you're not ok with your current setup. I'll cover your points individually.

The data being transferred is strongly encrypted. This is good. In other words, you could put the file with a download link up on a public website. If you trust the encryption, then your data is reasonably safe. However, if your data has tremendous value that would be worth spending time and money to decrypt, then people will try. Even with the best encryption methods, having many people trying to break it is not ideal. But it will soon become clear why I mention this as an alternative to FTP.
IP-restriction is in place at the firewall level. This is good. This means that even if your data is worth attempting to decrypt, it will not be possible unless you can pull off a MITM attack or somehow else get on the wire. This adds protection.
There is protection in place on the FTP server against file deletion (though not overwriting). This is where you went wrong. Plain Text FTP is fine, until you allow any sort of editing at all- and you said you can overwrite the file. Now you are worse off than if you didn't use FTP in the first place. You'd be better off with the public download link- at least no one can blow away your data.
The credentials aren't valid for any other services. That's a good thing, because you should treat the plain text ftp as if the credentials are public knowledge.

tldr; Remove the edit rights on the ftp user and then I'd say you're ok, even though your setup is strange. (And by strange I mean, why have all the protections and then use plain text ftp?)

To answer your other specific question- if someone sniffs the username and password, AND if they can get on the wire (but they already are if they're sniffing!), then they can replace your encrypted file with a different one. It sure would be a bad day if your important data was one day replaced with a text file that simply says, "F Society".


Arbitrary query parameter reflected in server response header. Is it exploitable? SCENARIO:
If I send requests like these:
http://site.com/page?safe_param=1?my_arbitrary_param=2

The server responds with a normal HTTP response but within common headers it includes also the arbitrary param:
[...]
my_arbitrary_param: 2
[...]

How could be this leveraged?

This may be a real problem.
By definition the HTTP response Headers are usually trusted. In a context with some reverse proxy caches between you (the browser) and the 'faulty' server you may be able to do bad things on the reverse proxy caches (or http load balancers, ssl terminators, etc.).
You may be able to generate cookies from this server with GET arguments (like &set-cookie=phpsessid=something;httpOnly=false;SameSite=none).  But that's maybe not the biggest problem.
You should look at the behavior on existing headers. If there is a Content-Length header on the classical response, what happens when you add a &content-length=0 argument on you query (or another size). Is this header added, is it replacing the existing one?
What happens if the response is chunked (Transfer-Encoding: chunked) and you add a Content-length header on this response? Or the contrary.
This could become even more fun if you have a way of uploading files on the server. Because you could control the body of the response. You could add http responses in that body, enter the HTTP Response Splitting issues (HTTP Smuggling).
You could play with partial-Content queries (hide html in parts of uploaded images, in EXIF zones), forge stranges responses, try to alter any header related to the message size (transfer-encoding, content-length) or the mime type.
So, in terms of cache poisoning or http Desync it could be a real issue.
HTTP response headers should not be controlled by the client, the protocol is not made for that. Just look at all issues coming from CRLF injections, here you have the same vector (control over http headers in the response) but you do not even need to inject CRLF characters (but in CRLF injection you can inject the double CRLFCRLF to start the body here you cannot).


How malicious 3rd party toolbars on IE could be? How dangerous for the user such 3rd party search/ad Internet Explorer toolbars are?

Are they able to transmit information regarding my Internet surfing behaviour back to their developers even when I don't interact with them?
Are they able to modify my page results and maliciously implement Cross-Site Scripting stealing for example credit card or social security numbers?
Are they able to access information beyond the browser (files, list applications, network configuration information?

Are they able to modify my page results and maliciously implement
  Cross-Site Scripting stealing for example credit card or social
  security numbers?

Yes. Such malicious extensions have always been developed. I think one of the best example we can mention is the notorious ZombieBrowserPack which is an opensource project develop first as a POC by Zoltan Balazs and which targets various the most used browsers (Chrome, Firefox and IE). This plugin can be manipulated remotely to steal authentication credentials and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google, or simply hijack your Facebook account.

  Are they able to access information beyond the browser (files, list
  applications, network configuration information?

Yes. The same extension we just mentioned is able   take screenshots using your machine's webcam, and not only can be used to mainuplate your files but also download other malicious files to execute them on the machine's victim.

  Are they able to transmit information regarding my Internet surfing
  behaviour back to their developers even when I don't interact with
  them?

Yes. Actually this plugin behaves as an HTTP proxy  allowing an attacker to communicate with a server on the victim's internal network without any interactions required to be performed by the victim.

In the beginning, such extensions were used by attackers for click fraud  by, for example, hijacking search queries; but the short and very rich history of the Web shows teaches us a long list of extensions developed to fulfill a targeted goals . Just to give you an example:

  Through the analysis of more than 48,000 extensions from the Google
  Chrome web store, the group of researchers was able to detect 130
  malicious extensions, including one with 5.5 million affected users.

Nowadays, you do not need only to use a malicious extension to be a victim of one of the scenarii you mentioned, but a simple visit to a given compromised webpage could lead to a drive-by download attack by exploiting your browser's vulnerabilities which are more frequently carried on by the extensions you install leading to spyware and adware (in the less dramatic cases) to infect your machine as it happened with visitors of Amnesty International's homepage on 2011 of which many users became victims.

So before making the decision to install any plugin to your browser, you need to be careful by checking the permissions requested by its developers, and when you visit a webpage prompting you a message to install a plugin to be able to view its content then do not hurry to follow the instructions (for example if you have already the Flash plugin installed and the page asks you to install it then this is likely to be a drive-by download attack requiring the user's interaction). And as a general safety practice, never install a plugin unless useful and install as few as possible of them and verify if you can the behavior and source code of your extensions from time to time as it is done here.


One time password with Hardware Token I am researching software authentication methods that are easy yet secure to implement in my own projects.

IDEAS: Steps to authenticate apps

The application is running from a USB drive as it is never installed on any one computer.

Upon each run, the software starts up Information such as USB Hardware ID and perhaps an ID unique to the app is gathered and somehow securely hashed into an activation key-like string.
This string is then passed as a parameter into a PHP function where it is reversed (server-side) and content checked against a database to verify that the application was run from an 'authorized' USB key and not copied from one to another (as H/W ID would change and not match the one in the database) - effectively this would minimise the chance that a client gets two working 'software licenses'.

Questions

The idea is to be able to retrieve the columns for the row in the database, which matches that particular HW ID and unique app secret will locate the correct row. The PHP is used to check if further entries in that row are also matching other values such as whether the HW key is expired or not. However, to prevent the user from using that same string parameter every time, it should be random and near impossible to calculate/guess, yet link to the same location in the database.

I am now considering encryption instead of hashing (for the benefit of maintaining the data), as it can be decrypted using a master key at the server. I understand that hashing only converts in one direction and perhaps I wasn't expressing the scenario correctly before this edit so I hope things have become a little clearer. Could someone guide me in the right direction? How is this done?

I'd really appreciate any feedback and ideas on how to make this happen properly.

You want a string that is unique every time the registration key is checked and something that the user will not be able to easily reverse engineer (and thereby bypass your DRM restrictions).

One way to do this is to have the application store your crypto key. You concat/combine the software keys, IDs, and whatever other data you want, along with a random string that changes every time this data is accessed/requested. You encrypt this with the crypto key and pass to your server. The server decrypts with its crypto key, extracts the decrypted data and dumps the random string.

The use of the random string means that the resulting cyphertext string is unique each time, making it difficult to reverse engineer.
Encrypting means that you can read the plaintext data even though the cyphertext is different each time (a feature that a straight hash cannot provide).

The downside is that the cyphertext might get large (depending on how you do it). You should also make sure that the random text is of a variable length to further make it difficult to guess the component strings.

The other problem you will have is the proper handling of the key in your app. Once a user gets that, then they can craft their own strings that will pass your tests.

In general, you are asking about how to devise a DRM solution. There are lots of established ways to do this, and I recommend you look at their design patterns.

The common struggle is that once you place your app in the hands of a user, then you lose a lot of control. It is better to design your solution so that it does not matter if a user copies your software, or design a framework upon which your app runs instead of locally (which is way web-based apps are so popular). You also have to weigh the cost/benefits of all this design work against the work a user will have to go through to defeat it. Are you placing your efforts in the right place?


Secure GET-based remote API access via PHP I am programming a way in PHP for my users to be able to access a remote API though my website. I was wondering if any of you had some input on whether or not this was secure (NOT considering any vulnerabilities that may be on the remote system)

print file_get_contents("https://website.com/?uid={$_GET['uid']}");

Is this secure? if not, can you explain why?

Note: The site does not return any value that is sent using the uid parameter.

I see three issues with this:

An attacker could set other query parameters than uid by e.g. using 123&foo=bar. Depending on how your site and how website.com works, this could lead to unexpected behaviour. To mitigate this, use some sort of whitelisting or filtering. E.g. if uid should always be a number, check that $_GET['uid'] only contains digits first.

Whoever can control content on website.com can now control content on your site. This basically means that anyone who has access (legitimate or not) to website.com can XSS you or spread malware through your site. If you don't trust them fully, don't do this. Or make sure the Content-Type header is set to something where this is not an issue.

Open redirects! If website.com has an open redirect vulnerability, you have a big problem. An attacker can now make your site serve basically anything! You could tell PHP not to follow redirects to solve this, but if website.com relies on redirects for functionality this might cause you trouble.


Could malware move during a scan to avoid detection? I think every AV-Scanner is using some predictable recursive scan to search files for malware. Couldn't malware easily detect a scan and just move to an already checked location, determined by knowing which algorithms certain AV-Scanner uses ?

Is there any mechanism in place by AV-Scanners to prevent such a behaviour?

Also couldn't a rootkit remove itself during a scan, and then put itself back into place after a scan is finished ?

The main reason malware can't evade AV this way is because the on-access scanner will catch that.

From the AV point of view, malware moving to different files is the same problem as new files being created during the scan. A very simple solution is for the AV to keep track of new files being created (which includes current files being renamed). This is done by hooking the OS API or other lower level hooks.

In theory, a perfect rootkit will be invisible to an AV. To increase AV chances against rootkits, the AV starts very early in the startup sequence, it uses low level ways of communicating to the OS and hardware, and it will monitor tampering activity on itself. Also, the first stage of a scan is on active processes and system binaries. That's done especially because in-memory malware can play tricks like you mentioned.

Also bear in mind that any strange activity on the side of the malware, like moving files, jumping through the memory of different processes and using rootkit-like methods will only attract attention to it because legitimate software will not have such behaviour. A strange behaviour will be flagged by the AV heuristics and that might help to detect the malware or the binary might be uploaded to the AV servers for further analysis and cross-checking.


Creating a separate privileged (admin) user account for authenticated VA scans When reading many sources on performing authenticated vulnerability scans, it has been mentioned that creating and using a separate admin (privileged) user account for scans is recommended rather than using an existing privileged user account.
May I know the risks involved in performing the scans using an original admin user account?

Let me see if I understand your question. You want to enter the live, admin password into an automated tool? And you are unclear on the risks of doing that?
A few things come to mind:

the distribution and storage of the live admin password across multiple "users"
the sharing of an admin password for multiple purposes
the lack of positive attribution of any actions performed to the scanner or the admin
the inability to easily disable the admin password if the scanning tool is compromised
the inability to lock out the scanner's credentials outside of expected scanning windows
the inability to limit the scope of the scanning admin account
the violation of "principle of least privilege" and "separation of duties"
the various compliance issues that might arise

The scanning account needs to be distinct to each scanner so that its effects can be limited, the actions of the scanner can be properly attributed, and the credentials can be disabled if compromised.
No one should know the system/domain admin password but the admin...