What exactly does "Nation-State" code look like? Juniper Networks has discovered unauthorized code that appears to be planted by a nation-state attacker in their firewalls.

A similar claim was made about Stuxnet, Duqu, Flame, Gauss, and probably others that these were probably all written by nation-states. Whatever proof that may or may not support the idea now, the media began spreading the idea very early on after their discoveries.

When pieces of malicious code are discovered in the wild without anybody taking credit what indicators point to the malicious code being nation-state and not organized crime or small hacking groups (Anonymous, LOLSEC, other unassociated groups)? Are there code smells that paint a target or is it more the circumstances around what the code impacts and who the intended target was? Or is it just fear mongering?

what indicators point to the malicious code being nation-state and not
  organized crime or small hacking groups (Anonymous, LOLSEC, other
  unassociated groups)?

In this specific case, the people who know the indicators, aren't telling (yet).

There are a number of indicators that may come into play, such as:

Provenance, or, where stuff comes from -

There has been significant work done to tie together actors and campaigns by analyzing the use of unreleased code.  For example:

  In 2015 Kaspersky's research findings on the Equation Group noted that
  its loader, "Grayfish", had similarities to a previously discovered
  loader "Gauss" from another attack series, and separately noted that
  the Equation Group used two zero-day attacks later used in Stuxnet;
  the researchers concluded that "the similar type of usage of both
  exploits together in different computer worms, at around the same
  time, indicates that the EQUATION group and the Stuxnet developers are
  either the same or working closely together". (Wikipedia)

If the Juniper attack shares certain characteristics with other known APT attacks, then it's likely to be an APT attack.  Unfortunately - again - the only people who'd actually know what those characteristics are, at this point, are the incident responders, and they're not talking.

Purpose, or, what can be done with the stuff -

A backdoor on a firewall is brilliant and useful for any attacker.  Weakening encryption in a way that can benefit eavesdroppers without requiring endpoint access more strongly benefits APT groups, because they are more likely to have access to ISP-level network captures than, say, Anonymous.

In your comment above you call that "subjective and circumstantial", but it's really not.  The described vulnerability has the advantage of being largely undetectable (compared to endpoint compromise, and assuming Detachment 2702 is working properly) and the disadvantage of requiring advantageous network access (which nation-states have been working at since long before there were computers).

Patterns, or, crumbs that don't get cleaned up -

There have been various APT groups whose work was attributed based on strings or commonalities - an email address, a command and control server IP, a source code path name that didn't get stripped from compiled objects.  You can bet that whatever got left at Juniper is being gone over with a fine toothed comb, by people who have done the same at dozens or hundreds of other victims.  If there are crumbs to be found, they will be found.

It could be any of these, or all, or none.  No way to tell until someone writes a paper or releases details which allow us to pin it down.

Update 20151228 - You may want to read "APT28 Under the Scope", which aims to describe a particular APT actor.  Notice some of the Patterns they used - they mapped the compile time of the attack tools, to determine which timezone the actors came from.  They also found a hardcoded path to a debug file where one of the directories in the path was the Russian word for 'Users'.  I'm not suggesting APT28 is the crowd who hit Juniper, it's just interesting to see the analysis process and the level of minutia that can be used to try and attribute responsibility for an attack.


"Out of the box" database security When you install a RDBMS (say, PostgreSQL) and create a database, without taking any additional steps, what can you assume about the security/confidentiality of the data? I mean, is it encrypted by default, so even a person with physical access to the machine (or root password to the OS) would have trouble accessing it without the superuser credentials? Are the credentials (or some easily crackable equivalent) stored somewhere, like in a file?

Sorry if that sounds obvious, but for me it's not. Searching for "database encryption" yields many results about how to encrypt a database, what use cases it's good for, etc, but doesn't answer my basic question. For an ordinary, no special needs scenario (who has the password accesses the data, who hasn't doesn't), do I have to take additional steps for securing my data?

Contrast that question to OS filesystems and Truecrypt: for the former, it's obvious that nothing is confidential at all, you must use full-disk encryption to protect your data; for the latter, it's easy to see the credentials are not stored anywhere, if you don't have the password/keyfile the data in front of you is useless. What assumptions can I make about RDBMS (at least the most common, production-oriented ones)?

The data is not out of the box encrypted.  Files are stored within a subdirectory /var/lib/postgresql/.  See: http://www.postgresql.org/docs/8.4/static/storage-file-layout.html

While the OS is running its limited to being read by root/postgres user.  Remember, if a user has permission to reboot from a live cd or into single user mode or take out the hard drive and there's no full disk encryption, they can read the files.  Granted the files aren't easy to navigate through -- they are stored in a binary format, but you can often pick out ASCII strings from the files (and a dedicated attacker could get at the full underlying data).


Is it dangerous to program a user-called deamon that sends passwords via https? I have this problem:

My console app needs to connect to a server. However, the server requires passwords in plain text per HTTP POST for login. The connection is HTTPS.
The app is only called now and then, but does not run permanently.

Now, I don't want the user to enter his or her password for every run of the app. My idea was:

When the user starts the app for the first time, the user is being asked for a password. A new deamon is being started (i.e. a program executed by the user, which can run for mulitple weeks), and the entered password is passed directly to the deamon.
To login to the homepage, the app only tells the demon "login". The demon, which has the password in RAM, calls wget to login to the website [1].

My main worry is that the deamon has the password in RAM. What dangers could arrise from this?

I see three risks:

Someone could access the RAM. Probably by forcing your computer to swap it out, then pressing the power button, and then investigating you hard disk. It's possible, but probably not effective.
The deamon could use temporary files to store it's memory. Probably true for bash? However, if I'll write a C program, this should not be possible?
Someone could use a script which says "Hi deamon, I'm wget/the internet, give me the password". As long as I'll call "/usr/bin/wget", and as long as the user isn't root, I think that won't be possible?

Any other issues?

Notes:
[1] wget gets the password via a file, so the password is not in the ps-table. The file would be constructed by the demon with read-rights only for the user, and would be deleted after the login.

Any other issues?

Yes, you are overcomplicating it.

I'd suggest you should just setup a ramfs or a LUKS mount and set permission so that only your application have read access to that directory. The application should be setuid to the special user, or you should have a sudoers rule that allows running sudo -u specialuser secureapp.

Security is the same or better than what you're proposing, and it would be much simpler to implement.

As to your concern that someone can dump the RAM, if your attacker have the privilege to dump RAM, you're already screwed. Leaking the password is the least of your worries.

If you can't leak the password anyway even if the attacker can dump RAM, then you should not be using passwords for login. Instead, I'd suggest alternative form of authentication like access token, or PKI with client certificate, possibly in a hardware security module (e.g. x.509 or OpenPGP smartcard).

If you want to write a daemon anyway, and you have an area in the RAM that contains sensitive data, you should use the mmap(MAP_LOCKED)/mlock() to allocate unpageable memory or to prevent a part of the memory from being paged out.

To your third concern, rather than the daemon listening on HTTP via TCP (AF_INET), I'd suggest the daemon should listen on Unix domain socket (AF_LOCAL). With Unix socket, you can apply file permission to restrict who can communicate with the socket, this gives you much finer access control than TCP. Examples: ssh-agent and gpg-agent are implemented using Unix sockets.


using NoScript - what approach to use with randomnly named CDN scripts? I ran across this on namecheap.com.  This question isn't about namecheap.com itself, which I have no problem trusting.  Rather, what approach do you recommend in dealing with CDN scripts that have very long random names?  Now, I know they're most likely just how the main site decided to refer to external utility scripts they've put on a CDN.

But, if the main site had been hacked, the attackers could also inject a script to fire and use a long random name that looks innocuous by looking a like a utility script.

Is there any particular reason to be more cautious about these long random named scripts than for the more recognizably-named ones?  I suppose not, but they do make me a bit queasy on NoScript.  Especially on sites that I will enter credit cards into.

The Cloudfront URL is a unique identifier for namecheap' CDN.

There is nothing to worry about these urls.
Regarding your question why to use such URL: my guess is that they don't use Cloudfront for their entire website (maybe not AWS at all). So they only use Cloudfront for their assets.

Although I don't see it your screenshot if the Cloudfront URL is used by the website  itself or by a third party library.


How to check if an image file is clean? I want to find out if it's possible to check if an image file like JPEG, PNG, GIF or BMP is safe and don't have a virus in it.

I want to filter an image file before I send them to sandbox to check if it's not suspicious and I know its safe file.
The response from the sandbox takes 2-3 minutes and I want to reduce the time if I can filter some files that definitely clean.

Is there a method to find out if an image file is definitely safe?

It is not possible to verify with certainty that an image is clean, short of manually analyzing it to see if it conforms perfectly to the standards, and that your image viewer likewise conforms to the standards. Instead, you can encode the image between a simple format. Converting an image to a trivial format carries with it the risk of exploitation, but converting from a trivial format to a more complex format does not. You can exploit this reduced attack surface area, for example:

Load the suspect image into a sandboxed image converter. The image converter must not have any filesystem access, X11 access, or access to unnecessary syscalls. The sandboxed image converter must be untrusted as it will be using potentially vulnerable libraries.
Have the sandboxed image converter re-encode the image into a trivial pixelmap format, such as PPM. The format must be simple enough that it would be infeasible to exploit. The assumption is that this conversion process may compromise the converter, so all subsequent steps must not need to trust this stage. A pixmap is trivial enough for these purposes.
A second, unsandboxed image converter then takes hold of the pixmap, e.g. through shared memory. This image converter is trusted, as its only input will be a format so trivial that exploitation is infeasible. The pixmap can then be converted into a more proper image format, assuming of course you do not want the output to be a large, uncompressed, raw image.

So why not just have a single sandboxed process convert the image? If you assume that the image parsing library for the input is vulnerable, then even a sandboxed process can no longer be trusted. If you ask it to convert a JPEG to a PNG and the JPEG is malicious, it could embed a different exploit into the PNG output. This is not going to be likely, but it is possible, making this a no-go.

If this is overkill, then there are still some other, simpler ways to decrease the likelihood of falling victim to an image parsing exploit. A non-exhaustive list of recommendations is:

Keep all your software up to date, especially image libraries.
Verify that the image format matches the extension, e.g. by checking the MIME type.
Do not accept images from untrusted sources if possible.
Use only common image formats such as JPEG, PNG, and GIF.


Cleaning metadata of documents For an organization working mainly with xls, pdf and doc files (but also other MS Office tools), how should it deal with metadata? How can we scan all documents and strip the metadata from them?

Metadata can potentially provide information that an attacker would find valuable. For example, the author value can reveal the organization's username convention, which could be later used in conjunction with password guessing or social engineering. The software used to create the file can also be potentially usable for an attacker if the target is using out of date software with known vulnerabilities. The best practice would be to scrub metadata, but it comes down to a business management decision of whether the risk is significant enough to spend time removing the data. There are several easily available tools for metadata inspection and removal.


Exposing a version number through the assets urls I just received a blackbox pentesting report where the security company recommended to hide the version number from the page (be it returned to the user as a text or used as a cache-buster in the css/js/img urls, like /path/to/file.css?v1.2.3.

I gave it some thought and could not think of a good solution that would comply with their recommendation and keep those resources fresh and cached on the client's devices.

These days browsers and proxies do crazy things about caching resources (sometimes when they even should not have). So urls must be unique between releases.

But if they are - then really does not matter whether it's a version number in the url, or a file contents hash, or a random value. If it's stable it still allows to uniquely identify a version.

I can invent some dirty way (which I'm not sharing at the moment, but later when I see any feedbacks), but what industry is doing these days to comply with the similar recommendations?

UPD: as promised, here is a workaround that would "keep" caching and hide the version number:

instead of version component in the url use the hash derived as: hash(version_str + year_str + week_number_str + secret_str). That way the value would naturally change every week and leak nothing.

While exposing specific version numbers is considered a bad practice and is not recommended, in this case I do not really see an issue.

It is likely that the version is also displayed as a comment in the CSS file (and often also in JS files). It's quite easy to identify the version for such files (not 100% reliable but 99 out of a 100 times it will work)

As a security consultant, I would be more interested in your update policy:

How often do you check for updates on externally[1] used dependencies (CSS / JS)
How often do you apply these updates?
What's the process you execute before using these updates in production systems.

[1] I am not stating that you load these resources externally, just stating that it's a CSS file that is not created by you or your company.

As a side note: If this is considered the worst problem you have with your application, you've done quite well.


Redacting URLs as an email-phishing preventative? In a large organization (e.g., a city staff), relying on human behavior to prevent phishing attacks isn't nearly effective enough. While it would be somewhat inconvenient (security usually is), I'm thinking of an approach whereby the email client would redact all URLs in a message. Not only make the URLs inactive, but eliminating them entirely. For example, something like this:

  Click here to see our new report on property taxes:

  [URL removed]

If there really is a new report, and if the city staffer really wants to see it, he or she can go to the website and track down the report. If the user goes to the website through a password manager or a bookmark, there's no way the bogus site will be reached instead of the real site. (A phishing attack involving a site that the user is unfamiliar with, and therefore has no login for, wouldn't be a phishing attack.)

While not all phishing attacks involve URLs in emails, my guess is that 99% of them probably do.

I'd appreciate some comments on whether you think this would be effective in reducing phishing attacks. I'm less interested in whether the absence of URLs presents an inconvenience, as I know it does.

(Forcing the email client to operate in text mode only removes the linkage; the URL is still there.)

First of all, it would be a usability nightmare.

Second, it wouldn't even fix the problem it purports to. While it could be effective to phishing mails designed for 'normal' clients, attacks designed to suir such systems would probably be even more effective.

The users of such networks would be used to using all kind of alternative ways to refer to urls. Suppose I wanted to link to this question and ask you to upvote my answer, as you don't allow me to write  https://security.stackexchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative I could say:

security.stackexchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
https:/ /security.stack exchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
Go to security SE question 215871
bitly 2ZoZiTS
Link sent to your personal mail
Please call to 555-0123 so I can give you the actual url
Search "Redacting URLs as an email-phishing preventative?" in Google
See last active question
hotel  tango tango  papa  sierra colon double slash sierra  echo  charlie  uniform  romeo  india  tango  yankee dot sierra  tango  alpha  charlie  kilo  echo  xray  charlie  hotel  alpha  november  golf  echo dot charlie  oscar  mike slash quebec  uniform  echo  sierra  tango  india  oscar  november  sierra slash two  one  five  eight  seven  one slash romeo  echo  delta  alpha  charlie  tango  india  november  golf  dash  uniform  romeo  lima  sierra  dash  alpha  sierra  dash  alpha  november  dash  echo  mike  alpha  india  lima  dash  papa  hotel  india  sierra  hotel  india  november  golf  dash  papa  romeo  echo  victor  echo  november  tango  alpha  tango  india  victor  echo
Url sent in an attachment

Note that some malicious mails already use urls in attachments as a way to [attempt to] bypass email filters. You might think "I will just strip urls from attachments, too", but that will cause havoc when the documents your users are redacted get silently corrupted by the email system. The formatting may possibly break everywhere, too. Not to mention that such endeavor might require you to be able to (properly) recognize and edit almost every existing file format.

Additionally, your legal department will probably bar you completely from modifying the invoices (received as email attachments), no matter how innocuous the edit.

Also things like recovery links for forgotten passwords would not work at all for your users, either.

But IMHO the main problem would be that the users would be "trained" to do all kind of weird workarounds, a "hidden url" that made them go through such hoops would not raise any suspicion at all.

(And as noted by Joseph Sible, your antispam filter would not be able to examine the obfuscated urls)

Some examples:

Make the user to search "StackExchangeBank blocked credit card" on Google. Then make a phishing page for the StackExchangeBank appear top by using uncommon words, or even buying ads.
If you call me so I give you the url that would be otherwise filtered, I can send you to a phishing page, adding some live social engineering to make you it more credible than just a plain email.
Send them through a url shortener. The user will have no idea where it is getting sent
The n-th question on the list would obviously change, so it would not guarantee the user to arrive to the "legitimate" question you asked, instead voting on a different question "impersonating" the one he was expected to reach.

A much saner approach would be that you changed the urls to go through a redirecting service of yours. Some email security filters already do that. This way they can check, when the user clicks the link if it is listed on a blacklist (where it might not have been when the email was received), and thus block the access. You might also have it show a Big Scary Warning that they are Not going to a safe website, the moment they try to reach a not-whitelisted site (only those they have credentials to, supposedly). And still, such approach would be somewhat flawed since the users will actually have credentials to more sites than those whitelisted at the proxy to not show the warning, and legitimate sites often decide to put out content of theirs on a new domain (which wouldn't appear on the whitelist, obviously). If there are too many false positives, users will end up paying little attention to them, as it would be 'normal' to receive them.


Protecting wireless network My wireless network protected under WPA-PSK/WPA2-PSK protocol.
Is there a good reason to change the default user/password for the router management interface?

What would it take for an hacker to get into my network?
Does the fact that I use default user/password would make it easier to hack?

Short answer: Yes, change it.

As long as you can ensure that the attacker is not able to break into your WiFi (using WPA2 is good beginning) and is also not able to get access by other ways (e.g. over VPN, weak WPA2 password, plugging a cable into your switch, malware on your devices, ...), theoretically there is no need to change the password.

However, since you probably can not ensure these requirements, you certainly should change the password. So that in the case the attacker is able to break into your network, he can not damage that much.


Logjam definition question As I understand it, the Logjam TLS attack is an attack that downgrades the DHE cipher suite used by the server to DHE_EXPORT. Where the client thinks it is talking DHE 512 and the server things it's talking DHE_EXPORT (which is 512 but with a different name?).

It is not possible to downgrade to a lower (weaker) bit DHE ciphers: it is just a cipher downgrade.

In Logjam attack, the client presents a list of cipher suites (includes some strong cipher and EXPORT cipher as well). A Man-in-the-Middle attack will change this request such that highest grade cipher in the request becomes the EXPORT grade cipher.

The server doesn't want to reject this request (it could be an eCommerce website and server don't want to lose business), so the shared secret is derived using export grade cipher suite which can be broken if that prime group is sieved using GNFS.

Check out this video, it's a long one but from the authors of Logjam
https://www.youtube.com/watch?v=mS8gm-_rJgM


LUKs Header Backup Security It seems that one of the weak points in LUKs encryption is that the LUKs header can be a single point of failure if you do not create a backup header for it.

My question is: What methods of securing your backup LUKs header do you take to ensure it is not recovered by someone else?

Possible options that come to mind for me:

Hiding them in a safe location or leaving it with a trusted third party
Encrypting them
Using stenography to hide them

A combination of all three?

The threat from a backup LUKS header is that an attacker who obtains a copy of it and the password for one of the key slots can access the volume's data even if you subsequently change that password.  However, they can also do this if they gain access to the encrypted volume itself.

Basically, protect the backup header in the same way you would protect the encrypted volume, and don't worry too much.  This isn't a major attack vector.


How to get any information from 1102,1104,1105,1106 ports? I have port output from nmap scan below.

  1102/tcp  open     ssl/adobeserver-1?

  1104/tcp  open     ssl/xrl?

  1105/tcp  open     ssl/ftranhc?

  1106/tcp  open     ssl/isoipsigport-1?

I tried telnet and openssl s_client -host *host* -port *port* and connected to these ports. But I don't get any answer.

How to communicate with them? The don't response at all.

That depends on the service listening to these ports. Often when ports are in sequence, like your output, there is just one process running multiple instances each bound to its own port.

Without any info about the server, it is hard to tell what protocol is used to communicate over these ports. For all we know it's a custom network protocol, allowing only certain types of data or addresses.

You could feed a stream of /dev/urandom endlessly to see if something comes back. I can ensure you, the successrate is low.


Does browsers use one-way or two-way SSL/TLS? Does browsers use one-way or two-way SSL/TLS when I browse to a https address?

Typically you are using one-way SSL/TLS because your browser is checking the certificate of the server but the server is not checking for a client certificate pre-installed in your browser.

When using mutual authentication the browser verifies the server's certificate just like a typical one-way connection but an additional step is involved where the server verifies that the client has a certificate which allows them to access this system. This is not common and requires you to install a client certificate.

The browser can do both easily but if an additional certificate was not installed the authentication is probably only one way (authentication of the server). In both cases, all traffic is encrypted in both directions the one-way or two-way part just refers to the authentication components.


How can Facebook use history data in browser Web is filled up with the recent decision by Facebook to track user browsing history like adage.com andNYTimes.
How can a web application use browsing history which is local to that browser? Is it even possible to get browsing history from modern browsers like FF and Chrome?

Historically, interest-based targeting on the social network hinged on users' own declarations of their likes and interests in their profiles, as well as Facebook pages they had "liked," according to Brian Boland, Facebook's VP-ads product marketing.
Now, Facebook is using the passive data -- where users go on their PCs and phones -- to make its own ads smarter. Advertisers who want to reach Facebook users who are interested in camping, for example, will be able to reach that audience with greater accuracy. "There's just a more robust set of information that informs that you're interested in camping," Mr. Boland said.

Many sites have social buttons. These images are hosted on the social networks servers. When these images are loaded in the browser, the browser will add the  referer header. This allow the owners of the social network to know what sites you have visited.

I believe this explains how facebook is able to track your browsing history.

A web-browser plugin called AdBlock is capable of blocking these social buttons. Here is an explaination of the Social Buttons from their website:

  From: https://adblockplus.org/en/tutorials#disablesocial

  How to disable social media buttons

  Almost every website today contains buttons of social media platforms,
  such as Facebook, Twitter, Google + and others. Even if you never
  click these buttons, your browsing data is still being transferred to
  these platforms in order to create a profile based on your browsing
  habits.

  If you want to browse the web without being observed by the social
  media websites, Adblock Plus offers an easy solution to remove these
  buttons.

Ordinary tracking scripts from advertisements network does more or less the same - but can also be blocked with web-browser extensions.


What certifications do I need to become a Malware Analyst? I've previously posted here on how to get started as a malware analyst, and wanted to say thanks on getting me started.

How much do certifications help me on my resume and which one(s) should I get? Will experience ultimately be better than a cert? And finally, when should I get certified? I'm currently a sophomore studying information assurance, should I wait until I graduate to get certified?

The obvious answer here is that experience is the only thing that matter. Reverse engineer tons of stuff. Expand your knowledge. Share what you've learned. Etc etc.

But of course, getting a certification won't do you any harm and as far as I am concerned, will only count as a plus on your CV.

However; having a certification on your CV doesn't get you a job on it's own. In today's day and age the recruiters are actively searching for people who "do more". I would suggest that you start building your "brand". Make yourself visible in the community. Discuss new malware on Twitter. Share your knowledge here on security.SE etc. That's what ultimately is going to secure your position as a malware analyst.

When it comes to what certs to take; I've heard and read a lot of good things about the GIAC Reverse Engineering Malware (GREM) certification.

I've also been looking at a lot of open Malware Analyst positions, and here are some of the varous certifications they ask for. There are probably many more, and these are usually just suggestions from the hiring-side. Don't be afraid if your certification isn't on their "we want someone with these certs"-list, they might just not have concidered (or hear of) the one you have (which isn't necessarily a bad thing, HR is HR after all).

