How is Google's Sidewalk Lab's Free Wifi Hotspot Tracking me? Elaborating from this question : Bluetooth/WiFi Identity tracking in public spaces - How to discover?
Questions:
How are they tracking me :

From a hardware perspective

Is it a mac address that they are getting from my device by blasting wifi

From a software perspective

I assume they are using some sort of wifi based triangulation

How is it legal?

Is it because it is public space?

Background if Unfamiliar

Researchers Piotr Sapiezynski, Arkadiusz Stopczynski, Radu Gatej and Sune Lehmann point out that "large companies such as Google, Apple, Microsoft, or Skyhook, combine Wi-Fi access points with GPS data to improve positioning, a practice known as 'wardriving'." The actual "how" is "proprietary to large companies."

Smartphone location tracking via Wi-Fi signals, motion sensors for subway riders
I know very little about this subject and would like to learn more. I do know that it was such a large issue in NYC that the ALCU stepped in:

In March of 2016, the NYCLU sent a letter to the Office of the Mayor warning that, under the previous privacy policy, CityBridge, the company behind the LinkNYC kiosks, could potentially retain a vast amount of information about users – often indefinitely. The NYCLU contended that this gave CityBridge the ability to build a massive database that could pose a risk of security breaches and unwarranted NYPD surveillance.....Under the old policy, users had to submit their e-mail addresses and agree to allow CityBridge to collect information about what websites they visited on their devices, where and how long they lingered on certain information on a webpage, and what links they clicked on. The privacy policy only offered to make “reasonable efforts” to clear out this massive amount of personally identifiable user information, and even then, only if there was 12 months of user inactivity. That meant that New Yorkers who used LinkNYC regularly could have had their personally identifiable information stored for a lifetime and beyond.

CITY STRENGTHENS PUBLIC WI-FI PRIVACY POLICY AFTER NYCLU RAISES CONCERNS

Q: 1.  From a hardware perspective
Is it a mac address that they are getting from my device by blasting wifi

-From the CityBridge website:

  Q. How long is data stored?

  Technical information from individual sessions, such as session
  length, device type, and device language is stored for up to 60 days
  before it is deleted. An example of this data is a monthly report of
  average session lengths.

  Anonymized MAC addresses will be stored for up to a year from your
  last session to allow seamless network access. Other operational
  technical information, such as monthly subscriber counts and total
  network utilization may be stored indefinitely.

CityBridge indicates that they do not store any personal information in their databases at all in the Q&A section, yet they do mention that they store connected devices' MAC addresses, which is a contradiction of their own stated policy about not collecting personal information in my opinion.

Q: 2.  From a software perspective
I assume they are using some sort of wifi based triangulation

-In the case of tracking, it wouldn't necessarily need to be a triangulation based algorithm as they would be able to log which access point (AP) a user is connected to as said user is moving through the city.  This would actually give CityBridge a fairly accurate path map for connected users depending on how many APs they've installed and how close toegther they are.  Users' devices are going to connect to the strongest AP signal for the highest connection speeds.

Q: 3.  How is it legal?
Is it because it is public space?

-Yes and no...simply being in public space does not give a company the right to track anyone.  What makes this a legality grey area is the fact that users must "register" their devices and agree to a ToS to connect to the CityBridge service.  Keep in mind that when you agree to connect to, install, download anything....especially free services, you're pretty much giving the developers/companies the right to whatever information they require in the ToS you've agreed to.

Please also keep in mind that public wifi is insanely unsecured.  Other users could easily sniff traffic from other users on the network and compromise the systems connected.  This is actually a big issue in public spaces like Starbucks and McDonalds.

Two easy reads

http://lifehacker.com/5853483/a-guide-to-sniffing-out-passwords-and-cookies-and-how-to-protect-yourself-against-it

http://www.androidauthority.com/capture-data-open-wi-fi-726356/


Would usage of jCryption 3.0 + SSL have mitigated the Heartbleed vulnerability? I came across a project called jCryption 3.0, which encrypts data between the client and server, without using SSL. If a website's JavaScript had used jCryption 3.0 to encrypt login form fields before sending them (over SSL) back to the server, would this technique have mitigated a potential Heartbleed attack?

This question assumes the following:

SSL is used to verify the identity of the site, and provide a second layer of encryption
jCryption 3.0 is used to encrypt any sensitive data sent between the client and server, even over SSL
The server that the browser posts to is a load balancer (running a vulnerable version of openssl), which decrypts the incoming traffic and sends it on to a web server for further processing

From my understanding, someone performing a Heartbleed attack on the vulnerable load balancer would potentially only be able to uncover encrypted username & password data, or the server's private key from memory.

The server has to decrypt the information. Once it is decrypted, it is in the server's process memory in plaintext. Then it would be leaked by heartbleed.

Furthermore, the server must have the decryption key. So it would likely be stored in the process memory and would be recoverable via heartbleed attacks.


My computer was probably infected by a virus from a professor I got a mail from my professor this morning with a request.zip file attached and a password in the mail to open it. Since the mail was from my professor and he already did send me zip attachments I didn't think about it and opened it, but it ended being a strange word document.
Later he wrote the whole team a mail that he has a virus and that we shouldn't open the attachment.
I updated my antivirus software (GDATA-Internet Security) and ran two virus scans but it didn't find anything on my computer.
It looks like the following two examples I found on this and another blog. You can find them here (1) and here (2)
What should I do now? Is there a way to find the data on my computer?

In basic I think that word document contained a macro that got executed and probably audited your system for any AV software and then downloaded the real malware. I would suggest to reinstall the whole system if that's possible and check for strange behavior in the network as this malware may try to look around the network to see what else is there.
Yes, there is a chance to find all data on your computer and send it to remote server where will be stored and wait for someone to check it. I would recommend getting an secure computer/laptop that was not in the network to prevent any further spreading of the malware and change all passwords that you have stored/used on the infected system.


Is it possible to change code of website through an embedded image say I allow my users to embed images that others can view, then the user rewrites the image to be a PHP file for instance. Would that pose a security risk of him injecting something into my code?

Would that pose a security risk of him injecting something into my
  code?

Yes

If you allow your users to upload an image file with no 'robust' validation,  it is trivial for an attacker to upload a malicious PHP file (e.g. by faking it as an image through changing the Content-Type request header) and execute it on your server or get a remote access.

Secure handling of File upload is not easy. You may find the below article helpful to know more about its security risks and recommendations:

8 Basic Rules to Implement Secure File Uploads


Recently received a odd email http://photomi.co.kr/httpcnbc9home-2.com.php?subpage216
Learn How to Make Money 0nline Fast

__________________
. louanne visszakuldod
Sun, 22 Jul 2012 0:33:42

Is there a way to identify what this page that is being linked to it doing? I'm afraid to click the link due to the odd site and spelling Online with a zero.

It will most likely infect your computer with some malware or keylogger.

Use a VM or a computer you are willing to reformat after to access the link, and run some malware analysis tool to check out what is happening.

If you have to ask here though, I suggest you just ignore the link. Malware analysis is a very complex topic that is difficult to understand.


Exploiting flash XSS holes I have a URL to a flash file. Sample :-

http://abc.mydomain.com/Findme.swf

Now, there is a parameter called xmlpath as :-

http://abc.mydomain.com/Findme.swf?xmlPath=something.

Is it not that xmlpath is used to point to an xml file? If proper sanitization of the parameter xmlPath is not done, how can it lead to an XSS. Explanation with an example would be well appreciated.

A parameter is a parameter: a data element (necessarily a character string, in the context of a URL) indexed by a formal name. What is done with that parameter on the server is entirely up to the server.

We here enter the realm of suppositions. The parameter name "xmlPath" is suggestive of the parameter value being a path name for a file which uses XML. We may imagine that, upon receiving the request:

http://abc.mydomain.com/Findme.swf?xmlPath=something

then the server will try to read one of its local files named "something", decode its contents as XML, and then interpret the contents in some application-specific way. Conceivably, since the base URL includes the name "Findme.swf", the result of the server-side processing might be a SWF file to be interpreted in the client browser (specifically, in its Flash plugin). We could even infer that the exact SWF file contents will depend on the result of the processing of the above-mentioned XML file.

What can possibly go wrong ? This is the important security question, because attacks can be viewed as forcing systems to derail when faced with unexpected, abnormal or invalid input. We could try something like this:

http://abc.mydomain.com/Findme.swf?xmlPath=..%2F..%2F..%2F..%2F..%2Fetc%2Fshadow

