If my phone for two factor authentication is stolen, can the attacker access my account via an email password reset? Suppose I setup an online account with 2FA on my phone, and an attacker gains access to my phone. My phone is logged into my email account. The attacker knows my online service's account username or find the username from my emails. Then he requests an email password reset, and he uses the 2FA app on the phone to authorize the reset request. Now he has both the password and 2FA.

Is this scenario possible? How do I prevent it? What should I do in case I lose my phone to avoid this attack?

As @Limit pointed out in the comment under your question, the attacker would first need to unlock your phone. Which is a problem. But not impossible. But for the sake of argument, let's assume the attacker stole your phone in an unlocked position (you were sitting at a coffee shop, checking the internet, put it down, turned to talk to someone, and someone else swiped it for example).

To answer in a word, yes. This compromise is completely possible, and part of the reason I personally have a slight disgust to the ways some companies are rolling out 2FA. Especially google, who knows for a fact that the user that uses their authenticator on their phone likely also has their email on the very same device.

The security trinity is supposed to be this:

Something you are (username, fingerprint, retina)
Something you know (password, key-file, other data blob)
Something you have (OTP generator, Keyfob, yubikey)

The problem is that the user desires convenience, and this always presents a threat to this model. The key factor in the way the trinity works is that these things aren't supposed to overlap.

don't use your username as your password
don't use the same key-file for your "password" as your yubikey's public key (or worse private)
etc...

However this line is becoming increasingly blurred, because many users desire all of their tech related tasks to be aggregated on one device. It creates the situation where a person turns a password (something you know) into essentially a device that autocompletes the password when required. Effectively turning it into something you have since you are no longer required to know it, simply posses the device.

This situation is made worse by allowing that same device to also house the software authentication mechanism that is supposed to turn the device into a replacement for keyfobs.

What this ultimately creates is the false sense of security where the user thinks they have the trinity of username-password-authenticator but really only has a username and two authenticators, and both of them are one device.

This is made even worse if you think about how much of our lives are linked to said e-mail account. Not just your email itself, but any service that also registered with that email likely also has a reset policy that utilizes it. Thus allowing the attacker to also transfer ownership of any services to themselves through your one device. Furthermore the email also provides an easy to use interface that will search for the services you have signed up for. All they must do is search for "please verify your email by clicking here:" and out comes a list of domains where you have attempted to register.

This is something I try to advise people on whenever I see it. Each security step must be segregated as much as possible within reasonable usability constraints. If you have the google authenticator on your mobile, don't allow your email to remember the password to your gmail. If you do allow it, use the authenticator on another device, such as an ipad, another phone or your computer. There are some great alternatives to traditional authenticators that work with phones and don't require any operations to be done on the phone itself. Like the Yubikey NEO which has NFC enabled. Even if your phone is stolen, the yubikey likely wont be (Please don't attach it to the key-chain that hangs from your phones...).

These methods keep each part of the trinity separated, and thus, mitigate the problem somewhat. It's always important to clearly define the line between each part of your security structure. Otherwise they start to mesh together until, as in this case, they effectively become the same part of that trinity, leaving a void where one of them once stood.


Best approach to confirm email within mobile app? Would appreciate your opinion on the options explored:

a- Launch app and ask for a verification code that was sent to user email?

b- Launch app by clicking deep link + verification code in the email and confirm to user their email has been verified

Q1-From a information security point of what are advantages and disadvantages of both these approaches?

Q2- Any other considerations to take into account?

A more general question:

Q3- Given that mobile devises are frequently used to authenticate users would it be safe to say that mobile apps are less prone to authentication issues just by virtue of being on mobile?

Since this is about security, I would say regardless on how you do it, the security boils down to how many charachters that is suitable to use as "verification code".

However, using a single direct-activation link that is NOT a custom protocol registred as in the above comment, there is a risk that a unaware user clicks this links and inadvertly activates a account that the user did not register.

However, from a usability Point of view: Everyone does not have their email account tied to their phone, so a alternative must be used.

So my suggestion here is:

Have 2 alternatives, where the first alternative is a link like:
appcustom://activate/39734962

But you also provide a secondary means of activating, that is like:
"If you receive your email on a Another device than which the app is installed on, Press "Use Code" and enter  39734962 as code."

In the app, you must verify that the activation code corresponds to the same phone that initiated the activation.
Eg: First user register with email. Server sends a unique token to app, that is saved on phone memory.

On server, you store email, token and activation code.

Upon activation, user enter code or click the custom protocol handler link.
Your app then sends to server: Email, the token that was previously saved, and then code. Server checks all 3 fields match.

This would mean that if the user register, then delete the app from phone, and then reinstall the app, the user would be unable to activate using the activation code the user received. The user would have to request a new activation code.

A good idea is to kick off registration from this Point, so when user successfully has typed the activation code or clicked the link, the user is taken to the registration form to fill in the rest of the details, and where the email field is prefilled and not possible to change (of course you also need to check on server-side that the email field is not changed).

By using such a scheme, you avoid email adresses getting locked up because of malicious or unaware users.

Eg:

1: User fills in Email and press submit.

2: Phone receives token from server. Phone saved email and token in memory.

3: User clicks protocol link in mail or enters the code in the app manually. App sends email, token and code to server. Server validates Email, token and activation code is correct.

4: User is now taken to the registration form where he is asked to fill in the rest of the details, like username, select a new password to use with account, first name, last name etc.
Of course, the link and code in email must remain valid until the registration is actually completed, so if user accidentally abort the process (for example moves out of network coverage), they will be able to continue at a later time.

However, its a good idea to expire activation codes and tokens by time, for example 48 hours is a good time.


Bank asking for password for encrypted document My bank has advised that they are sending me a letter by email.

The letter within the email will be encrypted.

Rather than giving me a password for the letter, the bank asked me over the phone to provide them with a password for the document.

Is it common practice to ask the customer over the phone for a password?

First and foremost: Isn't a letter that is sent by email still an email?

More importantly: this practice seems less secure than other implementations of password sharing processes, but it is probably not overwhelmingly risky to use.

If you compare this to the process that is used to send your debit/credit card + PIN to you - it is pretty much the same, but with less paper used.

Process 1:

Letter 1 is sent with a debit/credit card.
Letter 2 is sent with your PIN.

Process 2

You speak on the phone to set the password.
A letter is sent with confidential information.

The important part is, that both steps (1) are separate from the related steps (2). So if only one message is intercepted, it is useless without the other. There are certain risks involved that apply particularly for process 2. E.g. if the person you speak to, intercepts the mailthe one with the letter he/she would have both information needed. It is also relatively "easy" to record phone calls for an employee in a call center, while it is "harder" to check the contents of a sealed envelope without the recipient knowing.

The biggest risk involved is the transmission of the password. At least the call center agent knows the phone if you do have to tell them directly. If this person then intercepted the e-mail/letter, they would have all the information that is needed to get to the confidential information. The likelihood of that happening is probably relatively small though - unless you are a high priority target. If you are and this information is crucial don't do this. If you aren't, then go for it.


Are multiple network interface still recommended in a virtualized world? Before the virtualization era, it was recommended to have several network card on a physical server :

1 for production dedicated network (only application's stream like
http, SQL*NET, ...)
1 for administration network (ssh, monitoring,
...)
1 for backup network (netbackup, ...)

These recommendations had security and ops advantages:
network port for administration or backup purpose are not available on production facing network, dedicated bandwidth for backup that doesn't impact production bandwidth, ...

With virtualized servers and network are multiple network card/interface still recommended  ?

It depends on your security goals. Separate interfaces have been used not only for the advantages you stated, but also to keep the dedicated networks, storage and backup networks, and the administration networks logically segregated. Just because an infrastructure is virtualized doesn't mean that the need for network segregation goes away.

If you lump all these networks together into one you are no longer able to enforce specific security rules for each, so if you have a security requirement to keep these networks separate before virtualization then you need to keep them separated after virtualization.


hide dhcp/ip request, traffic under lan router I have a question on the following scenario:

Lets say, we have a normal LAN network with 192.168.1.1/24 gateway, DNS, DHCP servers all running on 192.168.1.1 ;

There is only one client: 192.168.1.200.

Now, for me, as an attacker, is it possible to use (any) IP ( just assume ip pool is 192.168.1.x is allowed), which the LAN router wouldn't detect and log in its general logs, (like DHCP) leases and so on?

The question is how to be undetectable (that is not generate any logs) on the router.

The attacker could use the clients IP = 192.168.1.200, but in logs you would have anyway 2 same IPs with (same) MAC addresses.

Okay. I cleaned up your post to what i think it is you're asking for which is how to connect to a network without getting the router generating logs about my activity.

You can manually set your IP address of your machine to 192.168.1.199. Since your machine is the client, it must send a Discover request for an IP address to the router if it wants one. If you set it statically, the DHCP process never kicks in.

Additionally, you can manually set your DNS to something external like 8.8.8.8 (google's public/free DNS servers) but that will not let you resolve any internal client devices.

If you don't want someone knowing that you've connected to their LAN, your best bet in a scenario like this would be changing your MAC address randomly whenever you want to connect and using a Static IP. Most routers will store information on MAC addresses in order to assist in routing information correctly between clients.


Dealing with a malware infected server I have a web server which is heavily infected by malware. That is, around 12 websites (Outdated CMS) are infected by PHP shells and XSS. My websites are banned and are not accessible anymore. I have SSH access but I can not run root commands.

Question: What are the ways by which I can check for shells on my web server without being able to connect directly to the websites and low privilege SSH access.

NeoPI was helpful in finding some of them, which were checked manually.

ShellDetector gives a lot of false positives.

I am open to suggestions on clearing the malware.

Since you have no root access yourself I consider this compromise only restricted to your own account. Otherwise the owner of the server would probably have taken care of the issue already.

The best way is probably to nuke the site and set it up again, but only after checking how the attacker came in and make sure it is no longer possible.

The best way to check where exactly your server is compromised is to compare all data with a known good version. I don't know about your setup but it is common to make the site development on a local system and then mirror the data to the remote system. Thus it should be possible to compare these both versions or to simply restore the site from your local copy. Not that you need to check also if files exist remotely which don't exist locally.

If instead you have done all the changes on the production system and do not have local copies then I'm very sorry for you since this effectively means that you have to look at all the files and see if they differ from what you remember. File modification times might be an indicator of a change but are not reliable since they can easily be set to other times (also older) without needing special privileges.

Additionally there might be changes to the database. If you web application dynamically creates HTML based on fragments in the database then you have to go through all records an look for anomalies.

If you have access to the log files of the server these are also a good source when looking for abnormal behavior, but it is up to you to know how your site works and what would then be considered abnormal.

And finally your site might be vulnerable by remote file inclusion attacks (RFI). In this case you will not find much traces on your local system, because the files used in the attack might reside on a remote system. Thus make sure your web application is secure. You should do this anyway because otherwise chances are high that you get compromised again fast.

Note that simply searching for known malware is not enough because even small modifications on existing malware will leave the malware working but you will not find it any more.


bcrypt no need to store salt? I'm confused with bcrypt, I would think I would need to store my salt, and then compare my plain text password + salt to the hashed password, however from documentation it does not look like storing the salt is necessary at all. Indeed I used this code to create salt and hashed password:

  let salt = await bcrypt.genSalt(10);

  const saltpasshash = await new Promise((resolve, reject) => {
    bcrypt.hash(plain_text_password, salt, function(err, hash) {
      if (err) reject(err)
      resolve(hash)
    });
  })

  //NOTE I SAVE saltpasshash as users pass and the salt in a separate field in the users table.

This works, what I am confused about is it will then return a valid result if I compare as follows:

valid = await bcrypt.compare(plain_text_password, user.saltpasshash);

I'm confused as to why this would be valid when I am not providing the salt, and if so, why store the salt at all?

From a description of bcrypt at Wikipedia:

  ... The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters)

Thus, the salt is automatically included in the output string which means there is no need to add it by yourself.


XSS and browser parser order I remember reading something a while ago about successful XSS attacks when the wrong encoding technique was used for the context. In particular, I remember this when HTML encoding in Javascript context, for a tag's attribute's value representing a Javascript hook, like onload.  For example,

   <body onload='doSomething ("userdata")'>

where the server HTML encodes the userdata before writing the HTML over the socket to the browser.

As I remember, the browser would first parse the page for HTML, decoding the the attribute value, undoing the HTML encoding of the userdata. The browser would next parse for JavaScript. If the userdata were crafted as an XSS payload, like

  x")&&alert ("xss

it would now be executed. For the life of me, I can no longer find the relevant references that demonstrate this behavior, nor can I remember whether parsing order has other subtleties - like if HTML encoding styles or URLs will result in XSS vulnerabilities. Or if there are parse order issues with encoding between URL, CSS and JS.

What references demonstrate that encoding with which mechanisms in the wrong context will result in continued XSS vulnerabilities, and which will result only in usability issues?

The XML standard will implicitly decode all attribute values. When rendering an HTML page, these attributes are interpreted as their decoded character literal values before interpreted as a possible JavaScript event.

In the context of XSS, a DOM event can lead to XSS by undermining the escape routine used to build the XML document.  For example, the following escaped sequence is an XSS vector:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);sendHaxor(document.cookie);//');" />

