What is more safe for browsing the web: PC or smartphone? The scenario is: somebody without concern about security is navigating through the web. This person will access doubtful websites, like adult content or media sharing, for example.

Between a pc with Windows and a smartphone with android, which one is a less bad option for this person? If the answer change depending on windows or android versions, please specify this versions.

First, here I compare an up-to-date Android phone which receives regular updates with a Windows PC which receives regular updates. While this might be the normal case if you buy a PC with Windows 10 it is not guaranteed if you just buy a cheap Android phone. Thus, I assume that you use a vendor and product known for its good product support, like phones from Google or the Android One phones. Even then the phones will only get updates for a few years, which is usually not as long as a PC would get updates. Thus, you might need to replace the phone after a few years with another one.

With this in mind ...
The security features of the underlying OS in terms of protecting the applications itself are basically the same, i.e. both provide hardening of the kernel, offer layered security with sandboxes inside the browser etc.

One major disadvantage of Windows compared to Android is that in Windows all applications started by a  user essentially run as the same user and can thus affect each other. This means that a compromised word document could lead to the installation of malware which could read the password store of the web browser. In Android instead the different apps are more isolated between each other since they are running as different users and data have to be explicitly shared between the applications except for data stored on some common storage where all apps have access.

Another advantage of Android is that applications are usually installed from the Google Play Store and the user needs to be explicitly go into the settings and allow apps from third-party places to be installed. And while Windows has some kind of app store too it is currently common to install apps just downloaded from the internet, from some CD-ROM or an USB drive. This attack vector is actively used to trick users into installing some apps, because they are allegedly needed to view a video on some (usually illegal) video sharing site, allegedly are the security update for Adobe Flash which is needed or similar. While an app store like the Google Play Store might contain bad apps too (and often did in the past) it is still much less likely to get a bad app from the app store than one would get from just downloading something from the internet. And, as explained in the previous point, the harm a malicious application can do in Windows is significantly higher than what it can do in Android.

Additionally entire classes of attack vectors which affect PC's are not relevant on Android phones: there is no Flash, no Java applets, no macros in Office documents, no EXE, SCR, ..., which means many of the typical malicious payloads in mails will simply not work. Credential phishing done through mail or by tricking users when browsing the web is relevant on both platforms though.

One main disadvantage of a phone vs. a PC is the smaller screen size and therefore reduced information and the ways information can be displayed by interacting with the device. For example there is no such thing as hover over a link or click right for a context menu in order to receive more information about the real link vs the claimed link. Often the URL of the visited site is also not shown to save crucial screen space for the actual content.  But, given your intended non-technical audience this loss of information might not be that much of a problem since this kind of audience can probably not deal with this detail of information anyway.

But in summary I think that an Android phone which is currently up-to-date and will be kept-up-to-date (which means buying a new one after some years) is the better choice for a non-technical person with only a few needs in terms of communication, i.e. basically web browsing, mail and messaging.


Are there password/passphrase guessers/crackers which can utilize facts supplied about the target? I was just reading a discussion about cracking passwords that said the person running the tool might know things about the target like the birthday of his first girlfriend's dog but the tool won't.

This got me thinking. Are there password guessing tools that can include as input a list of known facts about the target, possibly obtained through social engineering, such as important dates and names of family, pets, persons they have various kinds of relationships with?

Such a tool could weight things like the years, the days of the week, names of months, in the dates, and first names, surnames, nicknames, pet names etc to give them higher priority in combinatorial dictionary attacks.

Who's your daddy

CUPP

Description and download link is in the linked page(s).
Downside is (as far as I know) they can be only used under Linux.


Is it possible to transfer malware/viruses through a KVM Switch, from one computer to others? I am curious about the transfer of malware from one machine to another by use of a KVM Switch.

I am looking to connect a KVM switch between my computers up to my new testing machine, and want to make sure that if something happens to the testing machine, that I somehow wont infect other computers attached via the KVM Switch.

Note: for those who don't know what a "KVM Switch" is, it is essentially a device that connects a Keyboard, Video-Device, and/or a Mouse between multiple computers that can be switched with the press of a button.  There are many kinds that do many things.  Some are specific to one or the other( i.e., keyboard and mouse only), and others do all sorts of cool things such as audio.

Note 2:  The "Testing machine" is a machine that will be used for vulnerability learning and testing of applications for exploits via sites such as OWASP.  I am not sure what I will encounter when doing this, but since these sites are dedicated to vulnerability testing, and meant to be exploited, who knows what people could do to it that could be very bad for the network and it's computers.

So essentially is it possible to transfer malware through a KVM switch, and how likely is something like this to occur?

EDIT:  Just found this Can a KVM switch be vulnerable through a VGA port?

Not sure if this would be an issue in my case, but thought it would be an interesting post to add.  It seems the issue is the "VGA Port," but I would assume USB could also be interfaced and connected to, to execute malicious code...  The question is...  How likely is that to happen?  I would assume it would be easier to connect over USB, than VGA, but not sure if something special is needed in how the malware transfers over.

Theres 3 ways a USB KVM switch could infects its "neighbour":

1: Either, if the KVM switch supports firmware upgrade over USB without any physical button press to put it in "upgrade mode".
Then a BadUSB style of attack could be used to reprogram the KVM switch to send commands or similiar.

2: If the KVM switch's USB host accepts anything, including USB drives, and you have connected a USB drive to it. If the "bad" computer infects the drive, and you then push the button to switchover, the infected USB could also infect the "clean" computer.

3: If any device behind the KVM is vulnerable, for example a keyboard or mouse, to BadUSB, and then the device is "infected", and you switchover.

However, a KVM switch that uses PS/2 output, I would say is 100% safe. Even if it's console input is USB.
Eg, the following 2 types of KVM switches are safe:

2 USB ports + 1 VGA/DVI/HDMI port --> 2 VGA/DVI/HDMI ports and 2 purple PS/2 and 2 green PS/2
1 purple PS/2 and 1 green PS/2 + 1 VGA/DVI/HDMI port --> 2 VGA/DVI/HDMI ports and 2 purple PS/2 and 2 green PS/2

These types of KVM switches are safe, even if you use a PS/2 to USB adapter, and/or a USB to PS/2 adapter to connect to it, as the PS/2 lines cannot transfer malicious data, thus no malicious data could be transferred over at button-press.

Yes, the PS/2 to USB adapter connected at the "bad" host end, could of course be infected with "BadUSB" malware, but then the infection would be contained to that host, as the "clean" computer has its own adapter, and the transfer to the KVM switch from host are PS/2.

PS/2 devices that are firmware-upgradeable over the PS/2 line without having to switch to USB mode or similiar - i would say, you can count them on one hand.

Image ports, like VGA, DVI and HDMI, are fully safe, as they cannot mount or send commands to the computer. They can send identification strings to the computer, like the manufacturer name of the screen and its supported rates and resolutions, but to actually compromise anything, the device would then need to take advantage of a exploit in the host computer like a buffer overflow or similiar AND the monitor must be firmware-upgradeable over the image port, so the malicious payload can be installed.

Pretty unlikeably that the computer monitor would be firmware-upgradeable via its picture input AND you get a malware in the "bad" computer that supports infecting the monitor AND the "clean" computer is vulnerable (Buffer overflow or similiar) to bad strings sent via the image port.


How to verify that the certificate of a file is trustworthy? What steps should I take to make sure that the certificate of a file can be trusted. Or is there really a way to be absolutely sure about that?

I am currently implementing this validation using the WinAPI. The validation of a file's digital signature is done using WinVerifyTrust. As the certificate verification, I am extracting all the information about the certificate (like its thumbprint, all root CAs, etc.). However, I don't know how to use it to verify its authenticity.

Any other tips and information about verifying the digital signature and certificate of a file is appreciated.

This answer has an implementation in C++:

BOOL bIsSuccess;
DWORD dwEncoding, dwContentType, dwFormatType;
HCERTSTORE hStore = NULL;
HCRYPTMSG hMsg = NULL;
PVOID pvContext = NULL;

// fill szFileName
...

// Get message handle and store handle from the signed file.
bIsSuccess = CryptQueryObject (CERT_QUERY_OBJECT_FILE,
                               szFileName,
                               CERT_QUERY_CONTENT_FLAG_ALL,
                               CERT_QUERY_FORMAT_FLAG_ALL,
                               0,
                               &dwEncoding,
                               &dwContentType,
                               &dwFormatType,
                               &hStore,
                               &hMsg,
                               &pvContext);

  To verify the signature of the file I would recommend you to use CertGetCertificateChain and CertVerifyCertificateChainPolicy to verify not only that the certificate is valid in general, but that it (or all its parents) is valid for authenticode (szOID_PKIX_KP_CODE_SIGNING). CertGetCertificateChain can be used for different revocation scenarios. You should do two separate calls with CERT_CHAIN_POLICY_AUTHENTICODE and CERT_CHAIN_POLICY_AUTHENTICODE_TS to verify that both Authenticode chain policy and Authenticode Time Stamp chain policy are valid.


Can a smartphone be hacked by calling it? I have received call from international number (0012024558888). After receiving it I cut the call as it was irrelevant to me and I did not  give any information to them. Now I  doubt it as spam/scam call. My question is that can they hack personal information from my mobile (like messages etc,.)?

Very unlikely. I have never heard of an exploit in any cellphone operating system which can be exploited by taking a call from a malicious caller. If there were something like that, it would likely have made some news headlines, because it would be a huge vulnerability which would affect millions of end-users and would likely get widely exploited not just by criminals but also by juvenile pranksters.