in order to try to get the server to read the /etc/shadow file (which, on a Unix-like system, contains the hashed versions of the local users' passwords), process it, and somehow leak the file contents in what the server returns. This specific example is unlikely to work for two reasons:

On a normal Unix-like system, /etc/shadow cannot be read by non-administrative local users, and, in particular, the user who runs the Web server process. This depends on the server configuration, of course, but it usually takes some inordinately creative incompetence to make /etc/shadow readable from Web applications.
/etc/shadow is not in XML format so the decoding will fail.

Note that, for point #2, any decoding error could result in some complex debug information which may contain a dump of the input data which triggered the decoding, e.g. the complete /etc/shadow file itself... Also, we do not really know if the server really decodes the XML file. It is possible that the server simply reads and embeds the XML file "as is" in the returned SWF, to be decoded on the client. As I said, we are just layering suppositions on top of each others. Anything is possible.

A common reflex of Web programmers is to think of such vulnerabilities in terms of "sanitized input". This is wrong. It is true that any input from external entities, in particular connected Web clients, is suspect and must not be trusted; however, it does not follow at all that there would be some magic sanitation operation which would make the data "clean" and absolutely innocuous. This is the wrong mindset. There is no such thing as generically clean data. This guy:

is NOT an IT security specialist.

When input data must be processed, it must be inspected with all due care for its intended purpose. Here, the xmlPath parameter is processed as a path to a file so it must be inspected for actually designating an allowed file path, where "allowed" depends on the application. It can be surmised that the server hosts some XML files which are to be read upon normal processing, probably stored in a specific directory or directory tree. The code on the server should then make sure that the xmlPath parameter it is about to use really designates one of these files, and none other on its hard disk. This is not easy because the server code must keep track of all the possible ways of interpreting a file path by the OS; OS vendors have proven very creative in that respect. There are many encoding issues to deal with.

A more secure way of processing such input parameters is to work symbolically. The server should not expect a path but some sort of identifier that the server code will map to a local file. For instance, an xmlId parameter could be, when received by the server, hashed with some cryptographic hash function, and the hexadecimal result used as file name in a specific directory. Hexadecimal contains no dot, slash or any other special character, so there is no risk of escaping the directory and reading unwanted files.

None of the above has any relation with XSS, aka cross-site scripting. XSS is a generic name applied to attacks when some user-provided input data is reflected into some answer which is sent to another user, and the browser of that second user interprets it as a script excerpt. When XSS applies, a user can then choose some executable code (Javascript, but executable nonetheless) to run in the security context of another, target user, which opens the road to a lot of nastiness.

There is no reason to suspect that the site we are talking about is subject to XSS (at least, no more reason than "this is a Web site").


Is it possible to modify a CA without having to reissue all of the derived certificates? Background: I have my own authoritative certificate that I generated myself for signing certificates for services my friends and I use, including web server, ircd, etc.  It's convenient because I don't have to spend money getting my certificate signed and among my those who use it, the guarantee of security is fairly complete.

Caveat: Being somewhat noobier then than I was now, I set my CA to expire after a year.  This was about 10 months ago.  The private key is 4096 bit RSA and the certificate is self signed with SHA512, so it should stay secure for pretty much as long as I'm around to care about it, as long as I don't lose the private key.

Question: I know I can generate a new certificate from the private key with a longer expiration date (say 100 years from now for the purposes of this discussion).  Would the replacement be as simple a process as substituting the newly generated, extended certificate to all of the clients?  Would they accept the subcertificates as trusted, provided they updated their stored copies of the CA to reflect the new expiration date?  Would I be able to skip regenerating all of the intermediate certificates as long as the CA's keypair and fingerprint remained the same?

You shouldn't have to reissue all of your certificates. Assuming that each is still valid, and as long as you use the exact same key and subject for your CA you should be able to extend the life of your CA and redistribute the certificate as the new trust anchor.


Can a Windows 7 PC with folder sharing and remote desktop disabled, still be penetrated by a rogue computer on the same WiFi or LAN? Assume the network is already penetrated, and the attacker already fully controls another PC.

Other than setting up a proxy to intercept traffic from all other systems on the network and use that to inject rogue traffic. Other than that, what would the vectors be for an attacker to attempt to directly infiltrate one of the computers on this network. More importantly, what would the corresponding mitigation steps be?

Note:

The purpose of this question is mainly educational/theoretical. So mitigation steps required (however few there are) other than "installing an AV" are preferred.
All attacks would be through the network. There is no transfer of physical media between the infected computer and the (to-be-)protected one. You can further assume that there is no shared storage (NAS, etc), nor are there any shared folders, shared credentials (user-groups), RDP/VNC etc on ANY of the computers.
However, other than the above, no further hardening steps have been taken.
The primary concern is data-theft. (in case that matters, or if it can help narrow down the scope of the question)
This question is intentionally limited to Windows 7 so as to limit the scope of the answers, and to provide some further limiting, pre-existing conditions (folder-sharing and RDP disabled). However if the essential nature of in-network PC-to-PC threats do not vary much, then a platform-neutral answer will also be appreciated.
If the question is still too broad, I'd appreciate being pointed in the direction of an informative (if technical) guide, or even a starting point for getting such (technical / detailed) guides.

There are a few possible scenarios, even after assuming Man in the Middle is not happening.

Missing patches:

If your system is missing a patch that allows RCE, that is an easy win. There are plenty of remote exploits that exist, and new ones every so often.
Mitigation: Patch your system!

Are you on a domain?

You didn't mention Windows 7 Home or Professional. If your machine belongs to a Windows domain, and another machine on your network is compromised you are in trouble. Once the attacker gets Domain Admin, they can control your PC fairly easily.
Mitigation: Deactivate your network card and cry?

Default Configurations:

Windows has a number of insecure default configurations. LLMNR is one of them, and is easily exploited. Mitigation: Disable LLMNR & NBT-NS (see the bottom of that link)

PSExec

I know you mentioned that you are not sharing folders, but is port 139 and 445 closed? Read over the capabilities of PSExec.

Vulnerable Applications

Run NETSTAT on your PC. You may find that some applications you have installed are listening on a port for an incoming connection. If there is a vulnerability here you leave an opportunity for a remote exploit.

Mitigations?

Patching obviously. OSSEC is a nice tool that goes beyond AV in that you can get alerts when events happen on your PC that shouldn't typically happen. Also review your Windows Event Logs, check your AutoRuns (and use the VirusTotal integration), check your listening ports (with NETSTAT) and change passwords often.


In Linux, when I consider trusting a new software source, what do I need to evaluate? When I'm using the Linux software PackageKit, I get confused about what specific items of information I will need in order to decide whether to authorize software installation from a new software source.

I'm using Gnome in openSUSE. I think the question would be just the same for other systems that have PackageKit, such as KDE in Fedora.

Each time that I do this, I wonder:

What opinions do I need to form?
What values do I need to know in order to form my opinions?
How do I determine that those values are correct and consistent?

Several times I have elected to install software from a repository that wasn't previously configured in Linux. A repository can give me advantages including notifications of updates and better integration with my distribution and environment.

Soon after I choose to install the new software, often by pushing a 1-click install button on the software.opensuse.org web site, the PackageKit "Software signature is required" dialog appears. It displays the following items of information. Each of them seems to relate to something that I may need, but they each present a bit of a puzzle as well.

Repository name. This is often one word. I think it is not always exactly the same text as what I would see listed at software.opensuse.org, or wherever I last saw mention of the repository. Anyway I'm not sure where PackageKit gets this name and on what basis I can believe it's correct.
Signature URL. I don't know what to do with it. I suspect it's the ID of some resource, not actually a site where I can learn more.
Signature user identifier. I don't know what to do with this, either. It looks like an email address. I don't know whether it represents the person I should trust, the person I should contact with concerns, the address at which I should contact that person, etc.
Signature identifier, eight hexadecimal digits. It's not quite clear from the dialog or its documentation, but I gather that it's actually just a few digits of a GPG key that in full would have 40 hexadecimal digits.

There has been criticism of the "Software signature is required" dialog. That's not exactly what I'm looking for. If needed, I could avoid PackageKit for this task and use YaST or zypper, just as PackageKit users on other systems could use apt, dpkg, rpm, or yum. I would still want to know what information is necessary, whether it's the information that PackageKit presents or any other information.

This is why the dialog sucks: it's confusing.

The decision to trust a particular repository or not is one you already took when you added it to your package manager. The whole point is to get software from the repo: if you didn't trust it you wouldn't be downloading and running code from it.

I suspect that this dialog is attempting to protect you from a situation where the repository is not the same one you trusted when you added it. For example, someone might have performed a Man-In-The-Middle attack, so you think PackageKit is connecting to the trusted repo but in fact is connecting to another, evil one. If it's connecting to the evil one, then the signature will not match.

If that's right, then they certainly shouldn't show it to you very often. They should trust the repo's signature at the point of adding it, and then pop up this dialog only when there's subsequent trouble.


Can OnionDuke malware actually spread to new systems through an image? I do realize that questions about malware in images has been asked before. It just does not look like they answer the questions in this particular situation.

This is about the OnionDuke APT malware that F-Secure reported about here (note that this report is dated Friday, November 14, 2014).

My question is about information in this article by F-Secure (according to which OnionDuke was found in 2014). This article says on p.23:

  In contrast however, for OnionDuke and MiniDuke the linked image files
  contain embedded malware to be downloaded and executed, rather than
  instructions.

And the information in this recent article (also by F-Secure) which says the following:

Does this information about OnionDuke mean that it attempts to infect new systems by embedding itself inside an image that is executed when viewed by a user, or is that image for upgrading systems that are already infected?

Does this information about OnionDuke mean that it attempts to infect new systems by embedding itself inside an image that is executed when viewed by a user, or is that image for upgrading systems that are already infected?

From my understanding the payload needs to be extracted from the image by an existing instance of the malware or by a dropper. Other part of the report make this more clear in that they write (The Dukes Whitepaper, page 14):

  Screenshot of a tweet intended for
  OnionDuke, with a link pointing
  to an image file that embeds an
  updated version of OnionDuke

Thus Twitter is part of the Command & Control structure and the malware will load the instructions from the tweet, i.e. where the update can be found. Embedding the malware inside the image is used to make it look innocent, so that firewalls or breach detection systems don't consider the data suspicious. And such an image can be easily placed on lots of trusted sites so that chances are high that the URL for the image will not be blacklisted.

The image itself is not used as an exploit vector, that is viewing the image inside the browser is harmless. It is only used as a container.


Logic for generating Strong Password? I try to encrypt password using MD5 but there are decoders for MD5. So I'm worried about encryption of password for big website.

Is there any logical suggestion or step function to generate strong password?

I can't understand what you are asking, but has been asked many times here.  If you want to know how you should store your passwords; a modern strong keystrengthened cryptographic hash like bcrypt is ideal; at worst use something like sha256/sha512 with a random salt (different for each account) stored with the password.  This has been covered in many threads here.

As for how to think of a strong password, random passphrases are great, and diceware is an easy way to come up with one.  Also 10+ character long passwords with mix of uppercase/lowercase/numbers/symbols are sufficiently strong.  If you use many unique passwords (always a good idea) its helpful to use tools like keepassx to keep an encrypted list of your passwords associated with each site.

Remember never re-use passwords at multiple sites.  E.g., if you use the same password at your bank as some random webapp, you have no assurance t hat the random webapp isn't storing your password in plaintext (or near equivalent) and some admin/hacker there will someday try to use that password with other information (like your username) at places like your bank.


How can I validate that a PRNG's output is insecure and predictable? Say I talk to a developer who is using some output of a Pseudo-random number generator in order to do some security task. I know based upon common knowledge that only Cryptographically Secure Pseudo Random Numbers should be used.

However, I want to take this a step further - how would I create a proof-of-concept that the current method is not secure? I would guess that I need a large collection of outputs from this particular PRNG algorithm... But aside from that, I have no idea what else I would need to do. Is there a way for me to use a cryptanalysis tool to derive the seed or salt (assuming there is one)? How can I prove or disprove that such a PRNG is predictable using security auditing tools and/or scripts? Assume the same seed is used.

A problem you're having here is you're thinking about it in a much too black-box fashion (e.g., collecting a large collection of outputs), which is not what an actual attacker will do. An actual attacker will get as much concrete information about internals as they can, including the PRNG algorithm and the code for the applications that you use it in, and exploit specific details to break it.

So apart from pointing you at programs that demonstrate how trivial it really is to break a bunch of very popular standard library PRNGs, there aren't obvious generalizations to be made here, apart from maybe a bit of cryptanalysis (which is a black art not explainable in a Stack Exchange answer) they're just looking at PRNG code and figuring out what attacks that specific code:

https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/
https://crypto.stackexchange.com/questions/51686/how-to-determine-the-next-number-from-javas-random-method
https://crypto.stackexchange.com/questions/52000/how-can-c-rand-be-exploited-if-a-secure-seed-is-used


Do 64-bit applications have any security merits over 32-bit applications? A particular article from arstechnica.com stated this.

  One of these protective measures is called Address Space Layout Randomization, ASLR, and it works by moving DLLs and application memory into unpredictable locations within the 4GB that each 32-bit application has available to it. This makes exploitation harder, but on 32-bit systems the protection is limited. With only 4GB of space, there aren't that many random locations to choose. DLLs, for example, still need to be packed relatively close together, to ensure that there are large tracts of free space open for applications to store their own data in.

Does this have any technical merit or should I file this away as the usual nonsense non security-focused sites come up with?

ASLR is a hide-and-seek game: in case the attacker succeeds in overflowing a buffer and overwriting pointers, the OS loads the application code (the main executable and its DLL) in randomized locations, so as to make it harder for the attacker to actually hit a meaningful location. By construction, it works better when the playground is larger. The extended address space in 64-bit mode is a larger playground.

To quantify things: in 32-bit mode, the address space is, at most, 32-bit wide (actually 31-bit when the kernel is not aware of 64-bit mode). The DLL loader must respect page alignment, and a page is 4 kB on x86. This gives, at most, 20 bits of entropy in the randomization of ASLR, but in practice lower than that because spreading the DLL throughout the whole address space can induce higher fragmentation (preventing the application from allocating, e.g., a 1 GB continuous buffer, something which is commonplace when editing pictures or movies). This is what the text you quote alludes to. Let's assume, for instance, that the DLL loading will occur only within one eighth of the address space, i.e. 29 bits; with alignment, this means 17 bits of entropy, aka 131072 possible locations for any given DLL. In any case, an industrious attacker could rely on luck, by simply repeating the attack (with a script) a few dozen thousand times until it works.

With 64-bit mode, the address space is extended to 48 bits, lowered to 44 bits on Windows, because they did not bother to go beyond. This adds 12 bits of entropy; in other words, it multiplies by 4096 the attacker's effort (in case the attackers relies on luck).

Therefore, it is true that, in some way, the extended address space of 64-bit mode increases security. Of course, ASLR has any effect only when a buffer overflow has occurred, in which case you are already in big trouble.


Cryptography Online Education Do the security experts at IT Security have a preference between the two cryptography courses offered by Coursera (Stanford), "Cryptography I" and Udacity, "Applied Cryptography"?

I am seeking an introductory-level course, and have a modest amount of experience with Java, macros, and CS in general.

I don't believe there can be an objective answer to that question. So, here is a subjective answer: the Coursera course is by Dan Boneh, so it cannot be bad.

Note: cryptography is a rather advanced topic. To really get the hang of it, you need to know a bit of maths, especially linear algebra and some probabilities.


Can a file get accidentally corrupted while downloading? I read an answer here about websites providing downloadable files together with their hashsums. It contained a sentence I'm thinking about whenever I download something, but I never really understood it: The provided hash lets you double-check that the file you downloaded was not corrupted accidentally in transit.

I think I can vaguely remember that this, having to redownload a file because it's broken, happened sometimes in the past, when I suffered from a 56k modem, and downloads where a pain in general.
But I'm not sure this happened, and I couldn't explain it - there is TCP, which should be capable of handling my download perfectly fine, and it's around since at least 1983.

Is there any way a downloaded file could differ from the file on the server, besides malicious attacks like MITM? Or: as a user, if I think something isn't right about the finished download, does it have to be a MITM attack?

It is possible but uncommon with HTTP that the actual bytes are corrupt. But it is not uncommon that the download simple breaks in-between and that the browser does not notice. This is especially true if no length information are sent with the content (i.e. ends with TCP close) but even if a length is sent or chunked encoding is used browsers often ignore such errors.

With FTP it is even worth because there is no real way to indicate the length of the content, that is the content always ends with connection close. Apart from that corruption can happen if you use the wrong transfer mode ASCII instead of BINARY.


Offline brute-forcing of a bank card PIN I may be neglecting a crucial fact here, but putting the following together leads me to believe it is dead-easy to determine a bank card's PIN using the most basic hardware available to everyone (I speak for my country in what follows):

Each bank has an internet banking application that uses a "digipass" to verify the user. These are all made in China and there are only some models in use. It does not matter which logo or serial number is on the device, they all work the same.
The digipass asks for your PIN, and knows if it's correct or not (quite fast).
A regular PIN is 4 digits, making for 10000 possible codes. Brute-forcing that is easy.

Put everything together, and you get this:

Steal a bank card,
modify a digipass to allow for a quick succession of PIN number trials, and detect if it thinks the PIN you entered is correct (this is simple? electronics, really)
Get a card's PIN in say, 5 seconds per try, roughly 14 hours.

I must really be missing something, or is bank card security that ridiculous?

The chip embedded in the smart card locks itself after a defined number of incorrect PIN entries, typically between 3 and 10 attempts.


How, if at all, are some programming languages inherently less safe? Can it be that applications written on certain languages are inherently less safe, no matter how hard you try to get it straight?

Or, can it be that some programming paradigms are less safe than others?

That is, should the development of safety critical software consider avoiding, or using (or using with care) certain languages?

Safe programming is a subset of correct programming -- every exploitable vulnerability is, basically, a bug such that the consequences of exercising the bug are advantageous to an ill-intentioned individual (the "attacker").

Languages offer facilities which help or not help in making correct programming. For instance, if the task at hand involves doing things with character strings, languages that have an inherent type for character strings, handled as immutable values, make things much easier for the developer. Many modern languages such as C#, Python, PHP or even Javascript fall in that category. Conversely, more low-level languages like C and Assembly require the developer to handle allocation for buffers holding strings, taking care of all lengths and deallocation at the proper time. In that sense, C and Assembly are "less safe" languages than most others when it comes to handling character strings, because they require more care from the developer. "Care" is a scarce resource.

In the same vein, some languages include a lot of "magic" such as automatic trans-typing, which means that a seemingly simple expression may hide a lot of complexity, that may bite the unwary developer. Some modern languages such as C#, Python, PHP or Javascript have that flaw. Conversely, low-level languages such as C and Assembly tend to be "safer" in that everything they do is explicit. The developer just has to read what is in front of his eyes, with less mental inferences on what the interpreter/compiler will do. "Thinking time" is a scarce resource.

There is no paradigm that is inherently less safe than any other; however, lack of a defined paradigm is assuredly less safe. Safe programming, ultimately, is about a developer who knows what he is doing, and this comes from discipline.

Edit: "Discipline" means never writing any code whose complete behaviour, under all possible combinations of normal and abnormal input data, is not fully understood by the developer. In particular, it implies not throwing code together and tweaking until the thing accepts to run. Similarly, copy&pasting from Stack Overflow is poor discipline -- reading solutions on SO is very fine, but it must be followed by thorough understanding of what the code does.


Why is the proportion of TLS usage higher at weekends? Google has data available here on the proportion of emails outbound and inbound from Gmail using TLS encryption. Apart from an overall increasing trend, a striking feature of the inbound data in particular is a regular oscillation. Here is the past year's data for the proportion of encyrpted email arriving in Gmail inboxes:

Downloading the data and splitting it up by day, it's clear that the oscillation is a weekly variation coming from increased usage at the weekend:

The vertical axis here is the proportion of emails using TLS, so 1 would mean all emails used it. The units on the horizontal axis are `week number', with week 1 beginning Wednesday 11th December 2013, when the data set begins (there's some days with missing data, which appear as the gaps in the graph).

There is some weekly variation in the outbound data too, but it's far less obvious, and doesn't seem to follow the same clear weekday/weekend pattern.

There is bound to be some degree of speculation here, but can anyone offer a plausible explanation? There are clearly factors affecting the volume and type of email sent like this (more work-related emailing during the week, or marketing emails targeted at weekends), but it isn't obvious to me why this particular pattern should result.

I would need more elements to be sure, like the protocol used. What is clear when looking at the raw data is that the variation is mainly visible on inbound mail. That alone let me suspect that mails send through the webmail use TLS, while mails sent through SMTP relays do not. Which is somewhat coherent with SMTP protocol: it may go through a number of uncontrolled relays, so encrypting the transmission looks useless and many SMTP relay do not implement it. Instead they relay on the sender to encrypt the message content if privacy is needed.

That could explain why on work days, more mails are sent from work through corporate SMTP relays (no TLS), while less are on week end.

Below is my opinion:

Anyway, pretending that using TLS to and from GMail increases mail privacy is more marketing than information. What is the threat here? It is not far from securely closing a sheephold after letting the wolf in... The only way to increase privacy is to exchange encrypted content. But Google does not want to advise a method that would prevent itself to use the mail contents


Providing a SMS recovery feature without compromising the security of an account I'm designing a system so that it encrypts a user's profiles. The only way of accessing the information stored in it is by either:

Providing the password for the account
Resetting the password using offline backup codes
Resetting the password by sending an SMS code

We will assume that the device receiving the SMS code, nor the transportation method of the SMS, is not compromised.

In order for the three methods to grant access to the user's profile, a key will be generate to encrypt and decrypt the profile. We will then store encrypted versions of the key so that each of the following methods listed above can access the information in the profile.

For method 1 & 2, ensuring that the key remains confidential is easy. For method 1 simply encrypt the key using the user's password. For method 2 generate the backup codes, encrypt the key with them, and then give them to the user. For method 3 however, I'm not sure how this should be done.

Question 1: How can I provide a feature that allows a user to recover their account by sending a SMS code to their device, such that the organisation that stores the data cannot access the information in the user's profile?

Question 2: A company allows users to reset their passwords using SMS. Does this imply that the company can access information stored in their user's account?

An organisation is able to modify the system so that they can retrieve whatever data was encrypted - just make sure that the next time the user logins in you store a copy of their password. However, in the event that an adversary obtains a copy of the accounts, my question still remains valid.

I don't think this is possible, with 1 and 2 you are effectively giving the user full control of the encryption keys and making sure the server does not know them. However, with 3 you need to generate new keys.

However, for securing against an attacker getting a copy of your database, a HSM will help. An HSM is a hardware storage of private keys, meaning it is impossible to copy the private key.

For your SMS-application, you would encrypt the profile key with the public part of the HSM keypair. When you need to generate an SMS-key, you can have the HSM decrypt the profile key and either re-encrypt it with the SMS-password (as you do with the regular password), or just use this as a part of the password-reset process (decrypting and re-encrypting when the user sets the new password).

There might be advanced cryptographical tools I don't know, maybe zero knowledge proofs could be used, however, this sounds like PhD-research-level stuff.


Why if a server response contain both Public: TRACE and Allow: TRACE then responds with 405 NOT allowed? SCENARIO:
I'm testing a web application. To test if TRACE is enabled I used both
nmap --script http-methods target.com

and
curl  -k -i -X OPTIONS target.com

After running the former I get
443/tcp open  https
| http-methods:
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE

with the latter I get
Allow: TRACE ...
Public: TRACE ..

So I guess TRACE  should work. But when I run
curl  -k -i -X TRACE target.com

I get
HTTP/1.1 405 Not Allowed
Server: Microsoft-Azure-Application-Gateway/v2
...

Which is not what I was expecting.
QUESTION:
why TRACE is blocked? is because of Azure or what?

It looks like a false positive, according to the documentation (https://nmap.org/nsedoc/scripts/http-methods.html) this script works by sending an OPTIONS:

Finds out what options are supported by an HTTP server by sending an OPTIONS request. Lists potentially risky methods. It tests those methods not mentioned in the OPTIONS headers individually and sees if they are implemented. Any output other than 501/405 suggests that the method is if not in the range 400 to 600.

The methods listed in response to the OPTIONS request may not actually be supported or may be handled as a GET method. If OPTIONS request returns TRACE, nmap script does not verify this, just prints as a supported method.
You should manually verify every potentially risky method (PUT, DELETE, CONNECT, TRACE) which is returned by OPTIONS request. If response is 405 Not Allowed than method is not supported and there is no security risk.


Diffie–Hellman key exchange questions at the moment I am working on a chat application, where more than two clients can communicate at the same time.

I just got started with the encryption so please be bear with me.

My goal is to implement end-to-end-encryption so I've done some research on that and I found about Diffie–Hellman key exchange. I have a brief idea how it works, also plenty of questions.

On wikipedia it says that it works as following:

We decide on a big prime number, we'll call it P.
g has to be a primitive prime root of P.
Each client picks an arbitrarily private key which follows this condition: 1<= Private_key <= P
They send their private keys which are generated as following: (g^private_key) mod Pover the server
the secret shared key is (User2PublicKey^User1PrivateKey) mod Pand vice versa(User1PublicKey^User2PrivateKey) mod P

My questions to you are:

Does this work on a multi-client chat? I had some attempts on paper to emulate a connection for three clients and I couldn't get the same shared key. If so could you provide me an example for that please?
I know it may sound silly, but P, g and the keys are just integers? Like P could be 139, g 37 and so on?
Instead of encrypting the messages with the recipient's public key, couldn't I use the secret shared key for that? To avoid encrypting the message for each client connected.
P and g could be generated on the server side?
Could anybody provide me an example of implementing this in Java?

You should never write an implementation to an existing algorithm or design an algorithm. The algorithm should be picked up from a book and implementation from a library.

Keeping the above points in mind, remember that Diffie Hellman is vulnerable to MITM attacks as there is no authentication factor involved in the protocol. For confidentiality, I would recommend using SSL.

Generate a self-signed certificate for Entity B. Entity A will have a copy of the certificate and would trust it. Entity B is authenticated. Now for the authentication of A, you can simply have a pre-shared secret which A will represent and B will verify.

You can refer the docs for DKE implementation in node.js - https://nodejs.org/api/crypto.html#crypto_diffiehellman_computesecret_otherpublickey_inputencoding_outputencoding


Bypass cookie validation I have discovered that a web application allows the setting of certain cookie values through request parameters. Each request param results in a separate Set-Cookie header. i.e. a request like this:

/url?cookie1=first_value&cookie2=second_value

results in the following headers:

Set-Cookie: cookie1=first_value
Set-Cookie: cookie2=second_value

These headers appear after the session id cookie header, so I figure I should be able to fix the session by using a cookie value like the following

first_value; another_cookie=another_value

URL encoding the space, semicolon and equals signs. However once the app sees the semicolon, it simply truncates up to that point, so the response header becomes:

Set-Cookie: first_value

My question is, what other delimiters might a browser accept, or what methods might allow the filter to be bypassed.

A CRLF Injection might work. You would use a URL like the following:

/url?cookie1=first_value%0d%0aSet-Cookie:%20cookie2=second_value


Is it secure to use a part of the key as IV in AES? I seen a lot of AES implementation samples wide spreaded over the Internet in almost every language I can recognize. There is one difference that I reflect to be repeated between all.

Some of them are require a IV and a key. Two entities.
Some of them reuse a part of the 128 bit key as a IV. One entity (in my eyes).

For instance, this can be found on the net

Rfc2898DeriveBytes pdb = new Rfc2898DeriveBytes(password, salt);
rijndael.Key = pdb.GetBytes(32);
rijndael.IV = pdb.GetBytes(16);

..and the whole sample this part come from is quite wide spreaded. Even in MSDN forums. One other hit on the net with 22 upvotes says "This is plug and play code that I found on internet. It just works:"

This cause me some headache. Is this secure? I can't see why authors bother to create an IV functionality just to see it being shortcut just by cutting key in half to produce a byte array with size that fit IV?

I feel that the question will be more complex because if the different cipher modes use the IV on different way. Also it may be dependent on how the application is built. For instance; is the full key always unique? If not, how is the entropy of the key? And separately, is the pair (iv, password) always unique?

By looking at many of the samples that populate IV with a part of the key, they posted an static 16 byte array with fixed values. No indication or attempt to make audience understand that the sample is expected to be used for random -whatever- keys.

Is it safe to use a part of the key as IV and what is best practice?

Is it safe to use a part of the key as IV and what is best practice?

In a word. NO.

IV is a fundamental part of cryptography that forms part of the essential element of randomisation. The use of a non-cryptographically random IV that is static or otherwise predictable as part of your encryption process means that you are potentially weakening the randomisation element of your chosen cryptographic algorithm.

The reason example code frequently uses fixed IVs is for that very reason. It's example code, commonly found in books or on websites.  The authors have a need and desire to keep the example code as short as possible, so fixed IVs are used on the unwritten understanding that the reader has a sufficient grounding in the principles of cryptography to know they should be using random IVs in real life.

If memory serves, Bruce Schneier has an entire chapter on IVs in one (or more) of his books. That would be an excellent starting point if you really want to get into the detail of the matter.


Encrypt secret with numeric PIN, but allow wrong attempts I am looking for a method to encrypt a secret with a numeric PIN in such a way that if an attacker tries to decrypt with the wrong PIN, the ouput should be different.

For example, if the secret is ABCDE and the PIN is 5533, and the attacker tries to decrypt it with the incorrect PIN 1234, the output should be BASDAFF (a random string that looks like the secret).

I want to use this method to encode Diffie Hellman private key with PIN, so that a secret will be generated even if the PIN is wrong.

Technically, this is how unauthenticated encryption works by default - an incorrect key will produce an incorrect plaintext. Only if there's authentication or error-checking (and in ready to use libraries, there generally is) will decryption produce an error.

Note that it's trivial to brute-force the PIN due to its tiny keyspace, unless the number of attacks is very limited and they can't be distributed between many machines. The PIN can be made perishable to that end, removing the file after N attempts, provided there's a more permanent way to authenticate.

Generally, you should NOT encrypt the secret with the PIN itself, but rather with a key generated using a PBKDF (bcrypt, scrypt, argon2) from user-known secrets such as the password or the PIN and a salt. Depends on what exactly you're trying to do.


How do DoT and DoH facilitate fingerprinting by resolver operators? https://dnscrypt.info/faq/ states for both DNS over HTTPS and DNS over TLS that it

Provides more information than regular DNS to resolver operators in order to fingerprint clients

How so?

TLS Resumption
TLS Resumption is a mechanism which allows the client to resume a recent TLS session so they can use the previously established session keys to continue encrypted communication and skip the key exchange step in the TLS handshake. However, it also allows  sessions to be linked together by the server, so it can be used to track the client over longer periods of time.
A similar problem is presented by TCP Fast Open. Clients can send a TFO cookie to reduce the round trips required to open a TCP connection. However, like TLS resumption, this can be used to uniquely identify the client and track it across sessions.
HTTP Headers
Another way to fingerprint clients would be through User-Agent, Accept-Language and Cache HTTP headers to infer information about the client such as the client version, locale and possibly some information about a subset of the client's history, as mentioned in RFC 8484.

Of course, it's possible to mitigate most of this on the client side, by not utilizing TLS resumption or TCP fast open, and not sending accurate HTTP headers, perhaps even randomizing them (although I am not sure whether any DoH/DoT clients take care of this or not).


How were resources shared before OAuth? With OAuth 2.0, it is pretty straight forward for a developer to authenticate a user via another service in order to obtain its data, e.g. get tweets from a Twitter user or fitness data via RunKeeper, without getting to know the users credentials.

What was used before OAuth 1.0 and what other technologies are being used? Were credentials often exposed to the developer/service before OAuth?

There are several techniques that are still being used beside OAuth.

API keys/Service keys
Whitelisting IP's
User/Password Login
Token Login (non OAuth)... eg. custom implementation.
none, just a 'secret' web-endpoint.

and often a combination of them.

What you saw often was a combination of whitelisting and one of the other techniques.

OAuth was designed to limit the rampant "leaking" of user login credentials, by implementing a system of token and authentication (not based on user information)

it is even designed with thoughts of replacing the tradional Username/password system. (in conjunction with openid which does a similar thing though other mechanisms, that work amazingly in unison).


Does Wazuh have capabilities for handle virus/malware/rootkit ? If yes, How? This question is similar with this one:

OSSEC capabilities for handle a virus that already spread into the deepest system

But it didnt roughly answer how could i do that exactly. I have tried Wazuh app for maybe 5 months in a row, as far as i know, wazuh unable to delete the virus/malicious software that have been found. Like they just tell us there are some rootkit or virus but i couldnt find how to delete that malware using some of wazuh features like active-response even though the malware have already detected.

Did wazuh have capabilities for delete or disable a malware that have been found ?

Wazuh engineer here.

I wonder how Virus are being detected in the first place. If you have some kind of AntiVirus solution, then you can do an integration and have Wazuh process AV alerts (triggering active response to remove malicious files or stop malicious processes).

Having said that, Wazuh can also detect malware looking for IOCs (rootchecks), detecting anomalies (hidden files or processes), and monitoring the file system (syscheck).

Something that works really well to detect malware is the integration with VirusTotal. This way, when a binary file is changed or created, Wazuh will check against VirusTotal and learn if it is detected by AV engines. If so, you can trigger an active response to eliminate it.

In addition Wazuh has done integrations with AVs like ClamAV or Karspersky to do that exact same thing.


Can you have Secure encryption with a backdoor, and still be secure? Is it possible to have an encryption algorithm/implementation that has a "backdoor", that also wouldn't introduce flaws into the encryption?

For instance, if you have a master password, once that gets leaked that person now has access to anyone's account.

Would it be possible to have TWO passwords work to decrypt: One for the authorities, and one for the user? That doesn't sound very secure, as now maybe collision are far more likely.

Then, there's also the issue of if that password given to the authorities will be secured (e.g. maybe they keep it in a excel spreadsheet in their gmail account)

To your first question, no, the backdoor is a flaw in the encryption.  Think about Kerchkoff's Principle: a system must remain secure, even if everything about the system is known except the key.  A backdoor would be revealed by examination of the system.

However your second clarification is talking about the concept of key escrow.  I may have my secret key, but the company also has a secret key.  Either one can decrypt the message.  Those are common, and supported in various security packages.


Multiple "rundll32.exe mhunk.dme" instances. Is my PC Infected with Something? So, I have this strange list of rundll32.exe
There are quite a lot of rows of it (see attached image) when I open the process tab in my task manager
I've already read the link here: Multiple running instances of rundll32.exe
The patterns appeared to be in the cmd line column

rundll32.exe mhunkw.dme,

For example, in my screenshot you will see

rundll32.exe mhunkw.dme,krvvjwa
rundll32.exe mhunkw.dme,oxvlyk
...
rundll32.exe mhunkw.dme,szswzunt

the list goes on.
Any idea what this is?

Multiple copies of rundll32 running strangely named files does look like a classic malware infection to me, although as the article you linked to states there could be benign reasons, and gives steps to possibly determine what these files are. You could also use this link's suggestions to try and recover your system.

Using a malware removal tool may tell you what you've been infected with. Realistically though even if a malware removal tool seems to work you cannot be sure it's been successful - some malware is incredibly persistent and you can sink a lot of time trying to clean it off a system with no success. This is why the general advice on this site is to save your data, wipe your system, and restore your data and programs.

Also, keep your system updated in the future. The majority of malware out there uses well known security holes that have been patched for weeks or months, and uses flaws on not just the OS but Java, Adobe Flash, and such-like. So keep all your software up to date, not just Windows.


Is it safer to design websites and servers with HTML5 rather than flash? I run a small business, designing and building websites. Currently our websites we build use Adobe Flash.

We are thinking about migrating to HTML 5, are there any security advantages in doing such a thing?

The risks of Flash are client side.  When viewing an compromised site that is well designed (not susceptible to XSS), there should be no difference in security between Flash and HTML 5 since the content is not malware.  The main security problem with flash is for the client.  When they visit a site infected with Flash based malware, bad things can happen to their computer.  It isn't a server side concern.


Possible to connect to VNC server only with a NTLM Hash? I'm using a training lab to learn computing security. And I retrieved the hash of the admin in this form:

admin:1001:NO PASSWORD*********************:D4BF5A8658AFXXXXXXXX5B8DBB60859746:::

So, I just have the NTLM part (not the LM), and cracking password is very hard without LM part.

So I would like to know if there is a tool to connect to the VNC service (port 5900) of the remote computer only using the NTLM hash.

Yes, use psexec module from Metasploit.. however, for this to work port 445 should be open on the target. psexec module will require the username and password hash to deploy a meterpreter backdoor. once, achieved you can run the vnc post exploitation module and will be presented with a nice GUI of the target, All the best.


What happens with a subpoena and a system designed to protect itself from you? After reading about the recent Dropbox issue I'm starting to wonder if they could legally keep their initial promise.

Lets say that you're like Dropbox or Lastpass and you store users' information in such a way that you can't open a user's files. What do you do when you're subpoenaed for a user's files? (I'm looking for answers besides getting a lawyer.) How do you get a user's information when you designed the system so you can't?

Even if you tap the connection looking for their password, that doesn't work if the file is downloaded by the user then decrypted locally.

How would sites like Dropbox or Lastpass respond to a subpoena like this?

Lets say that you're like Dropbox or Lastpass and you store users information in such a way that you can't open a users files. What do you do when you're subpoenaed for a user's files?

This is not true for your examples, but let's assume you operate a system in which the encryption is done client side and there is no further authentication.

It's quite likely that instead of a subpoena your servers are seized unless you are seen as a large company for which this would be disproportional.

A subpoena will probably include requests for logs including ip-addresses and usernames. It may include a request for usernames/passwords in some jurisdictions or an alternative access to the account. It may include a backup of the stored information.

You can comply with all of these requests in the scenario. Sure the backup will be useless unless the police get further information or are able to guess the encryption key (e. g. if it is password based).

In any case it is best to get a lawyer to reply. This is especially true if you cannot comply with the request in letter or intention. The lawyer will be able to explain the reasons in the "correct language" and therefore make it less likely that your servers will be seized.


How to detect whether a GnuPG private key has passphrase on it from a script? I've written a script to help our developers store a copy of their private keys without a passphrase inside our Puppet tree (not committed to Git) so our Vagrant boxes can use Hiera with eyaml + gpg (https://github.com/sihil/hiera-eyaml-gpg) to access secret data during testing.

The script works great, but I'd like to also automate the process of verifying that the secret key has been stripped of a passphrase properly in the copy.

So far, the only way I found is manual - execute gpg --homedir ... --edit-key keyid and then in the interactive prompt run password and look for a This key is not protected. message.

I'd like to do that automatically in the script - basically I want to know how does the gpg tool know that it should print this message. From the answer in https://security.stackexchange.com/a/54205/45966 and reading the GnuPG source code in g10/export.c I conclude that "no passphrase" is actually regarded as "passphrase is empty string" and the code actually tries to decrypt a random string with the passphrase and verify that the result contains repeated random pattern.

Is this correct?

If so - is there a way to avoid having to re-implement that entire process myself but instead use gpg command line tool or some Python/Ruby API's to do that for me? I looked at a few Python and Ruby front-ends to gpgme but didn't see something like this there.

I see in g10/build-packet.c that I should expect some different output if the packet is protected or not, but trying to compare dumps of protected vs. unprotected secret keys didn't yield anything except small differences in hashes. I might be mis-interpreting the code there.

From my testings, gpg --list-packets will yield different results depending on whether the key is encrypted or not. A key generated without passphrase will directly have information on the key revealed:

:secret key packet:
    version 4, algo 1, created 1444376378, expires 0
    skey[0]: [1024 bits]
    skey[1]: [17 bits]
    skey[2]: [1017 bits]
    skey[3]: [512 bits]
    skey[4]: [512 bits]
    skey[5]: [510 bits]
    checksum: 9df4
    keyid: [snip]

while a key with passphrase only gives information on the public key parts and string-to-key procedures in use:

:secret key packet:
        version 4, algo 1, created 1378729401, expires 0
        skey[0]: [1024 bits]
        skey[1]: [17 bits]
        iter+salt S2K, algo: 3, SHA1 protection, hash: 10, salt: e182c39f07747f0c
        protect count: 65011712 (255)
        protect IV:  d5 0d 20 dc cb a2 e9 16
        encrypted stuff follows
        keyid: 99543578D453449B

You'd still have to parse the output, but this should be stable enough to directly go for absence of a [whatever] S2K line (there are different S2K procedures, so make sure to fetch them all or use some kind of wild card). Sadly, there is no special --with-colons output for --list-packets that would be easier and more reliable to parse.


Physical vs Logical - Location/Address According to the CJIS Security Policy -

Access Enforcement

  The information system shall enforce assigned authorizations for
  controlling access to the system and contained information. The
  information system controls shall restrict access to privileged
  functions (deployed in hardware, software, and firmware) and
  security-relevant information to explicitly authorized personnel.

  Access control policies (e.g., identity-based policies, role-based
  policies, rule- based policies) and associated access enforcement
  mechanisms (e.g., access control lists, access control matrices,
  cryptography) shall be employed by agencies to control access between
  users (or processes acting on behalf of users) and objects (e.g.,
  devices, files, records, processes, programs, domains) in the
  information system.

Agencies shall control access to CJI based on one or more of the following:

Job assignment or function (i.e., the role) of the user seeking
access
Physical location
Logical location
Network addresses
(e.g., users from sites within a given agency may be permitted
greater access than those from outside)
Time-of-day and day-of-week/month restrictions

Are physical location and logical location are being referred as Physical address and Logical Address here? How these are different from Network Addresses.

Can someone please give the scenarios to make website compliant with CJIS Security Policy?

I cant give a scenario but I can tell you the difference in location.
Physical Location in your terms refer to where your access the site from, as in a physical address.  The logical address is what device you are using.  Because Full blown computers are now the size of cell phones, the definitions have to change to better suit the understanding.  Also you can go anywhere off the map and still access data, for this Physical Location is now deemed as a GPS Location Address.  A network address refers to your IP Address.


Risk associated with Exchange email address as username when AD authentication is enabled In my existing setup, we have Exchange Server joined with Windows Active Directory. Both the username and email address are the same for user accounts. Our support party also recommended using this approach.
But my Management questioned using the same email address as a computer login name. They told me that everyone, including third parties, knows the email address of the company.
When the email address is the same as the username, an attacker only needs to find the password. Management told me that our implementation reduces attacker workload by 50%. If the username is different from the email address, then the attacker needs to find both username and password.
But both my administrator and support team don't like this implementation because their workload will be increased. But their answer also not satisfactory to management. The support team said it is a standard.
What are the risks associated with this implementation or is this a secured approach?

Management is expressing the risk of user enumeration and suggesting "security through obscurity" as a solution. A determined adversary will find this technique as nothing more than a speed bump. A better way to approach this is to identify:

Excessive failed login attempts. This is two fold since you need to identify any attempts to brute force an account. Where many passwords are used against a single user account. The other aspect is identifying password spraying where a single password is attempted against many user accounts or where these techniques are distributed across multiple IP addresses. Identifying and taking action against these techniques will be a significant win since there's virtually no way for the adversary to be successful. Where this technique really succeeds is when the adversary has unfettered access to go through their lengthy password lists. By limiting these attempts, it just isn't feasible for the adversary to guess a password.

Logins from questionable IP addresses. Many large companies offer this functionality where an alert is generated upon successful login from unknown locations. I would suggest sending the alert to a helpdesk account or your central IT to follow-up. This is because an adversary could delete the email while logged in. To get this reporting setup will take development cycles. Hopefully someone can offer a solution that I'm not aware of as it would be quite useful.

Risk from other Services
While your question was only for Exchange there are often other services/applications/websites within an organization. All of which could be a playground for an adversary to use the aforementioned techniques. There have been countless breach disclosures where a forgotten server in a closet was the entry point. So take inventory of services exposed to the public internet and ensure they have similar protections. Then continue to services only accessible to internal users. For internal services, identifying excessive failed logins is probably sufficient since access from an unknown IP wouldn't necessarily make sense. Note that I've seen user's go through a password change without updating cached service credentials and triggering alerts for failed logins. So beware of false-positives! That being said, identifying legitimate abuse of an internal service will be a sufficient indicator of compromise to invoke your incident response process.
WebsiteFailedLogins
Warning: shameless plug. I'm currently finishing up a significant re-write of WebsiteFailedLogins. It's a PowerShell module, which leverages Logparser, to parse IIS logs (a component of Exchange) and identify excessive failed logins. Admittedly it's been many years since I've administered an Exchange server thanks to O365. However, I'm confident IIS will log the appropriate codes where this will be useful. Have a look at the README and Wiki for more information as I think it would make a great fit!


HTML password fields Imagine you are in a HTML page which offers you the password change service. Some websites bring the previous password in a password field, which you can't read. Is it possible to retrieve the password in field? (e.g: source code, sniffing the HTTP session?)

How does HTML handle the "security" of this field?

If they have the real old password in the field you can retrieve it by looking at the source of the HTML page. But usually there is only a placeholder like "this was the old password" which is used to detect if the user changes the password or if something else inside the formular gets changed. With proper security the site cannot even put the old password into the form since the clear text password itself should not be known to the site because the password was stored in an irreversible way (see how your passwords are stored on the internet..).


Should I be concerned about Wayback Machine trying to load scripts from unauthenticated sources? I regularly use Wayback Machine to help find archived versions of webpages that have been taken down or are other otherwise unavailable.

While using the site, I noticed a peculiar warning in Google Chrome's address bar.

Firefox shows a similar warning for insecure scripts.

Should I be concerned that Wayback Machine is trying to load scripts from unauthenticated sources?

(For the record, neither Microsoft Edge or Internet Explorer displayed any warnings)

No, not unless you are using a browser that does not block unauthenticated sources (i.e. plain HTTP) when loading an authenticated source (i.e. HTTPS). Most modern browsers will do this.

The error in this case is:

  Mixed Content: The page at 'https://web.archive.org/' was loaded over
  HTTPS, but requested an insecure XMLHttpRequest endpoint
  'http://wwwb-sentry.us.archive.org/api/3/store...

As the browser blocked the request, it cannot be intercepted by an eavesdropper or Man-In-The-Middle on the connection, therefore you are safe.

It is likely a configuration error on Wayback Machine sending the request over HTTP instead of HTTPS.


Preventing host discovery in network With tools such as Fing (Android app) and netdiscover (Kali Linux tool) its possible to get all connected devices in network.

How it's possible to prevent host discovery in a network?

There are multiple approaches an attacker can use for host discovery. I believe netdiscover uses ARP requests for host discovery, which operates on the Ethernet protocol (see https://github.com/alexxy/netdiscover). Other tools like nmap operate at higher protocol layers (ICMP, TCP/IP, UDP/IP, see https://nmap.org/book/man-host-discovery.html). A solution which prevents host discovery at higher protocol layers may not prevent host discovery at lower layers, and vice versa.

A firewall is a common solution for preventing host discovery. For example, Linux can use iptables to prevent host discovery at higher layers and arptables at the lower layers. This doesn't protect against sniffing of traffic by a passive attacker (netdiscover can do this).

Network segmentation or VLANs could further protect against host discovery at the Ethernet layer.

https://en.wikipedia.org/wiki/Private_VLAN
https://en.wikipedia.org/wiki/Network_segmentation


How to prevent cross site scripting in wordpress? I did source analyzer with third party services to my wordpress project. It found out that there are heaps of cross site scripting vulnerabilities. One of the example is like image below. How do I prevent the cross site scripting? Should I put validation in front end view (HTML / CSS / JS) or on back end (PHP / Wordpress)?

How do I prevent the cross site scripting?

Perform input validation and output encoding. Only allow characters that you expect, for example if you only expect digits, the back-end should not process regular characters.

Sometimes you expect a specific length, if the back-end detects it's either smaller or larger, do not process it.

Same goes for special characters, if you request a first name, don't allow special characters such as "<", ">", "$" etc.

  Should I put validation in front end view (HTML / CSS / JS) or on back end (PHP / Wordpress)?

Validation from a security perspective is always performed server side. Client side validation is only done for user experience.


What is the "Moose" worm and how can I protect myself from it? I have heard from others that there is a new worm called "moose". This actively targets and exploits home routers.

What are the effects of this exploit?

How can I protect myself from this?

Can I check if my router is vulnerable?

ESET released a report about the vulnerability here. Their key findings are:

  Linux/Moose targets consumer routers and modems including the hardware provided by Internet Service Providers (ISPs) to consumers
  The threat is built for deep network penetration spreading past firewalls
  It can eavesdrop on communications to and from devices connected behind the infected router, including desktops, laptops and mobile
  phones
  Moose runs a comprehensive proxy service (SOCKS and HTTP) that can be accessed only by a specific list of IP addresses
  The operators use the infected devices to perform social network fraud on Twitter, Facebook, Instagram, Youtube and more
  Moose can be configured to reroute router DNS traffic, which enables man-in-the-middle attacks from across the Internet
  It affects Linux-based embedded devices running on the MIPS and ARM architectures

If we look at how it spreads one statement is very important here:

  Last but not least, this threat spreads only by compromising systems
  with weak or default credentials. No vulnerabilities are exploited by
  the malware. Although downplayed by system administrators, this attack
  vector has been effective at compromising a lot of Internet-connected
  systems. As FireEye recently stated: “Brute forcing credentials
  remains one of the top 10 most common ways an organization is first
  breached.

They have listed a some of the devices which may be affected:

Network equipment vendors

3Com, Alcatel-Lucent, Allied Telesis, Avaya, Belkin, Brocade, Buffalo, Celerity, Cisco,
D-link, Enterasys, Hewlett-Packard, Huawei, Linksys, Mikrotik, Netgear, Meridian, Nortel,
SpeedStream, Thomson, TP-Link, Zhone, ZyXEL

Appliances vendors

APC, Brother, Konica/Minolta, Kyocera, Microplex, Ricoh, Toshiba, Xerox

Internet of Things vendors

Hik Vision, Leviton

Indicators of compromise

  If the credentials can be used via Telnet to login, if Telnet is
  enabled by default and if a shell access can be obtained by typing sh
  in the device’s prompt, then these are very good indicators that a
  device could be infected by Linux/Moose.

Prevention

  Change default passwords on network equipment even if it is not
  reachable from the Internet. Disable Telnet login and use SSH where
  possible. Make sure that your router is not accessible from the
  Internet on ports 22 (SSH), 23 (Telnet), 80 (HTTP) and 443 (HTTPS). If
  you are unsure about how to perform this test, when you are at home,
  use the "common ports" scan from the ShieldsUP service from GRC.com.
  Make sure that the above mentioned ports receive a Stealth or Closed
  status. Running the latest firmware available from your embedded
  device vendor is also recommended.


What is the actual mechanism when we used VPN on HTTPS Will the VPN intercept the client's connection and read client's sending content or insert something else into clients's sending content? What is the actual process when we used VPN to access to one HTTPS website?

Well, you're simply sending your encrypted web traffic through the VPN tunnel. The VPN doesn't care if it's HTTPS or any other protocol. They just forward your traffic.

So, if you visit an HTTPS site through a VPN...

Your ISP sees how you establish a connection to the VPN provider. They see the VPN server's IP which you're connecting to and can observe the handshake. Afterwards, they see how you exchange encrypted data which they can't decrypt or inject malicious packets into.
The VPN provider sees the IP of the website you're visiting. They can observe your TLS handshake with the web server and due to SNI they most likely also see the server's hostname. Afterwards, when you're interacting with the website, they only see you exchange encrypted data which they can't tamper with.

You'll probably also issue a DNS query which, if it is configured to go through the VPN, is only visible to the VPN provider and not your ISP. Also, this is assuming a correct setup with certificate checks. That is, your VPN client needs to verify that the certificate provided by the VPN server is legitimate (to ensure your ISP didn't tamper with it) and your browser needs to verify that the certificate provided by the website is legitimate (to ensure your VPN provider didn't tamper with it).

Somewhat related:

Can a VPN decrypt my SSL traffic? (They can't, unless you ignore certificate warnings.)


Does secure remote password verifier transmission need to happen out of band? With relation to the necessity of a verifier being transmitted from the client to the server prior to any handshake steps, I was wondering how this is supposed to happen securely?  To me this seems like a user registration before using the system, but doesn't that defeat the idea of zero-knowledge password proof?

I'm having trouble understanding how you are supposed to keep the veifier a non-public variable when it's required to be sent from the client to the server in the first place.  Would an initial ping to the server followed by a request for communication suffice? (But that doesn't really keep the verifier a secret...)

You seem to be talking about Password-Authenticated Key Exchange protocols.

But the problem you're describing is a general one: It is (currently) impossible to create an authenticated channel out of thin air. The best we have is PKI, a scheme to delegate the authentication to centralized entities which can be trusted by the client for their particular purpose, so that we don't have to explicitly authenticate each and every party we talk to.

Given PKI and thus server authentication, you can initialize a zero-knowledge mutual password-authentication within a secure channel created by server-side-authentication. Just the way that people today register accounts and passwords in an SSL-secured channel.

The difference is how vulnerable your protocol is to variety of different attacks in later stages of the transaction: Do I have a chance to capture your password in each and every login-process? What does the server and browser know at the end of a ZK-login? What is the impact of misunderstood PKI certificate warnings, assuming that the warning is caused by an active attack in 0.1% of the cases?


Is supporting older version of Java dangerous We have a code library that is used by developers and requires using Java 1.8. However, there have been requests to support 1.7 and it would be trivial to do so.

The library is basically a Java wrapper for a .NET CLI tool, so there is no real need for security outside of the .NET executable that is called.

I have a couple of questions about the security issues with Java:

Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?
Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?
Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

Is there a security risk involved with have the Java 1.7 JDK installed on our build machine if all it is being used for is to compile the jar file?

Probably not, but there's no need to do that: javac provides the -target flag, which allows you to generate classfiles compatible with any version (provided that you don't use source features or call library methods that were not supported by that version).

  Are there any major security concerns with supporting Java 1.7 when it is being used as a wrapper for a CLI tool?

Probably not. Security concerns with Java generally involve implementation issues in the JVM (Java Virtual Machine) or the libraries that it uses. There are also some issues with third-party libraries that enable exploitable behaviors (for example, Apache Commons Collections supporting a Map implementation that could execute arbitrary code).

If you're simply compiling the same code for different target architectures (1.7 versus 1.8) then you are almost guaranteed to get the same bytecode output. You can compare the bytecode generated for each version with the javap program.

  Does running our library (that uses 1.7) create any security risks if it is being used in a program that is being compiled with Java 1.8 (or the latest version), or does that mitigate the security risks and put in place the security patches of later Java versions?

I can't understand the question that you're asking, so I'll answer the question that I think you're asking: if you run a 1.7-compatible compiled class on an up-to-date 1.8 JVM then you receive all security benefits of that JVM. If running on a 1.7 JVM or an older 1.8 JVM you are subject to whatever security flaws were present in that VM.

Note that many open source libraries are targeted to 1.6 and even 1.5. The only real reason to target a newer version is if you use language features (eg, Lambdas) or library functions that weren't available in the earlier release. In that case, picking the minimum necessary target version will prevent an earlier installation from compiling with the class, because each Java version uses a different classfile version and older compilers won't accept newer files.


How to import plain public key into java keystore? I want to import a lone public key (.pem) into a Java keystore (.jks). I don't have the private key. As I understand, the public key must be wrapped as a certificate, so that I can import it into a java keystore.

The .pem content looks like:

-----BEGIN PUBLIC KEY-----
key_content....
-----END PUBLIC KEY-----

Is there a possibility to convert a plain public key to a certificate, so that I can import it into a java keystore? Or is there any other option to import a public key into a java keystore?

Simply converting the public key from .pem to .der is not enough. The public key is used for programatic encryption of data, not for TLS.

The standard (or at least conventional) certificate request process does require the privatekey matching the publickey to be certified. The pre-packaged operations of Java's keytool utility and the openssl commandline are limited to this standard process, as are several other existing Qs.

However, it is not fundamentally necessary. As long as you have a privatekey for the certificate issuer, nominally a Certificate Authority, and a certificate for that CA key or at least some critical metadata normally embedded in such a certificate, it is possible to issue a child cert for a given child publickey.

This can be done with OpenSSL by calling the X509_* routines in libcrypto from custom code; in Java the classes used by standard keytool are not officially part of the JRE spec but are open source, but if you can use the BouncyCastle third-party libraries (bcprov + bcpkix) they directly expose the needed functions in a convenient and documented/guaranteed form, so I show that. This creates a very minimal certificate with little of the information and especially none of the extensions that are commonly present in real, CA-issued certificates. If this is not sufficient for your needs, ask a more complete question.

For simplicity I read the (subject) pubkey PEM from a named file, and the CA key and cert from a JKS in a named file at a named alias. These sources of information can be replaced by others as you wish. I also don't do any error handling leaving Java to do its default stacktrace; you may need better.

import java.security.*;
import java.security.cert.X509Certificate;
import java.security.interfaces.RSAPrivateKey;
import java.util.Date;
import org.bouncycastle.asn1.x500.X500Name;
import org.bouncycastle.asn1.x509.SubjectPublicKeyInfo;
import org.bouncycastle.cert.X509v3CertificateBuilder;
import org.bouncycastle.openssl.PEMParser;
import org.bouncycastle.openssl.jcajce.JcaPEMWriter;
import org.bouncycastle.operator.ContentSigner;
import org.bouncycastle.operator.jcajce.JcaContentSignerBuilder;

static void Se179526FakeCert (String[] args) throws Exception {
    // pubkey.pem cakey.jks pw alias
    Object spki  = new PEMParser (new FileReader (args[0])).readObject();
    KeyStore ks = KeyStore.getInstance("JKS");
    ks.load (new FileInputStream (args[1]), args[2].toCharArray());
    PrivateKey cakey = (PrivateKey) ks.getKey (args[3], args[2].toCharArray());
    X509Certificate cacert = (X509Certificate) ks.getCertificate (args[3]);
    Date now = new Date(), exp = new Date(now.getTime()+30*86400*1000); // 30 days validity

    ContentSigner signer = new JcaContentSignerBuilder ("SHA256with"+cakey.getAlgorithm()).build(cakey);
    byte[] enc = new X509v3CertificateBuilder(
            /*issuer*/new X500Name (cacert.getIssuerX500Principal().getName()), /*serial*/BigInteger.valueOf(now.getTime()),
            /*validity*/now, exp, /*subject*/new X500Name ("CN=dummy"), /*spki*/(SubjectPublicKeyInfo) spki
        ) .build(signer) .getEncoded();
    // .addExtension's if&as needed before .build
    Certificate cert = CertificateFactory.getInstance ("X.509") .generateCertificate(new ByteArrayInputStream(enc));
    // could now store in a keystore; or to write out in PEM:
    JcaPEMWriter out = new JcaPEMWriter (new OutputStreamWriter (System.out));
    out.writeObject (cert); out.flush();
}


What current algorithms are considered (un)secure? With the new release of Windows 10, Microsoft has given .NET, Javascript and C++ developers a whole new bunch of options for cryptographic algorithms.

Where as the old .NET code only allowed AES and RSA, the new Windows 10 libraries allow thos algorithms:

Symmetric Algorithms

AesCbc
AesCbcPkcs7
AesCcm
AesEcb
AesEcbPkcs7
AesGcm
DesCbc
DesCbcPkcs7
DesEcb
DesEcbPkcs7
Rc2Cbc
Rc2CbcPkcs7
Rc2Ecb
Rc2EcbPkcs7
Rc4
TripleDesCbc
TripleDesCbcPkcs7
TripleDesEcb
TripleDesEcbPkcs7

Asymmetric Algorithms

DsaSha1
DsaSha256
EcdsaP256Sha256
EcdsaP384Sha384
EcdsaP521Sha512
RsaOaepSha1
RsaOaepSha256
RsaOaepSha384
RsaOaepSha512
RsaPkcs1 (represents an RSA public key algorithm that uses PKCS1 to pad the plaintext. No hash algorithm is used)
RsaSignPkcs1Sha1
RsaSignPkcs1Sha256
RsaSignPkcs1Sha384
RsaSignPkcs1Sha512
RsaSignPssSha1
RsaSignPssSha256
RsaSignPssSha384
RsaSignPssSha512

The algorithms that are italic are those I assume already approved as "insecure"/should not be used.
So what of those algorithms are still secure, which are explicitly unsecure?

I already considered this post, but I guess it's already outdated, again?

An algorithm can be secure only if used properly within a protocol that matches what the algorithm was meant to do. So none of the algorithms you list can be deemed "secure" in an absolute, unconditional way.

On the other hand, some algorithms are necessarily insecure and should never be used (for a security purpose). In your list, these are:

DES block cipher: it uses a key which is too short to be strong against the most stupid of brute forces attacks. 3DES, however, is fine in that respect.
Block ciphers in ECB mode tend to leak a lot of information on the encrypted data, with "real-world" plaintext data, and should be avoided except in some very specific cases.
RC4 has some biases which are rarely deadly, but are still a concern.

The rest of the list is "fine", in that they can be used properly and provide useful security. A lot of people nowadays are very nervous when they see "SHA-1" but this is a crowd-induced reflex which is mostly unsubstantiated.


How do I stabilize a reverse shell in when the attack box is using powershell? So I've managed to get a version of netcat onto my windows machine and I can run the standard:
nc -lvnp 1234

and this properly connects to the victim's machine, but it's a very fragile connection. Ctrl + C will just drop the connection, tab doesn't auto complete, and the up and down arrows don't give me history. On linux, the common way to stabilize the shell looks like this:
python -c "import pty; pty.spawn('/bin/bash')"      //run on victim's machine
CTRL + Z                                            //switches over to your machine
stty raw -echo                                      //run on your machine
fg                                                  //switches back to victim machine
export TERM=xtrm                                    //run on victim machine

The problem is that ctrl + z just locks up Powershell so that's about as far as I get. Even if I use a Kali linux docker container, I am still running that container through Powershell or CMD and I just just can't get past that ctrl + Z issue.
How do I stabilize a reverse shell through Powershell or CMD?

it's a very fragile connection. Ctrl + C will just drop the connection, tab doesn't auto complete, and the up and down arrows don't give me history.

It's not fragile. When you type Ctrl+C, the shell sends a SIGINT to the running process, which happens to be nc. This causes the process to terminate, breaking the connection. Tab doesn't autocomplete and arrows don't provide history because you aren't using a pty.

ctrl + z just locks up Powershell so that's about as far as I get.

Once you run that Python command to set up a pty, you can use keys to view history. However, on Windows, Ctrl+Z is EOF (equivalent to Ctrl+D on Linux). On Linux, Ctrl+Z will cause SIGSTOP to be sent to the running process, and it will be detached from the terminal. Because you are running Powershell, when you type Ctrl+Z, it is interpreted by Windows.


Redirected to unsafe page on freshly installed Windows 10 This is my first question in security, so let me know if something about the question should be fixed.

Some background information:
My Windows 10 laptop was starting to get realy, realy slow when browsing the internet (Chrome lagged alot when fetching simple pages like www.google.com). However i could still play rather demanding games without too much trouble. A week ago i got a call from my internet provider telling me a unit was sending spam-emails from the IP of my appartement.

To try to fix this, i ran a full AVG-scan on both my Windows 10 units (nothing was found). I also had a raspberry pi, open for SSH-Connections with default username and password (very bad practise, i know) which i turned off and disconnected.

My guess was that is was the PI that was responsible for the spam-emails. But since my main laptop was much slower than it should be, i did a fresh install of Windows 10 today, through a bootable USB.

Now to my problem:
The first thing i did, on the new Windows 10, was to open edge and type www.google.com, but i got no response, just a blank page, tried closing Edge and redo, same issue. Then i tried Internet Explorer and i typed in www.google.se, and i somehow ended up at a "There are hot womens in your neighbourhood"-site (the domain ended in rsc.cdn77.org).

My question:
What can be the reason i was redirected to that page on a freshly installed Windows 10 and should i still be worried? Can my router be infected (its a standard router from my internet provider on which i could not lockate the DNS on)? Can another unit on my WiFi be infected and cause this (the only other units connected was two Android phones, a TiVo and a couple of chromecasts according too me and according too the status page on my router)?

It sounds like your router has been infected by a dns hijacking malware.


Ways to obfuscate web browsing habits Web browsing metadata provides a lot of insight on person's habits. How can I reduce that insight? Is there something like "Detachment 2702" (http://en.wikipedia.org/wiki/Cryptonomicon)  plugin for browsers?

Some basic things adversary should not be able to do:

serve reliably relevant ads/product/youtube recomendations
discover when I arrive at home or go to bed
flag me for reading dissident articles and watching DIY video about gas masks
flag me as the user that hogs most traffic from my ISP
flag me for using VPN/TOR

You could also create a "traffic generator" that randomly browses all kinds of sites at all hours.  It would need to do a full impersonation where it visited a page and pulled down all of the resources (css, javascript, images) and then followed links, etc.

A really good impersonator would browse at human-speed and develop habits such sites it likes to revisit or things it searches for.

Generate enough random traffic and your traffic should blend right in.  It won't hide your behavior but it will make it difficult for it to attribute it to you.


Best practice / Risk Assessment payment websites I have two websites which do both accept payments on a subdomain. The subdomain is an independent system from the main website.

I have a question regarding the best practice to decide which of the following setup is the most secure (Of course, each individual website has to comply with PCI DSS etc. but this shouldnt be topic right now)

Version 1: Both payment websites are hosted on the same, independent server. I can see the advantage in being able to make the server more secure, as more unnecessary systems (e.g. webmail which is used by the primary website, ftp access etc) can be shut off, more stricter firewall rules can be established (e.g. no ftp, no port 80 connections etc, no email service). However, when someone manages to gain access to the server, he could tamper with both websites at the same time.

Version 2: Each payment website is hosted on the same server as the primary domain. The advantage / disadvantage are reversed compared to Version 1.

Is there a best practice? Do I assume that the risk of having both website hacked is minimal on Version 1 and thus the most favorable? Or is the risk of having multiple credit card processing websites hacked at once too high?

Thanks for your advice!

While there will be a lot of opinions around this, from a numbers viewpoint, I believe that having a common payment site independent from your other web sites is more economical and secure.

Reduced attack surface.  The single site should have a very simple API for your other sites to consume:  "Customer X wants to pay amount Y for order Z", that sort of thing.  This limits the possible ways for an intruder to violate the system.  As you need to examine every single input for a flaw, there are simply fewer inputs to examine.
Reduced audit scope.  When you start dealing with payments, you must deal with PCI compliance.  Payment systems are really onerous to certify.  You don't want to have to pay the auditors extra to crawl over all your app servers just because they may have some payment data in them.
A breach can easily be more disruptive than you imagine.  If you're thinking that you're going to expose either X accounts hosting on one server each, or 2X accounts hosting on a common server, either breach has the potential to be so detrimental to your common business that both entities may go out of business entirely.  Let's see if I can draw this:

    Number of     |
accounts breached | Progressively larger impact to business
                  |
    10^1          | Small fines, increased auditing
    10^2          | Larger fines, greatly increased auditing expense
    10^3          | Internet/Yelp impact to brand reputation, lawsuits
    10^4          | Local newsworthy impact to brand
    10^5          | Class action lawsuits, regional impact to brand
    10^6+         | National/international impact to brand

At every point on the scale your business' very survival is at increased risk.  Would risking 2X accounts because you include two web sites change the potential impact?  Not so much.

I think you're better off pooling your resources and securing a single payment site.  And the more you look at this problem for smaller retailers, the more I recommend contracting with a payment gateway, and offloading that risk from your core business of selling widgets or gizmos.  If a payment provider is breached, that generally won't reflect as badly on the web sites that used them.  If it helps, think of the extra cost as an investment in reputation insurance.

Even if you choose to go with your "version 2", I would still recommend each web site maintain its own payment gateway as architecturally independent from the rest of the web site as possible.  That means separate payment servers from the web servers, separate databases for payment data, etc., for the same reasons:  to reduce the attack surfaces and decrease audit scope.