This is one of the many reasons why the Content-Security Policy (CSP) is valuable at preventing the slippery problem of XSS.


What are the advantages/disadvantages of attribute-based access control? An example attribute would be "employee is currently located in the US" and is trying to access a document that requires the person to be accessing the document in US territory.

Simple google search would give you the answer to this question.

Vendors like Axiomatics are more than willing to answer the question.

The US Government also has an opinion

You might have missed 1 Raindrop unless you follow the field, but I think it answers your question nicely:

  It seems to me that the value of XACML and ABAC is really in the use cases that they enable. It's outward focused, and unlocks value through new kinds of services. . . .

The summary is that ABAC permits you to express a rich, complex access control policy more simply.  Most access control policies (I'm looking at you RBAC) rely on ''someone'' somewhere updating a policy as employees move from job to job or responsibility to responsibility. People get added for temporary needs, and never removed.  There is a huge back end to implementing the policy.

The simplest and coolest example I can cite is from a real world example. Turns out that the bouncers/bartenders at a bar were checking ID and were memorizing/copying the information from cute  women. Then they would either stalk the women, or wait till the women had had enough to drink that their judgement was impaired and offer them a drive home.  This is an opportunity for a bad thing to happen.  The bar implemented an ABAC solution.  When the women entered they submitted their ID to a machine that either issued a wristlet or tagged the credit card as over/under 21.  The only information the bartender had was whether the person was legitimate to receive alcohol; access control (to alcohol) was decided based on a single attribute (over/under 21), without revealing any additional information.

ABAC, if implemented as part of an identity infrastructure means that when Mark Wallace moves from the developers group to the project manager's group, his access control rights will be updated because he changed supervisor, workstation, and job title, not because someone remembered that he had admin permissions and took time to update a configuration file somewhere.   The HR department feels that it is very important to keep track of who my supervisor is, and they have a vested interest in keeping that information up to date; my permissions flow from those kind of organic decisions.

Disadvantages?  There aren't a lot of deployments because it is still kind of new, and because you only get the full benefits when you deploy sufficient infrastructure.  Vendors are still playing with the right implementation of the right protocols. There is a lot left to be worked out.


Should I scan both HTTP and HTTPS seperately? I'm doing a scan on some domains (who I will not name here) using OWASP ZAP. When I typed in the URL of a domain as http://thedomain, it returns http://thedomain/robots.txt and just a bit more. After that, it automatically went on to scan https://thedomain without me specifying to use https and got me a lot of information.

As far as I know, the main differences between HTTP and HTTPS are that HTTPS is encrypted and more secured and uses port 443 by default instead of port 80. Some of the domains I've scanned return somewhat different results between when http and https are scanned.

Taking into account the differences in results and the resources it takes to scan entire domains (mainly time), should I scan both http and https?

Technically, it is entirely possible for a web server to return different content depending on whether you accessed it via HTTP or HTTPS. In fact, nearly all servers supporting HTTPS do this; if you access /foo/bar via HTTP, you get a redirect to HTTPS, and if you access it via HTTPS, you get page content (or at least a 404). It's rare (though not unheard-of) for this redirect to itself have a vulnerability, so it's worth testing. Additionally, it's a good idea to know what content your web server makes available over plain HTTP - sometimes sensitive data is exposed! - and also some web apps will send a user from HTTPS to HTTP for some links/requests and that gives a network attacker a good opportunity to steal cookies, data, or begin an SSL-stripping attack; you definitely want to find such things.

Pretty much the only time that you can completely ignore plain-text HTTP is if you use HTTP Strict Transport Security (HSTS). A user visiting the site for the first time will presumably neither be sending nor receiving sensitive data in their first request/response, and will be immediately redirected the HTTPS and then the browser will not allow any further HTTP requests to that domain once it sees the Strict-Transport-Security header. Some very old browsers don't support HSTS, but... well, anybody using a browser that old is metaphorically wandering around picking up random guns, aiming them at their foot, and pulling the trigger; it's not your job to try to stay ahead of them and unload every gun they might find first.

Scanners generate so many requests already, and HTTP->HTTPS redirects are so light on server resources, that I don't expect you have any need to worry about extra scan time or server load. Scanners are generally "smart" enough to not bother with HTTP requests when every time they try one they just get a redirect in response, when they see HSTS headers, and/or when all cookies are set with the Secure flag so somebody using HTTP instead could only make unauthenticated requests.


How do I stop my IP from being resolved through my Skype? I recently discovered that someone found out my current IP info via Skype among other information. People can do this via a thing called Skype resolvers. However nothing I do so far seems to work. I have my connection set to "Allow direct connections to your contacts only." I also have Skype installed on Linux as well as Windows. However even when I uninstall Skype on Linux and I also think both Linux and Windows I am still resolvable. I also tested on this on myself using an online skype resolver. Any help much appreciated. Thanks.

Due to an increase in DDOS attacks in the gamer community Skype no longer allows an IP to be shared by default as of 01/21/2016. They are likely no longer setting up the handshake and making you a peer to peer connection and you are now transmitting information through a central server or a proxy server to make this happen.

  Skype is fully committed to delivering as safe and secure of an
  experience as possible to our customers. We have recently introduced
  the ability to hide a Skype user’s IP address and we’ve set this as a
  default status in the latest versions of Skype.

  Starting with this update to Skype and moving forward, your IP address
  will be kept hidden from Skype users. This measure will help prevent
  individuals from obtaining a Skype ID and resolving to an IP address.

  You can find this update in the latest versions of Skype on desktop
  and mobile* devices, which you can download here. We also recommend
  you update Skype across your devices to ensure you benefit from the
  best experience possible.

  *Android, and coming soon as default on iOS.


Does using an http proxy completely hide my real IP address? If I obscure my IP by going through a free http proxy and visit a page, will that site's admin ever be able to find out my true IP or anything related to my true connection/info?

Just because your traffic is passing though a proxy it doesn't mean you are safe.  "Transparent" proxies will transmit your IP address using the X-Forwarded-For HTTP header.  There are also cookies that can be used to identify you,  such as flash's evercookie.   You can even be fingerprinted and tracked by the extensions you have installed and what versions you are running using The EFF's panopticlick.

Using Tor in Firefox from an open wireless access point works well.  Ironically, the fingerprints gathered by EFF's panopticlick is used to make the Firefox's anonymous mode more difficult to track.  This is because Mozilla and the EFF are working together on this project.


How can I test my web application for timing attacks? race conditions, etc.

Are there automatic tools for this? What manual techniques should I use?

From the Area51 proposal

Timing attacks, race condition (CWE-362) vulnerabilities are not very common for web-applications, these are primarily problems of more low-level languages. For example, in CVE-2006-5178,
race condition was due to incorrect implementation in PHP interpreter itself. But application relying on those functions goes vulnerable too.

It could be daunting to attempt to reproduce such vulnerability, due to timing issues and the needs of specific environment. With automated vulnerability scanners it is not feasible to conduct such test - even for human it is not easy to find such vulnerability.

To my opinion, developer just needs to keep in mind when the main process can be interrupted. Atomicity should be provided when the sequence of actions must not be interruptible. Mainly database actions are susceptible to such attacks. Even when DBMS supports transactions and provides means for safe synchronization, there can be more global actions that are under control of DBMS to make them atomic. Attention should be pointed also to situations where threads are used.

In the link to CWE-362, there are list of papers that are useful to read. Those would provide much more information than I have given here.


What's the difference between SSLv3 being deprecated and SSLv2 being prohibited? I've been working on some security docs for a database at work - a quick guide on how to create a JDBC connection over TLS for this. The docs I have mention that while it supports SSLv2, SSLv3 and TLSv1, SSL is not recommended. I have no problem with adding this to the guide, or linking to the relevant RFCs, but I'm a little unsure about the language the RFCs use.

RFC 6176 prohibits the use of SSLv2, which I interpret as "Do not use this. Just...don't."
RFC 7658 deprecates SSLv3; my interpretation of this is "Don't use this, unless you really need to."

Both RFCs state that their version of SSL must not be used. So, are my interpretations of this accurate? If not, what's the difference?

Both documents intend to prohibit the use of the respective protocol and use the same RFC 2119 as a reference for terminology.

RFC 7658 (the one titled "Deprecating...") specifically says:

  Security Considerations

  This entire document aims to improve security by prohibiting the use of a protocol that is not secure.

Both documents were written in different times, by different teams and both are classified as "proposed standard". Moreover, RFC titles seem not be standardised and no BCP document of IETF mentions how the titles should be formed.

The documents should be considered as a whole and their interpretation and application should extend beyond their titles.


Truly deniable encryption What tools can be used to make truly deniable encryption?
Suppose, authorities can use any force to make you open your passwords.

Truecrypt can have only one hidden container, which means that authorities will not stop, until you reveal this second password, even if you did not create hidden container.

So, is there any way to create many hidden containers, so that authorities could not even tell how many passwords they should beat out of you. And it is desirable that this way should be secure enough against other, more intelligent decryption methods like statistical analysis of used clusters and so on.

Here http://en.wikipedia.org/wiki/Deniable_encryption i've found info about rubberhose, but it is not maintained since 2000, so i dont know how much it is reliable.

Another way I found is to write to hard disk with different offsets using for example similar scripts
http://sourceforge.net/projects/stlth/files/

But this way, as far as i understand, data is not mixed physically, so it is vulnerable to that smart statistics methods. I.e. if authorities see that you heavily used the part of drive that is not revealed using passwords you already gave then they continue to try to get the passwords.
Rubberhose, accorging to documentation, has protection against these methods, but the project is too old.

What another tools could you advise to make several hidden containers on disk?

If you write random bytes to an entire device, and then create a headerless (no LUKS or TrueCrypt) encrypted block at a random point on the device, then this is not something that can be detected.

For example on Linux;

Take a 100GB HDD.
Fill it with random data:

dd if=/dev/urandom of=/dev/sda bs=4K
Create an encrypted loopback device at a 'random' point on the disk:

losetup --offset $RNDOFFSET --sizelimit 5G -e aes -k 256 /dev/loop0 /dev/sda
Make your filesystem:

mkfs.ext4 /dev/loop0
And mount it:

mount /dev/loop0 /mnt/secret

The purpose of all this is that encrypted data should be indistinguishable from random bytes. This way your encrypted 5GB block is camouflaged against the random noise. Any crypto-disk headers, such as LUKS, would show clearly where the block resides, so bare encryption must be used.

Provided you keep $RNDOFFSET secret (don't go writing it to your fstab) the presence of an encrypted filesystem should be very difficult to detect.

And you can always say that the device is just a scratchpad or swap area that you use with a key that is randomly generated at each boot.


What drives security controls in cloud models: Business requirements? Or SLAs? I'm preparing for the CCSP exam and another test question is throwing me off.

The question reads:

  In all cloud models, security controls are driven by which of the
  following:

  A.  Virtualization engine
    B.  Hypervisor
    C.  SLAs
  D.
  Business Requirements

I chose C. SLAs because:

Virtualization and hypervisor answers are too technical and not in scope for the context of this question.
The cloud provider may not necessarily have the same business objectives as the customer so a business requirement for the customer may not align with the goals or security objectives of the cloud provider.
The SLA is a mutual contractually-binding document describing the extent of service reliability and the scope of overall liability for both parties in the cloud.

Example: if the cloud provider decides to sell all customer information to a customer's competitor, that would be in breach (hopefully) of the security and disclosure terms outlined in the SLA... right?

Obviously though, I'm wrong though according to the test prep material.  Could someone please elaborate?

The test prep material considers "D. Business Requirements" the correct answer.

The SLA is in place to mandate that service levels are achieved in order to meet Business Requirements. Business Requirements trumps everything else. I get your reasoning above but SLAs are not standalone and sit between the security controls and the business requirements. The SLA may be used to measure the security controls but they're in place to meet business requirements rather than just for the sake of it.


Can a SIM-less smartphone be tracked only by IMEI? If in the phone is no SIM card, connection to cell towers is at my own behest. But what about the opposite way, can the local base stations search for a specific phone through its IMEI?  Question extracted from this comment by yasserbn

Clarification: The phone does not have a SIM card and does not initiate any emergency calls. Can the base station find such phone by IMEI, say, by pinging it or otherwise tricking in to connect?

Answers at 1 only establish, that tracking is possible through emergency calls or internet connection. Can a smartphone be accessed only by knowing its IMEI? deals only with remote file access

Phones without a SIM still talk to the towers whether you make emergency calls or not. They access the cell network for time updates, if nothing else. No "tricks" required, no "finding" required. You can see this if you go into the network settings and look up what carrier the phone is connected to.

So, yes, a SIM-less phone is still very much active and, therefore, traceable.


Passwordlist generation, permutations and long passwords I was wondering what could be a way of generating a list where the passwords were like:

CorrectHorseBatteryStaple
BanjoTurtleNinjaHobo
PizzaSurfMotherMetal
etc...

I already fiddled a little with crunch but i couldn't find a way of selecting groups of words to permutate.
I thought of writing a script that run in a wordlist of english words (not counting articles and such ) and grabs 3-5 words at random and then toss them into cruch for the permutations, but i soon realized that the resulting worldlist would quicly reach a dimension beyond useful.

Maybe there is a way to just generate a fraction of the permutations for each set of words, the list wouldn't be complete but at least it could be usable.

lets say, picking 4 words at random from the first 2000 most used words ( not considering articles and such ) and permutate on those 4 words (or 3 or 5).

Running some numbers:

combinations of 4 words out of a group of 2000: 664,668,499,500 ( 664 Bilions ).
permutations of 4 words: 4! = 24

24 * 664,668,499,500 = 15,952,043,988,00 ( 15,952 Bilions ).

And that would mean something like a little over 30 PB of wordlist. (i assumed 7 bytes for each word ). Too much.

Even taking half of those combinations would mean having 15 PB of material to scan through.

Those are 50 years of non stop password cracking at a whoping 10000 words/s. No thank you.

Is there a more clever idea? I'm beginning to think that this kind of passwords are almost uncrackable.

You're 100% right that storing all possible permutations wouldn't scale very well.

An efficient way to generate all possible passphrases from a source wordlist "on the fly" (without having to store the result) is by using the hashcat project's princeprocessor:

$ cat wordlist.txt
Correct
Horse
Battery
Staple

$ pp64 --elem-cnt-min=4 <wordlist.txt | head
HorseHorseHorseHorse
HorseHorseHorseStaple
HorseHorseStapleHorse
HorseStapleHorseHorse
StapleHorseHorseHorse
HorseHorseStapleStaple
HorseStapleHorseStaple
StapleHorseHorseStaple
HorseStapleStapleHorse
StapleHorseStapleHorse

By default, the maximum password length that will be generated is 16 characters. For your use case, you'll probably want to bump that up (so that the above will work):

--- pp.c    2018-01-06 14:55:52.259441280 -0900
+++ pp.c.new    2018-01-14 18:20:51.162651928 -0900
@@ -29,7 +29,7 @@
 #define IN_LEN_MAX    32
 #define OUT_LEN_MAX   32 /* Limited by (u32)(1 << pw_len - 1) */
 #define PW_MIN        1
-#define PW_MAX        16
+#define PW_MAX        32
 #define ELEM_CNT_MIN  1
 #define ELEM_CNT_MAX  8
 #define WL_DIST_LEN   0

... and recompile:

$ make clean
rm -f pp32.bin pp64.bin pp32.exe pp64.exe pp32.app pp64.app

$ make
gcc   -W -Wall -std=c99 -O2 -s -m64 -DLINUX   -o pp64.bin pp.c mpz_int128.h

$ ls -la pp64.bin
-rwxr-xr-x 1 user user 22912 Jan 14 18:27 pp64.bin

A killer feature of princeprocessor is its ability to pick up where it left off using the -s flag, if you have to interrupt the process for some reason. It stores a restore value in the "pp.save" file upon exit, and that value can be used to resume exactly where it was interrupted, even billions of guesses in. This makes its value over a large static wordlist even better.


How to prevent from DNS spoofing in Java code which obtains a name of localhost FORTIFY static scan has detected that this piece of our java code is vulnerable to DNS spoofing attack:
public String getLocalhostName(){
    try {
        return Inet4Address.getLocalHost().getHostName();
    } catch (UnknownHostException e) {
        return null;
    }
}

FORTIFY also gives these recommendations:

Recommendations:

You can increase confidence in a domain name lookup if you check to
make sure that the host's forward and backward DNS entries match.
Attackers will not be able to spoof both the forward and the reverse
DNS entries without controlling the nameservers for the target domain.
This is not a foolproof approach however: attackers may be able to
convince the domain registrar to turn over the domain to a malicious
nameserver. Basing authentication on DNS entries is simply a risky
proposition.

The host name retrieved by this code is later saved in logs and in the database - only for audit purposes (we want to know which record in the table comes from which server). So in our specific case I think there is no any risk. But I'am courious to know an example of the scenario that is voulnerable to such an attack, because I can;t imagine any.

My questions are:

Is getting the local host name really vulnerable to such an attack ? I can't imagine such a scenario.
How to implement this check in practice (in this code snippet)?

Tkank you.

While static code analysis can improve security, it is wise to take the context into consideration. Same thing is done with vulnerability analysis reports.
In your code as written, there is no sensitive details being sent to the server (localhost in this case). So there is something else throwing the issue, and you may want to detail that.
What the analysis report is likely trying to tell you is:

verify the server through some other means before sending credentials.

This can be done with certificate pinning, which embeds a certificate chain or thumbprint into the program. Java has a built-in "keystore" functionality for this purpose.
There are libraries in many different languages that do DNS (like this one for Java), but suggesting a check on "both the forward and the reverse DNS entries" seems awkward and futile.
Again context matters as with DNS and certificate pinning, there are ways around it.
If you start with "What's the actual risk to the program I'm writing?", better answers can come about.


Changes in security measures after gaining objectively big social following in a short time period? Say you have 2-step authentications with strong and different passwords and a different email for each account and say your following goes from 1k to 500k people for example in a short period of time. Do you just roll on as before in respect to your accounts' security or do you employ changes? If the latter, what should those be?

Standard security risk assessment model would give a tentative yes to increasing security. standard model evaluates risk as the likelihood of an incident and the cost of the incident balanced the cost of reducing the likelihood or cost of the incidence.

An increase in exposure, as measured by an increase in followers, would indicate and increased likelihood of an incident (more people know you exist, and a greater value of your account to those who would steal it -- increased quantity and quality of potential attackers). Presumably an increase from 1 to 500K followers would indicate greater revenue as well, so the cost of an incident (interruption of revenue, lost goodwill etc.) would increase as well

So you would want to balance that out as long as that was doable in a way that doesn't cost more than you're making. What options are available will depend on the platform(s) you're using and the level of control you have.


Is it insecure to reveal if a password is being used for another account after a set period of time? Password reuse can be considered a pandemic of security. The obvious way to fix this is to encourage people to use password managers, but (comparatively) few people actually do.

My idea is to have websites, once a user signs up or changes their password, to check all other accounts for the same password. If one is found, after a set delay of maybe a day or so, an email would be sent to the user who signed up or changed their password alerting them of this fact and recommending they change their password.

I can imagine an immediate problem with this, which is system resources. It's expensive to securely hash passwords, and hashing a single password for comparison with thousands, possibly millions of accounts would be taxing. Another possible issue is spam, but I believe this can be fixed quite easily with email verification.

Assuming proper password storage practices, and assuming system resources isn't an issue, are there any security concerns about doing this?

To reiterate:

A user signs up or changes their password.
The system checks if that password is used in any other account. During this time, the password is stored in memory. If the system experiences a failure during this time, the check is cancelled and it is assumed the password is unique.
If it is reused, the user receives an email the next day simply saying their password is used elsewhere and recommending the user changes it.

Yes. It should be considered a breach in security to reveal this information. It deliberately the weakens security of the service. And timing is of no concern here.

It is a false premise that two users having the same password pose a security problem that should be avoided. It does not.
However revealing this very fact is a security concern which shall be mitigated by applying proper salting and hashing passwords. These precautions are meant to hide the fact that two users use the same password.
To illustrate the risk: just think what you could very well write in such an email:

Hey, we have just found that the password you registered yesterday is actually used by one of our users.
Please update your dictionaries for password crackers. And don't forget to immediately check it against our and other companies' leaked account databases.


Getting data from AWS Secrets Manager at deployment (ENV variables) vs. at run-time (e.g. aws-sdk) Given a serverless deployment of some kind (i.e. something that relies on AWS Lambda for computing), and secrets stored in AWS Secrets Manager, what difference from security standpoint is there between the following two options:

reading secrets from SM at deployment and providing them to Lambdas as ENV variables
reading secrets from SM directly from deployed functions at the runtime.

Ignore performance implications, and the need to grant one extra permission to the lambda role in the second case.

There's 3 key differences I can think off:

Using ENV variables typically means they will be in plaintext and visible in the GUI to anyone that can view the function. Reading them at run-time, means that only those principals with access to the secret in SM can view it.
If you wish to change the secret (e.g. rotate the DB credentials), then using ENV variables you'd need to redeploy the function. This is to ensure any running functions referencing the older variables gets reset.
Also, by calling SM during run-time, there will be a log into Cloudtrail of when the function pulled down the secret, but with ENV variables, it'll only be logged when you deploy the function (because that's when it was pulled down).

Now some quick caveats, even for calling during runtime, you'd typically call it during init time (outside your handler) rather than on every invocation -- otherwise you'd be charged for each invocation. But if you do this, you'll only log the first call in Cloudtrail, and you won't be able to rotate the password consistently :(. I understood RDS Proxy allows you to store DB credentials at the proxy rather than at the lambda function, but haven't explored this yet.

KMS allow for encryption of ENV variables as well -- again not something I've explored though.


What's the difference between Anti-malware and antispyware? Whats the difference between Anti-malware and antispyware ?

Malware is a portmanteau of the words "malicious" and "software". Spyware is a portmanteau of the words "spy" and "software".

In terms of the words themselves, there's little or no difference between them. One might describe spying as malicious, just as one might say that a backdoor application has spying capabilities.

In terms of technical differences, spyware is a class of malicious software that attempts to steal some kind of information from your computer, such as your personal information (e.g. name, address) or your credit card number, keystrokes, etc. It could also be something less overtly evil, such as reporting statistics about your browsing habits back to an advertising agency.

Anti-malware software usually targets the broad range of malicious software. It looks for the stuff that causes damage, loss, unauthorised access, or annoyance - essentially what a layman would refer to as "viruses".

Anti-spyware tends to focus on less of the "delete your entire hard disk" types of malicious software, and more on the "this will steal your personal information" stuff, including the less overtly evil stuff that I mentioned before.

If you're wondering if there's any difference in how they work, there pretty much isn't. The monitor file and application activities and look for things that match a signature or heuristic, then block them or report them to the user.


What is the best way to store passwords in OpenLDAP? I would like to store user credentials in an OpenLDAP or similar directory server.

A lot of online commentary about storing passwords in modern contexts recommends using password derivation schemes like PBKDF2, bcrypt and scrypt. It looks like OpenLDAP offers salted SHA1 as it's "most secure" storage option.

Two questions:

Is Salted SHA strong enough to protect passwords in the event of compromise?
What are my options for hardening password storage on OpenLDAP?

Ok, so I found some resources that are helping me to answer my question.

There is a module that allows you to use PBKDF2 with either SHA1, SHA256 or SHA 512. This is probably the best solution for most situations. (See: https://github.com/hamano/openldap-pbkdf2 )
Alternatively, you can use the local Unix/Linux crypt facility, and configure OpenLDAP to salt the passwords. YMMV will vary by platform. AlgorithmsAvailable hashes on RHEL 7.1 include MD5, Blowfish, SHA-256 and SHA-512 according to the crypt(3) manpage.

For my situation, salted general purpose hashes don't cut the mustard, so the first option is the best solution.


How secure is Google’s/Android’s Smart Lock functionality? Newer Android phones (since Android 5, “Lollipop”) have the Smart Lock functionality that allows one to unlock the phone, among other ways, with a trusted device (Bluetooth or NFC) instead of entering the usual PIN, pattern or password.

I’m asking about NFC in particular. How secure is Smart Lock when configured to unlock the phone when a specific NFC tag is activated?
I’m worried that someone could simply create an NFC tag with the same ID as mine (since NFC activates just by touching something, it’s very difficult to protect an NFC tag from being read at all times).
Note that I’m not asking about the case where my NFC tag is stolen – obviously, my phone would no longer be safe in that case.
What I’d like to know is how secure the technical implementation is, i. e. how can Smart Lock be sure that it’s really my NFC tag and prevent being fooled by something pretending to be my NFC tag.

In my case, the “NFC tag” is my YubiKey NEO. Their FAQ page makes some worrying statements:

  Can the YubiKey NEO be used as a Smart Lock device for Android Lollipop?

  Yes, the YubiKey NEO can be used as an NFC tag registered for Smart
  Lock on Android Lollipop devices. For more information, see the
  Android support page.

  Note: Android’s SmartLock features uses a static 7 byte ID, which does
  not conform to Yubico’s security threshold standards. We recommend
  users consider this feature a convenience and not a strong
  authentication replacement.

If someone was to touch and read your NFC tag with the intention of cloning it, then they can do so and fool your phone by cloning the NFC tag.  The phone relies on the tag's UID but this too can be cloned (you can get UID changeable tags from places like Alibaba).

Some specialized NFC tags & readers use certain tricks to protect against cloning using some proprietary techniques which makes them limited to that brand.


Chicken-and-egg-problem: What's the intended secure way of installing anti-virus software with online installers? In various places (notably, the English Microsoft Answers forums1), people are quick to note that a Windows machine should not get connected to the internet without any anti-virus software installed. Otherwise, infections are said to happen within minutes by means of built-in security flaws.

At the same time, some anti-virus software is following the current trend of providing only online installers2. These installers are only tiny packages that will download the required installation data on the fly once started on the target machine. Obviously, these won't work without an internet connection.

What is a safe procedure for setting up malware protection on a new PC when I should not connect to the internet before having the malware protection in place, but cannot install the malware protection without connecting to the internet?

1: e.g. in this thread: "A computer should NEVER be connected to the internet for extended periods (i.e., long enough to run a manual check for updates or for Automatic Updates to download/install needed updates) without a valid, fully-updated anti-virus application installed."

2: e.g. Avira's Free Security Suite provides an installer for the suite umbrella control center, from where the single security tools can be installed - but only with an internet connection. Even the offline installer will install something that will remain disabled until you activate its license ... via the internet.

Disclosure: I work for an anti-virus vendor.

First, the answer. Most vendors which I'm familiar with usually offer "full" or "offline" installers of their products. Typically they are usually more difficult to find (i.e. no link on homepage - in some cases you might need to ask support), but they do have them. In my experience it is usually easier to find those files by Googling av-vendor-name offline install - the web sites it finds are usually not the vendor site (so make sure to do this on a machine with AV installed), but they usually provide direct links to the vendor's own website, and those you can download from.

Note that the main purpose for providing them is not a "chicken-and-egg problem", but to install on disconnected or very slow speed environments and to save traffic when you need to install the product on several machines - since the online installer would download it again and again.

Second, I would not agree with a premise that "Windows machine should not get connected to the internet without any anti-virus software installed". This is only true if your connection to Internet is direct - meaning you plug your DSL/cable modem, set in bridged mode, directly into your laptop Ethernet port, and it gives you the public IP address (and gets you blasted right away via EthernalBlue or something similar). This configuration is quite rare though.

If you are behind a NAT router, which does not forward any ports - which is more of a typical default configuration - your Windows machine is relatively safe as long as you are not doing anything dangerous on it, such as:

Browsing random web sites;
Setting up and opening emails;
Inserting various storage media (such as USB sticks or CD/DVD);

and so on (using Calculator or playing Solitary is unlikely to get you infected)

So after installing Windows, you do have the opportunity to open a website of the anti-malware vendor of your choice, and install the anti-virus without compromising security of your PC.


What prevents me from using ARP poisoning to force a client to use HTTP? So I was just thinking about how ARP poisoning can be used to intercept a clients request, forge an SSL cert, and send it back, with the caveat of not meeting certificate validation, but what if I were to intercept a client communication, send back a 301 to the http version of the site if the request is SSL, and then act on behalf of the client when communicating with the legitimate server over HTTPS.

if the client believes that I am the router, how would the client ever know that it has been forced to HTTP?

Obviously the browser bar would be white, not green, but that is almost a moot point regardless.

If the client's initial request is for HTTPS, then the client will insist on first doing the SSL handshake, and only then, within the newly created SSL tunnel, will the client send the actual HTTP request, the one you want to respond to with a 301 code. This means that if the client entered the https:// URL (either he typed it, or followed a bookmark which includes it), then, as an attacker, you still have a SSL thrown against you.

Of course, if the client is prone to click through the "friggin' browser warnings" then all bets are off.

Similarly, if the client always types the raw server name, and expects the server to receive the HTTP request and send back a redirect to HTTPS, then you can intercept that redirect and keep the client on a pure-HTTP fake site. It always bring us back to the client and what he is ready to accept. If the client performs an HTTP (not HTTPS) request at some point, and won't notice the lack of padlock icon or green URL bar, then you can leverage that single point of vulnerability to keep the client in a non-SSL world, intercepting all attempts at redirection to SSL. Automation of this attack has been demonstrated under the name sslstrip.


What is the use case of request signing in this mobile app? The API of a mobile app I was testing is sending the AWS AccessKeyId and SecretKey used for request signing from the AWS Cognito server unencrypted (apart from the regular TLS encryption). Making it possible to re-sign all requests to their AWS Lambda API, e.g. using Burp's "AWS Signer" extension.

With this, a Man-In-The-Middle could sign all altered requests, so I wonder what the actual use case of request signing is, in this instance?

Shouldn't the AccessKeyID and SecretKey be kept secret?

The owner of the app is telling me that this is not an issue because they are following the AWS guidelines.

Is that correct? Or are they doing something wrong?

Why would they sign the requests in the first place in their mobile app?
What is the use case of signing the requests, when the 'secrets' for creating a signature are distributed via the same connection in clear (except TLS)?

Is this conform with best practices, when using AWS Lambda for serverless mobile app APIs? Is request signing even useful in this instance? Most apps I have tested didn't use request signing.

Shouldn't the AccessKeyID and SecretKey be kept secret?

According to this:
Yes, they should be kept secret.

With this, a Man-In-The-Middle could sign all altered requests, so I
wonder what the actual use case of request signing is, in this
instance?

According to this
AWS access key ID is a form of unique user/account identifier
And
AWS secret key is like private key
So the signing is a way to authenticate\identify a user

Why would they sign the requests in the first place in their mobile
app? What is the use case of signing the requests, when the 'secrets'
for creating a signature are distributed via the same connection in
clear (except TLS)?

The reason why they designed it like this we would never know, but sending such a sensitive information in cleartext is not a good idea. However, according to this
The request is not signed with the secret itself, but with a signing key which is generated using the secret. It also uses HMAC-SHA256 for signing.

Thus, The AWS latest authentication mechanism simply will not accept secret key. It authenticate API requests based on the aforementioned way.


Attacks on encrypted computer? I think we all know the fact that boot-harddrives can be encrypted.
Windows usually uses Bitlocker (relying on AES-CBC) and Linux / Unix usually uses dm-crypt (relying on AES-CBC) and the rest of the software usually uses XTS-mode (TrueCrypt, BestCrypt,...).

Now, there's the potential for bitflip attacks with CBC.
My first thought was to use this for DoS, by simply flipping any bit of either the drive's salt or of the log-in hashs. Would it be possible, by flipping a single bit (multiple bits), to deny access from any legitimate user?The computer can be considered shut-down as of time of acquiration.

Are there any attacks, exploiting the bit-flipping property of CBC, to break the security of the targeted computer?
A security break can be a DoS, a placement of an exploit or similar.

As far as I understand, bit flipping attack applies if you can see the decrypted output. Thats how you can manage to obtain desired plaintext changes step by step.

Look at the Evil Maid attack if you want to see an example of full disk encryption defeat.

Causing the DoS is easy as you can alter the key slot (you can know where it's located easily), the legit passphrase will be unusable after that.

With LUKS, for example, your passphrase for unlocking the drive is derivated and the key obtained can decrypt the master key stored in a key slot. That scheme allows you to have multiple passphrases at the same time being able to unlock the drive (for multiple users without the need to share the passphrase) and to change the passphrase without the need to decrypt-encrypt all the disk again. If you alter the encrypted master key(s) (in their key slot) passphrase(s) become(s) unusable and indeed, the data is lost (DoS).


They think I am their IT Dept....What to do about it? I have been asked to test out any security holes for a company. I created an email account that looks similar to their IT department's address and everybody is complying :)
I have only asked them to send me some simple things like their WAN IPs.
I want to take it a step further though, perhaps some backdoor access? or a few files off their computer?
Nothing malicious, white-hat stuff etc..

What do you guys recommend I ask for in the next email?

First off what you're doing sounds like a pen. test/security test.  It's very important when doing this kind of testing to ensure you have a signed off scope document from someone in authority at the company you're testing, as without that you could do something that the company wouldn't be happy with.  Also without authorization from the company some actions will be in breach of local cybercrime laws.

So assuming that you've got a general authorization for "social engineering" style attacks, it would depend on your goal.

Asking a user to open a file which gives you access to the internal network would be one option (using something like SET or Metasploit to generate the payload
Ask a user to provide your their password.  Depending on your scope again if successful you could then use this to access things like webmail systems to prove that attackers can gain unauthorised access to company information in this way.


Best way to save username/password programatically I have a requirement to programmatically save a username and password on the local workstation and retrieve them back.

What would be the most secure way of doing this?

I have used DPAPI in the past with success but it looks like DPAPI uses 3des which has been deprecated.

Would CNG-DPAPI be the better choice?  Any other methods that would be more secure?

Thanks, Mike

3DES has not been deprecated, nor has DPAPI. While the 3DES algorithm is not ideal and should not be used in new designs where avoidable, the best attack we know against is is a meet-in-the-middle attack which requires 512PiB of error-correcting RAM and 2112 + 256 operations. Considering other possible attacks against DPAPI, e.g. using the mimikatz DPAPI module on a running system, this seems rather outlandish.

CNG-DPAPI (which is called DPAPI-NG now) would be a better choice for modern designs. Unfortunately the examples out there are fairly scant, leaving you to work a lot of things out on your own. The following is a high-level example of how you might implement secret storage using DPAPI-NG:

Call NCryptCreateProtectionDescriptor with dwFlags set to 0 and pwszDescriptorString set to a protection descriptor string. To protect the data such that only the current user can access it, use "LOCAL=user", and for machine-wide protection use "LOCAL=machine". You can also encrypt to a set of web credentials under an ASP context, a certificate from the certificate store, a domain user by specifying a SID, or you can specify a fully custom security descriptor using SSDL.
Call NCryptProtectSecret, passing in the handle you got from the above operation, in order to encrypt small amounts of data (e.g. a credential string)
Call NCryptStreamOpenToProtect if you want to encrypt a lot of data. This opens up a stream that you can write data into via NCryptStreamUpdate.
Call NCryptUnprotectSecret in order to decrypt data that was encrypted with NCryptProtectSecret.
Call NCryptStreamOpenToUnprotect to decrypt data that was encrypted with NCryptStreamOpenToProtect. Again, NCryptStreamUpdate is used here.
If you used any of the stream functions, call NCryptStreamClose to close them.
Call NCryptCloseProtectionDescriptor to close the protection descriptor handle you created in the first step.

DPAPI-NG is still affected by tools such as mimikatz, but that's just an inherent part of how operating system security works - if an attacker is running code as an administrator, they have won.

The old API for DPAPI is much simpler, but the new API has more comprehensive support for different security scenarios as described above. The cryptography in use is certainly not the weakest link in the chain for either API.


What type of attack is the below SQL injection? Today in the apache access log I saw something like this

https://xxxxx/xxxx/xx/something.html' or (1,2)=(select*from(select name_const(CHAR(103,119,111,107,69,82,84,99,118),1),name_const(CHAR(103,119,111,107,69,82,84,99,118),1))a) -- 'x'='x.html

t's an SQL injection attack but I am not able to figure out what the attacker trying to do.

And also the ascii Representation of the characters correspond to "gwokERTcv" what does this mean?

This is a pretty basic scan attack that can determine a couple of things on your system without much effort.

Is your system running MySQL
Will your system parse the SQL statement and return a value.

If your server responds appropriately to the command, the attacker knows that they can manipulate your database and potential exploit your system. Uh oh.

The good news is this is just a scan. Take it, see if you can make the command work on your own and learn how they want to attack from there.

More information on this can be seen here:

https://firegenanalytics.com/2017/12/splunk-review-121017/

-- Edit --

I just wanted to point out that they weren't trying to get anything from your database. They just attempted to create a temp table with some columns and values for their temp table to perform a command assessment. The values don't really mean anything.


Session id remain same after and before logging in asp.net application Before logging in to the asp.net application, i checked the headers and there was already a session id in cookie header
cookie: ASP.NET_SessionId=3de0es3brpfbcmvkzhkidsmt

And when i logged in to the application, the same cookie header was present there. When i send a request by removing this cookie header from the request, i am logged out. So my question is what is happening over there? Is it some bug? Please elaborate. Thanks

Not a bug, the Session Cookie is created regardless of 'user' authentication. The sessID cookie is ONLY an Identifier (X Client has X Cookie). Once a user has been authenticated with the server you may continue to use that cookie to identify the authenticated user.


Unknown android device connecting to my wireless router even after changing wifi key several times An unknown android device is connecting to my wireless router even after changing the wifi key several times.
How is this possible?
My router admin page doesn't have a password set.
Even though how is it possible to access the admin page before connecting to the wifi.

Yet another question asking for help that got unfairly downvoted by an anonymous coward who didn't bother to help. Upvoted and FTFY.

Anyway, now for the answer. You mentioned your router admin page isn't login protected. Rookie mistake, right off the bat. If the owner of the unknown device knows the manufacturer and model of your router, it becomes trivial to look up the config instructions for the router, navigate to the admin page, and change various settings, including the router key.

Intuitively, there should be a chicken-and-egg problem preventing access even if you have a setup like that: the unknown device doesn't have the router access info, so it has no way of getting on the network to access the admin page. However, this becomes a problem if your router allows open access through some misconfiguration (Veroxi's comment provides a good example).

I have no idea if your router supports MAC-address banning - if it does, you could see if you can find access information, find the MAC address of the offending device, and ban it.

Finally, as Daniel E. said, use a good encryption and authentication scheme. The modern standard is WPA2. In particular, stay away from WEP. Most modern routers will use WPA or WPA2 by default if you setup the router to require authentication.


Staying logged in as a user for remote access (such as Team Viewer) Pros & Cons This company we newly help have no remote access policy for say, but they allow the users to use Team Viewer.  I have noticed some user leave their PC logged in all night and weekends and just shut the screen to save time at login.  So they can open Team Viewer, login and voila there in.

*Keeping in mind that:

We have re-vamped their password by giving the maximum Team Viewer password strength possible/allowed by Team Viewer (length, characters, etc.)
The office is physically secured, so let's not worry about someone sneaking in and such.

What would be the true Cons?  The pros are mainly for end user to save time...

There still are two risks even with good password strength and good access control in the office.

Even if Team Viewer pays high attention to security, there is still a possibility of the program being compromised, as in remotely exploitable by some kind of vulnerability. PC's staying on in the week-end would allow an attacker to freely use the exploit while the guy supposed to monitor security is doing a BBQ with his friends.
The access control might be as good as you want, but if the threat comes from inside it is useless. Let's say the manager is on a business trip and lets his pc on to access with TeamViewer from his laptop, John who is a bad guy, wants access to said manager's info for whatever reason, he can stay in office until 7:30pm and wait until everyone has gone home and have fun with the manager's data.

Except for this, AFAIK it should pose no problem. It is a matter of how much you trust Team Viewer and how much the company trusts its employees.


what do you do when an ssl certificate expires and your app uses ssl pinning? I originally posted this question on StackOverflow, but reposted here due to lack of responses.

I am trying to decide if it's a good idea to do ssl pinning in my iOS game that uses a server to deliver content. It seems like it's important, but the one thing that is really bothering me is the thought of the day that the certificate expires. Since the certificate has to be included in the app bundle, this means there will be a point where users will be forced to upgrade. Depending on what Apple is doing at that time, might mean they can't upgrade due to device / os constrictions. So, I am really nervous about putting this in.

Has anyone had any experience with ssl pinning and expired certificates, making this a seamless, no-down-time thing for your users?

Your application could store multiple certificates in its pin list. The procedure for changing the cert would then be:

Some time before the certificate expires, release a new version of
your app with a replacement cert in the pin list, as well as the
original cert
when the old certificate expires, replace it on the
server - the app should then still work as the new cert will already
be in the pin list
Some time after the cert expires, release a new
version of your app removing the old cert

This should reduce the risk of service interruption but does not remove it completely, since some users may not install the new version of your app.

Also, it may not help you in cases where you need to change the server cert in a hurry (e.g. you think the cert may have been compromised).

I have also heard of people who have allowed their applications to update their pin list when connecting over "more trusted" networks. For example WiFi would be less trusted than 3G/4G since it is must cheaper and easier to do a man in the middle attack on WiFi.

On balance and from an operational perspective, I think certificate pinning causes more problems than it solves unless your data is particularly sensitive and confidentiality/integrity significantly outweighs availability in your list of concerns. (I realise I might get some downvotes for this view).


Permissions for Azure OMS Agent files I have two files that the Azure OMS agent reads/writes from that are world writable files.  Our vulnerability scanner (rapid 7) is picking these up as vulnerabilities. It's also poor practice in general.

/var/opt/microsoft/omsagent/{subscriptionid}/state/contentlocationcache.cache
/var/opt/microsoft/omsagent/{subscriptionid}/log/ODSIngestion.status

File permissions are respectively set to:

-rw-rw-rw- 1 omsagent omiusers
-rw-rw-rw- 1 omsagent omiusers

If I change the permissions to

-rw-rw---

I am unable to get scan data back from the device.  Does anyone know the permissions these files should be set to?  Microsoft doesn't seem to have documentation on these permissions in general.

It should be -rw-rw-r--. The vulnerability scan is warning you that every other shouldn't write (w) on this file.


ROP payload layout confusion I was reading an article (exploitresearch.wordpress.com) about using ROP to bypass DEP/ASLR. Near the end he lays out the 33 steps for his payload. These are layed out in the order that the shellcode instructions are written in the final payload (also shown in the last HxD image @ offset 304). I am a little confused by the first few dwords:

1) 0x100016f0 (pop eax)
2) 0x01a19f7f (a value)
3) 0x10002fd7 (pop ecx)
4) 0x100bcc5a (another value)
5) mov [ecx], eax (*0x100bcc5a = 0x01a9f7f, delta between GetTimeZoneInformation and VirtualProtect)