It's not possible to prove a negative, though. Maybe there is some obscure vulnerability I have never heard of. But that's really nothing you should worry about unless you are a target which is so valuable that you are worth burning a zero-day exploit on.


Is this vulnerable to XSS exploit? A typical ajax call:

$.ajax({
  url: "http://mywebsite/script?param=" + $("#field").val(),
  dataType: "jsonp",
  success: function(response) {
      $("#id").html(response);
  },
 });

sends a parameter .
The parameter is filtered and sanitised on the server side.
The server returns a simple text response that is used to be displayed on the HTML page.
However it is possible to intercept the response and include   tag.
Because the code uses $("#id").html(response) to display the response, the modified response, including  content will be executed .

As this occurs only when the server response is manipulated and before displayed on client, is this vulnerable to XSS ? How can this be exploited ?

As preventive method is it better to use $("#id").text(response);
instead of   $("#id").html(response) to ensure the response string, even when intercepted, is displayed as text ?

You have not given us enough information to determine if this is vulnerable to XSS. XSS occurs when a user input is displayed in a browser without proper escaping. For example:

$.ajax({
  $("#id").html($("#field").val());
 });

is vulnerable because the input value from #fieldis displayed in the browser without escaping.

If we look at your example:

$.ajax({
  url: "http://mywebsite/script?param=" + $("#field").val(),
  dataType: "jsonp",
  success: function(response) {
      $("#id").html(response);
  },
 });

a vulnerability exists if response contains all or parts of #field's unescaped value. If response can only contain constant strings such as OK and Error, or if there was proper HTML escaping done on the user input, then you are secure. Otherwise, you have a vulnerability.


Could a certificate authority and a ISP preform a MITM attack on HTTPS traffic? I'm just wondering if it is technically possible for your ISP to work with a certificate authority (either compelled by a government agency or otherwise) to create a MITM attack to see into your https traffic.  I've used a few MITM servers from time to time to look at network traffic. When it's encrypted, I'll install the locally generated certificate from the MITM software on my OS and just like that I'm seeing the green locked icon and able to see into HTTPs connections.  So I'm wondering is it possible for an ISP to get a CA to mint certificates on the fly for whatever website a user is accessing and give the user of the ISP an https page with no warnings or errors while still being able to see the traffic.  I'm going to of course exclude Certificate pinning.

So I'm wondering is it possible for an ISP to get a CA to mint certificates on the fly for whatever website a user is accessing and give the user of the ISP an https page with no warnings or errors while still being able to see the traffic.

While it would technically be possible to do so it would be overly complex. It is much easier that a CA creates a new intermediate CA certificate which the ISP then can use to issue new certificates on the fly itself. This will work as long as the domain is not explicitly pinned to a specific certificate or CA in the client (like done with google, facebook etc in modern browsers) since the browser will trust any locally trusted CA for any domain.

Publicly trusted CA actually sell intermediate CA in some cases but usually explicitly forbid misuse for MITM. Such "accidents" still happened in the past, see here or here. See also Can a nation-state adversary perform a MITM attack by compelling a CA to issue them with fake certs? for a related question.

Note that a CA which either deliberately issues false certificates, was compromised or shows otherwise bad behavior will usually be revoked as trusted from the browsers, no matter how big the CA is. This happened in the past with DigiNotar, Startcom/WoSign and Symantec.


Resources on security risks of NFC Mobile phones are, increasingly, starting to support NFC.  NFC can be used for a rich set of applications (including mobile payments, identity, and file sharing).

What are primary security risks associated with NFC?  Are there any research papers, white papers, or other technical resources available that analyze the security risks of NFC?  Are there any good technical resources on securing NFC-enabled applications?

You can check this paper : http://media.blackhat.com/bh-us-12/Briefings/C_Miller/BH_US_12_Miller_NFC_attack_surface_WP.pdf

It's from a talk given by Charlie Miller at BlackHat 2012 :

  Near Field Communication (NFC) has been used in mobile devices in some
  countries for a while and is now emerging on devices in use in the
  United States. This technology allows NFC enabled devices to
  communicate with each other within close range, typically a few
  centimeters. It is being rolled out as a way to make payments, by
  using the mobile device to communicate credit card information to an
  NFC enabled terminal. It is a new, cool, technology. But as with the
  introduction of any new technology, the question must be asked what
  kind of impact the inclusion of this new functionality has on the
  attack surface of mobile devices. In this paper, we explore this
  question by introducing NFC and its associated protocols.

  Next we describe how to fuzz the NFC protocol stack for two devices as
  well as our results. Then we see for these devices what software is
  built on top of the NFC stack. It turns out that through NFC, using
  technologies like Android Beam or NDEF content sharing, one can make
  some phones parse images, videos, contacts, office documents, even
  open up web pages in the browser, all without user interaction. In
  some cases, it is even possible to completely take over control of the
  phone via NFC, including stealing photos, contacts, even sending text
  messages and making phone calls. So next time you present your phone
  to pay for your cab, be aware you might have just gotten owned.

There is a tons of links at the end.


New denial-of-service vulnerability in TLS protocol, based on shooting down other users' sessions? I think I have a new denial-of-service attack on TLS, and I'd like you to check whether this is a real vulnerability.

I recently learned about the proper way to drop an authenticated client session (see this question).
According to RFC 5246 & RFC 5077 this is done by sending a fatal alert. But nothing is said about whether full session resumption is really required for such dropping or not, which means that actually any client may purge authenticated sessions of any other client, knowing just the sessionID.

The steps are:

connect to server and send client_hello with target sessionID
wait for server answer, which will include server_hello, change_cipher_spec & finished
send UNENCRYPTED fatal alert with any value

RFC 5246 says (§7.2.2):

  Upon transmission or receipt of a fatal alert message, both parties
  immediately close the connection.  Servers and clients MUST forget any
  session-identifiers, keys, and secrets associated with a failed
  connection.  Thus, any connection terminated with a fatal alert MUST
  NOT be resumed.

This works perfectly well in any connection & cipher state, including NULL.

I have just checked the actual OpenSSL implementation. The vulnerability (if it is a vulnerability) is present. What would community say? Am I to push this issue as real vulnerability or is it just the way it should be and nothing to worry about?

To summarize:

It may work, or not, depending on how the server manages its cache for session parameters.
The RFC are not consistent.
It is not a "real" vulnerability.

TLS sessions were initially meant to be an optimization, to avoid client and server doing the full handshake with its "heavy asymmetric crypto" for each connection (the actual cost of such crypto is often overrated but that's not the point). Existing, deployed clients and servers tend to remember sessions for some time, then forget them when it becomes inconvenient to keep remembering (typically, on the server side, when the RAM buffer dedicated to such storage is full, old sessions are evicted). The idea is still that client and server may still do a full handshake, transparently, when needed; the session resumption is opportunistic.

Some deployed systems rely on session resumption to work a bit more reliably; in particular, Web-based applications with client authentication with a smart card: using the smart card implies making a signature with the card, which has a small computational cost (say 1 second) and a high user cost (the human user may have to type a PIN code). However, even in these cases, it is understood that session parameters are stored in RAM only, so if the client browser is closed and then reopened, no session will be resumed and a full handshake will occur.

RFC 5246, in section 7.2.2, contains this paragraph:

  Error handling in the TLS Handshake protocol is very simple.  When
  an error is detected, the detecting party sends a message to the
  other party.  Upon transmission or receipt of a fatal alert
  message, both parties immediately close the connection.  Servers
  and clients MUST forget any session-identifiers, keys, and secrets
  associated with a failed connection.  Thus, any connection
  terminated with a fatal alert MUST NOT be resumed.

This is a blanket statement meant, informally, to deter some as yet unspecified brute force attacks relying on the attacker "trying out" a lot of session resumptions. There are a few enlightening points that must be made about that prescription:

Historically, sessions had also to be "forgotten" when a connection was not properly closed (with an explicit close_notify). However, existing Web servers close connection abruptly, so Web browsers have adapted by keeping sessions "alive" even when they were terminated in a way that TLS-1.0 would frown upon.
This notion of forgetting the session upon a fatal alert does not work on the server when session tickets are used, since, by definition, a server with session tickets does not manage his own memory. In that respect, RFC 5077 and RFC 5246 are inconsistent: this "MUST NOT be resumed" cannot be enforced by a server that uses session tickets.

It so happens that most SSL implementations are reluctant to break laws of physics in order to comply to RFC.
Even without sending an alert, a "fatal condition" can always be forced by an attacker: it suffices for the attacker to open a connection by himself, reusing the same session ID as a connection used by the genuine client. The server will try to resume the session (ServerHello, ChangeCipherSpec, Finished) then expect the ChangeCipherSpec then Finished from the client. Since the client is the attacker and the attacker does not know the master key for the session he is purporting to resume, his Finished message won't decrypt properly, triggering a bad_record_mac from the server. If section 7.2.2 is to be followed, then the server should then forget the session.

It shall be pointed out that the "kill the session by failed Finished" attack expressed in the previous paragraph may be easier to pull off than the one you are describing, since it involves only observing a genuine connection (to get the session ID), not modifying that connection.

The third point above is important because it shows that until it has received a properly encrypted-and-MACed Finished message from the client, the server has no proof that it is really talking to the real client. Arguably, the session is not "resumed" until that point, and therefore should not be "invalidated" for any erroneous condition occurring before that point (be it an explicit alert from the client, or a MAC failure, or anything else). However, the RFC is not clear about that either, so what really happens really depends on how the server manages its cache, at the whims of the server implementor.

The vulnerability is not "real" in that any attacker who is in position to fiddle with client connections can already do a lot more harm by, for instance, responding to the client's ClientHello message with a synthetic alert message or simply random junk that will convince the client that there is no working SSL/TLS server on the other side -- a much more comprehensive denial-of-service than simply making the server and client spend a couple of milliseconds of CPU for a full handshake.


Metasploit Log or Additional Information Re: Exploit completed, but no session was created Almost all of my personal lab work with Metasploit has been unsuccessful. Most commonly I get the message "Exploit completed, but no session was created." I don't know what to do after this happens. Is there any way to read a log or discover more information about why this happens?

Its Metasploit way telling you the exploit failed , because the system is patched and not vulnerable to this exploit, Or  possibly  that you have configured your payload handler wrong and so the payload code can't connect back.


Outbound DDOS attack from a centos server We run a mail server (postfix/dovecot/centos 6.4). The hardware is based on a supermicro chasis with IPMI features.

It also runs a web interface for accesisng mails(Apache web server )

Recently our DC said that we are sending outbound DDOS attacks which touched upto 1.3Gbps as per their saying. They nulled the IP. After our request they re activated the IP again.

Now we are monitoring the server regulerly and seeing abnormal outbound traffcis at a avearge rate of 2mbps we dont sent that much emails) with peaks of upto 30mbps after each 30minutes period.(as per the data of New Relic Monitor)

