Home Forum Software Security: invalid data injection

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #656

    Replicating the HTTP Get parameters, one can inject (invalid) data into the system, in order to cripple the network and invalidate measurements.

    Current firmware uses an additional CRC , that is harder to replicate by just sniffing the traffic.

    Additional solutions are needed to protect data integrity.

    • This topic was modified 8 years, 2 months ago by uradmonitor.
    Jeff Cooper

    Since you know what interval legitimate devices report at, could an algorithm be made to detect messeges that deviate from this?

    What about pki? That could be used for non-repudiation on the device’s messages. It may be hard to implement/enforce on diy units though.


    Delay check might help at least to exclude packets coming too early, so we could have this among other mechanisms.

    PKI would be excellent, but probably impossible for the reasons you’ve mentioned, but also because it requires a relatively complex code, and the available memory is low.

    We also need to think of a solution as close to plug-and-play as possible. If it’s too hard to implement on DIY units, it will not work.


    Hello Radu, hello Jeff,
    I’m not a friend of total encryption, because it may leed to relying on it.

    Much more easy than spoofing data will be takeing sensors down (server side, client side, routing, …).
    To prevent this, in first step there might be a flashing “offline” LED on the device or the eMail alert you think about …

    But even thou you can make the device believe it’s online.
    At the moment my “urad” sends all data to my own server, where I can do those tests.

    In next step you could show a current average-value on devices display. Anyone will wonde about the difference online/offline if there is spoofing. In total this might be more reliable than encryption.

    But maybe there should be a, lets say .. saltet hash, to prevent easy spoofing.
    When registering a new device, you get a divice-id and a shared secret. This secret has to be used to calculate the crc. So not every teenager can send fake date.



    because the topic is “invalid data injection”, I’d like to add this:

    In my opinion, every sensor (urad or diy) should have (in first thought) two states:
    1) works fine
    2) incidence
    nothing more

    Where “incidence” for example could be:

    • Value out of fixed range per device (also lower than minimum is detected!).
    • Value out of floating (narrow) range, calculated on historical data.
      Also lower than minimum is detected!
      For example: Value out of 4 times the standard deviation of last year except last 3 days.
    • Standard deviation itself (for example last hour) out of fixed limit.
      Meaning devices values are unreliable.
    • Device offline.
    • Device changed IP-Address in other intervals than regular.
      Standard deviation on the “same-IP-timespan”. ?? 🙂
    • Device sent wrong packets within last 3 month.

    Please extend this.

    The idea of this list is, to detect problems with one sensor without relying on the packets the sensor sent.



    Best be if each device had unique key stored in them and it would be attached to device id. Key would be used to hash all data before its sent to server, hash is attached to request.

    Server gets request, looks up device by its id and grabs its key.
    Validates request data ( does same hashing procedure as device ), if everything matches up – request is probably genuine.
    Upsides are that:
    1. devices could be pretty easily blacklisted using this method
    2. it would be hard to fake some other device

    Downsides are that each device would need to have unique binary image on it.


    I had similar project going where program executable had to had unique key in it before all users downloaded.
    My approach to this was to take and compile 4 different excecutables with different known keys in them, then using hexedit find differences between those files. Knowing where each difference was I was able to write relatively small script ( in php ) which used single compiled file and replaced key inside of it before it was served to user.

    Maybe similar strategy could be used here.
    To generate binaries with unique keys, record those keys to database.

    Then it would be in human hands to get bin images inside controllers.


    Indeed patching would automate the production of unique firmware binaries, without compiling the source code every time.

    But there is also the approach presented here: https://www.uradmonitor.com/topic/automated-device-ids/

    The eeprom can also be written without changing the firmware using a separate script, after main firmware is written.


    Can device communicate over HTTPS and have built in certificate validation?

    Edit: Seems like that would be too much for micro-controller 😛

    • This reply was modified 8 years, 2 months ago by Hexide.

    Hello Vinz,

    I think you have covered pretty much everything to secure the problem and even beyond that to detect if a device is behaving suspicious.

    Also @Jeff ‘s suggestion on checking upload interval is important in limiting invalid data.

    Unless anyone has anything else to add, I will propose this as solution, and standardise it in a specs document written for the next firmware release.


    Hello Hexide,
    You’re right; I also proposed this “shared secret” used for hashing (see link automated-device-ids).

    so I missed

    • Devices upload interval is unusual
    • Devices timestamp-value is dubious

    Does someone have other (maybe mathematical) ideas, to detect suspicious data?

    By the way
    you also can LIMIT the number of queries in MySQL.

    Maybe one MySQL-user per device is too much but user-groups for special urad und DIY-devices may be good. (See: http://dev.mysql.com/doc/refman/5.0/en/user-resources.html).

    So one group can’t totally overload the server, and others can still store data.

    Example: You could now use one new user for online requests (SELECT) only.
    If you limit this user, the database will always be able to store new data.


    Vinz, Datawarehouse time! Slightly off topic, but;

    Example: You could now use one new user for online requests (SELECT) only.
    If you limit this user, the database will always be able to store new data.

    Two databases, preferably on different servers, one – the OLTP system (datawarehousing speak: on-line transactional processing) database is where the monitors send their data. Not normally queried.

    Second database is an OLAP (on-line analytical processing) db. Is used for reads/queries. Can be kept near-real time with the OLTP db through clever data shuffling ETL processes.

    Disadvantage is you double your data, bonus is warehouse can be denormalised for speed, can be a history too – if need be, can truncate OLTP tables and still have all data from all time in OLAP warehouse. Also solves problem of read/write contention or query deadlock.

    Sounds like overkill in a project so ‘small’ but it’s growing very quickly and soon we’ll have to consider technologies like this, I think.

Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.