How does pop eax followed by the address of a value save that value into eax? I thought you had to push the value then pop eax.

There's no need to perform any push operations since you control the stack already. You can have the data you wish to store within your registers already placed where you can conveniently perform operations with them.

In ROP, you find a series of useful code snippets present already within your target program that you can refer to as gadgets, which are typically the tail ends of normal subroutines that do operations you need for successful exploitation. You line up the addresses of the gadgets you wish to execute and the data you'd like to use with them inside a fake stack in memory you control before you perform a "stack pivot" to move your stack pointer (esp in x86) into your data.

After the stack pointer has been moved into your data, control of the program will be forfeited to your fake stack at the next ret. When this instruction executes, the top word/address on the stack (0x100016f0 in your example) will be popped of, and placed into the program counter to redirect it into a gadget on the tail end of some function looks like pop eax; ret;.

Where the next word on your stack is 2) 0x01a19f7f (a value), your stack pointer would already be pointing to this data when the pop instruction executes, storing this word inside your eax register.

Then, the ret to immediately follow pops off your next ROP gadget address to continue on in execution.


Why does Amazon ask for the CVC/CVV if it bills without it? I have a follow-up question relating to this question:

How does Amazon bill me without the CVC / CVV / CVV2?

If amazon.com can bill without the CVV why does it ask for it the first time information is entered?  Maybe they just silently discard it?  Maybe the first transaction you ever do utilizes your CVV but subsequent ones don't?