The provider said that we might be running DDOS reflection attacks. The server logins are safe and authentication log says nothing abnormal

We dont have any DNS server running. Also NTP is running in client mode and it is secured.

nettop, iptraffic,nethogs show everything normal, only transmitted and recieved traffic summary in ifconfig says about the large amount of data sent.

Also we disabled NTP client on our IPMI as i read that supermicro IPMI is vulnerable to NTP reflection DDOS.

AT this point I am clueless and seeking help from experts here. Helps will be appreciated

The first port of call might be to take a packet dump (ie, tcpdump)  and see what it is you're throwing out.


Authorizing a device to access user resources Description:

I am building an information display system. The system consists of the following:

A Django Rest Framework based backend providing a low-level JSON API
A single page application web front-end for users which makes use of the backend
Standalone Raspberry Pi devices which use the JSON API to fetch content to display on a screen

Users create accounts for themselves, after which they can upload media to the server, create playlists and set which of their devices uses which playlist. For example, they can upload an image, create a playlist with the image and then tell one of their devices to display that playlist.

Limitations:

Only the user who owns the media or playlist can access it.

The Raspberry Pi computers cannot act as servers, they can only make requests to the back end.

The Raspberry Pi computers are not used directly by the end user. It doesn't have a keyboard. Ideally, the user just plugs in the device's power and ethernet cables and everything 'just works'.

Each device can have only one owner (or none).

The device only fetches playlists and media (e.g. images, video) from the server.

The device can only fetch playlists belonging to the device's owner.

Problem:

What is a secure way of establishing device ownership and making sure a device can only fetch playlists belonging to its owner? The device obviously does not have the username/password required to access the user's resources in a normal way.

I have considered a solution where the device has a unique ID which is too long to guess and is only available to someone who has physical access to the device.

The user would be able to take ownership of a device by adding the device ID to a list of devices they own.

This ID would be passed along with the device's request for a playlist, and the server would provide access to it if the owner of both the playlist and device are the same.

The problem is that if someone finds out the device ID, they will be able to take the device for themselves or download other peoples' playlists. The device ID also could not be changed.

What would be a better way of fetching playlists from the device? Thank you.

The user would be able to take ownership of a device by adding the
  device ID to a list of devices they own.

What you need is some way to prove that the user is in physical possession of the device.

Going by media (e.g. images, video) it sounds like you have a display of some form, therefore it would be easiest to display some temporary PIN on the device which the user has to enter along with the device ID into your site when they try and add the device to their account.

You could either generate this PIN online and send it to the device, or generate it offline using a protocol such as TOTP.

  This ID would be passed along with the device's request for a playlist

Once you've undertaken the authentication process I would not recommend sending the ID. Instead generate a temporary set of credentials during the authentication process and send them to the device, that way you can revoke the credentials if required or if the user re-authenticates (say they give the device to someone else).

I'd also suggest embedding a unique private key for every device, that way you can easily encrypt the temporary credentials with the device's public key knowing that if anyone else obtains the keys, only the authentic device will be able to decrypt them.


How to apply custom filters for John The Ripper when cracking RAR3 archive password? My problem is that I'm trying to crack RAR file with is encrypted with RAR3 encryption.
Decided to try with John The Ripper.
Here are clues I have from my friend.

Max password length is 8
Only capital letters or digits

And I need now filter to make John crack the password without trying to check small lowercase letters.
On hashcat it's easy to do but program do not support $RAR3$*1 type of hashes.

You will need to be running John 1.9.0 to support masks.  The following John mask specification:
john -1='?u?d' --mask='?1?1?1?1?1?1?1?1'

Will match 8 characters of Upper and Digits.
The MASK documentation file from the distribution is available here and goes into more detail about what you can do with masks.


Can the IV + Salt be the same? During my encryption app i've got the password creation bit:

PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 10000, keyLength);

and later on the actual encryption part:

cipher.init(Cipher.ENCRYPT_MODE, secret, ivSpec);

The initialisation vector need random bytes, the salt needs random bytes, can I use the same (cryptographically secure) random bytes for the salt and the IV or would that weaken the encryption somehow? - It would make storage a little easier if I could.

I'm not talking about reusing the IV or the salt over multiple messages, for each separate message a new array of bytes would be generated, but could I for each individual message double up and use the same newly generated bytes for both the salt + the IV?

EG:

Message 1: Random bytes = h6ds .... Salt = h6ds / IV = h6ds

Message 2: Random bytes = djs9 .... Salt = djs9 / IV = djs9

Message 3: Random bytes = 9sdf .... Salt = 9sdf / IV = 9sdf

... and so on

