Is it possible to make a laptop useless to thieves? I was robbed...

That included my Linux notebook and my company's notebook. Both are encrypted.
Mine is encrypted with LVM over LUKS, using a passphrase to unlock the hard drive once the kernel has been started by the UEFI. But Secure Boot was disabled on the machine.

The company uses Bitlocker in Transparent Operation Mode. They claim the computer would not boot if the hardware configuration is changed, and it was an HP notebook, which has special extra security.

However, for the thief who's not much interested in data, all this is not very concerning. On my setup, a simple USB stick containing an OS would allow them to reinstall an OS on the drive and sell the notebook. If I had activated the Secure Boot and set a password on the BIOS, it could have been more complicated. But not impossible. Whatever the security layer, all that is needed is to unplug the CMOS battery for long enough to reset the BIOS settings, and all that extra layer is gone.

One could think that the company's computer is a bit more secure, but recent issues with a patch by Microsoft showed that actually a reset of the BIOS is still possible to get access to the computer (not necessarily the data).

My new laptop has Secure Boot and a TPM (ASUS UX433 if that matters, but my question is more generic). Is it possible to configure the UEFI and TPM so that a tampering of the configuration really locks the computer to those that doesn't have the necessary (recovery) secret?

(Let's consider for the question that really complicated manipulations such as unsoldering and replacing a complete component is outside of the scope. The issue here is rather that it is actually simple to reset the CMOS. On my desktop computer, it is even worse: moving a jumper at boot is enough, and it is well documented in the manual!)

First of all, my condolences for your loss! Hope you're alright.

If I understood correctly, your general concern is how to totally prevent further stolen device usage (and/or sale) by a criminal.

In this case, this question won't ever have any answer that would age well, because whenever your machine becomes unreachable physically, the only way to ensure no further damage is to nuke it from orbit.

And, in any case, even with the Apple's "Find My Mac" service (or with the "Find My Device" feature of Windows 10), you definitely wouldn't be able to prevent disassembling your laptop and selling the components as spare parts.

Note that the laptops deemed hard to resell in one piece, like Macbooks, are known to be easy to sell disassembled for pricey spare parts; therefore, there's no specific advantage to Macbooks here. (Apple constantly makes its devices harder and harder to fix and repair, so, like I said, this answer won't age well.)

Apart from that, depending on the particular laptop model and the hardware configuration, there may be different ways (with different level of reliability) to brick the device or its components. In general, those matters have something in common with re-flashing some of the built-in devices. If you're really concerned, you may even try to pick a laptop which is easy to kill with software; generally, googling might help you here.

There would hardly appear any initiative by the laptop vendors for making their devices easier to brick, because:

Making a device sustainable against physical access and damage is enormously costly and is effectively a never-ending arms race, as the DRM initiative quite clearly shows us;
It doesn't look like that's the incentive of the laptop vendors who won't really earn a lot in this battle (actually, probably quite vice versa).

The simplest way to brick a device in case of a thieft and an arbitrary laptop is probably to attach a yellow Post-it to your laptop with something on the lines of password: 123 on it, and to run a bricking script when the incorrect password is entered. This won't be reliable, and nothing would be, but this would probably work in most of the cases.


Should SHA-1 be used with RSA-OAEP? PKCS#1 defines SHA1 as a default hash function and all implementations support this hash function and the mask generation functions based on SHA1. In some implementations you can change the hash function used for OAEP Padding.

Can a SHA1 hash be used with encrypting random data (symmetric encryption keys) or should another hashing method be used?

Are there known attacks or vulnerabilities?

What are the advantages of other hash functions?

SHA-1, as a hash function, is known to be "slightly shaky". It is a 160-bit hash function (its output is a sequence of 160 bits); as such, it should offer 280 resistance to collisions, whereas it seems that its true resistance is closer to 261 or so.

However, OAEP does not ask much from its underlying hash function. It seems that collision resistance is not actually needed at all to ensure the security of the encryption system. See this article for details (it is a bit technical).

Bottom-line: we do not know of any attack that would work against RSA-OAEP by leveraging any weakness of SHA-1; we are not even sure whether such an attack can exist at all. In that sense, there is no known advantage, from a cryptographic point of view, in switching from SHA-1 to another hash function in the context of RSA-OAEP.

However, the current fashion is to shoot SHA-1 on sight and insist on switching to one of the SHA-2 functions (e.g. SHA-256 or SHA-512) systematically. Therefore, using SHA-256 is good for public relations, and will save you some time, because sticking to SHA-1 will require justifying yourself to a lot of people.

Note that SHA-256 has a larger output (256 bits), which imposes a lower limit on the size of the data that you will be able to encrypt. If using a 2048-bit RSA public key (256 bytes), the maximum message size with RSA-OAEP+SHA-1 will be 214 bytes (1712 bits), whereas it will be 190 bytes (1520 bits) for RSA-OAEP+SHA-256. If all you are encrypting are keys for symmetric encryption then this should not matter in practice.


How to block spammers from using my public email api I am working on a web application which allows users to share stuff on a web-page by clicking on an 'email to friend' link; similar to what extole is doing here http://www.american-giant.com/mens-heavyweight-full-zip-hooded-sweatshirt-product.html

on this page if you click on the email icon near "REFER & GET $15", you will see a pop-up where you can enter your own email and a friends email and can edit the subject of the email. When you click send the data is sent to the backend as json. They are using a plain simple url to do this i.e. http://refer.american-giant.com/v2/share.

The problem for me is that somehow spammers got hold of my url (can't mention here) and now they are using it to spam others by using some sort of a script. What I did is I placed a check in the backend api to block an ip if more than 5 share requests originate from it, but it seems that the spammers have a lots of ips (more than 30,000 from what I counted in my logs) so they are still able to send lots of email. One possible solution is to use a captcha to thwart the spamming script. But I am curious that how extole is doing it. They aren't using any captchas; and they are famous too, so it is unlikely that spammers don't know about their publicly accessible api. Can any one shed some light on this?

Note: 1. I am using a third party email service to send the emails. 2. Users are not required to sign in as this defeats the purpose of sharing on a simple website 3. Users can edit the subject and body, thus these are sent to the api call and this is what allows the spammers to abuse the api with their own stuff.

This is commonly known as a replay attack, when the attacker repeatedly transmits a legitimate message using a script. In this case, there are minor modifications to the message since the spammers change the email parameters in each message.

What you could do to prevent that is to implement a nonce. A nonce is a random string that is unique for every single request. The nonce should be generated in the back end and stored in a database. The nonce can then be embedded in a hidden field in the form. When the form is submitted, you check the nonce against the database. If it is valid, you process the request and remove the nonce from the database. By doing so, any future request using that some nonce will be invalid and thus you would prevent spammers from repeatedly re-issuing the same request.

However, a more sophisticated bot can bypass this system by reloading the page to obtain a new nonce for every replay.

Another method which is more intrusive is to implement a captcha. It will stop most spammers, but as usual, the most determined ones will theoretically still be able to write a script to bypass that as well.


Is it safe to expose these particular Firebase derived services? This question was found on SO. The answer there does not satisfactorily answer the question and since it is a security one and one that warrants a good technical explanation, I am reposting it here. Please let me know if this is not appropriate.

Following the Google developer instructions on implementing Firebase in my app, I notice that android lint complains.

The idea is that we have to implement two services which inherit from Firebase services:

public class MyFirebaseInstanceIDService extends FirebaseInstanceIdService { ... }

public class MyFirebaseMessagingService extends FirebaseMessagingService { ... }

and then register those services in the manifest. But, it's not quite perfect. In particular, these two recommended AndroidManifest.xml service entries do not contain any special permissions:

<service android:name=".MyFirebaseMessagingService">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT"/>
    </intent-filter>
</service>

<service android:name=".MyFirebaseInstanceIDService">
    <intent-filter>
        <action android:name="com.google.firebase.INSTANCE_ID_EVENT"/>
    </intent-filter>
</service>

and so the linter says:

  Exported services (services which either set exported=true or contain an intent-filter and do not specify exported=false) should define a permission that an entity must have in order to launch the service or bind to it. Without this, any application can use this service.

Should I just add this attribute to each service tag and be done with it

tools:ignore="ExportedService"

or is there a better approach in this situation? I mean, is it safe to expose these particular Firebase derived services like this?

This may solve your problem !

<service android:name=".MyFirebaseMessagingService"
 tools:ignore="ExportedService">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT"/>
    </intent-filter>
</service>

<service android:name=".MyFirebaseInstanceIDService"
 tools:ignore="ExportedService">
    <intent-filter>
        <action android:name="com.google.firebase.INSTANCE_ID_EVENT"/>
    </intent-filter>
</service>

android:exported

  This element sets whether the activity can be launched by components
  of other applications — "true" if it can be, and "false" if not. If
  "false", the activity can be launched only by components of the same
  application or applications with the same user ID. If you are using
  intent filters, you should not set this element "false". If you do so,
  and an app tries to call the activity, system throws an
  ActivityNotFoundException. Instead, you should prevent other apps from
  calling the activity by not setting intent filters for it.

  If you do not have intent filters, the default value for this element
  is "false". If you set the element "true", the activity is accessible
  to any app that knows its exact class name, but does not resolve when
  the system tries to match an implicit intent.

  This attribute is not the only way to limit an activity's exposure to
  other applications. You can also use a permission to limit the
  external entities that can invoke the activity (see the permission
  attribute).


Am I safe if I run untrusted applications inside a Virtual Machine I have some untrusted software. I plan to run them on a guest Windows 7 on my host Windows 8 OS using Oracle VirtualBox. In the worst case, will only my guest OS be affected? Can the hacker access information from my main OS? I don't expect the developers of this software to be skilled enough to do a "Virtual machine escape"

Escaping a virtual machine does not require skill. It only requires that:

A known vulnerability exists in the VM.
The attacker downloads and uses the exploit.

The Internet is a fabulous thing; it allows people to do a lot of things that they don't actually understand.

In any case, if you dutifully apply security updates to your VM solution (i.e. when VirtualBox tells you that a new version available, you don't tarry: you download and install that new version right away), then risks of a successful escape are slim. An "unskilled" attacker can only apply known exploits for known vulnerabilities, and the VM vendor also keeps track of such vulnerabilities. The relevant notion here is that of a Zero-day: an attack that the attacker knows of before everybody else; your assumption of "unskilled attacker" really means that the attackers cannot use zero-day vulnerabilities.

That being said, while you can assume that your VM is robust, there still are risks of mis-configuration. VM solutions, in particular VirtualBox, allow for "shortcuts" between the guest and the host. VirtualBox calls these guest additions. In particular, these allow for shared folders; but also mouse integration, clipboard access, 3D graphics fall-through... these are so many escape routes by which hostile guest code could impact the host.

An important point is that "guest additions" are drivers installed in the guest, which exercise extra functionalities offered by the VM. If you do not install the guest additions, then the escape hole may still be there, ready to be used. For instance, to prevent an hostile guest from accessing shared folders, you must disable it (or not enable it) from the VM settings.

Similarly, if you let the VM use the default network settings (NAT), then the hostile code can do network calls to other machines within your local network.

Therefore, you must review all VM settings to make sure that you deactivate all features that could allow for an escape or unwanted impact outside of the guest. In particular, take care of the network configuration (it is simpler if you deactivate it altogether, or use internal networking).


Would an encryption scheme that generates an extra key to be securely stored offsite be a safe backdoor? Let me be clear first and foremost: I do not think installing a backdoor in security algorithms is a good idea. They undermine the trust in the software and in the company that provides the service. That being said, I do agree that encryption provides a certain measure of protections for criminals and malicious actors against legitimate inquiries by authorities, which in turn can lead to dangerous situations.

I am also aware that cryptography is an INCREDIBLY complex subject matter, which should be left to the professionals with many years of experience. That said, in the below question, I will attempt to leave the creation of the cryptographic algorithm to the pros.

Now, the main question: Imagine a scheme like this:

A new algorithm is developed with equal security as the current standards. In effect, the algorithm that replaces AES would be just as hard to crack as AES if you do not know the key.
This algorithm generates one extra unique decryption key when used. This key is then sent via a secure channel (i.e. HTTPS or equivalent) to an NGO with the sole duty of guarding these keys. As soon as the tool gets confirmation that it is delivered, the tool securely deletes this key. The key is always different and strong enough that brute-forcing is not feasible. In addition, the encryption software will require a usable connection to the NGO via internet when the encryption is started to ensure that the key can be sent.
Once the key arrives, it is stored in an offline, airgapped database that can only be accessed in a single room with rigourous safety. In addition, the database and the machine it is located have tamper protection, similar to tamper protection on bank transports: any access that's out of the ordinary, like too many requests within a certain period or too many faulty requests, and the machine gets wiped.
When a legitimate law enforcement organization has need of a key to decrypt, it sends a formal request to the NGO. The NGO first analyzes the request based on the importance of the request. the NGO allows decryption when the suspect is strongly incriminated by other evidence, and only in the case of terrorism, murder or abuse of a minor (which are probably the only widely accepted reasons for public opinion).
If the NGO allows decryption, a trusted employee of the NGO goes to the room the database is accessible from and downloads the key on a read-only medium with similar tamper protection as the database. This medium is then handed over to the law enforcement organization that originally requested it. At this point, normal law enforcement will take over.

Assuming all of the above is feasible, what problems can arise from this system?

In addition to the points mentioned by Lucas Kauffman I would elaborate on point two:

  2.This algorithm generates one extra unique decryption key when used. This key is then sent via a secure channel (i.e. HTTPS or equivalent) to an NGO with the sole duty of guarding these keys. As soon as the tool gets confirmation that it is delivered, the tool securely deletes this key.

What would stop someone from implementing the algorithm but omitting the part where the second key gets sent to the NGO? Such an implementation would still output the normal key, making it completely compatible with other users of the cryptosystem.

The only way to do this would be to make the algorithm closed source and safeguard its implementation from reverse engineering through intense obfuscation. But nobody in the security community who isn't completely out of their mind would ever trust an algorithm which isn't open to public peer review.

Also keep in mind that the people law enforcement wants to find are those who are already breaking the law. Criminals would have no qualms to encrypt their information with any of the other cryptosystems which are currently available, even when doing so is declared illegal. Unless, of course, the punishment for using non-government-approved encryption software is just as harsh as the punishment for terrorism, murder or abuse of a minor, but that would be hard to justify IMO.

That means you would create an expensive key escrow infrastructure and put a legal shackle on millions of citizens and companies regarding the software they are allowed to use without affecting any of the people you actually want to affect.


Could a home PC get hijacked if the said PC is in a private network, with dynamic IP and behind a router that doesn't have ports forwarded? I've been paranoid about this idea for a while, that I'll be an idiot, lose control of myself, and turn off my precious firewall. I'm scared about my password as well. I'm worried a hacker will hack my Linux PC? Under these conditions, is it even possible? I know about offline hacking, but that doesn't matter for me usually, since I usually have my lappy at home.

If your question really is "is it even possible?" then the answer is yes.

Your primary concern with that setup is client-side attacks.

If malware infects your PC, it could start a reverse shell. Your firewall can combat this with egress filtering, but it is tricky nonetheless. Even ICMP may be used for reverse shell communication, or the traffic may be encrypted or obfuscated. Or the malware may simply exfiltrate your data to a remote server.

You may unwittingly install this malware yourself. Software you already use like a browser or browser plugin may have a vulnerability that could be exploited, e.g. drive-by-downloads.

Defences are numerous. You can keep your software up to date, only install trusted software and use your judgment when browsing. Furthermore, you can run anti-virus software. Of course, there are many, many measures you can take.

In order to decide what action to take, consider the risks and your threat model. Ask questions like:

What's at stake?
What level of risk am I comfortable with?
Am I defending against random or targeted attacks, by whom?


Can smartphone spyware work even if there is no data connection? I am using an Android phone. Is it possible for spyware to transmit data even when I don't have any internet plan/connection? Can it use some other way, say, cellular network etc.?

EDIT1:
SMS and calls in my mobile are chargeable, so if any spying software uses these ways to send call recordings or surrounding recordings or any data, I should be able to do find out. Would your reply change in this scenario?

EDIT2:
I suspect my roommate has installed spyware in my Android phone. He is not a hacker. So, he has to rely on spywares available out there, free or paid. So are there such spywares available in market, which can work without internet connection?

Yes, it's possible. A malware can simply utilize the SMS functionality in your phone to transmit formatted data from and to your phone. Heck, it might even use DTMF.

Update: After your edits, your question turned from acceptable to really bad. In any case, the most plausible scenario here is via Bluetooth.

However, I think you're just very paranoid and/or you have some troubles with your roommate. Solving this issues can't be done with hacking/counter-hacking.


NIDS sensors placement in the network of an organization I am studying IDPs and I would like to know where network-based IDPS sensors can be placed in the segments of the network of the university organization. I am looking forward to analyse different scenarios of sensor placements and the benefits for each one. Can anyone give a suggestion? Thanks in advance!

It really depends on the network layout, and what you want to monitor.
Is the inbound or outbound traffic more interesting to you?

For bigger organizations, that probably have several offices, and server/infrastructure networks it makes sense to have dedicated sensors with a network specific configuration.

Traditional NIDS (Passive Mode)

I'd put it on a mirror port of the core of that network segment. Make sure that your hardware (NICs, switches) can handle that. For sensor reliability I would look into getting two network cards and setup bonding.

Traditional NID(P)S (In-line Mode)

The traditional setup I often come across is that the sensor itself acts as a router and handles all the traffic coming in and out. So it would be the second hop on the network for outbound connectivity, 2nd to last for inbound. There is a lot of design considerations that has to be done here to not compromise the reliability (additional packet loss), availability of the network, such as a fail-over when the sensor goes down, unintentionally or during maintenance.

This one is hard to scale, and you have to take software and hardware configuration very seriously, only enable features and rules that applies to your threat model.

A good alternative is to go for the passive route and write an agent that triggers action on certain events, such as connecting to the firewall/router/DNS server etc, and applying rules. This way you would get the same effect with less risk of compromising the availability of your network. There is some (old) software known as SnortSAM that may serve as a good example on how to achieve this.

Good reads

Emerging Threats - SnortSAM summary

SANS Institute - How to place IDS sensor in redundant networks

Strategic Sensor Placement for Intrusion Detection in Network-Based_IDS

I hope you find this helpful, feel free to ask any follow up questions. I'm very interested and trying to keep up within the Network Security Monitoring field myself, so the pleasure is mine :)


Why is the subject's public key not used for encryption in SSL? As far as I understand the workings of SSL - the client generates the pre-master secret and sends it to the server encrypted using the server's public key. Now, both parties perform some steps to generate the master secret and the session key. This session key is used for symmetric encryption from now on (e.g. communication in HTTPS).

My question is, given that we are sending the public key of the server to the client - and it is being authenticated and verified as well by using digital signatures of the Certificate Authorities - why don't we just use this public key for encryption?

Is it because asymmetric encryption is less efficient? Is this a trade-off between a one time less efficient operation (sending of pre-master secret and generating master secret) during handshake rather than multiple time asymmetric encryption? Any idea?

Clarification: My question doesn't suggest using asymmetric encryption for session keys instead i was asking about no session keys altogether, i.e. just use the public key sent to the client for encryption. See my answer to get what my question was.

There are several reasons for this. The main one is performance: asymmetrical encryption is SLOW.

In addition, many such algorythm have a fixed maximum size for the data they can encrypt (RSA, as defined in PKCS#1, has a maximum of 245 bytes for commonly used key size).

Also, you cannot implement forward security this way: anyone obtaining a copy of the private key will be able to decrypt any past message.

Finally, there is simply the fact that it is more flexible to negotiate the encryption scheme that to force it to use the one that was used to sign the certificate.


Risk of specific changes to the "Trusted" security zone Our EDI VAN provides software to transmit sensitive customer and business data between our ERP and their website. This software requires that I add several URLs (including one plain HTTP) to the "Trusted" security zone on Windows 10. It also requires that I enable "Display mixed content", "Access data sources across domains", and "Don't prompt for client certificate selection when only one certificate exists" for that zone.

What are the security implications of these changes? Are any of them clearly unnecessary security risks that I should warn my managers about? I already have a low opinion of our EDI VAN, so my bias may be fueling my suspicion.

An EDI VAN is a secure outsourced network where EDI documents can be exchanged between business partners. Your company is provided with a "mailbox" or alternate means from which EDI documents are sent and received, similar to traditional paper based mail (snail mail). The “value added” part of the mailbox are often services like mail notifications, inspect, authentication, and validating the message.  Messages should be tracked and recorded for auditing purposes, as well as other services available through VANs, such as backup and recovery, mapping, compliance and more.

For everything to be in order you must have high trust in the EDI VAN provider and / or be able to make sure it handles security in a sufficiently good manner. Otherwise, you may end up with something being compromised.

Setting everything as "trusted" is definitely not a good security practice. That would practically allow that software to do anything and transmit anything across your infrastructure (given the other settings).

Instead, you should ask the provider what ports or other limited settings are specifically needed to enable correct communication between the software and its destinations. Mixed content means the connection is not required to be secure, which is a big risk (you will transmit data that is not encrypted).

Therefore, you should definitely determine how trusted that provider is and warn your company in regard to security.


Single sign-on models for a mixed environment I'm not entirely sure if this is the right site for this, but I'll give it a shot.

Basically, I'm looking into different ways of setting up a single sign-on service for an existing corporate environment. Within this environment, there's anything from old legacy systems to new web services, all running on different platforms.

I'm not really looking for specific solutions, as much as high-level approaches/strategies. I found a great writeup here, but it's from 1997, so it's not exactly up-to-date. If you know of a similar, but newer, paper, please post a link to it. If not, I would be eternally grateful if you were able to contribute with information on more modern models that haven't yet been brought up. If you have implemented such a system in a similar environment, I would be very interested to hear how you went about it, and why you chose that specific strategy.

If this question would fit better on another site, please leave a comment and I'll post it there instead.

Thanks!

If you try to implement a SSO system you have to distinguish two fundamental different solutions:

Server side SSO: in this approach every server application must use a central authentication system like a LDAP or it must trust some kind of ticket like in Kerberos or SAML or the authentication must be done with some kind of certificate.
Client side SSO: in this approach you have to use some kind of client software which automates the authentication process.

The advantage of Server side SSO is, that it can be implemented in a way that it gives you more security like a simple password authentication. But every server must be able to join the SSO system. In some cases this is technological complicated (SAML for graphical user interfaces other than the web browsers) and for legacy applications this may be a show stopper.

In those situations you have to use the client side SSO where some kind of software handles the authentication by sending login and password credentials to the input fields of the legacy application. This approach has a phishing weakness, because it is difficult for the client to trust the server, because a login window can only be identified by some kind of window title which can be easily hacked on every windowing system.

Rule of thumb: SSO in heterogeneous networks is complicated and very expensive.


Firefox ESR storing passwords during session? Can anyone else reproduce this while having Firefox NEVER remember passwords:

open Firefox ESR
log into Facebook
x out of the Facebook tab
open a new tab
click on the Facebook thumbnail
does it log you in automatically? (cause it does me!!!)

I have my Firefox security settings to NEVER remember passwords for sites, and for Facebook I always just close the option to click on my face to log in.

In my previous OS (Ubuntu 16.4.3) this behaviour wasn't happening (same browser) And if I close the whole Firefox program and open it again, it won't log in automatically.

I'm a security n00b so maybe someone just needs to explain what's happening behind the scenes here?

I have my Firefox security settings to NEVER remember passwords for sites

This just means that Firefox doesn't save the password itself.
Once you're logged in, Firefox stores a session cookie to remember you as a Facebook user without needing you to re-enter the password. This cookie doesn't automatically expire once you close the tab. So although your password value won't be remembered, your session will be.

If you want Firefox to forget about your Facebook session once you close the window, you can use a private browsing window. (Ctrl + Shift + P)

If you want Firefox to forget about your Facebook session once you quit the browser, you can change that in the settings. Go to Preferences > Privacy & Security > History. Choose Use custom setting for history and at Accept cookies from websites set Keep until I close Firefox:

(Image source)


Prevention of devices using same OTP secret I have a requirement of OTP applications on mobile devices not sharing the same secret (even if the mobile devices are owned by the same user). A single secret must be present in a single device.

Open source applications that implement OTP (like Google Authenticator and FreeOTP) do not satisfies my requirement: the secret is not device unique, due the fact that I can scan the QR-Code with more than one device and backend never will know about that. I think it is not something related with the application itself, but with the RFC 4226 that not specifies this requirement.

So I thought about a process to mitigate the risk of users using OTP secret in more than one device (need internet connection - not a requirement be offline). The steps:

App generate unique secret protection key on first execution
App send the secret protection key to the server
Server generate a unique secret for app
Server encrypt the secret using the secret protection key from the app and return the blob to the app
App decrypt the info using the generated key and starts to generate OTPs
Both encrypted secret and secret protection key would be storaged on app

I know that this approach is not tamper-proof and the secret could be restored from storage but would be more difficult.

About all explained here, my questions are:

Would be a good approach exchange OTP's secret through web, even if it is protect by TLS?
Is the unique secret protection adding security or a flaw to the process?
Would be possible to achieve a similar result in a offline sync?
Is there open source frameworks to achieve a better protection of the secret key (i.e. not exposing directly to user, like QR-Code does)?

If you're designing your own authentication app; instead of scanning the OTP token, scan an authorization token that will then be used to retrieve the OTP from a server. The server can then be setup to only release the token once. Bundle certificate pinning into your application, and you're good to too.

The flow would look like this.

User requests OTP token from website
User opens app and scans QR code, which contains one time use API key
App then contacts server, verifies certificate with pinned cert
App submits one time use API key, server returns OTP token and marks the API key as defunct.


Browser as Honey-Pot, is there? I'm watching all this movement around Metasploit project, the great number of different exploitation plugins, and thousands of exploit packs. Now, it is real truth, anyone could configure his own black-hole in the network. Moreover, any admin of any services in the network could attack me just for fun, while I'm reading an article on his page.

I know, there is only one exception, it is: up-to-date system, up-to-date browser, javascript disabled by default, and without any flash players. However, I can see such option, to verify my services for fair-play. It is Exploitable Browser ala Honey-Pot.

The same way Metasploit collects holes in different browsers, this Honey-Browser could collect holes to keep up an alert-system. I know FireFox and Chromium are Open-Source and would be the base for such Honey-Browser. Such an alert-system with all known exploits could detect any Http/Https/Whatelse activity against my browser as an Network-IDS.

Is there any thing what I'm talking about? For example, I know about the Mantra Security Framework. There are hundreds of attack-plugins or extensions, but no one to defend.

For example,

How does an exploit-pack work? It is a pack of exploits, and all exploits attack browser whether it is IE, FF, or Chrome, one by one, in sequence.
Once any of the exploits was detected by signature, the next part of session could be written in a kind of sandbox to protect the browser.

Such a plugin could be a nice shield for browser.

If I understood well your question's title, and if you are looking for opensource stuff:

  I know, FireFox and Chromium are Open-Source and would be the base for
  such Honey-Browser.

then you can use, for instance, Thug which is a browser emulator written in Python automatically interacts with the malicious website to check its exploits.

There are also other Thug equivalent tools.

Note that the attacks upon browsers are mainly done using malicious JavaScript code performing especially drive-by download attacks. One of the solutions I implemented myself to detect compromised websites intended to target clients/visitors is based on a honeypot that uses several virtual machines on which different operating systems and browsers are running -without antivirus intalled- and a program that checks the health of the operating systems and browsers during and after the automatic navigation of all the pages of a given URL.


Is it safe to play third-party games on Facebook? While using FB, I observed many friends playing games such as "Which character you are from some particular web series or movie?" I think this can be dangerous because when I clicked on CLICK TO PLAY button of one of those games, I opened the privacy policy page of that product.ON this page, it is mentioned that some third parties advertisers associated with that product can collect our IP address.

Then, I searched on internet what someone can do with my ip address and got to know that our account can be hacked easily if someone knows our IP Address. So, I think it can be dangerous to play these games on FB. So, I want to ask the experts present here whether it is a matter of concern for all people who just click on and then play these games for fun?

So the primary concern of Facebook games is privacy. If you play a Facebook game, there's a good chance that your information is being shared with somebody, who will sell it to somebody else who will use it to target you with specific advertisements.

But let me remind you that you're using Facebook.

The IP address can go in there as well. IP addresses don't always provide an accurate location, and they don't always stay the same, but they can provide one extra piece of signal for the algorithms.

As far as security, your IP address is already being scanned every day by potential attackers. This is called the background noise of the Internet. Most home users don't have anything for the scanners to find, unless they're exposing a media server or file server to the Internet. If you do that, make sure everything is up to date and that you use strong passwords. Unless you've got some opening like that, DoS is about the only thing an attacker would do with your IP address.

When we come to Facebook games, though, consider this: Why would a gaming company scan your IP address or do a DoS just because you play their game?


openssl: recover key and IV by passphrase A large amount of files were encrypted by

    openssl enc -aes-256-cbc -pass pass:MYPASSWORD

Openssl should derive key+IV from passphrase. I'd like to know key+IV equivalent of that MYPASSWORD. Is that possible?

I know MYPASSWORD. I could decrypt and then re-encrypt with new known key+IV with:

    openssl enc -d -aes-256-cbc -pass pass:MYPASSWORD
    openssl enc -aes-256-cbc -K MYKEY -IV MYIV

But the problem is that the amount of data is quite large.

Usage of the openssl enc command-line option is described there. Below, I will answer your question, but don't forget to have a look at the last part of my text, where I take a look at what happens under the hood. It is instructive.

OpenSSL uses a salted key derivation algorithm. The salt is a piece of random bytes generated when encrypting, stored in the file header; upon decryption, the salt is retrieved from the header, and the key and IV are re-computed from the provided password and salt.

At the command-line, you can use the -P option (uppercase P) to print the salt, key and IV, and then exit. You can also use the -p (lowercase P) to print the salt, key and IV, and then proceed with the encryption. First try this:

openssl enc -aes-256-cbc -pass pass:MYPASSWORD -P

If you run this command several times, you will notice each invocation returns different values ! That's because, in the absence of the -d flag, openssl enc does encryption and generates a random salt each time. Since the salt varies, so do the key and IV. Thus, the -P flag is not very useful when encrypting; the -p flag, however, can be used. Let's try again; this time, we have the file foo_clear which we want to encrypt into foo_enc. Let's run this:

openssl enc -aes-256-cbc -pass pass:MYPASSWORD -p -in foo_clear -out foo_enc

This command will encrypt the file (thus creating foo_enc) and print out something like this:

salt=A68D6E406A087F05
key=E7C8836AD32C688444E3928F69F046715F8B33AF2E52A6E67A626B586DE8024E
iv=B9F128D827203729BE52A834CC0890B7

These values are the salt, key and IV actually used to encrypt the file.

If I want to get them back afterwards, I can use the -P flag in conjunction with the -d flag:

openssl enc -aes-256-cbc -pass pass:MYPASSWORD -d -P -in foo_enc

which will print the same salt, key and IV as above, every time. How so? That's because this time we are decrypting, so the header of foo_enc is read, and the salt retrieved. For a given salt value, derivation of the password into key and IV is deterministic.

Moreover, this key-and-IV retrieval is fast, even if the file is very long, because the -P flag prevents actual decryption; it reads the header, but stops there.

Alternatively, you can specify the salt value with the -S flag, or de-activate the salt altogether with -nosalt. Unsalted encryption is not recommended at all because it may allow speeding up password cracking with pre-computed tables (the same password always yields the same key and IV). If you provide the salt value, then you become responsible for generating proper salts, i.e. trying to make them as unique as possible (in practice, you have to produce them randomly). It is preferable to let openssl handle that, since there is ample room for silent failures ("silent" meaning "weak and crackable, but the code still works so you do not detect the problem during your tests").

The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:

magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f
salt value (8 bytes)

Hence a fixed 16-byte header, beginning with the ASCII encoding of the string Salted__, followed by the salt itself. That's all! No indication of the encryption algorithm; you are supposed to track that yourself.

The process by which the password and salt are turned into the key and IV is un-documented, but the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function (KDF) with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented -md flag (!!!); the "iteration count" is set by the enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.

This is quite weak! Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to "try" several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use openssl enc, make sure your password has very high entropy! (i.e. higher than usually recommended; aim for 80 bits, at least). Or, preferably, don't use it at all; instead, go for something more robust (GnuPG, when doing symmetric encryption for a password, uses a stronger KDF with many iterations of the underlying hash function).


Monitor traffic that is going through my router I want to monitor the HTTP traffic of all clients connected via wifi to my wireless router. I want to capture the traffic with my Notebook which is also wirelessly connected to the router.

Hardware & Software setup:

  Capturing with: Intel 7260 Wireless, Ubuntu 14, Wireshark &
  Aircrack-ng

  Client to monitor: Android Smartphone

  Router: Wireless Router 2.4GHz 802.11n, fixed wifi channel

  //

  What I did til now (without any success):

  sudo airmon-ng start wlan0

  // mon0 is started successfully

  gksu wireshark

  // warns me that I should not run it in root, but I want to see that
  this works first, I'll take care of security later

  In Edit-> Preferences -> Protocols -> IEEE802.11:

  Reassemble fragmented 802.11 datagrams: true

  Ignore vendor-specific HT elements: false

  Call subdissector for retransmitted 802.11 frames: true

  Assume packets have FCS: false

  Ignore the Protection bit: Yes with IV

  Enable Decryption: true

  Decryption Keys: wpa-pwd, mywlanpassword:myrouterssid

In the capture options:

  Capture Interface: mon0

  promiscuous mode: true

  snaplen: default

  buffer: 2mib

  monitor mode: disabled

  // I also tried with true but it doesn't seem to make a difference as
  due to usage of airmon-ng I suppose that monitoring is already enabled

  Display options: all true

  Name resolution: all false

After starting the capture I disable WIFI on my Smartphone and reenable it.
I can see that some MDNS packets are captured and a one time IGMPv2. But when I browse on the phone (normal http sites, no network compression activated) or use any apps that would connect with online service, I don't see any HTTP or TCP traffic for the Smartphone. If I start the browser on my notebook I see all browser traffic (HTTP requests, responses, files etc).

Am I missing something?

You said you wanted to monitor the HTTP traffic. Not all network traffic (e.g., DNS, SSH, etc.). You didn't say whether it was passive or active monitoring. You haven't stated whether the systems being monitored are under your control or not. (I.e., can you make a configuration change on them?). If you only want all the HTTP/HTTPS traffic, and you have the ability to configure the devices a bit, then use a proxy. Set up Burp or WebScarab or Charles proxy on your laptop. Make sure it is listening on your regular network IP address (not just localhost, which is the default). Then, you need to get all the various devices to use your laptop as their HTTP proxy. Caveat: if your laptop is not there or if the proxy program is not running, the devices will not be able to use any HTTP/HTTPS services.

Now, to get devices routing their HTTP through your proxy, you have 2 choices: manually configure them or try to get your network to give out your proxy as information with the DHCP leases.

To manually configure a client, go into its settings and look for the proxy setting. Enter the IP address of your laptop and the port number that it is listening on. (e.g., 192.168.1.10:8080). All HTTP traffic from that device (if you do it at the OS level) or from that browser (if you only configure the web browser) will now route through your laptop.

Depending on how handy you are with your DHCP server, you can use information like this: https://blog.x-way.org/Networking/2012/12/30/Automatic-Proxy-Configuration-via-DHCP.html to cause networking clients to automatically receive the information telling them to use your proxy whenever they connect to the network.

This will give you full ability to not only monitor but to even tamper with the data passing out of whatever device uses your proxy. Remember that TLS connections will start issuing warnings (because your laptop is not truly the end system, and the certificate will be bogus). Some mobile apps (e.g., banking apps) may refuse to run because they can detect the man-in-the-middle.

If you're only interested in HTTP/HTTPS traffic, and you can configure the devices, then this is a pretty good way to do it.


DOMXSS - Is Input Field Content an Attack Vector? A typical example for DOMXSS is that vulnerable code carelessly processes the part after the hash mark as in https://www.example.org/path/param1=val1&...#PAYLOAD_HERE without validation. For example, the string could be assigned via innerHTML to some DOM element. (Or one of many jQuery methods such as html(), before(), prepend() and several more.)

Now, comparing to Reflected XSS, where URL parameters, form parameters or other parameters (e.g. as part of a JSON-formatted body) may contain the payload, these are often input that can be entered into form fields.  For instance, the URL https://www.example.org/?search=query is virtually always the result of the user entering query into a search field. (At least, that's the intended use case.) Now, it is possible to bypass the process of entering the query string into the form field by submitting the query-URL directly. Similar for POST, albeit this is a bit more complex (which is not the point here; for the sake of discussion I take it for granted that it is possible).

Thus, if the application is vulnerable to Reflected XSS through an input field, virtually always it is possible to craft a malicious URL that, when clicked, exploits the vulnerability.

However, it appears to me that this does not hold for DOMXSS. If an application had an input field that carelessly uses its content to update some DOM element without any validation whatsoever, then clearly one could inject arbitrary scripts into the DOM. Consider for instance a hypothetical app that has an input field with id input_field and a target element such as a p, div, span or whatever with id target, and JavaScript code with a line like this:

document.getElementById("target").innerHTML =
    document.getElementById("input_field").value;

Here the content of the input field is not sent forth and back as would be for Reflected XSS.

The question for me is: Could that be exploited by an attacker (without exploiting a preceding XSS attack)?

That would be hard to exploit without combining it with another vulnerability. How would the exploit code get into the input? I suppose combining it with UI-redressing or something like that could have worked, but I dont see any clear way of exploiting it. Could be seen as a self-XSS.


Securing a Laptop from a Foreign Intelligence Agency What would be the best practices for securing a single-purpose Windows laptop against a determined foreign intelligence agency from tampering with data on the machine?  The machine would be used several times per year by two individuals who independently verify each other's work and print the results.  The machine would not need access to the Internet, but when in use would need to be connected to a printer.

Some of the things I've thought of so far:

Use a laptop with a TPM module.
Encrypt the drive.
Disable the NIC.
Disable the USB ports.
Use a strong password on the machine.
Physically store the machine in a locked safe while not in use.
When used, transport the laptop using two different security personnel.
While out of the safe, the laptop would always be attended by at least two individuals.
The laptop would be a fresh install of windows with no 3rd party software installed on it (not sure about updates in a situation like this).
The custom software on the computer, when run, would compute the hash of it's binary files (e.g. exe and dll) and generate a code that the user would compare to a known value to detect tampering.

Any changes or additions?

I am assuming that there is some reason you can't use a dozen different laptops in multiple countries or jurisdictions doing the same activities to provide extremely high redundancy (as pointed out in a comment on the question). If any of the laptops have results that differ, at least one of them can be assumed compromised and incident response can kick in. The number of independent computations could be scaled to match your requirements. This of course assumes that the activity done on the laptop is deterministic and that there is only one "right answer", allowing any honest and uncompromised party to come up with the exact same results.
Assuming you need to maximize integrity for a single laptop, your plans seem solid. I would however make a few changes and additions to your proposal:

Switch to Linux so vulnerabilities are not given to nation states before being patched.

Require that those who handle the laptop provide a comprehensive chain of custody.

Don't just disable unused peripherals, cover them with anti-tamper epoxy resin.

Disallow using any untrusted peripherals. Even VGA/HDMI can be vulnerable!

Do not use custom software to hash binaries. Secure software already exists.

Require smartcards to identify to the device. Shamir's Secret Sharing is useful.

Mind EMSEC by working in a secure area or using shielded devices.

Mutual authentication
It's important that the users of the computer are able to authenticate to it. Normally, it is the user who authenticates themselves to the computer, but in high-risk environments, it may be necessary for the computer to authenticate itself to the user as well. This can be done using various experimental mutual authentication technologies like MARK, which uses an active USB device.
Each person who uses the laptop should be using a smartcard as part of the authentication process. This card should be kept physically secured. Depending on your threat model, it may even need to be hidden while on the person. It is possible to use secret sharing algorithms to ensure that a threshold of authorized individuals are required to fully authenticate themselves to the system. This could be set up such that, say, five people have keys, and at least three of them must use their keys at the same time to authenticate. This will protect from up to two people going rogue while still allowing authentication even if up to two people lose access. The exact parameters, including the weight each person holds, can be tweaked at will to match your threat model.
Firmware and software integrity
Assuming that the TPM is used for SRTM, it will be able to detect any modifications to the bootloader and related software, as well as certain firmware and even the BIOS itself, assuming the BIOS contains a read-only boot block (the CRTM). If encryption is also used, this provides a greater level of tamper resistance. Unfortunately, most block modes are malleable (plaintext can be intelligently modified even without knowing the key), so it is necessary to have the OS verify all components of the system even after boot, for example by using IMA, the Integrity Measurement Architecture, available on Linux.* IMA may reduce I/O performance by breaking demand paging.
Often, the NIC or USB controller will still be active even if the operating system is ignoring them. A vulnerable BIOS could be compromised through such interfaces. Most systems' BIOS are horribly insecure and allow both local attackers (malicious processes running on the machine) and physical attackers to gain higher privileges. You can do some limited analysis of BIOS security by using the CHIPSEC framework. This framework is designed to verify certain security attributes for a platform's firmware. Important information is available on their wiki. This framework is designed primarily for BIOS vendors and OEMs who wish to look for vulnerabilities that allow the firmware to be overwritten at runtime despite standard software write locks put in place.
* I have little experience with Windows, but I believe it is possible to support such integrity with that operating system. However, it is important to remember that nation states often get prior notice to vulnerabilities in Windows before they are disclosed publicly or even patched. For this reason, Windows is likely not the best platform to be using.
Physical attacks
If someone gains unrestricted physical access to a laptop, it is not your laptop anymore. There are a number of different physical attacks that one can carry out. Some of them can be mitigated, whereas others would require you physically modify your laptop to mitigate:

DMA attacks - Many peripherals support direct memory access, both internal and external. External GPUs, Thunderbolt, Firewire, and internal PCI and PCIe ports all support DMA. This support allows anyone who connects a device to these interfaces to perform reads and writes to arbitrary memory locations. The mitigation requires your laptop have a proper DMAR table and a modern IOMMU (VT-d2 for Intel). You must also boot with the IOMMU enabled, e.g. by passing intel_iommu=on to the boot command line on Linux.

Cold boot attacks - Passive retrieval of memory is possible by removing the memory modules and placing them in a different device to read. This allows them to read sensitive data, but does not allow tampering, as it is a highly invasive procedure that necessarily requires the target machine to be shut down. Full memory encryption mitigates this, and the use of ECC memory can also complicate the attack (ECC typically requires the memory modules be reset to a known state during initialization).
Cold boot attacks only compromise confidentiality of data in memory, not integrity. If integrity is all you need, then cold boot attacks are not relevant to your threat model.

JTAG - JTAG is a debug protocol and interface on the motherboard for many devices from ones as simple as CPLDs to ones as complicated as enterprise x86 processors. Plugging a JTAG probe into the interface allows complete, absolute control of the chipset, allowing them to halt the machine, read and write registers and memory, and interact with peripherals. If an attacker manages to connect to the target using JTAG, all bets are off. You need to ensure the device either does not have a JTAG header, or that the header has been destroyed or coated with epoxy.

Additionally, physical attacks may involve connecting to a vulnerable peripheral. Nearly everything can be vulnerable, even VGA and HDMI can be exploited by abusing things like EDID. USB devices may support DCI, and a few fail to disable it in their BIOS. These systems can see USB abused to pass JTAG commands without opening the machine and connecting a probe to the motherboard. Networking interfaces can be vulnerable, and vulnerabilities have been found. Sometimes it is not enough to simply disable the ports in software, as various DCI vulnerabilities have shown. You may need to physically block the ports using a strong epoxy resin.
Physical tamper evidence
There are several ways to detect physical tampering with a device. All of these methods require you take a high-resolution photograph of the machine at multiple angles so that you can compare them against your actual machine at any time that you suspect it may have been modified. Any solution for detecting physical tampering will be visible as a discrepancy between the photo and the actual device. The general idea is to place something in sensitive areas of the device which will be visibly broken or moved if that area is intruded upon. A few examples:

Security tape - The standard way is to use tamper-evident security tape. These are stickers or strips of tape that leave unique marks on the surface if they are removed, and which are designed to be resistant to steam or other techniques used to gently pull them off. These can get quite expensive, supporting features such as holographic labels and unique marks.

Epoxy resin - Epoxy is a strong glue-like substance that sets in and cannot be easily removed without destroying anything that it coats. There are many types of epoxy of differing strengths and properties. You would want one which is designed to resist tampering (e.g. designed not to easily be removed with solvents or fine drills), as well as non-conductive and non-thermally insulating, to prevent shorts and overheating. When used correctly, epoxy resin can both resist physical attacks (tamper-resistance), and make successful attacks visible (tamper-evidence).

Nail polish - Nail polish that has a lot of glitters is actually very, very useful as a form of a ghetto security seal. When placed around the joints of a system, it becomes extremely difficult to open it without moving the glitter. Once the glitter is disturbed, it becomes nearly impossible to place it back exactly as it was, leaving valuable evidence behind for the defender.

Emission security (EMSEC)
When you have nation states as an adversary, covert monitoring of electromagnetic signals is a very real possibility. These signals can be used to read keystrokes from 20 meters away or more. It can be used to perform Van Eck Phreaking to view computer displays through walls. It can be used to break encryption by listening to the processor as it works on cryptographic material. Mitigating this requires a large, secure perimeter (several hundred meters), or using a TEMPEST-certified device. These certifications do come from the government (e.g. NATO SDIP-27 and USA NSTISSAM), but they allow devices to be certified as immune dangerous to EMI/RFI leakage.
Unless you are in a secure, shielded room or have a large and secure perimeter, you must make sure your devices are shielded while they are being used for sensitive operations. While not strictly related to electromagnetism, it is also important to use the device in a room with no windows, just as high-security government facilities do. This prevents audio (both from conversations, and from the keyboard) from being recovered using laser microphones. If your budget or circumstances make any of this impossible, you must rely on standard OPSEC to prevent your adversary from getting close enough at the critical time to record sensitive emissions.


Disabling SSL v2 and weak ciphers on client PC's Is it a requirement to also disable SSL v2 and weak ciphers on client PC's? I have seen quite a few posts for disabling them on servers, but nothing about a regular client PC, say, running Windows XP or Windows 7.

You might want to read the three excellent answers to the question How does SSL work, where it's all explained, but in a nutshell, the server will select which ciphersuite (and compression) to use during the SSL/TLS handshake, after it receives supported ciphersuites from the client. Since you removed support of certain weak ciphersuites on your server end, they can't be selected for the SSL/TLS transport encryption, even if they are supported on the client.

Edit to add: As has @DavidHoelzer mentioned in the comment below, not all websites have yet moved to TLS, and you don't want to be punishing your users for that. Even the weaker ciphersuites are better than none at all, if you remove support for them on clients. Your users would most likely still use those websites, even if they couldn't connect to the host using HTTPS, and would end up opting for HTTP, exposing them to many more threats in the process. In short - I wouldn't recommend it.


Is it inconsistent to tell users to "not click on password links in email", and requiring clicks on "forgot password" links? On one hand, IT Security shops have been telling users to not click on links in email because they can do damage to your computer, or phish your personal information.  Many of those issues are outlined in the link below:

What malicious things can happen when clicking on links in email?

Then again most of those same shops conflict with their own advice and require their use for certain situations such as:

email-based verification & registration
email-based password reset link

Since inconsistent guidance never bodes well for security, I think that there should be a pattern, practice, or technology that will allow for better security and a consistent message.

Question:

What are our options in getting rid of this conflicting advice regarding links in email?
What patterns, practices or technologies should be adopted?

You mention a very specific subset if phishing attacks related to fake password reset emails.

Assumption 1: you already have controls in place to reduce these inbound emails based on whitelists, SPF, whatever.

Assumption 2: you have controls in place to limit outbound website visits by your users to malicious sites.

Assumption 3: you are asking simply for a pattern (rule) to give to your users to help them decide when they should click a password reset link in an email vs being suspicious and not clicking... If not a pattern for users, then something more technical/automated.

Easy rule of thumb for users : Don't click password reset links in emails unless you are expecting to receive such an email.

If you receive an unsolicited password reset email, ignore/report it to IT.  If you request a password reset from SaaS application XYZ and you receive an email from application XYZ in the next few minutes, it is probably legit.


Break out or bypass php functions I'm currently doing an online CTF and I have LFI an can read the source code of the upload function. In there I see the following line:
shell_exec('rm -rf ' . directory/ . '*.p*');

So anytime I upload a .php file, it gets deleted.
Is there a way to break out the code so the remove of *.p* file never happens or can I execute .php files without having the file extension being .php?

Solution: upload the file as hidden, for example: .shell.php and call the file directly.


Is the Struts2 token interceptor a viable way of protecting against CSRF? I'm currently implementing the default Struts2 token interceptor on all of our forms as a measure against CSRF (making a user unknowingly execute an action on our product by visiting another website and triggering malicious javascript).

Some technical specs on the token: when used, it creates 2 hidden fields on the form: a field called struts.token.name containing the name of the token, and a field with the name of the token and a randomly generated token. This token is also saved in the session, and the name of the token is stated in the configuration page. We configure each page token to have a unique name based on the name of the page and the ID of the token, if available. This is so a user can have 2 edit pages of the same type open, for example to copy over certain attributes from one object to the next.

When the page is submitted, a check is made whether the page contains a token of the name stated in the configuration page. If not, the page throws an error. If the token is present, a check is made whether the token is the same as the one stored in the session. If not, the page throws an error. If both checks pass, the page proceeds as normal.

My main concern is that a malicious page uses Javascript to retrieve the original page, append it to their own page and retrieve the relevant token fields to append them to their own request. Is that a legitimate concern?

If your application has CORS(Cross Origin Resource Sharing) enabled then yes, javascript code running in attacker page can make calls to your application, retrieve the token and send it in the next request which can result into cross site request forgery(CSRF).

However if CORS is disabled on your application then there is almost no way attacker can access your page and retrieve the tokens from it. CSRF attacks are usually done with the help of authenticated user by tricking them to click on some link running malicious code.

Struts token interceptor validate tokens once and then reset the token in Session object so that no one else can use the same token which could be due to CSRF attack or user trying to submit same request again(Multiple Form Sumission ).


Possible to execute a non-persistent XSS attack without using the url/query string? I've been reading up on non-persistent XSS and all of the examples I have found use the situation where a webpage takes something from the url/query string and places it on the page.

Is there any way to execute a non-persistent XSS attack without using the URL or query string?

Any time an application is building HTML from attacker controlled input it becomes a vector for XSS.  For instance HTML5/JS applications on the Tizen and WebOS platforms can be subject to XSS via any number of vectors including Bluetooth, e-mail, Malicious NFC tags, and just about anything else you could imagine.  Because JavaScript is building the HTML this falls under the bigger category of DOM Based XSS.

As a participant in the Google Bug Bounty Program I found XSS in Google Music by uploading an mp3 file with JavaScript in the ID3 tags.  The application was displaying the Album name and Band name on the page,  and that was enough.


What is the difference between Key Derivation Function and (salted) Hash? I see in this post that the main difference is that KDF outputs have "certain randomness properties", and I don't understand what does it mean. Suposing that that "certain randomness properties" are for protect from rainbow tables and that precomputed stuff.

But using hash with proper salting we can also protect from those attacks. So in that sense I believe that there's no difference between this two tools, differing only in the implementation.

I also know that other aim of the KDF is to be enough slow in order to slow down hypothetical attacks, without spoiling user experience in terms of speed. Well, in the strict sense, this could be also achieved in hashing adding some useless operations (e.g. for(i = 0; i < 1000000; i++); ), even if it wouldn't be very clean.

So, what's the difference? Is one better than other? When would we have to use one, and when the other?

There are actually two kinds of KDFs. One kind is designed to derive a key from high-entropy input (like another key); this can be done with a fast keyed hash like HMAC. The other kind takes a password as input. Passwords are low-entropy; they're not inherently very hard to brute-force. A good password hash thus has to be slow.

In your question, you said that adding for (i=0; i<bignum; i++); would slow the hash. This is actually completely useless. The attacker does not have to play by your rules. Hashes need to protect passwords when the attackers have a copy of the hashes. If the attacker can compute hashes quickly, it doesn't matter how slowly you compute them. Hashes need to be inherently slow; there should be no shortcuts to evaluate them faster than the legitimate server.

The "randomness properties" are because a KDF needs to produce a key. They have nothing to do with precomputation, including rainbow tables. Cryptographic algorithms typically make certain assumptions about the key; among other things, they normally assume it was selected totally at random from the set of possible keys. Keys are also expected to be a certain length; their derivation functions need arbitrary-length output.  In contrast, it's OK if a password hash has lots of structure to the output. Maybe there's a 70% chance that adjacent bits have the same value. Maybe it spreads 128 bits of entropy into 4096 bits of output. As long as it's hard to reverse, that's a fine hash, but it's unsuitable as a key.

A secure password-based key derivation function is a secure password hash (PBKDF2 is in fact one of the big 3 hashes). The reverse is not necessarily true. Which one to use is simple: use a password-based key derivation function to derive a key from a password, and a hash to store passwords.


Can you get rid of the ZeroAccess botnet without a complete reinstall? I'm interested in the recommended course of action for when you find a (Windows) system infected with the ZeroAccess botnet.

I've seen various blog posts online recommending that the user download and run a script, which will remove the botnet, but in your opinion is this enough, or is a full re-install recommended?

Thanks

Some background: The Zeroaccess rootkit/botnet is a multi-purpose, highly resilient bit of malware. It causes compromised devices to participate in click-fraud and mine Bitcoins. Compromised devices participate in a peer-to-peer Command and Control network, which makes the botnet resilient against takedown measures.

Overall, it is a very clever bit of malware that is still being investigated in detail:

  Ross Gibb and Vikram Thakur will be presenting their findings from
  this operation at the annual Virus Bulletin Conference to be held in
  Berlin, October 2-4, 2013. In addition, a comprehensive white paper
  will be released soon to coincide with the presentation laying out the
  inner details of the ZeroAccess threat.

Given how well-written this malware is, the usual recommendation applies - the only way to be certain is to rebuild the device from known good media.

If this machine is one you use regularly, then you should strongly consider rebuilding it ("rebuild" here means to reinstall or restore your Operating System to factory defaults).

If you must give up some security in order to save time or money, then there are some removal tools out there from reputable vendors: Symantec, AVG, ESET, McAfee to name a few.

Perhaps if the infected computer is only used by your 8 year old nephew to play Angry Birds, you could consider just using a removal tool or process.


Intercepting wifi traffic So people always talk about how if you use http over a shared wifi hotspot, people will be able to see your unencrypted data, but I have never been able to make the direct connection from a network security standpoint. I would like to know how to intercept such data and how to view it in a form that is usable. If I connect to a wifi spot and get Wireshark to listen on wlan0 (wireless interface), is this going to be sufficient to view everyone else's traffic? It would seem that when another user on that lan navigates to a website, they will maybe send a broadcast/arp to everyone, but I don't see how their http traffic would ever go through my wlan interface when it would be destined for the default gateway?

Secondly, wireshark has a lot of sporadic meta data that goes passing through. I know of a unix security tool called dsniff that is supposed to render only password data (not http in partcular) and this is the only tool I have found to render useful data like http traffic. Are there any better tools for this?

You may be having difficultly because it's not a network based interception of http, it's a radio based interception of data at layer 1 (physical).

Essentially, on a wired network:

Layer 1 (physical): Copper or fiber wires and physical devices (NIC, GBIC, switch, router, firewall).

Interception at Layer 1 (i.e. using port mirroring on a switch to direct a copy of all traffic on Port X to Port A(ttacker) is quite simple, but requires physical access at some level (access to the cable in Port A, at a minimum).

Layer 7 (application): HTTP or HTTPS
Once Layer 1 has been compromised, HTTP traffic is completely available.  HTTPS traffic is not; additional protections are provided by HTTPS.

On an 802.11a/b/g/n/ac Wifi network:

Layer 1 (physical): Radio waves being broadcast from one antenna, which induce current in every antenna they're in range on (where range depends on both the inverse square law as well as the receiving equipment's sensitivity, gain, and losses).
Interception at Layer 1 can be done by anyone who can manage to get a "good enough" signal to their receiving hardware.

Higher sensitivity receiving hardware has a lower bar to the "good enough" standard.
Using a poorly designed or implemented antenna (your belt buckle) requires a stronger signal than using a well designed and implemented antenna (a properly calculated antenna tuned specifically for the frequency in use, with a very short run of low loss cable, matched impedance, etc.).

Layer 2 (data link): WPA/WPA2, if enabled, provide protections here by encrypting the payload of 802.11 frames.
Layer 7 (application): HTTP or HTTPS
Once Layer 1 has been compromised, if there is no encryption at Layer 2, or if that encryption has been defeated, HTTP traffic is completely available.  HTTPS traffic is not; additional protections are provided by HTTPS.

Wireshark is quite capable of using a wide variety of Wifi cards in monitor mode ("promiscuous" mode in wired NICs) if the OS lets it, which Linux does much more easily than Windows.

If you want to see this ON YOUR OWN WIFI NETWORK ONLY (see local, regional, and national laws in your location), try a Kali (previously known as Backtrack) LiveCD.  Or buy an AirPcap wifi adapter.  Or use many USB Wifi adapters in a Linux (Kali or other) guest OS in a VM on your Windows host.  Use either Wireshark or Airodump-ng.

For Wireshark, further details are available at the Wireshark CaptureSetup/WLAN page.

For Airodump-ng, part of the Aircrack-ng suite, information is available at pages like the Aircrack-ng FAQ "What is the best wireless card to buy" page.


Linux authenticating against Active Directory, is one keytab for all Linux machines enough? We have lots of Linux (RHEL) machines authenticating against Active Directory.

Is one keytab for all Linux machines enough?

Do we need one keytab for each machine?

What are the PROS and CONS?

What are the risks of using one keytab for all the Linux machines?

The main point of Kerberos is authentication - it allows networked entities to prove their identity.  In order for this to work, each entity needs to have a unique name (in Kerberos jargon, "principal name").

You won't want to share one keytab among all machines, because a keytab contains the secret key of a specific Kerberos principal name.  Sharing a keytab would mean you are sharing that keytab's identity among all machines.  The machines would all use Kerberos to declare that they are the same machinename, and Active Directory will not be able to tell the machines apart.

Consider an analogy: trying to share one keytab among multiple machines is similar to trying to share one Kerberos principal name among multiple users.  You can instruct five people to all use the same username and password... and they can log in... but the system they log into will not realize that there are five separate people.  The system would see multiple connections to one single account, since all the connections are using one single Kerberos principal name.


How do PGP keys "expire"? When creating a PGP key, you can choose when the key "expires". What does this mean and how does it work?

If your public key expires, it can't be used to encrypt.  When you generate your private/public keys, you should generate a revocation certificate so you can immediately revoke if needed...if you have no expiry time and no revocation certificate they can last forever.

As for how it works, quoting from https://www.gnupg.org/gph/en/manual/c235.html :

  A key's expiration time is associated with the key's self-signature.
  The expiration time is updated by deleting the old self-signature and
  adding a new self-signature. Since correspondents will not have
  deleted the old self-signature, they will see an additional
  self-signature on the key when they update their copy of your key. The
  latest self-signature takes precedence, however, so all correspondents
  will unambiguously know the expiration times of your keys.


Under what circumstances can WPA be cracked? can someone please tell me under what circumstances can WPA be cracked? i'll appreciate it.

It is susceptible to KRACK Attack. KRACK is attack is Key reinstallation attack. WPA2 also susceptible 2 KRACK attack.  WPA based on LEAP or TKIP and it use single passphrase for authentication. It is possible to brute-force very easily. Because passphrase is static.


Do Chrome/browser extensions break the tab sandbox? So, as far as I know, Chrome and possibly other browsers have a very low privilege process spawned for every tab.

How do browser extensions interact in regard to this sandboxing? I'm not talking about directly compromising an extension, but compromising Chrome, and then escaping from the tab sandbox by compromising the extension.

Access to privileged methods in a Chrome extension depends on two factors:

The active extension permissions.
The current process.

Chrome extensions can only request access to privileged APIs after declaring the necessary permissions in the manifest file. There is also a set of private APIs that are only available to an extension when their extension ID is whitelisted (hardcoded in Chromium's source code). This is not really relevant if you want to escape the sandbox, it just defines the boundaries of the impact of a compromise.

There are two "sandboxes". One that is visible to extension developers, that aims to protect users from websites that try to leverage the privileged extension methods. The other one is transparent to extension developers, and provides protection against compromised (render) processes.

Chrome is a multi-process application, consisting of one (high privilege) browser process, and multiple render processes. Each tab/site runs in its own process see Process Models for more details, with the minimal privileges necessary to execute their task.

Extensions can use so-called content scripts to modify the appearance or functionality of websites. These content scripts share the same process as the website on which they are acting, but the JavaScript code runs in a separate context. This allows the extension system to offer a very limited set of privileged JavaScript methods to the content script, e.g. in form of the extension message passing API and cross-origin AJAX. When a tab process is compromised, the damage is limited. It could make cross-domain requests (if the extension had the permission to do so) and send messages to the extension's background process, but not read files from your filesystem, nor use any of the more powerful extension APIs. When one tab process (renderer) is compromised, the damage is usually limited to that single tab/origin, thanks to the security architecture.

Other parts of the extension (e.g. background pages, popup pages and pages where the omnibox displays chrome-extension://[EXTENSIONID]/...) run in the extension process. Pages within the extension process can use powerful APIs provided that it has requested permissions to use them, including read access to files on your local file system (provided that it has requested access, and you have explicitly put a tick at the "Allow access to file URLs" checkbox at the extension settings page - this does not happen by accident, don't worry).
When an extension process is compromised, the damage is limited to what an extension can do. It cannot write to arbitrary files on you file system, for instance.

(note that a malicious extension developer does not need to go into the efforts of compromising an extension process, because if you install a malicious extension that requests the "Access your data on all websites" and "Access your tabs and browsing activity", then it already has sufficient power to mess with your websites, e.g. by stealing passwords when you type them).

External resources

http://www.chromium.org/developers/design-documents/process-models
Describes the different process models that Chromium supports for creating renderer processes.
http://webblaze.cs.berkeley.edu/2010/secureextensions/
Describes how Chromium's extension system is designed from the security-first approach.
http://seclab.stanford.edu/websec/chromium/
Describes Chromium's security architecture (not just extensions, but the browser as whole).
http://www.chromium.org/developers/design-documents/site-isolation
Site isolation (not extension specific, but relevant for the security assessment of content scripts)


Avoid unauthorized updating of online leaderboard php/sql I am developing an offline web app (game) for android using cordova (phonegap). The leaderboard of the same is maintained online in my server.

Currently this is how the leaderboard is updated

Step 1) The user's score is stored in the offline app's local storage.

Step 2) The user presses the "update my score" button connecting to the internet.

Step 3) The button basically sends an ajax request to https://mywebsite.com/scoreupdate.php?userid=user_id&score=obtained_score

Step 4) Based on this the database is updated in my server by scoreupdate.php file and returns success.

These are the problems I am facing

1) Anyone can easily visit https://mywebsite.com/scoreupdate.php?userid=user_id&score=obtained_score if they know the user id (It can be easily obtained from the app's localstorage data) and he/she can update his/her score in the leaderboard simply by replacing obtained_score value with some high value to get a better position in leaderboard.

2) Any secret value stored in the app or localstorage can be obtained easily as the whole thing is built in javascript. Reverse engineering of the app is also possible so I couldn't find a way to efficiently authenticate that it is the real app which is sending the request to the server and not a person.

My requirements

1) The app must be able to authenticate the scoreupdate.php file that it is the real app and not a person. So that only the app will be able to update the leaderboard.

2) The logic of the authentication shall not be cracked by the user just by reading the source code of the app. (eg: multiplying the user id with some numbers and doing the reverse process in server won't work)

Is there some way to accomplish this?

Javascript scrambling is not effective as it can be de-scrambled easily

EDIT

I am not worried if someone steals the user credentials via a MITM or any bruteforce like attacks. Even the real user who owns the profile should not be able to update his/her own score.

I disagree that it is impossible.

Depending on the form of your game it might be possible to apply the following scheme:

During the game, record the starting state, including seeds to RNGs and all inputs from the user.
When submitting the game, submit this "replay" of the session to the server together with the claimed score.
On the server, run through the game logic with the provided input and see if it results in the same score. If it does, the replay is valid and you update the score.

This way, you have effectively transformed the problem of cheating to the problem of writing a bot or a solver for your game which is the best you can ever get in a situation like this.

Basically this is a very good solution for any games that can be viewed as an NP-complete problem where verifying a solution is computationally easy while finding it is computationally hard. One such example is Sokoban.


Is deleting files from a database considered a denial of service attack? If i am able to access a database and delete all the files which a web app would read, would that be considered a Denial of Service attack?

It is not a duplicate of the question in the following link since the hypothesis is different, although the outcome may be equivalent:

Is unauthorised deletion an integrity or availability issue?

Yes, in the sense that anything which "denies service" is a "denial of service".

The CIA Triad defines information security as anything which affects Confidentiality, Integrity, or Availability of the system / data.

As pointed out in comments, this is not always an "attack" since it's just as likely to be accidental. Whether this is the result of a malicious attack, an admin botching a patch install, or the building catching fire, DoS due to data loss is definitely a security risk for which organizations should have a plan in place.

Assuming it is an intentional attack, if they have enough access to the backend server to delete db files, then there are far more subtle and nefarious things they could do (like stealing the db, selectively deleting data, planting a network sniffer, etc), so a DoS is pretty much the least dangerous thing in the category of "attacker has write-access to the server's filesystem", which is why "deleting the database" is to "DoS" as "canoe" is to "vehicle": not the first thing that comes to mind, but technically counts.


Using the TPM module to measure boot process and remote attestation I have a question about Remote Attestation and measured boot with a TPM-Module.

The illustration shows my project schematically. A TPM module will be used to measure the boot process and validate user applications. The kernel generates a hash value from all user applications and extends the PCR register 17.
Authentication should be performed using the Remote Attestation Protocol. (Simplified:) For this the verifier sends the prover the challenge c (which includes a nonce, and information about which register he is interested in). The prover response with a signed (with an AIK Key because the EK Keys should not be used) messages of the PCR-Values (in this example PCR[17]). With the signature, the challenge knows that the response come from a TPM.

So far so good, but how does the verifier know that the PCR values are "correct"? Where do the reference values come from for comparison? Is there a local copy of the expected PCR values on the verifier's page? can you simply calculate them? (For example, the verifier knows the hash values of the user application and calculates the PCR values itself).

I am looking forward to more information and useful links. Thank you for your answers and help.

The TPM seals arbitrary data using a key derived from the state of its PCRs. It is up to you to tell if that data is correct. It could be a decryption key, so the disk can only be read when the PCRs are in the right state, or even a secret phrase known only to you, ensuring that an attacker cannot spoof it because they do not know it. There are many answers on SE which explain measured boot.


many csh http shellshock attacks I administrate a public server that receives about a 100 csh HTTP shell shock per day from different sources. It is an HTTP GET Method that that requests the /cgi-bin/authLogin.cgi URI.

Knowing that the requested URI does not exist in my server  is it normal to receive much attack attempts from the internet ? Does that mean that my server is compromised ?

Edit

Can anyone with networks auditing experience  tell me if receiving that much attacks from the internet is normal or not?

Based on the URL being requested it seems that these are attempts to exploit a shellshock vulnerability in QNAP Network Attached Storage (NAS) devices. If this is not a QNAP NAS, and you know that your servers have the shellshock vulnerability patched, then you probably don't need to worry.

The fact that you are repeatedly getting requests for a URL that doesn't exist suggests that these attacks are not targeted toward you specifically, but are instead coming from automated bots that scan tons of online servers looking for ones that have a specific vulnerability. Unfortunately these bots are extremely common, so 100 requests a day isn't all that unusual for a small to medium sized website. It's all just a part of running a server on the Internet. As long as you are not vulnerable to the specific things they're looking for, they shouldn't cause a problem.


What are the Pros and Cons of allowing users to stay logged in to a web application? To become a more well-rounded developer, having a better understanding of security concerns and best practices will help me endeavor to build web-apps that are both user-friendly as well as secure.

I'm currently working with cookies using PHP for a login script and have heard that storing a hashed password in a cookie is not a good practice. The only scenario where I thought this would be an issue would be if someone left their computer unlocked and an intruder was able to impersonate the computer owner during the login process. I told him Amazon does this- where users are logged into their account while they shop for things- but my friend countered, citing how Bank of America kicks the user out after being idle for a few minutes.

I Googled my question where I found only implementation methods instead of providing different scenarios of how staying logged in would be a bad thing.

I'm working with cookies in PHP for a login script and my friend thinks storing a hashed password in a cookie is bad news.

Your friend is absolutely correct, there is no reason to do this. It's not a matter of staying logged in, it's a matter of needlessly exposing the password hash (side note: please use PHP's password_hash function for hashing passwords).

While exposing the password hash over an encrypted connection (you are using HTTPS aren't you?) isn't the end of the world, the real problem is that it indicates to me that you're probably authenticating sessions by comparing the cookie's value against the stored hash. This means you have no way to invalidate session cookies, if the password hash is ever exposed, that's all an attacker needs to access someone's account!

Use PHP's built-in session management, which uses a sufficiently long random value to keep track of users (at least in recent versions, old versions have had problems with this).

To answer your original question of how long sessions should last, it varies wildly. My desktop is indefinitely logged into my Gmail account, but most bank sites expire sessions after 15-30 minutes of inactivity. For a site that doesn't have anything too important, long lasting sessions are fine, though it's good to allow users to see existing sessions on their account and expire them manually.


Does a signed hash reveal any information about the original message? As part of the end to end encryption for my app, I am following the standard procedure of using RSA to exchange the temporary AES256 key. Currently when A decides the key to send to B, he encrypts it with B's public key. All of this is taking part over a TLS connection to the server. However B is sort of taking the key on blind faith that it came from A. Of course, it's not like anyone can send B the AES256 key. You need to log in first to the server before it's willing to pass messages to A. The AES256 key is also only ever sent during the setup of a session between A and B which B would have to have accepted before. The server will also check that there is a requested session start between X and B before sending anything to B and that it is really X that B wants to have a session with. The point of the end to end is to prevent the server from knowing what's going on between A and B (even if it is my own physical one).

I thought that making A include a signed hash of the key to B would reassure B that the key really did came from A. However, java in android isn't able to encrypt the signed hash because it is exactly 2048 bits (as expected). Would there be any danger in just transmitting the signed hash (Java RSA with SHA512) in plain sight? My understanding is that hashes are brute forced which at this point, you might as well just brute force the AES key anyways.

Edit:
Since it seems like people are getting to the heart of the problem: encryption over UDP, what's done is done. I'll write up how I'm currently doing it. It's my own personal project so I welcome any improvement. I'm not emotionally attached to the current method.

(All this take place over an existing TLS connection as the "command" socket is TCP)

A generates the AES256 key using java's SecureRandom.
A gets a copy of B's public key from the server.
A sends an the RSA encryptd key to B using android's RSA/NONE/OAEPWithSHA1AndMGF1Padding. This is chosen for the OAEP padding which (from what I've read) sounds like the best method of making the input to RSA look as random as possible to avoid the output having certain characteristics based on the input.
B gets the message and sends an "ok" command to the server which tells A.

(The rest takes place over plain UDP)

A sends a message to B using android cipher's AES/GCM/NoPadding. GCM was chosen because (from what I've read) it's the best method for "chopping" up the data into secure pieces. GCM is supposed to contain a MAC so I'm assuming it takes care of authenticating for me. A new cipher instance is instantiated for every block of data. I'm assuming android's cipher.init takes care of the IV (new for every block). After encrypting. the data is sent [IV length;IV;AES256/GCM Data]. From what I've read the IV is like a salt which is used to prevent precalculated attacks. Normally in a database the salt is stored in plain text so in this case it's transmitted in plain. (If it wasn't this creates an infinite regression problem.)
B does the reverse process and sends a response to A using the method described above.

A new AES256 key is used for each session between the 2 for forward secrecy. In terms of replay, the plaintext data has a sequence number.
I have seen MAC decryption failures in the logs when using LTE at the beginning of the session. Haven't had a plausible explanation why.

I believe this is a case of the XY problem. You are trying to allow authentication in your protocol scheme, and you are asking how to securely do it using a method which you implicitly assume is necessary. The reality is that there are already plenty of ways to prove that a given key is authentic without sending over a hash of the key. I suggest you read into how TLS provides authentication without actually signing the session key itself. As that's the subject for another question, I'll answer specifically as to whether or not the signed hash of a message (such as a shared key) reveals any information about the contents of the original message (tl;dr the answer is no, it does not).
Signing a message involves computing the hash of the message and signing the hash. Because the signature depends only on the value of the hash, we can safely ignore the signature. It gives away no more information about the message than the hash itself. So can we attack the hash?
An attack that would allow someone to learn information about the input to a hash function given only the digest itself is called a (first-)preimage attack. More specifically, this is an attack against some hash function f where given only digest h, one is able to find an arbitrary message m such that f(m) = h faster than exhaustive search. All modern cryptographic hashes*, such as SHA-512, are conjectured to be preimage-resistant. As such, providing the hash to a message gives away no information about the message itself. The only possible way an attacker could find the message is if it is short enough that it is feasible to brute force the message until a matching hash is found.
For future reference, there are three classes of attacks against a cryptographic hash function f:

Preimage attack - Given h where f(m) = h, find any m' such that f(m') = h.

2nd preimage attack - Given m, find any m' such that m ≠ m' and f(m) = f(m').

Collision attack - Find any pair of m and m' such that m ≠ m' and f(m) = f(m').

An unbroken cryptographic hash with a digest length of n is assumed to have a first-preimage and second-preimage resistance of 2n and a collision resistance of 2n/2. This is the case for SHA-512.
* Formally, a collision and preimage-resistant cryptographic hash is defined as a function that maps an arbitrary-length input to fixed-length output. For a message space of {0,1}* and some fixed n, the algorithm for cryptographic hash function f is defined as {0,1}* → {0,1}n. This is explained in more detail in an answer on Crypto.SE.