I was looking at the specs for a particular payment gateway and one thought I had based on that was that maybe amazon.com could be doing a pre-auth for $0.00, with the CVV / CC#, getting a transaction ID for that and then passing the transaction ID to the payment gateway on all subsequent calls, charging a different amount each time?

TylerL already answered this on the related question; when you add a new credit card to your account, they ask for the code once to confirm that the card is physically present in the moment of adding.

This gives them a little more confidence that the card is legit, but still lets them offer one-click purchasing, etc.


Is it possible to have multiple key lengths in PKI? Is it possible to have multiple key lengths in a PKI? For example, use a 1024-bit key for the issued certificate, a 2048-bit key for the intermediate certificate, and 4096-bit key for the root certificate? I don't know a lot about PKI, but does this make sense?

Yes, each certificate stands on its own, and can be any bit length without any connection to the length of certificates which it signs or which have signed it.

And yes, it may make more sense to have a root certificate, which is used rarely but requires more security, be a longer key length than a web server certificate, which is used often and where the computational speed has an impact.


How to prevent replay attacks without exposing stored password security? A common way to prevent replay attacks when logging in is for the server to present a challenge (chall) and request a response in the form hash(chall+secret) where the secret is already known by the server, and can be determined from the user's password (e.g. password hash).

However, as far as I understand, that means that in the event of a server data breach, the data stored on the server (hashed password) is enough to complete the challenge, nullifying the reason why passwords are stored hashed in the first place.

How can this problem be solved?

... the data stored on the server (hashed password) is enough to complete the challenge

What you describe is a known problem with digest authentication.

An alternative might be to use digital signatures. In this case the client creates a key pair, keeps the private key and publishes the public key. When the client should authenticate itself the server sends a challenge to the client and the client signs this challenge using its private key and sends the result back to the server. The server can verify that signature using the known public key and thus can be sure that the client owns the secret private key. This secret key gets only stored on the client side.

Basically the same mechanism is used with client certificates (mutual authentication) in TLS. And TLS also adds protection against man in the middle attacks and against sniffing or modifying the traffic. So it is probably better to just use TLS with client certificates instead of implementing this by your own.


Cannot exploit stack-based buffer overflow with ASLR-disabled, since RSP differs heavily between executions? I have made a little toy program, compiled with ALSR disabled, that I want to exploit using stack-based buffer overflow:

// gcc stackexec0x1.c -Wl,-z,execstack -no-pie -fno-stack-protector -o stackexec0x1

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define SBUFSZ 0x100
#define LBUFSZ 0x800

int main(int argc, char* argv[]) {
    char buf[SBUFSZ];
    printf("# ");
    fgets(buf, LBUFSZ, stdin); // exploit this!
    printf("%s", buf);
    return 0;
}

I can easily overwrite the return address, saved on the stack, with a custom one. However, between consecutive runs of the program, the rsp register (just before ret) differs:

0x7ffdc114dc88
0x7ffeb97d5668
0x7ffd48027798
0x7ffdbf2e9ea8
0x7ffe036a5d78
0x7fff40595998

Computing the differences between the aboversp register values, one can see they are big. It would not be feasible put a NOP-sledge that covers most of them on the stack?

How can I conveniently choose a return address into the NOP-sledge + payload on the stack, so that it's executed (with high probability), when the function returns?

checksec:

checksec stackexec0x1
[*] '/home/nlykkei/exploit-dev/stackexec0x1/stackexec0x1'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x400000)
    RWX:      Has RWX segments

The GCC -no-pie option partly disables ASLR: the binary will be loaded at fixed base address (i.e. 0x400000); however, other memory segments (e.g. stack) may still be loaded at random base addresses.

To completely disable ASLR, you need to disable it system-wide using:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Now, the stack will be loaded at a fixed base address. The addresses below are values of rsp just before ret in main (examined using r2 -d):

0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8
0x7fffffffdfb8

Given this, it should be easy to choose a target address into your NOP-sledge.


Is it possible to reverse a sha256 hashed value if we know part of the input value? I'm a total noob, so please help me out.
Suppose something is hashed in sha256. If we know the value of some part of the hashed text, can we figure out the entire text?
Ex: xxxxxx + j4l58jl6j4l6j4 = 64j1l5l64lkh41l654kj165l4j1566ghj6ghj6g1.

All are hypothetical values. So, we know that the value on the right hand side is the final hashed value, is it possible to figure out the value of xxxxxx?

Can we Calculate/Figure out/Find out? = NO
Can we efficiently Bruteforce? = YES
--- ANSWER BELOW IS FOR BRUTEFORCE ---
By the design of Cryptographic Hash Functions, they are 'one way'. i.e. can not be reversed.
But just in case you stumble upon this scenario (super rare in real-world and common in CTFs).
You can use Hashcat(tool) to Bruteforce with masking to bruteforce just initial characters.
E.g.
Hash (sha256) = c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38
Plain Text = XXXXh_Example
(X - Unknown)
Constraint = printable ASCII and Numbers
Hashcat mask = ?a?a?a?a
Hashcat mode = 1400 (SHA2-256)
command =
hashcat -m 1400 c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38 -a 3 ?a?a?a?ah_Example

so this will reduce the time significantly while brute force. Try the above example
you might see something like :
x64mayhem$ hashcat -m 1400 C0489750C13B64906237515B5B944E0D9FE9380DFC2F60CC29CA2C88514C0A38 -a 3 ?a?a?a?ah_Example
hashcat (v5.1.0) starting...

...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce MX150, 500/2002 MB allocatable, 3MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
...
<snip>
...

Approaching final keyspace - workload adjusted.

c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29ca2c88514c0a38:hAa5h_Example

Session..........: hashcat
Status...........: Cracked
Hash.Type........: SHA2-256
Hash.Target......: c0489750c13b64906237515b5b944e0d9fe9380dfc2f60cc29c...4c0a38
Time.Started.....: Mon Aug  3 09:02:41 2020 (4 secs)
Time.Estimated...: Mon Aug  3 09:02:45 2020 (0 secs)
Guess.Mask.......: ?a?a?a?ah_Example [13]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 15592.6 kH/s (0.11ms) @ Accel:128 Loops:32 Thr:256 Vec:1
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 48369440/81450625 (59.38%)
Rejected.........: 0/48369440 (0.00%)
Restore.Point....: 0/95 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:509120-509152 Iteration:0-32
Candidates.#1....: hAaeh_Example -> RWj h_Example
Hardware.Mon.#1..: Temp: 51c Util: 61% Core:1721MHz Mem:3003MHz Bus:4

Started: Mon Aug  3 09:02:38 2020
Stopped: Mon Aug  3 09:02:45 2020

*on GPU


Certificate Transparency Android For iOS-Apps, it is possible to use Certificate Transparency as stated here. We are developing native Apps for the different mobile platforms and are discussing to establish a more secure way of handling SSL-certificates.

Does anybody know if there is a similar way by Google to integrate Certificate Transparency into Android or make it usable by Android-Apps? At the moment, it seems that there is no implementation for Android and on certificate-transparency.org, there is also no Java-Client implementation that could be adopted (directly).

Although Conscrypt has code to support Certificate Transparency there doesn't seem to be an easy way to use this in an app as Google don't expose the API. It is possible to use Conscrypt as a dependency however this isn't necessarily right for every app with its use of native libraries that need bundling and the need to set custom system properties.

I have been involved in writing the open source https://github.com/Babylonpartners/certificate-transparency-android to alleviate some of these issues whilst providing easy configuration for use with OkHttp, HttpUrlConnection and Volley. You simply specify the domains you want CT to be enforced with and the library takes care of everything else, such as getting hold of an up-to-date log list.


How can I check that my cookies are only sent over encrypted https and not http? I read a blog post GitHub moves to SSL, but remains Firesheepable that claimed that cookies can be sent unencrypted over http even if the site is only using https. They write that a cookie should be marked with a "secure flag", but I don't know how that flag look like.

How can I check that my cookies are only sent over encrypted https and not over unencrypted http, on my site that is only using https?

The cookies secure flag looks like this:

  secure;

That's it.
This should appear at the end of the Http header:

  Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly;

Of course, to check it, simply plug in any proxy or sniffer (I use the excellent Fiddler) and watch...

*Bonus: I also threw in there the httpOnly attribute, protects against cookie access from Javascript space, e.g. via XSS.


How unwise is it to exclude WSL from Windows Defender? Windows Defender often takes up a significant amount of CPU time due to I/O operations in WSL. For example, if I'm working on web development and using tools like npm or yarn, downloading packages takes a considerable amount of time as compared to when I disable Windows Defender real-time protection. This is also the case with Android Studio for mobile development.

As an alternative to disabling the anti-virus completely, this article suggests adding WSL to the list of exclusions:

https://medium.com/@leandrw/speeding-up-wsl-i-o-up-than-5x-fast-saving-a-lot-of-battery-life-cpu-usage-c3537dd03c74

Having done that, I noticed an improvement—the same as when I disabled Windows Defender.

However, I'm really concerned about the security implications of doing this. In particular:

I have public and private ssh key pairs in WSL that are used to authenticate my GitHub. If someone were to gain access to these, they could potentially do some nasty stuff.
WSL itself has access to the Windows file system. I have limited information security knowledge, but I see this as something to be worried about.
Some researchers have suggested that it's possible to use "Bashware" in WSL to exploit Windows security vulnerabilities.

So I'm at a crossroads. I either have to suffer an extreme loss of productivity or potentially expose myself to malware. What are my options here?

It really depends what your risk profile is. Is this your personal computer or one you use for work? Are you behind a corporate network/firewall or just on your home network?
What's the worst thing that could happen if you did download a virus on WSL? Remember malware on WSL can still access the rest of your computer. While there isn't as much malware for linux (or WSL) it doesn't mean they don't exist so this is something you would need to take into account. If you are just downloading NPM/YARN packages you might be okay but it is still possible to inadvertently install malware from NPM packages.
Some options you could consider to mitigate the risk:

You could just do the odd malware scan to make sure you are okay
You could set up a linux VM on your machine and do your dev in there. This means any malware you might download during development wouldn't affect the rest of your machine.
You could set up some Linux VMs elsewhere to you (e.g. AWS EC2 instance). If you make sure they are immutable (aka you can easily kill one and start a new one and just continue) you wouldn't need any VMs locally, your local machine is safe and you can easily blitz the VM and start a new one if you wanted to.


Is SQLi via a "Long" variable possible in Java / Hibernate? I'm taking a look at an webapp source code and, although the dev has been careful enough as to use prepared statements to fill in the query's "String" parameters, he/she has filled all the query's "Long" parameters using simple concatenation.

  Example:

Obs: status has type String, var1 has type Long

Query query = entityManager.createQuery(
            "SELECT UPPER(request.attributeValue) FROM PreOrderedRequests request
             WHERE request.status = :status AND request.report.id = " + var1);

I know he/she should not have done that, but my question is: has anyone here seen an actual exploit for that? How would one take advantage of this behavior?

For the suspicious ones: I'm not hacking anything. Just a friend of mine that asked me to take a look at this specific piece of code.

In your Java example:

Query query = entityManager.createQuery(
        "SELECT UPPER(request.attributeValue) FROM PreOrderedRequests request
         WHERE request.status = :status AND request.report.id = " + var1);

If var1 is a byte, short, int, long then there is no security exploit. These will be interpreted by the SQL server as the developer intended.

If 'cached prepared statements' is enabled, then such code would degrade the cache's effectiveness, but that would not qualify as a security issue.

If var1 were a double, float or char then an attacker could likely cause an SQL syntax error (with Infinity, -Infinity or some unexpected charactor), but it would be rare for that error to become a usable SQLi attack. This would primarily be a means of gathering information. (i.e. error pages could reveal a vulnerability in some edge cases)

If var1 were a String it is obviously a serious issue.

If var1 were some other Object, then the risk would depend on the Object's toString method. (i.e. Integer is safe, but CharSequence is unsafe, and Collection is probably unsafe)


Replay attacks and PGP email encryption From my understanding of PGP email, the following is possible:

Alice sends a message to Bob. Then Bob can take that exact same message and send to Carol while making it seem to Carol like it is from Alice to her.

This could be prevented if the standard were to also sign the recipients along with the email.

My question is: is there a standard practice to protect against such replay attacks?

Your argument is valid, with Sign & Encrypt method, the 2 layers are independent and this gives you (as Bob) the ability to re-encrypt Alice's message while the signature is still in place and forward it to Carol.

One other option would be to Encrypt then Sign but there's also a vulnerability in this approach. Bob or any eavesdropper can remove the signature and add his own signature. Without knowing the contents of the encrypted message he can impersonate himself as the sender of the message.

There are numerous discussions on SE so I won't get into them. e.g: Should we sign-then-encrypt, or encrypt-then-sign?

The solution has to add a binding between the signature and the encryption layer because the vulnerability lies in the gap where these two independent layers are.
And as you said we could add the recipient's address into the encrypted part of the message.

In this Page (Defective Sign & Encrypt in S/MIME,
PKCS#7, MOSS, PEM, PGP, and XML ) in section 5, five repair options are proposed:

  Sign the recipient's name into the plaintext
  Encrypt the sender's name into the plaintext
  Incorporate both names
  Sign again the signed-&-encrypted message
  Encrypt again the signed ciphertext.

For Naming Repairs solutions:

  Perhaps part of the reason naïve Sign & Encrypt seems secure is that with many common payload messages, S&E is secure. For example, even if Alice just signs and encrypts the text ``Dear Bob, The deal is off. Regretfully, Alice,'' then Alice's message is secure, albeit only accidentally so. The presence of names under both crypto layers is crucial, but including both names is not strictly necessary

Using Sign/Encrypt/Sign:

  Inner Signature: "Alice wrote the plaintext;"
  Encryption: "Only Bob can see the plaintext;"
  Outer Signature: "Alice used key B to encrypt."

Using Encrypt/Sign/Encrypt:

  First Encryption: "Only Bob sees the plaintext;"
  Signature: "Alice wrote the plaintext and the ciphertext;"
  Outer Encryption: "Only Bob can see that Alice wrote the plaintext and ciphertext."

You can also find the analysis of cost/benefit under that link, the simplest repair is adding recipient's address to the plaintext and then Sign and Encrypt.

Going back to your main question, there seems to be no standard implementation for PGP clients to add/verify recipients address in the ciphertext, so one could go ahead and manually add/verify the address into the message body.


Email Compromised due to Yahoo Mail Exploit On Monday due to XSS vulnerability present in the Yahoo mail my email has been compromised. I have immediately changed my password but i am not sure is this enough i.e. do i need to delete my cookies and whatever else.

Changing your password is enough to prevent them from regaining access to your Yahoo mail account.  While you're doing it, you may want to change your security questions/recovery questions, and set up a mobile number for password resets.  You should not need to delete your cookies (though you can if you want).

If you used the same password on any other site, change it on the other site as well.

In principle, there are some ways that the hacker might have been able to access other accounts you have on other websites.  First, if you stored the passwords for other websites anywhere in your inbox or any mailboxes on your Yahoo account, then an attacker could have viewed them.  Second, if you use your Yahoo email address as the email address for accounts on other websites, then the attacker could have used the password reset functionality on those other websites to gain access to your accounts on other websites.  There's probably no good way to know for sure if either of these happened.  If you are concerned about this risk: log into every other account you have on every other website, and change the password on each of those accounts to something new.  Yes, I realize this is a serious pain, so you'll have to judge for yourself whether it's worth doing or whether you want to just take the risk that the hacker didn't get access to any of your other accounts.


Botnet fingerprinting Does anyone know of any research of papers on fingerprinting botnets?  If a given target is being brute forced or DDoSed do methods exist to determine if a brute force or DDoS on another target are coming from the same botnet?  Based on geography of the nodes and time of day given nodes are attacking?  I'm talking prolonged attacks.

Sorry to post a page of links, but you will find a ton of research at this link:

http://www.cyberwarzone.com/understanding-and-mitigating-ddos-attacks-tools


Why is using [x] to generate random keypairs a bad idea? Anyone who has generated large GPG public/private keypairs has come across this annoying message: "Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!"

Searching for answers, you will often find answers such as these:

  Use rngd -r /dev/urandom [1] [2]
  Install and use rng-tools [3]
  Make a symlink so /dev/urandom is used instead of /dev/random [4]

After which you find a comment (usually with a distinct lack of explanation, just a violent outburst):

  Oh my god, that's a horrible idea!!

Why are these alternative methods of generating random keypairs a bad idea? What makes waiting for /dev/random to finish so much more secure?

rng-tools acts as a bridge between your computer's hardware random-number generator (if it has one) and /dev/random  If you trust your computer's hardware RNG, there's nothing wrong with using it.  If, on the other hand, you don't have a hardware RNG, rng-tools can be used to make the kernel think there's more randomness in its entropy pool than there actually is.

The problem with the suggestion in your first link (rngd -r /dev/urandom) is that you're feeding the output of the kernel's entropy pool back into it, and pretending that this represents new data.  Likewise, the "symlink /dev/random to /dev/urandom" suggestion in the third link forces gpg to use a source of not-necessarily-high-grade randomness when it's expecting a source of high-grade randomness.

The problem with using low-grade randomness when generating RSA keypairs is that if your keypair shares a factor with someone else's keypair, there's a trivial attack that can deduce your private key from your public key (use Euclid's algorithm to compute the GCD of the two public keys, which is one of the prime factors, then use simple division to compute the other prime).  This is particularly a problem with embedded systems that generate a keypair on first boot, when they don't have much if any entropy available.


Can I use the RSA algorithm so that the receiver does not know how to decrypt it? If I don't want the receiver to know what I am encrypting, can I use RSA? I am  embedding the encrypted information along with its HMAC in an image  using steganography... then can I use the RSA algorithm?

For example: encrypt with my public key and decrypt with my private key when needed.
Is this good or should I use AES instead?

The purpose is that if the receiver leaks the data, I can prove that it belongs to me.

You could embed the identifying data in the image, and then encrypt it with a private key (whether RSA or another asymmetric cryptosystem).

Then, everybody can use your public key to decrypt the information that you hid in the image... once you've told people it's there. This would prove that you had hidden some information in the image before it was leaked.