The IV should be unique for every message encrypted, so no, if you intend to encrypt more than one secret using the key you generate from this password, you cannot reuse the salt as the IV.   Reusing an IV at best leaks information about the plaintext, and at worst, can destroy your encryption scheme altogether (depending on the mode you're using) and so yes, in any case if it is reused, it will indeed weaken the encryption.

If, however, you are not reusing it, and it will only be used a single time, then no, the fact that the same random value serves as a salt elsewhere should have no effect on the strength of the encryption at all.

Edited to add:  There is a one caveat that I don't believe applies in this specific case, but should mention.  Since you are using a KDF to generate the key, the salt constitutes a part of the strength of the key.  If the IV is being exposed to the attacker (Given the wording of the question, I don't think that's the case here) then you make the attacker's job considerably easier when it comes to being able to compute candidate keys, and keys generated from weak passwords become susceptible to dictionary attacks.   If the salt/IV is merely being stored, however, and compromise of one can be reasonably considered to compromise both, then the initial premise that the strength is not effected still holds.


Can the USB standard be altered to prevent the "firmware attack"? Wired, and others are reporting on a research paper by Karsten Nohl and Jakob Lell. The paper apparently shows how any USB device (not just memory sticks) can be infected with malware at the firmware level. This can then be used to attack any device the USB device is attached to. As the malware resides in the firmware, even wiping the memory stick of data is insufficient, as the firmware remains untouched.

USB is such an entrenched standard; can this be fixed in the next version?

Bruce Schneier suggests that this is the kind of attack the NSA would favour.

Note: There will be a presentation at BlackHat 2014 by the authors.

Edit: Adam Caudill and Brandon Wilson have released proof of concept code for this at DerbyCon 4.

I think this WIRED story is way out of proportion. While it's true that a USB device can act as a keyboard, or mouse, or a hub with both, it would only act with the privileges of the current user, and the attack wouldn't be stealthy: the device would have to open a command window, type commands, etc. with no way to read commands output.

You absolutely don't need to assume that a computer is potentially compromised just because a USB device was attached to it once.

The proposed solution "only allow a specific brand" is ridiculous too (how can you reliably measure that when the USB stick is lying?). A much simpler, more robust solution would be to block additional keyboards and point device, unless the user confirm that a wants to have two keyboards or two point devices.

Being able to reprogram any device firmware without a user manipulation (good old jumper...) is still a serious security issue, obviously.


How do I create a detached plain text signature? If I use gpg --detach-sig file, then I get a small file.sig, but it is not plain text, so this is not useful if you wish to send the signature in a plain text format.

If I use gpg --clearsign file, then I get file.asc which contains the whole file plus a plain text signature at the end of the file. For viewing the signature, this is not easy if the payload is something other than text, since you can't open the file as plain text if your text editor can't handle the raw payload data. And I would prefer the payload and signature be separate files.

If I use both of the arguments at once, gpg --detach-sig --clearsign file, it behaves identically to only --clearsign, basically ignoring --detach-sig.

How can I create a detached plain text GPG signature?

The command you want is:

gpg --detach-sig --armor file

This will create a detached signature and will armor it, i.e. encode it with ASCII.

See the GnuPG documentation for more information.


What's the point of spam posts where the link is too small to be visible? Recently, a forum I frequent has received multiple spam posts on its general discussion board (three in the space of ten days). They all look like legitimate posts at first, but buried inside each of them was a spam link to an external website. I don't know whether it's the same website each time - I didn't check the first two before they were edited out by moderators and the threads locked.

Here's the odd thing, though: the link is always in 1pt text and coloured to blend in with the post's background, so it's completely invisible. You'd have to know it was there and actively hunt it down in order to click on it. So getting us to click the link is clearly not the goal here.

So what's the point? Why spam us with links that we don't even realise are there? There must be a goal here, but I'm at a loss as to what it might be.

Increase site ranking

When search engines parse pages (Googlebot for example), they look for backlinks in order to try  to determine the popularity of a website.

The more backlinks go toward a website, the better search engines will rank it and the higher it will get in search result.

Decrease competitor site ranking

It's also possible that the attacker might be a competitor and try to decrease the ranking of a website (the forum here). In order to do this, attackers plant backlink in competitor website that links to porn, illegal good and services or untrusted website. There are then good chances that this will decrease the rank of the website.

You might find more informations about it by researching about Black Hat SEO


Is using a switch enough to hide MAC adresses of my devices from my ISP? I guess that my question sounds particularly dumb for specialists, but I was unable to find a reliable answer trough Google, so eventually I decided to post it here.

I have a router obtained from ISP.

In order to prevent seeing all my MACs from provider's side, is it enough to use a network switch?
Or I should buy a second router on my own, disable WAN management so he can see only one MAC (belonging to 2nd router)?

The router will know all of the MAC addresses since that is part of its purpose. If the ISP has remote access to the router then they will always be able to see that information in the ARP table.

Whether putting in an inner router will help is somewhat debatable - it should help but it may not be totally possible to guarantee that no data will leak.

Does it matter? What is more important is whether the ISP might listen in on any traffic, I can't imagine that it would profit them in anyway so the risk is probably pretty low. However, the possibility exists.

What might be a better option would be to put in a VPN terminating proxy. Such a device would act as a proxy channelling all of your data down a VPN tunnel and so no unencrypted traffic would be visible to the ISP. A decent router such as the Ubiquity EdgeRouter Lite would give you that capability.

Indeed, an inner router is not an uncommon architecture when using high-speed broadband (>8M, e.g. Fibre To The Cabinet) as the ISP often puts in a "modem", sometimes referred to as a "residential gateway". What this really is is a router with a phone connection upstream and Ethernet downstream. You connect your own (or the ISP's) router to the Ethernet connection and the router "dials" the address of the ISP to connect. The gateway is typically locked down and you can't see anything on it nor make any changes. In this case you can choose whether or not to use a VPN. If you don't, the ISP would be able to sniff your traffic and could work out that you have multiple machines but isn't likely to be able to be more specific.


Preventing Path Traversal Best Practise? Script:

header("Content-type: text/css; charset: UTF-8");

$var = $_GET['var'];
$var = str_replace(array('/', '../'), array('', ''), $var);

echo file_get_contents($var);

Is it possible to exploit Path Traversal without using forward slash?

In other words, would this code be enough to prevent Path Traversal?

$var = str_replace(array('/', '../'), array('', ''), $var);

If Yes:

What about backward slash? is it safe?
Would double encoding and hex encoding have any affect on that?

If No:

How would you rate it impact?
What is your suggestion for a better solution?

  PS: Operation System: Linux

Edited :
Yes ,
I really missed the point of the question sorry for that .Forward slash filtering will prevent LFI in Linux but it won't in Windows-based servers  . And LFI can lead to RCE I did that many times but it's another argument .

So you are safe if you are using Linux as you said but if someone used your script in Windows it easily bypassed by (..) backward slash .

The double encoding trick and hex won't work in this situation since you show the file after filtering .

That's all  what I know .


Why can't a cryptographic hash inside a cryptogram serve as a MAC? My question is closely related to Why do you need message authentication in addition to encryption?

Specifically I am interested in symmetric-key cryptography. I understand that attackers may modify cryptographic messages and the resulting decryption will be an altered message, MACs are designed to solve this. I read that one should create the cryptogram then generate a MAC from the cryptogram and send them together.

My question is why couldn't one simply append the original unencrypted message with a cryptographic hash of the original message and then encrypt them together? Then the receiver could decrypt both and verify the hash. If the cryptogram was altered the internal hash would no longer match and wouldn't it be hard to alter the message and/or internal hash such that they remain consistent since they are both encrypted?

Appending the hash then encrypting the whole lot is not necessarily secure. Actually, depending on the encryption system, it may be awfully weak. For instance, suppose that encryption is done with a stream cipher such as RC4: encryption is done by XORing with a key-dependent pseudorandom stream. Thus, the attacker sees this:

   E = (m || h(m)) XOR S(K)

where m is the message, h is the hash function, and S(K) is the pseudorandom stream generated from key K. If the attacker guesses the value of m (from context), then he can recompute h(m), and then obtain:

   S(K) = (m || h(m)) XOR E

Then, the attacker chooses his own message m', with arbitrary contents, and send:

   E' = (m' || h(m')) XOR S(K)

and voilà! Integrity has been defeated.


Should JWT token be stored in a cookie, header or body What is the most secure way to store transfer and store a JWT token, or any authentication token in general?

Someone told me it's secure to send the authentication token as a cookie, but I don't understand how this would provide any additional security over just using a plain session ID cookie for authentication, as the browser would include that cookie for all outgoing requests anyway. Have I misunderstood something?

What makes a lot more sense to me, is if the token would be stored in a response header or body, then extracted in the client side programmatically and manually added to each request. There would be no way to intercept the token over HTTPS connection and CSRF attacks are rendered impossible (I would use CSRF token anyway). Of course the authentication token could still be accessed by XSS attack, but isn't the cookie also prone to this attack?

I don't understand how token in a cookie provides ANY additional security over authentication based on simple session ID cookie? Am I missing some information?

By putting the token in the cookie and setting that cookie HttpOnly, you can prevent access to the cookie by malicious client side script (ie, XSS) - there is no access to an HttpOnly cookie from JavaScript, the browser will protect it and handle sending the cookie only to the right origin.

https://www.owasp.org/index.php/HttpOnly


Is TLS 1.3 supported in Dovecot 2.3.4 and Postfix 3.3.2? I would like to configure an email CentOS 7-based server to use TLS 1.3. Currently it uses TLS 1.2 for securing the SMTP and POP3 sessions. For SMTP I use Postfix software and for POP3 I use Dovecot software. I am interested in using only TLS 1.3 in the email sessions. Is that possible with Dovecot 2.3.4 and Postfix 3.3.2 ?
I searched on the Dovecot and Postfix wikies and I didn't found any information related to TLS 1.3.

Postfix and Dovecot rely on OpenSSL. TLS 1.3 is supported since OpenSSL 1.1.1 which is not the OpenSSL which comes with CentOS 7. This means you would need to compile your own version OpenSSL and compile all the tools which should use it against it.
Postfix 3.3.2 supports TLS 1.3 - see http://www.postfix.org/announcements/postfix-3.3.2.html
There is no specific mention of OpenSSL 1.1.1 in the Dovecot Changelog but this indicates that one should be able to compile Dovecot with OpenSSL 1.1.1, so TLS 1.3 should be doable there too.


Good steps to survive from denial-of-service attack (DoS attack) I need to follow several steps to safe our Web Project from DoS attack.

Is there any guideline / steps?

EDIT : We have our own server where we are running several e-Commerce websites. Our server's OS is CentOS.

To avoid downtime during DDoS running single server, you can make sure that your operating system remains stable during DDoS, so when the attack is gone, it continues to work. This can be accomplished the following way:

Setup IPTABLES with rate limit
Add Varnish proxy and configure it to deny attacks, it's stable and very resilient and has some modules to support it.
Enable syncookies
Use latest Linux kernel

This is very difficult thing to do and not straight forward, that's why the answer is a bit vague, and hardly you will get anything else.

In essence, you should make sure that flood is not reaching your application level causing server to choke, but instead dropping connections.

See this on Server Fault:

https://serverfault.com/questions/417969/how-to-tune-linux-kernel-to-withstand-ddos-haproxy


If I have the input and output, can I know the encryption technique? I have a program that can encrypt text, I tried to discover the encryption that is used in this program and could not figure it out, knowing that if the plaintext is P and the encrypted text is C, if we encrypt C, it will generate P again "double encryption generate the original message" also the encrypted text is a unicode charachters, strong text e.g. input "abcd", output "žœ›"
is it possible to find the encryption technique?

As @David's answer pointed out, this is, in general very hard to do. Especially since some encryption algorithms like AES use a random initialization vector (IV) as the starting block. So correct implementations would generate a different IV each time, even if the plaintext is the same, resulting in a different message.

As an example, let's encrypt Hello World! in CBC mode with:

key: 0000 0000 0000 0000 (not secure, just for illustration)

If I use IV = 0000 0000 0000 0001, I get ciphertext (base64): KcS/oAzkKMi03Nrf65hlww==

If I use IV = 0000 0000 0000 0002, I get ciphertext (base64):
2wTIRW8sSb4XpE9Ue3xm6w==

(The IV is usually included with the encrypted message. I omitted it for ease of comparison)


Is multiple encryption a good idea? I know that many encryption algorithms, while secure, have vulnerabilities.
To reduce risks, would multiple encryption like this

Blowfish_CbC ( Rc2_OFB ( AES128_CBC (myfilecontent)))

be a good idea?

I know that execution time seriously increases, but this isn't a problem for me. Any suggestions or ideas?

By adding more algorithms, you do two things:

Potentially increase the strength of the encryption.
Increase the attack surface of your application.

AES128-CBC is strong. If you're implementing it properly, and using strong random keys and unique random IVs, you're very safe. The US government (NSA) certifies AES for use in securing top-secret documents. I somewhat doubt that your security requirements are anywhere near theirs, so you should consider AES more than strong enough alone. If you're really paranoid, move up to 256-bit AES.

Chaining algorithms only provides more provable security if you use independent keys for each. Using the same key for all ciphers means you still only have to bruteforce one key, though at 128 bits it's been predicted that we might never posess the equipment to do so.

Chaining multiple algorithms makes some sense in ridiculously high-security high-paranoia long term storage situations like TrueCrypt volumes, where the deployment environment is completely unknown. However, unless you're likely to be storing military secrets that'll be shipped into a hostile country, and happen to be a professional cryptographer, I'd stick with just using AES.


How to copy files without copying Alternate Data Streams I want to backup my infected Windows system's files before formatting it all and reinstalling the system. I would do it from a Linux Live USB. I've heard that one should be careful in copying only the files and not the alternate data streams or they would help the malware persist when reinstalling the system.

From Linux, how do I copy the files safely without carrying the alternate data streams with them?

Copy it to any non-NTFS filesystem.
Alternate Data Streams (ADS) are a feature unique to NTFS. They are similar to, but distinct from, extended attributes (xattrs) on many Linux filesystems like ext4. The primary difference is that ADS streams may be hidden, requiring knowledge of the ADS handle to access it (at least without specialized tools), whereas xattrs can be easily enumerated.
Because only NTFS supports ADS, copying it to a filesystem like ext4 effectively cleans it out. It is for the same reason that xattrs are not preserved when a file is copied from ext4 to NTFS.
On a side-note, while malicious code could theoretically hide in a file's ADS, it would not be active there. Malware stored in an ADS would be completely neutralized until something else intentionally activated it. It is no more a source of infections than other places data can be hidden.


Client side encryption with sustainability as a service I only need 2 things.

1) The user to know that only him (not even then admins) can decrypt his data that rely on my server. He will always provide his key to decrypt data.

2) To be able to provide this service to him for many years to come , with any upcoming changes in client side cryptography methods.

Should i go for it or rely only on good https, password strength and server database encryption?

The platform will start as laravel application.

Your options and your requirements do not seem to match.   If you rely on HTTPS, password strength, and server database encryption, then the admin can, in fact, access the decrypted data.   SO, if requirement 1 is actually a requirement, then this option is not viable.  If, however, requirement 1 is merely a "nice to have" then this option might work.

So, the question is:  Is requirement 1 actually a requirement?   If it is, then your only real option is client-side encryption.  For any reasonable assurance of integrity, this requires either a client-side application or browser plug-in without automatic update mechanisms.  Server-based mechanisms are simply too easy to subvert to be serious contenders.


How dangerous is negligent RFID / NFC card use? Nowadays RFID / NFC is everywhere. From public transport use, door opening to Credit Cards.

I see often people just passing their wallet in RFID/NFC readers to do all kind of operations.

This seems to me that opens a new angle of attack to cards. It's not hard at all to install a card reader next to another and read all kind of information.

How danagerous is this behaviour?

I am sure there are already initiatives to improve security but meanwhile there are for sure legacy cards / systems that can easily be cloned and abused.

NFC readers are a great piece of technology. Sadly, it has been poorly executed and has many security concerns. Most the security concerns have been "debunked" by credit card companies whom continue to push the technology. Theft using NFC on various RFID systems is open to compromise, but really all depends on how secure the user is with this information, The NFC must be passing active data to be hijacked or intercepted. So a malicious person cannot simply pass his or her phone passed your wallet and get information, unless there is an active data stream or connection to a reader. But there has also been workings to have more levels of authentication to ensure appropriate use.

Eavesdropping

Eavesdropping is when a criminal “listens in” on an NFC transaction. The criminal does not need to pick up every single signal to gather private information. Two methods can prevent eavesdropping. First there is the range of NFC itself. Since the devices must be fairly close to send signals, the criminal has a limited range to work in for intercepting signals. Then there are secure channels. When a secure channel is established, the information is encrypted and only an authorized device can decode it. NFC users should ensure the companies they do business with use secure channels.

Active Attacks

There are NFC attacks based on actively probing a card without the cardholder's knowledge, and this is done outside of the context of eavesdropping on or intercepting a legitimate transaction.  The idea is that you sit next to someone on the train, and a computer in your backpack attacks the victim's card while it's still in their wallet.  The first demonstration of this was on Mobil's SpeedPass, which was defeated this way long ago.  Charlie Miller recently presented on this at the 2012 Black Hat.

Data Corruption and Manipulation

Data corruption and manipulation occur when a criminal manipulates the data being sent to a reader or interferes with the data being sent so it is corrupted and useless when it arrives. To prevent this, secure channels should be used for communication. Some NFC devices “listen” for data corruption attacks and prevent them before they have a chance to get up and running.

Interception Attacks

Similar to data manipulation, interception attacks take this type of digital crime one step further. A person acts as a middleman between two NFC devices and receives and alters the information as it passes between them. This type of attack is difficult and less common. To prevent it, devices should be in an active-passive pairing. This means one device receives info and the other sends it instead of both devices receiving and passing information.

Theft

No amount of encryption can protect a consumer from a stolen phone. If a smartphone is stolen, the thief could theoretically wave the phone over a card reader at a store to make a purchase. To avoid this, smartphone owners should be diligent about keeping tight security on their phones. By installing a password or other type of lock that appears when the smartphone screen is turned on, a thief may not be able to figure out the password and thus cannot access sensitive information on the phone.

While it may seem like NFC would open up a world of new security risks, it may actually be safer than a credit card. If a user loses her credit card, a criminal can read the card and find out the owner’s information. If that same person loses her smartphone and has it password protected the criminal cannot access any private info. Through data encryption and secure channels, NFC technology can help consumers make purchases quickly while keeping their information safe at the safe time.

Slides: "Practical Experiences with NFC Security on mobile Phones"
Security in Near Field Communication
Security Risks of Near Field Communication
Blackhat study Exploring NFC attack surface


Identify SSL version and cipher suite We have a Java application running on a Linux server and we are transmitting some files using a third party Java library which uses HTTPS internally to connect to external servers. These are legacy libraries and we have only .jar files.

How can I identify which SSL/TLS version is being used by this library? Is there a way to monitor the TCP traffic on my Linux machine to track SSL headers?

One of the way that I use to capture the network traffic from the java application using Wireshark. Refer the documentation to capture the traffic. Once the traffic is captured. Click Analyze -> Decode As -> Transport,select the port and the select SSL, apply and the save the settings. The captured traffic will be shown as SSL. Look for the response of the  "client hello" message in the captured traffic. This is where SSL/TLS handshake is done.

Refer the below image:


What is the Best Method to Store SQL Host, Username and Password for Multiple Databases? I have a large project which has multiple web servers (one for each client), one application (for all clients), and multiple SQL databases (one for each client) as pictured below.

.

For security purposes I need to have separate passwords and usernames. How can I safely store the passwords to the SQL Servers on the application server? I could encrypt the host, username, and password and keep the key on the application server, or would it be better to store the passwords encrypted on another SQL Server? And where should the encryption key be kept?

First you must make sure that you are not facing an x-y problem, because having one database per user behind the same application is not the most common design. It is much more common to share the database and let the application implement the user separation. Among other advantages, you have one single database connection, which greatly eases scalability and database maintenance.

If you really need that design, my prefered choice would be to let the password responsability to the users. If it is an option, the database password could simply be the web user password. That way you do not even have to store it and just create the database connection at login time and close it at logout (or end of web session). Alternatively, you could derive a key from each individual web password and use it to encrypt the database password for each user if you want to maintain them separate => result is the same, you need the web password that you do not store, to access to the database

If none of those are acceptable options, you will have to store the passwords in an invertible form on the application server, but it is a security nightmare. Your options are:

don't care at all: store the passwords in clear text and pray that nobody ever get access to those data - surprisingly it is a too common option(*)...
don't care much: same as above but encrypt the passwords with a fixed key hardcoded in the application - a little better because the attacker now needs two elements but one of them can never change
do your best: encrypt the passwords with a modifiable key. It could be read from the environment at boot time and changed on a regular base, say every month for example. But that means that when changing the master password you also must change all database passwords in a atomic way - ok, any database can do it, but beuhhh.... Alternatively you could mimic password vaults and encrypt a whole file at the cost that accessing an individual password will require a full decryption unless you accept to keep the full database in clear text in memory.

(*) ... but it can be an acceptable option if the application server and the database servers are in the same security zone.


Alternative to security questions for account recovery when email isn't an option I'm working on a project whereby a certain level of anonymity is required for users. One of stipulations is that no email is used at all, as it makes the barrier to entry too high for people who want anonymity in this service but don't have an anonymous email account to hand.

One of the issues with this is that account recovery becomes painful if someone forgets their password. Security questions would end up being a massive security hole, as there isn't the burden upon the attacker to compromise the email account as well as guess the answers.

A potential method I'm considering is to give the user a file full of random data upon account creation, and have them use that as a token for resetting their account. The only issue I can see with that, though, is that people would likely lose the file.

What other options do I have?

You could encourage your users to put their passwords in a secure password storage system such as KeePass. The system requires that the hold on to something anyway, better just have them hold onto the password and not add another piece (they would have to somehow secure the token file you give them to prevent it from being stolen/intercepted). You may also run into issues with the way your random tokens are created if the algorithm was not implemented correctly and some correlation or predication became possible.

There may be some potential to use a certificate based system for authentication, then they just hold onto their key, which is more likely to be held onto then a reset token (I can't even remember where my TrueCrypt recovery CD went). Maybe you tell them to put it in KeePass or jsut a encrypted file and then put it in their dropbox - it will be in multiple places, but accessible only in an encrypted/protected format.

I think your users need to make the tradeoff between convenience and security. (a) If the data on the site is so important, than you must be responsible enough to hold onto your password (b) If its not that important, you give up the convenience of a reset for the safety of knowing no one else will likely be able to get into your account.


Can I use something other than AES 128 to store my PSCredential? From what I've read the ConvertTo-SecureString will store a password with AES-128 (which as I understand it is cracked)...is it possible to use more bits?

I've read in Get-Help the following, but I don't know how to proceed:

If an encryption key is specified by using the Key or SecureKey
parameters, the Advanced Encryption Standard (AES) encryption algorithm is
used. The specified key must have a length of 128, 192, or 256 bits
because those are the key lengths supported by the AES encryption
algorithm. If no key is specified, the Windows Data Protection API (DPAPI)
is used to encrypt the standard string representation.

Also, I'd like to run it with a Scheduled Task in Windows.

Yes you can use up to AES 256 as mentioned here.

  ConvertFrom-SecureString and ConvertTo-SecureString have two
  parameters that you can use to change the default behavior.  These
  parameters are –SecureKey and –Key.  The –SecureKey parameter takes a
  SecureString object and the –Key parameter, a byte array (Byte[])

  You use –SecureKey with a SecureString memory object that encrypt and
  decrypt the other SecureString.  This does not really help us in our
  goal of storing secure passwords and accessing them through
  automation.  You would need a SecureString object built, either by
  unencrypting another string using another option, or by having someone
  type the SecureString interactively.   The first does not solve the
  problem of it being secured, the second does not solve the automation
  problem.

  The –Key parameter allows you to use a 128-bit (16-byte), 192-bit
  (24-byte), or 256-bit (32-byte) key and uses the Advanced Encryption
  System (AES) cipher, also known as the Rijndael cipher, to
  encrypt/decrypt the SecureString.  It is symmetric encryption so you
  need to provide the same key for encryption as you do when you decrypt
  the encrypted string back to the SecureString.  One way to do this is
  to embed the key in each script file.  Not surprising, this not
  recommended and results in security not much more secure than just
  storing the password in plain text in the script.  It also makes it
  difficult to change the key or password which should due frequently
  using this method.  A better choice is to store the key in a separate
  file from the script and encrypted password.


The registration confirmation email contains my password: do they keep it in plaintext? I was kind of shocked when I just received my confirmation mail from the shop where I just registered myself: they sent my username (which is my email address) and the password I typed in.  The password was not partially replaced with *s or similar; it was the naked, blank password I picked.

This does mean people who can check the emails the shop sends could theoretically see my login data, does it not? I believe this is the first time I get a confirmation with my full login information so this seems really weird and somehow concerns me. Should it?

From the fact that I received my password by email, I am guessing that the shop does not encrypt my password.  Is this a valid inference?

Sending you the password in plain text does not necessarily mean the database stores it in plain text, especially if they sent you the email before encrypting and storing the password. However if you ask for the password later on (e.g "forgot password" mechanism) and they do send it to you like this, it implies that they are either storing in plain text or they're using an easily reversible encryption. In either case, there is reason to be concerned unless they only send you the password on registration and before storing it on their server in encrypted format.

In particular:

If they have a "forgot my password" link that sends you the password you had previously set up, then yes, there is reason to be concerned: they are storing the password in plaintext or using reversible encryption.
If they send you a new password, then it doesn't necessarily mean they are storing the password in plaintext or using reversible encryption.  In that case, you don't have enough information to know whether there is cause for concern.

A separate issue is that, in any case, email is not a safe medium for sending passwords.  Thus, even if they aren't storing the password in plaintext, if they are sending it to you by email in plaintext, that does pose some risk.

according to plain text offenders:

  Man in the middle attacks are easy to pull off between server and the
  comminucation protocol in itself is not encrypted.


Enabling Unsigned ActiveX A third-party wants to provide a web app which they say only works if we enable unsigned ActiveX (unfortunately users are required to use IE). I understand what 'signing' is, as well as the basic impacts could be if we run unsigned software, such as having client-side code being execute on the browser.

My questions are:

Is this acceptable, first of everything, from a security standard (i.e. accepting an unsigned software)?
Does the fact that none of our users have admin privileges on their machines mitigate the risks of running unsigned software?
Is it possible to allow the unsigned ActiveX only for that software, but not for everything else?
Does 'being signed' really mean more secure? I mean, it's signed, so what?

Any pointers to further reading would also be much appreciated.

I'll have a shot at addressing this one.

Is this acceptable, first of everything, from a security standard (i.e. accepting an unsigned software)?
Accepting unsigned software that is trusted for some other reason in itself isn't an issue. Accepting ActiveX isn't considered acceptable at all. I'd suggest running the browser that uses ActiveX within its own virtual machine with some fairly harsh isolation settings.

Does the fact that none of our users have admin privileges on their machines mitigate the risks of running unsigned software?
Not really, anything accessible to the user level will still be fair game. The lack of admin rights just means that a few things will stay out of reach unless an avenue for privesc can be found.

Is it possible to allow the unsigned ActiveX only for that software, but not for everything else?
Yes, you can whitelist ActiveX for that one particular domain if you so desire. I would really suggest running it inside the aforementioned virtual environment though. ActiveX is not something you want touching your systems in any way that you can avoid.

Does 'being signed' really mean more secure? I mean, it's signed, so what?
Not really. Anyone can buy a code signing certificate with minimal scrutiny. The cheapest I could find is $70 and promises to be issued within 20 minutes.


Secure login across two web apps I have an requirement to implement cross-domain login for two web apps (APP1 and APP2) so that a user can access APP2 once they have logged into APP1.
APP2 needs to know an ID of the user who is logged into APP1.
I have come up with a solution but I'm not sure it's the best way to do it. Could you please take a look at this solution and point out potential vulnerabilities or give me some hints how to get it done in a better way?
Here's the solution:

APP1 has a link to the APP2 somewhere on the website. The link contains a login token which is generated by APP1's server, i.e. https://app2.somedomain.com/index.html?login-token=U2FsdGVkX1+S5BDg4DV0nnoq3iIEjAj6Wk48F20GjNWGZDoad8VgAW9nG4ltBV0iQNuFz428yqh6pQ6JcKMIO9c+hy9+BDGfDfqz6tuCqp4=
A login token is a plain text encrypted using a symmetric key algorithm such as AES and an encryption password which is known only by APP1 and APP2.
It contains the following information:
userId, ip address, timestamp, secret-key,
ie.
00001,87.143.203.12,1399725213,secret-key
APP2 receives the request, decrypts the login token using the encryption password and checks the following:

HTTP referer - it should match to the APP1 server URL
IP address
secret-key - both apps share the same secret-key (is not the same as the encryption password) to verify that the request comes from APP1
whether the login token has been used or not.

APP2 guarantees that a login token can be used only once so it won't be possible to steal a login token and use it to access APP2 from another computer.

I would use an open source implementation of OAuth.  Even better,  you could use a 3rd party OAuth provider so that you don't have to worry about leaking your customer's credentials in the event of a compromise.


Secure internet access while traveling Given the risks of shared wi-fi as stated here, here and here, I would like to ask what are good practices for someone who is always traveling.

While having your own wi-fi with a strong WPA2 password may solve your problem well for your computer at home, if you need to constantly travel to other cities and countries with your laptop then it's no longer a good option.

What would be best solutions for someone who wants to be independent and secure in his internet connections while on the move?

In one of those links VPN and SOCKS were recommended. If one of those happen to be part of the solution, specific suggestions on how to choose and implement it would be most welcome.

The best way is to simply encrypt your traffic from/to the country. Using a VPN tunnel, or a SSH socks5 tunnel are the two most common solutions. They will encrypt the traffic from your laptop to the server, before it reaches the internet. Of course someone could sniff the servers traffic, but it would be out of reach to whatever country you're visiting.

You can get a VPN account from many different providers for a monthly/yearly fee if you don't want to set up a server yourself (which is quite difficult). They will provide step-by-step guides to get you going, and it's really easy to get it installed. Many of them also promises anonymity.

A SSH-tunnel requires that you have access to a shell account. You can easily set up a SSH-server in your own home. It would encrypt the traffic from your laptop to your home network before it reaches the internet. The traffic will seem as it came from your home network. This is the simplest solution if you want to do it yourself, and you can specify the applications that should run through your secure tunnel, wheras with a VPN-account everything will run through the tunnel.

My own solution is to run all my browsing traffic through a ssh tunnel, and have a portable, slimmed firefox installation that I use when I want to browse around for fun (youtube, reddit, ...).

If you don't use a tunnel, make sure you only login to websites using secure https. Never download and run any files using your unsafe connection. Use a safe dns provider such as opendns or google dns to protect yourself from dns-spoofing. Preferably an encrypted DNS-provider. I'm not sure if encrypted DNS is very common (but I know that opendns provides it).

Some email providers, such as gmail, use full HTTPS by default. While others like yahoo only use HTTPS during the log in. Keep that in mind aswell (and enable it if you are using hotmail because it's not enabled by default).

I could expand indefinitely on this subject. But if your knowledge is slim, just get a monthly VPN account from a safe provider. This is the safest and easiest solution to protect yourself.

If you decide to get a VPN-account, I recommend that you do some research before choosing which one. Here is a link to torrentfreak with a list of VPN providers.

https://torrentfreak.com/which-vpn-providers-really-take-anonymity-seriously-111007/


Access to the codebase in big companies I am wondering how big companies manage access to their codebase from their developers. In order to make their code safe do they allow their developers to have access to entire codebase or to only particular subprojects to avoid stealing the entire codebase?

For example, if a company has 10 developers, should they set in place access control policies, so each developer will have access only to particular module he/she needs to develop?

If so, please let me know how to achieve this.

[Edited]: As expected the code source has been taken from one of the developers and sold it to somebody, it was done by trusted developers for those who says trust is must.

In any sanely managed company, a developer usually gets full access to the sourcecode of any project they work on.

The reason is that the benefits of releasing parts of the code on a strict need-to-know basis isn't worth the bureaucratic hassle and the huge work impairment it creates for the developers.

Developers can't work without seeing the whole picture. I am a professional software developer who works in a team which maintains a huge system. Most of the problems I get tasked to fix are bugs which could be in any part of the system. I need the full sourcecode in order to figure out where the bug originates and how to fix it. I wouldn't be able to do that job if I would need to fill out a form and wait for management approval before I can look at some of the modules which could have something to do with it.
Good software developers don't grow on trees. They are hard to replace and they can easily get a job somewhere else. To get and keep the best talent, you need to treat your developers well. If my company would start to hassle me with unreasonable access restrictions to sourcecode, it would frustrate me because I can't work efficiently and it would insult me because it means they don't trust me. I would be gone in a few weeks.
Most code isn't actually that valuable. Most code which gets written in the world is only useful for solving the problem of one specific client. For anyone else, the code is completely worthless.
Even if the code is valuable to a larger demographic, you have the law to protect it. Copyright and non-disclosure clauses in work contracts allow you to sue the pants off of anyone who tries to sell your intellectual property to someone else.

Technical measures to prevent sourcecode leaks on a network layer (like proposed in the comments to the question) are not an effective solution either. Developers are smart. They solve computer problems for a living. If they really want to get some information out of your building, they will find a way to do it. Not even the NSA was able to prevent Edward Snowden from leaking gigabytes of confidential data.

Besides, a malicious developer can do far more harm than just leak your sourcecode. There isn't much you can do about that, because the more you try to monitor and limit your developers, the less efficient they will be and the more unhappy they will become.

So what can you do to prevent your developers from turning against you? It's simple: Don't hire developers you can't trust and treat them well so they won't form a grudge against you. That means if you are a manager suffering from paranoia and trust issues, then software development is not the right industry for you (you might want to give retail a chance).


Store a secret on a Windows computer so that even an administrator cannot access it I am looking for a way to store a secret on a Windows computer so that even the administrator cannot access it.

But executables that are signed with a specific code signing certificate should be able to access that secret without user interaction.

I was thinking about using the following approach:

Create a new Windows user "SecretKeeper" with a random password that is not known to any user.
Install a Windows Service running under the SecretKeeper user account. (The Service can be started automatically by Windows without anyone else knowing the password of SecretKeeper)
Give the secret to that Service, have it store the file on the file system and encrypt it using the Windows File Encryption API (so only that specific user SecretKeeper can read the file)
When an application needs the secret, it can communicate with the service in a way so that the service can check the code signature of the executable before sending the secret.

Problem with this approach is that an administrator can exchange the service executable with their own executable that is then started running as SecretKeeper and can decrypt the file.

Is there some way to make sure the executable for an installed Windows service is not exchanged even by the administrator or is there maybe a completely different approach to achieve the goal of hiding a secret even from the administrator?

Note: I am aware that a local administrator of a Windows computer has other means to access process memory of running processes or watch communication between processes and that there would have to be other mechanisms to prevent that.

This question is similar to the following questions:

How to store client secret securely on application base in Windows?
Can I create an application that can decrypt data but the administrator of the application cannot?
How to store a file securely on the windows file system?

To be honest, that's probably not even the weakest point in your scheme.  If I was the admin trying to get the secret, all I'd do is decompile the app that's requesting the secret (to see how it does it), and just build a quick .exe that politely asks your service for the secret.  I mean, your secret-keeper doesn't really have any way of knowing whether the app requesting the secret is authorized to have it.

I think the short answer is: you really can't do what you're asking.


Is there any difference for OS fingerprint technique used in Nmap inside -A and -O? Is there any difference between the technique or algorithm used from Nmap to guess the OS between the option -A and -O? If not, why -O option requires root privileges but -A that it is doing at least the same (and even more) does not require special privileges?

-A without root privileges does not perform OS detection. The -A option is a shorthand to enable many of Nmap's advanced capabilities:

OS detection (-O)
service version detection (-sV)
NSE script scanning (-sC), and
traceroute (--traceroute)

Of these, OS detection and traceroute require root privileges. The other two features (with the exception of just a few NSE scripts) do not require root privileges. When you use the -A option, Nmap will enable as many of these features as it can at your current privilege level, and it will not complain or give an indication that it is leaving any out.


Why can't we bypass DNSSEC DNSSEC is a suite of security extensions to enhance DNS security. (e.g.: avoid cache poisoning)

However I was wondering how does the resolver know that the next NS will use DNSSEC?

E.g.: Someone wants to resolve www.example.com..
Let's assume that the authoritative NS example.com. has DNSSEC enabled and properly configured.

The resolver will first contact the root servers ., then the TLD servers com. and finally the authoritative example.com.. However, as the resolver send a DNS query to that last NS, he doesn't know if DNSSEC is enabled.

This means that an attacker may forge DNS packet and do his poisoning stuff...

I know I'm wrong, the resolver must be aware that the next NS uses DNSSEC. But I don't get how!?

The authoritative for .com will indicate in its signed answer that example.com is also signed (some output omitted)

$ dig +norec +dnssec a www.example.com @c.gtld-servers.net

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.
example.com.        86400   IN  DS  31589 8 1 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE
example.com.        86400   IN  DS  31589 8 2 CDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03 E576343C
example.com.        86400   IN  RRSIG   DS 8 2 86400 20150503041532 20150426030532 33878 com. P7R78q8UpfNTw+oVYJkL4BizSB4b8sglabdODISZEFSP3/z7CPAXOa4C 31rbNeLvD/O0I6pmYbg33HILGyj+yxAlZj7x3LNuLzaun86S201XcLkH /Xe/tLA+kEBgwZ6RV+1Vvqc51kAcQuN0U+6v5nZFaCJ1ZhvZ/S8w7FMf dfY=

Note the RRSIG - this is signed with the key for .com, and it allows the client to validate the DS records. The DS (Delegation Signer) records, in turn, are a hash of the DNSKEY for example.com. When a client receives this reply, it knows example.com MUST be signed, and MUST be signed with a key that matches one of the DS records. If the client then gets non-DNSSEC data from the example.com name servers, it knows something is wrong and will treat the data as BOGUS.


encrypting a file with an RSA key I wrote a java program to encrypt and decrypt files using AES algorithm in CBC mode and a random initialization vector. but there is something fundamental I'm not understanding:first I generate a random iv and load it to the cipher in the encrypt method.
then when I want to decrypt the file,do i need to load the same iv to the decrypt method?

Yes, you need the same IV to initialize the decryption process. The purpose of the IV in CBC mode is to ensure that encrypting the same plaintext will result in a different ciphertext each time. By the way, are you encrypting it using AES or RSA?


php_register_variable_ex vulnerability question Vulnerability I am referring to is:

http://www.securityfocus.com/bid/51830

And here in more detail:

http://auntitled.blogspot.com/2012/02/mini-poc-for-php-rce-cve-2012-0830.html

So basically what it amounts to is that in the code someone forgot to add an "else" statement and it allows an attacker-controlled string to be interpreted as a ZVAL struct. What I want to know is if an attacker could potentially store something else other than a hardcoded address in the string he/she controlls such as a pointer or register. I'm pretty sure this isn't possible, but if it was it would make code execution much easier.

This is a nasty vulnerability.  In short,  it allows a remote attacker to read and/or write to an arbitrary memory address.  So you can't modify a register directly.  Being able to read an arbitrary memory address is very important in modern exploitation because it allows you to read an ASLR'ed memory address.  This is important because when you control the EIP,  you can then point it to the exact memory location of the attacker's shell code.  This vulnerability also bypasses canaries,  its not a buffer overflow, the attacker can overwrite the return address directly on the stack which will become the EIP when a target function returns.


Is this an attack and how can I fix it? I don't know where to start in searching the forum for existing threads that might cover my issues.

I recently received a spoof email pretending to be from a client for whom I've just started to do some basic SEO and content work.

The email directed me to a problem URL on the site:

http://clientdomainname.com/%E2%80%8E

I have changed the domain name, but the rest of the URL string is exactly what I received. There is no page corresponding to the URL on the site, so it triggered a 404.

The client did not send it, so I'm thinking that the URL may perhaps initiate some kind of script.

My questions are:

Are my concerns plausible? The sector has hotted up recently and there are some unscrupulous large businesses trying to push small players out.
How can I find out if that URL string triggers some kind of malicious script? Should I ask the host (hostgator) to scan, or is there a better way to scan?
What steps can I take to remove and prevent it from happening in future?

If you ever need to check a suspicious URL, you can use a service like urlquery to check if it has a malicious reputation, the HTTP transactions that take place, any java script that runs, etc etc. Very useful. They also provide a screenshot of what the visited page looks like.

http://urlquery.net/


best operation mode for Rijndael-256 in PHP so my question is about the operation mode. In another thread I heard that ECB is bad which makes sense when I read about it, so I wanna change some things at my Crypto to make it better and wanted to ask on which of the Rijndael-256 modes is the best with regard to the following points:

PHP compatible
Secure
reliable
not too much overhead in the ciphertext (it gets transferred over the internet more than often enough)
I dont need authentication since I already have the hash of the Plaintext stored elsewhere

what I am storing is session identifiers, which are 256-char A-Z a-z 0-9 strings, and the key is an automatically generated hash of certain user data (user agent and similar things) in case it may help

if there's a better encryption method feel free to tell me about that as well.

For mode selection: anything other than ECB is safer. Do not worry too much ( have a look at https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation )

But for Rijndael-256 ...

http://php.net/manual/en/function.mcrypt-encrypt.php#117667

Rijndael-256 is NOT AES-256. Do not use Rijndael-256 or you may fail to decrypt (say, by OpenSSL).

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

  AES is a variant of Rijndael which has a fixed block size of 128 bits,
  and a key size of 128, 192, or 256 bits. By contrast, the Rijndael
  specification per se is specified with block and key sizes that may be
  any multiple of 32 bits, with a minimum of 128 and a maximum of 256
  bits.

And, mcrypt was DEPRECATED in PHP 7.1.0, and REMOVED in PHP 7.2.0, please consider to use OpenSSL or Sodium


Sourcing hardware that is least likely to contain backdoors I understand that CPU silicon (for example) is scrutinized for backdoors but there are other aspects of a computer system that may "leak data" to the outside world unbeknownst to the owner regardless of driver or OS configuration.

I'm looking for advice on how to protect myself from hardware-based exploits such as CPU-silicon backdoors, Bluetooth or wifi hardware-based vulnerabilities, or even hacks in BIOS of the motherboard or any connected devices.

Some examples of a hardware hack could include

A hard drive that has modified firmware (e.g. IRATEMONK)
Setting a jumper pin to enable discreet functionality
A undocumented keyboard sequence (other than control-alt-delete) that bypasses a BIOS password
A bluetooth receiver that "wakes up" when a magic packet is seen
An integrated camera and microphone that records data to NVRAM when conditions apply
A GPS receiver that wakes up when at a certain location.

Question

What guidelines should I follow to purchase hardware (computers, networking equipment, power supplies, etc) that is secure at a hardware & firmware perspective?  (before the OS level)

The answers I'm looking for could be either legal/contractual, or technical in nature.

Your questions is about preventing the inclusion of hardware that contains intentionaly created backdoors, but I suggest that in addition to prevention you consider detection, mitigation, and response.

There are different levels of sophistication in creating and detecting hardware backdoors. So, in part you need to understand your own level of expertise in detecting intentional hardware vulnerabilities. Doing design analysis is a good place to start. The general architecture should make sense and be familiar. A true from scratch hardware design is quite rare. Therefore look for the components of the design that deviate from previous revisions and other design for similar components.

Perform your own hardware security testing. Using your system security design create tests for the given piece of hardware and attempt to determine whether it passes or fails your security model for the intended system.

Mitigation of hardware security issues include strategies such as treating as much hardware as possible as untrusted and only investing trust in hardware that is critical to the secure operating of your system.

Only do business with people you trust in jurisdictions where harms done by companies and individuals may be fairly adjudicated.


Pros and cons of installing security updates automatically? I recently got into a discussion regarding automatic installation of security updates. The system is used and managed by a small nonprofit organization—essentially one or two admins managing the system in their free time. They typically touch the box only if there are feature updates to be done, or if something is not working (which they typically discover by people complaining about it, as there is no monitoring).

Since there is a high risk of admins neglecting security updates, I suggested automating security updates (specifically installing only security updates, not other updates). Now somebody else claimed that no serious admin would ever configure automatic installation of software updates.

The possible reasons against automation that I can think of do not seem major issues to me:

Spoofed update repository—updating manually makes this no less likely to happen, and with proper signature verification, this should be fairly hard to exploit.
Updates breaking the system—security updates should for the most part maintain interface compatibility and would thus be drop-in replacements, hence this risk is adequately mitigated by limiting automatic installation to security updates.
Data corruption because of updates on a running system: with proper packaging and installation routines, I would expect packages to take proper measures (e.g. shutting down a service before upgrading it and restarting it afterwards).
Downtime: can be controlled by scheduling automated upgrades to take place during a designated maintenance window; apart from that, I consider it less of an issue in this particular case as usage of the system is low.

What is the general recommendation regarding automatic installation of security updates (considering the scenario of a system that gets admin attention on a sporadic basis only)? What are the risks caused by automatic installation of security updates?

If you look at CIS Controls (formerly known as TOP20 Critical Security Controls), and particularly the number #3, you will find:
Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.

So I would recommend it, especially in the case of "low admin attention".

You have well identified the risks, the biggest one being operational issues (update requiring a reboot, update stopping some services, etc.).

Regarding the risk of spoofed update repository, today most update systems rely on TLS authentication and/or package signature, limiting this risk. This risk is usually lower anyway than running a system with an unpatched critical vulnerability.

At the end of the day, you should also consider the risk exposure of the system (internet exposure, etc.) in your decision matrix.


Selection of Curve in ECC for openssl 1.0.1? I am using both version of openssl 1.0.1 and openssl 1.0.2 :
in openssl 1.0.2 have one function which is to set highest preference curve automatically.

But, in openSSL 1.0.1 there is no any function to set highest preference curve automatically.

I have to set manually curve.
I dont have much knowledge of ECC so can anyone guide me which curve is best and more secured?

#if OPENSSL_VERSION_NUMBER >= 0x1000200fL

      /* Set automatic curve selection for server ssl to onoff.If onoff is 1 then
      the highest preference curve is automatically used for ECDH temporary keys
      used during key exchange. */
      (void)SSL_set_ecdh_auto(ssl, 1);

#elif OPENSSL_VERSION_NUMBER < 0x1000200fL

      sECDH = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);    //  secp256r1 curve - referred as prime256v1
      (void)SSL_set_tmp_ecdh(ssl, sECDH);

#endif

Thanks!

Short answer: secp256r1 secp384r1 and secp521r1 are all good conservative choices. secp256r1 currently has better compatibility with browsers than the others, for more detail, see this question.

If your clients are up to date (aka modern-ish browsers) then I would recommend curve25519. It was invented by Daniel J. Bernstein (a university prof who's famous in the crypto world) and he was very transparent about how he came up with the random numbers, so there's no chance of government backdoors in that curve. It also has better performance than the NIST P-* curves [wikipedia]

But really, anything supported by openssl is fine unless you are a military organization or a bank, in which case stop posting here and hire a security expert!


How to handle self-made certificates for Windows executables? I have a product which I sell to customers. It includes a PC running Windows 7, something like a Kiosk-system. There are two user accounts, one Admin and one User account. The user account should have nearly no rights, while the Admin account should have all the rights. To make things more safe, I use windows software restriction policies (SRP), so that the user is only allowed to run executables signed by me with a rule. I created these certificates with OpenSSL and then sign my executables with SignTool. This works like a charm.

My question is now, how to handle these certificates? I sell these PCs all around the world and I am not able to update all these certificates if they expire. I could make them last 100 years, but I'm not reassured with this. I offer software updates every year or so. Is there a easy and secure way to update the certificates with these software updates?

I would be very pleased if someone could may help me with this question.

Thanks in Advance, Max

Really you should use certificates that are issued from a trusted root certificate not a self-signed one. This gives customers the knowledge that the cert in use is valid. Using self-signed certs means that someone could, theoretically replace the cert with their own - using their own private key to sign a replaced executable. So really you are not providing that much security using self-signed ones.

In addition, it isn't really just the certs you need to handle but the signed executables. I guess that it is fine for customers to retain an exe signed with an expired cert as long as the dates all match up. If this isn't acceptable, you will have to create a way to distribute updated exe's and this is a standard software distribution problem. I'm sure you will find a convenient library or tool to help depending on the toolchain you are using to create and distribute the code in the first place.


Why is autofs insecure? I am hardening CentOS/RHEL 7.6. The hardening documents recommend disabling the automounter, "unless it is necessary."
Why is autofs such a problem?
One of the benefits of networking is a shared file system. What other alternatives are there?

Update
Here is the link to the [sic] very informative documentation.
RHEL OS must disable the file system automounter unless required.

Here is the text from the DISA STIG URL:

  The autofs daemon mounts and unmounts filesystems, such as user home
  directories shared via NFS, on demand. In addition, autofs can be used
  to handle removable media, and the default configuration provides the
  cdrom device as /misc/cd. However, this method of providing access to
  removable media is not common, so autofs can almost always be disabled
  if NFS is not in use. Even if NFS is required, it may be possible to
  configure filesystem mounts statically by editing /etc/fstab rather
  than relying on the automounter.

  The autofs service can be disabled with the following command:
  $ sudo systemctl disable autofs.service

To find it, go here and search for autofs

Many filesystem drivers are insecure.
There's nothing wrong with automounting in theory, given that dangerous filesystem options are disabled for automounted filesystems, but the reality is that mounting arbitrary filesystems can make it possible to exploit vulnerabilities. Many filesystem drivers are very complex and designed for speed, not for security. Precious little effort goes into securing filesystem drivers from maliciously-designed filesystem images because they are not usually coming from untrusted sources. Disabling the autofs service prevents an attacker from feeding a malicious filesystem to the a vulnerable driver. The upshot of disabling autofs is that less kernel code is being exposed to an attacker.


When moving beyond SSL3 is not possible, what cipher suites are immune to POODLE? I understand that anything not using CBC will work, but are there any such modes? I'd also like to avoid weak stuff like RC4/5 and MD5 so preferrably ciphers that use sensible functions.

On a SSL 3.0 only server with several weak functions disabled client-side, Internet Explorer defaults to 3DES keys with SHA1 HMAC in CBC mode, is there anything better I can do?

I don't think so, at least not with IE (per this page on Wikipedia).

Between RC4 and CBC there really aren't any good SSLv3 cipher suites to use.


How does WannaCrypt detect when someone pays the ransom? It seems they are processing it manually, but how can they verify the payment? WannaCry doesn't provide a unique ransom bitcoin adress for each victim.

Until now, it will be manually operated. But now there is a new path for the money - you got a text message with a request to contact the operator with the private bitcoin wallet address: