Explaining security vs. performace to a non-tech superior I was tasked to implement some sort of password-based encoding/decoding in an android app by my non-tech SO. He also showed me this list of android security providers. Naturally, He chose the one with the most acronyms and highest numbers (PBEWITHSHA256AND256BITAES-CBC-BC) to go with.

How do I explain to him (in layman's terms) that the provider is quite overkill for the app, and might result in a performance hit?

Password-based encryption, with both encryption of the data and a signature to prove that the data can't have been modified by anyone without having the password, using longer keys, is a good choice.

PBE = password-based encryption. Isn't this what you need?

WITHSHA256 = SHA-256 is a modern hash algorithm, and is used to prove that the data can't have been modified by anyone with having the password at hand. 256-bit hashes are the modern standard, with 512-bit hashes for those of us who want just a little bit more reassurance. The SHA-2 family of hash functions is the most recent NIST standard digests.

AND256BITAES = AES-256 is a modern encryption algorithm. The 256-bit key size is for those of us who want just a little bit more reassurance, even though a 128-bit key size can be sufficient for many uses. The AES family of functions are the most recent NIST standard block ciphers.

CBC = The CBC mode for encryption is the default choice for turning a block cipher into a stream cipher. Stream ciphers are needed when one has a stream of data of arbitrarily length to be enciphered. AES in CBC mode is a more modern choice than RC4.

BC = The choice of crypto provider library. Choose a reliable, performance crypto library. BouncyCastle is implemented in Java, so the JIT may be able to optimize it. OpenSSL is implemented in C and the crypto provider might have bindings to the C functions, but the JIT is unable to optimize the C functions.

If there is a need to encrypt, then there is an equivalent need to encrypt with modern algorithms and techniques. Use them, unless there is a specific, demonstrable, and proven reason against.


Two-phase anonymization EDIT:

[N.B: I fully replaced the original question which was not a very good statement of the problem (see comments) with a more apt one.]

I have records that contain - among other things - the location of users and their ID (it is a big stream of data).  I need to provide a 3rd party the location of users. (The stream is also filtered based on other criteria in the stream and perhaps even merged with some other data sources that all contain user IDs - if it is of any interest here and now.)

I must not pass the user IDs to the 3rd party.

The records a output have to enable the 3rd party to build up "routes" and/or time-variant location maps of users over a period of time (say a day but much longer than one hour).  To this end they must be able to identify records that belong to the same user.  Thus some key has to be passed.

An important restriction that constitutes the core of the problem:

For the discussion let me define "anonymized user ID" an attribute that is is derived from the attributes of the input records such that it is (nearly) uniquely derivable from the user ID (e.g. a hashed salted user ID or a fixed random mapping), and placed in the records of the output stream so that records that belong to the same user can be identified.

Legal regulations and internal rules are such that I must make sure that the "anonymized user ID" can be reproduced for no more than one hour.  (Just as an illustrative example: if I would happen to use a salted hash of the user ID as "anonymized user ID" I would have to use a new salt hourly.)

(Note: As mentioned above the 3rd party has to map locations to users for longer.   They still don't care about the identity of the user but they have to know that it is the same user all along.)

And the questions are: Is there a way to do this at all?  If yes, how?

To restate: your system has users with assigned IDs. You receive periodic location data associated with these user IDs in real time.

You also have one (or more) clients who want to analyze your user locations. Each client needs to receive randomized tokens that each map to a user ID, and the tokens can refer to a specific ID for a period of no more than some maximum duration, say 24 hours. The client needs the location data. The client never needs the real user ID.

And you have a policy prohibiting you from internally retaining the location associated with your real user IDs.

Here's a possible solution:

First, obtain a public key from each of your clients. At the start of each day, for each client generate a random salt and store it internally in RAM, keeping it secret. Upon receipt of a new User ID and location pair, add the client's salt to the ID then compute the hash. After hashing, immediately encrypt the hash with the client's public key, applying randomized padding, then immediately discard the hash. The encrypted salted hash is now a client-specific encrypted token. Preserve only the client ID, the public key ID, the encrypted token, and the location data; place the data in the appropriate message queue. Repeat the tokenization process for each client who will receive the data; after tokenizing the user ID for each of your clients, discard the real user ID.  You can then send the encrypted tokens with the location data to each receiving client. Once per day, destroy each client's secured salt and generate a new one.

By destroying the intermediate hash and the user ID, you remove the only links you have tying the location record to a real user ID. You control the client's ability to correlate records by destroying their salt.


Why is credit card information not stolen more often? Nowadays there are a lot of hacked websites with stolen login information. In many cases the website states that no credit card data and/or payment information was stolen.

Why is that? What I assume is: That both, the database storing the payment data and the one storing user-credentials are separated from each other. So far so good. But what I do not understand: Why shouldn't they be able to find access to the database storing payment information?

The latter is still visible/accessible from the outside; that is because users of the website can also view/add/edit their own payment information, e.g. whether they want to use paypal/credit card/IBAN. So the database is obviously accessible from the "outside world".

PCI DSS

The major reason for this is a decade long effort by the payment cards industry to limit the extent of such breaches by requiring everyone who handles payment card data to either (a) conform to a set of security practices and (usually) audit requirements, or (b) stop handling payment card data themselves and delegate it to someone who can handle this better.

You shouldn't underestimate the second part - while pretty much all sites handle their own user account data, the vast majority of sites (especially smaller ones) that accept credit card payments do not store credit card data in any way whatsoever; if they do want recurring payments without asking CC number every time, they instead store 'just enough' information to show the user (e.g. a partial card number) that this card is "remembered" plus a token issued by their bank/gateway/whatever that enables additional payments from this card to the same merchant - so these tokens are useless to an attacker.

While it's not 100% proof and there are many, many cases where PCI DSS is blatantly violated, it does mean a significant reduction in the number of vulnerable companies.


Why do attackers bother (trivially) obfuscating their source code? A friend of mine recently discovered and sent me a small collection of trojan php scripts that were uploaded to his machine. Here's an example:

eval(gzinflate(str_rot13(base64_decode('huge-string'))));
die;

Why do attackers bother doing all of this? Any developer can trivially reverse these steps to see the source code.

The only reason I can imagine is an attempt to prevent antivirus detection against an existing codebase (base64() the script, you have a 'new' virus, at least for a few minutes).

This vector is largely successfully mitigated by things like heuristic virus detection, which looks precisely for suspicious snippets of source like this.

This isn't aimed at defeating human analysis, it's aimed at defeating intrusion detection / prevention systems, and other automated scans, as the code comes into the network.

PHP is a Turing-complete language, which means that a single piece of code can be represented in a near-infinite number of ways. Automated systems have limited resources, and are designed with this fact in mind - they'll attempt to unravel basic eval obfuscation and other simple tricks, but there's little point attempting to analyse and identify every possible obfuscation technique. It's a losing battle, and their developers' time is much better spent implementing other features.

Once the code gets onto an internal system, it can be scanned by anti-malware software. These systems have access to the code as it runs, so it can be much more easily identified. There's no point analysing all the complex packing code when they can just identify the unpacked in-memory string using a simple detection signature.


Can an ISP limit what security software (firewall) that will work? My ISP (JCOM) says that McAfee is the only security software that will work with them. Is that true? The system is running Windows 7 Home Premium Japanese Version.
The McAfee system is provided by them and under their support but no obvious customisation mark.

No but they can blame any problems you have on running an unsupported firewall and refuse to offer any support until your unsupported firewall is disabled.


How can I reliably erase all information on a hard drive? As storage technologies change over time, using different encodings and remappings to deal with sector errors, the best way to permanently erase/wipe/shred data changes also.

Methods for flash drives and other solid-state drives are covered nicely at Jesper Mortensen's answer on SSD erasure.

Various methods for hard drives are described at http://en.wikipedia.org/wiki/Data_erasure and include

"Secure erase", a function built into modern ATA hard drives
Gutmann's methods for various old hard drives
An oft-cited data sanitization method in NISP Operating Manual (DoD 5220.22-M)

Does the ATA "secure erase" cover all modern hard drives and interfaces?

Are there modern storage devices besides SSDs that require something different?

The other option I've heard of is always encrypting everything you send to the drive yourself via something like Truecrypt.  If you do that, it would seem that you have to be able to securely destroy the keys when necessary.  And in the absence of a neuralyzer, does human memory of the password render any hard disk encryption schemes vulnerable to data recovery?

The only NIST approved method to securely erase a hard drive is by utilizing the secure erase internal command - documented at the Center for Magnetic Recording Research (CMRR) - and that is what everyone should be doing. It is an ATA command, and covers (S)ATA interfaces.
After that, you can optionally degauss the drive to erase the firmware itself.
Lots of interesting info in Guidelines for Media Sanitization, NIST SP 800-88 (2014).
A quote from the paper:

Secure Erase
An overwrite technology using firmware based process to overwrite a
hard drive. Is a drive command defined in the ANSI ATA and SCSI disk
drive interface specifications, which runs inside drive hardware. It
completes in about 1/8 the time of 5220 block erasure. It Was added to
the ATA specification in part at CMRR request. For ATA drives
manufactured after 2001 (Over 15 GB) have the Secure Erase command and
successfully pass secure erase validation testing at CMRR. A
standardized internal secure erase command also exists for SCSI
drives, but it is optional and not currently implemented in SCSI
drives tested by CMRR. SCSI drives are a small percentage of the
world’s hard disk drives, and the command will be implemented when
users demand it.

A more recent (2010) short presentation from NIST that compares different erase techniques and their limitation is in a ppt presentation by Lyle and Russell.


Clear Text Passwords I discovered recently that organisation X is storing web app usernames and clear text passwords in excel sheets on their internal network filestore.

These are not used for authentication.

I have tried to argue that the sheets should be encrypted/have some password mechanism.

The ultimate response, seems to be: if someone has gained access to read the excel sheet then they already have such wide access, the passwords are the least of the problem.

I have also suggested building a second network and moving the most crucial data to ithe,  with very limited access. There was concern regarding the admin overhead of this.

I don't know where or how to proceed in the discussion. Please help?

Clear text passwords in and of themselves are not a problem. The problem is with the risks associated with that data. What is the impact to the users, and what is the impact to the company if this data is leaked, disclosed, lost, or corrupted? What if it was publicised that this data was in the clear, as you describe?

If there are no risks, then it does not make sense to implement costly controls around it.

If there are risks, then the controls need to be scaled with those risks.

I know that it is easy to say, "OMG! Clear text passwords from a web app in 2016?! What kind of a company is this? There are numerous libraries that the devs could have called to take care of this from the beginning!" I know I did when I read your post.

But at this point, changes to the environment need to make sense in terms of the risks involved. Your job is not to come up with the most compelling technical or security argument (if one of those arguments would have worked, then the problem would not exist). Instead, your job is to quantify the risks to the company and propose a control appropriate to those risks to mitigate them. That's how you proceed.

If the risks are high and costly and they are still not interested, then ask them if their fire insurance is paid up. Small investments can stave off massive losses, just like insurance.

If you still cannot get them to deal with this, then you are left with the unfortunate, yet valid, situation of leaving this business decision in the hands of the business. They bear the risks. You gave them the needed info to manage those risks appropriately. There is not much else you can do.

But before you get to the fatalistic stage, get a good discussion going around the risks and how you can help them limit the company's exposure.


Difference Between Binary Exploitation and Reverse Engineering? I am a beginner in Reverse Engineering and am trying to improve my skill by participating in any CTF's I can and solving CrackMe's. I am trying to find out why Binary Exploitation and Reverse Engineering are always separated as two different topics.

My Question is simple:

  Is Reversing different from Binary Exploitation?

Rather that cite definitions of the terms I'd like to give my personal view of what these things are.

Reverse Engineering is the process of taking an output and and figuring out what the input was. It also means tracing the steps that a piece of information took from it being inputted up until it is outputted. Think of this as figuring out things work without having the source but a level of abstraction just above the machine. When it comes to software, reverse engineering tends to be the process of debugging the running code of an application in assembly as it runs. Watching it run, following the process it takes, allows you to trace the steps and reassemble them yourself into something meaningful you can use yourself.

Binary exploitation is the process of abusing subtle (or perhaps not-so-subtle) flaws in software to make an application performs functions that it wasn't design to perform. While it's not impossible to exploit flaws in binaries without doing reverse engineering, I would argue that almost all binary exploitation exercises begin with reverse engineering to understand how the application works and to help identify the flaws.


Password Reset URL forwarding If a previously registered user clicks on the password reset button during login, I want to send them an email with a reset password link.

I have three queries:

How to add an expiry date to the URL link?
How to structure the URL? I previously had not hashed passwords and sent a "click here" link with

https://www.example.com/?login&EMAIL=website&PASSWORD=text-password&LOGIN=1&PATH=2

Now I have hashed all passwords how do I structure the URL? Do i still include the email&hashedpassword as above or hash the entire URL?
I noticed with a well known UK site that when my wife requested my password to be reset I want sent the reset URL, but because one of my email addresses
is auto-forwarded to my wife's email, she was able to reset my password and log into my account. Obviously i'm not too bothered in this instance, however
I know many people who auto-forward their personal emails to work email addresses so technically someone could use a password reset URL to hack an account.

Is there a way round this...for example when you send the password reset URL, it only "works" if clicked from the mail client with that email address?

Don't do this. Add the expiry to the database, and check whether the token is still valid. If you add it to the URL, you are inviting people to modify it.
Why are you sending a password out? The industry best practice is to send a short lived, single use token that takes users to a page that allows for entry of a password and a password confirmation, then sends them to the application login page to use the newly entered password to log in. That way, you avoid ever sending passwords from your server, meaning that only server compromise of some sort will reveal any passwords, whether user or system generated.
There is not really a concept of "the mail client with that email address" - for example, I have an email account which I access from web browsers on various computers, an email client on my personal computer, and an email client on my phone. I also access other addresses with those same clients. The general way to ensure only the intended user can use such links is to keep the validity period as short as possible - an hour or so at most. There may be some users whose email takes longer than that to arrive, but remember that they are actively trying to log in at that point. If you tell them you have sent an email, they will probably go and look for it.


Access-Control-Allow-Origin wildcard doesnt allow sending session cookies I always thought CORS restrictions was to disable the following scenario:

I enter attacker.com, JS sends GET facebook.com, my browser adds my cookies, attacker.com has access to my facebook profile/feed.

BUT

I am trying to send a GET request from my http://shop.domain.com to MY http://www.domain.com/api/accounts/me with javascript, because I want to share some user information to my shop. shop.domain.com is shopify so I can't put any backend code to this subdomain.

I got this error:

Access to XMLHttpRequest at 'https://www.domain.com/api/accounts/me' from origin 'https://shop.domain.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

my API returns Access-Control-Allow-Origin: * and I STILL cannot post credentials. so what is the use case for Access-Control-Allow-Origin: *? I can understand why it's not working but What am I protected from if this header is not present.

What change does this header bring at all?

also my cookies are domain-wide but HTTP only, so JS on the shop.domain.com cannot just extract my session id.

The use case of Access-Control-Allow-Origin: * is to allow cross-origin XHR from any domain. This can be useful for some public API.

But in case a site requires a user to first log in and then keep the user authenticated using session cookies (or basic authentication), XHR within this session (i.e. with credentials) is usually only expected to be same-domain or in some cases cross-origin but only from selected domains. Cross-origin XHR from arbitrary domains which includes credentials  is very likely a fatal misconfiguration. To make the most obvious case of such misconfiguration impossible the combination of Access-Control-Allow-Origin: * and withCredentials=true will fail. If you want cross-origin XHR with credentials you need to explicitly specify the origins which are allowed to do this kind of sensitive access instead of just using a wildcard.

See also MDN: Request with credentials.


When did we start to call malicious software "malware"? I'm looking into the history of malware. When was malicious software fist called malware? I think that malicious software is called "computer virus".

According to dictionary.com this was first recorded in 1990-95; mal(icious) + -ware

Following chart from google Ngram may help too, (Ref)


What’s the best way to permanently delete data from your iPhone? As the title suggests what’s the best way to permanently delete data from an iPhone.
I know when you delete something, it’s not really deleted, but merely marked as ‘free space’.
So how, on an iPhone, can you make sure it’s gone for good so no high-level forensics can retrieve it?

I don't think there is a way to actually scrub the data.
The recommended method is doing a factory reset. All the data will be left behind intact but the encryption key will be lost, so the data will be virtually irrecoverable. (Or as much as the key can be brute forced in a reasonable time frame)


Is it possible to boot into root's /bin/bash on a LUKS encrypted device? I have to check the possibility of case mentioned in the title. An average Linux could be booted up into root's terminal directly without authentication by modifying kernel boot parameters.

I'd like to know, how is it possible (if any) on a LUKS encrypted device? How should I modify parameters without any other Live CD?

If the root partition is encrypted, then the only way to run its /bin/bash is to decrypt that file. In fact, if the partition is encrypted, the only way to even know whether there is a file called /bin/bash is to decrypt directories on the partition. With a LUKS encrypted device, you can't even know whether there's a filesystem there. So no, it is not possible to boot into a system where the root filesystem is encrypted. (Unless you know or guess the key, of course.)


Is this DNS reflection attack a DOS or DDOS attack? I was asked this as a test question and I was wondering if I answered correctly. I was thinking this was a DOS attack because it came from one server not multiple. So can anyone tell me if this is correct or wrong?

If you have 10 attackers and they all send requests to 1 DNS open resolver and the DNS resolver sends all the replies to just 1 victim. Is this a DOS attack or a DDOS attack?

I answered as a DOS attack.

I would have answered DDOS since there is distribution (10 attackers).

This is a rather difficult question - one would refer to a thorough dictionary definition of "DDOS", which does not exist.

If you look at "the web", definitions always state that several machines are used for the attack, which is the case here - one could even say that there are 11 machines participating in the attack.


Would Qubes still be secure on an untrusted machine? If you can't trust your own computer, would installing Qubes on it do any good? Or is it already too late if your machine might be infected?

In a theoretical sense, no, if you can't trust the computer then you can't trust Qubes. Just as an example of theoretical attacks the computer could record your keystrokes, your screen, mouse clicks, install infected version of qubes rather than the one you supplied, manipulate Qubes (via the same input channels you would use) and so on. On the practical side your biggest concern would be something like a hardware logger, where the keylogger is a piece of hardware rather than software. I have not personally seen malware that can survive an OS wipe and continue to monitor Qubes.


Does allowing SSLv3 or TLSv1.0 weaken other protocols? (TLSv1.2+) I know that SSL and TLS below v1.2 are insecure and should not be used.

By allowing the use of those insecure protocols, can that expose connections using the stronger TLSv1.2+ protocols to any vulnerabilities?

If I have some users who refuse to move off TLSv1.0, can I leave that protocol enabled on an 'at your own risk' basis without compromising the more sane users?

There are no currently known attacks like that. If your server does SCSV then modern TLS 1.2 or TLS 1.3 clients should be safe. But a future attack might be discovered that uses old protocols to attack connections using new protocol. A famous example is DROWN, in which if your server also supports SSLv2 or the private key for your certificate was used in a certificate that is used by an SSLv2 server (possibly different certificate, possibly different server), your TLS connections are vulnerable.

Note that some regulatory bodies prohibit leaving TLS 1.0 enabled.

Ask your users when they plan to upgrade from TLS 1.0. Their TLS 1.0-only client will become not very useful very fast. It is already not able to use credit card payments.

Set a deadline for your own support of TLS 1.0. A reasonable deadline is June 2018. We're a bit past that, so don't set your own deadline too far in the future.

Remind them that TLS 1.2 was released in 2008. Chrome has supported TLS 1.2 since version 29 in 2013.

I should add that there is a subtlety that is not apparent from just looking at the version number. The protocol TLS 1.0 is not completely busted, if it is implemented and configured correctly. I think a modern openssl 1.1.1 based server would be fine, communicating to a modern openssl 1.1.1 client (like a recentish version of python/ruby/php), even when limited to TLS 1.0. The problem is that a modern TLS client would support TLS 1.2 and AEAD cipher suites, and there is no reason to limit it to TLS 1.0. A TLS client that was implemented before TLS 1.2 was specified and has not been updated since is highly likely to be insecure. I would bet money on it being insecure. It is possible that the client has been patched since then and is secure, but if it could be patched, why couldn't it be updated to a version that supports TLS 1.2?

It turned out that implementing the TLS CBC cipher suites securely is too damn hard. All the major players had vulnerabilities, some of them needed multiple attempts to fix it (e.g. s2n), some made worse vulnerabilities while trying to fix it (e.g. openssl), some just gave up and recommended a switch to AEAD only configuration for those who are worried (e.g. golang). Some are still not fixed. An internet wide scan showed that vulnerable servers are still deployed, so a client connecting to a random internet site that supports only TLS CBC cipher suites is not guaranteed that the connection is secure. The browser vendors are going to ratchet the whole ecosystem, kicking and screaming, into PFS+AEAD. But it will take years, because some people expect to use a Red Hat server for a decade without upgrading. Note that HTTP2 standard has already said that only PFS+AEAD is secure, and lower security cipher suites are not allowed for HTTP2. In 2015. TLS 1.3 only supports PFS+AEAD. That was out in 2018.


Does DNS pinning protect against all DNS rebinding attacks? I found an example of a DNS rebinding attack scenario in the paper "Dynamic Pharming Attacks and Locked Same-origin Policies for Web Browsers".

  Figure 1: An example of a dynamic pharming attack against www.vanguard.com. (1) Initially, the pharmer arranges for the victim’s DNS queries for www.vanguard.com to resolve to the pharmer’s IP address, 6.6.6.6. (2) Then, when the victim visits www.vanguard.com, the pharmer returns a trojan document containing malicious Javascript and a iframe referencing Vanguard’s home page. (3) The pharmer then updates the DNS entry for www.vanguard.com to the IP address of Vanguard’s legitimate server and denies subsequent connections from the victim. (4) This causes the victim’s browser to renew its DNS entry for www.vanguard.com, and (5) load Vanguard’s legitimate home page in the iframe. (6) After the user authenticates herself, the malicious Javascript in the trojan document hijacks her session with the legitimate server.

Now it seems browsers today implement a feature called DNS pinning. From Wikipedia:

  Web browsers can implement DNS pinning: the IP address is locked to the value received in the first DNS response. This technique may block some legitimate uses of Dynamic DNS, and may not work against all attacks.

My question is: does this countermeasure effectively protect against the described attack scenario? If so: what are some examples of attack scenarios that are not successfully protected against (see claim in Wikipedia quote)? If not: what's the reason why the attack succeeds and how could you succesfully protect against it?

DNS pinning does not protect against sophisticated DNS rebinding attacks.

Consider a scenario where an attacker sets up a firewall in front of their web server. You request their website, attacker.com, which results in a DNS query returning their IP address. The DNS result has a TTL (time to live) of 1 second. Normally, this means the browser should make another DNS request after 1 second has passed, however, DNS pinning instructs the browser to ignore the TTL and add some unit of time (say one hour) to it. So now, your browser won't make another DNS query for that hostname for 1 hour, 1 second. After the DNS query completes, your HTTP request is sent and the attacker sends back the website you requested with javascript code which will launch the attack.

Now, the attacker's Javascript has set up an AJAX request which waits two seconds before firing. Then it automatically requests some resource on the attacker's website again. However, the request fails. This is because the attacker has already set up a firewall rule blocking your browser's request. Now we are in the following state:

The TTL has expired on your first DNS request, but DNS pinning is still in effect
You made a request back to the attacker's website via their JS AJAX call
The request was dropped by the attacker's firewall

These three things will cause your web browser to send another DNS query despite the fact that you are using DNS pinning. In effect, the attacker has easily defeated your DNS pinning strategy by using a firewall and sending a second request outside of the TTL. DNS pinning isn't an effective strategy because there are plenty of legitimate reasons why someone's server might be down; your browser is forced to make a second DNS query in case there is another DNS record that will resolve to the correct machine (e.g. in case of a server migration, downtime, whatever). Basically, your browser has no way of knowing whether or not it's actually being attacked here; for all it knows, the server is legitimately down and so, it MUST make another DNS request.

So... why does it matter that there's a second DNS request?

The second DNS request is usually used by the attacker to return an incorrect IP address for the DNS record. Browsers have what is called a "same origin" policy which prevents webpages from making requests of resources that they do not own. Basically the way same origin works is that it says http://hostname.com can only request http://hostname.com. But it actually works using the IP address for hostname.com, not the human readable hostname itself. So in a DNS rebinding attack, when your browser makes the second DNS query that I described earlier, the attacker will return a "fake" IP address in the DNS query result. Then your browser will think, for example, that the IP address 1.1.1.1 belongs to attacker.com even though it really belongs to google.com. This allows the attacker to exploit the same origin policy of the browser; now the attacker's javascript can request stuff from google.com via AJAX. Also, they can read and set cookies and other malicious stuff. This exploits same origin policy by tricking the browser into trusting the second DNS record that was returned. Now the browser thinks hostname.com is associated with the IP address 1.1.1.1 even though it really isn't. What's a browser to do? DNS doesn't have that kind of authentication built in. :(

Preventing the DNS rebinding attack

There are a bunch of ways to prevent it, and I'm pretty sure modern browsers already have implemented protection against these attacks. One easy way to prevent it (as a web owner) is to check the HTTP host header of a request. For example if you are google.com then you would receive a request but the host header would still say attacker.com. Obviously that isn't part of your domain, so you can prevent the attack simply by dropping the request. Why would someone want to do this to begin with? Well, click fraud in advertising. Scraping search engines from many machines at once. Stealing valuable data from web sites on your internal company network. Etc.


Perfect Forward secrecy in TLS session I am looking at packet captures of perfect forward secrecy for cipher "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256". Per definition of PFS, after initial client and server hellos exchanged, both sides must come up with public-private key pairs and they share the new public keys. In packet capture, i am seeing client is sending its public key in very next message (under "EC-Diffie-Hellman Client Params" header) but server doesn't (instead server is sending new session ticket). How does server sends its new public key to client?

From RFC 4492, section 2.2:

  The server sends its ephemeral ECDH public key and a specification of
  the corresponding curve in the ServerKeyExchange message.  These
  parameters MUST be signed with ECDSA using the private key
  corresponding to the public key in the server's Certificate.

  The client generates an ECDH key pair on the same curve as the
  server's ephemeral ECDH key and sends its public key in the
  ClientKeyExchange message.

Further, in sections 5.4 and 5.7 you can find their structure.


Authentication: Username (email) and password hashed together in one database field I am currently developping a platform with a PHP framework for our client.

The head of the client's IT department wants us to handle authentication with one database field containing email+password+salt (hashed) so there isn't a plain text email field in this table and the password is more secure (his reasoning). The user should be able to login with his email address and password. So the email address serves as the username.
The idea behind this is that the email addresses of the users are very important for the business of our client and the IT head wants to obscure the email address in the login table in case of a possible attack. (e.g. a hacker gets access to the login table)

This is of course only possbile, because the hashed email adress for the login is linked to his email address in the profile table.
Basically there are two tables which are required for this process to work. The tables are in the same database of course.
One login table with the hash combination field (email, pw, salt) and one profile table which contains among other things the email in plaintext in one field. Let's call it profile_email.

I have strongly recommended not to use this solution, because I have never before heard of this and I have already identified some possible problems with this solution.

So my questions are: Is this a safe and feasible solution? Can you think of any unforeseeable problems? Have you heard of similar solutions?

As far as I can tell, this scheme doesn't make any sense.  As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash.

As I'm sure you've already noted, without the plaintext email (regardless of whether it's in the profile table or the login table) relying solely on a single hashed value of email + password + salt is infeasible (you would have to go through each row, getting the salt, computing the hash, seeing if it matched, if no match, getting the salt from the next row, computing the hash, seeing if it matched, etc, etc, etc...) and would be a security disaster, because it would allow an attacker to test the hashes for all users on the site with a single login attempt vs. only being able to test the hash for a specific user.

I don't see any good reason to do this.   It doesn't improve security, it does increase complexity, and the implementation is fraught with peril.  You should politely, but firmly push back on the client to follow standard best practices rather than trying to invent his own harebrained scheme.


Layered email encryption with multiple private keys on separate media I'd like to encrypt e-mail messages so that multiple physically separated keys are needed to decrypt them.

For example, I'd like to have three private keys stored on different media, as in:

key A on a harddrive,
key B on thumbdrive 1, and
key C on thumbdrive 2.

I'd like to have the messages encrypted successively to all 3 keys, so that I have to decrypt with all 3 to recover the plaintext.

Will Thunderbird work easily for this? What is a good cryptomail client?

Note: This answer was posted before the question was migrated from Cryptography Stack Exchange.  As such, it only addresses the purely cryptographic aspects of the question.

What you could do is set up a single public/private key pair using e.g. RSA or (EC)DSA, and have your e-mail program store the public key and encrypt your messages using it.

You can then store the private key in a file successively encrypted using three other (public/private or symmetric) keys, and store those other keys in different locations.  Thus, in order to decrypt the messages, you'd first need to decrypt the private key, which would require all the other keys.

Alternatively, you could split the private key file into multiple shares using e.g. Shamir's secret sharing, and store the shares in separate locations.  One advantage of this method is that you could set up the secret sharing scheme to only require some predefined fraction of the shares in order to reconstruct the key.  For example, you could generate four shares such that any three of them would be enough for reconstructing the key; that way, you could still decrypt the messages even if you lost one share.

As for recommending a good e-mail client for encrypted messages, I'm afraid I can't help you much there.  In any case, it's really off topic for Cryptography Stack Exchange; you may get better answers to that part of your question at Super User or at Information Security Stack Exchange.


How secure is to seed PRNGs with the sequences from CSPRNG? Background: Implementing online casino, I would like to use a number of PRNGs with high throughput, like MersenneTwisterFast. I know it is not cryptographically strong, but quite unpredictable when used with a proper seed value (is it?), let's say, AES-CTR.

Question: How secure would be the PRNG, initialized by a generated value from another PRNG, that was initialized by a cryptographically strong seed (taken from /dev/random per se)?

As to my mind, good PRNG algorithm can't be predicted when seed is unknown (and which is securely random), so the seeds for the second level PRNGs are also securely random, and their sequence is also unpredictable. Am I right?

UPDATE: I think this article is highly related to my question: /dev/urandom is actually a properly seeded CSPRNG seeding other CSPRNGs.

This certainly looks like premature optimization.

A fast CSPRNG on a modern Intel CPU will output between 500 MB and 2 GB per second. Even if you have a quite random game which requires 100 random bytes per second per player (I can't think of a typical casino game anywhere near that) a single core will be able to generate random numbers for ten million simultaneous users.

Other operations, such as database access, the webserver etc. will be much more expensive than generating good random numbers. I recommend seeding a good stream cipher like ChaCha or AES-CTR from the system random generator instead of downgrading to an insecure PRNG. It's possible that the system random generator by itself is already fast enough.

Check eBACS for benchmarks of stream ciphers.

Using non crypto PRNGs like Mersenne-Twister for an online casino is a really bad idea. These generators don't aim an unpredictability. They only try to look random enough that their flaws don't cause any deviation from actual random data that breaks the using code by accident.

For example if you ran a scientific simulation with MT and with perfect random numbers and it gave different results, that'd be considered a flaw in MT. But it doesn't try to resist somebody who deliberately tries to predict the output.

As @CL. already said, MT is easily predictable once you've seen a few hundred outputs. Compare that with a CSPRNG which will be indistinguishable for true random numbers even after observing petabytes of data.


Why don't more DGA malware families use word-lists? Of all the known malware families that use DGAs to communicate with their C2, only very few use DGAs that generate non-random-looking domain names. For example, Suppobox generates domain names by randomly selecting a few words from a hard-coded word-list and concatenating them together. Rovnix does the same but uses publicly accessible copies of the U.S. Constitution rather than a hard-coded list.

The goal of this is pretty clear: to circumvent the algorithms used by security software that detect random-looking domain names. So this has me wondering: why don't more DGAs do this? For a malware designer, what are the possible downsides to using this strategy?

Black hats have limited resources too, same as the white hats. Thus as long as a technique works good enough for a malware there is not much motivation to change it. Instead it is more effective to improve the parts of the malware which are more impacted by advancements of the white hats. But, if the current DGA algorithm too heavily impacts the functionality of the malware then the authors will probably move to different algorithms or use a different C+C communication architecture.


Do SIEM appliances perform similar tasks to non-commercial anti-malware software? First of all, let me apologise if this is considered an ignorant question. I'm new to the concept of SIEM and have been asked by my new employer to familiarise myself with the subject.

I understand that SIEM is a security appliance for enterprise users, and that there are many different versions out there - I'm currently trying to understand the McAfee SIEM product.

My question is this, do SIEM appliances perform similar tasks (as well as the additional, high-end enterprise tasks on top) as done by non-commercial anti-malware software available to general consumers; e.g. detecting/stopping viruses and other threats, scanning systems for threats, etc. but on an "enterprise" level, or are they a completely different kettle of fish and are not to be confused with each other at all?

Do they share any similarities at all?

If a similar question has been asked before on this site, please do point me towards it. Thanks in advance for your help.

Anti-Virus scans files for malware signatures. It could run on an email gateway or firewall or individual machines

A HIDS runs on individual machines (usually servers) and checks for malware signatures, rootkits, and modified files, and analyzes network activity (for that machine), and log entries. Generally you want your HIDS to report to a central server

A NIDS runs on a dedicated computer or device, usually connected to a mirror port on a switch, or on a network tap. It analyzes network traffic looking for intrusion signatures

Syslog runs on individual machines and logs system and application info. Hopefully you ship these logs to a central server

A SIEM collects data from your HIDS and NIDS and syslog and correlates the info, looking for suspicious interactions

There are open-source SIEMs such as OSSIM


Question about Trusted Service Paths I am studying Computing Security, and I was reading this article about Windows privilege escalation. I tried to run the following command on my own Windows machine to see if I had some "Trusted Service Paths" issue:
wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v "C:\Windows\\" |findstr /i /v """

And I got the following output:
c:\wamp\bin\mysql\mysql5.6.17\bin\mysqld.exe wampmysqld

So I don't get it, the command above was supose to find out paths with "spaces" in it (like C:\wamp\bin\Some Folder\ for instance), but here I can just see dots. So my question is: are folder names with dots vulnerable to Trusted Service Path attack ?
(meaning, if I put a mysql5.exe in mysql folder, will Windows parse/execute it also when trying to reach mysqld.exe ?)
Thanks

Unquoted service paths are only vulnerable if they contain spaces. That is because Windows would handle the space as a break and pass the rest of the service path as an argument.

Original path:

c:\wamp\bin\mysql\mysql5.6.17\bin\mysqld.exe wampmysqld

If the path would look this way:

c:\wamp\bin\mysql\mysql5 6.17\bin\mysqld.exe wampmysqld

Windows would first try:

c:\wamp\bin\mysql\mysql5.exe 6.17\bin\mysqld.exe wampmysqld

and if there's a file with that name there, it would try to execute it otherwise Windows would try the rest of the service path until next space or the end, depending on if there's an argument or not.

c:\wamp\bin\mysql\mysql5 6.17\bin\mysqld.exe wampmysqld

By quoting the service path you define the correct path, everything there after is handled as arguments.

"C:\Quoted\Service\Path.exe" <argument>


Is there any conceivable reason to prevent a password change in an authentication system? I connect to the VPN of another company with a company-specific username and password (they aren't giving everyone the same password to every company to access it or anything ridiculous like that.) After one of our employees left, I contacted this company about updating our password. I was told they are unable to change passwords and can only issue new usernames. Doing this would mean about two months of being unable to use their system due to paperwork and bureaucracy, so obviously quite an inconvenience.

Is there any reason besides poor design that their system would not be able to accommodate a password change? Passwords are also recoverable. This is a large company and there are probably a few hundred companies using this system, and as it is government-related there are no alternatives.

I agree this must be bad design. You may want to have password stability over certain periods for synchronization across systems or when a new system is integrated into a larger system. Except for those circumstances, you want to be able to change a password  whenever a password may have been exposed, which could be anytime.

The only thing I can think of is that the password is used for a secondary purpose, such as making a digital signature of every person who read a particular document. In a case like this where the password is used to keep a record of an individual's action it would be complicated or confusing to change passwords. However the easy solution is to issue a password for authentication and another cryptovariable for digital signatures.


Paypal sent an email addressing me with one of my old passwords as my name I got this email from service@intl.paypal.com, with the title:

Your account has been limited until we hear from you.

I think this is a scam / spoof email because I don't see any notification in my Paypal account and this is Hotmail account is not used as my Paypal login. (It used to be not any more for more than a year.)

But the troubling thing is, the TO: field has my old password as my name, then my email in brackets. A screenshot below should clarify what I'm saying. I've blurred my email and the two red arrows are pointing to what was my old password in plain text.

Is there anything I could do to protect myself? Does that mean the sender has me under their "contact book" with my name as my password? I have already forwarded the email to spoof@paypal.com.

It seems like the spammer got your personal information including your password through a security breach somewhere. Why did they use your password instead of your name? I would say it was an honest mistake on their side. They just mixed up the fields when designing the spam mail.

When you are still using the password somewhere, you should change it ASAP. In the future you should avoid using the same password for different services. Data breaches become more and more frequent, and they even hit larger companies which really should know how to secure their systems. Using a password manager like KeePass can help you to manage all the different passwords.


Shielding electromagnetic wave I tried putting mobile phone in a microwave oven and close it, putting the phone in a fridge, a cooker and close it,... every time the phone still can receive the call from other phone which means those devices can not shield against electromagnetic wave.

AFAIK, there is attack based on electromagnetic leakage, so at least, is there any effective and simple way to shield electromagnetic radiation?

Use a faraday cage. I have tried it before and managed to completing shield it such that it is unable to get any GSM or wifi signal.

http://en.wikipedia.org/wiki/Faraday_cage

A link on building simple homemade faraday cages : http://www.thesurvivalistblog.net/build-your-own-faraday-cage-heres-how/


Can the root user be removed from a *nix system to prevent privilege-escalation? Once a *nix system is properly configured and hardened, is it a conceivable strategy to remove all super user/root users? Are there benefits to removing root from a system altogether to prevent super-user privilege escalation exploits altogether?

Edit: More to the point: Can super user (root, uid=0 or otherwise) be replaced entirely with a capability based system?

Even if you wanted to, I don't think you can remove the root user. From Wikipedia:

  On Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser, regardless of the name of that account.

and a lot of the kernel code that vulnerabilities exploit does stuff like

// become root
uid = 0;
...
if (uid == 0)
    // do some protected thing

So the superuser isn't really a "user account", it's literally the number 0. If you can find an exploit to set uid = 0 then bam! your process has sudo, regardless of whether or not there's a user account named "root".

EDIT ADDRESSING COMMENTS: several flavours of linux prepend a "!" to the root's password in the /etc/shadow password file (a character that can not be generated with the password hashing function) which makes it impossible to actually log in as root. That stops some types of root-priviledge escalation attacks based on cracking the root password, but the more dangerous kind of privilege-escalations are based on buffer-overflow attacks that over-write a process' uid variable to be uid=0, at which point that process is root.


SMBv1 Server vs Client relative vulnerability risk IT support guy here (NOT security expert):
I have several clients who currently have at least one legacy appliance that runs a Samba (or something like it) server using SMBv1, which cannot be upgraded to use higher SMB versions.  Other than replacing the appliance completely (which in some cases would be quite expensive (e.g. CNC machines)), their only choice is to continue using SMBv1 for now.
If we look at SMBv1 vulnerabilities ONLY, the two security extremes would be:

No SMBv1 enabled on ANY device on the network: MOST secure
SMBv1 enabled on ALL devices on the network:   LEAST secure

I would like to understand some "middle ground" options:

If have ONLY the appliance itself (call it APPServer) plugged in and accepting SMBv1 connections, have I introduced a vulnerability to ANY other device on the network?  If so, how?

Obviously, if the APPServer is only speaking SMBv1 and it's the ONLY thing speaking SMBv1, it's gonna get pretty lonely, so...

If I now enable SMBv1 (Client-side ONLY) on ONLY one of my Win10 clients so that it can communicate with APPServer, how much worse has my situation gotten?  I'm guessing the APPServer could then be compromised if the Win10 Client was infected, but wouldn't everything else on the network be unaffected by SMBv1-related issues?  If not, how?

I assume Microsoft separated the ability to disable SMBv1 between client and server on recent Win10 installs because a device accepting SMBv1 connections as a server is inherently more vulnerable than using SMBv1 from the client side.  Is this assumption correct??
If so, am I correct in thinking that in scenario 2. above, the only device that is still vulnerable to an SMBv1-based attack is the APPServer?
If my reasoning about this is incorrect, please give a specific example if possible about how the WIN10 SMBv1 client (or ANY other device on the network) could be affected by an SMBv1-based attack.
I should mention that neither the APPServer or my Win10 Client in scenario 2. would be exposed to the public internet.

In general it seems like you've got a good understanding of the attack space.  Going to attack each question independently as there are a few here.
Questions

If have ONLY the appliance itself (call it APPServer) plugged in and accepting SMBv1 connections, have I introduced a vulnerability to ANY other device on the network? If so, how?

Not really.  It would be a good place to establish persistence.  Say there was another vulnerability, the attacker got in, their next move would be to gain access to as many devices as possible so when the original attack vector is squashed, they'd still have access.

If I now enable SMBv1 (Client-side ONLY) on ONLY one of my Win10 clients so that it can communicate with APPServer, how much worse has my situation gotten? I'm guessing the APPServer could then be compromised if the Win10 Client was infected, but wouldn't everything else on the network be unaffected by SMBv1-related issues? If not, how?

No.  Any device on the network can infect the APPServer, it doesn't need to use SMBv1 client to do so.

I assume Microsoft separated the ability to disable SMBv1 between client and server on recent Win10 installs because a device accepting SMBv1 connections as a server is inherently more vulnerable than using SMBv1 from the client side. Is this assumption correct??

Yes. That assumption is probably correct, though I'm not aware of MS explicitly saying this.
Publicly Exposed
I know you said that the AppServer is not exposed to the internet, but there always is the potential for the server to be exposed inadvertently or via an exploit on the router/firewall.  I've seen some exploits that allow an attacker to add port forwarding rules, to which you could use to point at your AppServer then pivot through the network.
General
All this being said, I'd still never recommend having a SMBv1 server on the network at all, there might be a way to plug it into a SMBv3 server over USB and share or some other protocol.
Good security is not only having a strong wall on the outside but also secured devices inside.


How does a hack leave no trace in server logs when there is a WORM IDS? I am wondering if a hacker managed to either SQL inject or social engineer into a database, how does one not leave a trace in the IDS (Intrusion detection like OSSEC)?

If an IDS is monitoring the server, logging everything that is write once then read only... Wouldn't it mean every step that's taken will be logged? SQL inject might trigger the IDS, so let's say a hacker social engineered to get a pass into the db, but still any steps logged... But you can't erase it as its write once only. Then how does a hacker leave without leaving any traces? Otherwise the last IP contact point can be revealed...

The write-once property of logging systems are poorly written most of the time.

Even you believe that your IDS is bulletproof: Don't forget that the attacker has full control over the attacked host. So, he can even control whether the host send packets to the IDS or not. Even if the packets are sent to the IDS, the network itself is mostly susceptible to attacks.


How can I share sensitive information with my team? I need to share information with my team, like passwords and credit card numbers.

The needs are pretty minimal -- just an encrypted "spreadsheet". Keepass is potentially a solution but

the user interface is horrible (all command-line would be fine)
It doesn't allow individual user access and revocation
it requires a master password that is shared by many

CPM seems to be what I'm looking for, it solves the above three problems, but it hasn't been maintained in a few years so I haven't looked into it too deeply yet. However maybe it doesn't matter that it's not maintained, because the underlying security is handled by GPG which of course is maintained.

What other solutions are out there?

Why don't use an OpenPGP implementation?
Which one will depend which one is available for your systems, check in your package list.

Many mail clients integrate it (thunderbird, evolution, ...), and you can update the public keys to a public key server (I'd recommend exchange them on a USB driver though, or using a known secure data transfer protocol and being careful).
Once it's setup in the mail clients, it will work out of the box, nothing to do...

In your case you might want to exchange the private key with everyone, surely you won't be able to exchange it by mail in clear text, you'll bite your tail. So it's the same problem, but you'll have to deal with it once and then your done.

Or you could send them the encrypted file and you would tell them the password via another communication system (phone, letter), unless your infrastructure is seriously compromised, it should guaranty a adequate level of security. Actually that's what banks do when you ask them to send you your online banking password, they won't tell it to you on the phone or by email but instead mail it to you in a old fashion way.

EDIT: please note that email are really unsafe, if a mailbox is compromised in the future, it will let the attacker access all the private files and passwords. Be sure to transmit critical data on a non-resilient support.


How to sign & timestamp log or zip files? I think I can easily sign the files however I also need a timestamp from 3rd party vendor. I want to digitally sign + stamp log files including DHCP & mail because of laws here.

UPDATE: I found more info about time stamping.
http://www.signfiles.com/timestamping/

If I understand what you are asking, it seems to me you are looking for a File Integrity Monitoring solution. Are you familiar with FIMs, or have you researched them? Do you think that fits what you are looking for?

Not sure what budget you are working with, but Tripwire is popular FIM vendor.


How does choosing where a password is stored affect non-repudiation? (or private key storage) Password managers, and numerous tools have been created to store end-user secrets over the years.  This proliferation has resulted in a hazy mix of opportunities to improve security.

In short, I think this could be broken into the following groups. (alternative scenarios wanted)

Local Authentication (w/no implicit network rights) (semi-transferrable secret)
Network Authentication (with implicit network rights) (semi-transferrable secret)
Hardware Authentication  (non-transferrable secret) for use with either above scenario

I'm trying to create a risk diagram of where authentication credentials can be stored, and what are the risks/threats of each approach.

The goal is to give an application developer, or security consultant a guide on the where an end user should store private keys and unhashed passwords should be stored for nonrepudiation purposes.

Question

What local authentication patterns exist, and what are the relative strengths in guaranteeing nonrepudiation?

This is an compendium of authentication methods.  I hope someone completes this map, and scopes it appropriately for nonrepudiation.

Most of my security knowledge is based in iOS, but input on other platforms is welcome.

Local only authentication

The key difference is that remote attacks (SSH/RDP/HTTP 401 Unauthorized) aren't possible even if the remote user has all the correct information.  The benefit here is that if the person is in physical control of the device, then the device itself acts as "something they have", and less stringent security rules may apply.

In addition, sometimes this authentication credential isn't directly convertible into an authorization token.

Depending on if the private key material is hardware secured (next section) it may escalate privileges by accessing a secure storage on the device.  Not sure if this distinction is worth noting since I haven't observed network authentication that leverages this security feature.

Windows

Windows Hello as face recognition
Windows Hello as pin entry
Windows Hello as picture unlock
Windows Hello as Thumbprint

Android

Pattern unlock
Pin unlock
Thumbprint

iOS

Thumbprint
Pin code

Apple Watch

Pin Code
Wrist detection

Hardware Secured

This is where private keys are non-transferrable, and/or the validating algorithm is secured by hardware.  Private key extraction may provide physical indications of trespass, and may risk rendering the authentication device itself inoperable.

None of these modes are usable across the network.

These authentication modes build on the previous local authentication methods.

Apple iOS Secure Element (SecKeyGeneratePair only)
Apple Watch Secure Element (SecKeyGeneratePair only)
TPM-based devices?
YubiKey (NFC/USB)

Hardware Secured Part 2

I'm not sure how to classify smartcards, since in RDP it's possible to authenticate to a remote machine through another machine.  I need to do more analysis of how a Smartcard private "proxy" works in contrast to other "proxy" solutions that could theoretically be used in the previous section

Smartcards

Software Secured via the OS

This is where the OS provides a measure of security.  Jailbroken or rooted devices may compromise security guarantees otherwise available.

These may be conditionally transferrable outside of the trusted ecosystem (some more easily than others).

iOS

Private storage per application
Application Groups
iCloud synchronization of private storage
SMS messages (iMessage has no 3rd party hooks; Android does)
Browser based Same Origin policy (Bearer tokens, remember me cookies, SOP, HTML Local Storage)
Safari app-to-website synced password via iCloud

Windows

TPM-based devices?
LiveID / Passport authentication
Browser based Same Origin policy
Browser-based local password caching (Chrome, IE, FireFox)

Chrome

Chrome password synchronization to passwords.google.com'

Android

SMS passwords/one time codes could be intercepted by 3rd party applications

Software Secured/Password managers

In many cases a password manager either provides "an additional place to look" for these transferrable/bearer tokens, and doesn't provide the same level of integrity that the hardware secured secrets provide, and doesn't have OS level guarantees.

HOTP/TOTP in software, such as Google Authenticator (it keeps the key somewhere), and Facebook authorization codes (depending on where the app stores the key, and if the device is Jailbroken/rooted)
Lastpass, Avast, 1Password can store the password database in DropBox, which makes it pretty easy for a 3rd party dropbox application to gain access to the file, and brute force the credentials. (OAuth tokens by 3rd party clients often request full access, not scoped)

Backups

The backups can be weakly encrypted on a compromised computer, or other device which can then be used to take all bearer tokens, or non-"local only"


How does a keyfile work? I was looking at some code on codereview that is far out of my league of understanding and just screwing around, but it raised a question.

This program (along with many other encryption programs, i assume) uses a keyfile.

Now, if I use /dev/random as my keyfile, it'll (theoretically) never be the same. Therefore, I could never decrypt the output file.

Is this feature unique to One Time Pad encryption tools? How am I supposed to decrypt it?

What do other tools do differently to allow me to decrypt it in the future?

Keyfiles have nothing to do with OTP encryption. Rather, they are, as the name implies, files that each contain a key. Naturally, trying to change the key midway through an encryption round-trip will not work at all, so yes, you have to use a file with identical contents to decrypt.

A good keyfile is a few kibibytes or more of randomized data stored in a largely inaccessible and (if possible) suitably obscure spot, say buried as one photo among a couple thousand mediocre shots of family holidays and the like. (I suppose the randomization could be added steganographically.) It functions much like a very long randomly-generated password stored in a file, and like a password, anyone that knows the right one can decrypt accordingly. But again, just like a password or any other key, you don't simply pipe /dev/random to it and call it a day: you have to keep the random-generated data around.

And to emphasize again: if you have a file with the right contents, you can decrypt; if you don't, you can't. This does mean that backups become just that little bit more important, and perimeter/physical security too.


Found PHP script with erratic code, htaccess kept resetting even if I change it When I browse on my hosting account, I found the index.php of my website has some code embedded to it, in the beginning there was really long line containing erratic code. There was also two more suspicious files I never saw the content of, I will paste the link of each respected files.

Code embedded from index.php -- link
Another php file -- link
Yet another php file (I had to use file sharing service because the file was big) -- link

I already deleted other files which contain some random suspicious looking code. The website was hosted on shared hosting service, is it a marketing website where I advertise my product.
I also saw that the .htaccess file had been modified to include unwanted .php code, when I change it to my original one-- after a minute or so the file kept reverting back to malicious one.
Can you tell me whats the next step for me ? Should I be concerned at this point ? I will gladly post any information you deemed useful. Thanks !

It looks like malicious code was inserted in your index.php file.  I took a look at the code you posted at https://controlc.com/64190848, and this is obfuscated code.  I used unphp.net to de-obfuscate this code.  You can see the result at https://www.unphp.net/decode/200752e5c8246fc5472ddc5ab9a3734f/.  Clearly, this is malicious code.
As to how this happened - there are a number of possibilities.  Your hosting service may have been exploited.  Or, one of your PHP scripts (or a component or plug-in that you are using) may have a vulnerability which was exploited.
As to how to recover - hopefully you have copies of your PHP files from before they were exploited, and you can recover from these.  Going forward, you may want to host your own site, so that you have more control over your environment.  It's inexpensive and simple to setup a LAMP web server on a VPS using Amazon AWS, or another VPS provider.  You also might want to take a close look any components or plug-ins that you are using, to be sure that you have the latest versions of these, and that there are no reported vulnerabilities in any of these.  Last but not least, once you are back up and running, you might want to run a vulnerability scanner against your site, to see if it finds any vulnerabilities (this may have been what the attacker did, to exploit your site).


How to check a public RSA key file is well formed? Inside a shell script I want verify a public RSA file. I want to find a way to check if this file is a genuine public key file, nothing else.
What are the ways I can verify this input file to check this is a genuine public key file, not a regular file?
I will be using this public key file in the future to validate an incoming encrypt gzip file, but that is out of scope for now.
I want to validate the input file to check its genuine RSA public key file is not an ordinary file. Please note that I do not have any other files with me (for example, a private key).
For example, if the file is ‘public.pem’ I just want check inside that it’s a genuine RSA public key file, not just a file with texts or file is not corrupted.
I’m already checking that file is not zero sized and the MD5 hash.
Other possible checks I found
Check the file contains the text ‘BEGIN PUBLIC KEY’ and ‘END PUBLIC KEY’.
I also found the following command using Google Search. Is there a better way to do this using OpenSSL?
openssl rsa -noout -text -inform PEM -in pubkey.pem -pubin

I found a satisfying answer in an answer to Stack Overflow question How to check a public RSA key file.


Why should my certificate signing request be signed by my private key? Why should my certificate signing request be signed by my private key?

Even if I obtain a bogus certificate out of someone else's public key, that is going to be useless, since in SSL the communication can happen only via session key. That session key will be available to me only if I have the corresponding private key for the public key I used to get the certificate for, for the client (or the other party) is going to send the session key encrypted using the public key and I can decrypt it only if I have the corresponding private key.

What then is the need to prove to the CA that I own the private key for the public key I am requesting the certificate for?

I'm sure if you looked hard enough you could find the official explanation:

  The signature on the certification request prevents an entity from
  requesting a certificate with another party's public key. Such an
  attack would give the entity the minor ability to pretend to be the
  originator of any message signed by the other party. This attack is
  significant only if the entity does not know the message being signed
  and the signed part of the message does not identify the signer.  The
  entity would still not be able to decrypt messages intended for the
  other party, of course.

RFC 2986: PKCS #10: Certification Request Syntax Specification -- Version 1.7


Log information for SIEM auditing in Linux How can I know what all types of events generated by Linux. I can get this from the logs, but reading logs and noting ID's is very time consuming.  All events might not be triggered.

I need this information for SIEM auditing. So is there any source where I can get this information?

Auditing is broad term and could mean auditing that the SIEM is working as expected or generating reports providing detailed usage statistics. (It could mean many other things beyond these as well)

The SIEM will only be as good as the data source, so that is the first thing you should check. Ensure you have a number of defined use cases, for example low level use cases may be normal user accounts attempting to use SUDO or add jobs to cron.

One you have a collection of use cases you need to ensure they are being logged. Linux does not log all actions by default, even if it does log them by default you need to ensure that the connector to the SIEM is receiving the raw logs. Depending on the Linux system and the methodology used this will differ, but the most common setup I have seen recently usually involves using rsyslog and auditd.

Once you have the raw data being collected by the SIEM connectors you then need to ensure that the raw logs are being parsed and normalised correctly, this is something I have seen configured incorrectly before and it can cause problems down the line. Standard syslog connectors may form a basis for the normalisation process, but depending on which logs are being collected and what format they are in this probably will require a level of tweaking.

Once this is done you need ensure that the events are being generated on the SIEM by the logs, if all is OK then you should see a stream of filterable events on your SIEM solution. This doesn’t necessary mean that any of the events are going to match your use cases.
The next thing you need to do is create rules for each of the uses cases; for example you may want a rule to fire every time a normal user uses SUDO.

The next stage is testing. Testing can be tricky, because you need to be able to do something that is going to trigger the rule and in most production servers that will either involve a lot of paperwork or it will not be possible at all. This means you will need to use either a test system or replay file that will flood your system with events, you can configure either to purposely carry out activity to that will trigger a rule and an action. This action could be anything from correlation with other events, sending alerts or key to this question feed directly into a report or query for auditing.

Additionally you can write scripts that will attempt to carry out the use cases and generate log entries, this will test the entire process from the raw logs through to the SIEM rules. (Good luck getting scripts like this onto a production server though)

Once you have thoroughly tested that each of the use cases are triggering the rules/actions you require, you can start tuning out any events that are not a security issue, for example some normal users may have legitimate access to the SUDO command and you do not need the rule to fire every time  they use SUDO.

One of the good things about SIEM is that in general they are very easy to audit as reporting is built in. You can configure a series of reports for each of your use cases. These can count how many times a rule fired, what times they fired, what actions were taken etc. You can dig down deeper and audit all events regardless if they fired a rule or not. Really you are only limited by your imagination or computing resources, although you should only really use the SIEM to report on security events.

These reports can be configured to provide detailed statistical analysis or general aggregated data. Once again you need to decide what you want to see, for example do you need to prove you are compliant with certain regulations? If yes; Break the regulation down into discreet provable objectives and then generate a report based on each of them, this process will be different for each environment and each regulation you need to be compliant with.

The SIEM will take time to mature, it is just the nature of the beast and things should improve over time, with continued tweaking, testing and reporting.

One thing to be very careful of though is not to out scope yourself, you may create a set of rules so tight that you end up with blind spots and miss malicious and/or anomalous activity in the environment, this is something that reporting will not help you with.

TL:DR

Ensure your data source is configured correctly, i.e. the correct logs
are being forwarded to the correct place.
Ensure the SIEM is seeing the data correctly.
Test and tune all your rules.
Configure reporting within the SIEM based on your unique auditing
needs, i.e each set of regulations/audit demands/environment/SIEM
will require bespoke configuration for the reporting and auditing
phase.
In addition to this, time will be required for the baselines of the
expected events and maturity of this SIEM to be established.

Finding information sources on the detail of how to do this can be tricky. Most enterprise class SIEM solutions are propriety products and the literature is quite heavily protected, if you are a customer go to your vendor directly and ask for support. There are a few resources dotted about online, but in general I find the information to be of low quality and in many cases out of date.

SANS have a paper called Successful SIEM and Log Management Strategies for
Audit and Compliance that you can get in PDF format here.


How easy/difficult is it to spoof DNS? Are some scenarios safer/more risky than others? Practically speaking, how easy difficult is it to spoof DNS?

What scenarios are more risky than others? For example:

A phishing email or twitter link that attracts users to click a hyperlink
A link on an internal sharepoint site on a different subnet
Where a malicious user may be on the same subnet.
other scenarios... (please add your own)

If the victim is using an open wireless network, spoofing DNS is easy.  It is easy for the attacker to mount a man-in-the-middle attack and send forged DNS responses.  Therefore, if you are using an open wireless network, you should not trust DNS at all: it is trivial to spoof.

Similarly, if the attacker is on the same subnet as you, spoofing DNS is easy: in this case, it is trivial for the attacker to eavesdrop on your DNS requests and then spoof responses and play man-in-the-middle games.

If the victim is using some other network, spoofing DNS is not easy but potentially feasible.  If the victim is connected to the network via a wired network, in most cases the attacker can't easily arrange to eavesdrop on your network communication.  In this case, the easy man-in-the-middle attack no longer applies, and the attacker has to work harder.  There are still some other possible attacks, but they are not nearly as easy to mount:

Kaminsky attack. If you have an older DNS client (one that doesn't use source port randomization), the only protection against spoofing is a 16-bit ID field.  16 bits is not enough to defend against random guessing, and Dan Kaminsky showed how to spoof DNS under these conditions.  Therefore, if you have an old DNS client that doesn't use source port randomization, you should assume it is easy to spoof DNS.

Fortunately, after Kaminsky discovered his attack, there was a concerted effort to add defenses against his attack (e.g., by randomizing source port IDs), and most modern clients do use source port randomization.  Therefore, for modern DNS clients, while Kaminsky's attack is still possible in principle, it would require an awful lot of traffic, so it'd be possible but non-trivial to mount such an attack; unless you are a high-value target, you're probably pretty safe if your DNS client uses source-port randomization.  However, there are still some systems that have not deployed protection against the Kaminsky attack, either because they are very old, or because they are embedded systems that haven't been updated, or because they are behind a NAT that destroys the source port randomization -- and those systems remain highly vulnerable.
DNS cache poisoning.  In the past, many DNS caches were vulnerable to cache poisoning attacks, where an attacker could fool them into accepting a malicious reply to a DNS query and then cache that malicious reply.  Then all subsequent clients who use that DNS cache who query that name would get the incorrect and malicious answer.

These days, modern DNS software has been updated to defend against all known cache poisoning attacks, so cache poisoning attacks should be difficult to mount today.  It's possible there might still be a few DNS caches out there running very old software, but I'd expect them to be pretty rare.
Client-side malware.  One thing that some client-side malware does is modify your system's configuration so that all DNS queries go to the attacker's DNS servers.  Thus, if your machine has been infected with this malware, the attacker gets to spoof DNS easily.
Drive-by pharming.  If you connect to the Internet via a consumer/SOHO-grade cable modem, DSL modem, personal wireless access point, or similar device, you may be vulnerable to a nasty attack known as drive-by pharming.  In a drive-by pharming attack, the attacker reconfigures your router to change its DNS settings, so that all DNS queries go to the attacker's DNS servers.  If the attacker can do this, it thereafter becomes easy for him to spoof DNS.

How can this happen?  One way: If you run an open wireless network, an attacker who is physically nearby may be able to hop on your network, connect to your router at a standard address (e.g., http://192.168.0.1), and if you haven't set a strong password on it, guess your password and change its configuration.  A little more subtly, even if you have chosen a strong password, if you are logged in, the attacker might still be able to change the configuration, by exploiting the fact that many routers' local web configuration interface does not defend against CSRF attacks.

Worse, in some cases these attacks can be mounted remotely, by an attacker who is on the other side of the world.  If you are using a vulnerable router, and if you are currently logged into your browser or if you haven't set a strong password on your router, if you visit a malicious web site, the malicious web site may be able to use Javascript and Java to connect to your router (from the inside interface), guess your password or exploit a CSRF attack, and change its DNS configuration -- invisibly, in a way that you have no idea happened.

Unfortunately, many deployed routers are vulnerable to these attacks, and because there is no good channel for deploying security updates, this fact is not likely to change any time soon.  I would rate this attack as medium difficulty; it's probably not too hard to find some users who you can attack in this way, but might be difficult to attack a targeted user (unless you are physically nearby).
Server-side hacking.  If the attacker can hack a DNS server that is responsible for example.com, then the attacker can control the responses that are sent when clients ask for the IP address of example.com.  This attack is probably relatively difficult for most sites, but the difficulty will vary depending upon the target.  One study found that 17% of DNS servers have known vulnerabilities.

This attack is worse than it might first seem, because there is a great deal of transitive trust in the DNS.  For instance, the Government of Ukraine's web site depends indirectly upon Dreamhost's DNS servers (kmu.gov.ua's DNS is served by servers at adament.net; adament.net's DNS is served by dreamhost.com), upon Norway's and Sweden's DNS servers (ua's DNS trusts sunet.se, which relies upon nordu.net, which relies upon no), and upon a number of other DNS servers.  Therefore, if you can hack any of those DNS servers, you may be able to spoof DNS for the Government of Ukraine's web site.  The amount of such trust varies significantly from site to site.  One study found that 45% of DNS names are susceptible to hacking, due to indirect dependencies of this sort upon vulnerable DNS servers.

Bottom line. Overall, I'd say that if if you are using an open network where the attacker can eavesdrop on you, then spoofing DNS is trivial -- whereas if you are using some other network where the attacker can't eavesdrop upon you, then spoofing DNS is pretty hard but far from impossible.

Therefore, I think there are good reasons to use solutions like DNSSEC and SSL/TLS.


Tracing origin of malicious PHP script I'm looking at a Linux server running Apache + mod_php. A malicious PHP script was uploaded during the night. It's owned by the Apache user and I would think it almost certain that the script was generated by an exploit in some of our existing PHP code.

I looked in the Apache log for hits on the script, and from that got the attacker's IP. I then searched back for other activity by this IP ... nothing. I also searched back for hits from the same User Agent (in case the attacker was connecting through proxies). Nothing.

So I then grepped the log for POST requested issues in the few minutes before the first hit on the malicious script, in the hope of finding which legitimate script the attakcer had exploited. A few hits, but nothing that stood out. For each of these scripts I've appended some code at the top to dump POST data to a log file.

I then searched the Apache log for strings like 'lynx', 'wget', 'tmp' in case the attack had been via GET. Nothing.

So I'm a bit stuck now. I wonder if anyone can think of any clever ways to determine how this malicious script was uploaded, or any additional logging I could put in place? (mod_dumpio is an option)

Let me answer with a few observations, and comments. I will begin with the "whodunit" approach of aiding in determining who, what, when, where, and how.

What - a file you found on your system
When - what date was it found
How - how was it uploaded
Who - who uploaded it

You already know the file because you found it. Let's call this file: malicious.php. What you mention doing is determining "who" accessed this file, but you need to figure out how it was uploaded. Looking at the who accessed this file is the wrong approach. This is because attackers usually use multiple attack points. E.g., one system may scan you, another may compromise you, and yet another may access the system one compromised. So let's figure out the who first using deductive methods:

$ ls -ltha malicious.php
-rw-r--r-- 1 www-data www-data 0 Mar 27 10:59 malicious.php

In this instance, we see the file belongs to user www-data in group www-data. This does not mean an attacker uploaded it via http using post or get. There is nothing to stop someone from exploiting say telnet, uploading a file and performing a chown on the file.

ls -ltha --time=atime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 10:09 malicious.php
ls -ltha --time=ctime malicious.php
-rw-r--r-- 1 www-data www-data 0 Apr 27 11:00 malicious.php

We can see the differences in timestamps here. If someone used say timestomp (Metasploit) MAC times can be changed. So we can deduce on the data above, that we are more or less within the 50 minute realm. Let's ensure that this user has never logged in, for that we can check wtmp, auth, ftp logs, etc. If this user has never logged in, we can then infer that this was not uploaded in any other fashion outside of via HTTP.

When - we reduced the timeframe to a degree to a 51 minute period. The logs I would look at would be error logs FIRST followed by access log. The reason for this is simple, at no point in time would an attacker know exactly how to get a file on your system. This means, there was a trial and error recon. This will be in your error logs appearing as a 404 or 403. I would search those first. Now let's further reduce the searching. A log analysis of visits will show what is normal versus what may be an anomaly. For example, if the base of traffic goes to say index.html remove all those instances, and look at the anomalies. One you determine this, you have then determined the How. This is completely separate from figuring out how they compomised your your code which would be a completely different question.


Unusual Get/Connect requests to Apache Not sure if that has been asked before but over the last week I am getting hundreds of CONNECT and GET requests to my Apache web server for domains that are not on my server. Some are for well known sites like instagram.com. Here is a few that happened this morning:

120.78.240.35 - - [15/May/2019:09:15:10 +0200] "CONNECT book.spicejet.com:443 HTTP/1.1" 405 519 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_111)"
120.78.240.35 - - [15/May/2019:09:15:09 +0200] "CONNECT book.spicejet.com:443 HTTP/1.1" 405 519 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_111)"
120.78.240.35 - - [15/May/2019:09:15:09 +0200] "CONNECT book.spicejet.com:443 HTTP/1.1" 405 519 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_111)"
120.78.240.35 - - [15/May/2019:09:15:09 +0200] "CONNECT book.spicejet.com:443 HTTP/1.1" 405 519 "-" "Apache-HttpClient/4.5.3 (Java/1.8.0_111)"
51.75.12.139 - - [15/May/2019:09:15:07 +0200] "CONNECT api.goldenfrog.com:443 HTTP/1.1" 400 0 "-" "-"
120.76.246.242 - - [15/May/2019:09:15:05 +0200] "CONNECT api.nokair.com:443 HTTP/1.1" 405 516 "-" "-"
54.37.76.200 - - [15/May/2019:09:15:03 +0200] "CONNECT hq.uis.kaspersky.com:443 HTTP/1.1" 400 0 "-" "-"
72.130.166.116 - - [15/May/2019:09:15:03 +0200] "CONNECT stockx.com:443 HTTP/1.1" 400 0 "-" "-"
51.77.245.206 - - [15/May/2019:09:15:00 +0200] "CONNECT 160.153.202.75:443 HTTP/1.0" 405 535 "-" "-"

Any idea what could be causing those requests to be redirected to my server? Initially I thought that it might be a scan to see if the server could be used as a proxy but this has been going on for the better part of a week now.

Likely a bot looking for open proxies. The url in the log is the page it's trying to load via any open proxy it can find.


gpg is trying to sign with an old signing sub-key I no longer have I got a new smartcard (yubikey neo) and generated a new signing key on it. so now my public key mentions both the old one and the new one:

pub   rsa3072/B50A93EA 2015-08-13 [expires: 2018-08-12]
uid         [ unknown] Arthur Ulfeldt <arthur@ulfeldt.com>
sub   rsa2048/6EE4E07A 2015-08-13 [expires: 2018-08-12]
sub   rsa2048/BC4C4B6C 2015-08-13 [expires: 2018-08-12] # <-- new key
sub   rsa2048/67E40B89 2015-08-13 [expires: 2018-08-12]
sub   rsa2048/91FF2F99 2015-08-16 [expires: 2018-08-15] # <-- old key
sub   rsa2048/3157DA5D 2015-08-16 [expires: 2018-08-15]

and gpg -K shows which ones I have the private keys for:

sec#  rsa3072/B50A93EA 2015-08-13 [expires: 2018-08-12]
uid         [ unknown] Arthur Ulfeldt <arthur@ulfeldt.com>
ssb>  rsa2048/6EE4E07A 2015-08-13 [expires: 2018-08-12]
ssb>  rsa2048/BC4C4B6C 2015-08-13 [expires: 2018-08-12]  # <-- new key
ssb>  rsa2048/67E40B89 2015-08-13 [expires: 2018-08-12]
ssb#  rsa2048/91FF2F99 2015-08-16 [expires: 2018-08-15]  # <-- old key
ssb#  rsa2048/3157DA5D 2015-08-16 [expires: 2018-08-15]

running gpg  --clearsign -u B50A93EA --status-fd 1 --debug-all prints this:

....
gpg: DBG: chan_5 -> KEYINFO F5B5D673F6FFFA999162D7F2F4F91750FF756F2F
gpg: DBG: chan_5 <- ERR 67108891 Not found <GPG Agent>
gpg: DBG: md debug: can't open dbgmd-00001.clearsign
...
gpg: DBG: chan_5 -> SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Arthur+Ulfeldt+<arthur@ulfeldt.com>%22%0A2048-bit+RSA+key,+ID+91FF2F99,%0Acreated+2015-08-16+(main+key+ID+B50A93EA).%0A
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> SETHASH 8 5B6489E68D...A9780A91BB6526C
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> PKSIGN
gpg: DBG: chan_5 <- ERR 67108881 No secret key <GPG Agent>
gpg: signing failed: No secret key

which looks like it is using subkey 91FF2F99 to try and sign with.

gpg --card-info shows the correct keys on the card.

How can I verify that it is indeed trying to sign with the old key?

is there a way to cause it to use whatever key is actualy avalable on the smartcard that's plugged in at the moment?

PS: I'm using gpg (GnuPG) 2.1.7

I had similar issues, only specific to Enigmail after upgrading to GnuPG2.1 on Debian via dist-upgrade (Sid user).

I could not send emails that I intended to sign. Enigmail reported:

  Error - encryption command failed `

Debugging GnuPG resulted in several errors:

ERR 67109139 Unknown IPC command <GPG Agent>
ERR 67108949 No pinentry <GPG Agent>
command 'PKSIGN' failed: No secret key

After a bit of reading (answer from Jens Erat as well), turns out indeed that enigmail/gpg-agent were selecting the signing subkey with the newest creation date.

To clarify, I originally created GnuPG keys following a Debian guide for developers, which recommended creating sub-keys for each different machine. However I did away with that practice almost immediately for various reasons, and deleted the signing subkey in question.

Both subkeys; the older that I kept, and the newer I thought I had deleted, were displaying when I'd run gpg --list-keys xxxxx in terminal.

Another hint for me was the 'No secret key bit', indeed there was no matching secret subkey for the public signing subkey that was being selected, perhaps I only deleted that one -- not sure.

So I deleted the public signing subkey that Enigmail kept trying to use:

gpg --edit-key xxxxx
$ key 2
$ delkey

Magically I could send signed emails again.

Not sure if the GnuPG upgrade reloaded the old key keys, if I somehow didn't delete the key right previously or had somehow restored it, or if Enigmail is simply working differently with GnuPG 2.1 (or even just differently in latest Enigmail update for Icedove).


How does SAML signature exchange work between IDP and SP? I'm trying to understand the SAML protocol 2.0 (signed) exchange.

Here is what I understood so far:

IDP has its own public (PB1) and private (PV1) pair
SP has its own public (PB2) and private (PV2) pair

Now when an IDP has to sign a data, it does so by using it Private key PV1.
Then SP can verify it using the public key PB1 accessible to SP via metadata of IDP / KeyInfo.

Likewise, if SP has to sign data, it does so using its own private key PV2
then IDP can verify the sign data using public key PB2 accessible to IDP via metadata of SP/ KeyInfo.

Is my understanding correct?

This is correct. That is one way that signature varification can be made and it is as far as I know the most common one.

It is also possible to for the entity signing to attach the public certificate to be used for verification, in the signed XML. This then assumes that the certificate is validated by som other mean like verifying that it is signed by a trusted CA.


Information Security and Financial Risks Recently, we've been asked by Audit Dpt. to have financial risks controls in our ERP (fraud-like incidents).
Our question is if this request is covered by the scope of Information Security Dept?
If so, I think a set of tests should be developed with IT and Finance Dpt.

So, What are the competencies of a Information Security Office related to financial risks?
Is there any certification or academic path Information Security professional should follow in order to develop skills to respond to financial risks (like fraud)? Does CRISC cover this type of risks for instance?

This is certainly security related and if the transactions involved are done by electronic means, then it is certainly part of estimating risk and determining appropriate security measures that should be taken.  Information Security doesn't exist in a vacuum.  It is dependent on all the surrounding factors, all the way down to physical security of the building that the computers are located in.

Fraud is a type of security incident from misuse of your system, having systems to limit the risk of such incidents is well within the bounds of Information Security documentation, though the exact acceptable level of risk likely needs to come from finance or management.

Many technical measures (such as identity and/or credit checks) may also come in to place to prevent fraudulent activity as well, so Information Security needs to be specifically involved in the process rather than being brought in at the last minute.

I don't think that it is necessary to expect an Information Security person to have in-depth knowledge of particular financial fraud risks (that is why there is a finance department) but it is important to get how systems and policies should respond to those threat documented in a consistent response plan for the entire organization.


Malware: Is there a difference between automounting vs manually mounting? This is specifically for Ubuntu, but if you'd like to include a reply that'd help Windows users, please do.

Background:
I'm working on the suspicion that there's malware on my neighbour's laptop, desktop PC and a external HDD. I've scanned them with ClamAV and found nothing. It's suspected to be a Windows virus/worm or a boot sector virus, and the source of infection is another Desktop PC which I've scanned with ClamAV (from live Ubuntu) and found more than one virus and three worms. That PC had only Windows installed, so I suspect that all the malware was for Windows only (symptoms of infection was that the system would sometimes restart randomly or when booting or when reaching the Windows login screen). I used my pen drive on that system (before knowing it was infected, and used the pen drive on my neighbour's computers only in Ubuntu) and also used another friend's pen drive which when I tried opening with GParted on my neighbour's laptop, GParted just crashed, and in one instance ended up corrupting my neighbour's EFI partition. Just by opening the pen drive with GParted.
When my neighbour's desktop PC restarted on boot twice simultaneously and his laptop restarted on boot once, I suspected his computers were infected.

What was done:
Wiped entire HDD of PC with DBAN and reinstalled Ubuntu from a DVD.

TL; DR
Now I need to backup some large files from the Ubuntu laptop (which I suspect is infected, although ClamAV found nothing), onto a pen drive so that I can transfer it to the Ubuntu desktop PC.
Am working with the paranoid assumption that if there's a Linux worm in the laptop which antiviruses can't yet detect, then it'd copy itself into a new pen drive automatically if automount is enabled.
So the question is: Will it help to disable automount and manually mount the pen drive? Is there any chance there's a lesser chance that a worm could infect a pen drive if mounting is done manually? If no, then how can I safely transfer those 7GB+ files to the desktop PC from the laptop?

A mount is a mount, and from the perspective of software (malicious or otherwise), it doesn't matter whether or not the mountpoint was created manually or not. If your /media/your-usb-stick directory is writable by a given user, then any program running as that user will be able to save files to it. Automounting does not change that behavior.

Worms work by spreading over the network, using vulnerabilities to infect machines. It must be executed so it can attempt to exploit other computers through the network. Malware that simply exists as a file on an external drive poses no realistic threat.