Open Bug 1451986 Opened 7 years ago Updated 2 years ago

Cisco AMP For Endpoints reporting Firefox as Generic IOC

Categories

(External Software Affecting Firefox :: Other, defect)

All
Other
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: rob.evans512, Unassigned)

References

Details

(Whiteboard: [specification][type:bug])

What did you do? ================ 1. Cisco Advanced Malware Protection picked up onmi.ja as IOC 2. Tried researching existing prevalence 3. Tried seeing if this has existed in the wild before What happened? ============== Starting sometime last week, several of our customers picked up the following: Generic IOC: RtoLUnicode.ioc C:\Program Files\Mozilla Firefox\firefox.exe -contentproc --channel=8124.62.849238545\1321440302 -childID 9 -isForBrowser -intPrefs 6:50|7:-1|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|251:1|260:2000|277:4|281:0|290:60000|308:300|309:30| -boolPrefs 1:0|2:0|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:1|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:0|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|181:0|182:1|184:1|186:0|188:1|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|219:0|220:1|221:0|222:1|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:1|305:0|306:0|307:0| -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

 ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{af0e791f-6c46-4432-aecf-2b49763781d3}| -schedulerPrefs 0001,2 -greomni C:\Program Files\Mozilla Firefox\omni.ja -appomni C:\Program Files\Mozilla Firefox\browser\omni.ja -appdir C:\Program Files\Mozilla Firefox\browser 8124 \\.\pipe\gecko-crash-server-pipe.8124 tab What should have happened? ========================== Why are arguements being supplied to firefox, and why are they in right to left format? From Cisco: A filename was detected containing the right to left unicode character. This causes the character string following the symbol to be displayed in reverse. This is used for displaying languages such as Arabic in the correct way. Seeing this in a filename is very unusual, and is known to be used by the OSX malware Janicab. Is there anything else we should know? ====================================== After reversing the argument text, it referencing a file call omni.ja. We are curious as to why this behavior is happening. I've seen this is an optimization tool within Firefox, but why is it referenced as a command line argument. This happened to multiple desktops last week simultaneously. I'm assuming after firefox update? If not is this a valid IOC that should be reported?
Below is an additional trigger that occurred on another machine: File Path: /Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container Command line arguments: /Applications/Firefox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container -childID 31 -isForBrowser -intPrefs 6:50|7:-1|19:0|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|260:2000|277:3|290:60000|308:300|309:30| -boolPrefs 1:0|2:1|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:1|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:1|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|180:0|181:0|182:1|184:1|186:0|190:0|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:0|305:0|306:0|307:0| -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

 ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{8dea759f-057a-f542-a6af-f5791d52ddae}| -schedulerPrefs 0001,2 -greomni /Applications/Firefox.app/Contents/Resources/omni.ja -appomni /Applications/Firefox.app/Contents/Resources/browser/omni.ja -appdir /Applications/Firefox.app/Contents/Resources/browser -profile /Users/dotoole/Library/Application Support/Firefox/Profiles/o7y81eok.default-1469293277497 1241 gecko-crash-server-pipe.1241 org.mozilla.machname.802841719 tab