GIAC Reverse Engineering Malware (GREM)
Microsoft Certified Solutions Expert (MCSE)
Cisco Certified Network Associate (CCNA)
Cisco Certified Network Professional (CCNP)
Certified Information Systems Security Professional (CISSP)
Certified Ethical Hacker (CEH)
Certified Authorization Professional (CAP)

For your last question; Take a certification when you have the money, time and done enough research on the certification to make you certain that it covers exactly what you want to learn. There is no rush, and some employers even pay for certifications once your hired. So my best suggestion is, start building your brand and grow your knownledge.


Should I put a potentially insecure program online? OK: a forward. I am not a security expert. I am one of four kids at a high school working on a project. I don't have any experience with real-life situations where security is a concern.

I have a project that's for automated program grading. Students upload code and we compile and test it. Obviously, there's a threat of people uploading malicious code. So what we have recently done is have the code be executed behind a runas command on a user with little privileges. It seems to work, but then again what do we know?

Now my instructor wants us to go forward and put our project online, available to the internet. I worry that our project is likely insecure, and that us students are not qualified to assess the program's security.

Would a simple runas-based "security" system be sufficient, or should we hold off on putting it online?

Edit: to clarify, the way it works is that people upload programs to our server, which then executes it locally and displays the results. So if the uploaded code is malicious and works, then it's our server that's taken over.

"runas" will protect you from only a portion of the threats.

There are a few ways you could handle this. You need to lock down the firewall to prevent outgoing connections that you do not intend. Logging and auditing need to be turned on (and reviewed!!) to catch tampering.

If the server is a VM, you could have it revert to a saved snapshot every hour, meaning that any malicious code could not persist.

Can you maintain a copy of the uploaded code and the IP address that uploaded it for forensic review?

In any case, you need to think of the server as already compromised and treat it as such. Segregate it on the network that it is on, and nuke it from orbit either regularly or at the end of your project. Make sure there is nothing else running on the server that could not handle being taken over (i.e. make your service the only thing running on the server).


Would multiple exposed bcrypt hashes of the same UUID v4 with random generated salt be too insecure? I'm looking into implementing an ownership check on JSON objects and want to avoid going back to the database to ensure ownership of said object/record (i.e., to prevent a user from updating an object/record they do not own - mostly CRUD operations). This would occur in the context of a web-application/service api.

My thought is to have a private server-side system assigned "ownership" v4 UUID tied to every user record, so that when passing any user owned JSON object to the view, the system encrypts the owner's private "ownership" UUID using bcrypt with a random salt and assigns it to the object/record (where it could be persisted along with the record for caching purposes so it does not have to be re-encrypted). Also, I should note it's possible that owned objects may be encrypted separately each with their it's own random generated salt, even though they are in fact the same user's ownership UUID (this is needed to help prevent tracking of user's object ownership in certain application use cases).

Later, if a user tries to update said object, the server would have to validate their private UUID against the bcrypt hash to ensure if they have the ownership rights to update the record.

This is assuming that I would encrypt using an appropriate number of rounds for the encryption. Another assumption I'm making is the encryption and checking time would outweighs any database check times. The last assumption to point out is this strictly an app security check and would do nothing if someone actually got a hold of the database.

My current thinking is that with the UUID being random and it's large string size (along with an appropriate number of rounds) would make having these bcrypt hashes exposed publicly not be so much of a problem. Or is this approach just too much risk/oversight?

You don't need bcrypt here.

Bcrypt and other similar password hashing functions use salts and iterations in order to cope with the inherent weakness of passwords, which is their vulnerability to exhaustive search. The space of possible passwords, the one which most users will choose and be able to remember, is simply too small for comfort. We use iterations so that the attacker's task is slowed down. We use salts so that the attacker may not make economies of scale when trying to break several passwords. But all of this makes sense only because breaking one password is feasible.

When the data which is to be hashed (for ulterior verification) is a strong random key, chosen uniformly from a space large enough to defeat exhaustive search, then salts and slow hashing are not necessary. This is the case for your "private UUID". A "v4" UUID is supposed to contain 122 bits generated from a cryptographically strong PRNG. This is way beyond that which is amenable to exhaustive search. This "private UUID" is a key in the true sense of the term.

So, in a given protocol where you hash these "private UUID" with bcrypt, you can replace bcrypt with a simple hash function (e.g. SHA-256) and forget about the salts. In your case, the server stores h(UUID) for some hash function h, linked to a user, and the user has to show the UUID itself to be granted access. This is the simple "password" model but with a really strong password, which does not require the tools developed to tolerate human-remembered passwords (which are not strong). Of course you would want to run the whole protocol under the protection of some layer which ensures that the client talks to the right server, and the transfers are protected from eavesdropping and alterations (basically, SSL).


What happens when captcha keys get compromised? I was just wondering out of interest. What happens if your captcha keys get compromised. What can they be used for and how can you detect that they have been compromised.

I assume you are talking about recaptcha keys. The answer is not much happens if your recaptcha secret key is compromised. As far as I know, the key is only used to verify the server's identity to google's api when verifying the user's response. Since the response can only be verified once, an attacker cannot use it to bruteforce the solution to the captcha and therefore cannot bypass the captcha simply by learning the secret key. The attacker can use recaptcha with your key, but since recaptcha is already free, there is no point in doing so.
As @ThoriumBR mentioned, the attacker can abuse the service in which case google will detect anomalous activity and block your account. This could result in DoS for your website while you try to clear up things with Google. Your service being suspended would be the most obvious indicator of your key having been compromised (atleast if google informs you why it was suspended).


Storing third party auth info; Is this secure? I have a feature request to connect my PHP web-app to the users mail server. I have usually strayed away from this type of work as it will mean storing the users email passwords.

My question: is it secure to store a users third party email password, if the email password is encrypted using PHP's openssl functionality, of which the private key will be some hashed version of the users login password to the PHP application. (Users login passwords will be hashed using a different algorithm for authentication purposes.) The plaintext password to the web-app will not be stored in the server.

Upon user login, we can use the plain text password  to access the private key to the users encrypted email password.
This could then be re-encrypted using openSSL, with a daily refreshed server key.

The result (or part thereof) of that encryption, could be stored as a cookie in the users browser, only accessible every time the user loads a page in the web-app.

Is this method effective for ensuring the security of the third party email passwords?

It's hard to tell from how you worded it, but it sounds like there may be a few areas that can be improved.  You don't want they key to be derived from some hashed version of the password, but rather want to use a secure key derivation function to derive an encryption key for the user's keyring.

Derived keys have limited security, so you want to limit how much you encrypt with the derived key.  My recommendation is to produce a truly random encryption key to use for the user's e-mail credentials.  That key (symmetric) is then encrypted with the derived key from the user's password and stored in the database.  When the user logs in, their password should be used to determine their derived key and the data key should be decrypted and stored in the user's session.  When the user needs to access the e-mail configuration, the key is available to be used for decryption, however as soon as the session ends, the credentials will be cleared from memory and be unavailable until the user re-enters their password.

The use of a separate key for encrypting the e-mail credentials also means that you can use asymmetric cryptography to encrypt the configuration key so that it can be used by a separate server for sending e-mails when the user is offline (if you end up needing that feature).  Since this e-mail server could be isolated from input from the outside world, it would have a much higher degree of security and the private key wouldn't be available to the outside world so it would be very difficult to compromise the account details.


Is this data encryption process secure? I have created the following encryption process which I will be using to store CD keys inside my database. Before I use it, however, I need to make sure that this is as secure as possible.

From what I see, there are two primary concerns:

The storage of the private key must be extremely secure. If someone gets a hold of the primary key, they can decrypt all the data in my database
The encryption method must be as secure as possible

Is there a better way to securely store data in this scenario? If not, how can I ensure that this process is as secure as possible?

Here's my code:

public static function encrypt_key($key)
{
        $iv_size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CBC);
        $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
        return $iv . openssl_encrypt ($key, 'AES-256-CBC', '32 bit private key', 0, $iv);
}

public static function decrypt_key($key)
{
        $iv_size = mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CBC);
        $iv = substr($key, 0, $iv_size);
        return openssl_decrypt(substr($key, $iv_size), 'AES-256-CBC', '32 bit private key', 0, $iv);
}

There are several improvements that can be made to the functions you've given, based on my knowledge.

Obvious threats

First, and most important, keep your private key secure, and make it external to the function definition (e.g., a second argument). I would recommend spending significant effort solving this problem. Is this per-user encryption, or application-wide encryption? If it's per-user, then why not use a key derivation algorithm, such as PBKDF2? If it's application-wide, then good luck with secure storage - I've thought about it before, and it seems non-trivial for a typical web app. Just make sure that you don't store the private key along with the source, nor (obviously) in the same database.

Also, as an aside: never use symmetric encryption for anything that's password-like. Use a one-way hash instead. I'm assuming, for this answer, that you need to actually recover the original CD key, rather than just verify a match.

Second, I'm dubious of the use of MCRYPT_RAND. It sounds like it might be the same PRNG as rand(), which is not ideal. Generating the IV with MCRYPT_DEV_URANDOM is what I'd recommend - /dev/random and /dev/urandom are both considered top-notch sources of cryptographic random numbers on Unix-based systems. Note that you don't generally want to use /dev/random for a web application, because it would open up an easy DoS vector - and /dev/urandom should suffice outside of embedded environments, anyway.

Other implementation issues

Now, with the major vulnerabilities that I can spot taken care of, a few more fine-grained details:

You're mixing OpenSSL and mcrypt functions. Also, openssl_encrypt is not documented in the official PHP docs (I suspect it's documented for C somewhere, though...). It might be better to use mcrypt_encrypt instead, since it's explicitly documented for PHP.

You're mixing CAST-256 and AES-256, as well. You should probably stick with AES-256 throughout, since that's the generally-advised standard algorithm for strong symmetric encryption. Note that AES-256 is MCRYPT_RIJNDAEL_128 used with a 256-bit key, and is NOT the same as Rijndael-256, which is something that I hadn't previously realized (the more you know!).

I'm not sure about the preferred cipher mode, but CBC is one that I have seen recommended for AES, at least. Hopefully someone else will have some input.


Methods for protecting computer systems from physical attacks I am interested in cost effective and creative ideas for detecting physical attacks against computer systems.   This includes,  but is not limited to Tamper Evident security measures.

Consider the following attack scenario:
An attacker would like to obtain data from a harddrive. The target machine is setup with Full Disk Encryption,  a bios password is set and the boot priority states that the encrypted drive is the first device to be booted.

The passphrase must be typed in order decrypt the drive and boot the machine.  A Hardware Keylogger could be installed to obtain this value.  Some full disk encryption implementations can be defeated with Bus Sniffing,  however in order to carry out this attack the computer case must be opened.   In either attack, after a period of time the attacker can return and collect the harddrive and intercepted passphrase.

How can you detect if your computer case has been opened?  How can you thwart the use of a hardware keylogger?

Also here is a great talk on Bypassing Tamper Evident Devices.

Edit:
The state of modern physical security is incredibly poor.  Literally every door lock available at my local Walmart can be picked in seconds.  Most homes in the US are still using pin tumbler locks that originally invented by the Egyptians thousands of years ago.

The problem with trying to detect these attacks is that their common target - desktop workstations - largely goes unobserved for most of its life.  Even if it actually sits on the desktop, users rarely pay attention to it except to push the power button, insert/remove removable media, or plug/un-plug accessories - all of which generally can be done from the front of the system, while the simplest way to hide these attacks is to plug into the rear.  You could perhaps mandate that all desktops be kept actually on the desktop, and have all peripherals plugged into front-facing ports, but that almost certainly won't gain good user acceptance.

There probably is no easy way to thwart a hardware keylogger, except to regularly check your peripheral connections.  You can include this in your end-user training, but it's unlikely to ever actually be done by them and it increases the probability that they'll have to call for help when they've inadvertently unplugged something essential in the process.  A better method, if there must be one, may be to have a team of technicians perform regular hardware inspections.

The easiest and most cost-effective way to detect breaches into the computer case itself would be to use stickers akin to the ones OEMs use for warranty validation.  Of course, this would require that you regularly check said sticker to verify it hasn't been tampered with.  Again, this is not something that would be well accepted or implemented by the end-user.  So, it will be up to your technicians to regularly inspect their systems.  You'll also have to make sure that said technicians have access to the stickers so that they can apply new ones whenever they service the systems, but then we wander into the possibility of insider attacks.

Alternately, some cases and motherboards support hardware-based monitors which can alert you at boot-time if the case was opened since the last power-on.  These may or may not be easily circumvented (i.e.: Attacker covers his track by power-cycling the system to dismiss the alert before the victim uses it again.) depending on design, and again may still be vulnerable to insider threats.


Is the CSR and public key the exact same thing? Is the CSR and public key the exact same thing?

I require the CSR - can I create a Public key from .cer and use it as CSR?

I need the CSR for HPKP backup key generation.

Is OpenSSL the only way to do this (Windows Machine)

No, they are not the same.  A public key is actually one member of a "key pair", consisting of both a public key and the matching private key.  The CSR is a Certificate Signing Request, which is just a form you fill out.

When creating a CSR, you attach your public key to it and fill in other needed data; you then send it to a Certificate Authority (CA).  The CA takes the data from your form, and if you pass all their validation tests (i.e. your credit card is charged), they use the data from your CSR to create a certificate, and then they sign your new certificate with their "root" certificate.  This gives the rest of the world assurance that the public key found on the certificate is actually associated with you.

Normally, nobody but the CA needs a CSR.

In your case, it sounds like you're stuck in the middle of someone else's process that hasn't been described adequately.  If this "HPKP backup key generation" (whatever that is) is creating a public/private key pair, they may be asking for a "blank" CSR to use as a template to request a new certificate every time they generate a new backup key.  (Really, they probably just need the data fields you want on the certificates.)  But that CSR is always incomplete because the public keys haven't yet been generated.

You probably need to sit down with both the certificate people and the HPKP people, and figure out who actually needs what.


Can hackers find secret tokens passed to HTTP GET requests? I have some code like this in index.php:

if(isset($_GET['something'])){
    //do something
}

Can hackers find this and request index.php?something, or is this sufficient for security?

You're relying on a principle called security through obscurity, which is generally frowned upon. There is a widely-accepted principle called Kerckhoffs's Principle which states:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

An alternate, and more general, form of the principle is called Shannon's maxim:

  The enemy knows the system.

Essentially, this means that you should never rely on an obscurity mechanism to protect your system. You should assume that attackers know the code, and can discover any vulnerabilities like this.

As such, your access mechanism should involve proper authentication - e.g. entering a set of credentials that can be checked on the server side, using proper password hashing. This means that even if an attacker knows your code, he cannot exploit it.


How does ASCII-Armoring help to prevent buffer-overflow attacks? I was reading about return-to-libc attacks at Wikipedia.

According to what I read and understood from the article, ASCII armoring means that binary data is converted into ASCII values by grouping them into 8-bit chunks.

The article quotes:

  Indeed, with ASCII-Armoring, all the system libraries (e.g. libc)
  addresses contain a NULL byte. Nevertheless, this same concept can be
  used in a similar and more advanced attack known as return-to-plt,
  where instead of returning to libc, the attacker uses the PLT
  functions loaded in the binary (e.g. system@plt, execve@plt,
  sprintf@plt, strcpy@plt, etc...).

Can someone please explain, how exactly does ASCII armoring prevent buffer overflow? I didn't get the part where it says, that system library addresses contain a NULL byte. And how does return-to-plt prevent buffer overflow? I searched, but didn't find much explanation regarding return-to-plt attacks.

If the address is getting treated as a null terminated character string at some point, inclusion of this "ASCII-Armored" address would cause functions that work with null terminated character strings such as, strcpy, strlen, sprintf to stop processing at the end of the libc address.


SMS Authentication: random OTP or a cryptographic one I'm adding two-factor authentication using SMS to enhance an existing login process. Since I'm not working with physical tokens, I was wondering what is considered the safest:

Sending random 8 character strings or 8 digit hashes generated using some kind of Time-based One Time Password (TOTP)algorithm.

My own considerations were the following:
Hashes generated using TOTP don't have to be stored in order to check if they are entered correctly by the user. Randomly generated tokens do need to be stored and linked to a user account and a time stamp.

Yet, the process of randomly generating a string seems easier and appears to have less vulnerable spots that can be compromised.

If done properly, time-based one-time passwords will be reasonably secure. That's a bigger "if" than usually assumed.

What would work would be the following:

Decide about your time granularity, e.g. 5 minutes. All dates considered here will be a multiple of that granularity (i.e. 8:05:00, 17:25:00... but not 16:34:00).
Generate a secret symmetric key K of appropriate size (16 bytes straight from /dev/urandom, CryptGenRandom(), java.security.SecureRandom or System.Security.Cryptography.RNGCryptoServiceProvider, depending on your religion).
When generating a one-time password P for user U at time T, compute:

P = encode(HMAC/SHA-256(U || T, K))

which means that you "concatenate" the user name and the current date into a custom structure (XML, ASN.1, text-with-separator... whatever fits your bill, as long as it is deterministic and non ambiguous), over which you compute a MAC, using specifically HMAC with SHA-256 as underlying hash function, and K as key. The encode() function is something which truncates the output of HMAC and encodes it into something that can be displayed on a phone and typed in by a user.
You send P to the user. At time T' (presumably not long after T), the user comes back and enters a password P'. You then recompute the value of P for time T' and for time T'-5min, for the same user U. If either value matches P', then authentication succeeds, otherwise it fails.

The tricky points:

You must not truncate "too much". The attacker may want to try his luck and send a random password; the space of possible passwords must be wide enough to make such success highly improbable.
You can use any "encoding" you want as long as it is deterministic and mostly uniform. For instance, interpret the HMAC value (a 256-bit string) as a big integer (in the 0..2256-1 range) and take the remainder of the division of that integer by 100000000; you can then represent that value in decimal (left-padded with zeros if necessary), to get a nice 8-digit password. The remainder operation is the "truncate" and it will be sufficiently unbiased in this situation. If you prefer 8 letters, divide by 268 and use base 26 to represent the remainder.
The granularity is linked to the security. Note that upon verification, we try exactly two passwords (we need that, because the password must be valid even if the user gets his SMS at 11:34 and enters it back at 11:36). This divides by 2 the difficulty for the attacker: if passwords are 8-digit sequences, then there are 100000000 possible passwords, but the attacker has probability 1/50000000 of success. A granularity of 5 minutes means that a one-time password is valid for 5 to 10 minutes. If we want to make this lifetime more precise (e.g. 5 to 6 minutes) then we must lower the granularity (e.g. down to 1 minute) and accept more passwords (for T', T'-1, T'-2... to T'-5) which raises the success rate for the attacker (here 1/16666667). There is a trade-off here: more precision implies less security. In my opinion, it is best to keep security high and to tolerate password lifetime to freely vary in the 5-to-10 minutes range.