What's happening here is that the prefs are sent down as argv, and are not always textual data; I suspect what's going on is that there's some random binary that happens to be a unicode RTL codepoint. I believe this is fixed on nightly, where we've switched to using shared memory to pass down prefs. ni?njn who did that work and should be able to confirm.
Flags: needinfo?(n.nethercote)
Group: websites-security → core-security
Component: Security → Other
Product: developer.mozilla.org → External Software Affecting Firefox
Asa: do you know who to pass this on to to reach out to Cisco?
Group: core-security
Component: Other → Untriaged
Flags: needinfo?(asa)
Product: External Software Affecting Firefox → Firefox
Component: Untriaged → Other
Product: Firefox → External Software Affecting Firefox
Hi Alex and Daniel, So I understand this is regular firefox behavior? Should this be expected behavior going forward? If I understand Alex correctly some random firefox binary just so happens to contain unicode U+200F (RTL Mark) and passes it as argv back to firefox? Apologies for lack of knowledge in product internals. I can submit to Cisco if this is behavior that should be whitelisted. Thanks,
Yes, this looks like normal behavior (which will be changed when Firefox 61 is released).
Many Thanks! Happy TGIFFF, -Rob
Bug 1436863 greatly reduced the amount of pref data passed via argv, including the particular pref containing the binary data -- unless a user changed that pref, which is highly unlikely. It will ship in Firefox 60. Bug 1438678 then eliminated the passing of all pref data via argv, making this case impossible, even if the user changed that particular pref. It will ship in Firefox 61.
Depends on: 1436863, 1438678
Flags: needinfo?(n.nethercote)
In case it helps, the binary data for the default value of that pref can be seen at https://dxr.mozilla.org/mozilla-central/rev/62c2508f27a865dd0ac5ca3f0485cb20afafbbd0/modules/libpref/init/all.js#2114 > pref("network.IDN.blacklist_chars", "\u0020\u00A0\u00BC\u00BD\u00BE\u01C3\u02D0\u0337\u0338\u0589\u058A\u05C3\u05F4\u0609\u060A\u066A\u06D4\u0701\u0702\u0703\u0704\u115F\u1160\u1735\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u200B\u200E\u200F\u2010\u2019\u2024\u2027\u2028\u2029\u202A\u202B\u202C\u202D\u202E\u202F\u2039\u203A\u2041\u2044\u2052\u205F\u2153\u2154\u2155\u2156\u2157\u2158\u2159\u215A\u215B\u215C\u215D\u215E\u215F\u2215\u2236\u23AE\u2571\u29F6\u29F8\u2AFB\u2AFD\u2FF0\u2FF1\u2FF2\u2FF3\u2FF4\u2FF5\u2FF6\u2FF7\u2FF8\u2FF9\u2FFA\u2FFB\u3000\u3002\u3014\u3015\u3033\u30A0\u3164\u321D\u321E\u33AE\u33AF\u33C6\u33DF\uA789\uFE14\uFE15\uFE3F\uFE5D\uFE5E\uFEFF\uFF0E\uFF0F\uFF61\uFFA0\uFFF9\uFFFA\uFFFB\uFFFC\uFFFD"); It does include \u200f, as per comment 4.
Here is the command from comment 0 formatted to be more readable: > C:\Program Files\Mozilla Firefox\firefox.exe > -contentproc > --channel=8124.62.849238545\1321440302 > -childID 9 > -isForBrowser > -intPrefs 6:50|7:1|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|251:1|260:2000|277:4|281:0|290:60000|308:300|309:30| > -boolPrefs 1:0|2:0|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:1|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:0|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|181:0|182:1|184:1|186:0|188:1|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|219:0|220:1|221:0|222:1|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:1|305:0|306:0|307:0| > -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

 ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{af0e791f-6c46-4432-aecf-2b49763781d3}| > -schedulerPrefs 0001,2 > -greomni C:\Program Files\Mozilla Firefox\omni.ja > -appomni C:\Program Files\Mozilla Firefox\browser\omni.ja > -appdir C:\Program Files\Mozilla Firefox\browser > 8124 > \\.\pipe\gecko-crash-server-pipe.8124 > tab Things to note: - The binary data containing the RTL char occurs in the argument to the -stringPrefs flag. - omni.ja is subsequently mentioned in the arguments to the -greomni and -appomni flags. Comment 0 says that omni.ja is the problem, but I don't think it is. Rob, do you agree? Perhaps you thought the binary data was part of the omni.ja filename? (Understandable, the command is hard to parse!)
Flags: needinfo?(rob.evans512)
BTW, if Cisco wants to do some testing, Firefox 60 (where it is fixed) is in Beta, and can be obtained here: https://www.mozilla.org/en-US/firefox/channel/desktop/#beta
(In reply to Nicholas Nethercote [:njn] from comment #9) > Here is the command from comment 0 formatted to be more readable: > > > C:\Program Files\Mozilla Firefox\firefox.exe > > -contentproc > > --channel=8124.62.849238545\1321440302 > > -childID 9 > > -isForBrowser > > -intPrefs 6:50|7:1|34:1000|42:20|43:5|44:10|51:0|57:128|58:10000|63:0|65:400|66:1|67:0|68:0|69:100|74:0|75:120|76:120|159:2|160:1|164:60|165:30|166:512000|175:5000|177:6|191:8192|192:524288|193:5|206:10000|227:24|228:32768|230:0|231:0|240:5|244:1048576|246:100|247:5000|249:600|251:1|260:2000|277:4|281:0|290:60000|308:300|309:30| > > -boolPrefs 1:0|2:0|4:1|5:0|24:1|27:0|28:1|29:1|31:1|32:1|33:1|36:1|37:0|38:1|41:1|45:1|46:0|47:0|48:1|49:1|50:1|52:0|55:1|56:1|59:0|60:0|61:0|62:0|64:0|70:1|71:1|72:0|73:1|77:1|78:1|79:0|80:0|81:1|82:1|83:0|84:1|87:0|88:0|91:1|92:1|96:1|97:1|98:0|99:1|100:0|101:0|103:0|104:0|105:1|106:1|107:1|110:1|111:1|112:1|113:1|114:1|115:0|116:0|117:0|119:0|120:1|121:1|122:0|123:0|124:0|125:0|127:1|128:0|129:1|130:1|131:1|132:0|133:0|134:1|135:1|136:1|137:1|138:0|139:1|140:1|141:1|142:1|143:1|144:1|145:0|146:1|147:1|148:0|149:1|150:0|152:0|153:0|154:0|155:1|156:1|157:1|158:1|161:1|162:0|172:0|173:0|174:1|178:1|181:0|182:1|184:1|186:0|188:1|194:1|195:0|196:1|197:1|198:0|201:1|205:1|207:1|208:0|210:1|213:0|219:0|220:1|221:0|222:1|225:0|226:0|229:1|232:0|234:1|235:1|237:1|238:0|245:1|248:1|253:0|254:0|255:0|256:1|257:1|258:0|259:1|264:0|267:1|268:1|269:1|270:1|271:1|272:0|273:0|279:0|282:0|283:0|284:1|285:1|286:0|287:1|288:1|289:1|291:0|292:0|294:0|303:1|304:1|305:0|306:0|307:0| > > -stringPrefs 3:7;release|151:0;|212:3;1.0|223:332; ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

 ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻ 。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞./。ᅠ�|224:4;high|278:38;{af0e791f-6c46-4432-aecf-2b49763781d3}| > > -schedulerPrefs 0001,2 > > -greomni C:\Program Files\Mozilla Firefox\omni.ja > > -appomni C:\Program Files\Mozilla Firefox\browser\omni.ja > > -appdir C:\Program Files\Mozilla Firefox\browser > > 8124 > > \\.\pipe\gecko-crash-server-pipe.8124 > > tab > > Things to note: > > - The binary data containing the RTL char occurs in the argument to the > -stringPrefs flag. > > - omni.ja is subsequently mentioned in the arguments to the -greomni and > -appomni flags. > > Comment 0 says that omni.ja is the problem, but I don't think it is. > > Rob, do you agree? Perhaps you thought the binary data was part of the > omni.ja filename? (Understandable, the command is hard to parse!) You are correct, we were looking for any readable information from argv injection, and not understanding any of the switches we were able to spot omni.ja easily in each sample, and believed it was related (customer lack of knowledge :-) ). I'm happy with the answer, initially both us, and Cisco AMP thought that anything other than user supplied arguments to the firefox.exe was strange. We went into this not understanding how Firefox passes preference data, or any other data for that matter, and in what format is considered normal or not. Thanks, -Rob
Flags: needinfo?(rob.evans512)
> I'm happy with the answer, initially both us, and Cisco AMP thought that anything other than user supplied arguments to the firefox.exe was strange. We went into this not understanding how Firefox passes preference data, or any other data for that matter, and in what format is considered normal or not. Fair enough. In case it helps: these arguments are only used in content processes, which are created by the main process. You'd never use these arguments when invoking Firefox yourself from the command line, for example. (Well, you could, but I'm pretty sure they would be either rejected or ignored.)

Maybe Peter Saint-Andre has contacts with Cisco. I don't know who else to suggest. (Sorry for the extremely late reply to a need info request.)

Flags: needinfo?(asa)

Is this still a live issue in Firefox 67? If so I'm happy to reach out to folks at Cisco.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.