Note that this question granularity is precisely the point where security of time-based passwords departs from that of randomly chosen passwords. As explained above, you need to accept N successive passwords for some N (at least 2), and the chances of success for the attacker are N times as much as what he would have for a random password of the same size.
For multi-frontend systems, the key K must be shared because the server which receives the first request and generates the password is not necessarily the same than the one who receives the second request and must verify the password; but both must use the same key. Also, all frontends must have the same notion of time (use NTP).
The key K needs not be permanently stored; it is acceptable that it does not survives reboots, since the generated passwords are short-lived anyway. You could generate K when the server starts (this means that a password sent by SMS before the reboot will not be accepted after the reboot, which is probably no big deal). Mind, though, that transient keys can be a hassle with multi-frontend systems (the frontends must somehow use the same key).
You want to add some guard mechanisms to avoid vandal attacks: people who ask for one million authentications for a given user U. User U does not want to receive one million spurious SMS; and you certainly do not want to pay for the sending of one million SMS (these things ain't free). One possible countermeasure is to use the SMS-based password only as a second authentication step, after having verified the user's principal (non moving) password (or whatever is your first authentication factor in your two-factors system).


Which security documents do providers typically share with their customers? In the context of managed/cloud hosting, what level of information does a provider typically share (under NDA) with its customers for compliance audit/3rd party risk assessment purposes?  What are documents that are generally made available, and what are some that aren't?

For example, does a provider share policies and standards, but not procedures; an Information Security Policy but not a Business Continuity Plan; Internal-use classification, but not business confidential?  Does a provider forego sharing detailed information in favor of its own 3rd party audit?

The audits are generally related to common regulations/standards/frameworks such as HIPAA, PCI-DSS, SOX, ISO 27001, etc.

This question verges upon opinion-based, but I'll try and provide some suggestions based on my experience (which is biased towards PCI but touches on others).  It isn't specific to the cloud but I believe there's an equivalence.

Some rules of thumb:

Attestations / summaries are distributed, reports are generally not
Policies are more likely shared than distributed
Formal audits are often subject to distribution limits

Some more information on these ROT:

Audits and scans often come in multiple levels.  For example, a PCI audit will result in a ROC (Report On Compliance) and an AOC (Attestation Of Compliance).  The former is a fully detailed report, and the latter is a quick summary.  The AOC is for distribution, and the ROC is not.  And - in the case of PCI - the AOC is not considered fully authoritative; the Service Provider Listing on the card brands' site is what customers are directed to for an authoritative source (compliance can be invalidated within a reports valid timeframe...)

The same is generally true of scans.  Detailed scan results, which list items that are not desirable even if they aren't fully non-compliant, are almost never distributed.  Top-level reports which list whether or not items existed are pretty much it.

When it comes to policies, these are generally handed out only grudgingly.  A common practice is to permit partners to come onsite to view the policies rather than distributing them.  This both ensures the security of the policies from distribution and subtly discourages partners from going through the trouble of coming to get them.

This is very one-sided, by the way.  I've worked for a large bank which required copies of security policies for company that wanted to integrate anything with them.  They're in a position to demand that, and they do.  The client of a bank or a service provider, however, lacks the leverage required to demand the same.  Also, what I said about the ROC and AOC - the ROC must be handed up the ladder to the Card Brands; that's what it for.  But it's never shared downward.

Finally, be aware that limits may apply.  If you have a contract, then it may include contractual obligations.  Large customers will often demand clauses that allow them access to things, or even to audit the service provider on a regular basis.  Some auditors place distribution limits on their full audit report, and in the case of SSAE16 SOC 2 report, distribution is disallowed by default.


Should I develop with TLS on or off? I develop applications on my local computer that I later deploy to a TLS production server. Should I develop with TLS on or off?

The answer is simple - yeah, dev using TLS. Here's why:

You need to set the secure flag on cookies
You want to make sure all resources accessed are https
You might forget to turn on TLS dependencies when you deploy your code to production
It's easy to do this. Go use acme.sh to register a let's encrypt cert using DNS for domain verification. Create a DNS A record that points to 127.0.0.1. Done.
Don't use self signed certs because I don't want you forming a habit of clicking past TLS warnings

If you really really don't want to....

Then you need a post deploy compensating control. That means scan your website looking for TLS dependancies like the cookie secure flag. Use qualys free scanner to probe your site for issues like this.


Possibility of faking someone's public key I know how public key cryptography works; (very) simplified:

Alice takes Bob's public key and sends an encrypted message with said key and sends it to Bob.
Bob and only Bob can decrypt the message, since he's the only one that possesses the concurring private key.

Scenario (also simplified):

I somehow infect Alice's device and replace Bob's "stored" public key with my own public key. After she encrypts her message with my public key and sends it, I intercept the message and can now decrypt it with my private key. I could then act as the man-in-the-middle.

Edit: We assume that we somehow only can change the public keys and not read the message in plaintext.

My questions are:

How does Alice know Bob's public key?
Is is possible to deceive someone (or the device itself) so that they would i.e. think that they're sending the message to Bob but infact are encrypting the message with someone else's public key?
How is this issue circumvented?

If Alice keeps her correspondent's public key in a database, spreadsheet, text document; then it's feasible that your scenario would work.

However, most (including Alice hopefully) would only trust public keys that have been certified as authentic. There are two mainstream methods by which this is currently done:

Certified by a central authority

The public key is certified by an organisation specifically set up for this task - these are called Certification Authorities (CA).

The CA will have checked Bob's credentials when he asked them to certify his public key.  Bob can then send his certified public key (commonly known as a certificate) to Alice and his many other friends/colleagues.

If Alice only trust public keys that have been certified by trusted CAs then your scenario now fails.  You cannot sneak in your public key as it hasn't been certified and consequently Alice won't trust it.

You can approach the CA with your public key, but they'll only certify that it belongs to you - not to Bob (or Alice, or anyone else).

This method is used by the commercial CAs which sign the certificates used for asserting the identity of resources on the Internet (such as this site).  Organisations may also operate their own CAs.

Certified by friends and/or colleagues

An alternative to the above method is for Alice to confirm with friends/colleagues that already correspond with Bob as to whether his public key is genuine.  They'll know this by confirming with others, or by confirming with Bob himself (maybe a face-to-face meeting). This way, the trust spreads like a spider's web, leading to this concept being called a web-of-trust.

This latter method is used by Pretty Good Privacy and Gnu Privacy Guard.

The CA isn't the be-all and end-all of the problem though.  In your scenario you have compromised Alice's device, which means you could configure her device to trust public keys certified by another CA - namely yours.  You can now certify your public key masquerading as Bob's and Alice would unwittingly trust it.

However, CAs come into their own when we diverge slightly from your question and consider 'Bob' not to be a person, but instead to be a new resource on a extremely large network such as the Internet.  In such cases, the Web-of-Trust model would not work simply due to the scale of the problem of managing all the public keys.

In other words, a CA would not be of much benefit in a scenario which consists of a single one-to-one relationship, such as Alice and Bob in your question, because it simply changes the test Alice implicitly makes from Do I trust Bob's public key? to Do I trust that my device hasn't been configured to trust additional CAs?

However, in a one-to-many relationship, such as the Internet, a CA will remove the requirement to somehow check each and every public key before use and replace it with checking the configuration of your device (which we all do without question!).

Of course, in the real world, if you successfully compromise Alice's device, whether you change Bob's public key is immaterial in the bigger picture.


How did stuxnet hid it's files after the infection? I've noticed that when ~WTR4141.tmp is loaded, it doesn't set hidden file attributes to .lnk files and on the other .tmp rootkit file of the Stuxnet bundle.

I've seen that these are all the possible file attributes on Windows:

Let-  Bit
ter   masks Description and notes
--- ------- ------------------------------------------------------------------
 R      0x1 Read-only
 H      0x2 Hidden
 S      0x4 System
(V)     0x8 Volume label (obsolete in NTFS and must not be set)
 D     0x10 Directory
 A     0x20 Archive
 X     0x40 Device (reserved by system and must not be set)
 N     0x80 Normal (i.e. no other attributes set)
 T    0x100 Temporary
 P    0x200 Sparse file
 L    0x400 Symbolic link / Junction / Mount point / has a reparse point
 C    0x800 Compressed (flag changable with directories only)
 O   0x1000 Offline
 I   0x2000 Not content indexed (displayed as 'N' in Explorer in Windows Vista)
 E   0x4000 Encrypted
(V)  0x8000 Integrity (Windows 8 ReFS only; attribute not displayed in Explorer)
 -  0x10000 Virtual (reserved by system and must not be set)
(X) 0x20000 No scrub (Windows 8 ReFS only; attribute not displayed in Explorer)

(Taken from: https://superuser.com/questions/44812/windows-explorers-file-attribute-column-values)

So my question is simple: How does stuxnet hide itself?

Answer is also simple - inject into Explorer and hook the following functions:

FindFirstFileW
FindNextFileW
FindFirstFileExW
NtQueryDirectoryFile
ZwQueryDirectoryFile
.

Symantec has a bit more in depth explanation.


How to secure MySQL database usernames and passwords within a php file? I am working on a PHP website and my researches showed that it is entirely possible that the server can get hacked and the PHP files may get exposed. I store the MySQL DB Username and Password within the PHP files in the form of constants, which is then used while forming the connection string.

define("HOSTNAME","hostname.com:2086");
define("DBNAME","databasename");
define("DBUSER","databaseusername");
define("DBPASS","databasepassword!");

/* Defining DB Handler */
try{
    $DBH = new PDO("mysql:host=".HOSTNAME.";dbname=".DBNAME, DBUSER, DBPASS);
    $DBH->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $DBH->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
}
catch(PDOException $e){
    echo $e->getMessage();
}

If by any case the PHP files get exposed, this would cause the database and its contents to be at risk too. Am I doing it wrong? Is there a better way to ensure the safety of the database even if the PHP files get exposed?

I good way to protect your keys is to put the php file with the credentials outside of the webroot.
 Even when the 'raw' php files are then served to a client, none of them include the database  credentials. (does not protect against someone with file access on the server).

Another defensive measure you can take is limiting the connections the Database accepts connections from. (so not the whole world but just a select list of specific ip's)

Lastly you should make the account that connects with the Database only have rights on its own database, and no other!


At times bettercap ARP sniffing works great and at times not at all, what would be the reason? I like to track the websites my daughter goes to in order to have some control. So I installed bettercap and setup a script to start it to sniff the HTML URLs being accessed (well, the reverse URL from the IP really).
sudo bettercap --eval 'set events.stream.time.format 2006-01-02 15:04:05;
                       set arp.spoof.targets 192.168.n.m;
                       arp.spoof on;
                       net.sniff on'

Note: the command is a single line (no new-line), I added new lines here for clarity.
The result is a large list of URLs as she hits one website or another. Especially, I see a ton of marketing websites (darn!). But at times I just see the messages:

endpoint detected as

and

end point lost

(the messages include the IP address and device name, in general).
So even though the end points are properly detected, no other data comes through.
My network looks more or less like this:
+--------+   +-------+
| Laptop |   | Phone |
+---+----+   +---+---+
    |            |
    |            |
    |            v
    |      +----------+
    +----->| WiFi Hub |
           +-----+----+
                 |            +-------------------+
                 |            | Main Server       |
                 v            |                   |
           +----------+       |   +-------------+ |
           | Switch   |<------+   | Kali Linux  | |
           +----------+       |   | (bettercap) | |
                 ^            |   | VPS         | |       +--------+
                 |            |   +-------------+ +------>| Router +----> Internet
                 |            |                   |       +--------+
                 |            +-------------------+
           +-----+-----+
           | Laptop    |
           | (Wired)   |
           +-----------+

So all the traffic from all the machines do go through the Main Server using the FORWARD capability of the Linux firewall. In other words the computers to the left are all isolated (they can still communicate between each others but not directly to the main server, the main server can connect to some of them, though). So the network is rather secure.
Since it worked before I would imagine that the script is correct, but still, there is something that makes Kali bettercap work or fail just like that. I'm not too sure what I would need to do to make it work every time I reboot without having to fiddle with it (although this time the fiddling didn't help, it's still not tracking anything).

For those wondering, what I can actually do is use a tool such as tcpdump to look at the packets going through the Main Server. The command accepts an expression which is a pcap filter. For example:
sudo tcpdump -i eth1 src host 192.168.100.100 | tee packets.txt

This command will record the packets in packets.txt and print them on the screen. It will include most everything that goes through 192.168.100.100 on the eth1 interface. Keep in mind that you're going to get all the packets. That's a lot. There are options to extend the filter, though, and for example only show TCP/UDP packets and not each ARP, ICMP, etc. That definitely works a lot better than the so called bettercap software. At the same time, you get swamped with packets so you really need to work on filtering the results. Especially, you'll see a bunch of repeat and IPs that do not resolve to a domain name... (many CDNs/large companies don't have names for all of their IPs).

To sum up the comments, you don't even need to use ARP spoofing since all of the network traffic is already passing through your server. At this point, you can passively sniff any unencrypted traffic, and may be able to determine what hosts are being contacted by using the TLS SNI value, which is unencrypted. If you want to monitor and control HTTPS traffic further, you would need to set up a TLS interception proxy and install your root CA on client machines.
If this were truly a scenario where an ARP spoof attack was needed, these attacks aren't always reliable due to their nature; mainly caching issues and conflict with legitimate ARP requests.


User data encryption/decryption in a database (PHP) I was wondering which is the best way to encrypt and decrypt user data in a database, to make it much more secure as it is possible?

I was reading about AES but I would like to know if is really the best way.

I was planning to use AES and a secrete key for encrypt/decrypt, is there any better way?

Secure, yes, but against who or what ?

Regardless of how you encrypt data, your server must still be able to decrypt it. So any attack which subverts your server (e.g. buffer overflows or SQL injection) will yield full data access to the attacker, regardless of your encryption.

Encryption will do you any good only against attackers who get backdoor access to the storage, e.g. who steal a backup tape or recover an old hard disk from a dumpster. Then, this points to the kind of encryption you need: Transparent Data Encryption (equivalently, a full-disk encryption, as hinted at by @Polynomial). TDE does not remove confidentiality needs, but it concentrates them: you "just" have to worry about the encryption key, which is small and does not change over time, instead of gigabytes of ever-mutating data.

(Of course, if you want to sprinkle encryption all over the server just to ease the qualms of some administrative hierarchy somewhere, then forget all of this and just go for an algorithm with the most impressive-looking acronym, preferably with a very long key. "RSA-8192 and AES-256/CBC with HMAC/SHA-512" will reliably plunge the average bureaucrat into an ecstatic trance.)


I accidentally installed an adware filled Firefox [solved] I installed Firefox using a download site, rather than the correct site.

After running and installing Firefox I noticed my Chrome had an addon called Swift Browser added to it by a third party. After thinking about what I downloaded recently, Firefox came to mind and when I checked the link again I realized my mistake.

Malwarebytes removed 5 things, then using "add or remove" programs I uninstalled Firefox.

I would like to know any other steps I should take or what I should be expecting.

I ran ADWcleaner on advice from a friend. Another thing was removed running HitmanPro 3.7.8.

Hitman Pro removed a few trackers.

When compromised you should re-install your machine completely. There is no way of knowing for sure that nothing else has been compromised.


Does Gibson's fingerprinting service add much additional security? I just read this post and it proposes a method of storing SSL fingerprints online so that you can double check that your certificates have not been tampered with.

But is it really relevant or useful? To me it does not seem to add any security: it lets you know that you are being snooped on,  but doesn't protect you from that. In addition, it seems a bit cumbersome to use the service1. Also, the note about EV certificates seems invalid because malware can just replace browser binaries. I was just able to compile2 my own hacked firefox that allowed GRC.com to show up as EV with my certificate. Many companies already force modified browsers3 on their employees.

So, does this fingerprinting service add much security to the existing system?

1. Security at the expense of usability, comes at the expense of security.

2. This usually takes time, fortunately I do have a compiled FF with me and I can run an incremental build.

3. To be frank I've only heard of one case where the browser had an addon baked in to the install (like Tor Browser) that locked down some parts, but I'm sure there are more

I would say that the mixture of multiple font sizes, colours, frames, underline, bold text, underlined bold text (for God's sake !) is enough clue about the kind of site you've stumbled upon.

However, let's put aside these aesthetic considerations; Gibson might be colour-blind and that would not be his fault. So, let's see what the proposed system is about, technically. Gibson runs a service on his server. Let's call G Gibson's server. A user U wants to connect to some SSL server S, but fears that he might be under the scope of an interceptor proxy which runs a Man-in-the-Middle attack by issuing on-the-fly a fake certificate for S (this may work if a CA under control of the interceptor proxy has been pushed in the "trusted CA" store of U's browser). Then user U connects to G, enters the name for the target site S; G connects to S, fetches the certificate used by S, and returns it to U. That way, U can check whether the certificate he sees (from server S) is identical to the one seen from G.

As a security system, it has (at least) the following issues:

Since user U connects to G with a SSL connection, that one could be intercepted just as easily by the interceptor, and the page contents replaced. If, gods forbid, Gibson's service gained any kind of non-negligible popularity, then proxies would do just that automatically, which would reduce the service's added value to exactly zero. The foundation of Gibson's service is the idea that his SSL Web page can be obtained as is, free of malicious alterations, and yet the situations that the service tries to help with are indeed the cases where SSL Web pages cannot be assumed to be obtained without malicious alterations. This looks self-contradictory... because it is.
The extra security hinges on the idea that while user U could be under the influence of an evil proxy, Gibson's server G is, of course, completely free of such attacks and sees the World as it is. He claims as such: "We use the “Tier 1” provider “Level 3” to connect directly to the Internet Backbone with no third-party between us and any remote website." This is, at best, delusional wishful thinking. The sentence is, in itself, a contradiction: "We use a third-party provider to send our packets so that our packets reach any remote Web site without going through any third-party provider." And regardless of how much money Gibson pays on his side of the connection, he has no control over how other Web sites are connected to the World.
Gibson seems to assume that though the World is full of nasty evil entities, he, of course, is obviously completely trustworthy and what he utters can only be the Truth. It goes without saying; indeed, he does not say it. But, pausing for a few seconds, if we choose to assume that we are being "lied upon" (Gibson's terminology) by people who already have quite a lot of technical power on our browsers (inserting extra trusted CA), then why would we trust a random stranger on the Internet ?
... which brings me to the next point, which is that the method used by Gibson's service seems to carefully avoid taking the one step which would make it more useful, namely signatures. Gibson's service is over HTTPS, so that is authentication: user U might be persuaded, on the moment, that he is indeed viewing a genuine page from G (subject to the caveats above). However, he gets no proof that he can show. G does not sign the assertion about the fingerprint of the certificate that he saw. If G was fooled, or dishonest, or both, then he could claim never to have sent bogus information. Why would you trust a service who does not have the decency to at least engage its own responsibility ?
Even if the system works, it may fail on normal load-balancing systems: a given Web site may be hosted on several front-ends, which do not necessarily have the same certificate. In fact, it is recommended that each front-end gets its own certificate, because the alternative is to give the same private key to each front-end, implying the private key traveled at some point -- and that's never a good thing. With such a multi-front-end system, Gibson's service would claim proof of interception at least half of the time, which would be downright embarrassing (but his avoidance of responsibility, as explained above, would come in handy at that point).
The usability issue is of course a serious problem, which alone makes the service mostly useless, even if we assumed that it would be fine otherwise.

However, could the core concept be salvaged, and all these issues dealt with ? Indeed it is possible; it is called Convergence. That system fixes most of the issues with a Gibson-like service:

Assertions about server's certificates, as exposed to the World, are signed by the "notaries", so they take responsibility and cannot as easily cheat on users -- at least, they have a high risk of getting caught.
There is not one notary, but many (at least so it is hoped), so each user can elect to choose whatever notaries he wishes too, not a single Gibson. By construction, each user of Convergence uses several notaries.
Notaries have memory, so they track certificate changes over time, too. This is much better than the basic check done by Gibson's service, which is just for the present. Convergence not only checks that the certificate used by a server is indeed the same from all the notaries' point of views, but also whether that certificate seems to change a lot over time, as that is heuristically a good indication of ongoing foul play.
Convergence relies on a browser extension which does the check automatically, avoiding the usability issue.
Sites with several certificates are taken into account in the protocol, which has special features to avoid spurious alerts in that case.

It is unclear whether Convergence is really good and useful, and, in any case, it seems not to be as widespread as could be wished for. But it, at least, avoids the glaring shortcomings of a Gibson-like service.

Gibson's point about EV certificates is, of course, bogus. He appears to have faith in the magic of EV certificates. He claims that "they cannot be spoofed" and his reasoning hinges on the idea that EV certificates are validated against an internal list of "trusted EV roots" that malware or evil sysadmin cannot alter. But they can ! Gibson seems to have observed one or two situations where the sysadmin (or some malware) inserted a proxy-controlled CA in the trusted root store, but did not bother to alter the "trusted EV" store -- from which he concluded that the sysadmin could not alter the "trusted EV store". The conclusion is wrong.

Possibly, Gibson has paid some extra to obtain a pretty "EV" certificate (indeed, they are almost twice as expensive at DigiCert), from which the usual infatuation developed. It is a common psychological effect: people who have paid a lot for some service or object will thereafter feel invested with the sacred mission to assert, whenever possible, that the service or object they paid for is way better than any other cheaper replacement. This is understandable, the alternative being to admit they they were swindled. Self-delusion is a the safety mechanism by which self-esteem protects itself. Arguably, Apple understood this concept decades ago, and it made them filthy rich.

The core issue with the envisaged scenario, though, is that it does not ultimately make sense. We are talking about a user whose browser and/or OS was modified without his consent. It is true that, right now, a common "modification" used in some organizations is the insertion of an extra trusted root CA, in order to allow seamless MitM attacks on SSL and thus the usual assortment of content inspection and filtering. Blue Coat's ProxySG product is often cited as an embodiment of this method; in the open source world we would talk about SSL Bump as part of the well-known Squid proxy. These products use an extra, controlled root CA because it is convenient: it allows the interception service to work with minimal hassle. However, it does in no way mean that interception MUST use fake certificates issued on-the-fly relatively to a controlled CA.

Indeed, in order to push an extra trusted CA, the "attacker" (often not really an evil, legally reprehensible attacker, more a sysadmin in some corporation who tries to enforce some company policies) must have sufficient privileges on the user's machine. With the same privileges, the same "attacker" could simply install some code which intercepts all the data before it gets encrypted; this is called hooking. It yields complete access over the SSL data without having to do anything about certificates; it even works against an unmodified browser. No amount of EV-greenness does anything against it.

Summary: Nope. No additional security worth speaking of. There is an underlying concept which may provide additional security, but only if done properly, i.e. not the way Gibson does it. And, even then, it would not really save victims against attackers who are powerful enough to make SSL interception work in the first place.


Available Resources for Securing RHEL 6 Some in our infrastructure group want to upgrade to start taking advantage of the new features in RHEL 6. In the past, I have relied on the NSA Guide to secure RHEL 5 and CentOS 5 installations. I find this guide invaluable.

Does anyone out there have experience with securing RHEL / CentOS 6 in a similar way? If so, what resources (written or consultative) did you leverage?

I have heard from some colleagues that version 6 is significantly different from version 5 in various ways, so I don't want to leave gaping holes in our security because I didn't adequately account for those differences.

Is Red Hat's own Security Guide for RHEL 6 really sufficient?

Would anyone go so far as to say that, unless you have a compelling functional reason, you should hold off on upgrading from 5 to 6 until some group like the NSA can produce a guide that is specific to the version you are trying to protect?

I appreciate any feedback that you may have, even if it is directing me to a more appropriate forum.

When it comes to something like a hardening guide, RHEL 6 is still considered fairly new. As sad as it seems, many of these types of guides take several months or years to produce. That being said, by and large, for your purposes the difference between EL 5 and EL 6 should be fairly minimal. When I began supporting EL 6, most of my changes were rather cosmetic. For instance, making sure to use rsyslog instead of syslogd. Since RedHat produces their own guide, a lot of the version specific work should be taken care of there.

I would, however, encourage you to check out the NSA Fact Sheet for RedHat 5 and the CIS Benchmark. Some specifics may change, but much of the core work should translate quite well.

I would also recommend checking out this related question: How to secure a dedicated linux server running a LAMP stack for commercial E-commerce use

It is worth noting that as of 2 June 2012 there exists a Red Hat Enterprise Linux 6 Benchmark from the Center for Internet Security.


How can I secure the usage of root access on android, given that I have regular updates? the situation:

I use Android 5.1
I'm running the "rooted" variant of fairphone OS, which means that:

I can enable Root access in the developer settings, i.e. I don't need to exploit my phone.
Fairphone promises to deliver security and bug fixes, in general updates for this android version.

I think I understand the security implications of using root on android.
I want to use a few apps (Titanium Backup, Droidwall and maybe XPrivacy) with root access in a "secure way", which means: I want to limit the security implications described above to the least possible.

my question:

How can I increase the security of the usage of root for some apps in android?

Note: I'm aware of threads like this one. However I ask specifically about how to secure apps which need to have root (or whom I decide to give root). I'm not talking about the general hardening of android.

You can easily do this by being a good, secure user. Follow the basic tenants of security, and be careful of what you install on your phone. After all games are great, but not when they're really viruses. Since it sounds like you're really going for a super secure phone with data archiving and backup, don't install something unless you KNOW it's safe, and keep as few applications as possible on your phone.

After all you if you do the work, then you've done the work. You look like you're well on your way to making a secure, archival-able phone image for yourself. Just in case maybe some anti malware apps aren't a bad idea so you can be sure to reset accounts from another device if it does get compromised.


What are the security features of the Microsoft PasswordVault class? There doesn't seem to be much information on the PasswordVault but it seems to provide for local encryption of credentials.
There are references to it in this source code and this blog.
The reason I'm asking is so I can understand the platform specific features (Windows based OS) and when the code is ported to other platforms using a cross platform compiler such as Xamarin

the PasswordVault uses the Windows.Security.Credentials namespace. As of today, this namespace is unavailable in Mono. so the other most popular cross platform compiler just won't work for this feature.


Securing a private RSA key for distribution There's a new law concerning POS systems in Norway which comes into effect 1.1.2017 starting that:

  b. Private Key – is secured by the system vendor, only the vendor knows the key.
  c. Public Key – is sent to The Tax Authorities "

This law states that POS machines have to hash and sign certain data that then gets logged to electronic journal. Their information letter specifically says that data should be signed using private key.

This in turn means that the private key somehow has to exist in every copy of the POS software so that it can sign hashes even if the customer's internet goes down.

If one encrypted it, the key for decrypting still have to exist in the client program..

Is there any way to properly secure a private key for distribution in a client software?

Its done by using a "Smart card" tamper resistant storage chip, so the key can only be "used", not "extracted". If any attempt is made to attack the chip to reveal the key, different sensors will react and erase the chip as soon as it is powered up.

The sensor is usually one-shot, eg when a specific condition is met, the sensor is permanently tripped, so as soon as the power is applied, it will detect that the sensor is tripped and erase the key.

The key is also stored in a way so it practically becomes impossible to extract the key using passive methods while the chip is offline.

Propably the chip will also include battery and a trusted clock, to prevent tampering, so it can also detect any tampering "offline".

This chip will propably be part of a hardware device that must be used in conjuction with the POS system, either embedded, or if its a software POS, a USB key or something inserted in the USB port.

The reason a key scheme is used, is to prevent someone from creating a fake journal that is a exact copy for the genuine journal except that certain records is changed.

Here in sweden a similiar scheme is used, but instead of requiring each POS vendor to gain a key, a "journal box", that is compatible with all POS system is used. This journal box signs data in roughtly the same way, and a verification code is shown on receipt, but the difference is that only the "journal box" vendors need to be "trusted".

And no, theres no requirement for a offline signing system. The vendor can simply require online-signing for software-only solutions if no hardware is to be distributed, and then if the internet is down, then its simple as "you are not permitted to sell, period".
A similiar rule is here in sweden if theres a power outage. Not allowed to sell.


How to know an SMTP server is securely configured I have set up an SMTP server for personal use, and I used Postfix for that. However, Postfix has a lot of different options for how to configure it, and I'm guessing by configuring it incorrectly you can open it up to a lot of security problems, like unauthorized people sending spam mail. I followed the Ubuntu official guide mostly, but I had to step outside a little of them to get it work the way I want it.

So I want to make sure that my changes did not open up the SMTP server to some nasty security problem. What I'm looking for is a way to verify that, maybe some program designed to test that.

How do I know that my SMTP is secure?

There are free services that test for remote relay availability (just google for smtp relay test to turn up several) which are going to do the same thing attackers do (attempt to relay mail, watch the result, report back).  If you perform a few of these, get their results and can match it up with your log file (to identify why the relay did/didn't work) you can pretty easily tell if you are going to unleash a spam zombie or not, and what other config issues there might be.  Postfix has a lot of configuration options, but is pretty mature so they have streamlined basic setup (believe it or not) vs what it was 15 years ago.


Career path: Is going for PMP along with having a rich experience in the InfoSec field a good career move? I think the title pretty says it all.

Do you think that if one has experience in implementations of security and network solutions, and then gets to become a PMP, will that be an added value to his career?

One way I can think of it, is that companies will hire these people from the outside, and would have them planning and running the entire project from A to Z. So it basically gives you the option to be independent.

Any thoughts on the matter?

A project management certification will help your career if you want to move from a technical to a managerial or project management role. If you want to stay technical then it has no real value, and even makes you look less technical. I have a PMP and I have to say it's not particularly valuable, but it is an important credential to have as an IT management consultant.


PHP socket_connect Stack Overflow In the desciption of the vulnerability:

Stack-based buffer overflow in the socket_connect function in ext/sockets/sockets.c
in PHP 5.3.3 through 5.3.6 might allow context-dependent attackers to execute
arbitrary code via a long pathname for a UNIX socket.

I can see how this might be a local issue, but how could an attacker potentially exploit this remotely?

EDIT:

Exact vulnerability: http://www.securityfocus.com/bid/47950

I'm not intimately familiar with the details of this vulnerability, and you didn't link to any further information about it, but just based upon the information provided here:

If your PHP code allows remote users to influence the contents of the Unix socket pathname (something that may be rare, but perhaps not completely implausible), then a malicious remote user may plausibly be able to use their influence on the pathname to exploit the vulnerability.